[squeak-dev] startup time command line (or dropped files) arguments

David T. Lewis lewis at mail.msen.com
Wed Oct 1 01:49:10 UTC 2014


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 at 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



More information about the Squeak-dev mailing list