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

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

by StÃ©phane Ducasse

On Jan 26, 2011, at 3:49 PM, Fernando Olivero wrote: > Great Work! > > Is it safe to assume that all ui requests go through UIManager now? well.... I not bet my head on that. :D But if you find cases then we should fix that one by one. > > Fernando

Jan. 26, 2011

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

by Sven Van Caekenberghe

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 ?

Jan. 26, 2011

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

by Henrik Sperre Johansen

On 26.01.2011 12:40, HwaJong Oh wrote: > Thank you for your detailed advice. > Although i could only comply bitShift: adivce. Using trait was unsuccessful. > super send is not possible with traits and applying PointArrayTrait on > ShortPointArray makes strange error. > > New version is out. (Balloon-hjo.73) Strange, using a trait worked fine when I tried it, all tests passing, see v74 in inbox for details. Cheers, Henry

Jan. 26, 2011

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

by Fernando Olivero

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(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. > > > 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 Adrian Lienhard

Implemented as redirects this is possible. Making the build server available under, say, ci.pharo-project.org should also be possible (without a redirect) since we have access to the server (I assume). With Google project this is obviously not possible. The question is where to implement the redirects. Marcus, can Hetzner, who hosts the DNS, do this? Adrian On Jan 26, 2011, at 13:44 , Sven Van Caekenberghe wrote: > +1 > > On a related note, I just discovered that pharo.st actually does the right thing, cool! > I don't know how things are organized, but at least the pharo.st domain seems to be owned by Marcus. > Anyway, in some respects it seems like a better name. > > Sven > > On 26 Jan 2011, at 11:14, 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 >> > >

Jan. 26, 2011

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

by Igor Stasenko

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

[Pharo-project] [update 1.2] #12323

by Marcus Denker

12323 ----- Issue 3572: Failing test on Hudson: MCInitializationTest.testWorkingCopy Issue 3594: Expander needs tweaking to enable resize in a TableLayout (again) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 26, 2011

Re: [Pharo-project] Issue 3594 in pharo: Expander needs tweaking to enable resize in a TableLayout

by pharo＠googlecode.com

Updates: Status: Closed Comment #8 on issue 3594 by marcus.d...(a)gmail.com: Expander needs tweaking to enable resize in a TableLayout http://code.google.com/p/pharo/issues/detail?id=3594 in 12323

Jan. 26, 2011

Re: [Pharo-project] Issue 3572 in pharo: Failing test on Hudson: MCInitializationTest.testWorkingCopy

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.2 Comment #4 on issue 3572 by marcus.d...(a)gmail.com: Failing test on Hudson: MCInitializationTest.testWorkingCopy http://code.google.com/p/pharo/issues/detail?id=3572 removed from 1.2

Jan. 26, 2011

[Pharo-project] Issue 3598 in pharo: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3598 by marcus.d...(a)gmail.com: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing http://code.google.com/p/pharo/issues/detail?id=3598 Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing - fix is simple : initialize the CompilerTest interactive ivar before running tests.

Jan. 26, 2011