<br><br><div class="gmail_quote">2011/3/24 Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu">leves@elte.hu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>On Thu, 24 Mar 2011, Eliot Miranda wrote:<br>
<br>
(pine can't quote your mail, sorry)<br></blockquote><div><br></div><div>:) No problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
</blockquote><div><br></div><div>SPunds good. Got any URLs? Lukas, got any code?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Both formats could be supported for a while, then we could leave the current format behind and simplify the parsers/compilers, etc.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>best,</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
Levente<br></blockquote></div><br>