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> wrote:



On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <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> 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> 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> wrote:
> Wonderful!  Thanks.
>
>> On Oct 17, 2017, at 3:45 PM, stephan <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/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.pdf
>>
>> https://github.com/SquareBracketAssociates/Booklet-uFFI
>>
>> has a link to a bintray pdf download
>>
>> Stephan
>>
>>
>>
>
>