On 30 December 2013 21:33, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Dec 30, 2013 at 09:04:05PM +0100, Levente Uzonyi wrote:
On Mon, 30 Dec 2013, Frank Shearar wrote:
On 30 December 2013 19:14, Levente Uzonyi leves@elte.hu wrote:
On Mon, 30 Dec 2013, Frank Shearar wrote:
On 30 December 2013 18:36, commits@source.squeak.org wrote:
A new version of CommandLine was added to project The Inbox: http://source.squeak.org/inbox/CommandLine-fbs.3.mcz
==================== Summary ====================
Name: CommandLine-fbs.3 Author: fbs Time: 30 December 2013, 6:36:22.399 pm UUID: a8ce5a55-8bb5-ac4b-a112-eb308ce3bf53 Ancestors: CommandLine-fbs.2
If launched headless (with option -headless or -vm-display-null), use the CommandLineToolSet instead of the StandardToolSet.
We must startUp: before AutoStart because AutoStart triggers the processing of startup scripts (because it asks all registered AbstractLaunchers - in particular, ProjectLauncher - to do their thing).
=============== Diff against CommandLine-fbs.2 ===============
This allows headless things to report bad things happening, like dumping syntax error notifications to stdout and exiting.
People who use RFB won't like this, because it quits the image on the first error.
Does RFB get used in a _headless_ manner? An alternative would be to
It depends. RFB can be used with -vm-display-null, or one can use xpra and use -vm-display-x11. We start our images with xpra, but still connect to them using RFB, because it's more responsive. xpra is still useful, because it's not safe to press alt+. through RFB, because you can interrupt the RFB process itself.
Our squeaksource.com image works this way. We run it as a headless image with -vm-display-null, and the image has RFBServer to support interactive access. It works very well, and I believe that this is a common configuration for Seaside application servers.
OK, so I misunderstood what "headless" meant. I thought it meant "doesn't use a GUI", but it really means "doesn't render a GUI to a physical device".
In that case, the commit's useless. I'll have to take a look at what the Pharo guys have done, and see how I can make that work.
What I need is to be able to treat the execution of an image as a strictly command-line process. I need to, without doing anything inside a startup script, to be able to signal to the image that it must use the CommandLineToolSet. The CLTS and DummyUIManager will then ensure that external interactions with the user happen only over stdout, stderr and std in.
Using SmalltalkImage >> #run: doesn't do what I need, because syntax errors are thrown outside the block, when the startup script is parsed. Although it might do the trick if we rewrote the way startup scripts are run. There's a bunch of wrongness in CodeLoader already (like parsing relative file paths relative to the image's location, rather than the current working directory).
Either way, it's much more work than I can stomach for the moment. I'll shelve this commit.
frank
Dave