[Pharo-project] 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
Yes, we love the monkey and missed him ⦠On 05 Dec 2012, at 04:43, Camillo Bruni <camillobruni@gmail.com> wrote:
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
Cool, where can we found source code of the monkey? -- Pavel On Wed, Dec 5, 2012 at 4:43 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
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
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? Thierry
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
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Sources are in my smalltalkhub repository: http://smalltalkhub.com/#!/~dh83/ci On 2012-12-05, at 06:28, Goubier Thierry <thierry.goubier@cea.fr> 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 <camillobruni@gmail.com> wrote:
Sources are in my smalltalkhub repository: http://smalltalkhub.com/#!/~dh83/ci
On 2012-12-05, at 06:28, Goubier Thierry <thierry.goubier@cea.fr> 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
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
Le 05/12/2012 13:47, Esteban Lorenzano a écrit :
On Dec 5, 2012, at 1:21 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
Sources are in my smalltalkhub repository: http://smalltalkhub.com/#!/~dh83/ci
On 2012-12-05, at 06:28, Goubier Thierry <thierry.goubier@cea.fr> 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... By the way, is this expected that the current directory in a Pharo image is not where the vm was started, but where the image file is kept? I have to use (PipeableOSProcess command: 'pwd') output asFileReference to get the true working directory. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 2012-12-05, at 10:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 05/12/2012 13:47, Esteban Lorenzano a écrit :
On Dec 5, 2012, at 1:21 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
Sources are in my smalltalkhub repository: http://smalltalkhub.com/#!/~dh83/ci
On 2012-12-05, at 06:28, Goubier Thierry <thierry.goubier@cea.fr> 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...
then I think you should be fine with the approach I took. I think once 2.0 is declared stable someone will take care of OSProcess. So looks like 2.0 almost covered all your needs, the only thing missing is the startup shell. Of course we can extend Pharo's command line tools a bit, they are still in early stage and need improvement..
By the way, is this expected that the current directory in a Pharo image is not where the vm was started, but where the image file is kept? I have to use
(PipeableOSProcess command: 'pwd') output asFileReference
to get the true working directory.
yeah, the whole working directory stuff is a mess: - FileSystem has it's own notion of working directory, - so does the rest of the Image, - the only one getting it more or less right is OSProcess :/ I wanted to unify it at some point, but well, too many things at the same time :P
Camillo Bruni-3 wrote
OSProcess should load fine and without legacy when 2.0 is released I think once 2.0 is declared stable someone will take care of OSProcess.
I opened an issue...
I realize this is not a problem with Pharo itself, but OSProcess is extremely important and we should track it to make sure it gets loadable into 2.0.
I'll email Dave and see what we can come up with...
Pharo2.0a Latest update: #20476
UndefinedObject(Object)>>doesNotUnderstand: #wait UnixOSProcessAccessor>>grimReaperProcess in Block: [[event wait.... BlockClosure>>newProcess in Block: [self value....
At least one problem seems to be updating for FileSystem. Also, deprecation warnings for OSPlatform class>>osVersion
-- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4663955.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Wed, Dec 5, 2012 at 1:21 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
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
you don't need FileSystem-Legacy if you use OSProcess from Coral: Gofer new squeaksource3: 'coral'; package: 'OSProcess'; load. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
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
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.
very nice! thanks! So that means all the FileSystem changes have been included? On 2013-01-25, at 05:14, "Sean P. DeNigris" <sean@clipperadams.com> 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
-- 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 Fri, Jan 25, 2013 at 10:54:40AM +0100, Camillo Bruni wrote:
very nice! thanks! So that means all the FileSystem changes have been included?
I think so, yes. I'm not too familiar with using FileSystem yet, so let me know if I missed something. So far I have done the updates for all of OSProcess and CommandShell-Piping, but I have not yet done the rest of CommandShell. There is a lot of file system interaction in CommandShell, so that may take a while. But OSProcess is done, and class PipeableOSProcess in CommandShell-Piping is updated too. So that should be a help for many people. Dave
On 2013-01-25, at 05:14, "Sean P. DeNigris" <sean@clipperadams.com> 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
Thanks a lot david!!! Stef On Jan 24, 2013, at 10:38 PM, 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.
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
Perfect that is really great news! I will try it immediately. On 25 Jan 2013 15:08, "Stéphane Ducasse" <stephane.ducasse@inria.fr> wrote:
Thanks a lot david!!!
Stef
On Jan 24, 2013, at 10:38 PM, 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.
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
On 26 Jan 2013, at 1:59, "David T. Lewis" <lewis@mail.msen.com> wrote:
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
There's still value in tests that fail on Windows, and in an ideal world those folks who need OSProcess on Windows (all of them, surely!) could then go look at the CI job to see what works and what not, and submit patches to the maintainer! frank
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 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. Failing to find the plugin should not be an expected failure, but then all subsequent tests are expected to fail and are just noise. Actually the recent post on 'test dependencies' in Phexample looks like a good way to do this.
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
On Sun, Jan 27, 2013 at 01:11:07AM +0800, Ben Coman wrote:
David T. Lewis wrote:
On Sat, Jan 26, 2013 at 08:50:43AM +0800, Ben Coman wrote:
David T. Lewis wrote:
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.
Failing to find the plugin should not be an expected failure, but then all subsequent tests are expected to fail and are just noise. Actually the recent post on 'test dependencies' in Phexample looks like a good way to do this.
Now I understand what you mean. You're right. Personally I don't mind seeing all of the tests that are impacted by a problem like this, but I agree it's mostly noise at that point. Dave
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
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...
Thanks again, David. OSProcess & Piping are absolutely essential, and CommandShell is really cool. It's so important that we have them working well :) -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4666040.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I can write a configuration if you want. Stef 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
On Tue, Jan 29, 2013 at 01:45:27PM -0300, St?phane Ducasse wrote:
I can write a configuration if you want.
Stef
That would be great, thank you! Dave
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
Ok then I will give a try this evening. Stef On Jan 29, 2013, at 2:24 PM, David T. Lewis wrote:
On Tue, Jan 29, 2013 at 01:45:27PM -0300, St?phane Ducasse wrote:
I can write a configuration if you want.
Stef
That would be great, thank you!
Dave
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
I'm working on a configuration. I will let you know if it loads :) can you tell me a bit the dependencies between the package? Base Pipping Commands For now I will do it really simple. Stef 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
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
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
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
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.
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.
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
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
On Tue, Jan 29, 2013 at 10:54:55PM -0300, St?phane Ducasse wrote:
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.
Same for me. But first I will walk to town and have a hamburger and beer :) Dave
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
I published a new version of the badly named ConfigurationOfOSProcess. Next steps: - renaming it to ConfigurationOfCommandShell - explicit the dependency to OSProcess - Check what sean did and publish Stef On Jan 30, 2013, at 2:14 AM, David T. Lewis <lewis@mail.msen.com> 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.
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
David In fact Sean and others did a good job so I will update their configurations and publish them in the squeaksource repository and the MetaRepoForPharo20. I will let you know when you can test it. Stef
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
stephane ducasse wrote
I will update their configurations and publish them in the squeaksource repository and the MetaRepoForPharo20.
I fixed the configs to work on Pharo 1.4 and Pharo 2.0 and uploaded to sqs/MetaRepo... and ss3/MetaFor20... There are still some issues (like tests are failing because ReferenceStream doesn't exist, and scattered references to FileDirectory), but the core functionality seems to work. For example, I was able to do: PipeableOSProcess command: 'open http://www.google.com'. (PipeableOSProcess command: 'ls') output. in both 1.4 and 2.0, which is my standard metric of whether OSP is working :) -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669468.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Feb 12, 2013 at 08:13:39AM -0800, Sean P. DeNigris wrote:
stephane ducasse wrote
I will update their configurations and publish them in the squeaksource repository and the MetaRepoForPharo20.
I fixed the configs to work on Pharo 1.4 and Pharo 2.0 and uploaded to sqs/MetaRepo... and ss3/MetaFor20... There are still some issues (like tests are failing because ReferenceStream doesn't exist, and scattered references to FileDirectory), but the core functionality seems to work.
I thought that I got rid of all the explicit references to FileDirectory and ReferenceStream, so check to make sure you're using the latest version of OSProcess. Maybe I missed a few of the references, there were quite a few. Dave
For example, I was able to do: PipeableOSProcess command: 'open http://www.google.com'. (PipeableOSProcess command: 'ls') output. in both 1.4 and 2.0, which is my standard metric of whether OSP is working :)
-- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669468.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
normally On Feb 12, 2013, at 5:59 PM, David T. Lewis <lewis@mail.msen.com> wrote:
On Tue, Feb 12, 2013 at 08:13:39AM -0800, Sean P. DeNigris wrote:
stephane ducasse wrote
I will update their configurations and publish them in the squeaksource repository and the MetaRepoForPharo20.
I fixed the configs to work on Pharo 1.4 and Pharo 2.0 and uploaded to sqs/MetaRepo... and ss3/MetaFor20â¦
@sean what was the problem because I tested it several time on 1.4 and 2.0
There are still some issues (like tests are failing because ReferenceStream doesn't exist, and scattered references to FileDirectory), but the core functionality seems to work.
@David I took the latest version normally of all command and os packages.
stephane ducasse wrote
@sean what was the problem because I tested it several time on 1.4 and 2.0
The tests were failing due to FS differences between 1.4 and 2.0. I uploaded fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged release so we shouldn't change it). Also, I moved the dependency on the CommandShell version from the baseline (where I originally put it in error), to the versions. For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC into a #'squeak' one. -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Feb 13, 2013, at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
stephane ducasse wrote
@sean what was the problem because I tested it several time on 1.4 and 2.0
The tests were failing due to FS differences between 1.4 and 2.0. I uploaded fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged release so we shouldn't change it). Also, I moved the dependency on the CommandShell version from the baseline (where I originally put it in error), to the versions.
Nobody use this 4.5 so we could just modify it. Because 4.5.1 looks boring to me.
For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC into a #'squeak' one.
-- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 13 February 2013 16:03, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Feb 13, 2013, at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
stephane ducasse wrote
@sean what was the problem because I tested it several time on 1.4 and 2.0
The tests were failing due to FS differences between 1.4 and 2.0. I uploaded fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged release so we shouldn't change it). Also, I moved the dependency on the CommandShell version from the baseline (where I originally put it in error), to the versions.
Nobody use this 4.5 so we could just modify it. Because 4.5.1 looks boring to me.
As a general rule this is a very bad idea. The version number should allow you to say with certainty what's in an artifact. Just modifying it means that "4.5" tells you just about nothing about someone's setup when they say "4.5 is broken". frank
For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC into a #'squeak' one.
-- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Feb 13, 2013, at 6:28 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 13 February 2013 16:03, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Feb 13, 2013, at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
stephane ducasse wrote
@sean what was the problem because I tested it several time on 1.4 and 2.0
The tests were failing due to FS differences between 1.4 and 2.0. I uploaded fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged release so we shouldn't change it). Also, I moved the dependency on the CommandShell version from the baseline (where I originally put it in error), to the versions.
Nobody use this 4.5 so we could just modify it. Because 4.5.1 looks boring to me.
As a general rule this is a very bad idea. The version number should allow you to say with certainty what's in an artifact. Just modifying it means that "4.5" tells you just about nothing about someone's setup when they say "4.5 is broken".
frank I do not really need a lesson. ***I*** created the wrong 4.5 version so probably nobody could reliably use it. So what is the point to get a major version broken. I do not want to always have to remember that I should use 4.5.1.1 better 4.5 Stef
frank
For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC into a #'squeak' one.
-- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 13 February 2013 19:35, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Feb 13, 2013, at 6:28 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 13 February 2013 16:03, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Feb 13, 2013, at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
stephane ducasse wrote
@sean what was the problem because I tested it several time on 1.4 and 2.0
The tests were failing due to FS differences between 1.4 and 2.0. I uploaded fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged release so we shouldn't change it). Also, I moved the dependency on the CommandShell version from the baseline (where I originally put it in error), to the versions.
Nobody use this 4.5 so we could just modify it. Because 4.5.1 looks boring to me.
As a general rule this is a very bad idea. The version number should allow you to say with certainty what's in an artifact. Just modifying it means that "4.5" tells you just about nothing about someone's setup when they say "4.5 is broken".
frank I do not really need a lesson. ***I*** created the wrong 4.5 version so probably nobody could reliably use it. So what is the point to get a major version broken. I do not want to always have to remember that I should use 4.5.1.1 better 4.5
Look, it's your software, so it's your call. If it was _my_ software - and it's not - I'd just figure out how I managed to release something broken, fix that, and release a 4.5.1. It's not like you're going to run out of version numbers. frank
Stef
frank
For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC into a #'squeak' one.
-- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Frank Shearar-3 wrote
As a general rule this is a very bad idea
+1. It's a bad habit to get into and subverts part of MetaC's usefulness, as Frank described. In fact, I find 4.5.1 very exciting, because it uses semantic versioning to communicate a whole world to the user without a long comment. Given x.y.z, z is a bug-fix release with no additional functionality -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669711.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
David T. Lewis wrote
I thought that I got rid of all the explicit references to FileDirectory and ReferenceStream, so check to make sure you're using the latest version of OSProcess. Maybe I missed a few of the references, there were quite a few.
I think you're right... don't know what I was looking at :/ The test errors I saw in 1.4 were due to FS differences between 1.4 and 2.0: - In 1.4 #ensureDeleted must be #delete - The only way to get the file delimiter that works in both 1.4 and 2.0 is "(Smalltalk at: #DiskStore) current perform: #delimiter" i.e. the send to #current was added I made the changes and uploaded to OSP and CommandShell sqs repos. It's nice to avoid Platform packages, and the conditionals are currently quarantined on the class-side of OSProcess, but Metacello would remove them from the codebase completely, just leaving a clean message send, where three branches had been... just sayin ;) - Sean -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669670.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Jan 29, 2013 at 09:34:37PM -0300, 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?
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.
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.
- 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
Oops I missed those, I meant to make compatibility methods for them. I don't want to make it a String extension because then it would be an override in Squeak. I'll probably do something like CommandShell class>>withBlanksTrimmed: aString which will work in both.
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. Thanks a lot! Dave
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
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!
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
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
Camillo Bruni-3 wrote
- full smalltalk implementation (no more ruby)
Yay!!!! -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4663964.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Camillo Bruni-3 wrote
I had a sudden urge to program something so I revived the monkey (partly) ... the only thing missing are the couple of changes I proposed for the main image:
Those three issues have all been integrated. Can we unleash the monkey now?! -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4665734.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
The build service got accidentally deleted, so we will have to readd that thing first :) On 27 Jan 2013 18:12, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Camillo Bruni-3 wrote
I had a sudden urge to program something so I revived the monkey (partly) ... the only thing missing are the couple of changes I proposed for the main image:
Those three issues have all been integrated. Can we unleash the monkey now?!
-- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4665734.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Camillo Bruni-3 wrote
The build service got accidentally deleted, so we will have to readd that thing first :)
Do you want me to open an issue? -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4665739.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (13)
-
Ben Coman -
Bruni camillo -
Camillo Bruni
-
Damien Cassou -
David T. Lewis -
Esteban Lorenzano -
Frank Shearar -
Goubier Thierry -
Pavel Krivanek -
Sean P. DeNigris -
stephane ducasse -
Stéphane Ducasse -
Sven Van Caekenberghe