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