Ok.
So Iceberg will not try to wrap other modes of conversion and versioning like
STON
STON is not for versioning code.
But objects.
Yes, I know. I was referring to its possible use in moving Smalltalk between
environs. It’s normally used for domain objects, but it could be used to
serialize code itself (just another domain object), if we have no universal
chunk format for Smalltalk. Seems that STON could be managed somehow from
within Iceberg to move class/method definitions, but we also have the different
package- and namespace- structures needing specialization for each environment.
Similar comments apply to unique syntax specializations, like the
period-delimited literal-array evaluables possible in Pharo, but not in VW, for
example. STON under Iceberg might also let us add or strip class-name
prefixes, automatically, when porting between Smalltalks with/without
modules/namespaces, like VW and Pharo, for example. I’m thinking every
Smalltalk would have an Iceberg. It would be the go-to tool for versioning and
conversion of Smalltalk code for any environ.
For now, I’ll settle for getting Iceberg to work reliably in 7.0.3. Are the
best references on Iceberg the Pharo books or the Iceberg GitHub site? Which
Iceberg material is most up-to-date for Pharo 7.0.3?
Is anyone reporting stability/VM problems with Pharo installed to a non-default
directory and/or when working with GitHub repos not kept in the default
subfolder of the image folder? My Pharo 3.0.7 install and all repos are in
non-default directories, and I’m wondering whether this is causing the crashes.
and Monticello to provide a kind of seamless LCD approach and some backward
compatibility with Monticello (without encouraging new use of Monticello)?
No because the distance is too large. We cannot burn our two engineers on “nice
to have” when the “must have” is
not yet done.
Now migrating to iceberg is super easy and configurations are a lot simpler
than with monticello.
Stef
Shaping
