On Sat, Aug 27, 2011 at 1:08 PM, Luís Oliveira <span dir="ltr"><<a href="mailto:luismbo@gmail.com" target="_blank">luismbo@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><div class="gmail_quote"><div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sat, Aug 27, 2011 at 5:05 PM, Liam Healy <<a href="mailto:lnp@healy.washington.dc.us" target="_blank">lnp@healy.washington.dc.us</a>> wrote:<br>
> My thought now is that I should define methods for translate-*-foreign and<br>
> free-translated-object dispatching on the foreign-struct-type class.<br>
<br>
</div>That makes sense. The type object should have all the necessary info<br>
you need to construct whatever objects libffi requires. (I'm not<br>
familiar with the libffi API.) I.e., you shouldn't need to define<br>
specific translation methods for each struct type definition.<br></blockquote><div> </div></div><div>I think I do need specific translations; see below.  I think a default would be appropriate though.  libffi needs a pointer to a foreign structure.<br>


<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div>
<br>
> The body will call the same method with the structure name, and applications can<br>
> define methods eql-specialized on the name.<br>
<br>
</div>I don't think that's necessary. DEFCSTRUCT takes an undocumented class<br>
argument that allows for specialization based on class rather than<br>
using EQL-specializers. I'm guessing you're thinking about stuff like<br>
converting CLOS objects into C structs. That is something that hasn't<br>
been properly explored in CFFI. See the undocumented<br>
DEFINE-C-STRUCT-WRAPPER for a half-baked go at that problem.<br></blockquote></div><div><br>I didn't know about the :class argument defcstruct, that seems right.  I could define a default method for foreign-struct-type.   I'm not thinking about CLOS objects, though that's interesting.  However, I don't view foreign structs as always mapping into Lisp structures; my canonical example is complex numbers (see FSBV readme <a href="http://repo.or.cz/w/fsbv.git" target="_blank">http://repo.or.cz/w/fsbv.git</a>) because the original driver for FSBV was the use of complex numbers in GSLL.   I convert Lisp complex numbers to and from the foreign structure consisting of two doubles or floats.<div class="im">

<br>
<br> <br>
> Does this sound like it will<br>
> work correctly with CFFI as it exists now, so that I can then introduce the<br>
> libffi interface for the calls to foreign functions?<br>
<br>
</div></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
What kind of translation do you need these methods to do on FOREIGN-STRUCT-TYPE?<br>
<br></blockquote></div><div>They should take the lisp object, allocate the foreign structure, then define the slots correctly (recursively if necessary), and return the pointer.  For the return pointer, they should read the contents and generate the lisp equivalent.  I suppose the calls to libffi functions should invoke translate-*-foreign just like it now invokes the functions on the properties fsbv::foreign-object-components and fsbv::setf-foreign-object-components.<br>


<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Cheers,<br>
<font color="#888888"><br>
--<br>
Luís Oliveira<br>
<a href="http://r42.eu/%7Eluis/" target="_blank">http://r42.eu/~luis/</a><br>
</font></blockquote></div></div><br>Does this make sense?<br>
<br>
Thanks,<br><font color="#888888">
<br>
Liam<br>
<br>
</font></div><br>