Re: [Pharo-project] pharo-seed and pharo
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)?
It's not possible to turn 1.4000 into the current one by loading packages in one step. because there are lots of objects that need to be migrated... it's a living system. There was *a lot* of manual fiddling involved, even just from one step to the next. Marcus -- Marcus Denker -- http://marcusdenker.de
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)?
It's not possible to turn 1.4000 into the current one by loading packages in one step. because there are lots of objects that need to be migrated... it's a living system.
There was *a lot* of manual fiddling involved, even just from one step to the next.
As a very simple example of a change that will be integrated soon: http://code.google.com/p/pharo/issues/detail?id=5217 An example of a *single* change that is not loadable with monticello. For a slighlty more complex one: http://code.google.com/p/pharo/issues/detail?id=5290 This one will be loaded as a hand-orderd changeset... There are many, many examples... changes to MC, replacing the EventSensor classes (and removing the old ones later...), changes in collections.... Marcus -- Marcus Denker -- http://marcusdenker.de
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). 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. Marcus -- Marcus Denker -- http://marcusdenker.de
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.
On 2 March 2012 23:18, Igor Stasenko <siguctua@gmail.com> wrote:
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.
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.
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)?
It's not possible to turn 1.4000 into the current one by loading packages in one step. because there are lots of objects that need to be migrated... it's a living system.
There was *a lot* of manual fiddling involved, even just from one step to the next.
but can we try and see :)
Marcus
-- Marcus Denker -- http://marcusdenker.de
participants (4)
-
Frank Shearar -
Igor Stasenko -
Marcus Denker -
Stéphane Ducasse