[Pharo-project] pharo-seed and pharo
siguctua at gmail.com
Fri Mar 2 18:18:56 EST 2012
On 3 March 2012 01:13, Marcus Denker <marcus.denker at 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:
>>> 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:
> "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
> 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 Denker -- http://marcusdenker.de
More information about the Pharo-dev