On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
Hi,
sorry for not sending before: work is hard :P yes, that should work, and no, I don't know a better way to define it.
No it won't work. See my message.
I think Eliot's idea is to form "libraries" of generic callbacks (for mars, for instance, I have CocoaCallback, child of Callback, who defines all my needed signatures, looks a lot at first instance, but if you see in detail, finally there are not so much variants)
Yes, the idea is to have a library of signature methods that marshal specific C callback signatures to/from Smalltalk blocks. The pragma specifies what ABI (application binary interface, or stack layout) the signature is for so that the scheme is cross-platform. But I expect that these signature methods could be the output of an ABI compiler, so that one wouldn't have to write them by hand. The pragma doesn't need to include a word-size since IA64 is a different ABI to IA32, and so the ABI subsumes word size. HTH
best, Esteban
El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribió:
Esteban,
Will this work? Even if so, is there a better way to define it?
longVoidStarLongRetInt: callbackContext sp: spAlien <signature: 'int (*) (long, void *, long)' abi: 'IA32'> ^callbackContext wordResult: (block value: (Alien newC:4) value: (Alien forPointer: (spAlien unsignedLongAt: 5)) value: (Alien newC:4) )
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Thursday, March 01, 2012 12:15 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI on 1.3: compile fields
thanks!!!!!
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm@gmail.com] Sent: Wednesday, February 29, 2012 10:18 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI on 1.3: compile fields
you need to define a signature... not at home now, but wait 'til tomorrow and I'll send an example
best, Esteban
El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribió:
What does "cannot find callback signature" mean from #signature:block:? I'm stuck.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm@gmail.com] Sent: Wednesday, February 29, 2012 6:54 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI on 1.3: compile fields
yeah... sorry about that is a bug on FFI... I managed to worked around it for HPDF, for a customer's project... but of course is not a good and definitive solution.
best, Esteban
El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribió:
This is gonna take a while... I had structs flying around as void* and was moderately happy. Nonetheless, your suggestion worked, provided I add a lot getHandle asInteger and change the void* to long :(
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm@gmail.com] Sent: Wednesday, February 29, 2012 6:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI on 1.3: compile fields
I also found some problems using void* in linux... maybe you want to use long (which has same size)... I "fixed" my problems that way.
yes... maybe we need to look at FFI to see why void* has problems some times, but well, that can help you atm (sorry for not having a better answer)
Esteban
El 29/02/2012, a las 8:11p.m., Igor Stasenko escribió:
On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Another glitch: is there any problem passing things as void*? I'm getting failure to coerce errors that did not arise before.
No idea. As you may suspect, i stopped using FFI/Alien once i got NativeBoost toy to play with.
Please file the issue, describing the problem. so we can look over it and fix it.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [ siguctua@gmail.com]
Sent: Wednesday, February 29, 2012 5:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI on 1.3: compile fields
On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Does 1.3 by default not create field accessors? Why is that? I thought nothing was happening.
Good question, i'd like to know the answer too. It is related to MC final 'installation' phase, where it initializing all classes.
In NativeBoost i was also using
noteCompilationOf: aSelector meta: isMeta "A hook allowing some classes to react to recompilation of certain selectors"
but there was a big question, at which point this hook is triggered, and looks like some changes in MC stop triggering it/triggering at wrong time (not all methods get into a class/ class not initialized etc), which makes it not very useful.
So i ended up creating a DNU handler on instance side, then on DNU i check if i have field accessors and if not, compile them on the fly.
Bill
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- best, Eliot