I've added http://code.google.com/p/cog/issues/detail?id=23
On Mon, Apr 4, 2011 at 4:38 AM, Eliot Miranda <eliot.mira...@gmail.com>wrote: > Hi Dale, > > this is a known issue spotted and fixed by Ken Treis. I've been tardy > in integrating the fix. I'll try and do that in the next couple of days. A > test case would help (Ken, Dale?). > > If you want to try Ken's fix in advance then see > http://lists.gforge.inria.fr/pipermail/pharo-project/2011-March/044521.html > > Apologies, > Eliot > > > On Sun, Apr 3, 2011 at 1:04 PM, Dale Henrichs <dhenr...@vmware.com> wrote: > >> >> On Apr 3, 2011, at 12:48 PM, Dale Henrichs wrote: >> >> > >> > On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote: >> > >> >> Norbert, >> >> >> >> Today I have found that I can get GemTools to work on the mac using >> Squeak 4.2.4beta1U. >> >> >> >> Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value >> (get a Space is low error, because the size comes back as >> 1330942246849085449, instead of a reasonable number). >> >> >> >> The image is identical and the gci library file is identical in both >> cases, I've just switched the vm that I'm using. >> >> >> >> Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first >> FFI call into the library. >> >> >> >> Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI >> call that returns the unreasonable number in 4.2.5beta1U...the argument to >> the function is a SmallInteger (343552513) ... at least this error gives me >> hope that I can figure out what's wrong with this call sooner or later ... >> >> >> >> Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the >> moment on the Mac for running GemTools ... >> >> >> >> Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works >> gives me an incentive to try getting GemTools running on PharoCore.1.2... >> >> >> >> If any of the vm or FFI guys have some insight to these problems I'd >> appreciate some pointers to what may be going on... >> > >> > Here's the FFI call: >> > >> > apiGciFetchObjImpl: anOopType >> > >> > <apicall: ulong 'GciFetchObjImpl' (OopType64) > >> > ^self externalCallFailed >> > >> > and OopType64 is a subclass of ExternalStructure with the following >> fields declaration: >> > >> > fields >> > " >> > (OopType64 defineFields) >> > " >> > >> > ^#(asOop 'ulonglong'). >> > >> > and the function declaration from the header file: >> > >> > int GciFetchObjImpl(OopType theObject); >> >> I thought it might be suspicious that a SmallInteger was being passed in >> when the argument type should have been OopType, so in the Cog vm, I traced >> the source of the argument back to the _result_ another FFI call: >> >> <apicall: OopType64 'GciNbPerform' (OopType64 char* ulong long) > >> >> The result is declared as OopType64 so it looks like the result was not >> converted to the correct type on return...which ends up with the incorrect >> argument coming in .. >> >> When the Squeak 4.2.5beta1U runs through the same sequence of calls, the >> result of GciNbPerform gets correctly converted to OopType64, so that seems >> to be the ulitmate source of the error ... >> >> Not sure whether this is a VM issue or an FFI issue, in either case I >> assume that the bug exists in some C code floating around somewhere.. >> >> Dale >> >> >> > -- http://marianopeck.wordpress.com
