Hi Igor, It seems to be nice work, just a question: if my image ruins and I want to send Cmd + . at some point (let's say some code which triggers the keystroke combination in myscript.st), if I understood right that would raise an error too... do your changes permit exceptions for actually wanted "popup" behaviors like those necessary for reparing? Cheers,
Hernán 2011/1/26 Igor Stasenko <siguc...@gmail.com>: > Hello pharoers, > > the last two days we worked hard with Marcus to incorporate this new > stuff into image, and now we're done. > All images past #13021 now have non interactive ui manager > (NonInteractiveUIManager). > We fixed almost all broken tests caused by introducing it (there are > only few minor ones left). > Probably there could be more infrastructure around that in future > (like redirecting Transcript output to some file/stdout while running > headless), but first things first. > > > Couple of words, what new stuff gives to you: > > - suppose you want to run image headless. Suppose that you probably > run an arbirary (or not so) piece of code, > which not always clear how well it goes.. and it could lead to > unwanted popups, like asking user to confirm something, > or even opening a debugger window, actually anything which leads to > one unwanted effect: making your image to wait for user's input or > other form of intervention, > which is completely what you don't wanna see on server image, because > it should run fully automated. > > How it works: > > UIManager, during image startup, checks if image runs headless, and if > so, then it switching to non-interactive mode. > The non-interactive mode means that any request to UI manager which > normally leads to some user interaction now will trigger an error > (ErrorNonInteractive). > If you run image headful again, it will switch to usual UI manager > back, so don't expect to have this error when running headful image. > And be careful when testing/writing your code: image will run using > different ui manager depending on startup conditions. > > (Note: some VMs on some platforms filtering out the VM command line > parameters and image can't detect that it runs headless. To prevent > that, add extra -headless arg as last one in argument list. > > For example: > > squeak -headless myImage.image myscript.st -headless > > ). > > To test if image running headless, a new protocol was introduced: > > Smalltalk isHeadless > and > Smallalk isInteractive > > (which are antonyms). > > > Error handling: > > In case if there an unhandled error occurs, the default behavior is: > - print stack trace on log > - quit image ( or save a new version of image and then quit) - this > is controlled by preference, found in 'settings->Headless mode' group. > > So, sometimes to track the error, you can turn this preference on, > then you can open saved instance of image and check with UI & debugger > what causing the error. > This is what you want to avoid to be default behavior on server, > because on server you need 24/7 service available without your > intervention :) > So, the normal setup for background images now will be to fire a fresh > image if current one dies ( and send mail with pharodebug.log contents > to root :) ) > > P.S. I hope these changes will make life for setting up headless > workflow much easier, because now we can easily track down all issues > which you can't see. > Because before that by default you having a hanging image, which doing > something or not (and you have no idea, because it headless). > > P.P.S. For squeakers, if you want to harvest the changes, take the > changesets from here: > > http://code.google.com/p/pharo/issues/detail?id=3593 > http://code.google.com/p/pharo/issues/detail?id=3596 > > -- > Best regards, > Igor Stasenko AKA sig. > >
