- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by HernÃ¡n Morales Durand

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(a)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. > >

Jan. 27, 2011

Re: [Pharo-project] Issue 1057 in pharo: SerialPlugin doesn't handle arbitrary nodes names

by pharo＠googlecode.com

Comment #8 on issue 1057 by serge.st...(a)gmail.com: SerialPlugin doesn't handle arbitrary nodes names http://code.google.com/p/pharo/issues/detail?id=1057 Yes, you are right, this is the mess with all these isString everywhere. I'm not the author of the code. ;-) I dunno if this is a good idea to have portNumber and portName depending on the platform. Maybe we should rewrite it in order to only use names like 'COM1' for Windows and '/dev/ttyS*' for Unix/Linux ? Any comments about that ?

Jan. 27, 2011

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by Eliot Miranda

On Wed, Jan 26, 2011 at 4:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 January 2011 21:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Wed, Jan 26, 2011 at 6:27 AM, Igor Stasenko <siguctua(a)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. > >

Jan. 27, 2011

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by Igor Stasenko

On 26 January 2011 21:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Jan 26, 2011 at 6:27 AM, Igor Stasenko <siguctua(a)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.

Jan. 27, 2011

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by Mariano Martinez Peck

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(a)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. > > > > >

Jan. 26, 2011

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by Eliot Miranda

On Wed, Jan 26, 2011 at 6:27 AM, Igor Stasenko <siguctua(a)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. > >

Jan. 26, 2011

[Pharo-project] About FileSystem (probably not for 1.3)

by StÃ©phane Ducasse

Hi guys, I was checking the state of FileSystem and we cannot push it into pharo like that! Sad but we should not put code where not a single method has a comment. So instead of crying and bashing colin, I started a while ago to understand (great pain) and write comments probably wrong, of course. Now I did several iterations but not enough. So I will read the blog entries of lukas and try to continue. http://www.lukas-renggli.ch/blog/filesystem Now if you want pharo to evolve, then this is clearly a place to help. We should get better class comments, and all the methods with a comment. Else FileSystem will not get integrated. I will veto it. Colin lost all the changes he did after ESUG so we will have to live with that (for example FSPath not being a class for public consumption and others). Stef

Jan. 26, 2011

[Pharo-project] For a metacello and metacello Repositories taskforces

by StÃ©phane Ducasse

hi guys I really think that this is important that we to the point where the idea of repositories for distributions is working. Getting this idea working is really important since it will enable all the rest to fall naturally in place (hudson checking....) So could you (torsten, Miguel, dale...) try to come up with an agenda of the next steps that should be achieved to arrive to the point where: - a user can publish a configuration into a distribution and all the packages get copied and published there - get a browser browsing the configurations of that distribution? Stef (busy but cannot do otherwise). "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

Jan. 26, 2011

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by Noury Bouraqadi

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. >

Jan. 26, 2011

Re: [Pharo-project] Easy access on pharo-project.org

by Alexandre Bergel

+1 Alexandre On 26 Jan 2011, at 13:00, StÃ©phane Ducasse wrote: > Good ideas! > > On Jan 26, 2011, at 11:14 AM, Torsten Bergmann wrote: > >> We have the shortcut to the collaborative book: >> >> http://book.pharo-project.org >> >> >> Would it be possible: >> >> 1. to access the build server >> https://pharo-ic.lille.inria.fr/hudson/ >> >> under a simple name like: >> >> http://hudson.pharo.org or >> http://ci.pharo.org (ci = continuos integration) >> >> 2. to access the issue tracker >> http://code.google.com/p/pharo/issues >> under >> >> http://issues.pharo-project.org or >> http://bugs.pharo-project.org >> >> 3. to access the wiki >> http://code.google.com/p/pharo/w/list >> under >> http://wiki.pharo-project.org >> >> 4. And the book page >> http://pharo-project.org/documentation/tutorials-books >> has no reference to the collaborative book >> http://book.pharo-project.org >> >> Thx >> T. >> -- >> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 26, 2011