[Pharo-project] Loading GemTools in Pharo 1.1.1-dev
Hi, I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. An error appears when loading Metacello Browser version #development. After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable. What am I doing wrong? or do I need to use a different image? Regards, Veronica
Hi Veronica ;-) First update Metacello: ConfigurationOfMetacello project updateProject On 30 Mar 2011, at 15:42, Veronica Isabel Uquillas Gomez wrote:
Hi,
I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. An error appears when loading Metacello Browser version #development. After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable.
What am I doing wrong? or do I need to use a different image?
Regards, Veronica
Veronica , if you work on Mac, consider this email from Dale : I have had trouble using GemTools on the Mac when running with a pharo version later than Pharo1.0 ... I have tried a number of different things and haven't | |figured out what is wrong, so for the MAC you need to use Pharo1.0 (that's what the GemTools one-click is based upon). Dario
Hi,
I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. An error appears when loading Metacello Browser version #development. After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable.
What am I doing wrong? or do I need to use a different image?
Regards, Veronica
Sounds like a metacello problem. It is definitely working because I own a Mac and I'm using an 1.1 image. Did you try loading via ConfigurationOfGemTools? Norbert Am 30.03.2011 um 15:50 schrieb Dario Trussardi:
Veronica ,
if you work on Mac, consider this email from Dale :
I have had trouble using GemTools on the Mac when running with a pharo version later than Pharo1.0 ... I have tried a number of different things and haven't | |figured out what is wrong, so for the MAC you need to use Pharo1.0 (that's what the GemTools one-click is based upon).
Dario
Hi,
I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. An error appears when loading Metacello Browser version #development. After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable.
What am I doing wrong? or do I need to use a different image?
Regards, Veronica
Indeed it works now... I was directly loading a version of GemTools via ConfigurationOfGemTools but that image is also needing an update of Metacello first. Veronica On 30 Mar 2011, at 18:07, Norbert Hartl wrote:
Sounds like a metacello problem. It is definitely working because I own a Mac and I'm using an 1.1 image. Did you try loading via ConfigurationOfGemTools?
Norbert
Am 30.03.2011 um 15:50 schrieb Dario Trussardi:
Veronica ,
if you work on Mac, consider this email from Dale :
I have had trouble using GemTools on the Mac when running with a pharo version later than Pharo1.0 ... I have tried a number of different things and haven't | |figured out what is wrong, so for the MAC you need to use Pharo1.0 (that's what the GemTools one-click is based upon).
Dario
Hi,
I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. An error appears when loading Metacello Browser version #development. After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable.
What am I doing wrong? or do I need to use a different image?
Regards, Veronica
On Mar 30, 2011, at 6:50 AM, Dario Trussardi wrote:
Veronica ,
if you work on Mac, consider this email from Dale :
I have had trouble using GemTools on the Mac when running with a pharo version later than Pharo1.0 ... I have tried a number of different things and haven't | |figured out what is wrong, so for the MAC you need to use Pharo1.0 (that's what the GemTools one-click is based upon).
Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem... I am glad to hear that some folks are not having trouble ... which only deepens the mystery:) Dale
Dario
Hi,
I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. An error appears when loading Metacello Browser version #development. After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable.
What am I doing wrong? or do I need to use a different image?
Regards, Veronica
well... it only works with a VM up to version 4.2.2 everything beyond that ended up in a strange login error, indeed On 30 Mar 2011, at 18:19, Dale Henrichs wrote:
Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem...
I am glad to hear that some folks are not having trouble ... which only deepens the mystery:)
Dale
I'll have to give vm version 4.2.2 a try ... Dale On Mar 30, 2011, at 10:02 AM, Johan Brichau wrote:
well... it only works with a VM up to version 4.2.2
everything beyond that ended up in a strange login error, indeed
On 30 Mar 2011, at 18:19, Dale Henrichs wrote:
Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem...
I am glad to hear that some folks are not having trouble ... which only deepens the mystery:)
Dale
Am 30.03.2011 um 19:02 schrieb Johan Brichau:
well... it only works with a VM up to version 4.2.2
well, right! Something I forgot to tell. That is the reason I start it from the command line :) Norbert
everything beyond that ended up in a strange login error, indeed
On 30 Mar 2011, at 18:19, Dale Henrichs wrote:
Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem...
I am glad to hear that some folks are not having trouble ... which only deepens the mystery:)
Dale
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... Dale On Mar 30, 2011, at 10:09 AM, Norbert Hartl wrote:
Am 30.03.2011 um 19:02 schrieb Johan Brichau:
well... it only works with a VM up to version 4.2.2
well, right! Something I forgot to tell. That is the reason I start it from the command line :)
Norbert
everything beyond that ended up in a strange login error, indeed
On 30 Mar 2011, at 18:19, Dale Henrichs wrote:
Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem...
I am glad to hear that some folks are not having trouble ... which only deepens the mystery:)
Dale
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); Dale
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
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 <dhenrich@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
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.miranda@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 <dhenrich@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
Hey Eliot, I missed that thread:) It looks like Ken included some FFI test cases in his patch code ... what would you need over and above that? An actual C library? Dale On Apr 3, 2011, at 7:38 PM, Eliot Miranda 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 <dhenrich@vmware.com<mailto:dhenrich@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
participants (7)
-
Dale Henrichs -
Dario Trussardi -
Eliot Miranda -
Johan Brichau -
Mariano Martinez Peck -
Norbert Hartl -
Veronica Isabel Uquillas Gomez