[squeak-dev] The Inbox: System-dtl.1164.mcz

David T. Lewis lewis at mail.msen.com
Thu Jun 11 00:52:57 UTC 2020

On Wed, Jun 10, 2020 at 05:07:53PM -0700, Eliot Miranda wrote:
> > On Jun 9, 2020, at 8:44 PM, Chris Muller <asqueaker at gmail.com> wrote:
> > 
> > ???
> >> > On 2020-06-09, at 11:52 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> >> > 
> >> > Funny you should mention it, that's how I went down this rabbit hole
> >> > in the first place. I was thinking that it would be an obviously good
> >> > thing to do if we could evaluate a doIt or named script file immediately
> >> > on image startup, as opposed to waiting until all of the Etoys script
> >> > processing comes to life somewhere later in the startUp process.
> >> 
> >> Exactly. Note that VW has several commandline switches we might want to learn from
> >> 
> >> -filein {some file names}
> >> -doit {some strings}
> >> -evaluate {a single string & write result to stdout & quit
> >> -cli {start a commandline loop}
> > 
> > What I most like about Dave's change is the improved separation of concerns:  it allows the OS to invoke an image with the proper startup script and/or arguments WITHOUT relying on Preferences readDocumentAtStartup being set correctly.  I can see -filein being useful for a production patch use-case, but the rest of those go back to mixing the Smalltalk environment in with the operating-system environment.  For safe and scalable headless interaction, you would just use a server.  I never knew if there was an actual use-case for -evaluate and -cli other than novelty.  Is there?
> Both are useful for testing. ???evaluate is useful in eg a (unix software build style) configure context.  ???cli is useful for people who want to explore, learn, demo, etc.  
> But since they don???t really cost much why are you bothering to try and veto them?

I didn't read Chris' question as a veto, just a bit of possibly justified
skepticism. But all four of these proposed options should be quite easy to
implement, so there's no reason not to try them :-)


More information about the Squeak-dev mailing list