On Mar 2, 2012, at 11:11 PM, Marcus Denker wrote:

> 
> On Mar 2, 2012, at 9:21 PM, Tudor Girba wrote:
>> 
>> Ok. So I downloaded the first Pharo Core 1.4:
>> https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip
>> 
>> but, I still do not know what packages to load. Is there an easy way to 
>> figure these ones out (and in particular the loading order)?


The update is done by ScriptLoaders #update* methods.

e.g. one of the first ones:

update14002
        "self new update14002"
        self withUpdateLog: '- remove ToolBuilder'.
        self loadTogether: self script267 merge: false.
        (MCPackage named: 'ToolBuilder-Morphic') unload.
        (MCPackage named: 'ToolBuilder-Kernel') unload.
        self flushCaches.


#script267 defines which MC packages are to be loaded for 14002. The list of 
packages slowly changes...
(e.g. in 14003 there will be no ToolsBuilder anymore, as we removed it here).

The #loadTogether:merge: shows that there is actually no load order... the 
changes are loaded together as
if it would be one package. So we just have the load-order of MC to worry 
about, which can be wrong... 
In that case, one has split the update in two: first add the classes/methods, 
then change the calling code.
If everything fails, we do have changesets where we can hard-reorder stuff.

Besides that, there is the proble of object migration. E.g. we removed things 
from the startuplist, the specialObjectArray...
e.g. in MorphicUIManager there is class var with the UI process. This used to 
be in Project, which is not there anymore...

I think what one could do is to combine updates of the simple kind. E.g. if we 
would have atomic loading, load order
problems would disapear. Then one could batch all updates together where there 
is no reflective change done in a postscript
(which happens, but not that often).

Another thing that one would need to do is to destinguish between "hot" code 
that is run when updating and the other.
One could structure the system in a way that the "active" code when updating is 
well known and controlled, and the non-active
one could be done in a way that state manipulations are part of a general 
inialization scheme and expicit...

There are lots of things to think about for the problem of updating a running 
system... difficult problem. Nice research area.

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply via email to