Oh fine, stupid tool sets, update your VMMaker image with: Name: Alien-VMMaker-Plugins-John M McIntosh.8 Author: John M McIntosh Time: 20 February 2010, 1:16:02 pm UUID: a8e7e044-bf22-4013-85b7-c70d2081cd4e Ancestors: Alien-VMMaker-Plugins-John M McIntosh.7 nil is null is (void*) 0 YES? Well not in non macintosh build chains since nil is UNDEFINED. Fine change nil to null that is in sq.h On 2010-02-20, at 11:20 AM, Javier Pimás wrote:

nice! this is way better, but I still have this:

/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/IA32ABI/IA32ABI.c: In function ‘primCallOutDoubleReturn’: -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

On 2010-02-20, at 3:02 PM, Javier Pimás wrote:

take it easy man, you look a bit nervous ;) . It is compiling now!!! but....

It must be all the objective-c compiling i'm doing at the moment.....

Alien compiled fine, but here I'm having some other problems, not related to alien itself, but to the vm building.

I had to add B3DAccelerator plugin because there were some errors, and now these errors mutated to:

Linking C executable squeakvm B3DAcceleratorPlugin/libB3DAcceleratorPlugin.a(sqOpenGLRenderer.c.o): In function `glRenderVertexBuffer': /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:846: undefined reference to `glColorMaterial' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:847: undefined reference to `glGetError' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:848: undefined reference to `glEnable' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:849: undefined reference to `glGetError'

...

/home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:159: undefined reference to `glLightModelfv' /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:160: undefined reference to `glGetError' collect2: ld returned 1 exit status make[2]: *** [squeakvm] Error 1 make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 make: *** [all] Error 2

[ 34%] Building C object SocketPlugin/CMakeFiles/SocketPlugin.dir/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c.o /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘netAddressToInt’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: (Each undeclared identifier is reported only once /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: for each function it appears in.)

Odd I wonder what is wrong since somewhere *most* of humanity has nil defined somewhere in some header. But you don't seem to. Toss a #define nil (void*) 0 in your sq.h However in looking at primitiveResolverGetAddressInfoResult there is no 'nil', it has 'null' Could we see your since I don't see any 'nil' EXPORT(sqInt) primitiveResolverGetAddressInfoResult(void) { sqInt addrSize; char *socketAddress; interpreterProxy->success(interpreterProxy->isBytes(interpreterProxy->stackValue(0))); socketAddress = ((char *) (interpreterProxy->firstIndexableField(interpreterProxy->stackValue(0)))); if (interpreterProxy->failed()) { return null; } if (!(interpreterProxy->failed())) { addrSize = interpreterProxy->byteSizeOf((oopForPointer( socketAddress ) - 4)); sqResolverGetAddressInfoResultSize(socketAddress, addrSize); } if (interpreterProxy->failed()) { return null; } interpreterProxy->pop(1); return null; } -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Ok, well that looks like a problem with VMMaker, so I'll cc the vm-dev list Note the addrSize = interpreterProxy->byteSizeOf((oopForPointer( socketAddress ) - nil)); where as I have

addrSize = interpreterProxy->byteSizeOf((oopForPointer( socketAddress ) - 4));

So I think the current VMMaker build process is broken? Fortunately it won't compile so the person can't get to the point of having the VM crash. On 2010-02-20, at 3:47 PM, Javier Pimás wrote:

mine uses it. I generated this from an image that I crated this afternoon, with RC2 and latest VMMaker from monticello. It says:

EXPORT(sqInt) primitiveResolverGetAddressInfoResult(void) { sqInt addrSize; char *socketAddress;

interpreterProxy->success(interpreterProxy->isBytes(interpreterProxy->stackValue(0))); socketAddress = ((char *) (interpreterProxy->firstIndexableField(interpreterProxy->stackValue(0)))); if (interpreterProxy->failed()) { return null; } if (!(interpreterProxy->failed())) { addrSize = interpreterProxy->byteSizeOf((oopForPointer( socketAddress ) - nil)); sqResolverGetAddressInfoResultSize(socketAddress, addrSize); } if (interpreterProxy->failed()) { return null; } interpreterProxy->pop(1); return null; }

Regards, Javier.

On Sat, Feb 20, 2010 at 8:34 PM, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:

On 2010-02-20, at 3:02 PM, Javier Pimás wrote:

...

take it easy man, you look a bit nervous ;) . It is compiling now!!! but....

It must be all the objective-c compiling i'm doing at the moment.....

...

Alien compiled fine, but here I'm having some other problems, not related to alien itself, but to the vm building.

I had to add B3DAccelerator plugin because there were some errors, and now these errors mutated to:

Linking C executable squeakvm B3DAcceleratorPlugin/libB3DAcceleratorPlugin.a(sqOpenGLRenderer.c.o): In function `glRenderVertexBuffer': /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:846: undefined reference to `glColorMaterial' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:847: undefined reference to `glGetError' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:848: undefined reference to `glEnable' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:849: undefined reference to `glGetError'

...

/home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:159: undefined reference to `glLightModelfv' /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:160: undefined reference to `glGetError' collect2: ld returned 1 exit status make[2]: *** [squeakvm] Error 1 make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 make: *** [all] Error 2

...

[ 34%] Building C object SocketPlugin/CMakeFiles/SocketPlugin.dir/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c.o /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘netAddressToInt’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: (Each undeclared identifier is reported only once /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: for each function it appears in.)

Odd I wonder what is wrong since somewhere *most* of humanity has nil defined somewhere in some header. But you don't seem to. Toss a #define nil (void*) 0 in your sq.h

However in looking at primitiveResolverGetAddressInfoResult there is no 'nil', it has 'null' Could we see your since I don't see any 'nil'

EXPORT(sqInt) primitiveResolverGetAddressInfoResult(void) { sqInt addrSize; char *socketAddress;

interpreterProxy->success(interpreterProxy->isBytes(interpreterProxy->stackValue(0))); socketAddress = ((char *) (interpreterProxy->firstIndexableField(interpreterProxy->stackValue(0)))); if (interpreterProxy->failed()) { return null; } if (!(interpreterProxy->failed())) { addrSize = interpreterProxy->byteSizeOf((oopForPointer( socketAddress ) - 4)); sqResolverGetAddressInfoResultSize(socketAddress, addrSize); } if (interpreterProxy->failed()) { return null; } interpreterProxy->pop(1); return null; }

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

-- Javier Pimás Ciudad de Buenos Aires

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

May be a dab initialize of the variable "WordPer..." On Feb 21, 2010, at 1:19 AM, Levente Uzonyi wrote:

On Sat, 20 Feb 2010, John M McIntosh wrote:

...

So I think the current VMMaker build process is broken?

In Squeak I get the expected line (using SlangBrowser and VMMaker-ar.158): addrSize = interpreterProxy->byteSizeOf((oopForPointer( socketAddress ) - 4));

So I guess it's a Pharo issue.

Levente

...

Fortunately it won't compile so the person can't get to the point of having the VM crash.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Thanks! That did the trick! Regards, Javier. On Sun, Feb 21, 2010 at 1:20 PM, David T. Lewis <lewis@mail.msen.com> wrote:

On Sun, Feb 21, 2010 at 01:19:36AM +0100, Levente Uzonyi wrote:

...

On Sat, 20 Feb 2010, John M McIntosh wrote:

...

So I think the current VMMaker build process is broken?

In Squeak I get the expected line (using SlangBrowser and VMMaker-ar.158): addrSize = interpreterProxy->byteSizeOf((oopForPointer( socketAddress ) - 4));

So I guess it's a Pharo issue.

It is definitely Pharo-related, but I can't quite spot the source of the problem.

In a Pharo image:

ObjectMemory baseHeaderSize ==> nil ObjectMemory bytesPerWord ==> nil

That is the reason for the incorrect code generation.

If you evaluate this, the object memory constants will be set up properly:

ObjectMemory initializeWithBytesToWord: Smalltalk wordSize

At that point, I expect that the code generation problem will be probably be fixed.

What I can't figure out is why this is not being initialized properly in a Pharo image. I'm fumbling my way through this with a borrowed computer (out of town this weekend, forgot to bring my laptop) and limited expertise with Pharo, so maybe someone can figure it out from the above clues.

HTH, Dave

-- Javier Pimás Ciudad de Buenos Aires

Solved the other problem, now I'm back to Alien. There are more issues. There are some missing functions: Linking C executable squeakvm CMakeFiles/squeakvm.dir/home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c.o: In function `sqGetInterpreterProxy': /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:358: undefined reference to `internalIsImmutable' /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:359: undefined reference to `internalIsMutable' /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:360: undefined reference to `primitiveFailFor' /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:361: undefined reference to `classAlien' /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:362: undefined reference to `getStackPointer' /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:363: undefined reference to `sendInvokeCallbackStackRegistersJmpbuf' /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:364: undefined reference to `reestablishContextPriorToCallback' /home/javier/st/squeak-svn/platforms/Cross/vm/sqVirtualMachine.c:365: undefined reference to `classUnsafeAlien' collect2: ld returned 1 exit status make[2]: *** [squeakvm] Error 1 make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 make: *** [all] Error 2 I'm so close... Thanks, Javier. On Sat, Feb 20, 2010 at 8:02 PM, Javier Pimás <elpochodelagente@gmail.com>wrote:

take it easy man, you look a bit nervous ;) . It is compiling now!!! but....

Alien compiled fine, but here I'm having some other problems, not related to alien itself, but to the vm building.

I had to add B3DAccelerator plugin because there were some errors, and now these errors mutated to:

Linking C executable squeakvm

B3DAcceleratorPlugin/libB3DAcceleratorPlugin.a(sqOpenGLRenderer.c.o): In function `glRenderVertexBuffer':

/home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:846: undefined reference to `glColorMaterial' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:847: undefined reference to `glGetError' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:848: undefined reference to `glEnable' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:849: undefined reference to `glGetError'

...

/home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:159: undefined reference to `glLightModelfv' /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:160: undefined reference to `glGetError' collect2: ld returned 1 exit status make[2]: *** [squeakvm] Error 1 make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 make: *** [all] Error 2

I think it should be linking to opengl lib but it isn't, maybe?. I also read in other thread that SocketPlugin is necesary but it didn't compile either. It said:

[ 34%] Building C object SocketPlugin/CMakeFiles/SocketPlugin.dir/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c.o

/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘netAddressToInt’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: (Each undeclared identifier is reported only once /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:206: error: for each function it appears in.) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘primitiveResolverGetAddressInfo’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:324: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘primitiveResolverGetAddressInfoResult’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:380: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘primitiveResolverGetNameInfoHostResult’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:461: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘primitiveResolverGetNameInfoServiceResult’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:500: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘primitiveResolverHostNameResult’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:539: error: ‘nil’ undeclared (first use in this function) /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c: In function ‘primitiveResolverStartNameLookup’: /home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c:626: error: ‘nil’ undeclared (first use in this function) make[2]: *** [SocketPlugin/CMakeFiles/SocketPlugin.dir/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/SocketPlugin/SocketPlugin.c.o] Error 1 make[1]: *** [SocketPlugin/CMakeFiles/SocketPlugin.dir/all] Error 2

make: *** [all] Error 2

To solve this I tryied adding a

#define nil ((void*)0L)

as Marco said (for alien plugin) and almost worked, but gave errors, so I used:

#define nil 0L

I have to say that I've compiled some Pharo and Squeak VMs before and didn't get those errors. It may be related to loading VMMaker with ConfigurationOfVMMaker (I always did it manually before), or because of an updated version.

I'm very close to be able to test it, any ideas??

Regards, Javier.

On Sat, Feb 20, 2010 at 6:17 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

Oh fine, stupid tool sets, update your VMMaker image with:

Name: Alien-VMMaker-Plugins-John M McIntosh.8 Author: John M McIntosh Time: 20 February 2010, 1:16:02 pm UUID: a8e7e044-bf22-4013-85b7-c70d2081cd4e Ancestors: Alien-VMMaker-Plugins-John M McIntosh.7

nil is null is (void*) 0 YES? Well not in non macintosh build chains since nil is UNDEFINED. Fine change nil to null that is in sq.h

On 2010-02-20, at 11:20 AM, Javier Pimás wrote:

nice! this is way better, but I still have this:

/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/IA32ABI/IA32ABI.c: In function ‘primCallOutDoubleReturn’:

--

=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the results: 37 run, 17 passed, 0 failures, 20 errors. TestCallingSequenceChar10Long2 TestCallingSequenceChar2LongLong2 TestCallingSequenceChar8Long2 TestCallingSequenceChar9Long2 TestCallingSequenceCharLongLong2 TestCallingSequenceChars TestCallingSequenceDoubles14 TestCallingSequenceDoubles2 TestCallingSequenceFloats13 TestCallingSequenceFloats14 TestCallingSequenceFloats2 TestCallingSequenceFloats2WithInteger TestCallingSequenceFloats2WithInteger2 TestCallingSequenceFloats7 TestCallingSequenceInt TestCallingSequenceInt8 TestCallingSequenceIntWithFloatArgs TestCallingSequenceLongLong2 TestCallingSequenceShort TestCallingSequenceString It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why should it try to load itself, if it's compiled as an internal plugin? I compiled it as external too but didn't work either. Other question, can classic FFI and Alien live nicely together (I mean have x plugin use classic FFI while y uses Alien)? One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have both in, right? Syntax highligthing is broken for Alien primitive methods like these: <primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'> Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it: Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". What should I do about that? ignore it? That's all for now, thanks! Javier. On Mon, Feb 22, 2010 at 4:32 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

You've not loaded Name: Alien-VMMaker-Support-John M McIntosh.8 Author: John M McIntosh Time: 11 January 2010, 12:53:14 am UUID: 6953c7ab-4924-48b0-9984-f15ec7fb7d2b

into your vmmaker image

so it's not build the interp.c pieces.

On 2010-02-22, at 8:18 AM, Javier Pimás wrote:

internalIsImmutable

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

-- Javier Pimás Ciudad de Buenos Aires

On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote:

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

...

...

Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it:

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker image.

Great work Jorge! Nice to know you won the battle against VMMaker! The ensure in special objects array error, has to do with some missing classes as John pointed out. The smalltalk special objects array has hardcoded indexes for some relevant classes ( Globals) in the system. In the alien configuration i've just ensured that the size should be 53, before loading Alien, because the Alien code installs itself in that array at positions 54 and 55.

Havent followed this thread and currently lacking some time. The VMMaker config is changeable, so go ahead. Take care that it also works in latest Squeak trunk. Since most VM maintainers use Squeak to build the VM this is essential to follow their progress. Would also be a great move if Alien would be available on Windows - this would open the door to interfacing with Win technologies like COM or .NET (and therefore wake more commercial interest in Pharo). Having Alien on major OS platforms would also allow to use Smalltalk<-> Java bridging technologies like JavaConnect/JNIPort, Bye T. -------- Original-Nachricht --------

Datum: Tue, 23 Feb 2010 10:08:55 +0100 Von: Mariano Martinez Peck <marianopeck@gmail.com> An: Pharo-project@lists.gforge.inria.fr CC: Arnaud Jean-Baptiste <jbaptiste.arnaud@gmail.com>, Torsten Bergmann <astares@gmx.de> Betreff: Re: [Pharo-project] Trying to build alien plugin in linux

Torsten and JB: it would be cool to create a new metacello configuration version with this new version of VMMaker, puting the fix about the baseHeaderSize and integrating JB fixes to VMMaker.

Cheers

Mariano

On Tue, Feb 23, 2010 at 7:55 AM, Fernando olivero <oliverof@lu.unisi.ch>wrote:

...

On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote:

...

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

...

...

Lastly, as I said when I loaded Alien Core the first time, I got this

error while loading it:

...

...

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m

not

...

sure what it is check for.

...

Why don't you try it in a regular Pharo image versus your VMMaker image.

Great work Jorge! Nice to know you won the battle against VMMaker!

The ensure in special objects array error, has to do with some missing classes as John pointed out.

The smalltalk special objects array has hardcoded indexes for some relevant classes ( Globals) in the system. In the alien configuration i've just ensured that the size should be 53, before loading Alien, because the Alien code installs itself in that array at positions 54 and 55.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

On Tue, Feb 23, 2010 at 10:51 AM, Torsten Bergmann <astares@gmx.de> wrote:

Havent followed this thread and currently lacking some time. The VMMaker config is changeable, so go ahead.

Done. We do it together with JB. Name: ConfigurationOfVMMaker-MarianoMartinezPeck.7 Author: MarianoMartinezPeck Time: 25 February 2010, 1:06:10 pm UUID: dca6ccf9-51d0-4ba0-9c71-e0261518ecad Ancestors: ConfigurationOfVMMaker-MarianoMartinezPeck.6 New version and baseline 1.2 as development. It integrate JeanBatipste fixes to VMMaker for pharo

Take care that it also works in latest Squeak trunk. Since most VM maintainers use Squeak to build the VM this is essential to follow their progress.

Would also be a great move if Alien would be available on Windows - this would open the door to interfacing with Win technologies like COM or .NET (and therefore wake more commercial interest in Pharo). Having Alien on major OS platforms would also allow to use Smalltalk<-> Java bridging technologies like JavaConnect/JNIPort,

Bye T.

-------- Original-Nachricht --------

...

Datum: Tue, 23 Feb 2010 10:08:55 +0100 Von: Mariano Martinez Peck <marianopeck@gmail.com> An: Pharo-project@lists.gforge.inria.fr CC: Arnaud Jean-Baptiste <jbaptiste.arnaud@gmail.com>, Torsten Bergmann <astares@gmx.de> Betreff: Re: [Pharo-project] Trying to build alien plugin in linux

...

Torsten and JB: it would be cool to create a new metacello configuration version with this new version of VMMaker, puting the fix about the baseHeaderSize and integrating JB fixes to VMMaker.

Cheers

Mariano

On Tue, Feb 23, 2010 at 7:55 AM, Fernando olivero <oliverof@lu.unisi.ch>wrote:

...

On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote:

...

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

...

...

Lastly, as I said when I loaded Alien Core the first time, I got

this

...

error while loading it:

...

...

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker image.

Great work Jorge! Nice to know you won the battle against VMMaker!

The ensure in special objects array error, has to do with some missing classes as John pointed out.

The smalltalk special objects array has hardcoded indexes for some relevant classes ( Globals) in the system. In the alien configuration i've just ensured that the size should be 53, before loading Alien, because the Alien code installs itself in that array at positions 54 and 55.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- NEU: Mit GMX DSL über 1000,- ż sparen! http://portal.gmx.net/de/go/dsl02

On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the results:

37 run, 17 passed, 0 failures, 20 errors.

TestCallingSequenceChar10Long2 TestCallingSequenceChar2LongLong2 TestCallingSequenceChar8Long2 TestCallingSequenceChar9Long2 TestCallingSequenceCharLongLong2 TestCallingSequenceChars TestCallingSequenceDoubles14 TestCallingSequenceDoubles2 TestCallingSequenceFloats13 TestCallingSequenceFloats14 TestCallingSequenceFloats2 TestCallingSequenceFloats2WithInteger TestCallingSequenceFloats2WithInteger2 TestCallingSequenceFloats7 TestCallingSequenceInt TestCallingSequenceInt8 TestCallingSequenceIntWithFloatArgs TestCallingSequenceLongLong2 TestCallingSequenceShort TestCallingSequenceString

Oh look SUnits, great stuff (*cough* well I wrote most of them).

Cool, this is really really useful (although I sometimes find wrting tests boring ;) ).

It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why should it try to load itself, if it's compiled as an internal plugin? I compiled it as external too but didn't work either.

Well it compiled, but that doesn't mean it works. In fact the error means the plugin code is never loaded, or is callable. Now one thing to consider is that the plugin load fails, because it can't find it. (external usage). Or because (internal and external plugin) the VM Version and the plugin version don't match.

Look for your definition of #define VM_PROXY_MINOR 8

It should be 8 or higher for compiling BOTH the VM and the Plugin. Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass confusion about which header is being used?

If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work with a plugin compiled with VM_PROXY_MINOR = 8. It silently fails... Well actually it gives the primLoadLibrary failure, but good luck in guessing why...

Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in any other place?

Other question, can classic FFI and Alien live nicely together (I mean have x plugin use classic FFI while y uses Alien)?

yes.

One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have both in, right?

One is a subclass of the other. I use the IA32ABIPluginAttic one.

Ok, what is the difference between them? a performance issue? everything works the same I choose one or the other?

Syntax highligthing is broken for Alien primitive methods like these:

<primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'>

Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it:

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker image.

In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't defined inside (Smalltalk at: #ObjectMemory) classPool Interestingly, after load alien, #ClassAlien gets added as a key, but all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this: (Smalltalk at: #ObjectMemory) classPool inspect: - size : 119 [#AllButHashBits] : nil [#AllButMarkBit] : nil [#AllButMarkBitAndTypeMask] : nil [#AllButRootBit] : nil [#AllButTypeMask] : nil ... [#ClassAlien] : nil ... Any ideas? -- Javier Pimás Ciudad de Buenos Aires

It would be missing, propose a change set. I would think people usually don't use VMMaker images as their daily work image. So take image, load vmaker, load vmaker stuff for alien, make alien plugin. got to my work image that doesn't have vmmaker in it, load alien support stuf, you don't need the alien-vmmaker-support btw. run tests. On 2010-03-01, at 3:36 PM, Javier Pimás wrote:

Hi, I'm still trying to advance with this. Don't know what caused the ObjectMemory classPools but it seems to be away now, maybe I did some mistake last time.

The thing is that now I have in ObjectMemory classPools all the original ones plus 4 new elements, which I think were added with this Alien-VMMaker-Support override:

ObjectMemory>>#initialize initialize #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector #SelectorAttemptToAssign) do: [:c | [ObjectMemory addClassVarName: c] ifError: []].

the thing is that it never assigns them any value, so my theory is that there's some code missing? Then in Interpreter it happens something quite similar. Interpreter>>#initialize does this:

...

#(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) do: [:c | [Interpreter addClassVarName: c] ifError: []].

#(#primFailCode) do: [:i | [Interpreter addInstVarName: i] ifError: []].

...

but then never calls initializePrimitiveErrorCodes, which would set the vars to a meaningfull value.

In conclusion, the question would be, where is this missing initialization code?

Hope you can help, thanks!

Javier.

On Tue, Feb 23, 2010 at 4:39 PM, Javier Pimás <elpochodelagente@gmail.com> wrote:

On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

...

Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the results:

37 run, 17 passed, 0 failures, 20 errors.

TestCallingSequenceChar10Long2 TestCallingSequenceChar2LongLong2 TestCallingSequenceChar8Long2 TestCallingSequenceChar9Long2 TestCallingSequenceCharLongLong2 TestCallingSequenceChars TestCallingSequenceDoubles14 TestCallingSequenceDoubles2 TestCallingSequenceFloats13 TestCallingSequenceFloats14 TestCallingSequenceFloats2 TestCallingSequenceFloats2WithInteger TestCallingSequenceFloats2WithInteger2 TestCallingSequenceFloats7 TestCallingSequenceInt TestCallingSequenceInt8 TestCallingSequenceIntWithFloatArgs TestCallingSequenceLongLong2 TestCallingSequenceShort TestCallingSequenceString

Oh look SUnits, great stuff (*cough* well I wrote most of them).

Cool, this is really really useful (although I sometimes find wrting tests boring ;) ).

...

It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why should it try to load itself, if it's compiled as an internal plugin? I compiled it as external too but didn't work either.

Well it compiled, but that doesn't mean it works. In fact the error means the plugin code is never loaded, or is callable. Now one thing to consider is that the plugin load fails, because it can't find it. (external usage). Or because (internal and external plugin) the VM Version and the plugin version don't match.

Look for your definition of #define VM_PROXY_MINOR 8

It should be 8 or higher for compiling BOTH the VM and the Plugin. Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass confusion about which header is being used?

If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work with a plugin compiled with VM_PROXY_MINOR = 8. It silently fails... Well actually it gives the primLoadLibrary failure, but good luck in guessing why...

Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in any other place?

...

Other question, can classic FFI and Alien live nicely together (I mean have x plugin use classic FFI while y uses Alien)?

yes.

...

One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have both in, right?

One is a subclass of the other. I use the IA32ABIPluginAttic one.

Ok, what is the difference between them? a performance issue? everything works the same I choose one or the other?

...

Syntax highligthing is broken for Alien primitive methods like these:

<primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'>

Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it:

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker image.

In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't defined inside

(Smalltalk at: #ObjectMemory) classPool

Interestingly, after load alien, #ClassAlien gets added as a key, but all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this:

(Smalltalk at: #ObjectMemory) classPool inspect:

- size : 119 [#AllButHashBits] : nil [#AllButMarkBit] : nil [#AllButMarkBitAndTypeMask] : nil [#AllButRootBit] : nil [#AllButTypeMask] : nil ... [#ClassAlien] : nil ...

Any ideas?

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

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

2010/3/3 Javier Pimás <elpochodelagente@gmail.com>

Ok, this is way nicer. The line that was missing and that seems to solve all this is

self initializeSpecialObjectIndices.

which I think should be placed in Alien>>#initialize just before

self ensureInSpecialObjectsArray.

but then I don't know why it should ensure anything that is done just before.

With that I it's really close to work. After a few hours I understood the way tests are done. In Alien plugin you integrated a couple of exported functions (ffiTest*), which you then call in the tests. These funcs do simple stuff like adding and returning the result, so you can compare, am I right?

Then I realized that (at least in linux) the tests won't work if you compile as internal (there won't be a .so, so you won't be able to load the C test functions!).

Now with the small fix I added, and compiling as external, I can see that it's actually almost almost working, buuuut I get these test results: 36 run, 17 passed, 19 failures, 0 errors (had to remove testCallingSquenceString because it crashed the VM). Notice that before I got 20 errors and 0 failures. This is because the results are wrong.

I debugged the code with ddd to see what's happening, and I can see that everything is going nice before the actual function call, that is done in dabusiness.h.

funcAlien = interpreterProxy->stackValue(funcOffset); f = *(void **)startOfParameterData(funcAlien);

#if STACK_ALIGN_BYTES (in my compiled code it is'nt defined, should it?) /* cut stack back to start of aligned args */ setsp(argstart); #endif r = f();

I took as example test #ffiTestLongLong10a2:, which calls ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2).

dabusiness.h allocated 56 bytes in argvec (10*4 for chars + 2*8 for longlong), which then fills correctly (ddd says 1 2 3 4 5 6 7 8 9 10 11 0 12 0). I have to admit that I don't fully understand whats happening with the stack then, but ffiTestLongLong10a2 gets its arguments wrong. I'm thinking of a calling convention problem. Here it's why:

In some run I have: &argvec[0] is pos 0aa0 (this is actually direction inside the stack, near it's top). Just before assembly CALL ffiTestLongLong10a2 I have ebp=0b68, and after the call it is pushed and replaced with esp, which is 0a88. Then, we have, args at 0aa0, 0aa4, ..., and current stack frame starting at 0a88 and going lower, 0a84, etc. That may be ok, but when I look into the ffiTestLongLong10a2 assembly it is trying to find the arguments by *substracting* to ebp (arg1 in ebp-1c, 2nd in ebp-20, ...) when it should adding, looking in greater positions (previous stack frame, arg1 is in ebp+18). This has to be some simple calling convention stuff, but I don't know how to solve it, any ideas?.

Subtracting from ebp is for accessing locals, adding to ebp for accessing arguments. Are you sure you're not misinterpreting a local access as an argument access?

Thanks for reading, Javier.

On Mon, Mar 1, 2010 at 9:05 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

It would be missing, propose a change set.

I would think people usually don't use VMMaker images as their daily work image.

So take image, load vmaker, load vmaker stuff for alien, make alien plugin.

got to my work image that doesn't have vmmaker in it, load alien support stuf, you don't need the alien-vmmaker-support btw. run tests.

On 2010-03-01, at 3:36 PM, Javier Pimás wrote:

Hi, I'm still trying to advance with this. Don't know what caused the ObjectMemory classPools but it seems to be away now, maybe I did some mistake last time.

The thing is that now I have in ObjectMemory classPools all the original ones plus 4 new elements, which I think were added with this Alien-VMMaker-Support override:

ObjectMemory>>#initialize initialize #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector #SelectorAttemptToAssign) do: [:c | [ObjectMemory addClassVarName: c] ifError: []].

the thing is that it never assigns them any value, so my theory is that there's some code missing? Then in Interpreter it happens something quite similar. Interpreter>>#initialize does this:

...

#(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) do: [:c | [Interpreter addClassVarName: c] ifError: []].

#(#primFailCode) do: [:i | [Interpreter addInstVarName: i] ifError: []].

...

but then never calls initializePrimitiveErrorCodes, which would set the vars to a meaningfull value.

In conclusion, the question would be, where is this missing initialization code?

Hope you can help, thanks!

Javier.

On Tue, Feb 23, 2010 at 4:39 PM, Javier Pimás <elpochodelagente@gmail.com

...

wrote:

...

On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the results:

37 run, 17 passed, 0 failures, 20 errors.

TestCallingSequenceChar10Long2 TestCallingSequenceChar2LongLong2 TestCallingSequenceChar8Long2 TestCallingSequenceChar9Long2 TestCallingSequenceCharLongLong2 TestCallingSequenceChars TestCallingSequenceDoubles14 TestCallingSequenceDoubles2 TestCallingSequenceFloats13 TestCallingSequenceFloats14 TestCallingSequenceFloats2 TestCallingSequenceFloats2WithInteger TestCallingSequenceFloats2WithInteger2 TestCallingSequenceFloats7 TestCallingSequenceInt TestCallingSequenceInt8 TestCallingSequenceIntWithFloatArgs TestCallingSequenceLongLong2 TestCallingSequenceShort TestCallingSequenceString

Oh look SUnits, great stuff (*cough* well I wrote most of them).

Cool, this is really really useful (although I sometimes find wrting tests boring ;) ).

...

It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why should it try to load itself, if it's compiled as an internal plugin? I compiled it as external too but didn't work either.

Well it compiled, but that doesn't mean it works. In fact the error means the plugin code is never loaded, or is callable. Now one thing to consider is that the plugin load fails, because it can't find it. (external usage). Or because (internal and external plugin) the VM Version and the plugin version don't match.

Look for your definition of #define VM_PROXY_MINOR 8

It should be 8 or higher for compiling BOTH the VM and the Plugin. Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass confusion about which header is being used?

If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work with a plugin compiled with VM_PROXY_MINOR = 8. It silently fails... Well actually it gives the primLoadLibrary failure, but good luck in guessing why...

Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in any other place?

...

Other question, can classic FFI and Alien live nicely together (I mean have x plugin use classic FFI while y uses Alien)?

yes.

One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have both in, right?

One is a subclass of the other. I use the IA32ABIPluginAttic one.

Ok, what is the difference between them? a performance issue? everything works the same I choose one or the other?

...

Syntax highligthing is broken for Alien primitive methods like these:

<primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'>

Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it:

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker image.

In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't defined inside

(Smalltalk at: #ObjectMemory) classPool

Interestingly, after load alien, #ClassAlien gets added as a key, but all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this:

(Smalltalk at: #ObjectMemory) classPool inspect:

- size : 119 [#AllButHashBits] : nil [#AllButMarkBit] : nil [#AllButMarkBitAndTypeMask] : nil [#AllButRootBit] : nil [#AllButTypeMask] : nil ... [#ClassAlien] : nil ...

Any ideas?

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

--

=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

-- Javier Pimás Ciudad de Buenos Aires

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Wiiiiiii. All tests passing now!! You were right, this func had so many variables that gcc was reserving some local space to do some intermediate calculations. To make the story short defining # define STACK_ALIGN_BYTES 16 solved it. After a lot of debugging I discovered that alloca was aligning the stack, allocating more space than necesary, and placing the args not starting from esp but from esp plus some offset. Adding getsp(argvec) to move argvec to the top of the stack didn't solve the problem because the code that pushes the args also overwrites it (don't know why, it's like alloca augmented the frame in the middle?). So, that define fixed everything, and #if __APPLE__ && __MACH__ && __i386__ # define STACK_ALIGN_BYTES 16 #endif should be changed accordingly (to something I don't know what). In my case I'm using gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1. Thanks for all the help! Regards, Javier. On Wed, Mar 3, 2010 at 2:36 PM, Javier Pimás <elpochodelagente@gmail.com>wrote:

Exactly, that's what confuses me most! The function doesn't even have locals:

EXPORT(LONGLONG) ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2) { return c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+i1 + i2; }

I'm quite sure it's substracting because I see the memory contents, and the disassembly is this (notice how it accumulates the result in edx):

0x75d32725 <ffiTestLongLong10a2+308>: movsbl -0x1c(%ebp),%edx 0x75d32729 <ffiTestLongLong10a2+312>: movsbl -0x20(%ebp),%eax 0x75d3272d <ffiTestLongLong10a2+316>: add %eax,%edx 0x75d3272f <ffiTestLongLong10a2+318>: movsbl -0x24(%ebp),%eax 0x75d32733 <ffiTestLongLong10a2+322>: add %eax,%edx 0x75d32735 <ffiTestLongLong10a2+324>: movsbl -0x28(%ebp),%eax 0x75d32739 <ffiTestLongLong10a2+328>: add %eax,%edx 0x75d3273b <ffiTestLongLong10a2+330>: movsbl -0x2c(%ebp),%eax 0x75d3273f <ffiTestLongLong10a2+334>: add %eax,%edx 0x75d32741 <ffiTestLongLong10a2+336>: movsbl -0x30(%ebp),%eax 0x75d32745 <ffiTestLongLong10a2+340>: add %eax,%edx 0x75d32747 <ffiTestLongLong10a2+342>: movsbl -0x34(%ebp),%eax 0x75d3274b <ffiTestLongLong10a2+346>: add %eax,%edx 0x75d3274d <ffiTestLongLong10a2+348>: movsbl -0x38(%ebp),%eax 0x75d32751 <ffiTestLongLong10a2+352>: add %eax,%edx 0x75d32753 <ffiTestLongLong10a2+354>: movsbl -0x3c(%ebp),%eax 0x75d32757 <ffiTestLongLong10a2+358>: add %eax,%edx 0x75d32759 <ffiTestLongLong10a2+360>: movsbl -0x40(%ebp),%eax 0x75d3275d <ffiTestLongLong10a2+364>: lea (%edx,%eax,1),%eax 0x75d32760 <ffiTestLongLong10a2+367>: mov %eax,%edx 0x75d32762 <ffiTestLongLong10a2+369>: sar $0x1f,%edx 0x75d32765 <ffiTestLongLong10a2+372>: add -0x48(%ebp),%eax 0x75d32768 <ffiTestLongLong10a2+375>: adc -0x44(%ebp),%edx 0x75d3276b <ffiTestLongLong10a2+378>: add -0x50(%ebp),%eax 0x75d3276e <ffiTestLongLong10a2+381>: adc -0x4c(%ebp),%edx 0x75d32771 <ffiTestLongLong10a2+384>: add $0xbc,%esp 0x75d32777 <ffiTestLongLong10a2+390>: pop %ebx 0x75d32778 <ffiTestLongLong10a2+391>: pop %esi 0x75d32779 <ffiTestLongLong10a2+392>: pop %edi 0x75d3277a <ffiTestLongLong10a2+393>: pop %ebp 0x75d3277b <ffiTestLongLong10a2+394>: ret

This is really weird! Why could gcc compiled it flipped? I'll continue looking.

Regards, Javier.

2010/3/3 Eliot Miranda <eliot.miranda@gmail.com>

...

2010/3/3 Javier Pimás <elpochodelagente@gmail.com>

Ok, this is way nicer. The line that was missing and that seems to solve

...

all this is

self initializeSpecialObjectIndices.

which I think should be placed in Alien>>#initialize just before

self ensureInSpecialObjectsArray.

but then I don't know why it should ensure anything that is done just before.

With that I it's really close to work. After a few hours I understood the way tests are done. In Alien plugin you integrated a couple of exported functions (ffiTest*), which you then call in the tests. These funcs do simple stuff like adding and returning the result, so you can compare, am I right?

Then I realized that (at least in linux) the tests won't work if you compile as internal (there won't be a .so, so you won't be able to load the C test functions!).

Now with the small fix I added, and compiling as external, I can see that it's actually almost almost working, buuuut I get these test results: 36 run, 17 passed, 19 failures, 0 errors (had to remove testCallingSquenceString because it crashed the VM). Notice that before I got 20 errors and 0 failures. This is because the results are wrong.

I debugged the code with ddd to see what's happening, and I can see that everything is going nice before the actual function call, that is done in dabusiness.h.

funcAlien = interpreterProxy->stackValue(funcOffset); f = *(void **)startOfParameterData(funcAlien);

#if STACK_ALIGN_BYTES (in my compiled code it is'nt defined, should it?) /* cut stack back to start of aligned args */ setsp(argstart); #endif r = f();

I took as example test #ffiTestLongLong10a2:, which calls ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2).

dabusiness.h allocated 56 bytes in argvec (10*4 for chars + 2*8 for longlong), which then fills correctly (ddd says 1 2 3 4 5 6 7 8 9 10 11 0 12 0). I have to admit that I don't fully understand whats happening with the stack then, but ffiTestLongLong10a2 gets its arguments wrong. I'm thinking of a calling convention problem. Here it's why:

In some run I have: &argvec[0] is pos 0aa0 (this is actually direction inside the stack, near it's top). Just before assembly CALL ffiTestLongLong10a2 I have ebp=0b68, and after the call it is pushed and replaced with esp, which is 0a88. Then, we have, args at 0aa0, 0aa4, ..., and current stack frame starting at 0a88 and going lower, 0a84, etc. That may be ok, but when I look into the ffiTestLongLong10a2 assembly it is trying to find the arguments by *substracting* to ebp (arg1 in ebp-1c, 2nd in ebp-20, ...) when it should adding, looking in greater positions (previous stack frame, arg1 is in ebp+18). This has to be some simple calling convention stuff, but I don't know how to solve it, any ideas?.

Subtracting from ebp is for accessing locals, adding to ebp for accessing arguments. Are you sure you're not misinterpreting a local access as an argument access?

...

Thanks for reading, Javier.

On Mon, Mar 1, 2010 at 9:05 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

It would be missing, propose a change set.

I would think people usually don't use VMMaker images as their daily work image.

So take image, load vmaker, load vmaker stuff for alien, make alien plugin.

got to my work image that doesn't have vmmaker in it, load alien support stuf, you don't need the alien-vmmaker-support btw. run tests.

On 2010-03-01, at 3:36 PM, Javier Pimás wrote:

Hi, I'm still trying to advance with this. Don't know what caused the ObjectMemory classPools but it seems to be away now, maybe I did some mistake last time.

The thing is that now I have in ObjectMemory classPools all the original ones plus 4 new elements, which I think were added with this Alien-VMMaker-Support override:

ObjectMemory>>#initialize initialize #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector #SelectorAttemptToAssign) do: [:c | [ObjectMemory addClassVarName: c] ifError: []].

the thing is that it never assigns them any value, so my theory is that there's some code missing? Then in Interpreter it happens something quite similar. Interpreter>>#initialize does this:

...

#(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) do: [:c | [Interpreter addClassVarName: c] ifError: []].

#(#primFailCode) do: [:i | [Interpreter addInstVarName: i] ifError: []].

...

but then never calls initializePrimitiveErrorCodes, which would set the vars to a meaningfull value.

In conclusion, the question would be, where is this missing initialization code?

Hope you can help, thanks!

Javier.

On Tue, Feb 23, 2010 at 4:39 PM, Javier Pimás < elpochodelagente@gmail.com> wrote:

...

On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the results:

37 run, 17 passed, 0 failures, 20 errors.

TestCallingSequenceChar10Long2 TestCallingSequenceChar2LongLong2 TestCallingSequenceChar8Long2 TestCallingSequenceChar9Long2 TestCallingSequenceCharLongLong2 TestCallingSequenceChars TestCallingSequenceDoubles14 TestCallingSequenceDoubles2 TestCallingSequenceFloats13 TestCallingSequenceFloats14 TestCallingSequenceFloats2 TestCallingSequenceFloats2WithInteger TestCallingSequenceFloats2WithInteger2 TestCallingSequenceFloats7 TestCallingSequenceInt TestCallingSequenceInt8 TestCallingSequenceIntWithFloatArgs TestCallingSequenceLongLong2 TestCallingSequenceShort TestCallingSequenceString

Oh look SUnits, great stuff (*cough* well I wrote most of them).

Cool, this is really really useful (although I sometimes find wrting tests boring ;) ).

...

It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why should it try to load itself, if it's compiled as an internal plugin? I compiled it as external too but didn't work either.

Well it compiled, but that doesn't mean it works. In fact the error means the plugin code is never loaded, or is callable. Now one thing to consider is that the plugin load fails, because it can't find it. (external usage). Or because (internal and external plugin) the VM Version and the plugin version don't match.

Look for your definition of #define VM_PROXY_MINOR 8

It should be 8 or higher for compiling BOTH the VM and the Plugin. Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass confusion about which header is being used?

If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work with a plugin compiled with VM_PROXY_MINOR = 8. It silently fails... Well actually it gives the primLoadLibrary failure, but good luck in guessing why...

Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in any other place?

...

Other question, can classic FFI and Alien live nicely together (I mean have x plugin use classic FFI while y uses Alien)?

yes.

One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have both in, right?

One is a subclass of the other. I use the IA32ABIPluginAttic one.

Ok, what is the difference between them? a performance issue? everything works the same I choose one or the other?

...

Syntax highligthing is broken for Alien primitive methods like these:

<primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'>

Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it:

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker image.

In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't defined inside

(Smalltalk at: #ObjectMemory) classPool

Interestingly, after load alien, #ClassAlien gets added as a key, but all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this:

(Smalltalk at: #ObjectMemory) classPool inspect:

- size : 119 [#AllButHashBits] : nil [#AllButMarkBit] : nil [#AllButMarkBitAndTypeMask] : nil [#AllButRootBit] : nil [#AllButTypeMask] : nil ... [#ClassAlien] : nil ...

Any ideas?

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

--

=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

-- Javier Pimás Ciudad de Buenos Aires

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

2010/3/4 Javier Pimás <elpochodelagente@gmail.com>

Also I have the theory that the problem may be related to some -fomit-frame-pointer hidden in some place that forces code to use references relative to esp instead of ebp.

Ah, that's *very* important. The plugin must *not* be built with -fomi-frame-pointer. In fact it needs -fno-omit-frame-pointer adding to Makefile.inc et al to ensure it always includes the frame pointer.

On Fri, Mar 5, 2010 at 1:20 AM, Javier Pimás <elpochodelagente@gmail.com>wrote:

...

Wiiiiiii. All tests passing now!!

You were right, this func had so many variables that gcc was reserving some local space to do some intermediate calculations.

To make the story short defining # define STACK_ALIGN_BYTES 16 solved it.

After a lot of debugging I discovered that alloca was aligning the stack, allocating more space than necesary, and placing the args not starting from esp but from esp plus some offset. Adding getsp(argvec) to move argvec to the top of the stack didn't solve the problem because the code that pushes the args also overwrites it (don't know why, it's like alloca augmented the frame in the middle?).

So, that define fixed everything, and

#if __APPLE__ && __MACH__ && __i386__ # define STACK_ALIGN_BYTES 16 #endif

should be changed accordingly (to something I don't know what). In my case I'm using gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1.

Thanks for all the help!

Regards, Javier.

On Wed, Mar 3, 2010 at 2:36 PM, Javier Pimás <elpochodelagente@gmail.com>wrote:

...

Exactly, that's what confuses me most! The function doesn't even have locals:

EXPORT(LONGLONG) ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2) { return c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+i1 + i2; }

I'm quite sure it's substracting because I see the memory contents, and the disassembly is this (notice how it accumulates the result in edx):

0x75d32725 <ffiTestLongLong10a2+308>: movsbl -0x1c(%ebp),%edx 0x75d32729 <ffiTestLongLong10a2+312>: movsbl -0x20(%ebp),%eax 0x75d3272d <ffiTestLongLong10a2+316>: add %eax,%edx 0x75d3272f <ffiTestLongLong10a2+318>: movsbl -0x24(%ebp),%eax 0x75d32733 <ffiTestLongLong10a2+322>: add %eax,%edx 0x75d32735 <ffiTestLongLong10a2+324>: movsbl -0x28(%ebp),%eax 0x75d32739 <ffiTestLongLong10a2+328>: add %eax,%edx 0x75d3273b <ffiTestLongLong10a2+330>: movsbl -0x2c(%ebp),%eax 0x75d3273f <ffiTestLongLong10a2+334>: add %eax,%edx 0x75d32741 <ffiTestLongLong10a2+336>: movsbl -0x30(%ebp),%eax 0x75d32745 <ffiTestLongLong10a2+340>: add %eax,%edx 0x75d32747 <ffiTestLongLong10a2+342>: movsbl -0x34(%ebp),%eax 0x75d3274b <ffiTestLongLong10a2+346>: add %eax,%edx 0x75d3274d <ffiTestLongLong10a2+348>: movsbl -0x38(%ebp),%eax 0x75d32751 <ffiTestLongLong10a2+352>: add %eax,%edx 0x75d32753 <ffiTestLongLong10a2+354>: movsbl -0x3c(%ebp),%eax 0x75d32757 <ffiTestLongLong10a2+358>: add %eax,%edx 0x75d32759 <ffiTestLongLong10a2+360>: movsbl -0x40(%ebp),%eax 0x75d3275d <ffiTestLongLong10a2+364>: lea (%edx,%eax,1),%eax 0x75d32760 <ffiTestLongLong10a2+367>: mov %eax,%edx 0x75d32762 <ffiTestLongLong10a2+369>: sar $0x1f,%edx 0x75d32765 <ffiTestLongLong10a2+372>: add -0x48(%ebp),%eax 0x75d32768 <ffiTestLongLong10a2+375>: adc -0x44(%ebp),%edx 0x75d3276b <ffiTestLongLong10a2+378>: add -0x50(%ebp),%eax 0x75d3276e <ffiTestLongLong10a2+381>: adc -0x4c(%ebp),%edx 0x75d32771 <ffiTestLongLong10a2+384>: add $0xbc,%esp 0x75d32777 <ffiTestLongLong10a2+390>: pop %ebx 0x75d32778 <ffiTestLongLong10a2+391>: pop %esi 0x75d32779 <ffiTestLongLong10a2+392>: pop %edi 0x75d3277a <ffiTestLongLong10a2+393>: pop %ebp 0x75d3277b <ffiTestLongLong10a2+394>: ret

This is really weird! Why could gcc compiled it flipped? I'll continue looking.

Regards, Javier.

2010/3/3 Eliot Miranda <eliot.miranda@gmail.com>

...

2010/3/3 Javier Pimás <elpochodelagente@gmail.com>

Ok, this is way nicer. The line that was missing and that seems to solve

...

all this is

self initializeSpecialObjectIndices.

which I think should be placed in Alien>>#initialize just before

self ensureInSpecialObjectsArray.

but then I don't know why it should ensure anything that is done just before.

With that I it's really close to work. After a few hours I understood the way tests are done. In Alien plugin you integrated a couple of exported functions (ffiTest*), which you then call in the tests. These funcs do simple stuff like adding and returning the result, so you can compare, am I right?

Then I realized that (at least in linux) the tests won't work if you compile as internal (there won't be a .so, so you won't be able to load the C test functions!).

Now with the small fix I added, and compiling as external, I can see that it's actually almost almost working, buuuut I get these test results: 36 run, 17 passed, 19 failures, 0 errors (had to remove testCallingSquenceString because it crashed the VM). Notice that before I got 20 errors and 0 failures. This is because the results are wrong.

I debugged the code with ddd to see what's happening, and I can see that everything is going nice before the actual function call, that is done in dabusiness.h.

funcAlien = interpreterProxy->stackValue(funcOffset); f = *(void **)startOfParameterData(funcAlien);

#if STACK_ALIGN_BYTES (in my compiled code it is'nt defined, should it?) /* cut stack back to start of aligned args */ setsp(argstart); #endif r = f();

I took as example test #ffiTestLongLong10a2:, which calls ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2).

dabusiness.h allocated 56 bytes in argvec (10*4 for chars + 2*8 for longlong), which then fills correctly (ddd says 1 2 3 4 5 6 7 8 9 10 11 0 12 0). I have to admit that I don't fully understand whats happening with the stack then, but ffiTestLongLong10a2 gets its arguments wrong. I'm thinking of a calling convention problem. Here it's why:

In some run I have: &argvec[0] is pos 0aa0 (this is actually direction inside the stack, near it's top). Just before assembly CALL ffiTestLongLong10a2 I have ebp=0b68, and after the call it is pushed and replaced with esp, which is 0a88. Then, we have, args at 0aa0, 0aa4, ..., and current stack frame starting at 0a88 and going lower, 0a84, etc. That may be ok, but when I look into the ffiTestLongLong10a2 assembly it is trying to find the arguments by *substracting* to ebp (arg1 in ebp-1c, 2nd in ebp-20, ...) when it should adding, looking in greater positions (previous stack frame, arg1 is in ebp+18). This has to be some simple calling convention stuff, but I don't know how to solve it, any ideas?.

Subtracting from ebp is for accessing locals, adding to ebp for accessing arguments. Are you sure you're not misinterpreting a local access as an argument access?

...

Thanks for reading, Javier.

On Mon, Mar 1, 2010 at 9:05 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

It would be missing, propose a change set.

I would think people usually don't use VMMaker images as their daily work image.

So take image, load vmaker, load vmaker stuff for alien, make alien plugin.

got to my work image that doesn't have vmmaker in it, load alien support stuf, you don't need the alien-vmmaker-support btw. run tests.

On 2010-03-01, at 3:36 PM, Javier Pimás wrote:

Hi, I'm still trying to advance with this. Don't know what caused the ObjectMemory classPools but it seems to be away now, maybe I did some mistake last time.

The thing is that now I have in ObjectMemory classPools all the original ones plus 4 new elements, which I think were added with this Alien-VMMaker-Support override:

ObjectMemory>>#initialize initialize #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector #SelectorAttemptToAssign) do: [:c | [ObjectMemory addClassVarName: c] ifError: []].

the thing is that it never assigns them any value, so my theory is that there's some code missing? Then in Interpreter it happens something quite similar. Interpreter>>#initialize does this:

...

#(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) do: [:c | [Interpreter addClassVarName: c] ifError: []].

#(#primFailCode) do: [:i | [Interpreter addInstVarName: i] ifError: []].

...

but then never calls initializePrimitiveErrorCodes, which would set the vars to a meaningfull value.

In conclusion, the question would be, where is this missing initialization code?

Hope you can help, thanks!

Javier.

On Tue, Feb 23, 2010 at 4:39 PM, Javier Pimás < elpochodelagente@gmail.com> wrote:

...

On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

On 2010-02-22, at 6:48 PM, Javier Pimás wrote:

Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the results:

37 run, 17 passed, 0 failures, 20 errors.

TestCallingSequenceChar10Long2 TestCallingSequenceChar2LongLong2 TestCallingSequenceChar8Long2 TestCallingSequenceChar9Long2 TestCallingSequenceCharLongLong2 TestCallingSequenceChars TestCallingSequenceDoubles14 TestCallingSequenceDoubles2 TestCallingSequenceFloats13 TestCallingSequenceFloats14 TestCallingSequenceFloats2 TestCallingSequenceFloats2WithInteger TestCallingSequenceFloats2WithInteger2 TestCallingSequenceFloats7 TestCallingSequenceInt TestCallingSequenceInt8 TestCallingSequenceIntWithFloatArgs TestCallingSequenceLongLong2 TestCallingSequenceShort TestCallingSequenceString

Oh look SUnits, great stuff (*cough* well I wrote most of them).

Cool, this is really really useful (although I sometimes find wrting tests boring ;) ).

...

It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why should it try to load itself, if it's compiled as an internal plugin? I compiled it as external too but didn't work either.

Well it compiled, but that doesn't mean it works. In fact the error means the plugin code is never loaded, or is callable. Now one thing to consider is that the plugin load fails, because it can't find it. (external usage). Or because (internal and external plugin) the VM Version and the plugin version don't match.

Look for your definition of #define VM_PROXY_MINOR 8

It should be 8 or higher for compiling BOTH the VM and the Plugin. Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass confusion about which header is being used?

If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work with a plugin compiled with VM_PROXY_MINOR = 8. It silently fails... Well actually it gives the primLoadLibrary failure, but good luck in guessing why...

Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in any other place?

...

Other question, can classic FFI and Alien live nicely together (I mean have x plugin use classic FFI while y uses Alien)?

yes.

One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have both in, right?

One is a subclass of the other. I use the IA32ABIPluginAttic one.

Ok, what is the difference between them? a performance issue? everything works the same I choose one or the other?

...

Syntax highligthing is broken for Alien primitive methods like these:

<primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'>

Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it:

Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".

What should I do about that? ignore it?

Well it seems to be related to

((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong'].

Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker image.

In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't defined inside

(Smalltalk at: #ObjectMemory) classPool

Interestingly, after load alien, #ClassAlien gets added as a key, but all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this:

(Smalltalk at: #ObjectMemory) classPool inspect:

- size : 119 [#AllButHashBits] : nil [#AllButMarkBit] : nil [#AllButMarkBitAndTypeMask] : nil [#AllButRootBit] : nil [#AllButTypeMask] : nil ... [#ClassAlien] : nil ...

Any ideas?

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

--

=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

-- Javier Pimás Ciudad de Buenos Aires

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

-- Javier Pimás Ciudad de Buenos Aires

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sat, 20 Feb 2010, John M McIntosh wrote:

PS, still looking for the rare fabled? windows developer who can build the plugin for windows.

I'll try if the linux version works. Levente

On 2010-02-20, at 11:20 AM, Javier Pimás wrote:

...

nice! this is way better, but I still have this:

/home/javier/st/squeak-svn/platforms/unix/src32/vm/intplugins/IA32ABI/IA32ABI.c: In function ?primCallOutDoubleReturn?:

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