Ross Boylan wrote:
> On Fri, 2010-09-03 at 19:55 -0400, David T. Lewis wrote:
>   
>> On Fri, Sep 03, 2010 at 02:35:53PM -0700, Ross Boylan wrote:
>>     
>>> On Fri, 2010-09-03 at 16:22 -0400, David T. Lewis wrote:
>>>       
>>>>> Here's the  code I put in ProtoObject
>>>>> ifNotNilDo: ifNotNilBlock
>>>>>       "RB adds for back compatibility"
>>>>>       "Evaluate the block, unless I'm == nil (q.v.)"
>>>>>
>>>>>       ^ ifNotNilBlock valueWithPossibleArgs: {self}
>>>>>           
>>> Duh.  I also need, in UndefinedObject in Cuis
>>> ifNotNilDo: aBlock
>>> 	"RB back compatibility"
>>> 	^ self
>>>
>>> Of course the right way is to change the OSProcess code to use something
>>> more portable than ifNotNilDo:.
>>>       
>> Hi Ross,
>>
>> I have updated both OSProcess and CommandShell on SqueakSource to address
>> all of the #ifNotNilDo: issues for Cuis, as well as the #fork issues that
>> you previously addressed. I think that I've captured all of your fixes.
>> Thank you *very* much for this.
>>
>> I did not actually load into Cuis to check, but a lot of the issues
>> were in the unit tests so I expect they will run properly now (knock
>> wood).
>>
>> And I have to give a grudging nod of appreciation to Juan for forcing
>> me to address the #ifNotNilDo: concerns. At first I was annoyed that I
>> had to rewrite a lot of code, but I have to admit that by the time I
>> was done I had cleaned out a lot of ugly cruft from OSProcess, so
>> I guess once again Juan has got it right :)
>>
>> Dave
>>     
> The latest changeset files in cleanly to a new Cuis2.7 image (in
> particular, I did not add any hacks for ifNotNilDo:).  All 190 tests
> passed the first 2 or 3 times I ran the tests, but, after running the
> 2.6 tests below, I got various failures in 2.7.
> UnixProcessUnixFileLockingTestCase>>testCooperatingProcesses02 failed
> once, and then
> UnixProcessUnixFileLockingTestCase>>testCooperatingProcesses04 the next
> time.
>
> The 2.6 and 2.7 tests were in different directories.  In the initial 2.7
> tests only that image was up, while in all later cases both were up. 
> The 2.7 image seems to do somewhat better than 2.6.  When I start from a
> fresh Cuis2.6 image, I get non-deterministic failures.  The first test
> suite run hung up, from memory at UnixProcessTestCase>>testCatAFile.
> The last two runs failed in
> UnixProcessWin32FileLockingTestCase>>testCooperatingProcesses04.
>
> I shut down the 2.7 image and tried running just the 2.6.  There was one
> failure, in
> UnixProcessUnixFileLockingTestCase>>testCooperatingProcesses04.
>
> Juan, do you have any ideas what changes between 2.6 and 2.7 might be
> relevant, or what might be causing these failure patterns?
>
> Ross

I don't think that any difference between Cuis 2.6 and 2.7 could be 
related to this. Most changes were in UI. The are two sets of kernel 
changes. One is  in numbers, where Cuis 2.7 is much closer to Squeak 
(lots of cool stuff from Nicolas), and all the tests pass. The other is 
Compiler / Decompiler / Debugger, and again, what I did, essentially, is 
to update Cuis to latest Squeak's. I think it is quite unlikely that 
there is any relation with OSProcess. You can check the tests to see if 
they use the Compiler or Decompiler, though.

I'd say that the OS scheduling of OS processes could be the cause of 
non-deterministic failures. Especially if you're running 2 images at the 
same time. I'd try to isolate possible causes, and make the process 
reproducible. I.e., set up all the images to test (various Squeak, 
Pharo, Cuis, etc), use the same vm, do a reboot of the os, do the tests 
on one image, writing on paper each step so it can be reproduced exactly 
(noting event other running applications on the machine, which should be 
kept to an absolute minimum). Write down the results. Then reboot the 
machine and do exactly the same on the next image. And so on. I know, 
this is terribly tedious. But proper testing requires a lot of discipline.

The alternative, is not testing, but debugging. Then you need to 
understand many internals of OSProcess and the tests being run. It will 
be quite some work too. But you'll end understanding it all, and fixing 
any issues.

Good luck!

Cheers,
Juan Vuletich