found this problem, replace stray :int's in the function def with 'gtype's<div><br></div><div>this fixed the last problem, now (test-gtk:gtk-demo runs.</div><div>thanks for your help,</div><div>Jimmy<br><br><div class="gmail_quote">
On Thu, Aug 11, 2011 at 8:43 PM, jimmy brisson <span dir="ltr"><<a href="mailto:theotherjimmy@gmail.com">theotherjimmy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <span dir="ltr"><<a href="mailto:ramarren@gmail.com" target="_blank">ramarren@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div>This probably means that the GType width is wrong for 64 bits, which<br>
is not entirely unexpected since it is defined like this:<br>
<br>
#if GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus<br>
typedef gsize GType;<br>
#else /* for historic reasons, C++ links against gulong GTypes */<br>
typedef gulong GType;<br>
#endif<br>
<br>
which means it can be either an uint (at least I hope gsize is<br>
consistently uint) or an ulong. On 32 bit machine they are the same,<br>
on 64 bit not. I had assumed that the first branch is the usual and<br>
defined gtype as gsize/uint. An easy fix would be to change<br>
(cffi:defctype gtype gsize) to (cffi:defctype gtype gulong). But that<br>
might break this on some other systems.<br>
<br>
Since I am not sure how to detect this without invoking the C<br>
compiler, I have now added the change as a controllable feature with<br>
ulong as a default and pushed to the repository. Please test it and<br>
report if it fixes the memory fault.<br>
<br>
Jakub Higersberger<br>
<br>
On Thu, Aug 11, 2011 at 9:40 PM, jimmy brisson <<a href="mailto:theotherjimmy@gmail.com" target="_blank">theotherjimmy@gmail.com</a>> wrote:<br>
</div><div><div></div><div>> I have been prodding the memory fault problem on my 64bit machine ans have<br>
> narrowed it down to one function:<br>
> gtk-list-store-newv<br>
> when called like (gtk-ffi:gtk-list-store-new '(:string :string)) this<br>
> function consistently produces unhandled memory fault errors (at<br>
> #x4000000056 for '(:string :string)) when passed anything that is length 2<br>
> or more or contains strings (the '(:string :string) example is what<br>
> (test-gtk:gtk-demo) calls).<br>
> the type signature looks like a match to the header files on my system.<br>
> for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and sbcl<br>
> compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3<br>
> from <a href="https://github.com/Ramarren/cells-gtk3.git" target="_blank">https://github.com/Ramarren/cells-gtk3.git</a><br>
> I am happy to help in any way I can and can provide more information if<br>
> needed.<br>
> Thanks for the great library,<br>
> Jimmy<br>
> --<br>
> "Open-source software has fewer bugs because it admits the possibility of<br>
> bugs." Paul Graham<br>
><br>
</div></div><div><div></div><div>> _______________________________________________<br>
> cells-gtk-devel site list<br>
> <a href="mailto:cells-gtk-devel@common-lisp.net" target="_blank">cells-gtk-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/mailman/listinfo/cells-gtk-devel" target="_blank">http://common-lisp.net/mailman/listinfo/cells-gtk-devel</a><br>
><br>
</div></div></blockquote></div><div><br></div></div></div>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" .<div>
I will pull it apart now to look for the source.</div><div>thanks,</div><div>Jimmy<br><font color="#888888"><br clear="all"><br>-- <br>"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</font><div class="im">
<br>
"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br>"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<br>
"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>