<div class="gmail_quote">On Sat, Feb 13, 2010 at 11:53 PM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net">mm_lists@pulsar-zone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Sat, 13 Feb 2010 23:36:13 +0100<br>
<div class="im">Juan Jose Garcia-Ripoll <<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>> wrote:<br>
<br>
</div><div class="im">> Nothing to add here. UFFI was and is very limited. CFFI is probably the way<br>
> to go for portable code, and is even favored for standardization. However,<br>
> 1) the ECL backend is crappy, 2) it will also not support GCC alignment<br>
> extensions and 3) it may still have problems with structures if a compiler<br>
> makes weird design choices. Problem 3) is solved by the fact that there are<br>
> more eyes watching CFFI and ensuring that it works.<br>
<br>
</div>And I guess that 4) it has various external dependencies (at least the<br>
current implementation), 5) performance might be affected because of<br>
the dynamic function lookup per call :)  But indeed for portability<br>
it's the best target currently...</blockquote><div><br></div><div>None of these are absolutely unsolvable. Your design choices for structures could be ported to the CFFI backend so that it no longer relies on function calls to access foreign data, but rather creates C-INLINE forms. The same thing could be said about foreign functions. But this needs somebody to sit and carefully study how to modify CFFI to add these improvements -- and whether it is actually possible or changes in the API/semantics are required.</div>
<div><br></div><div>Juanjo</div></div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>