On Wed, Jan 26, 2011 at 4:06 PM, Igor Stasenko <[email protected]> wrote:
> On 26 January 2011 21:58, Eliot Miranda <[email protected]> wrote: > > > > > > On Wed, Jan 26, 2011 at 6:27 AM, Igor Stasenko <[email protected]> > 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. > >> > > > > Is the name right? I mean, if I connect a listener via stdio support it > can > > still be interactive even though there's no head. Shouldn't it be called > > e.g. HeadlessUIManager or NonGUIManager? > > Yeah.. I thought about it. > Well, it is hard to call stdio a UI. Nobody calls basic i/o as UI, and > non-interactive UI is not the same as being able to interact using > basic i/o right? > Last time I used a command line application I interacted with it (e.g. bc, ed, et al). Of course a command-line app can be interactive. If it contains a read-eval-print loop it is interactive. However, command-line programs that don't take user input also abound (cat, mv, rm etc) and these are /not/ interactive (ok, rm -i is). Right? > Maybe HeadlessUIManager is better choice.. if people like it more then > we can rename it.. > And how to call ErrorNonInteractive then? > Because actually i named the error first, and then name of UI manager > came from there :) > Surely ErrorNonInteractive is a non-sequitur. An error is an error no matter whether in an interactive application or not. What's interactive or not interactive, or graphical or textual is the error handler. > >> > >> 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. > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >
