[Pharo-project] Instruments for headless images
Hello folks. I'd like to ask, if there any 'standartized' instruments for headless images (or alike). I need a simple things: - redirect all ToolSet/UIManager messages to Transcript - redirect Transcript logging to file or stdout in short, these tools should serve a simple, yet important purpose: - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message. Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story. I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet and - WriteStream subclass: #HydraTranscript which can be installed as a Transcript. And in order to prepare image to run in headless mode, i issued: ToolSet unregister: StandardToolSet. ToolSet register: HydraDebugToolSet. UIManager default: HydraUIManager new. Also, HydraTranscript startUp does something like: TranscriptStream newTranscript: (self basicNew initialize on: (String new: 1000)) With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images. I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode? -- Best regards, Igor Stasenko AKA sig.
there is a DummyManager to control pop up and friends. Stef On Jan 20, 2011, at 9:39 PM, Igor Stasenko wrote:
Hello folks.
I'd like to ask, if there any 'standartized' instruments for headless images (or alike).
I need a simple things: - redirect all ToolSet/UIManager messages to Transcript - redirect Transcript logging to file or stdout
in short, these tools should serve a simple, yet important purpose: - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message.
Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story.
I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet
and - WriteStream subclass: #HydraTranscript
which can be installed as a Transcript.
And in order to prepare image to run in headless mode, i issued: ToolSet unregister: StandardToolSet. ToolSet register: HydraDebugToolSet. UIManager default: HydraUIManager new.
Also, HydraTranscript startUp does something like:
TranscriptStream newTranscript: (self basicNew initialize on: (String new: 1000))
With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images.
I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode?
-- Best regards, Igor Stasenko AKA sig.
On 20 January 2011 21:49, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
there is a DummyManager to control pop up and friends.
where it located?
Stef
On Jan 20, 2011, at 9:39 PM, Igor Stasenko wrote:
Hello folks.
I'd like to ask, if there any 'standartized' instruments for headless images (or alike).
I need a simple things: - redirect all  ToolSet/UIManager messages to Transcript - redirect Transcript logging to file or stdout
in short, these tools should serve a simple, yet important purpose: - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message.
Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story.
I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet
and - WriteStream subclass: #HydraTranscript
which can be installed as a Transcript.
And in order to prepare image to run in headless mode, i issued: Â Â Â ToolSet unregister: StandardToolSet. Â Â Â ToolSet register: HydraDebugToolSet. Â Â Â UIManager default: HydraUIManager new.
Also, HydraTranscript startUp does something like:
   TranscriptStream        newTranscript: (self basicNew initialize                on: (String new: 1000))
With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images.
I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode?
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
The Ma stack does something similar, although not crippling the system to the same extent. How do you determine you're running headless? I attached my implementation of #maIsHeadless for determining whether the VM was launched headless. Perhaps we should integrate this functionality into Squeak and Pharo (or a variant without the prefix, of course). Then, I use MaCommandLineProcessor which is concerned with handling the command-line Squeak was launched with: Then, I write my .st scripts like: MaCommandLineProcessor do: [ : arg1 : arg2 : arg3 : etc | "my batch code script..." "args come in as Strings." "... you can have a variable number of args." ] as well as a uniform error-handler for all scripts, to redirect to stdout and stderr, thusly: MaCommandLineProcessor class>>#do: aBlock | stdOut stdErr | self ensureStartedUp. stdOut := StandardFileStream stdout. stdErr := StandardFileStream stderr. [ aBlock valueWithAllArguments: self args ] on: Notification , Warning do: [ : noti | stdOut nextPutAll: DateAndTime now asString ; space ; nextPutAll: noti description ; perform: MultiByteFileStream lineEndDefault. noti resume ] on: SyntaxErrorNotification do: [ : err | stdOut nextPutAll: err errorCode ; perform: MultiByteFileStream lineEndDefault. self haltOrQuit ] on: Error do: [ : err | stdErr nextPutAll: 'ERROR: ' ; nextPutAll: DateAndTime now asString ; space ; perform: MultiByteFileStream lineEndDefault ; nextPutAll: err description ; perform: MultiByteFileStream lineEndDefault. err isMaUserError ifFalse: [ stdErr nextPutAll: (err signalerContext longStack copyReplaceAll: Character cr asString with: (String perform: MultiByteFileStream lineEndDefault)) ]. self haltOrQuit ] #haltOrQuit is where it checks #maIsHeadless to determine whether to halt or quit. MaCommandLineProcessor is part of "Ma base additions" package, so any of the "Ma" softwares (Magma, Maui, Ma client server, etc.) will have it. But I think it would be useful to put this (or, a variant) directly into a future Squeak. - Chris On Thu, Jan 20, 2011 at 2:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello folks.
I'd like to ask, if there any 'standartized' instruments for headless images (or alike).
I need a simple things:  - redirect all  ToolSet/UIManager messages to Transcript  - redirect Transcript logging to file or stdout
in short, these tools should serve a simple, yet important purpose: Â - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message.
Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story.
I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet
and - WriteStream subclass: #HydraTranscript
which can be installed as a Transcript.
And in order to prepare image to run in headless mode, i issued: Â Â Â Â ToolSet unregister: StandardToolSet. Â Â Â Â ToolSet register: HydraDebugToolSet. Â Â Â Â UIManager default: HydraUIManager new.
Also, HydraTranscript startUp does something like:
    TranscriptStream         newTranscript: (self basicNew initialize                 on: (String new: 1000))
With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images.
I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode?
-- Best regards, Igor Stasenko AKA sig.
On 20 January 2011 22:05, Chris Muller <asqueaker@gmail.com> wrote:
The Ma stack does something similar, although not crippling the system to the same extent.
well, if by 'crippling' you mean preventing any unwanted activity when headless.. then yes, i want it :)
How do you determine you're running headless? Â I attached my implementation of #maIsHeadless for determining whether the VM was launched headless. Â Perhaps we should integrate this functionality into Squeak and Pharo (or a variant without the prefix, of course).
okay, as i suspected there is no direct way to determine that.. i don't like checking the command-line args, because obviously i can build vm which completely ignores that. but since there is no other options...
Then, I use MaCommandLineProcessor which is concerned with handling the command-line Squeak was launched with:
Then, I write my .st scripts like:
[snip] ohh.. well, but that is too much for a simple script. it would be good if image could provide something by default, because i don't want to repeat expressions like this in each script i write for running it in headless image. :)
 - Chris
On Thu, Jan 20, 2011 at 2:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello folks.
I'd like to ask, if there any 'standartized' instruments for headless images (or alike).
I need a simple things:  - redirect all  ToolSet/UIManager messages to Transcript  - redirect Transcript logging to file or stdout
in short, these tools should serve a simple, yet important purpose: Â - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message.
Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story.
I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet
and - WriteStream subclass: #HydraTranscript
which can be installed as a Transcript.
And in order to prepare image to run in headless mode, i issued: Â Â Â Â ToolSet unregister: StandardToolSet. Â Â Â Â ToolSet register: HydraDebugToolSet. Â Â Â Â UIManager default: HydraUIManager new.
Also, HydraTranscript startUp does something like:
    TranscriptStream         newTranscript: (self basicNew initialize                 on: (String new: 1000))
With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images.
I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode?
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
ohh.. well, but that is too much for a simple script. it would be good if image could provide something by default, because i don't want to repeat expressions like this in each script i write for running it in headless image. :)
Hm, you may have missed that the point of that was to _avoid_ repeating those expressions. That way, this is all your .st script has to be: CommandLineProcessor do: [ : arg1 : arg2 | "... your simple script goes here..." ] So that's not so much is it? All of the error-handling to stdout is tucked away in the image, as is the parsing of the command-line arguments. - Chris
well, if by 'crippling' you mean preventing any unwanted activity when headless.. then yes, i want it :)
Forgot to say, that's what I meant too. :) I should have said, "although not enhancing system performance to the same extent."
Begin forwarded message:
From: Chris Muller <asqueaker@gmail.com> Date: January 20, 2011 10:05:44 PM GMT+01:00 To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org> Cc: Pharo Development <Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] [squeak-dev] Instruments for headless images Reply-To: Pharo-project@lists.gforge.inria.fr, ma.chris.m@gmail.com
The Ma stack does something similar, although not crippling the system to the same extent.
How do you determine you're running headless? I attached my implementation of #maIsHeadless for determining whether the VM was launched headless. Perhaps we should integrate this functionality into Squeak and Pharo (or a variant without the prefix, of course).
Then, I use MaCommandLineProcessor which is concerned with handling the command-line Squeak was launched with:
Then, I write my .st scripts like:
MaCommandLineProcessor do: [ : arg1 : arg2 : arg3 : etc | "my batch code script..." "args come in as Strings." "... you can have a variable number of args." ]
as well as a uniform error-handler for all scripts, to redirect to stdout and stderr, thusly:
MaCommandLineProcessor class>>#do: aBlock | stdOut stdErr | self ensureStartedUp. stdOut := StandardFileStream stdout. stdErr := StandardFileStream stderr. [ aBlock valueWithAllArguments: self args ] on: Notification , Warning do: [ : noti | stdOut nextPutAll: DateAndTime now asString ; space ; nextPutAll: noti description ; perform: MultiByteFileStream lineEndDefault. noti resume ] on: SyntaxErrorNotification do: [ : err | stdOut nextPutAll: err errorCode ; perform: MultiByteFileStream lineEndDefault. self haltOrQuit ] on: Error do: [ : err | stdErr nextPutAll: 'ERROR: ' ; nextPutAll: DateAndTime now asString ; space ; perform: MultiByteFileStream lineEndDefault ; nextPutAll: err description ; perform: MultiByteFileStream lineEndDefault. err isMaUserError ifFalse: [ stdErr nextPutAll: (err signalerContext longStack copyReplaceAll: Character cr asString with: (String perform: MultiByteFileStream lineEndDefault)) ]. self haltOrQuit ]
#haltOrQuit is where it checks #maIsHeadless to determine whether to halt or quit.
MaCommandLineProcessor is part of "Ma base additions" package, so any of the "Ma" softwares (Magma, Maui, Ma client server, etc.) will have it. But I think it would be useful to put this (or, a variant) directly into a future Squeak.
- Chris
On Thu, Jan 20, 2011 at 2:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello folks.
I'd like to ask, if there any 'standartized' instruments for headless images (or alike).
I need a simple things: - redirect all ToolSet/UIManager messages to Transcript - redirect Transcript logging to file or stdout
in short, these tools should serve a simple, yet important purpose: - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message.
Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story.
I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet
and - WriteStream subclass: #HydraTranscript
which can be installed as a Transcript.
And in order to prepare image to run in headless mode, i issued: ToolSet unregister: StandardToolSet. ToolSet register: HydraDebugToolSet. UIManager default: HydraUIManager new.
Also, HydraTranscript startUp does something like:
TranscriptStream newTranscript: (self basicNew initialize on: (String new: 1000))
With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images.
I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode?
-- Best regards, Igor Stasenko AKA sig.
Igor, Headless support is an important feature. It should be something simple so that it can be used in many ways. I would suggest to read chapter 20 of the VW Application Developers Guide (it is only 10 pages). They basically have the option to toggle between headless and headfull. This is not detected automatically, but a global switch (with a test method). In headless mode all display access results in an error. In headless mode all Transcript output (can/is) also sent to a file (stdout would be another option). What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger). Saving a headless image headfull can also be done programmatically. I don't think more than that is needed. There are many options to interact with headless images, forcing one on people would not be good, the same goes for command line parsing, preferences, startup files, ... These other options could become separate projects. I would be an interested user and if I can will try to help. Regards, Sven On 20 Jan 2011, at 21:39, Igor Stasenko wrote:
Hello folks.
I'd like to ask, if there any 'standartized' instruments for headless images (or alike).
I need a simple things: - redirect all ToolSet/UIManager messages to Transcript - redirect Transcript logging to file or stdout
in short, these tools should serve a simple, yet important purpose: - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message.
Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story.
I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet
and - WriteStream subclass: #HydraTranscript
which can be installed as a Transcript.
And in order to prepare image to run in headless mode, i issued: ToolSet unregister: StandardToolSet. ToolSet register: HydraDebugToolSet. UIManager default: HydraUIManager new.
Also, HydraTranscript startUp does something like:
TranscriptStream newTranscript: (self basicNew initialize on: (String new: 1000))
With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images.
I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode?
-- Best regards, Igor Stasenko AKA sig.
On 21 January 2011 11:04, Sven Van Caekenberghe <sven@beta9.be> wrote:
Igor,
Headless support is an important feature. It should be something simple so that it can be used in many ways. I would suggest to read chapter 20 of the VW Application Developers Guide (it is only 10 pages).
They basically have the option to toggle between headless and headfull. This is not detected automatically, but a global switch (with a test method).
In headless mode all display access results in an error.
yes.
In headless mode all Transcript output (can/is) also sent to a file (stdout would be another option).
yes
What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Saving a headless image headfull can also be done programmatically.
I don't think more than that is needed. There are many options to interact with headless images, forcing one on people would not be good, the same goes for command line parsing, preferences, startup files, ... These other options could become separate projects.
well, again, when people running image(s) in headless mode, they are know what they doing, and i think their default expectation is that image(s) should be aware that it runs headless and do not try to invoke anything which requires user interaction (like yes/no dialog) , because this does not makes any sense.
I would be an interested user and if I can will try to help.
Regards,
Sven
-- Best regards, Igor Stasenko AKA sig.
On 21 Jan 2011, at 11:19, Igor Stasenko wrote:
What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great. Sven
On 21 January 2011 11:28, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 21 Jan 2011, at 11:19, Igor Stasenko wrote:
What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great.
this is next step.. I think this could be set by preference system on error: - print error to log and quit - print error to log and do save & quit - print error to log and do save new version & quit In future , by adding support from VM side we could also have: - switch to interactive(headfull) mode, by creating an OS window opening debugger , showing dialog(s) etc etc
Sven
-- Best regards, Igor Stasenko AKA sig.
On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 January 2011 11:28, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 21 Jan 2011, at 11:19, Igor Stasenko wrote:
What is interesting (and we might make that an option) is that the 'no
display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great.
this is next step..
I think this could be set by preference system on error: - print error to log and quit - print error to log and do save & quit - print error to log and do save new version & quit
In future , by adding support from VM side we could also have: - switch to interactive(headfull) mode, by creating an OS window opening debugger , showing dialog(s) etc etc
The VW headful/headless switch requires _no_ additional VM support at all. All one needs is stdio support (which we have) and everything else can be done in Smalltalk.
Sven
-- Best regards, Igor Stasenko AKA sig.
On 21 January 2011 19:06, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 January 2011 11:28, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 21 Jan 2011, at 11:19, Igor Stasenko wrote:
What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great.
this is next step..
I think this could be set by preference system on error:  - print error to log and quit  - print error to log and do save & quit  - print error to log and do save new version & quit
In future , by adding support from VM side we could also have: Â - switch to interactive(headfull) mode, by creating an OS window opening debugger , showing dialog(s) etc etc
The VW headful/headless switch requires _no_ additional VM support at all. Â All one needs is stdio support (which we have) and everything else can be done in Smalltalk.
err.. no additional support? you mean it already in there? - how to tell VM to close everything at runtime and become headless - how to tell VM to create a new window(s) and turn from headless to headful mode? there should be something from VM side, otherwise how else? unless, of course, image are in total control of host window creation/deletion, then of course it could decide what to do by own.
Sven
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Fri, Jan 21, 2011 at 10:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 January 2011 19:06, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 21 January 2011 11:28, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 21 Jan 2011, at 11:19, Igor Stasenko wrote:
What is interesting (and we might make that an option) is that the
'no
display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great.
this is next step..
I think this could be set by preference system on error: - print error to log and quit - print error to log and do save & quit - print error to log and do save new version & quit
In future , by adding support from VM side we could also have: - switch to interactive(headfull) mode, by creating an OS window opening debugger , showing dialog(s) etc etc
The VW headful/headless switch requires _no_ additional VM support at all. All one needs is stdio support (which we have) and everything else can be done in Smalltalk.
err.. no additional support? you mean it already in there? - how to tell VM to close everything at runtime and become headless
There's an openDisplay primitive that is used ever time the system comes up headless. IFAIA one never goes directly headless from a headful state. Instead one saves headless and resumes the snapshot headless. "Saving headless" means doing a snapshot that sets a variable such that when the saved image resumes it doesn't do an openDisplay. What one does do is dynamically become headful, and to do that one just uses the openDisplay primitive. (FYI openDisplay is primitive #960). - how to tell VM to create a new window(s) and turn from headless to
headful mode?
Use openDisplay.
there should be something from VM side, otherwise how else? unless, of course, image are in total control of host window creation/deletion, then of course it could decide what to do by own.
Sven
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 21 January 2011 19:53, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Jan 21, 2011 at 10:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 January 2011 19:06, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 January 2011 11:28, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 21 Jan 2011, at 11:19, Igor Stasenko wrote:
What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great.
this is next step..
I think this could be set by preference system on error:  - print error to log and quit  - print error to log and do save & quit  - print error to log and do save new version & quit
In future , by adding support from VM side we could also have: Â - switch to interactive(headfull) mode, by creating an OS window opening debugger , showing dialog(s) etc etc
The VW headful/headless switch requires _no_ additional VM support at all. Â All one needs is stdio support (which we have) and everything else can be done in Smalltalk.
err.. no additional support? you mean it already in there? - how to tell VM to close everything at runtime and become headless
There's an openDisplay primitive that is used ever time the system comes up headless. Â IFAIA one never goes directly headless from a headful state. Â Instead one saves headless and resumes the snapshot headless. "Saving headless" means doing a snapshot that sets a variable such that when the saved image resumes it doesn't do an openDisplay. What one does do is dynamically become headful, and to do that one just uses the openDisplay primitive. Â (FYI openDisplay is primitive #960).
- how to tell VM to create a new window(s) and turn from headless to headful mode?
Use openDisplay.
that what i meant by saying 'VM support' SqueakVMs don't have such primitive. But maybe we don't need it, because i think it would be much better to give image a full control upon creation/closing of host windows. So, image could decide by own what to do (and then you even don't need to a special handling in VM for headless mode, since it will be a decision which image does, not VM). -- Best regards, Igor Stasenko AKA sig.
On Fri, Jan 21, 2011 at 08:44:23PM +0100, Igor Stasenko wrote:
that what i meant by saying 'VM support' SqueakVMs don't have such primitive. But maybe we don't need it, because i think it would be much better to give image a full control upon creation/closing of host windows. So, image could decide by own what to do (and then you even don't need to a special handling in VM for headless mode, since it will be a decision which image does, not VM).
Maybe slightly off topic, but with an interpreter VM on X11 you can do this: OSProcess thisOSProcess processAccessor primKillDisplay. (Delay forSeconds: 5) wait. OSProcess thisOSProcess processAccessor primOpenXDisplay In other words, close the display under control of the image, and open it again under control of the image. You can also reopen the display on any X11 server willing to accept the connection (i.e. close the display on your current machine and reopen it somewhere else). VM support is in XDisplayControlPlugin (on SqueakSource). It should be possible to make it work with Cog also. The equivalent functionality for Windows and non-X11 Mac would work quite differently, so putting it in a plugin is a good approach. I agree with Eliot's recommendation that the display should be opened by the image after the image is started, rather than opened by the VM before the image is started. IIRC this has been discussed in the past but has not been implemented. Dave
Eliot does it mean that we could run headless and that if specified on the command line we could for example get a debugger open on bugs? Because I would love that for coral. Stef
On Fri, Jan 21, 2011 at 11:44 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Eliot
does it mean that we could run headless and that if specified on the command line we could for example get a debugger open on bugs? Because I would love that for coral.
Exactly. In fact I think one mode is that one can get the system to snapshot when the error happens, one can then send the snapshot to a developer, and the snapshot comes up headful with the debugger.
Stef
On 21 January 2011 21:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Jan 21, 2011 at 11:44 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Eliot
does it mean that we could run headless and that if specified on the command line we could for example get a debugger open on bugs? Because I would love that for coral.
Exactly. Â In fact I think one mode is that one can get the system to snapshot when the error happens, one can then send the snapshot to a developer, and the snapshot comes up headful with the debugger.
that what i actually meant by 'log error, save & quit ' option
Stef
-- Best regards, Igor Stasenko AKA sig.
Eliot it is possible with the current vms? Stef On Jan 21, 2011, at 9:15 PM, Eliot Miranda wrote:
On Fri, Jan 21, 2011 at 11:44 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Eliot
does it mean that we could run headless and that if specified on the command line we could for example get a debugger open on bugs? Because I would love that for coral.
Exactly. In fact I think one mode is that one can get the system to snapshot when the error happens, one can then send the snapshot to a developer, and the snapshot comes up headful with the debugger.
Stef
On Fri, Jan 21, 2011 at 1:35 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Eliot
it is possible with the current vms?
I think not, but I think its really really close. Basically instead of the VM responding to -headless you'd have the image respond to -headless and arrange that all the code that starts-up the GUI window is called from a new primitive, say, openDisplay. Right now (I think) the VM decides whether to open up the main display or not, and does so by looking for a -headless argument, and if not found, opening the GUI window which remains blank. Ask Igor to trace through the startup code on each platform, looking for "headless" in the source and I'm sure he'll find it. best Eliot
Stef On Jan 21, 2011, at 9:15 PM, Eliot Miranda wrote:
On Fri, Jan 21, 2011 at 11:44 AM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
Eliot
does it mean that we could run headless and that if specified on the command line we could for example get a debugger open on bugs? Because I would love that for coral.
Exactly. In fact I think one mode is that one can get the system to snapshot when the error happens, one can then send the snapshot to a developer, and the snapshot comes up headful with the debugger.
Stef
tx On Jan 21, 2011, at 11:19 PM, Eliot Miranda wrote:
On Fri, Jan 21, 2011 at 1:35 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Eliot
it is possible with the current vms?
I think not, but I think its really really close. Basically instead of the VM responding to -headless you'd have the image respond to -headless and arrange that all the code that starts-up the GUI window is called from a new primitive, say, openDisplay. Right now (I think) the VM decides whether to open up the main display or not, and does so by looking for a -headless argument, and if not found, opening the GUI window which remains blank. Ask Igor to trace through the startup code on each platform, looking for "headless" in the source and I'm sure he'll find it.
best Eliot
Stef On Jan 21, 2011, at 9:15 PM, Eliot Miranda wrote:
On Fri, Jan 21, 2011 at 11:44 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Eliot
does it mean that we could run headless and that if specified on the command line we could for example get a debugger open on bugs? Because I would love that for coral.
Exactly. In fact I think one mode is that one can get the system to snapshot when the error happens, one can then send the snapshot to a developer, and the snapshot comes up headful with the debugger.
Stef
Considerations about improving headless support need to not only be about what to do with error output. When "running headless," the user is taking on a different kind of interaction with the system; it is now an industrial interface instead of the GUI, but it *is* a user-interface nonetheless. Therefore interacting with the system this way should address *input* as well as output. The input in the industrial environment consists of the name of a Smalltalk script + command-line arguments to that script.
this is next step..
I think this could be set by preference system on error:  - print error to log and quit  - print error to log and do save & quit  - print error to log and do save new version & quit
It's important to allow the same image to be used by multiple scripts, some of which might want to exit without saving, some which want to save under a new name. "How-to-quit" should be specific to each input script, not a global preference in the image. Regards, Chris
On 21 January 2011 20:19, Chris Muller <asqueaker@gmail.com> wrote:
Considerations about improving headless support need to not only be about what to do with error output. Â When "running headless," the user is taking on a different kind of interaction with the system; it is now an industrial interface instead of the GUI, but it *is* a user-interface nonetheless. Â Therefore interacting with the system this way should address *input* as well as output.
The input in the industrial environment consists of the name of a Smalltalk script + command-line arguments to that script.
this is next step..
I think this could be set by preference system on error:  - print error to log and quit  - print error to log and do save & quit  - print error to log and do save new version & quit
It's important to allow the same image to be used by multiple scripts, some of which might want to exit without saving, some which want to save under a new name. Â "How-to-quit" should be specific to each input script, not a global preference in the image.
Yes, but i'm not talking about scripts which are crafted specifically to run for headless images and aware about various nuances. I am talking about scripts which are quickly coded without any precautions, because most of users can't make difference between running headless and headful and where all problems can arise from.. So for such scripts image should behave adequately and not hang in undetermined state waiting an input from potential user. It should use these settings as default ones. I just wanna make life a bit easier for people :)
Regards, Â Chris
-- Best regards, Igor Stasenko AKA sig.
+1
What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger).
That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui.
Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great.
Sven
participants (6)
-
Chris Muller -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe