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

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

On 7 July 2012 05:48, Sean P. DeNigris <[hidden email]> wrote: so someone must update it :)


> --
> View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p4638936.html
> 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?! ;-)

On Fri, Jul 06, 2012 at 08:48:08PM -0700, Sean P. DeNigris wrote:
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 <[hidden email]> wrote: 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.

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:

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