Hi. This is really great. Now, what are the differences from DummyUIManager that we included in PharoCore from the pharoKernel image ?
should we remove DummyUIManager? cheers mariano On Wed, Jan 26, 2011 at 8:47 PM, Noury Bouraqadi <[email protected]>wrote: > Great! Thanx. > > Noury > On 26 janv. 2011, at 15:27, Igor Stasenko wrote: > > > 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. > > > > >
