[Pharo-project] ProjectLauncher readDocumentAtStartup
Hi, this method was changed recently I think probably by the preferences work (Alain Plantec). It used to be a pref. Now it is hard coded to false. Is there a reason? It prevents scripts being executed on the command line. It causes the Mason example to not work in Pharo, and a bunch of other stuff to break. Is there a replacement for loading code on the command line? otherwise this needs changing, perhaps you did not know it is registered in the auto start mechanism. thanks, Mike
Michael Roberts a écrit :
Hi, this method was changed recently I think probably by the preferences work (Alain Plantec). It used to be a pref. Now it is hard coded to false.
Hi Michael, ok, there should a class variable and a setter for that.
Is there a reason? no, its an issue. It will be fixed as soon as possible.
Cheers Alain
Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Issue 1607 <http://code.google.com/p/pharo/issues/detail?id=1607>: ProjectLauncher readDocumentAtStartup a setting argh, it should be ProjectLauncher readDocumentAtStartup needs a setting. not awake enough Alain
BTW projectLauncher is a really funny class to support reading in .st files.... So one of these days we will have to kill it but keep the file loading aspect Stef On Dec 15, 2009, at 7:43 AM, Alain Plantec wrote:
Issue 1607 <http://code.google.com/p/pharo/issues/detail?id=1607>: ProjectLauncher readDocumentAtStartup a setting argh, it should be ProjectLauncher readDocumentAtStartup needs a setting. not awake enough Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse a écrit :
BTW projectLauncher is a really funny class to support reading in .st files....
yes its cool but showSplash and splashURL and eToyAuthentificationServer inst vars are never used; SplashMorph class var is never used (so none of its vars are used). The name, ProjectLauncher isn't that good (no other idea though) So I would at least clean it up (remove unused variables). I would also maybe find another name for it and move it to another package. What do you think ? Michael ? Alain
So one of these days we will have to kill it but keep the file loading aspect
Stef
On Dec 15, 2009, at 7:43 AM, Alain Plantec wrote:
Issue 1607 <http://code.google.com/p/pharo/issues/detail?id=1607>: ProjectLauncher readDocumentAtStartup a setting argh, it should be ProjectLauncher readDocumentAtStartup needs a setting. not awake enough Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Alain Plantec wrote:
Stéphane Ducasse a écrit :
BTW projectLauncher is a really funny class to support reading in .st files....
yes its cool but showSplash and splashURL and eToyAuthentificationServer inst vars are never used; SplashMorph class var is never used (so none of its vars are used). The name, ProjectLauncher isn't that good (no other idea though) So I would at least clean it up (remove unused variables).
It is (or rather was) the launcher used for loading etoys projects in the squeakland image. And more as a side effect it was able to load scripts. Or the script loading was moved into the ProjectLauncher after I added the launcher framework way back then ;-)
I would also maybe find another name for it and move it to another package.
We should throw away the current class and build a new ScriptLoaderLauncher and register it with AutoStart. Michael
I agree the current class is pretty poor. It has some odd conventions when viewed from a unix command line. I had to debug really hard just to find out how to exactly construct the path. However lets please fix the current bug, it is just a small regression. It will at least behave as it use to. Then let's write a new one. I will check out the fix tonight. thanks! Mike On Tue, Dec 15, 2009 at 11:45 AM, Michael Rueger <m.rueger@acm.org> wrote:
Alain Plantec wrote:
Stéphane Ducasse a écrit :
BTW projectLauncher is a really funny class to support reading in .st files....
yes its cool but showSplash and splashURL and eToyAuthentificationServer inst vars are never used; SplashMorph class var is never used (so none of its vars are used). The name, ProjectLauncher isn't that good (no other idea though) So I would at least clean it up (remove unused variables).
It is (or rather was) the launcher used for loading etoys projects in the squeakland image. And more as a side effect it was able to load scripts. Or the script loading was moved into the ProjectLauncher after I added the launcher framework way back then ;-)
I would also maybe find another name for it and move it to another package.
We should throw away the current class and build a new ScriptLoaderLauncher and register it with AutoStart.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mike do you know if this problem was fixed because I need it for coral. Stef On Dec 15, 2009, at 12:15 AM, Michael Roberts wrote:
Hi, this method was changed recently I think probably by the preferences work (Alain Plantec). It used to be a pref. Now it is hard coded to false.
Is there a reason? It prevents scripts being executed on the command line. It causes the Mason example to not work in Pharo, and a bunch of other stuff to break.
Is there a replacement for loading code on the command line? otherwise this needs changing, perhaps you did not know it is registered in the auto start mechanism.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse a écrit :
Mike do you know if this problem was fixed because I need it for coral.
Hi Stef, With my next slice you will be able to do ProjectLauncher readDocumentAtStartup: true Alain
Stef
On Dec 15, 2009, at 12:15 AM, Michael Roberts wrote:
Hi, this method was changed recently I think probably by the preferences work (Alain Plantec). It used to be a pref. Now it is hard coded to false.
Is there a reason? It prevents scripts being executed on the command line. It causes the Mason example to not work in Pharo, and a bunch of other stuff to break.
Is there a replacement for loading code on the command line? otherwise this needs changing, perhaps you did not know it is registered in the auto start mechanism.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
:) Thanks alain. I decided to kill red test on something else... :) but I will look at that. Stef On Dec 17, 2009, at 9:06 PM, Alain Plantec wrote:
Stéphane Ducasse a écrit :
Mike do you know if this problem was fixed because I need it for coral.
Hi Stef, With my next slice you will be able to do ProjectLauncher readDocumentAtStartup: true
Alain
Stef
On Dec 15, 2009, at 12:15 AM, Michael Roberts wrote:
Hi, this method was changed recently I think probably by the preferences work (Alain Plantec). It used to be a pref. Now it is hard coded to false.
Is there a reason? It prevents scripts being executed on the command line. It causes the Mason example to not work in Pharo, and a bunch of other stuff to break.
Is there a replacement for loading code on the command line? otherwise this needs changing, perhaps you did not know it is registered in the auto start mechanism.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
sorry stef, snowed under. will check and comment soon I also want to write to stderr and stdout, just like you no doubt for coral but that is another day ;-) Mike On Thu, Dec 17, 2009 at 8:36 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
:) Thanks alain. I decided to kill red test on something else... :) but I will look at that.
Stef
On Dec 17, 2009, at 9:06 PM, Alain Plantec wrote:
Stéphane Ducasse a écrit :
Mike do you know if this problem was fixed because I need it for coral.
Hi Stef, With my next slice you will be able to do ProjectLauncher readDocumentAtStartup: true
Alain
Stef
On Dec 15, 2009, at 12:15 AM, Michael Roberts wrote:
Hi, this method was changed recently I think probably by the preferences work (Alain Plantec). It used to be a pref. Now it is hard coded to false.
Is there a reason? Â It prevents scripts being executed on the command line. Â It causes the Mason example to not work in Pharo, and a bunch of other stuff to break.
Is there a replacement for loading code on the command line? otherwise this needs changing, perhaps you did not know it is registered in the auto start mechanism.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, there is no comment on the tracker - is the fix ready yet? Also, I don't think it should be a preference. As far as I can tell it is the only mechanism to get the image to run a script from the unix command line and all the VM documentation describes this as a feature I have uploaded the 1 line change required to Inbox and tested it on my mac at least System-Download-MikeRoberts.27 thanks, Mike
You read my mind :) We will arrive there. I hope to send an announce soon for a stupid pre alpha :) Stef
sorry stef, snowed under. will check and comment soon
I also want to write to stderr and stdout, just like you no doubt for coral but that is another day ;-)
Mike
On Thu, Dec 17, 2009 at 8:36 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
:) Thanks alain. I decided to kill red test on something else... :) but I will look at that.
Stef
On Dec 17, 2009, at 9:06 PM, Alain Plantec wrote:
Stéphane Ducasse a écrit :
Mike do you know if this problem was fixed because I need it for coral.
Hi Stef, With my next slice you will be able to do ProjectLauncher readDocumentAtStartup: true
Alain
Stef
On Dec 15, 2009, at 12:15 AM, Michael Roberts wrote:
Hi, this method was changed recently I think probably by the preferences work (Alain Plantec). It used to be a pref. Now it is hard coded to false.
Is there a reason? It prevents scripts being executed on the command line. It causes the Mason example to not work in Pharo, and a bunch of other stuff to break.
Is there a replacement for loading code on the command line? otherwise this needs changing, perhaps you did not know it is registered in the auto start mechanism.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Alain Plantec -
Michael Roberts -
Michael Rueger -
Stéphane Ducasse