> On 1 Jun 2019, at 11:08, Shaping <[email protected]> wrote:
>
>
> 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.
Tonel (and FileTree) are representations and models of code.
> 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.
Iceberg works very well in 7.x and 8, it is the default after all.
You are on Windows, other Windows users should answer.
>> 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
