[Pharo-project] [ENH] About NonInteractive UI manager
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.
Great Work! Is it safe to assume that all ui requests go through UIManager now? Fernando On Wed, Jan 26, 2011 at 3:27 PM, Igor Stasenko <siguctua@gmail.com> 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.
On 26 Jan 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).
Very good. Thanks a lot for all the effort! I'll have to start tracking 1.3 now and we're not yet using 1.2 ;-)
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.
Indeed, one step at a time, but if you add that as well, I think you have a complete solution! Things like advanced command line processing, scripting tools and some kind of REPL are too complex for core and should be part of optional packages. Sven PS: For which VM's is it necessary to say -headless twice ?
Indeed, one step at a time, but if you add that as well, I think you have a complete solution!
Things like advanced command line processing, scripting tools and some kind of REPL are too complex for core and should be part of optional packages.
we will have that soon :) We want to rewrite the codeLoader from scratch for Coral.
On 26 January 2011 15:59, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 26 Jan 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).
Very good. Thanks a lot for all the effort! I'll have to start tracking 1.3 now and we're not yet using 1.2 ;-)
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.
Indeed, one step at a time, but if you add that as well, I think you have a complete solution!
Things like advanced command line processing, scripting tools and some kind of REPL are too complex for core and should be part of optional packages.
Sven
PS: For which VM's is it necessary to say -headless twice ?
I found that it doesn't works with Cog VM on Macs. On Hudson build server, which runs on linux it works well out of the box (but that using Sqeuak VM though).
-- Best regards, Igor Stasenko AKA sig.
On 26 Jan 2011, at 16:12, Igor Stasenko wrote:
I found that it doesn't works with Cog VM on Macs.
On Hudson build server, which runs on linux it works well out of the box (but that using Sqeuak VM though).
OK, Thanks. I found the Cog VM's acting strange sometimes, especially in the headless case, a hanging headless VM is hard to debug (NonInteractive UI manager will hopefully change that in the future). The latest unix VM (4.4.7 2356) worked better for me. Sven
Sounds cool. Just a couple of questions: - should I as a UI developer take care of anything in particular to make sure that I do not bypass the mechanism? - when we access the image through RFB, will we get the UI? Cheers, Doru On 26 Jan 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.
-- www.tudorgirba.com "Value is always contextual."
On 26 January 2011 17:30, Tudor Girba <tudor.girba@gmail.com> wrote:
Sounds cool.
Just a couple of questions: - should I as a UI developer take care of anything in particular to make sure that I do not bypass the mechanism?
all calls directed to ui manager will be intercepted properly. if you using things like World/Hand/Display, then of course there is no any guarantees, but normally your application should not use it outside of morphic boundaries. I mean that if your application having morph subclasses, then of course you can use these globals directly in it. And for applications like Seaside, you normally should not directly use that and pass all UI requests to UI manager.
- when we access the image through RFB, will we get the UI?
no. When RFB is present in system, it should prevent from switching UI manager to non-interactive one. I imagine there should be some kind of hooks, so RFB can influence the decision whether use UI or not. I imagine a proper , non-intrusive way of hooking into this logic with RFB is to subclass the MorphicUIManager with own subclass and override the #onSnapshot: in order to prevent switching to non-interactive manager.
Cheers, Doru
On 26 Jan 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.
-- www.tudorgirba.com
"Value is always contextual."
-- Best regards, Igor Stasenko AKA sig.
On 26/01/11 9:27 AM, Igor Stasenko wrote:
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.
This is great work! I will test it out shortly, but I'm wondering about the VNC scenario. I run on a remote Linux server with "-headless". VNC is not started in the image. If I suspect a problem, then I use the Seaside app at /tools/vnc to start the VNC server. Then I attach to the image with a VNC client, and proceed to debug. I suspect this scenario will be broken. The problem is that the "-headless" flag does not mean there is no interactive UI needed. It means that there is no local display. If there is a way the flip the switch, in the running image, then the /tools/vnc code could flip that switch. -- Yanni
On 26 January 2011 17:44, Yanni Chiu <yanni@rogers.com> wrote:
On 26/01/11 9:27 AM, Igor Stasenko wrote:
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.
This is great work!
I will test it out shortly, but I'm wondering about the VNC scenario. I run on a remote Linux server with "-headless". VNC is not started in the image. If I suspect a problem, then I use the Seaside app at /tools/vnc to start the VNC server. Then I attach to the image with a VNC client, and proceed to debug.
I suspect this scenario will be broken. The problem is that the "-headless" flag does not mean there is no interactive UI needed. It means that there is no local display.
Well, the aim of this changes is to offer the default scenario for core images which have nothing like VNC loaded. Sure thing VNC could intrude (see my previous post) and change this in any way it likes it. The point it that we had almost nothing to offer to people who not using VNC until now.
If there is a way the flip the switch, in the running image, then the /tools/vnc code could flip that switch.
Yes, sure there is the way to flip the switch. The simpest way of doing that is to do following: UIManager default: nil. And of course the discussion about nice API around this stuff is welcome. If you have any better ideas how to make image with VNC server to play nicely with new changes, feel free to present it. For instance, one idea is to have VNC server running , but if there is no connections then use non-interactive UI manager, and only if there user connected then use interactive mode. Also, varoius different hooks /extensions could be made , like providing a choice what to do on unhandled error, i.e. instead of quitting the image, one could send a email and kill the process which raised an error :)
-- Yanni
-- Best regards, Igor Stasenko AKA sig.
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.
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 <bouraqadi@gmail.com>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.
On Wed, Jan 26, 2011 at 6:27 AM, Igor Stasenko <siguctua@gmail.com> 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?
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.
On 26 January 2011 21:58, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 26, 2011 at 6:27 AM, Igor Stasenko <siguctua@gmail.com> 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? 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 :)
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.
On Wed, Jan 26, 2011 at 4:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 January 2011 21:58, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 26, 2011 at 6:27 AM, Igor Stasenko <siguctua@gmail.com>
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.
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 <siguctua@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.
On 27 January 2011 05:59, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
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,
what should happen in headless image when you pressing cmd+. ? Or what you wanna achieve? Why you need to trigger interrupt by simulating such keystrokes? I think there is many ways how to interrupt a program (throw an exception for instance). And since usual pressing cmd-. leads to opening window, then in non-interactive mode it should raise a ErrorNonInteractive (if not handled by UI manager before).
Hernán
-- Best regards, Igor Stasenko AKA sig.
2011/1/27 Igor Stasenko <siguctua@gmail.com>:
On 27 January 2011 05:59, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
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,
what should happen in headless image when you pressing cmd+. ? Or what you wanna achieve? Why you need to trigger interrupt by simulating such keystrokes?
So I can provide manually highest priority to the interrupt code (sometimes "Cmd + ." from the keyboard doesn't work)
I think there is many ways how to interrupt a program (throw an exception for instance).
And since usual pressing cmd-. leads to opening window, then in non-interactive mode it should raise a ErrorNonInteractive (if not handled by UI manager before).
I see, what I want to know is if with your changes there is a way to distinguish unwanted popups from wanted for special purposes, or every UI request in all situations is considered an Error. Hernán
participants (10)
-
Eliot Miranda -
Fernando Olivero -
Hernán Morales Durand -
Igor Stasenko -
Mariano Martinez Peck -
Noury Bouraqadi -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba -
Yanni Chiu