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

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by David T. Lewis

On Tue, Jan 29, 2013 at 10:54:25PM -0300, St?phane Ducasse wrote: > > > Probably you need to load OSProcess. From a package point of view, the two > > are completely independent. You can load either OSProcess or CommandShell > > without loading the other. But from a practical point of view, CommandShell > > is not very useful without OSProcess to access the operating system. > > I would say that it does not work so commandShell requires OSProcess so I will add > it to the next version of the configuration and probably build a configuration for it. > +1 Dave

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by David T. Lewis

On Tue, Jan 29, 2013 at 05:42:39PM -0800, Sean P. DeNigris wrote: > David T. Lewis wrote > > Thanks! Probably we should call this ConfigurationOfCommandShell > > I was maintaining a ConfigurationOfCommandShell at > http://www.squeaksource.com/MetacelloRepository . I had done some > investigation into the dependencies and coded them into the baseline. Maybe > you can use it for inspiration... > Yes, there should probably be both a ConfigurationOfOSProcess and a ConfigurationOfCommandShell. I am not sure what repositories these should be in, but they should be somewhere that will be easy for a Pharo user to locate. I do not pay much attention to it for Squeak but for Pharo it is important to exclude MVC from the configuration, and there is a Pharo-specific menu registration that is different from Squeak, so it is good to be able to load these with Metacello configurations. Otherwise everything should be the some for Pharo and Squeak now. Dave

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by StÃ©phane Ducasse

thanks sean. I will have a look and I should rename the configuration. and the configruation should be publish in the package then once it will be ready I will push it to the MetacelloRepository. On Jan 29, 2013, at 10:42 PM, Sean P. DeNigris wrote: > David T. Lewis wrote >> Thanks! Probably we should call this ConfigurationOfCommandShell > > I was maintaining a ConfigurationOfCommandShell at > http://www.squeaksource.com/MetacelloRepository . I had done some > investigation into the dependencies and coded them into the baseline. Maybe > you can use it for inspiration... > > HTH, > Sean > > > > -- > View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4666478.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by StÃ©phane Ducasse

On Jan 29, 2013, at 10:14 PM, David T. Lewis wrote: > Stef, > > Thanks! Probably we should call this ConfigurationOfCommandShell, because > we also have a ConfigurationOfOSProcess in http://www.squeaksource.com/MetacelloRepository. > You have commit access to SqS/CommandShell if you want to post it there also. Yes now I understand. I will rename it tomorrow. Now bed. > > Dave > > On Tue, Jan 29, 2013 at 09:54:08PM -0300, St?phane Ducasse wrote: >> David >> >> I commited a first version here: >> >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/StephaneDucasse/PetitsBazars/main' >> user: 'StephaneDucasse' >> password: '' >> >> Stef >> >> On Jan 29, 2013, at 9:34 PM, St?phane Ducasse wrote: >> >>> David >>> >>> The first version is loading in 2.0:) >>> Do you want me to publish it in the www.squeaksource.com. repository? >>> >>> Some feedback: >>> - you have some circular dependencies between base and Commands. >>> Commandshell in base relies on ShellBuiltin >>> installCommands: aCommandArray self builtinCommands: (ShellBuiltin commandDictionaryFor: self commands: aCommandArray) >>> >>> >>> >>> - when I typed ls in the command tools I get an error because withBlanksTrimmed DNU >>> we could add it as an extension as follows. >>> String>> withBlanksTrimmed >>> ^ self trimBoth >>> >>> - same for withoutTrailingBlanks >>> >>> Strange I finally typed ls and I got >>> > cannot access system to run 'ls' >>> >>> >>> On Jan 29, 2013, at 12:14 AM, David T. Lewis wrote: >>> >>>> I have updated CommandShell for Pharo 2.0, and made a few additional >>>> updates to OSProcess also. In addition to CommandShell-Piping, the rest >>>> of the CommandShell package (except for CommandShell-MVC) can now be >>>> loaded into Pharo 2.0. CommandShellPharo provides the menu registration >>>> to make "Command shell" available under "Tools" in the world menu. >>>> >>>> The repository is at http://www.squeaksource.com/CommandShell, and the >>>> latest versions are: >>>> >>>> CommandShell-Base-dtl.29 >>>> CommandShell-Piping-dtl.13 >>>> CommandShell-Commands-dtl.13 >>>> CommandShell-UI-dtl.10 >>>> CommandShell-Morphic-dtl.2 >>>> CommandShellPharo-dtl.2 >>>> >>>> Yes I know, it needs a ConfigurationOfCommandShell. >>>> >>>> There are test failures related to VM issues but the basic functionality >>>> is now working, and both OSProcess and CommandShell should now be working >>>> for Pharo on Unix/Linux (and hopefully Mac) VMs. >>>> >>>> Dave >>>> >>>> >>>> On Thu, Jan 24, 2013 at 08:38:03PM -0500, David T. Lewis wrote: >>>>> >>>>> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. >>>>> >>>>> The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 >>>>> in the SqueakSource repositories for OSProcess and CommandShell. >>>>> >>>>> Thanks to Damien Cassou for doing the original work for OSProcess support >>>>> in Coral. I adapted his work so it will now load in both Squeak and Pharo. >>>>> >>>>> Unit test notes: >>>>> >>>>> The AioEventHandlerTestCase failures are due to AioPlugin not included in >>>>> the VM. I expect the tests will pass if AioPlugin is added to VM builds. >>>>> >>>>> Many test rely on #forkSqueak to create cooperating OS processes for the >>>>> tests. These tests fail on Cog, although this does not affect basic >>>>> functionality of OSProcess itself. >>>>> >>>>> UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem >>>>> introduced in the oscog branch of the OSProcessPlugin. This should be fixed >>>>> in the plugin but is a minor concern and does not affect normal usage >>>>> of OSProcess. >>>>> >>>>> Dave >>>>> >>>> >>> >>> >> >

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by StÃ©phane Ducasse

>> The first version is loading in 2.0:) >> Do you want me to publish it in the www.squeaksource.com. repository? > > Yes, that would be fine. I don't know if it should go in the CommandShell repository > or a Pharo one? I added you as developer on CommandShell so you can commit it > there. As you wish. For now I pushed it in my fourretout :) > >> >> Some feedback: >> - you have some circular dependencies between base and Commands. >> Commandshell in base relies on ShellBuiltin >> installCommands: aCommandArray self builtinCommands: (ShellBuiltin commandDictionaryFor: self commands: aCommandArray) >> > > Hmmm, probably so. I have not been too careful about the dependencies in the > packages within CommandShell. The hard part for me was to break all of the > dependencies between CommandShell and OSProcess. I was able to do that, but > I ended up with PipeableOSProcess in the CommandShell package. But most of > the people who use it only want OSProcess, so I need to figure out a better > way to split it. ok this is why metacello is interesting. It also forces us to think about dependencies. >> Strange I finally typed ls and I got >> > cannot access system to run 'ls' >> > > Probably you need to load OSProcess. From a package point of view, the two > are completely independent. You can load either OSProcess or CommandShell > without loading the other. But from a practical point of view, CommandShell > is not very useful without OSProcess to access the operating system. I would say that it does not work so commandShell requires OSProcess so I will add it to the next version of the configuration and probably build a configuration for it. > > Thanks a lot!

Jan. 30, 2013

[Pharo-project] The Road to 2.0

by Sean P. DeNigris

There have been 1482 issues tagged with 2.0 [1] Of which 1403 have been closed Leaving only 79 [2] As we near the finish line for 2.0, I acknowledge everyone who contributed... even if just one slice, or even one post that moved a discussion toward a great solution. To me, over 1400 issues in one year seems like an extraordinary amount of progress! Cheers, Sean [1] http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D2.0 [2] http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D2.0 -- View this message in context: http://forum.world.st/The-Road-to-2-0-tp4666482.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by David T. Lewis

On Tue, Jan 29, 2013 at 09:34:37PM -0300, St?phane Ducasse wrote: > > - when I typed ls in the command tools I get an error because withBlanksTrimmed DNU > we could add it as an extension as follows. > String>> withBlanksTrimmed > ^ self trimBoth > > - same for withoutTrailingBlanks > Thanks, these are fixed now in CommandShell-Base-dtl.31 and CommandShell-Tests-dtl.11 Dave

Jan. 30, 2013

Re: [Pharo-project] Pharo 2.0 - System Error Handling Failed

by Sean P. DeNigris

>From the users list... Sean P. DeNigris wrote > > Ben Coman wrote >> FirstImpressionsCount :) > I actually like that a lot. If there are no objections, I'll change it to > that. Also, this and HorribleXyz should be issue types, not statuses; I'll > fix that too... In the issue tracker: "Status:QualityControl" is now "Type:FirstImpressionsCount" and "Status:HorribleErrorBlockingEverything" is now a type (instead of a status) with the same name as before I did this because these things are not really statuses and then, for example if the status was HorribleErrorBlockingEverything, we either won't know when it's FixReviewNeeded, or it will be changed to that and maybe we forget how horrible it is :) All existing issues have been migrated to the new tags HTH, Sean -- View this message in context: http://forum.world.st/Re-Pharo-2-0-System-Error-Handling-Failed-tp4666479.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by Sean P. DeNigris

David T. Lewis wrote > Thanks! Probably we should call this ConfigurationOfCommandShell I was maintaining a ConfigurationOfCommandShell at http://www.squeaksource.com/MetacelloRepository . I had done some investigation into the dependencies and coded them into the baseline. Maybe you can use it for inspiration... HTH, Sean -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4666478.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by David T. Lewis

Stef, Thanks! Probably we should call this ConfigurationOfCommandShell, because we also have a ConfigurationOfOSProcess in http://www.squeaksource.com/MetacelloRepository. You have commit access to SqS/CommandShell if you want to post it there also. Dave On Tue, Jan 29, 2013 at 09:54:08PM -0300, St?phane Ducasse wrote: > David > > I commited a first version here: > > MCHttpRepository > location: 'http://smalltalkhub.com/mc/StephaneDucasse/PetitsBazars/main' > user: 'StephaneDucasse' > password: '' > > Stef > > On Jan 29, 2013, at 9:34 PM, St?phane Ducasse wrote: > > > David > > > > The first version is loading in 2.0:) > > Do you want me to publish it in the www.squeaksource.com. repository? > > > > Some feedback: > > - you have some circular dependencies between base and Commands. > > Commandshell in base relies on ShellBuiltin > > installCommands: aCommandArray self builtinCommands: (ShellBuiltin commandDictionaryFor: self commands: aCommandArray) > > > > > > > > - when I typed ls in the command tools I get an error because withBlanksTrimmed DNU > > we could add it as an extension as follows. > > String>> withBlanksTrimmed > > ^ self trimBoth > > > > - same for withoutTrailingBlanks > > > > Strange I finally typed ls and I got > > > cannot access system to run 'ls' > > > > > > On Jan 29, 2013, at 12:14 AM, David T. Lewis wrote: > > > >> I have updated CommandShell for Pharo 2.0, and made a few additional > >> updates to OSProcess also. In addition to CommandShell-Piping, the rest > >> of the CommandShell package (except for CommandShell-MVC) can now be > >> loaded into Pharo 2.0. CommandShellPharo provides the menu registration > >> to make "Command shell" available under "Tools" in the world menu. > >> > >> The repository is at http://www.squeaksource.com/CommandShell, and the > >> latest versions are: > >> > >> CommandShell-Base-dtl.29 > >> CommandShell-Piping-dtl.13 > >> CommandShell-Commands-dtl.13 > >> CommandShell-UI-dtl.10 > >> CommandShell-Morphic-dtl.2 > >> CommandShellPharo-dtl.2 > >> > >> Yes I know, it needs a ConfigurationOfCommandShell. > >> > >> There are test failures related to VM issues but the basic functionality > >> is now working, and both OSProcess and CommandShell should now be working > >> for Pharo on Unix/Linux (and hopefully Mac) VMs. > >> > >> Dave > >> > >> > >> On Thu, Jan 24, 2013 at 08:38:03PM -0500, David T. Lewis wrote: > >>> > >>> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. > >>> > >>> The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 > >>> in the SqueakSource repositories for OSProcess and CommandShell. > >>> > >>> Thanks to Damien Cassou for doing the original work for OSProcess support > >>> in Coral. I adapted his work so it will now load in both Squeak and Pharo. > >>> > >>> Unit test notes: > >>> > >>> The AioEventHandlerTestCase failures are due to AioPlugin not included in > >>> the VM. I expect the tests will pass if AioPlugin is added to VM builds. > >>> > >>> Many test rely on #forkSqueak to create cooperating OS processes for the > >>> tests. These tests fail on Cog, although this does not affect basic > >>> functionality of OSProcess itself. > >>> > >>> UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem > >>> introduced in the oscog branch of the OSProcessPlugin. This should be fixed > >>> in the plugin but is a minor concern and does not affect normal usage > >>> of OSProcess. > >>> > >>> Dave > >>> > >> > > > > >

Jan. 30, 2013