I did not - had no idea it existed. Is if fair to say that the 32 bit warning in the readme does not apply to Pharo 64 bit?
> On Oct 25, 2017, at 7:35 AM, Esteban Lorenzano <[email protected]> wrote: > > :) > > Did you look at this project: > https://github.com/estebanlm/libclang-pharo-bindings/ > <https://github.com/estebanlm/libclang-pharo-bindings/> ? > > it was using parseTranslationUnit (no 2)… there you can find how is being > used (I just converted it to tonel format, but older versions are in filetree) > > Esteban > >> On 24 Oct 2017, at 19:17, Todd Blanchard <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hey Esteban, >> >> Now that you have outed yourself as a maintainer of FFI, I have a question. >> :-) >> >> I want to call the libclang function: >> >> /** >> * \brief Parse the given source file and the translation unit corresponding >> * to that file. >> * >> * This routine is the main entry point for the Clang C API, providing the >> * ability to parse a source file into a translation unit that can then be >> * queried by other functions in the API. This routine accepts a set of >> * command-line arguments so that the compilation can be configured in the >> same >> * way that the compiler is configured on the command line. >> * >> * \param CIdx The index object with which the translation unit will be >> * associated. >> * >> * \param source_filename The name of the source file to load, or NULL if the >> * source file is included in \c command_line_args. >> * >> * \param command_line_args The command-line arguments that would be >> * passed to the \c clang executable if it were being invoked out-of-process. >> * These command-line options will be parsed and will affect how the >> translation >> * unit is parsed. Note that the following options are ignored: '-c', >> * '-emit-ast', '-fsyntax-only' (which is the default), and '-o \<output >> file>'. >> * >> * \param num_command_line_args The number of command-line arguments in >> * \c command_line_args. >> * >> * \param unsaved_files the files that have not yet been saved to disk >> * but may be required for parsing, including the contents of >> * those files. The contents and name of these files (as specified by >> * CXUnsavedFile) are copied when necessary, so the client only needs to >> * guarantee their validity until the call to this function returns. >> * >> * \param num_unsaved_files the number of unsaved file entries in \p >> * unsaved_files. >> * >> * \param options A bitmask of options that affects how the translation unit >> * is managed but not its compilation. This should be a bitwise OR of the >> * CXTranslationUnit_XXX flags. >> * >> * \param[out] out_TU A non-NULL pointer to store the created >> * \c CXTranslationUnit, describing the parsed code and containing any >> * diagnostics produced by the compiler. >> * >> * \returns Zero on success, otherwise returns an error code. >> */ >> enum CXErrorCode >> clang_parseTranslationUnit2(CXIndex CIdx, >> const char *source_filename, >> const char *const *command_line_args, >> int num_command_line_args, >> struct CXUnsavedFile *unsaved_files, >> unsigned num_unsaved_files, >> unsigned options, >> CXTranslationUnit *out_TU); >> >> The parts I'm not clear on are turning an array or ordered collection of >> strings into an argv/argc, turning an array of CXUnsavedFile's >> (FFIExternalStruct) into an array of pointers and count, and getting data >> back in an output argument as CXTranslationUnit which is an opaque pointer >> to a C++ object. >> >> Any tips on these mappings would be great. I've currently guessed it as: >> >> clang_parseTranslationUnit__cxIndex: cxIndex source: sourceFile arguments: >> argv unsavedFiles:unsaved options: opts >> >> | argc unsaved_files num_unsaved_files options error out_TU | >> argc := argv size. >> unsaved_files := unsaved ifNil: [ #() ] ifNotNil: [ unsaved ]. >> num_unsaved_files := unsaved_files ifNil: [ 0 ] ifNotNil: >> [unsaved_files size]. >> options := opts sum. >> >> error := self ffiCall: #(CXErrorCode >> clang_parseTranslationUnit2(CXIndex cxIndex, >> String sourceFile, >> String *argv, >> uint argc, >> CXUnsavedFile *unsaved_files, >> uint num_unsaved_files, >> CXTranslationUnitFlag options, >> >> CXTranslationUnit *out_TU)). >> >> (error = CXError_Success) ifTrue: [ ^out_TU ]. >> self error: error >> >> Thanks. >> >> >>> On Oct 22, 2017, at 2:42 AM, Esteban Lorenzano <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, >>> >>>> On 21 Oct 2017, at 21:15, Stephane Ducasse <[email protected] >>>> <mailto:[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] >>>> <mailto:[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] >>>>> <mailto:[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] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <[email protected] >>>>> <mailto:[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] >>>>>> <mailto:[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] <mailto:[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] >>>>>>> <mailto:[email protected]>> >>>>>>> wrote: >>>>>>>> Wonderful! Thanks. >>>>>>>> >>>>>>>>> On Oct 17, 2017, at 3:45 PM, stephan <[email protected] >>>>>>>>> <mailto:[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://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.pdf> >>>>>>>>> >>>>>>>>> https://github.com/SquareBracketAssociates/Booklet-uFFI >>>>>>>>> <https://github.com/SquareBracketAssociates/Booklet-uFFI> >>>>>>>>> >>>>>>>>> has a link to a bintray pdf download >>>>>>>>> >>>>>>>>> Stephan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >
