Add BinDeps to REQUIRE about clang.jl HOT 11 CLOSED

Will do tonight, thanks for the report (I mistakenly thought BinDeps was a default part of the package manager).

Also I haven't added documentation for wrap_c yet, so if you are using this then start from the wrap_$name drivers here:
https://github.com/ihnorton/libAV.jl/tree/master/src
https://github.com/ihnorton/libXML2.jl/tree/master/src

from clang.jl.

You're right ahead of me! I was just going to ask for documentation on wrap_c. I tried to copy and modify your driver code for libXML2, but it appears that the interface to wrap_c has changed since it was written? I took a guess at calling wrap_c.wrap_c_headers, but got a segfault. Might be because I was calling it in the wrong way.

from clang.jl.

Anyway, great work! I can hardly wait to use this.

from clang.jl.

Ah, just realized that it is the version that installed with the package manager that is lagging behind. Will give at try with master.

from clang.jl.

Sorry, should have mentioned that - the cindex part has been very stable, but I haven't bumped the package version yet because wrap_c has been in flux.

If you have a chance, I would be very grateful for any comments on the @c macro. I haven't profiled it yet, but am wondering if there is any obvious inefficiency. Loading all 1600 functions in libXML2 takes longer than I would like, and I don't know if this is due to the macro evaluation overhead or something else (does JIT run when the macro is evaluated?)

from clang.jl.

I see. Ok, now I get some output! I'll have to read up on the library that I'm trying to wrap before I can try it out :)
I'll see if I can get some time to look at the @c macro.

from clang.jl.

Another thought: I'm not sure that you need to have @c as a macro. Why not run the code generation that @c does at binding creation time, and pretty print the produced AST to the target .jl file instead? You can use Base.show_unquoted to pretty print an AST unquoted. The pretty printing seems to be able to round trip most ASTs; I think it should be able to handle yours. (Otherwise, open an issue at Julia, and I'll see if I can fix it.) If it is the macro that does take the time, this should show it. I hope that the output should be pretty readable, too.

from clang.jl.

Fixed: JuliaLang/METADATA.jl#141

from clang.jl.

Regarding the macro, the main reason I used that was to make the wrappers semi-readable. I'll try timing with pretty-printed versions to see if that makes a difference.

from clang.jl.

Thanks!
Readability is a good thing. I have no idea which version will be more readable. If the the expanded version is not much longer, it will allow me to understand what's going on without having to understand what the @c macro does.

Anyway, I looked a little bit at the @c macro. The first thing that strikes me is that you are using quite a lot of eval, which might well account for a great deal of the execution time. It might also be wrong -- using eval like this evaluates expressions in the context of the macro definition, not the invocation.

I don't quite understand what the code does. What are the evals for? If I understood the code, I could probably come up with an eval-free alternative. Do you have an example of input to @c and the expected corresponding output? Also, what does recurs_sym_type do?

from clang.jl.

I did some testing with variations of the macro, and found some impact of removing the eval (~1.99s with vs ~1.86s without):

https://github.com/ihnorton/libXML2.jl/commits/macro_perf_test

Regardless, I agree that it should go (100x chalkboard: I must not eval in a macro... I must not eval in a macro...). The original reason for the eval and recurs_sym_type was this kind of signature:

@c xmlEntityPtr xmlAddDtdEntity (xmlDocPtr,Ptr{:xmlChar},Int32,Ptr{:xmlChar},Ptr{:xmlChar},Ptr{:xmlChar}) libxml2

where the ":xmlChar" and other symbols are (eventually) typealiases defined before the function. I used symbols in order to avoid instantiating these as real typealiases in the generator environment. recurs_sym_type just descends into something like Ptr{Ptr{:xmlChar}} and evals the inner symbol.

Anyway, this was a bad design and I will get rid of the symbols in the generated code, which will allow to remove all of the evals.

from clang.jl.