Filein mechanics

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

Filein mechanics

Jeff Gonis-2

Hi everyone,

I am currently working on getting the Squeak Jenkins server to perform benchmarking and so far everything is going great except for one thing. When I try to filein code implementing some benchmarks into a headless VM, it just hangs. If I filein the same file to a non-headless VM everything works just fine.

Seeing as how things only blow up when I am running headless, debugging is made somewhat more complicated.

I was wondering if anyone had some advice on getting better debug information from a headless VM, besides explicit log statements? I was also wondering if this sort of problem is ringing any bells for anyone on the list. I don't really have a good grip on how filein works either, so any pointers would be greatly appreciated. Would filein be attempting to send ui messages that are failing? I didn't see any user input requests when I filed into a normal VM, so I don't think it is waiting on a response. Any help is appreciated.

Thanks for your time,
Jeff



Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

Herbert König
Hi Jeff,

if you still count this as headless (I do) load RFB into that image and use TightVNC or similar for the UI.
I do this on my text only Linux machine.

Cheers

Herbert

Hi everyone,

I am currently working on getting the Squeak Jenkins server to perform benchmarking and so far everything is going great except for one thing. When I try to filein code implementing some benchmarks into a headless VM, it just hangs. If I filein the same file to a non-headless VM everything works just fine.

Seeing as how things only blow up when I am running headless, debugging is made somewhat more complicated.

I was wondering if anyone had some advice on getting better debug information from a headless VM, besides explicit log statements? I was also wondering if this sort of problem is ringing any bells for anyone on the list. I don't really have a good grip on how filein works either, so any pointers would be greatly appreciated. Would filein be attempting to send ui messages that are failing? I didn't see any user input requests when I filed into a normal VM, so I don't think it is waiting on a response. Any help is appreciated.

Thanks for your time,
Jeff




    



Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

Jeff Gonis-2
As a follow up question for people who have experience working with headless images, would I need to set the "user name" in the image before I file in code? I know that when I make a change in a fresh image that isn't headless it asks me for my initials, is it possible that the filein code is waiting on user input for the initials?


On Thu, Feb 7, 2013 at 10:30 AM, Herbert König <[hidden email]> wrote:
Hi Jeff,

if you still count this as headless (I do) load RFB into that image and use TightVNC or similar for the UI.
I do this on my text only Linux machine.

Cheers

Herbert

Hi everyone,

I am currently working on getting the Squeak Jenkins server to perform benchmarking and so far everything is going great except for one thing. When I try to filein code implementing some benchmarks into a headless VM, it just hangs. If I filein the same file to a non-headless VM everything works just fine.

Seeing as how things only blow up when I am running headless, debugging is made somewhat more complicated.

I was wondering if anyone had some advice on getting better debug information from a headless VM, besides explicit log statements? I was also wondering if this sort of problem is ringing any bells for anyone on the list. I don't really have a good grip on how filein works either, so any pointers would be greatly appreciated. Would filein be attempting to send ui messages that are failing? I didn't see any user input requests when I filed into a normal VM, so I don't think it is waiting on a response. Any help is appreciated.

Thanks for your time,
Jeff




    







Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

Bob Arning-2
In reply to this post by Jeff Gonis-2
If you can't see what's going on inside the headless image, getting some sort of picture would be a start. Try doing this in the image and save it:

[
    [
        f _ FileDirectory default fileNamed: 'allMyProcesses'.
        f nextPutAll: Time now asString; cr.
        Process allInstances do: [ :p |
            p suspendedContext ifNotNilDo: [ :ctxt | f nextPutAll: 'priority: ',p priority asString; cr;
                nextPutAll: ctxt longStack; cr; cr]
        ].
        f close.
        (Delay forSeconds: 30) wait
    ] repeat
] forkAt: 60

the output might point you to where things stand.

On 2/7/13 12:14 PM, Jeff Gonis wrote:

Hi everyone,

I am currently working on getting the Squeak Jenkins server to perform benchmarking and so far everything is going great except for one thing. When I try to filein code implementing some benchmarks into a headless VM, it just hangs. If I filein the same file to a non-headless VM everything works just fine.

Seeing as how things only blow up when I am running headless, debugging is made somewhat more complicated.

I was wondering if anyone had some advice on getting better debug information from a headless VM, besides explicit log statements? I was also wondering if this sort of problem is ringing any bells for anyone on the list. I don't really have a good grip on how filein works either, so any pointers would be greatly appreciated. Would filein be attempting to send ui messages that are failing? I didn't see any user input requests when I filed into a normal VM, so I don't think it is waiting on a response. Any help is appreciated.

Thanks for your time,
Jeff




    



Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

Jeff Gonis-2
That is awesome.  Getting visibility into the image is exactly what I have been grappling with, so this is a big help.


On Thu, Feb 7, 2013 at 12:05 PM, Bob Arning <[hidden email]> wrote:
If you can't see what's going on inside the headless image, getting some sort of picture would be a start. Try doing this in the image and save it:

[
    [
        f _ FileDirectory default fileNamed: 'allMyProcesses'.
        f nextPutAll: Time now asString; cr.
        Process allInstances do: [ :p |
            p suspendedContext ifNotNilDo: [ :ctxt | f nextPutAll: 'priority: ',p priority asString; cr;
                nextPutAll: ctxt longStack; cr; cr]
        ].
        f close.
        (Delay forSeconds: 30) wait
    ] repeat
] forkAt: 60

the output might point you to where things stand.


On 2/7/13 12:14 PM, Jeff Gonis wrote:

Hi everyone,

I am currently working on getting the Squeak Jenkins server to perform benchmarking and so far everything is going great except for one thing. When I try to filein code implementing some benchmarks into a headless VM, it just hangs. If I filein the same file to a non-headless VM everything works just fine.

Seeing as how things only blow up when I am running headless, debugging is made somewhat more complicated.

I was wondering if anyone had some advice on getting better debug information from a headless VM, besides explicit log statements? I was also wondering if this sort of problem is ringing any bells for anyone on the list. I don't really have a good grip on how filein works either, so any pointers would be greatly appreciated. Would filein be attempting to send ui messages that are failing? I didn't see any user input requests when I filed into a normal VM, so I don't think it is waiting on a response. Any help is appreciated.

Thanks for your time,
Jeff




    







Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

Eliot Miranda-2


On Thu, Feb 7, 2013 at 11:18 AM, Jeff Gonis <[hidden email]> wrote:
That is awesome.  Getting visibility into the image is exactly what I have been grappling with, so this is a big help.


On Thu, Feb 7, 2013 at 12:05 PM, Bob Arning <[hidden email]> wrote:
If you can't see what's going on inside the headless image, getting some sort of picture would be a start. Try doing this in the image and save it:

[
    [
        f _ FileDirectory default fileNamed: 'allMyProcesses'.
        f nextPutAll: Time now asString; cr.
        Process allInstances do: [ :p |
            p suspendedContext ifNotNilDo: [ :ctxt | f nextPutAll: 'priority: ',p priority asString; cr;
                nextPutAll: ctxt longStack; cr; cr]
        ].
        f close.
        (Delay forSeconds: 30) wait
    ] repeat
] forkAt: 60

the output might point you to where things stand.

and with the Cog VMs on Mac and Linux sending SIGUSR1 to the VM will get it to print out the same to the console (provided you start the VM from a console).



On 2/7/13 12:14 PM, Jeff Gonis wrote:

Hi everyone,

I am currently working on getting the Squeak Jenkins server to perform benchmarking and so far everything is going great except for one thing. When I try to filein code implementing some benchmarks into a headless VM, it just hangs. If I filein the same file to a non-headless VM everything works just fine.

Seeing as how things only blow up when I am running headless, debugging is made somewhat more complicated.

I was wondering if anyone had some advice on getting better debug information from a headless VM, besides explicit log statements? I was also wondering if this sort of problem is ringing any bells for anyone on the list. I don't really have a good grip on how filein works either, so any pointers would be greatly appreciated. Would filein be attempting to send ui messages that are failing? I didn't see any user input requests when I filed into a normal VM, so I don't think it is waiting on a response. Any help is appreciated.

Thanks for your time,
Jeff




    











--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

Paul DeBruicker
In reply to this post by Jeff Gonis-2
Jeff Gonis-2 wrote
As a follow up question for people who have experience working with
headless images, would I need to set the "user name" in the image before I
file in code? I know that when I make a change in a fresh image that isn't
headless it asks me for my initials, is it possible that the filein code is
waiting on user input for the initials?

I ran into the initials issue building Seaside 3.1 on travisci.org.  If the code you're loading would pop up the initials dialog in headful Squeak then you need to set the initials in the *.st file you use to load the offending code into the image before that code is loaded.  On Squeak you can set the initials thusly:

Utilities setAuthorInitials: 'pad'

And on Pharo

Author fullName: 'PaulDeBruicker'


and if you want to be able to do it on both platforms from one script:

"Set the author in case its needed"
('Pharo*' match: Smalltalk version) ifTrue:[Author fullName: 'PaulDeBruicker'].
('Squeak*' match: Smalltalk version) ifTrue:[Utilities setAuthorInitials: 'pad'].


HTH

Paul
Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

Frank Shearar-3
In reply to this post by Jeff Gonis-2
On 7 February 2013 17:14, Jeff Gonis <[hidden email]> wrote:

> Hi everyone,
>
> I am currently working on getting the Squeak Jenkins server to perform
> benchmarking and so far everything is going great except for one thing. When
> I try to filein code implementing some benchmarks into a headless VM, it
> just hangs. If I filein the same file to a non-headless VM everything works
> just fine.
>
> Seeing as how things only blow up when I am running headless, debugging is
> made somewhat more complicated.
>
> I was wondering if anyone had some advice on getting better debug
> information from a headless VM, besides explicit log statements? I was also
> wondering if this sort of problem is ringing any bells for anyone on the
> list. I don't really have a good grip on how filein works either, so any
> pointers would be greatly appreciated. Would filein be attempting to send ui
> messages that are failing? I didn't see any user input requests when I filed
> into a normal VM, so I don't think it is waiting on a response. Any help is
> appreciated.

SyntaxErrors in your scripts will bite. Run the image headful until
you're sure you've got it right. Wrapping your script in an [] on:
Error do: [:e | "print to stdout" ] is a good idea, but doesn't save
you from a SyntaxError. We'll probably have this problem until we (a)
rewrite the load logic and (b) have something like Pharo's
CommandLineUIManager.

Also, don't ever put ! characters in your load scripts. Even if
they're in a string. See http://bugs.squeak.org/view.php?id=7732

frank

> Thanks for your time,
> Jeff
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Filein mechanics

David T. Lewis
In reply to this post by Eliot Miranda-2
On Thu, Feb 07, 2013 at 12:09:27PM -0800, Eliot Miranda wrote:

> On Thu, Feb 7, 2013 at 11:18 AM, Jeff Gonis <[hidden email]> wrote:
>
> > That is awesome.  Getting visibility into the image is exactly what I have
> > been grappling with, so this is a big help.
> >
> >
> > On Thu, Feb 7, 2013 at 12:05 PM, Bob Arning <[hidden email]> wrote:
> >
> >>  If you can't see what's going on inside the headless image, getting
> >> some sort of picture would be a start. Try doing this in the image and save
> >> it:
> >>
> >> [
> >>     [
> >>         f _ FileDirectory default fileNamed: 'allMyProcesses'.
> >>         f nextPutAll: Time now asString; cr.
> >>         Process allInstances do: [ :p |
> >>             p suspendedContext ifNotNilDo: [ :ctxt | f nextPutAll:
> >> 'priority: ',p priority asString; cr;
> >>                 nextPutAll: ctxt longStack; cr; cr]
> >>         ].
> >>         f close.
> >>         (Delay forSeconds: 30) wait
> >>     ] repeat
> >> ] forkAt: 60
> >>
> >> the output might point you to where things stand.
> >>
> >
> and with the Cog VMs on Mac and Linux sending SIGUSR1 to the VM will get it
> to print out the same to the console (provided you start the VM from a
> console).
>

Or if you are using an interpreter VM and you have OSProcess installed,
this turns on a similar feature:

  "OSProcess accessor setPrintAllStacksOnSigUsr1"

Although I have to say that I like Bob Arning's suggestion, since it will
produce a log file with something possibly useful at the end of the file
after the image hangs.

Dave