I have found the problem with VoidPointer3 generating accessors. No idea how to contribute back a fix but this is what I've found. FFITypeArrayType>>annonymousClassCreator ^ String streamContents: [ :stream | stream nextPutAll: '(FFITypeArray ofType: '; print: (self objectClass type isPointer ifTrue: [self externalTypeWithArity printString] ifFalse: ['#',self objectClass type class]); nextPutAll: ' size: '; print: self objectClass numberOfElements; nextPutAll: ')' ] Recalling that we are trying to come up with an accessor that can pull out a void*[3], this produces '(FFITypeArray ofType: #FFIVoid size: 3)' which produces an error as FFIVoid's size is undefined. In general, this will be wrong for any pointer type and will probably get the size calculation wrong. Doing a little digging I find that FFITypeArray>>ofType: aType size: aSize delegates resolution of aType to FFIExternalType>>resolveType:aType and this can take all kinds of different things including the native type name. It would be better if this generated the native name for pointers. (FFITypeArray ofType: 'void*' size: 3) So I changed it to: FFITypeArrayType>>annonymousClassCreator ^ String streamContents: [ :stream | stream nextPutAll: '(FFITypeArray ofType: '; print: (self objectClass type isPointer ifTrue: [self externalTypeWithArity printString] ifFalse: ['#',self objectClass type class]); nextPutAll: ' size: '; print: self objectClass numberOfElements; nextPutAll: ')' ] and this seems to work fine. Onwards...
On Oct 19, 2017, at 7:18 AM, Todd Blanchard <tblanchard@mac.com> wrote:
Thatâs great - itâs been kind of magical but a couple things have changed since you wrote it and some bugs have crept into ffi.
Right now Iâm finding the generated accessor for the VoidPointer3 is actually generating a void 3 accessor and that doesnât work. I spent all day yesterday tracking it to the accessor generating code.
Sent from the road
On Oct 18, 2017, at 22:29, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <tblanchard@mac.com <mailto:tblanchard@mac.com>> wrote: I'm working through Ben's great blog post about playing with libclang and I am puzzled by something.
Thx Todd. Knowing someone is looking at it encourages me to expand it. I'm interested in looking at your specific questions, but it might not be until next week after this stint of long work days.
cheers -ben
invalidateSessionData handle atAllPut: 0.
zero;s out the handle. Cool. However,
handle isNull
does not return true despite it being used in the getString method as
^ handle isNull ifTrue: ['external memory invalidated by session restart'] ifFalse:[LibClang clang_getCString__cxString: self].
Looks like there should be an isNull on ByteArray that returns true if all bytes are zero but it isn't there. Was it dropped for some reason?
On Oct 18, 2017, at 2:58 AM, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
Sure the documentation could be better, that is definetly important, but is already good enough and UFFI is a very technical subject much more suited to a mailing list . Its not physical possible to cover the massive potential of UFFI.
On Wed, Oct 18, 2017 at 9:32 AM Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Please do not hesitate to do Pull Requests. Luc told me that he wants to do a pass on it and Esteban promises that to me but he is super busy.
Stef
On Wed, Oct 18, 2017 at 5:54 AM, Todd Blanchard <tblanchard@mac.com <mailto:tblanchard@mac.com>> wrote:
Wonderful! Thanks.
On Oct 17, 2017, at 3:45 PM, stephan <stephan@stack.nl <mailto:stephan@stack.nl>> wrote:
On 17-10-17 23:06, Todd Blanchard wrote:
Anyone know what happened to this? https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres...>
https://github.com/SquareBracketAssociates/Booklet-uFFI <https://github.com/SquareBracketAssociates/Booklet-uFFI>
has a link to a bintray pdf download
Stephan