[Pharo-project] OSProcess test failures in Pharo 1.4
The few that I checked had to do with stdout being closed... OSProcess-dtl.70 Mac Lion Also tried running with vm from command line cc/ David Lewis UnixProcessAccessorTestCase>>#testRedirectStdOutTo UnixProcessTestCase>>#testCatAFile UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDo UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDoThenQuit UnixProcessTestCase>>#testClassForkSqueak UnixProcessTestCase>>#testClassForkSqueakAndDo UnixProcessTestCase>>#testClassForkSqueakAndDoThenQuit UnixProcessTestCase>>#testForkHeadlessSqueakAndDo UnixProcessTestCase>>#testForkHeadlessSqueakAndDoThenQuit UnixProcessTestCase>>#testForkSqueak UnixProcessTestCase>>#testForkSqueakAndDo UnixProcessTestCase>>#testForkSqueakAndDoThenQuit UnixProcessTestCase>>#testHeadlessChild UnixProcessTestCase>>#testRunCommand UnixProcessTestCase>>#testSpawnTenHeadlessChildren UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses01 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses02 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses03 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses04 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses05 UnixProcessUnixFileLockingTestCase>>#testFailFileLockOnLockedFile UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedOverlappedRegion UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedRegion UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedSupersetRegion UnixProcessUnixFileLockingTestCase>>#testFailRegionLockOnLockedFile UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite01 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite02 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite03 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite04 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite05 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite06 UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead01 UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead02 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite01 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite02 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite03 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite04 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite05 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite06 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite07 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite08 UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses01 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses02 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses03 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses04 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses05 UnixProcessWin32FileLockingTestCase>>#testFailFileLockOnLockedFile UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedOverlappedRegion UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedRegion UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedSupersetRegion UnixProcessWin32FileLockingTestCase>>#testFailRegionLockOnLockedFile UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite01 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite02 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite03 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite04 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite05 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite06 UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead01 UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead02 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite01 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite02 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite03 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite04 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite05 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite06 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite07 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite08 UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion
On Fri, Jul 06, 2012 at 04:49:35PM -0400, DeNigris Sean wrote:
The few that I checked had to do with stdout being closed...
OSProcess-dtl.70 Mac Lion Also tried running with vm from command line
cc/ David Lewis
OSProcess and CommandShell tests run successfully on Pharo 1.4 with an interpreter VM on Linux. Many of the tests rely on #forkSqueak to set up the test conditions, and these tests may not run on VMs that cannot fully support #forkSqueak (which is tricky to do when pthreads are involved in the VM). But note that the test failures do not mean that e.g. file locking is broken, they just mean that the file locking tests will not succeed if forkSqueak is not available on the platform. There might be some plugin version issues too. The testRedirectStdOutTo failure happened only when I ran the test on a Cog VM so I suspect this may reflect an out of date plugin. Sorry I cannot check now to be sure, but the failure happens with this version: OSProcess accessor osppModuleVersionString ==> '4.3.3 Cog' And no failure with this: OSProcess accessor osppModuleVersionString ==> '4.4.11' Dave
UnixProcessAccessorTestCase>>#testRedirectStdOutTo UnixProcessTestCase>>#testCatAFile UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDo UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDoThenQuit UnixProcessTestCase>>#testClassForkSqueak UnixProcessTestCase>>#testClassForkSqueakAndDo UnixProcessTestCase>>#testClassForkSqueakAndDoThenQuit UnixProcessTestCase>>#testForkHeadlessSqueakAndDo UnixProcessTestCase>>#testForkHeadlessSqueakAndDoThenQuit UnixProcessTestCase>>#testForkSqueak UnixProcessTestCase>>#testForkSqueakAndDo UnixProcessTestCase>>#testForkSqueakAndDoThenQuit UnixProcessTestCase>>#testHeadlessChild UnixProcessTestCase>>#testRunCommand UnixProcessTestCase>>#testSpawnTenHeadlessChildren UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses01 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses02 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses03 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses04 UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses05 UnixProcessUnixFileLockingTestCase>>#testFailFileLockOnLockedFile UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedOverlappedRegion UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedRegion UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedSupersetRegion UnixProcessUnixFileLockingTestCase>>#testFailRegionLockOnLockedFile UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite01 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite02 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite03 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite04 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite05 UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite06 UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead01 UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead02 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite01 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite02 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite03 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite04 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite05 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite06 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite07 UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite08 UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses01 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses02 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses03 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses04 UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses05 UnixProcessWin32FileLockingTestCase>>#testFailFileLockOnLockedFile UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedOverlappedRegion UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedRegion UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedSupersetRegion UnixProcessWin32FileLockingTestCase>>#testFailRegionLockOnLockedFile UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite01 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite02 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite03 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite04 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite05 UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite06 UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead01 UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead02 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite01 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite02 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite03 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite04 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite05 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite06 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite07 UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite08 UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion
David T. Lewis wrote
There might be some plugin version issues too. ... OSProcess accessor osppModuleVersionString ==> '4.3.3 Cog'
My failing image was running on the latest Jit Cocoa Cog VM from Jenkins and had the same outdated plugin -- View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p4638936... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 7 July 2012 05:48, Sean P. DeNigris <sean@clipperadams.com> wrote:
David T. Lewis wrote
There might be some plugin version issues too. ... OSProcess accessor osppModuleVersionString ==> '4.3.3 Cog'
My failing image was running on the latest Jit Cocoa Cog VM from Jenkins and had the same outdated plugin
so someone must update it :)
-- View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p4638936... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
so someone must update it :)
Yes, but how and from where?! ;-) -- View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p4638954... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Fri, Jul 06, 2012 at 08:48:08PM -0700, Sean P. DeNigris wrote:
David T. Lewis wrote
There might be some plugin version issues too. ... OSProcess accessor osppModuleVersionString ==> '4.3.3 Cog'
My failing image was running on the latest Jit Cocoa Cog VM from Jenkins and had the same outdated plugin
It's not necessarily out of date, it's just a different version from my "trunk" OSProcessPlugin. I use the versionString to keep track of the change level. '4.3.3' means that it came from one of the files in the oscog branch, but I'm not sure which one. I should also say that is it entirely possible that there are timing-related bugs in the OSProcess test suite that get exposed by Cog, which is much faster than an interpreter VM. I guess the way to find out would be to build a Cog VM with the "trunk" OSPP and see if the problems go away. I cannot try this right now but I'll look into it in a couple of days if no one else gets to it first (we have a lot of new people who know how to build VMs these days, so someone should give it a try, hint, hint ;) Dave
On 7 July 2012 15:37, David T. Lewis <lewis@mail.msen.com> wrote:
On Fri, Jul 06, 2012 at 08:48:08PM -0700, Sean P. DeNigris wrote:
David T. Lewis wrote
There might be some plugin version issues too. ... OSProcess accessor osppModuleVersionString ==> '4.3.3 Cog'
My failing image was running on the latest Jit Cocoa Cog VM from Jenkins and had the same outdated plugin
It's not necessarily out of date, it's just a different version from my "trunk" OSProcessPlugin. I use the versionString to keep track of the change level. '4.3.3' means that it came from one of the files in the oscog branch, but I'm not sure which one.
I should also say that is it entirely possible that there are timing-related bugs in the OSProcess test suite that get exposed by Cog, which is much faster than an interpreter VM. I guess the way to find out would be to build a Cog VM with the "trunk" OSPP and see if the problems go away. I cannot try this right now but I'll look into it in a couple of days if no one else gets to it first (we have a lot of new people who know how to build VMs these days, so someone should give it a try, hint, hint ;)
yeah.. it is a matter of changing the package version in configurationofcog
Dave
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
yeah.. it is a matter of changing the package version in configurationofcog
VMConstruction-Plugins-OSProcessPlugin.oscog-eem.35 corresponds to OSProcessPlugin 4.4.11 ConfigurationOfCog has three versions blessed development: 4.7 - loaded by the stable version of ConfigurationOfPharoVM 4.8 - declared as the development version for #common 4.9 Since ConfigurationOfPharoVM is loading 4.7 explicitly already, it seems we should change it from development to release, so that it is clear that it should not be changed anymore [1]. Also, since 4.8 is still blessed development, why don't we merge the changes from 4.9 into 4.8 and remove 4.9? If you agree with these changes, is 4.8 ready to be loaded by ConfigurationOfPharoVM stable? Let me know... Sean [1] After many conversations with Dale, it has sunk in that once a version is released, it should not be changed. -- View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p4639010... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
mmm... probably, but PharoVM needs an update too (btw, PharoVM is just a branded version of the cogvm, not more) Esteban On Jul 7, 2012, at 9:18 PM, Sean P. DeNigris wrote:
Igor Stasenko wrote
yeah.. it is a matter of changing the package version in configurationofcog
VMConstruction-Plugins-OSProcessPlugin.oscog-eem.35 corresponds to OSProcessPlugin 4.4.11
ConfigurationOfCog has three versions blessed development: 4.7 - loaded by the stable version of ConfigurationOfPharoVM 4.8 - declared as the development version for #common 4.9
Since ConfigurationOfPharoVM is loading 4.7 explicitly already, it seems we should change it from development to release, so that it is clear that it should not be changed anymore [1].
Also, since 4.8 is still blessed development, why don't we merge the changes from 4.9 into 4.8 and remove 4.9?
If you agree with these changes, is 4.8 ready to be loaded by ConfigurationOfPharoVM stable?
Let me know... Sean
[1] After many conversations with Dale, it has sunk in that once a version is released, it should not be changed.
-- View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p4639010... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
EstebanLM wrote
mmm... probably, but PharoVM needs an update too
Please check this carefully. The changes are simple, but I'm not sure I fully understand the standard procedure here. Issue 6302: Update OSProcess Plugin http://code.google.com/p/pharo/issues/detail?id=6302 Fix in inbox: SLICE-Issue-6302-Update-OSProcess-Plugin-SeanDeNigris.1 ConfigurationOfCog * v. 4.7 - bless as release * v. 4.8 - bless as release (will be used by updated ConfigurationOfPharoVM) - merge in changes from v. 4.9 - import v. 4.7 instead of baseline and remove duplication * v. 4.9 - remove ConfigurationOfPharoVM - change stable version for #'pharo1.4.x' to version: '2.0-2', which loads v. 4.8 of ConfigurationOfCog Sean p.s. I forgot to mention in the commit comment that 4.8 updates the OSProcess plugin to 4.4.11 -- View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p4639041... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (5)
-
David T. Lewis -
DeNigris Sean -
Esteban Lorenzano -
Igor Stasenko -
Sean P. DeNigris