> 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.
see below. > 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. see below > 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. Let it makes this clear. I’m personally not interested in moving code from Pharo to VW. I gave its chance long time ago to VW and I only got bad feelings and frustration. So do not expect me to push any action in this direction. The same applies to Squeak. If I would not have created Pharo I would work in Ruby or Python. People paid by VW should do their job not me. Or you can do it if this is in your roadmap. My goal is to have the best environment possible and I’m working to make it. My goal is not to have a smalltalk system compatible with the rest of the universe. Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute with compiler and other on top of GS VM. Now GS is not VW. :) > For now, I’ll settle for getting Iceberg to work reliably in 7.0.3. Perfect. We all use it daily so let know. > Are the best references on Iceberg the Pharo books or the Iceberg GitHub > site? Check both you may find some little differences but in general this is stable. > Which Iceberg material is most up-to-date for Pharo 7.0.3? I do not know. Nothing important changes between 7.0.3 and 8. > 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? I do not know. Windows is often a pain (with file name encodings and others). If you report situations that we can reproduce and that are not super super specific we will definitively have a look. > My Pharo 3.0.7 install and all repos are in non-default directories, and I’m > wondering whether this is causing the crashes. I do not know what is a non-default repo. Now on windows the state of the libraries to run scripts is making us trouble and we will have to fix it. > > > >> 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
