<div class="gmail_quote">On Sat, Aug 27, 2011 at 5:56 PM, Luís Oliveira <span dir="ltr"><<a href="mailto:luismbo@gmail.com">luismbo@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 class="im">On Sat, Aug 27, 2011 at 10:11 PM, Liam Healy <<a href="mailto:lnp@healy.washington.dc.us">lnp@healy.washington.dc.us</a>> wrote:<br>
> So you're suggesting retaining the :constructor and :deconstructor arguments<br>
> to defcstruct? It seems like a custom translate-*-foreign may be more<br>
> compatible with existing CFFI, though I guess a compatibility expansion<br>
> might be convenient.<br>
<br>
</div>No, that's not what I meant. Let's take your COMPLEX example. That<br>
should make things clearer.<br>
<br>
(defcstruct (complex :class complex-type)<br>
(real :double)<br>
(imag :double))<br>
<br>
(defmethod translate-to-foreign ((value complex) (type complex-type))<br>
(let ((p (foreign-alloc 'complex)))<br>
(with-foreign-slots ((real imag) p 'complex)<br>
(setf real (realpart value)<br>
imag (imagpart value)))<br>
(values p t)) ; second value is passed to FREE-TRANSLATED-OBJECT<br>
<br>
(defmethod free-translated-object (value (p complex-type) freep)<br>
(when freep<br>
(foreign-free value)))<br>
<br>
(defmethod translate-from-foreign (value (type complex-type))<br>
...)<br>
<br>
(defcfun (complex-conjugate "gsl_complex_conjugate") complex<br>
(c (:by-value complex)) ; or something like that.<br>
<br>
;; we can then call it like this:<br>
<br>
(complex-conjugate #c(3.0d0 4.0d0))<br>
#C(3.0 -4.0)<br>
<br>
;; what I was proposing is that one could /also/ call it like this:<br>
<br>
(with-foreign-object (p 'complex)<br>
(with-foreign-slots ((real imag) p 'complex)<br>
(setf real 3.0 imag -4.0))<br>
(complex-conjugate p))<br>
<br>
<br>
In summary, we're always dealing with struct pointers, but the<br>
function declaration will determine whether that struct will be passed<br>
by value or not. Does that make sense?<br></blockquote><div><br>Yes. I'm not (yet) concerned about the function declaration or the libffi call, because my confusion was about the conversion structure and how it might apply to structures, even before any foreign functions are called. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
My follow-up question was: is this too subtle? Should we make this<br>
more explicit? E.g.:<br>
<br>
(with-foreign-object (p 'complex)<br>
(with-foreign-slots ((real imag) p 'complex)<br>
(setf real 3.0 imag -4.0))<br>
(complex-conjugate (struct-pointer-value p)))<br>
<br>
Doesn't look too pretty.<br></blockquote><div><br>No, I don't like this either.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
> For a default conversion assuming a structure on the lisp side, I'm not sure<br>
> how to iterate over the structure. Maybe MOP has something? I do have<br>
> iterate-foreign-structure. If I assume a list or vector on the lisp side,<br>
> then I could iterate through it.<br>
<br>
</div>If we add such a feature, I guess the Lisp structure (or class) should<br>
be defined by defcstruct itself.<br></blockquote><div> </div><div>Good point. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
> If I define a specializer for a particular cstruct, what should the class<br>
> be? This looks like a type name, not the actual object that's passed as the<br>
> second argument 'type, so I presume it should be an eql specializer on the<br>
> name, but I admit I'm getting confused by this. In any case I think the<br>
> :class option to defcstruct won't always work because it does a defclass, I<br>
> need something like :existing-class that would just do a find-class.<br>
<br>
</div>Hopefully my example with COMPLEX-TYPE illustrates how that works. The<br>
type argument gets an instance of COMPLEX-TYPE, which is the result of<br>
(parse-type 'complex). Was it clear?<br></blockquote><div><br>Yes, thanks. The subclassing of type names was confusing me. The example makes it clear. I think I will define a macro to make the creation of the translate-*-foreign and free-translated-object methods a little bit easier.<br>
<br>Liam<br> <br></div><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>
</font><div><div></div><div class="h5">Luís Oliveira<br>
<a href="http://r42.eu/%7Eluis/" target="_blank">http://r42.eu/~luis/</a><br>
</div></div></blockquote></div><br>