Hi Ben, I will take a better look tomorrow morning, but as first sight, seems to be that you want to declare SomeObject and receive it as argument to the callback, while you are receiving just an ExternalAddress. If is that the problem what happens is that callbacks do not handle *any type* as the rest of UFFI… they just handle standard C types, so you will receive an ExternalAddress isn’t? You need to obtain the actual object as you need it. I see two strategies:
1) just create the object using SomeObject>>#fromHandle: This work fine if object is stateless and just want to access it’s defined vocabulary. 2) or… you can just caché the data someplace and then find it using the ExternalAddress as index. (I hope I interpreted the problem correctly… I’m a bit sleep here :P) cheers, Esteban > On 24 Sep 2016, at 19:40, Ben Coman <[email protected]> wrote: > > I'm seeking some support for Part 5 of my FFI tutorial > http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-5-client-data-and-recursive-visitorcallbacks/ > > where I'm trying to replicate some C code where: > * client_data is a void pointer, and an argument to a callout function > * a reference to some data (an int, or a struct) is passed to the > callout function as the client_data > * the callout function passes that same client_data to a callback > function which casts the client-data to the required type > > How can I replicate that with UFFI? The key thing is that *any* type > can be passed via client_data. So for a normal Pharo object defined > like... > > Object subclass: MyObject > instanceVariables: 'x y' > > myobject := MyObject new x:3 y:4. > > I want to pass a reference to myobject to the callout, and in the > callback dereference client_data to get myobject that I can operate on > normally. > > Is this possible with current infrastructure, or would it need > something new like FFIInternalPinnedReference to wrap myobject for the > callout and unwrap it in the callback? > > cheers -ben >
