https://pharo.fogbugz.com/f/cases/20574/FFITypeArray-annonymousClassCreator-doesn-t-handle-pointer-types-correctly <https://pharo.fogbugz.com/f/cases/20574/FFITypeArray-annonymousClassCreator-doesn-t-handle-pointer-types-correctly>
There you go. > On Oct 22, 2017, at 2:42 AM, Esteban Lorenzano <[email protected]> wrote: > > Hi, > >> On 21 Oct 2017, at 21:15, Stephane Ducasse <[email protected]> wrote: >> >> Esteban will probably reply to this thread > > yes, I will :) > >> >> >> On Thu, Oct 19, 2017 at 10:34 PM, Todd Blanchard <[email protected]> wrote: >>> I have found the problem with VoidPointer3 generating accessors. > > can you report that on fogbugz ? > (along with your solution) > > thanks! > Esteban > >>> >>> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> >>> >>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> wrote: >>>>>> Wonderful! Thanks. >>>>>> >>>>>>> On Oct 17, 2017, at 3:45 PM, stephan <[email protected]> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > >
