January 2011 - Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 27 January 2011 05:59, HernÃ¡n Morales Durand <hernan.morales(a)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.

Jan. 27, 2011

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

by pharo＠googlecode.com

Comment #10 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 Normally it works, but this is quite difficult to test because you need a serial device connected.

Jan. 27, 2011

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

by pharo＠googlecode.com

Comment #9 on issue 1057 by stephane...(a)gmail.com: SerialPlugin doesn't handle arbitrary nodes names http://code.google.com/p/pharo/issues/detail?id=1057 let us make it work. Now I do not know how I can test it Stef

Jan. 27, 2011

[Pharo-project] Issue 3600 in pharo: Enhancement : Refactorings and tests on Balloon-Collections.

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3600 by daliot...(a)gmail.com: Enhancement : Refactorings and tests on Balloon-Collections. http://code.google.com/p/pharo/issues/detail?id=3600 Refactoring is mainly about moval of a set of methods that PointArray and ShortPointArray share its definition. Both classes does not share common superclass, therefore a helper class named "FriendOfPointArray"is introduced. Attachments: Balloon-hjo.73.mcz 83.0 KB

Jan. 27, 2011

Re: [Pharo-project] First commit to Pharoinbox. Need advice.

by HwaJong Oh

Yes, you are right. I was wrong. There is nothing super send. I had error editing my trait codes around "super", so i thought trait can super send. http://screencast.com/t/yyjLLm0S MoveMethod: FriendOfPointArray >> at: index ^(pointArray superAt: index * 2 - 1) @ (pointArray superAt: index * 2) to PointArrayTrait >> at: index ^(super at: index * 2 - 1) @ (super at: index * 2) while editing "pointArray superAt:" to "super at:", the editor made error. Copying the code to native Mac editor, edit them, then copy back to Pharo editor suceeded. -- View this message in context: http://forum.world.st/First-commit-to-Pharoinbox-Need-advice-tp3237535p3241… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 27, 2011

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