[Pharo-project] pharo-seed and pharo

Igor Stasenko 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:
>>> 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.




More information about the Pharo-dev mailing list