On 3 March 2012 01:13, Marcus Denker <marcus.denker@inria.fr> wrote:
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).
well, atomic loading helps, except from cases when you deal with external resources or VM contracts. fortunately there are not so many of them.
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.
Indeed. And largely unknown, since most people living in edit-compile-run world :)
    Marcus
-- Marcus Denker -- http://marcusdenker.de
-- Best regards, Igor Stasenko.