[Vm-dev] Building OSProcessPlugin on macs

[John McIntosh]

I"ve compiled the aioPlugin in the past.

Some of the tests will fail because you cann't fork the VM into two
processes because the UI is tied to the main pthread for the App, so a
fork leads to insanity & a core dump.
Otherwise since OS-X is a Unix machine it should run all the other test cases.

On Wed, Jul 6, 2011 at 8:43 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>
> 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.
>



-- 
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================