[Pharo-project] [ANN] 10205
- New Diff tools - More collection tests - Collections categories as packages (level one) Next - category as packages collections level two - mike network refactoring (I hope it loads). - bugs, watchit and others etoy removal
Stéphane Ducasse wrote:
Next - category as packages collections level two - mike network refactoring (I hope it loads).
One problem with the network refactoring is that it moves classes between packages and thus needs to be loaded from a configuration map. I tried loadTogether:merge: but that still ends up with classes missing in the image. Suggestions on how to do this? I could port some of the ReleaseBuilder code that allows to script loading of configuration maps. Michael
On Jan 13, 2009, at 3:32 PM, Michael Rueger wrote:
Stéphane Ducasse wrote:
Next - category as packages collections level two - mike network refactoring (I hope it loads).
One problem with the network refactoring is that it moves classes between packages and thus needs to be loaded from a configuration map.
I tried loadTogether:merge: but that still ends up with classes missing in the image.
argh!
Suggestions on how to do this? I could port some of the ReleaseBuilder code that allows to script loading of configuration maps.
I would love to get some knowledge on configuration maps. So if you could it would be great.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Michael Rueger wrote:
Stéphane Ducasse wrote:
Next - category as packages collections level two - mike network refactoring (I hope it loads).
One problem with the network refactoring is that it moves classes between packages I dont see that the following follows. "and thus needs to be loaded from a configuration map."
Option 1, Atomic loading. Available in MC1.5/6 as an option that can be enabled. Option 2, Out of order loading feature of MC1.5.
I tried loadTogether:merge: but that still ends up with classes missing in the image.
Might be worth finding out why.
Suggestions on how to do this? I could port some of the ReleaseBuilder code that allows to script loading of configuration maps.
Installer handles mcm's.
Michael
Keith
Keith Hodges wrote:
Michael Rueger wrote:
I dont see that the following follows.
"and thus needs to be loaded from a configuration map."
Option 1, Atomic loading. Available in MC1.5/6 as an option that can be enabled.
hmm, we don't have MC 1.5 in Pharo yet, or did I miss that?
I tried loadTogether:merge: but that still ends up with classes missing in the image.
Might be worth finding out why.
Because it loads one package after the other. Usually the right load order fixes the problem, but in this case loading stops working because crucial classes go missing during loading. Michael
Michael Rueger wrote:
Stéphane Ducasse wrote:
Next - category as packages collections level two - mike network refactoring (I hope it loads).
ok, not sure if that is the best way to do it, but at least it allowed me to move forward :-) In the inbox there are two updates to ScriptLoader with updates 207 and 208 and new MC packages. 207 adds configuration map support to the ScriptLoader and also merges a couple of changes from the impara branch to allow "atomic" loading of configuration maps. 208 then loads the network changes. Michael
On Jan 13, 2009, at 5:39 PM, Michael Rueger wrote:
Keith Hodges wrote:
Michael Rueger wrote:
I dont see that the following follows.
"and thus needs to be loaded from a configuration map."
Option 1, Atomic loading. Available in MC1.5/6 as an option that can be enabled.
hmm, we don't have MC 1.5 in Pharo yet, or did I miss that?
No this is my huge pile of todo... I hope to finish with my house and get time soon.
I tried loadTogether:merge: but that still ends up with classes missing in the image.
Might be worth finding out why.
Because it loads one package after the other. Usually the right load order fixes the problem, but in this case loading stops working because crucial classes go missing during loading.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Cool I will have a look. Not now I have to finish two papers.... argh. On Jan 13, 2009, at 6:58 PM, Michael Rueger wrote:
Michael Rueger wrote:
Stéphane Ducasse wrote:
Next - category as packages collections level two - mike network refactoring (I hope it loads).
ok, not sure if that is the best way to do it, but at least it allowed me to move forward :-) In the inbox there are two updates to ScriptLoader with updates 207 and 208 and new MC packages.
207 adds configuration map support to the ScriptLoader and also merges a couple of changes from the impara branch to allow "atomic" loading of configuration maps.
208 then loads the network changes.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/1/13 Michael Rueger <m.rueger@acm.org>:
Keith Hodges wrote:
Michael Rueger wrote:
I dont see that the following follows.
"and thus needs to be loaded from a configuration map."
Option 1, Atomic loading. Available in MC1.5/6 as an option that can be enabled.
hmm, we don't have MC 1.5 in Pharo yet, or did I miss that?
I tried loadTogether:merge: but that still ends up with classes missing in the image.
Might be worth finding out why.
Because it loads one package after the other. Usually the right load order fixes the problem, but in this case loading stops working because crucial classes go missing during loading.
which only shows that code stinks and need further refactorings to avoid heavy package interdependencies. don't blame the tool :)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Tue, Jan 13, 2009 at 10:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Because it loads one package after the other. Usually the right load order fixes the problem, but in this case loading stops working because crucial classes go missing during loading.
which only shows that code stinks and need further refactorings to avoid heavy package interdependencies. don't blame the tool :)
In this case it is a problem with how MC treats a class move. If you load the package first that now includes the class, loading the other removes the class from the system. Loading the packages the way round works. After loading the first package the class is missing, then added by the other package the class was moved to. Unfortunately in this case the missing classes are needed for loading packages so you are stuck. Michael
participants (4)
-
Igor Stasenko -
Keith Hodges -
Michael Rueger -
Stéphane Ducasse