startup time command line (or dropped files) arguments

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; [hidden email]; 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:
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 <[hidden email]> 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.

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; [hidden email]; 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!

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 <[hidden email]> wrote:

On Tue, Sep 30, 2014 at 03:56:13PM -0700, tim Rowledge wrote:
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

  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 <[hidden email]> 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; [hidden email]; 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 <[hidden email]> 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; [hidden email]; 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