Eliot,
It turns out that I had already done the #fromInteger: game, but your reply/confirmation gave me a brief second wind. I added #asExternalAddress (doing the obvious thing given your reply) to both callback thunks and to GSL memory objects (handle bodies that
have subclasses for vectors, wavelet entrails, etc.). I took one FFI call parameter from long to struct*. That was interesting, because getHandle asInteger was giving me a *huge* number; the struct* argument worked where long failed me (it's usually the other
way around).
I am now at the point of getting an error in a method being called from a callback!!! That's a nice problem to have :) Somehow, I have to figure out how to get one of my handle bodies wrapped around an Alien argument. Whatever I do will also want to work
with non-aliens because I call (with some trickery) the same method myself to generate sample data.
As Sig said, the debugger is available inside of callbacks - that's going to be a huge help. It's time to shut down for the day or I will hate myself in the morning.
More to come. Thanks!!!!
Bill
From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda@gmail.com]
Sent: Wednesday, March 21, 2012 8:18 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Alien callback thunk as ExternalAddress?
On Wed, Mar 21, 2012 at 4:01 PM, Schwab,Wilhelm K
<bschwab@anest.ufl.edu> wrote:
I am getting near to jumping off the callback cliff. My problem is that I have a generated external structure that expects a void pointer (actually a function pointer). The setter
sends #getHandle. I tried to hot-wire that by defining CallbackThunk>>getHandle to answer the #address.
But FFICallbackThunk already implements address (inherited from Alien). Why getHandle?
Is there a way to get an ExternalAddress that points to the thunk? Should I even be asking this question? :)
I *think* it should be
ExternalAddress new fromInteger: anFFICallbackThunk address
--
best,
Eliot