From theotherjimmy at gmail.com  Thu Aug 11 19:40:58 2011
From: theotherjimmy at gmail.com (jimmy brisson)
Date: Thu, 11 Aug 2011 19:40:58 +0000
Subject: [cells-gtk-devel]  64bit listbox problem
Message-ID: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20110811/614ca4f7/attachment.html>

From ramarren at gmail.com  Thu Aug 11 20:32:48 2011
From: ramarren at gmail.com (Ramarren)
Date: Thu, 11 Aug 2011 22:32:48 +0200
Subject: [cells-gtk-devel] 64bit listbox problem
In-Reply-To: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>
References: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>
Message-ID: <CAFpQiZYMOMDD0c7EC4AjQrnOQnd2G7A0DX2oHSr7DzcqXo8GxQ@mail.gmail.com>

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
>



From theotherjimmy at gmail.com  Thu Aug 11 20:43:13 2011
From: theotherjimmy at gmail.com (jimmy brisson)
Date: Thu, 11 Aug 2011 20:43:13 +0000
Subject: [cells-gtk-devel] 64bit listbox problem
In-Reply-To: <CAFpQiZYMOMDD0c7EC4AjQrnOQnd2G7A0DX2oHSr7DzcqXo8GxQ@mail.gmail.com>
References: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>
	<CAFpQiZYMOMDD0c7EC4AjQrnOQnd2G7A0DX2oHSr7DzcqXo8GxQ@mail.gmail.com>
Message-ID: <CALQpJDvuZBCEYM-rk8OgKzoG7VS+LhxS4F_P3_WJ=o9+9Fdt1Q@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20110811/f8805abd/attachment.html>

From theotherjimmy at gmail.com  Thu Aug 11 20:50:22 2011
From: theotherjimmy at gmail.com (jimmy brisson)
Date: Thu, 11 Aug 2011 20:50:22 +0000
Subject: [cells-gtk-devel] 64bit listbox problem
In-Reply-To: <CALQpJDvuZBCEYM-rk8OgKzoG7VS+LhxS4F_P3_WJ=o9+9Fdt1Q@mail.gmail.com>
References: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>
	<CAFpQiZYMOMDD0c7EC4AjQrnOQnd2G7A0DX2oHSr7DzcqXo8GxQ@mail.gmail.com>
	<CALQpJDvuZBCEYM-rk8OgKzoG7VS+LhxS4F_P3_WJ=o9+9Fdt1Q@mail.gmail.com>
Message-ID: <CALQpJDtRwdSdQdPgnHNop8kpLHdJSmFGFeK5mt7Gh4Qbw=3FQg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20110811/f47f742e/attachment.html>

From theotherjimmy at gmail.com  Thu Aug 11 20:51:34 2011
From: theotherjimmy at gmail.com (jimmy brisson)
Date: Thu, 11 Aug 2011 20:51:34 +0000
Subject: [cells-gtk-devel] 64bit listbox problem
In-Reply-To: <CALQpJDtRwdSdQdPgnHNop8kpLHdJSmFGFeK5mt7Gh4Qbw=3FQg@mail.gmail.com>
References: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>
	<CAFpQiZYMOMDD0c7EC4AjQrnOQnd2G7A0DX2oHSr7DzcqXo8GxQ@mail.gmail.com>
	<CALQpJDvuZBCEYM-rk8OgKzoG7VS+LhxS4F_P3_WJ=o9+9Fdt1Q@mail.gmail.com>
	<CALQpJDtRwdSdQdPgnHNop8kpLHdJSmFGFeK5mt7Gh4Qbw=3FQg@mail.gmail.com>
Message-ID: <CALQpJDtbWttKr7zXU6e+2J9q9WizYwkNqeUMTmwwJxvwCpb8xg@mail.gmail.com>

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>

From ramarren at gmail.com  Thu Aug 11 21:02:50 2011
From: ramarren at gmail.com (Ramarren)
Date: Thu, 11 Aug 2011 23:02:50 +0200
Subject: [cells-gtk-devel] 64bit listbox problem
In-Reply-To: <CALQpJDtbWttKr7zXU6e+2J9q9WizYwkNqeUMTmwwJxvwCpb8xg@mail.gmail.com>
References: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>
	<CAFpQiZYMOMDD0c7EC4AjQrnOQnd2G7A0DX2oHSr7DzcqXo8GxQ@mail.gmail.com>
	<CALQpJDvuZBCEYM-rk8OgKzoG7VS+LhxS4F_P3_WJ=o9+9Fdt1Q@mail.gmail.com>
	<CALQpJDtRwdSdQdPgnHNop8kpLHdJSmFGFeK5mt7Gh4Qbw=3FQg@mail.gmail.com>
	<CALQpJDtbWttKr7zXU6e+2J9q9WizYwkNqeUMTmwwJxvwCpb8xg@mail.gmail.com>
Message-ID: <CAFpQiZbMuXKgcUYfzZ_t00HoRYZb0MuG-As+b2guofoMefJxmw@mail.gmail.com>

OK, thanks, I pushed it to the repository.

Jakub Higersberger

On Thu, Aug 11, 2011 at 10:51 PM, jimmy brisson <theotherjimmy at gmail.com> wrote:
> 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
>



From peter.hildebrandt at gmail.com  Wed Aug 24 15:14:45 2011
From: peter.hildebrandt at gmail.com (Peter Hildebrandt)
Date: Wed, 24 Aug 2011 08:14:45 -0700
Subject: [cells-gtk-devel] 64bit listbox problem
In-Reply-To: <CAFpQiZbMuXKgcUYfzZ_t00HoRYZb0MuG-As+b2guofoMefJxmw@mail.gmail.com>
References: <CALQpJDs1OeBfpS_Yk6zMU9Wwz6P5Y-Kp4Dpi2_7MrZCZGsnN5Q@mail.gmail.com>
	<CAFpQiZYMOMDD0c7EC4AjQrnOQnd2G7A0DX2oHSr7DzcqXo8GxQ@mail.gmail.com>
	<CALQpJDvuZBCEYM-rk8OgKzoG7VS+LhxS4F_P3_WJ=o9+9Fdt1Q@mail.gmail.com>
	<CALQpJDtRwdSdQdPgnHNop8kpLHdJSmFGFeK5mt7Gh4Qbw=3FQg@mail.gmail.com>
	<CALQpJDtbWttKr7zXU6e+2J9q9WizYwkNqeUMTmwwJxvwCpb8xg@mail.gmail.com>
	<CAFpQiZbMuXKgcUYfzZ_t00HoRYZb0MuG-As+b2guofoMefJxmw@mail.gmail.com>
Message-ID: <CAC5GNr+h-3wQuzUXjaGscAd1vPGmDKDJ7Pygdji6-QxVxdhBeA@mail.gmail.com>

Jakub, Jimmy,


Thanks to both of you for working through this. Glad to see other
people using this library.

Peter


On Thursday, August 11, 2011, Ramarren <ramarren at gmail.com> wrote:
> OK, thanks, I pushed it to the repository.
>
> Jakub Higersberger
>
> On Thu, Aug 11, 2011 at 10:51 PM, jimmy brisson <theotherjimmy at gmail.com> wrote:
>> 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
>