On 2 March 2012 23:18, Igor Stasenko <[email protected]> wrote: > 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.
It's off-topic for this thread, but note that Lukas had to completely remove MC's attempts at atomic loading in LanguageBoxes. In LanguageBoxes you often - perhaps even _usually_? - have instance methods not written in Smalltalk. The environment can parse these correctly only because class-side methods say "no, the instance methods of this class are in <whatever language>, so use <this parser/compiler instead." As a result, you cannot load those instance methods until the class-side methods have been loaded. Really, LanguageBoxes' special tricks apply only to when you can't load method A before you've loaded method B. It's not so much about _atomicity_ as it is about _controllable load order_. frank >> 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. >
