How are command line arguments intended for the image supposed to be dealt with these days? It’s an awfully long time since last I looked at this area and the code I’m seeing in the image is… convoluted.
I need to be able to handle some simple cases for Scratch startup and we seem to have completely changed how that area is handled. I have come across (and reeled in horror) code in ProjectLauncher, AutoStart etc but so far I don’t see anything to make it all make sense in my head. I don’t suppose anybody knows of a correct wiki page? Not found one so far.
Maybe I need to drop one or more of the current startup related classes and write a ScratchStart class?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Programmer: One who is too lacking in people skills to be a software engineer.
A good soul should take a look at Pharo and pick the good bytes from there
2014-09-30 20:12 GMT+02:00 tim Rowledge tim@rowledge.org:
How are command line arguments intended for the image supposed to be dealt with these days? It’s an awfully long time since last I looked at this area and the code I’m seeing in the image is… convoluted.
I need to be able to handle some simple cases for Scratch startup and we seem to have completely changed how that area is handled. I have come across (and reeled in horror) code in ProjectLauncher, AutoStart etc but so far I don’t see anything to make it all make sense in my head. I don’t suppose anybody knows of a correct wiki page? Not found one so far.
Maybe I need to drop one or more of the current startup related classes and write a ScratchStart class?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Programmer: One who is too lacking in people skills to be a software engineer.
On Tue, Sep 30, 2014 at 10:29:20PM +0200, Nicolas Cellier wrote:
2014-09-30 20:12 GMT+02:00 tim Rowledge tim@rowledge.org:
How are command line arguments intended for the image supposed to be dealt with these days? It???s an awfully long time since last I looked at this area and the code I???m seeing in the image is??? convoluted.
I need to be able to handle some simple cases for Scratch startup and we seem to have completely changed how that area is handled. I have come across (and reeled in horror) code in ProjectLauncher, AutoStart etc but so far I don???t see anything to make it all make sense in my head. I don???t suppose anybody knows of a correct wiki page? Not found one so far.
Maybe I need to drop one or more of the current startup related classes and write a ScratchStart class?
A good soul should take a look at Pharo and pick the good bytes from there
Good idea to take a look at the Pharo handling. But I think the Squeak handling has been pretty much unchanged for quite a while and it does still work. I'm using a unix VM, and there may be some platform differences, but the basic idea is that any command line parameters intended for the VM will be handled by the VM, and you then specify image name followed by document name followed by any other parameters that you may want to pass along to the image. The first thing after the image name is treated as a startup document, so that needs to be present if you intend to also pass along some other parameters. The remaining parameters are available to the image (evaluate "Smalltalk arguments"). Thus you can do something like this:
$ /usr/local/bin/squeak -vm-sound-pulse myImage.image myStartupDocument.st param1 param2 param3
The arguments #('param1' 'param2' 'param3') will be available for use in your myStartupDocument.st start script.
Dave
On 30-09-2014, at 3:16 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 30, 2014 at 10:29:20PM +0200, Nicolas Cellier wrote:
A good soul should take a look at Pharo and pick the good bytes from there
Good idea to take a look at the Pharo handling.
Yes, indeed.
But I think the Squeak handling has been pretty much unchanged for quite a while and it does still work. I'm using a unix VM, and there may be some platform differences, but the basic idea is that any command line parameters intended for the VM will be handled by the VM, and you then specify image name followed by document name followed by any other parameters that you may want to pass along to the image. The first thing after the image name is treated as a startup document, so that needs to be present if you intend to also pass along some other parameters. The remaining parameters are available to the image (evaluate "Smalltalk arguments"). Thus you can do something like this:
$ /usr/local/bin/squeak -vm-sound-pulse myImage.image myStartupDocument.st param1 param2 param3
The arguments #('param1' 'param2' 'param3') will be available for use in your myStartupDocument.st start script.
That’s what I thought would be the case. It seems a bit more complex though since some attempted testing dropped me into a problem with AutoStart (which does some fairly involved reading and fiddling with any arguments) passing on to ProjectLauncher>startUp >>>startUpAfterLogin which seems to want to treat any words in the commandline as filepaths and then use a CodeLoader to read them in. For example,` {vm} scratch.image fooble` fails part way through starting up because of an attempt to load `file:///home/pi/Scratch/fooble`.
Scratch expects (and this is documented old stuff that people appear to rely upon so I can’t easily change it, probably) to be able to do `{vm} scratch.image presentation fullscreen myProject.sb` and to get presentation and fullscreen as sort of keywords and the *.sb as a project filename.
As an aside I see that the class ProjectLauncher is only referenced in InstallerCruft class>>classProjectLauncher and InstallerCruft is not referenced at all. And I can’t find any actual code that installs it in AutoStart’s very short list of `InstalledLaunchers` so just possibly it isn’t supposed to be there any more?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Braccae illae virides cum subucula rosea et tunica Caledonia-quam elenganter concinnatur! = Those green pants go so well with that pink shirt and the plaid jacket!
On Tue, Sep 30, 2014 at 03:56:13PM -0700, tim Rowledge wrote:
On 30-09-2014, at 3:16 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 30, 2014 at 10:29:20PM +0200, Nicolas Cellier wrote:
A good soul should take a look at Pharo and pick the good bytes from there
Good idea to take a look at the Pharo handling.
Yes, indeed.
But I think the Squeak handling has been pretty much unchanged for quite a while and it does still work. I'm using a unix VM, and there may be some platform differences, but the basic idea is that any command line parameters intended for the VM will be handled by the VM, and you then specify image name followed by document name followed by any other parameters that you may want to pass along to the image. The first thing after the image name is treated as a startup document, so that needs to be present if you intend to also pass along some other parameters. The remaining parameters are available to the image (evaluate "Smalltalk arguments"). Thus you can do something like this:
$ /usr/local/bin/squeak -vm-sound-pulse myImage.image myStartupDocument.st param1 param2 param3
The arguments #('param1' 'param2' 'param3') will be available for use in your myStartupDocument.st start script.
That?s what I thought would be the case. It seems a bit more complex though since some attempted testing dropped me into a problem with AutoStart (which does some fairly involved reading and fiddling with any arguments) passing on to ProjectLauncher>startUp >>>startUpAfterLogin which seems to want to treat any words in the commandline as filepaths and then use a CodeLoader to read them in. For example,` {vm} scratch.image fooble` fails part way through starting up because of an attempt to load `file:///home/pi/Scratch/fooble`.
AutoStart is in the startup list. It has no class comment (WTF?!? Why not?). But it looks like it maintains a registry of launchers that presumably are intended to implement code loaders at image startup time. It further obfuscates the situation by invoking #startUp on the classes in its registry, as if they had been in the startup list, even though they are not in the starup list, and even though nobody could be bothered to document this in a class comment.
Happily, class AbstractLauncher does have an excellent comment (yay!) that explains what is going on, and one of its two concrete subclasses also has a comment. The other subclass is the one that we actually use in the registry (ProjectLauncher), so naturally it does not have a class comment.
That said, one might reasonably guess that the undocumented class ProjectLauncher that is invoked by the undocumented class AutoStart might very well be the thing thing that is producing the unexpected behavior that is causing problems for Scratch invocation.
I have not tried this, but I am guessing that "AutoStart removeLauncher: ProjectLauncher" might disable the unwanted document loading from the command line handling. Or perhaps, and here I am just guessing again, "AutoStart active: false" might just disable the whole thing entirely, which is possibly what you want for the Scratch loading.
Scratch expects (and this is documented old stuff that people appear to rely upon so I can?t easily change it, probably) to be able to do `{vm} scratch.image presentation fullscreen myProject.sb` and to get presentation and fullscreen as sort of keywords and the *.sb as a project filename.
A perfectly sensible expectation.
As an aside I see that the class ProjectLauncher is only referenced in InstallerCruft class>>classProjectLauncher and InstallerCruft is not referenced at all. And I can?t find any actual code that installs it in AutoStart?s very short list of `InstalledLaunchers` so just possibly it isn?t supposed to be there any more?
I don't actually think it's crufty at all, despite my commentary above. The class comment for InstallerCruft looks a bit crufty in its own right. What *does* seem to be missing is a comment for ProjectLauncher and for AutoStart, as well as a class initialization method somewhere that sets up the registery of launchers in AutoStart.
If you do decide to implement a startUp loader specifically for Scratch, you would probably want to implement it as a subclass of AbstractLauncher, and register it in the AutoStart registry.
Dave
Don't "reel in horror" drama-boy. Squeak's command-line processing is simple and effective. I use it heavily every day.
As you know, you can just pass in your arguments into the command-line like this:
squeak my.image arg1 arg2 arg3 &
Normally, "arg1" is the name of a .st script you would like to execute, while arg2 and arg3 are arguments to that script. This is useful when you want to give the image instructions from a file in the OS.
Normally, the .st script would contain something like the following:
Smalltalk runAndQuit: [ : arg2 : arg3 | "Do something. arg2 and arg3 are the Strings from the command-line." ]
After executing the block, the image will exit without saving. That is useful for batch applications but if you want to launch a server or something interactive where the user invokes the exit, you could simply use Smalltalk #run: instead of #runAndQuit:. There may be another case where you want to "build" an image and want it to save. There's one for that too.
I personally like the Smalltalk #run... API because it handles all the Notifications, Warnings, SyntaxErrors and Errors the way I like (by logging them to stdout and stderr) but you don't /have/ to use that if you don't want. You can always check "Smalltalk argumentAt: anInteger" to simply obtain the command-line arguments as Strings.
There are advanced cases where you may not want the first argument to be the name of a script. For those you can unset preference "readDocumentAtStartup".
On Tue, Sep 30, 2014 at 1:12 PM, tim Rowledge tim@rowledge.org wrote:
How are command line arguments intended for the image supposed to be dealt with these days? It’s an awfully long time since last I looked at this area and the code I’m seeing in the image is… convoluted.
I need to be able to handle some simple cases for Scratch startup and we seem to have completely changed how that area is handled. I have come across (and reeled in horror) code in ProjectLauncher, AutoStart etc but so far I don’t see anything to make it all make sense in my head. I don’t suppose anybody knows of a correct wiki page? Not found one so far.
Maybe I need to drop one or more of the current startup related classes and write a ScratchStart class?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Programmer: One who is too lacking in people skills to be a software engineer.
Tim> I need to be able to handle some simple cases for Scratch Tim> startup and we seem to have completely changed how that area is Tim> handled. I have come across (and reeled in horror) code in Tim> ProjectLauncher...
Chris> Don't "reel in horror" drama-boy.
Mmm, coffee... it's always too much (Tim) or not enough (Chris)! :)
-C
-- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
On 01-10-2014, at 4:27 AM, Craig Latta craig@netjam.org wrote:
Tim> I need to be able to handle some simple cases for Scratch Tim> startup and we seem to have completely changed how that area is Tim> handled. I have come across (and reeled in horror) code in Tim> ProjectLauncher...
Chris> Don't "reel in horror" drama-boy.
Mmm, coffee... it's always too much
Unpossible!
(Tim) or not enough (Chris)! :)
-C
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- He has a tenuous grip on the obvious.
On 30-09-2014, at 6:42 PM, Chris Muller asqueaker@gmail.com wrote:
Don't "reel in horror" drama-boy. Squeak's command-line processing is simple and effective. I use it heavily every day.
You might think it less ‘drama-boy’ if I remind you that I have to make this work for around 1.5 million regular users that don’t want to see an error notifier when they use a command line according to the older version. I’m inclined to think that some drama would be nice to avoid here…
I understand the process you explained and it’s a good way to do things. Nicer still if it were well documented of course - perhaps you could add your explanation to the swiki sometime? And probably as a class comment, come to that.
I guess I’ll need to turn off the readDocumentAtStartup pref and manually find any args. That’s really all I needed to know.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Microsoft Works
Don't "reel in horror" drama-boy. Squeak's command-line processing is simple and effective. I use it heavily every day.
You might think it less ‘drama-boy’ if I remind you that I have to make this work for around 1.5 million regular users that don’t want to see an error notifier when they use a command line according to the older version. I’m inclined to think that some drama would be nice to avoid here…
Yes, and in case the full bandwidth didn't come thru, please know that your comment amused me and I was simply playing on it. I hope you weren't offended.
I understand the process you explained and it’s a good way to do things. Nicer still if it were well documented of course - perhaps you could add your explanation to the swiki sometime? And probably as a class comment, come to that.
Okay, done.
http://wiki.squeak.org/squeak/6199
I guess I’ll need to turn off the readDocumentAtStartup pref and manually find any args. That’s really all I needed to know.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Microsoft Works
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Craig Latta -
David T. Lewis -
Nicolas Cellier -
tim Rowledge