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 ===========================================================================
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.
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
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
I've loaded VMMaker into a new Pharo image and it produces an interpreter that I can successfully compile. After loading VMMaker, ObjectMemory baseHeaderSize is nil as expected: BaseHeaderSize and BytesPerWord are initialized through #initializeWithBytesToWord:, which is called by #generateInterpreterFile. Hence, both variables are nil until VMMaker is run the first time.
Cheers, Adrian
On Feb 21, 2010, at 17:20 , David T. Lewis 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
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
vm-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
David T. Lewis -
Javier Pimás -
John M McIntosh -
Levente Uzonyi