On 3 March 2012 01:13, Marcus Denker <[email protected]> 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.
