When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me the following (yes back in 96) translated from Yoda language: you will be a real Jedi when your code will load in one click! you will be a real Jedi when your code will unload in one click and do not let shit behind it! Simple no. So when do we get real Jedi knights? Stef
I prefer being a technomage to a jedi, jedies are too, well naive and purists. By the way so how one can unload a project from the pharo image ? I never tried that one before. On Thu, Nov 19, 2015 at 10:59 PM stepharo <stepharo@free.fr> wrote:
When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me the following (yes back in 96)
translated from Yoda language:
you will be a real Jedi when your code will load in one click! you will be a real Jedi when your code will unload in one click and do not let shit behind it!
Simple no. So when do we get real Jedi knights?
Stef
+1 By the way so how one can unload a project from the pharo image ? I never tried that one before. Use the Force Dimitris Sorry I dont have the answer for this now, but I am interested on this issue. 2015-11-19 18:05 GMT-04:00 Dimitris Chloupis <kilon.alios@gmail.com>:
I prefer being a technomage to a jedi, jedies are too, well naive and purists.
By the way so how one can unload a project from the pharo image ? I never tried that one before.
On Thu, Nov 19, 2015 at 10:59 PM stepharo <stepharo@free.fr> wrote:
When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me the following (yes back in 96)
translated from Yoda language:
you will be a real Jedi when your code will load in one click! you will be a real Jedi when your code will unload in one click and do not let shit behind it!
Simple no. So when do we get real Jedi knights?
Stef
To unload a package you can do it from Monticello Browser..Select the package (left column), right click, "Unload Package". But not that it will not work properly in cases where you have method overrides (the original methods you override will NOT be recovered), or class collisions (imagine your package has a class name collision with a class name of another package)... Then you can have instances of classes you unload...hence the Obsolete thingy (instances are now instance of an obsolete class). Then you can also have subclasses in ANOTHER package of classes of the package you unload. What you do with the subclasses? and with the instances of such subclasses? So... order of unloading does matter across packages (in the same way that loading does). So for unloading multiple packages you should be using Meacello or similar. As you can see, it's not an easy task. On Thu, Nov 19, 2015 at 7:23 PM, milton mamani <akevalion@gmail.com> wrote:
+1 By the way so how one can unload a project from the pharo image ? I never tried that one before.
Use the Force Dimitris
Sorry I dont have the answer for this now, but I am interested on this issue.
2015-11-19 18:05 GMT-04:00 Dimitris Chloupis <kilon.alios@gmail.com>:
I prefer being a technomage to a jedi, jedies are too, well naive and purists.
By the way so how one can unload a project from the pharo image ? I never tried that one before.
On Thu, Nov 19, 2015 at 10:59 PM stepharo <stepharo@free.fr> wrote:
When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me the following (yes back in 96)
translated from Yoda language:
you will be a real Jedi when your code will load in one click! you will be a real Jedi when your code will unload in one click and do not let shit behind it!
Simple no. So when do we get real Jedi knights?
Stef
-- Mariano http://marianopeck.wordpress.com
Thanks for the info. I think i am on safe side of things since I dont mess with pharo internals. You say if I override an existing method, that method cannot be recovered, but that is strange since the system does have versions for each method , so I assume here that is not that is not possible rather than none actually implemented this in a convenient way. How you can have class collision , I assumed so far that the system does not allow you to have two classes with the same name. If you have subclasses in another package then I would let them MNU. I think its kinda insane to try to protect the user from all scenarios, at least not before you deal with more pressing issues / bugs. One thing that could help here is to have something similar to when we install a project that warns us that a project depends on other projects/ classes we could have the same warning for when we remove classes. I think also its a good idea to allow user some control, for example maybe the user want to keep those subclasses and make them subclass another class instead. Yeah I will look into unloading with metacello that sounds cleaner this is an issue that really interests me. How to make my project uninstallable and automatically update-able is two areas that deeply interest me. On Fri, Nov 20, 2015 at 12:56 AM Mariano Martinez Peck < marianopeck@gmail.com> wrote:
To unload a package you can do it from Monticello Browser..Select the package (left column), right click, "Unload Package". But not that it will not work properly in cases where you have method overrides (the original methods you override will NOT be recovered), or class collisions (imagine your package has a class name collision with a class name of another package)... Then you can have instances of classes you unload...hence the Obsolete thingy (instances are now instance of an obsolete class). Then you can also have subclasses in ANOTHER package of classes of the package you unload. What you do with the subclasses? and with the instances of such subclasses? So... order of unloading does matter across packages (in the same way that loading does). So for unloading multiple packages you should be using Meacello or similar.
As you can see, it's not an easy task.
On Thu, Nov 19, 2015 at 7:23 PM, milton mamani <akevalion@gmail.com> wrote:
+1 By the way so how one can unload a project from the pharo image ? I never tried that one before.
Use the Force Dimitris
Sorry I dont have the answer for this now, but I am interested on this issue.
2015-11-19 18:05 GMT-04:00 Dimitris Chloupis <kilon.alios@gmail.com>:
I prefer being a technomage to a jedi, jedies are too, well naive and purists.
By the way so how one can unload a project from the pharo image ? I never tried that one before.
On Thu, Nov 19, 2015 at 10:59 PM stepharo <stepharo@free.fr> wrote:
When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me the following (yes back in 96)
translated from Yoda language:
you will be a real Jedi when your code will load in one click! you will be a real Jedi when your code will unload in one click and do not let shit behind it!
Simple no. So when do we get real Jedi knights?
Stef
-- Mariano http://marianopeck.wordpress.com
Good points. And, even if it all worked, would anyone still prefer not to simply rebuild an image with all the code? IOW, wouldn't they "trust" an image that was only built UP rather than one built up and then partially torn down? IMO, unloading is for the viewpoint of having an "ultimate image" which is never replaced. Once ability to build from first-principles is solved, one can use the boundary of the image to fit many use cases, it becomes just another of many memory spaces, no longer "the" one, grand, image. Then the need to unload is greatly diminished. Unloading is good for custom-trimming an image of unwanted functionality which could not be built to spec because its packages are not in fine-enough granules, perhaps so it can be more suitable for a production environment (e.g., remove the server development tools). On Thu, Nov 19, 2015 at 4:55 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
To unload a package you can do it from Monticello Browser..Select the package (left column), right click, "Unload Package". But not that it will not work properly in cases where you have method overrides (the original methods you override will NOT be recovered), or class collisions (imagine your package has a class name collision with a class name of another package)... Then you can have instances of classes you unload...hence the Obsolete thingy (instances are now instance of an obsolete class). Then you can also have subclasses in ANOTHER package of classes of the package you unload. What you do with the subclasses? and with the instances of such subclasses? So... order of unloading does matter across packages (in the same way that loading does). So for unloading multiple packages you should be using Meacello or similar.
As you can see, it's not an easy task.
On Thu, Nov 19, 2015 at 7:23 PM, milton mamani <akevalion@gmail.com> wrote:
+1 By the way so how one can unload a project from the pharo image ? I never tried that one before.
Use the Force Dimitris
Sorry I dont have the answer for this now, but I am interested on this issue.
2015-11-19 18:05 GMT-04:00 Dimitris Chloupis <kilon.alios@gmail.com>:
I prefer being a technomage to a jedi, jedies are too, well naive and purists.
By the way so how one can unload a project from the pharo image ? I never tried that one before.
On Thu, Nov 19, 2015 at 10:59 PM stepharo <stepharo@free.fr> wrote:
When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me the following (yes back in 96)
translated from Yoda language:
you will be a real Jedi when your code will load in one click! you will be a real Jedi when your code will unload in one click and do not let shit behind it!
Simple no. So when do we get real Jedi knights?
Stef
-- Mariano http://marianopeck.wordpress.com
IMO, unloading is for the viewpoint of having an "ultimate image" which is never replaced.
Or, at least, not replaced from scratch while you're in the middle of day-to-day work and don't want to have to recreate a bunch of useful state somewhere else. Unloading has practical value. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Le 19/11/15 23:13, Chris Muller a écrit :
translated from Yoda language:
you will be a real Jedi when your code will load in one click! In Yoda grammar:
"When, in one click, your code will load, then, and only then, a Jedi will you be..." :)
Thanks my decoder was not working well :)
Stef writes:
When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me the following (yes back in 96)
translated from Yoda language:
you will be a real Jedi when your code will load in one click! you will be a real Jedi when your code will unload in one click and do not let shit behind it!
Simple no. So when do we get real Jedi knights?
We get them when we have modules that exist as live objects all the time, to which we can delegate the task of unloading. Those modules have access to all versions of methods and class definitions, and every method and class definition is covered by the module system at all times. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
participants (6)
-
Chris Muller -
Craig Latta -
Dimitris Chloupis -
Mariano Martinez Peck -
milton mamani -
stepharo