The monkey is back in town

> I had a sudden urge to program something so I revived the monkey (partly)
>
> - full smalltalk implementation (no more ruby)
> - basic command line handler (could be better but works..)
> - using OSProcess with FileSystem-Legacy in 2.0
>
> the only thing missing are the couple of changes I proposed for the main image:
>
> - http://code.google.com/p/pharo/issues/detail?id=7097
> - http://code.google.com/p/pharo/issues/detail?id=7096 
> - http://code.google.com/p/pharo/issues/detail?id=7095
>
> once they are in, we're ready to roll
> cami on fernet

> I had a sudden urge to program something so I revived the monkey (partly)
>
> - full smalltalk implementation (no more ruby)
> - basic command line handler (could be better but works..)
> - using OSProcess with FileSystem-Legacy in 2.0
>
> the only thing missing are the couple of changes I proposed for the main image:
>
> - http://code.google.com/p/pharo/issues/detail?id=7097
> - http://code.google.com/p/pharo/issues/detail?id=7096
> - http://code.google.com/p/pharo/issues/detail?id=7095
>
> once they are in, we're ready to roll
> cami on fernet

>
> Sources are in my smalltalkhub repository:
> http://smalltalkhub.com/#!/~dh83/ci
>
> On 2012-12-05, at 06:28, Goubier Thierry <[hidden email]> wrote:
>> Le 05/12/2012 04:43, Camillo Bruni a écrit :
>>> I had a sudden urge to program something so I revived the monkey (partly)
>>>
>>> - full smalltalk implementation (no more ruby)
>>> - basic command line handler (could be better but works..)
>>
>>> - using OSProcess with FileSystem-Legacy in 2.0
>>
>> So that would be the way to have OSProcess in 2.0?

>
> more or less: there is another deprecation warning coming from `Smalltalk osVersion` but it works...
> You can check the ConfigurationOfCI to see how to include it from
>
> http://smalltalkhub.com/#!/~dh83/fisleg
>
>
>>> the only thing missing are the couple of changes I proposed for the main image:
>>>
>>> - http://code.google.com/p/pharo/issues/detail?id=7097
>>> - http://code.google.com/p/pharo/issues/detail?id=7096
>>> - http://code.google.com/p/pharo/issues/detail?id=7095
>>>
>>> once they are in, we're ready to roll
>>> cami on fernet
>

>
> On Dec 5, 2012, at 1:21 PM, Camillo Bruni <[hidden email]> wrote:
>
>>
>> Sources are in my smalltalkhub repository:
>> http://smalltalkhub.com/#!/~dh83/ci
>>
>> On 2012-12-05, at 06:28, Goubier Thierry <[hidden email]> wrote:
>>> Le 05/12/2012 04:43, Camillo Bruni a écrit :
>>>> I had a sudden urge to program something so I revived the monkey (partly)
>>>>
>>>> - full smalltalk implementation (no more ruby)
>>>> - basic command line handler (could be better but works..)
>>>
>>>> - using OSProcess with FileSystem-Legacy in 2.0
>>>
>>> So that would be the way to have OSProcess in 2.0?
>
> "for now" :)
> OSProcess should load fine and without legacy when 2.0 is released

> Le 05/12/2012 13:47, Esteban Lorenzano a écrit :
>>
>> On Dec 5, 2012, at 1:21 PM, Camillo Bruni <[hidden email]> wrote:
>>
>>>
>>> Sources are in my smalltalkhub repository:
>>> http://smalltalkhub.com/#!/~dh83/ci
>>>
>>> On 2012-12-05, at 06:28, Goubier Thierry <[hidden email]> wrote:
>>>> Le 05/12/2012 04:43, Camillo Bruni a écrit :
>>>>> I had a sudden urge to program something so I revived the monkey (partly)
>>>>>
>>>>> - full smalltalk implementation (no more ruby)
>>>>> - basic command line handler (could be better but works..)
>>>>
>>>>> - using OSProcess with FileSystem-Legacy in 2.0
>>>>
>>>> So that would be the way to have OSProcess in 2.0?
>>
>> "for now" :)
>> OSProcess should load fine and without legacy when 2.0 is released
>
> +1.
>
> But I'm longing for the ability to integrate Pharo images in a mixed language git repository by loading in there a Makefile which:
>
> Builds a Pharo-based tool:
> - downloads the latest Pharo image and vm
> - loads the additional configurations and packages as setup (filetree, for example:)) on the command line...
> - loads the local packages
> - save the built image.
> - install a startup shell in a bin/ or build/ directory, the image in a share/ or lib/ somewhere.
>
> I know I can do that in 2.0, but I need OSProcess...

> David T. Lewis wrote
>> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0.
>
> Awesome!!! Thank you David. I just successfully used PipeableOSProcess in
> latest 2.0 with no load errors.
>
> Cheers,
> Sean
>
>
>
> --
> View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4665268.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

>
> On 2013-01-25, at 05:14, "Sean P. DeNigris" <[hidden email]> wrote:
>
> > David T. Lewis wrote
> >> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0.
> >
> > Awesome!!! Thank you David. I just successfully used PipeableOSProcess in
> > latest 2.0 with no load errors.
> >
> > Cheers,
> > Sean
> >

> On Fri, Jan 18, 2013 at 03:28:10PM +0100, Damien Cassou wrote:
>>
>> you don't need FileSystem-Legacy if you use OSProcess from Coral:
>>
>> Gofer new
>>   squeaksource3: 'coral';
>>   package: 'OSProcess';
>>   load.
>>
>
> 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
>
>

> On Fri, Jan 18, 2013 at 03:28:10PM +0100, Damien Cassou wrote:
>  
>> you don't need FileSystem-Legacy if you use OSProcess from Coral:
>>
>>  Gofer new
>>    squeaksource3: 'coral';
>>    package: 'OSProcess';
>>    load.
>>
>>    
>
> 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
>  
>
>
>  

> David T. Lewis wrote:
> >On Fri, Jan 18, 2013 at 03:28:10PM +0100, Damien Cassou wrote:
> >  
> >>you don't need FileSystem-Legacy if you use OSProcess from Coral:
> >>
> >> Gofer new
> >>   squeaksource3: 'coral';
> >>   package: 'OSProcess';
> >>   load.
> >>
> >>    
> >
> >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.
> >  
> Just general curiosity, is there a way to have a test queued to run
> first which tests for the plug-in, and if it fails the remaining tests
> become "expected failures" rather than "failures".

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

> On Sat, Jan 26, 2013 at 08:50:43AM +0800, Ben Coman wrote:
>> David T. Lewis wrote:
>>> On Fri, Jan 18, 2013 at 03:28:10PM +0100, Damien Cassou wrote:
>>>
>>>> you don't need FileSystem-Legacy if you use OSProcess from Coral:
>>>>
>>>> Gofer new
>>>>  squeaksource3: 'coral';
>>>>  package: 'OSProcess';
>>>>  load.
>>>>
>>>>
>>>
>>> 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.
>>>
>> Just general curiosity, is there a way to have a test queued to run
>> first which tests for the plug-in, and if it fails the remaining tests
>> become "expected failures" rather than "failures".
>
> Yes, you could do this by implementing #expectedFailures to check for the
> plugin and answer a different set of selectors depending on what it finds.
>
> It all depends on what you mean by an "expected failure". To me, failing
> to find the plugin is not an expected failure. It means that something is
> wrong, and somebody should do something about it. In this case it serves
> as a reminder to include AioPlugin in the next VM build. After all, that
> is one of the reasons for doing all those tests in the first place :)
>
> A related question is how to handle failures when running on some other OS
> (e.g. Windows) where OSProcess is really not meaningfully implemented. In
> that case, the failures really are expected. I allow them to fail because
> I wrote the tests for my own benefit as the developer (in that context,
> a feature that does not work on Windows really should fail the test, as it
> shows what still needs to be implemented), but running the tests as part
> of a larger suite on a range of operating systems would be a problem. I
> don't really have any answer for that. I suppose I could enumerate all the
> things that are not expected to work on a non-unix system, but that sounds
> like a lot of work (and no fun) to me.
>
> Dave

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