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

Re: [Pharo-project] [squeak-dev] Re: usability of Pharo and Squeak

by Henrik Sperre Johansen

On 02.06.2011 19:07, Dale Henrichs wrote: > Andreas, > > You are not alone. I too suffer from tooManyWindowsItis ... I am also doing something about it:) Don't we all? :) On a less ambitious note, what I've found to really help cut down on having to deal with it in my day to day VW work, is two menu items I added, called: - Close Inspectors/Debuggers - Close Senders/Implementers Performing a task? Open all the windows I feel like, concentrate on problem. Done with a task? Click the two buttons. Evaluate whether I want the few remaining windows. Start on next one. (It should be noted VW have tabbed system browsers, so I usually only have a few of those open) Cheers, Henry

June 3, 2011

Re: [Pharo-project] [squeak-dev] Re: usability of Pharo and Squeak

by Marcus Denker

On Jun 2, 2011, at 8:32 PM, Andreas Wacknitz wrote: > > The quality of the code and Smalltalk's elegance and kind of OO are only seen after the first hurdle is being taken. The "slice" where you can see this elegance is actually very thin. First people are put off by the look. And *if* you see the beauty of the language and dig deeper, you see the implementation of the rest of the system. Elegance is something else. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 3, 2011

[Pharo-project] 1.2.2 First Impression

by Sean P. DeNigris

I moved from 1.1.1 to 1.2.2 for my development work and wanted to share some things I noticed... Overall, 1.2.2 feels cleaner, snappier, and prettier. My Favorite Things: * OCompletion is really fast!!! * Creating new method protocols - you can type spaces * Help System starting to fill out, and easily accessible from the World Menu Bugs / Regressions (I don't have time to check if each is still true in trunk) * Debugger * the current statement is highlighted in "invisible blue". It's impossible to see. * Creating an accessor - "should be implemented" is highlighted, which is good; but the window doesn't have focus, and clicking on the window's title bar doesn't give the source pane focus * Choosing a protocol for a created method - the selection doesn't jump to the first matching category name like it did in 1.1.1 * OB * Syntax errors - "Nothing more expected ->" is not highlighted, making you have to first select it before you delete it and correct your mistake * Surrounding selected text (e.g. with quotes) - the surrounded text doesn't stay highlighted (the 1.1.1 behavior, which I found very useful) * Monticello - After changing a category name to a sub-category of a different package (e.g. "MyLibrary" -> "MyOtherProject-MyLibrary"), the package is not marked dirty in the MC browser until changes are viewed. I'm really excited to see what comes next!! We're creating a great system. Sean -- View this message in context: http://forum.world.st/1-2-2-First-Impression-tp3569795p3569795.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2011

Re: [Pharo-project] OSProcess on 1.2

by Igor Stasenko

On 3 June 2011 01:47, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > More info on hanging tests... > > Â UnixProcessAccessorTestCase > Â Â Â testIsExecutableForUserInGroup > Â Â Â testIsReadableForUserInGroup > Â Â Â testIsReadable > Â Â Â testIsWritable > Â Â Â testIsWritableForUserInGroup > > All hang on line: OSProcess waitForCommand: 'touch /tmp/delete.me'. > > UnixProcess>>waitForCommand: > Â Â Â Â <snip> > Â Â Â Â [proc runState == #complete] whileFalse: [d wait]. <-- infinite loop > > This may be related to another problem I was having with CommandShell: > Â p := PipeableOSProcess command: '/bin/echo this is a test'. > Â result := p output. "hangs" > > ExternalUnixOSProcess>>isComplete > Â ^ self runState == #complete > from PipeableOSProcess(PipeJunction)>>isComplete > from PipeableOSProcess(PipeJunction)>>outputOn: > from PipeableOSProcess(PipeJunction)>>output > > sounds like VM cannot detect that child process are finished (complete). > -- > View this message in context: http://forum.world.st/OSProcess-on-1-2-tp3569458p3569593.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

June 3, 2011

Re: [Pharo-project] OSProcess on 1.2

by Sean P. DeNigris

More info on hanging tests... UnixProcessAccessorTestCase testIsExecutableForUserInGroup testIsReadableForUserInGroup testIsReadable testIsWritable testIsWritableForUserInGroup All hang on line: OSProcess waitForCommand: 'touch /tmp/delete.me'. UnixProcess>>waitForCommand: <snip> [proc runState == #complete] whileFalse: [d wait]. <-- infinite loop This may be related to another problem I was having with CommandShell: p := PipeableOSProcess command: '/bin/echo this is a test'. result := p output. "hangs" ExternalUnixOSProcess>>isComplete ^ self runState == #complete from PipeableOSProcess(PipeJunction)>>isComplete from PipeableOSProcess(PipeJunction)>>outputOn: from PipeableOSProcess(PipeJunction)>>output -- View this message in context: http://forum.world.st/OSProcess-on-1-2-tp3569458p3569593.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 2, 2011

Re: [Pharo-project] OSProcess on 1.2

by Sean P. DeNigris

Miguel CobÃ¡ wrote: > > Can you elaborate > on the failures? All Pass except... UnixProcessAccessorTestCase Failures: testChDir testPrimForkAndExec testPrimGetChildExitStatus Hangs: on line: (OSProcess waitForCommand: 'touch /tmp/delete.me'.) testIsExecutableForUserInGroup testIsReadableForUserInGroup testIsReadable testIsWritable testIsWritableForUserInGroup OSPipeTestCase Errors: '#(''OSPipeTestCase>>#testBufferedUpToEnd'' <-- See http://forum.world.st/CommandShell-on-1-2-td3569478.html ''OSPipeTestCase>>#testIsAtEndOfFile'' ''OSPipeTestCase>>#testIsAtEndOfFile2' ''OSPipeTestCase>>#testNonBlocking' ''OSPipeTestCase>>#testNonBlockingBufferedPipe'')' AioEventHandlerTestCase: Errors: '#(''AioEventHandlerTestCase>>#testPrimAioModuleName'' Failures: ''AioEventHandlerTestCase>>#testFileReadableEvent'' ''AioEventHandlerTestCase>>#testFileWritableEvent'' ''AioEventHandlerTestCase>>#testSuspendAioForSocketReadableEvent'' ''AioEventHandlerTestCase>>#testHandleForFile'' ''AioEventHandlerTestCase>>#testEnableHandleAndDisable'' ''AioEventHandlerTestCase>>#testSocketReadableEvent'' ''AioEventHandlerTestCase>>#testHandleForSocket'' ''AioEventHandlerTestCase>>#testPrimAioModuleVersionString'' -- View this message in context: http://forum.world.st/OSProcess-on-1-2-tp3569458p3569570.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 2, 2011

Re: [Pharo-project] OSProcess and CommandShell

by David T. Lewis

On Thu, Jun 02, 2011 at 03:15:31PM -0700, Sean P. DeNigris wrote: > > David T. Lewis wrote: > > > > The latest version of OSProcess is 4.4.2, which contains a number of > > updates that may be relevant for Pharo. > > > > So why don't we set up the Config to always load the latest packages? Can > the stable be set this way (I guess load the baseline)? > That would be my suggestion, although I understood that "stable" was intended to refer to some known version that had been tested with a specific released version of Pharo. In any case, my recommendation as the package maintainer is to use the latest versions of OSProcess and CommandShell. Dave

June 2, 2011

Re: [Pharo-project] OSProcess and CommandShell

by Miguel CobÃ¡

El jue, 02-06-2011 a las 15:15 -0700, Sean P. DeNigris escribiÃ³: > David T. Lewis wrote: > > > > The latest version of OSProcess is 4.4.2, which contains a number of > > updates that may be relevant for Pharo. > > > > So why don't we set up the Config to always load the latest packages? Can > the stable be set this way (I guess load the baseline)? Because although it can work for the following months in a couple of years where OSProcess uses something from the image from 2014 it wont work anymore. It is better to link a stable version to a given version. This number can be then corrected as tested OSProcess versions are verified to work in a given image release. Even then, only the stable version for that pharo release would be updated, not every possible Pharo image. Cheers > > -- > View this message in context: http://forum.world.st/OSProcess-and-CommandShell-tp3447914p3569536.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

June 2, 2011

Re: [Pharo-project] SimpleWebDoc

by GastÃ³n Dall' Oglio

ok, thanks 2011/6/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Better focus on the one developed by camillo bruni and that we should put > online when he is back from Japan. > > Stef > > On Jun 2, 2011, at 8:31 PM, GastÃ³n Dall' Oglio wrote: > > > What about the current state of > http://www.squeaksource.com/SimpleWebDoc.html ? > > >

June 2, 2011

Re: [Pharo-project] OSProcess and CommandShell

by Sean P. DeNigris

David T. Lewis wrote: > > The latest version of OSProcess is 4.4.2, which contains a number of > updates that may be relevant for Pharo. > So why don't we set up the Config to always load the latest packages? Can the stable be set this way (I guess load the baseline)? -- View this message in context: http://forum.world.st/OSProcess-and-CommandShell-tp3447914p3569536.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 2, 2011