Begin forwarded message:
From: Matthew Fulmer <[EMAIL PROTECTED]>
Date: July 3, 2008 8:38:24 PM CEDT
To: stephane ducasse <[EMAIL PROTECTED]>
Cc: Matthew Fulmer <[EMAIL PROTECTED]>, Keith Hodges <[EMAIL PROTECTED]
>
Subject: Re: I'm interesting in knowing more on your atomic loading
On Thu, Jul 03, 2008 at 07:21:21PM +0200, stephane ducasse wrote:
Hi matthew
how can i learn about your atomic loading?
Stef
===== History =====
Atomic loading is a feature Colin Putney implemented for MC2,
then released as a separate, quite unstable library:
SystemEditor
http://www.squeaksource.com/SystemEditor/
Goran and I picked up this library as a core component of
DeltaStreams, and we fixed many bugs it had with loading
different combinations of things, due to not being tested in
production. In the meantime, Keith Hodges wrote a new package
loader for Monticello 1.5 that hooked into SystemEditor to take
advantage of it's atomic loading property. It hardly worked at
all, but the principle was there. See the class MCPackageLoader2
in Monticello 1.5:
http://www.squeaksource.com/mc/
I have since stopped working on DeltaStreams and started working
heavily with Keith in improving the basic tools in the image and
making new ones. Since I was already familiar with SystemEditor
due to my work on DeltaStreams, I volunteered to work on package
loader 2. I fixed a dozen or so bugs in both package loader 2
and SystemEditor, and now it is able to load quite a few
packages. It is still beta phase though. It is not yet able to
cope with the following:
Byte/Word/Weak classes
Traits
Tweak classes
I'm fixing those inadequacies in the order listed. Once they are
fixed, we will release PackageLoader2 as the default in
Monticello, and increment the version number of Monticello to
1.6.
===== How it works ====
SystemEditor has a set of classes (editor classes) that respond
to the same protocol as Class, Metaclass, MethodDictionary,
ClassOrganizer, SystemDictionary, and other related core
classes. Each one acts as an "editor" on an existing object in
the system. These editors respond to the same protocol as the
object they edit, but maintain changes internally, usually as a
list of additions/removals. When the time comes to commit the
changes (See SystemEditor>>commit), all these editors are passed
a MigrationTransaction object, and are asked to submit the old
and new copy of the object they are editing, which will be
swapped at commit time. When all objects have done this,
MigrationTransaction builds two arrays: one of old objects, and
one of new, and invokes the primitive
Array>>exchangeElementIdentityWith: , which does a bulk identity
swap (see MigrationTransaction>>commit). Everything that needs
to change is swapped: Recompiled classes, instances of those
classes, new methodDictionaries for classes that don't need
recompiling, Smalltalk, the SystemDictionary instance,
ClassOrganization instances, and so on, all during one
primitive.
===== Status =====
I'm fairly confident in Monticello1.6-beta, as it currently
exists. I use it as my default loader in all of my images,
except when I am dealing with Tweak in my croquet images.
To try it out, do the following:
HTTPSocket httpFileIn: 'installer.pbwiki.com/f/LPF.st'.
Installer install: 'Monticello16-Beta'
This loads LevelPlayingField (= Installer and MC1.5) and then
runs my script to load SystemEditor and activate PackageLoader2.
Pages you may want to read:
LevelPlayingField: a script to load Installer and MC1.5 into
most any image in use:
http://installer.pbwiki.org/LevelPlayingField
The script that loads MC1.5:
http://installer.pbwiki.org/LevelPlayingField-Monticello15
The script that activates MCPackageLoader2 (it is under
"Contributed Scripts" in the sidebar)
http://installer.pbwiki.org/Monticello16-Beta
--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
