On Sun, Feb 19, 2006 at 12:23:26PM -0800, John M McIntosh wrote:
> Well the OSProcess plugin wouldn't quite work with the carbon vm  
> because of:
> 
> a) x/11 (that was solvable by just commenting out a few things)
> b) unix path names. (that was harder).
> c) bundle versus unix library.
> 
> 
> I'm working on (c) at the moment,  (b) is solved by using a 3.8.10 VM

Hi John,
Problem a) should be fixed in recent OSProcess also.

Martin Snelgrove sent me some OSProcess test results a while back,
running on the following:
wms running OSProcess unit tests 19 October 2005 11:18:36 pm
OSProcess platformName => unix
OSProcess platformSubtype => powerpc
OSProcess osVersion => darwin7.8.0
OSProcess vmVersion => Squeak3.7 of '4 September 2004' [latest update: #5989]

The #forkSqueak methods were all working in the unit tests, so
I think that forking a headless Squeak will work on OS X:

#testForkHeadlessSqueakAndDo->1 run, 1 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes
#testForkHeadlessSqueakAndDoThenQuit->1 run, 1 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes
#testForkSqueak->1 run, 1 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes
#testForkSqueakAndDo->1 run, 1 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes
#testForkSqueakAndDoThenQuit->1 run, 1 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes

Quite honestly I don't know the difference between a darwin and
a carbon (I thought carbon was for the brushes on my harley's
generator) but I was pleasantly surprised that #forkSqueak
was working on at least some Mac flavors, so I think this is a
doable thing.
 
> At this time I need some folks to help in recompiling and testing the  
> OSProcess plugin to support the mac carbon vm.

If you find a volunteer for this, please CC me and I'll provide
whatever remote support I can. I don't have a Mac to work with,
but OSProcess class>>allTestResults produces some useful output
that may allow me to help.
 
> I'll note the carbon VM actually runs a number of OS threads at the   
> moment.
> 
> 1) For updating the low resolution clock every 1/60 of a second
> 2) For managing the mouse/keyboard/event input via carbon event manager.
> 3) The interpreter loop
> 4) OS thread for input/output  (created by carbon logic)
> 5) OS thread for sound  (created by carbon logic)
> 6) Lots of other threads if you use quicktime via FFI.

Here I suspect I have some work to do. OSPP does not try to account
for pthreads, which means that my signal handling is probably not
going to work right. There may be other things that need to be
pthread-aware also.

I don't know if pthreads are supported on all unix platforms (I
guess I am a little suspicious of anything called "posix standard"),
but I suppose it's pretty generic stuff nowadays. Which means I
probably aught to RTMF and add the required support in OSPP.

> However since the carbon VM doesn't run headless forking the VM I'll  
> guess is a problem... Mind starting up multiple headless unix squeak  
> VM managed by a headful squeak VM
> could be doable.

Definitely doable, as it seems to already work on some OS X flavors.

Dave