Hi matthew Thanks for your explanation. We were afraid by MC1.5 because - the atomic loading features as hacked by ralph looked dubious to us. we did not want to break the dependency mechanism - the problem with PLF is that it looks like a black box that loads a lot of stuff and we do not know why - since we do **everything** with MC is should work 100% or we are dead. Now we would be happy to ask our MC expert (yes I looked at adrian and lukas) :) to check your changes and slowly incorporate them. Alex did a small but cool improvement: dirty packages are always at the top of the mc browser. We found that cool and integrate it.
Indeed. Monticello is hard to load, precisely because the loader is being modified while loading. Thus, we have a script that is able to reliably load Monticello 1.5 onto any image:
http://installer.pbwiki.org/LevelPlayingField
To run it, do this: (I just tested it and got it working in Pharo)
HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st'
The actual job of loading Monticello is done here:
http://installer.pbwiki.org/LevelPlayingField-Monticello15
Notice the technique: first a plain file-out of PackageInfo and Monticello is loaded, next, nearly the exact same packages is loaded via Monticello. This ensures that the changes made to Monticello while Monticello is running are minimal. I keep that script up-to-date as I make changes to Monticello 1.5.
Monticello and PackageInfo have a number of improvements:
- Packages can be loaded out-of-order,
what does it mean exactly?
as orphaned methods and classes are stored in an Orphanage, which is revisited when loading later packages
- Tests can be separately packages from the main code, without extensive repackaging: Name a package Monticello.impl to get classes in Monticello-*, except for those that end in *-Tests, or name a package Monticello.tests to get all packages in categories Monticello-*-Tests
We would go for real packages = without relying only on naming conventions so I do not know if this one is really useful.
- A new dual version sorter, able to view changes between arbitrary versions in a repository; in the right pane of the MC browser, use the menu item "open dual changes browser"
Cool
- Working MonticelloConfigurations That I would really want and per package source so that we can load magritte in luask repos and moose in squeaksource and ob in wiresong
- I am fixing bugs in a new loader for Monticello that does code loading in a truly atomic fashion: code is swapped into the system, and pointers are revised in exactly ONE primitive. I have it working well enough that I made it my default loader.
This is really important.
It is able to load problematic packages that are sensitive to inconsistencies during loading, like Monticello and Morphic. As an Acid test, I am able to load Monticello using the new package loader, which has, until now, been impossible in any version of Monticello.
Good
The biggest remaining issue is Traits support;
Argh this is on my pipeline to check andreas proposal to have traits as subclass of classdescription but I did not find the time to check that.
Packages with traits are not supported. To try it out, run this after running the LPF script above:
Installer install: 'Monticello16-Beta'
In the past, people have had various problems with Monticello 1.5, such as loading FFI and strange issues with Instance variables. Keith and I were somewhat unaware of these until they were brought to our attention on IRC, and have since been fixed. This product is under active development, and our goal is to get the same very useful version of Monticello running on every active Squeak platform, and we have done so, to the best of our knowledge. So if you find a problem, please let us know and we will fix it, most likely within the hour. IRC is the best way; mailing lists are next.
Excellent.
I realize LevelPlayingField is not the preferred mechanism to load stuff into Pharo,
exact. I will be against loading stuff nobody look at.
and it brings along two other things beside Monticello 1.5 (namely, Installer and Launcher).
I like the installer even if one day we will refactor it :)
I will try to prepare something suitable for loading Monticello 1.5 into Pharo, but it cannot be a plain SLICE package, due to the Monticello loading problems I explained above. I'll read up at http://code.google.com/p/pharo/wiki/HowToContribute
Sure this is the rule for simple stuff. after we can use Installer or Cs.
I'll also see what changes Stef and Lukas made to Monticello as part of Pharo and attempt to merge them.
We wanted to have a rock solid version because it is and will be our backbone.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project