[squeak-dev] Processing a file at image startup (scripting)

Hi,

While delivering a small app (a project scheduler), people asked me if
it's possible to execute it by a command line without opening an
image. I have a pseudo-dsl to define a project (collection of tasks)
that the app is scheduling and so, what I'd like is launching the app
by passing a file as parameter. Then squeak "open headless", process
the entry file, write an outputfile with results and eventually
errors, and exit.

I did something but this is a terrible hack :) I'd like to have other
idea on that. If we consider:

squeak   -headless test.image   file.in

According to the vm man, file.in must be a script (st file with bang
notation). I'm not aware of a way to pass a plain text file. So I just
hacked ProjectLauncher>>startUpAfterLogin  (this is where I get a dnu
if passing a file as parameter) so that my file can be processed and
the image closed afterwhile.

Can people point me a better way of doing that ? My feeling is I need
to create a ScriptClass that has a startUp method where file
processing can be implemented.

Thanks

--
Cédrick


ps: a related question would be which startUp classes are not
necessary if we only need to process a File (do we need InputSensor,
etc...)

Cédrick Béler wrote: You might like to try Installer-Launcher which is loaded with LPF

http://installer.pbwiki.com/LevelPlayingField

This allows you to pass a sequence of classes and parameters to the
command line

squeak my.image TestReporter suite=allTests SmalltalkImage
save="out.image" +quit

The parameters are handled by the class methods #launchWith: paramsDict

Keith

If you are shipping a "real" application (i.e., not some image that
people do further development in) it is probably advantageous to do the
command line handling yourself. This is extremely simple:

1) Execute "AutoStart deinstall" when you prepare your app to get
AutoStart and ProjectLauncher out of the way.

2) When your app starts, process command line args as you'd like, for
example:

processCommandLine
     "Process command line arguments for this application"
     | index attr arg forumToLoad robot |
     self isSealedApplication ifFalse:[^nil]. "only process command line
for sealed apps"
     index := 0.
     [attr := Smalltalk getSystemAttribute: (index := index + 1).
     attr isNil] whileFalse:[
       attr caseOf:{
          ['-enableDebug']  -> [
              self enableDebug: true.
          ].
          ['-debugLevel:']  -> [
              arg := (Smalltalk getSystemAttribute: (index := index +
1)) asNumber.
              self debugLevel: arg.
          ].
       } otherwise:[
          "Check if this is just a file that was associated with the app"
          (self isKnownFileType: attr)
             ifTrue:[self launchWithFile: attr].
       ].
     ].

Cheers,
   - Andreas

Cédrick Béler wrote:

Thanks for your answers :)

2009/5/20 Andreas Raab <[hidden email]>:
> If you are shipping a "real" application (i.e., not some image that people
> do further development in) it is probably advantageous to do the command
> line handling yourself.

Yes, this si sort of what I did.

> This is extremely simple:
>
> 1) Execute "AutoStart deinstall" when you prepare your app to get AutoStart
> and ProjectLauncher out of the way.

ok, cool thanks. I hadn't noticed that.

Does this kind of method goes in a class that has to be added to the
StartUpList ?

MyFinalizationClass>>startUp

     self processCommandLine



Another question I have in mind is if it's possible to have a minimum
classes at startUp (if useful). Right now, in the StartUpList var, I
have for StartUpList:

#(#Delay #DisplayScreen #Cursor #InputSensor #ProcessorScheduler
#LanguageEnvironment #FileDirectory #ShortIntegerArray #ShortRunArray
#CrLfFileStream
#PasteUpMorph #NaturalLanguageTranslator #ImageSegment #ThisOSProcess
#PowerManagement #ExternalSettings #SecurityManager
#FreeTypeFontProvider #AutoStart
#SspApplication #UUIDGenerator #ProcessBrowser #CPUWatcher
#DateAndTime #SmalltalkImage #HostSystemMenus #Utilities #MenuIcons
#WeakArray #MultiByteFileStream #InternetConfiguration #Locale
#CommandHistory #HostWindowProxy #FreeTypeSettings #UITheme
#WAServerManager #WAExternalID #SpEnvironment #ApplicationService
#ModDoc #SDCheckPointer nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil)

Is there somewhere a "minimal" list of needed classes to run an image
headless ? Maybe this is not important anyway but I'd like to have a
"minimum system" to be shipped.


Last, I'd like to know if there's a way to run headless without
specifiing the parameter   -headless.  Actually, I'd like a vm that
run headless by default. Do I need to build my own vm for that ? At
the moment, I just created a small script so that all parameters are
hidden inside.

Thanks,

Cédrick

Cédrick Béler wrote:
> 2009/5/20 Andreas Raab <[hidden email]>:
>> 2) When your app starts, process command line args as you'd like, for
>> example:
>>
>> processCommandLine
>>    "Process command line arguments for this application"
>
> Does this kind of method goes in a class that has to be added to the
> StartUpList ?

It depends on how you start your app. What we do for our images is that
we use a class method called #runAsApp that is implemented on the main
UI class. It looks roughly like here:

runAsApp
        "Run me as a standalone app, sealed without development information."
        WorldState addDeferredUIMessage:[
                World submorphs do:[:each| each delete].
                Preferences disable: #warnIfNoSourcesFile.
                Preferences disable: #warnIfNoChangesFile.
                (self confirm: 'Save the sealed image?') ifTrue:[
                        AutoStart deinstall. "no autostart please"
                        Smalltalk saveAs.
                ].
                self launchAppFrame.
        ].

#launchAppFrame then instantiates the actual UI which (indirectly) calls
processCommandLine.

> Last, I'd like to know if there's a way to run headless without
> specifiing the parameter   -headless.  Actually, I'd like a vm that
> run headless by default. Do I need to build my own vm for that ? At
> the moment, I just created a small script so that all parameters are
> hidden inside.

That's what we do as well.

Cheers,
   - Andreas