<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
On 24.03.2011 20:10, Eliot Miranda wrote:
<blockquote
cite="mid:AANLkTi=0PXue5RHo-CsnqDZV4oVnH8JL7M8uaBO79DKq@mail.gmail.com"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<br>
<br>
<div class="gmail_quote">On Thu, Mar 24, 2011 at 12:02 PM, Igor
Stasenko <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span>
wrote:<br>
<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>
On 24 March 2011 19:43, Eliot Miranda <<a
moz-do-not-send="true"
href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>
wrote:<br>
><br>
><br>
><br>
> 2011/3/24 Levente Uzonyi <<a moz-do-not-send="true"
href="mailto:leves@elte.hu">leves@elte.hu</a>><br>
>><br>
>><br>
>> On Thu, 24 Mar 2011, Eliot Miranda wrote:<br>
>><br>
>> (pine can't quote your mail, sorry)<br>
><br>
> :) No problem.<br>
><br>
>><br>
>> "I have some image-level changes that I'll try and
commit asap, or at least give you as some inbox packages<br>
>> - parsing FFI method annotations to discover the
#threaded keyword that sets the "go ahead and thread this
call" bit in an FFI spec<br>
>> - an additional inst var in ExternalFunction (IIRC)
that allows the VM to record how much stack space to reserve
when marshalling an FFI call<br>
>> - the new callback marshalling machinery that
provides platform-independence<br>
>><br>
>> I just need to fid the time to push the code to
you.<br>
>><br>
>> Now on testing I use<br>
>> a) an image with a "listener" that reads and writes
from/to stdin/out while allowing one to interact with the
image<br>
>> b) a native Mac OS file dialog that uses a threaded
call to invoke without blocking the image and threaded
callbacks to determine which files to<br>
>> show (filter callback) and what the accept action
is. I've of course lost my workspace containing this and so
have to ferret out the doits from my<br>
>> changes file (I feel such a fool!). Alas this will
need work as it used an extension to a Teleplace native file
dialog plugin. But posting it to<br>
>> FFI will be good; it will test the FFI further.<br>
>> c) a threaded version of the ODBC connect that
hasn't really been tested<br>
>><br>
>> etting you and others to start pounding on these
would be fantastic. Just a matter of finding time. f
you're happy for me to push inbox packages,<br>
>> changesets, workspace contents then I can provide
something quickly. If you want me to commit canges that
I've made sure are backward compatible<br>
>> and don't break trunk I'm going ot be much slower.<br>
>><br>
>> best regards (albeit feeling a little frazzled :-)
),<br>
>> Eliot"<br>
>><br>
>> Isn't it the best time to migrate the syntax of FFI
calls to Pragmas? I know it takes some time to implement the
pragma support, but IIRC Lukas did that a few years ago, so
dusting it off and adding support for threaded calls (which
I didn't see yet) shouldn't be that hard.<br>
><br>
</div>
+1000.<br>
<div class="im"><br>
> SPunds good. Got any URLs? Lukas, got any code?<br>
><br>
>><br>
>> Both formats could be supported for a while, then
we could leave the current format behind and simplify the
parsers/compilers, etc.<br>
><br>
</div>
+1<br>
<div class="im"><br>
> Indeed. In fact, nothing is set in stone here. I
desperately want an accurate C signature, not the quick hack
we have now (a good thing we have a quick hack, but its a
long way short of copy/pasting C into the pragma). The
interpreted marshalling scheme Andreas did (ffi specs etc)
can serve for the moment. The main thing before getting rid
of that is a design for e.g. a NativeBoost based marshalling
code generator that is cross-platform, cross-ABI and works
with the interpreted VMs. I think this is therefore a good
way off, and there are people like Esteban who need to get
going now, so we can't let the perfect be the enemy of the
good and need to provide something functional asap, and that
may mean living with the current ffi annotation for a few
months.<br>
<br>
</div>
In NativeBoost i made a separate class for parsing a C
function<br>
declaration. It supports two forms of declaration:<br>
- named function, i.e.<br>
int foo (int bar, float zork)<br>
and anonymous one:<br>
int (int bar, float zork)<br>
<br>
as input, parser takes a literal array.<br>
<br>
So its quite easy to integrate it into compiler/pragma parser,
we only<br>
need to find out what format will work for us.<br>
<br>
so, it could be something like:<br>
<br>
<cdecl: #( int foo (int bar , float baz )) module:
#myModule><br>
<br>
or:<br>
<ffi: #( cdecl int foo ... ) module: ... ><br>
</blockquote>
<div><br>
</div>
<div>This is such a fascinating hack. e.g.</div>
<div><br>
</div>
<div>#(int (*compar)(const void *, const void *))</div>
<div> #(#int #(#* #compar) #(#const #void #*, #const #void
#*))</div>
<div><br>
</div>
<div>#(int (struct { field : 8; fence : 8; gate: 16; } arg))</div>
<div> #(#int #(#struct #'{' #field #':' 8 #';' #fence #':' 8
#';' #gate: 16 #';' #'}' #arg))</div>
<div><br>
</div>
<div>Can anyone prove that Igor's approach works for all C
signatures? What about other languages?</div>
<div><br>
</div>
<div>I find this is like really dirty sex, repellent and
irresistible at one and the same time.</div>
</div>
</blockquote>
Thank you for putting words to my feeling at the time I suggested it
:)<br>
Don't know if it works for every signature though, only the examples
he gave of the old format :/<br>
<br>
Cheers,<br>
Henry<br>
</body>
</html>