[Vm-dev] Building OSProcessPlugin on macs

[David T. Lewis]

On Wed, Jul 06, 2011 at 05:53:44PM +0200, Igor Stasenko wrote:
>  
> I trying to make a working OSProcessPlugin for mac vms.
> 
> Okay, i loaded the
> VMConstruction-Plugins-OSProcessPlugin.oscog-eem.30
> 
> and then building VM with:
> 
> StackMacOSConfig new
> 	addExternalPlugins: #( FT2Plugin );
> 	addInternalPlugins: #( UnixOSProcessPlugin );
> 	generateSources; generate.
> 
> (this is new api which i recently added to make it easier to generate
> VM with custom set of plugins)
> 
> It builds fine as internal plugin (fails as external one of course,
> because no access to these variables:
> 
> Linking C shared library
> /Users/sig/projects/cog/sig-cog/results/StackVM.app/Contents/Resources/libUnixOSProcessPlugin.dylib
> Undefined symbols:
>   "_envVec", referenced from:
>       _envVec$non_lazy_ptr in UnixOSProcessPlugin.c.o
>      (maybe you meant: _envVec$non_lazy_ptr)
>   "_primitiveFail", referenced from:
>       _primitiveIsAtEndOfFile in UnixOSProcessPlugin.c.o
>   "_argCnt", referenced from:
>       _argCnt$non_lazy_ptr in UnixOSProcessPlugin.c.o
>      (maybe you meant: _argCnt$non_lazy_ptr)
>   "_argVec", referenced from:
>       _argVec$non_lazy_ptr in UnixOSProcessPlugin.c.o
>      (maybe you meant: _argVec$non_lazy_ptr)
>   "_sqFileStdioHandlesInto", referenced from:
>       _getStdHandle in UnixOSProcessPlugin.c.o
> ld: symbol(s) not found
> 
> Remember we're discussed this, and i think we should add an API
> function for this, instead of relying on linker to bind those symbols
> at run time.
> Because this is too brittle and vague for external plugin.

I think this is just controlled by a compiler option on Mac. I don't
have a link to the discussion, but perhaps Esteban will remember the
details.

> 
> Okay, at least internal one builds, but then when i run tests.. a
> dozen of them failing.
> 
> UnixProcessTestCase:
> 18 run, 3 passes, 0 expected failures, 14 failures, 1 errors, 0
> unexpected passes
> 
> UnixProcessFileLockTestCase
> 23 run, 23 passes, 0 expected failures, 0 failures, 0 errors, 0
> unexpected passes
> 
> UnixProcessAccessorTestCase
> 46 run, 46 passes, 0 expected failures, 0 failures, 0 errors, 0
> unexpected passes
> 
> OSPipeTestCase
> 11 run, 11 passes, 0 expected failures, 0 failures, 0 errors, 0
> unexpected passes
> 
> UnixProcessUnixFileLockingTestCase
> 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0
> unexpected passes
> 
> UnixProcessWin32FileLockingTestCase
> 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0
> unexpected passes

Many of the tests rely on #forkSqueak, which in turn relies on
controlling the display with XDisplayControlPlugin, which is not
available on Mac.

> 
> Maybe i'm using wrong package for image-side code?
> I loaded OSProcess package,
> but i see there are separate OSProcess-Base , OSProcess-Mac, OSProcess-Tests etc
> 
> are they identical (since i see that David updating both), or it is
> better to use splitted versions?
> 

Using the OSProcess package is fine. I split it apart into sub-packages
because "modularity is good so more modularity must be better". Bad
idea, it did not help anything and now I have to maintain *all* those
sub-packages in addition to the OSProcess package. In any case, loading
the most recent OSProcess is the right thing to do.

Speaking of modularity, I long ago split OSProcessPlugin into
OSProcessPlugin + AioPlugin + XDisplayControlPlugin. This actually
*was* a good idea. But if I could ask a favor, could you please
try compiling AioPlugin for a Mac VM and see if it works? I expect
that it probably will work because the Mac VM uses the aio code
from the Unix VM, but I don't think that it has ever been tried.
The unit tests for OSProcess should confirm this (see AioEventHandlerTestCase).

Thanks!
Dave

> @Esteban, i see that you also making UnixOSProcessPlugin, but i wonder
> what is this:
> 
> configureUnixOSProcessPlugin: maker
> 	super configureHostWindowPlugin: maker.
> 	maker includeDirectories: '${platformsDir}/Cross/plugins/SocketPlugin'.
> 
> 
> why it uses rather unrelated configureHostWindowPlugin: there?
> 
> Because mine (which for Carbon builds) are following:
> 
> configureUnixOSProcessPlugin: maker
> 	"extra rules for UnixOSProcessPlugin"
> 
> 	maker includeDirectories: '${crossDir}/plugins/FilePlugin'.
> 
> I am missing something? Please let me know.
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.