Instruments for headless images

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Instruments for headless images

Igor Stasenko
On 21 January 2011 21:15, Eliot Miranda <[hidden email]> wrote:

>
>
> 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.
>
that what i actually meant by 'log error, save & quit ' option
>>
>> Stef
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Instruments for headless images

Stéphane Ducasse
In reply to this post by Eliot Miranda-2
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 <[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
>


Reply | Threaded
Open this post in threaded view
|

Re: Instruments for headless images

Eliot Miranda-2


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



Reply | Threaded
Open this post in threaded view
|

Re: Instruments for headless images

David T. Lewis
In reply to this post by Igor Stasenko
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
 

Reply | Threaded
Open this post in threaded view
|

Fwd: [squeak-dev] Instruments for headless images

Stéphane Ducasse
In reply to this post by Chris Muller-3


Begin forwarded message:

> From: Chris Muller <[hidden email]>
> Date: January 20, 2011 10:05:44 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Cc: Pharo Development <[hidden email]>
> Subject: Re: [Pharo-project] [squeak-dev] Instruments for headless images
> Reply-To: [hidden email], [hidden email]
>
> 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:
>> 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.
>>
>>

>


SmalltalkImage-maIsHeadless.st.gz (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Instruments for headless images

Stéphane Ducasse
In reply to this post by Eliot Miranda-2
tx

On Jan 21, 2011, at 11:19 PM, Eliot Miranda wrote:

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


12