Smalltalk › Pharo › Pharo Smalltalk Developers

Instruments for headless images

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Igor Stasenko

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.

Stéphane Ducasse

Re: [squeak-dev] Instruments for headless images

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

Chris Muller-3

Re: [squeak-dev] Instruments for headless images

In reply to this post by Igor Stasenko

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 <[hidden email]> wrote:

SmalltalkImage-maIsHeadless.st.gz (488 bytes) Download Attachment

Igor Stasenko

Re: [squeak-dev] Instruments for headless images

In reply to this post by Stéphane Ducasse

On 20 January 2011 21:49, Stéphane Ducasse <[hidden email]> 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.

Igor Stasenko

Re: [squeak-dev] Instruments for headless images

In reply to this post by Chris Muller-3

On 20 January 2011 22:05, Chris Muller <[hidden email]> 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 <[hidden email]> 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.

Chris Muller-3

Re: [squeak-dev] Instruments for headless images

> 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

Chris Muller-3

Re: [squeak-dev] Instruments for headless images

In reply to this post by Igor Stasenko

> 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."

Sven Van Caekenberghe

Re: Instruments for headless images

In reply to this post by Igor Stasenko

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:

Igor Stasenko

Re: Instruments for headless images

On 21 January 2011 11:04, Sven Van Caekenberghe <[hidden email]> 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.

Sven Van Caekenberghe

Re: Instruments for headless images

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

Igor Stasenko

Re: Instruments for headless images

On 21 January 2011 11:28, Sven Van Caekenberghe <[hidden email]> 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.

Eliot Miranda-2

Re: Instruments for headless images

On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <[hidden email]> wrote:

On 21 January 2011 11:28, Sven Van Caekenberghe <[hidden email]> 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.

Igor Stasenko

Re: Instruments for headless images

On 21 January 2011 19:06, Eliot Miranda <[hidden email]> wrote:

>
>
> On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 21 January 2011 11:28, Sven Van Caekenberghe <[hidden email]> 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.

Eliot Miranda-2

Re: Instruments for headless images

On Fri, Jan 21, 2011 at 10:19 AM, Igor Stasenko <[hidden email]> wrote:

On 21 January 2011 19:06, Eliot Miranda <[hidden email]> wrote:
>
>
> On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 21 January 2011 11:28, Sven Van Caekenberghe <[hidden email]> 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.

Chris Muller-3

Re: Instruments for headless images

In reply to this post by Igor Stasenko

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

Igor Stasenko

Re: [squeak-dev] Re: Instruments for headless images

On 21 January 2011 20:19, Chris Muller <[hidden email]> 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.

Igor Stasenko

Re: Instruments for headless images

In reply to this post by Eliot Miranda-2

On 21 January 2011 19:53, Eliot Miranda <[hidden email]> wrote:

>
>
> On Fri, Jan 21, 2011 at 10:19 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 21 January 2011 19:06, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> > On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <[hidden email]>
>> > wrote:
>> >>
>> >> On 21 January 2011 11:28, Sven Van Caekenberghe <[hidden email]> 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.

Stéphane Ducasse

Re: Instruments for headless images

In reply to this post by Eliot Miranda-2

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

Stéphane Ducasse

Re: Instruments for headless images

In reply to this post by Sven Van Caekenberghe

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

Eliot Miranda-2

Re: Instruments for headless images

In reply to this post by Stéphane Ducasse

On Fri, Jan 21, 2011 at 11:44 AM, Stéphane Ducasse <[hidden email]> 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