arrays with FFI structs
Locked
 
|
Are arrays within structs handled? I have a C type declaration...
typedef struct { enum CXCursorKind kind; int xdata; const void *data[3]; } CXCursor; which for the moment I've simplified the enum and defined... FFIExternalStructure subclass: #CXCursor instanceVariableNames: '' classVariableNames: '' package: 'Libclang' CXCursor class >> fieldsDesc "self rebuildFieldAccessors" ^ #( int kind; int xdata; void *data[3]; ) an evaluated... CXCursor rebuildFieldAccessors but it produces... Error: Unable to resolve external type: [ So it seems arrays inside structs are currently not handled ? Now I read the typedef as "data is an array of three pointers to void", so how likely is it for something like this to work... CXCursor class >> fieldsDesc "self rebuildFieldAccessors" ^ #( int kind; int xdata; void *data1; void *data2; void *data3; ) I'll experiment some more in the meantime. cheers -ben |
|
|
not very well (I didn’t adapted the parser or optimised it, but it works fine :P).
you need to declare a type: CXCursor class>>initiallize VoidPointer3 := FFITypeArray ofType: ‘void*’. then you declare: CXCursor class >> fieldsDesc "self rebuildFieldAccessors" ^ #( int kind; int xdata; VoidPointer3 data; ) that should work (never tried with void*, but I do not see why wouldn’t work) cheers, Esteban ps: and yes, the idea is to extend the parser for doing this… but no time :( > On 09 Sep 2016, at 19:11, Ben Coman <[hidden email]> wrote: > > Are arrays within structs handled? I have a C type declaration... > > typedef struct { > enum CXCursorKind kind; > int xdata; > const void *data[3]; > } CXCursor; > > which for the moment I've simplified the enum and defined... > > FFIExternalStructure subclass: #CXCursor > instanceVariableNames: '' > classVariableNames: '' > package: 'Libclang' > > CXCursor class >> fieldsDesc > "self rebuildFieldAccessors" > ^ #( > int kind; > int xdata; > void *data[3]; > ) > > an evaluated... > CXCursor rebuildFieldAccessors > > but it produces... Error: Unable to resolve external type: [ > So it seems arrays inside structs are currently not handled ? > > Now I read the typedef as "data is an array of three pointers to > void", so how likely is it for something like this to work... > > CXCursor class >> fieldsDesc > "self rebuildFieldAccessors" > ^ #( > int kind; > int xdata; > void *data1; > void *data2; > void *data3; > ) > > I'll experiment some more in the meantime. > > cheers -ben > |
|
|
by the way, this is a new feature of UFFI… old NB didn’t have it :)
> On 09 Sep 2016, at 19:17, Esteban Lorenzano <[hidden email]> wrote: > > not very well (I didn’t adapted the parser or optimised it, but it works fine :P). > you need to declare a type: > > CXCursor class>>initiallize > VoidPointer3 := FFITypeArray ofType: ‘void*’. > > then you declare: > > CXCursor class >> fieldsDesc > "self rebuildFieldAccessors" > ^ #( > int kind; > int xdata; > VoidPointer3 data; > ) > > that should work (never tried with void*, but I do not see why wouldn’t work) > > cheers, > Esteban > > ps: and yes, the idea is to extend the parser for doing this… but no time :( > >> On 09 Sep 2016, at 19:11, Ben Coman <[hidden email]> wrote: >> >> Are arrays within structs handled? I have a C type declaration... >> >> typedef struct { >> enum CXCursorKind kind; >> int xdata; >> const void *data[3]; >> } CXCursor; >> >> which for the moment I've simplified the enum and defined... >> >> FFIExternalStructure subclass: #CXCursor >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'Libclang' >> >> CXCursor class >> fieldsDesc >> "self rebuildFieldAccessors" >> ^ #( >> int kind; >> int xdata; >> void *data[3]; >> ) >> >> an evaluated... >> CXCursor rebuildFieldAccessors >> >> but it produces... Error: Unable to resolve external type: [ >> So it seems arrays inside structs are currently not handled ? >> >> Now I read the typedef as "data is an array of three pointers to >> void", so how likely is it for something like this to work... >> >> CXCursor class >> fieldsDesc >> "self rebuildFieldAccessors" >> ^ #( >> int kind; >> int xdata; >> void *data1; >> void *data2; >> void *data3; >> ) >> >> I'll experiment some more in the meantime. >> >> cheers -ben >> > |
|
|
In reply to this post by Ben Coman
On Sat, Sep 10, 2016 at 01:11:18AM +0800, Ben Coman wrote:
> Are arrays within structs handled? I have a C type declaration... Ben, Is it possible to write C functions to manipulate these structures, build these functions into a shared library, and call the functions from Pharo? More "object oriented", heh. Of course I've only just had a cursory glance at libclang while typing this reply and don't know what your usage is. Pierce |
|
|
On Sat, Sep 10, 2016 at 8:47 AM, Pierce Ng <[hidden email]> wrote:
> On Sat, Sep 10, 2016 at 01:11:18AM +0800, Ben Coman wrote: >> Are arrays within structs handled? I have a C type declaration... > > Ben, > > Is it possible to write C functions to manipulate these structures, build these > functions into a shared library, and call the functions from Pharo? Maybe. Particularly since my next challenge is to use a callback. My usage is parsing the VM platform C files as a one-shot import to analyse from Pharo, so doing most of the legwork in C and returning just the final result to Pharo may be fine. However at the moment my goal is as much about learning to use FFI, so I'll push in that direction as long as I can. > More "object oriented", heh. Actually "clang" is OO being written in C++. But I understand the C++ name mangling makes life difficult for our FFI. "libclang" is the plain-C wrapper interface of "clang", which also is advertised as more stable, with clang advertised as often changing. Apparently libclang can't access all of clang's features, but I think it will be a while before I reach the point of discovering the impact of that, and it may well be outside my requirements. cheers -ben > Of course I've only just had a cursory glance at > libclang while typing this reply and don't know what your usage is. > > Pierce > |
|
|
With UFFI, what you’ll do for “being OO” is to:
1) extend FFIExternalStructure 2) then use your class adding methods that use the structure into it (using “self” as argument). For example: FFIExternalStructure subclass: #MyStruct. MyStruct>>#method1: arg ^ self ffiCall: #(int function1(self, arg1)) (and example of this can be found on AthensCairoMatrix in image). cheers, Esteban ps: in Pharo5, you may want to update to latest UFFI (not *needed* but better… I need to make a new Pharo5 build with updated versions) > On 10 Sep 2016, at 04:41, Ben Coman <[hidden email]> wrote: > > On Sat, Sep 10, 2016 at 8:47 AM, Pierce Ng <[hidden email]> wrote: >> On Sat, Sep 10, 2016 at 01:11:18AM +0800, Ben Coman wrote: >>> Are arrays within structs handled? I have a C type declaration... >> >> Ben, >> >> Is it possible to write C functions to manipulate these structures, build these >> functions into a shared library, and call the functions from Pharo? > > Maybe. Particularly since my next challenge is to use a callback. My > usage is parsing the VM platform C files as a one-shot import to > analyse from Pharo, so doing most of the legwork in C and returning > just the final result to Pharo may be fine. However at the moment my > goal is as much about learning to use FFI, so I'll push in that > direction as long as I can. > >> More "object oriented", heh. > > Actually "clang" is OO being written in C++. But I understand the C++ > name mangling makes life difficult for our FFI. "libclang" is the > plain-C wrapper interface of "clang", which also is advertised as more > stable, with clang advertised as often changing. Apparently libclang > can't access all of clang's features, but I think it will be a while > before I reach the point of discovering the impact of that, and it may > well be outside my requirements. > > cheers -ben > >> Of course I've only just had a cursory glance at >> libclang while typing this reply and don't know what your usage is. >> >> Pierce >> > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |