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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
