[cells-gtk-devel] 64bit listbox problem

[jimmy brisson]

in my hase I forgot to tell you that the function is (defun
gtk-tree-store-new ...

sorry 'bout that,
Jimmy

On Thu, Aug 11, 2011 at 8:50 PM, jimmy brisson <theotherjimmy at gmail.com>wrote:

> found this problem, replace stray :int's in the function def with 'gtype's
>
> this fixed the last problem, now (test-gtk:gtk-demo runs.
> thanks for your help,
> Jimmy
>
>
> On Thu, Aug 11, 2011 at 8:43 PM, jimmy brisson <theotherjimmy at gmail.com>wrote:
>
>>
>>
>> On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <ramarren at gmail.com> wrote:
>>
>>> This probably means that the GType width is wrong for 64 bits, which
>>> is not entirely unexpected since it is defined like this:
>>>
>>> #if     GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus
>>> typedef gsize                           GType;
>>> #else   /* for historic reasons, C++ links against gulong GTypes */
>>> typedef gulong                          GType;
>>> #endif
>>>
>>> which means it can be either an uint (at least I hope gsize is
>>> consistently uint) or an ulong. On 32 bit machine they are the same,
>>> on 64 bit not. I had assumed that the first branch is the usual and
>>> defined gtype as gsize/uint. An easy fix would be to change
>>> (cffi:defctype gtype gsize) to (cffi:defctype gtype gulong). But that
>>> might break this on some other systems.
>>>
>>> Since I am not sure how to detect this without invoking the C
>>> compiler, I have now added the change as a controllable feature with
>>> ulong as a default and pushed to the repository. Please test it and
>>> report if it fixes the memory fault.
>>>
>>> Jakub Higersberger
>>>
>>> On Thu, Aug 11, 2011 at 9:40 PM, jimmy brisson <theotherjimmy at gmail.com>
>>> wrote:
>>> > I have been prodding the memory fault problem on my 64bit machine ans
>>> have
>>> > narrowed it down to one function:
>>> > gtk-list-store-newv
>>> > when called like (gtk-ffi:gtk-list-store-new '(:string :string)) this
>>> > function consistently produces unhandled memory fault errors (at
>>> > #x4000000056 for '(:string :string)) when passed anything that is
>>> length 2
>>> > or more or contains strings (the '(:string :string) example is what
>>> > (test-gtk:gtk-demo) calls).
>>> > the type signature looks like a match to the header files on my system.
>>> > for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and
>>> sbcl
>>> > compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3
>>> > from https://github.com/Ramarren/cells-gtk3.git
>>> > I am happy to help in any way I can and can provide more information if
>>> > needed.
>>> > Thanks for the great library,
>>> > Jimmy
>>> > --
>>> > "Open-source software has fewer bugs because it admits the possibility
>>> of
>>> > bugs." Paul Graham
>>> >
>>> > _______________________________________________
>>> > cells-gtk-devel site list
>>> > cells-gtk-devel at common-lisp.net
>>> > http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>>> >
>>>
>>
>> that seems to have fixed the listbox error, but the same error (including
>> that #x400... value)  appears after "query link :tree-selection-predicate
>> cells-store nil" .
>> I will pull it apart now to look for the source.
>> thanks,
>> Jimmy
>>
>>
>> --
>> "The closed-source world cannot win an evolutionary arms race with
>> open-source communities, who can put orders of magnitude more skilled time
>> into a problem." --Eric Raymond
>>
>> "Open-source software has fewer bugs because it admits the possibility of
>> bugs." Paul Graham
>>
>
>
>
> --
> "The closed-source world cannot win an evolutionary arms race with
> open-source communities, who can put orders of magnitude more skilled time
> into a problem." --Eric Raymond
> "Open-source software has fewer bugs because it admits the possibility of
> bugs." Paul Graham
>



-- 
"The closed-source world cannot win an evolutionary arms race with
open-source communities, who can put orders of magnitude more skilled time
into a problem." --Eric Raymond
"Open-source software has fewer bugs because it admits the possibility of
bugs." Paul Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20110811/8c3679fe/attachment.html>