Alternative and more direct way to interface to p4est/t8code

[jmark]

This issue is just FYI and open for discussion.

Idea: Instead of relying on 3rd-party packages for generating interfaces to C libraries we write them "manually" by ourself and are indepentent and have direct control. Compilation is much faster (nearly non-existent), too.

I also pieced together a macro for convient function signature description.

An example how this looks like can be found under:

https://github.com/jmark/T8code.jl/blob/main/examples/playground/2d_box_ccall.jl

[ranocha]

Would the resulting code be substantially different from code generated via Clang.jl?

[jmark]

I do not know. Haven't looked into Clang.jl.

[ranocha]

Yeah. The mental model of the Clang.jl approach is also very similar - we would just use Clang.jl to generate an initial Julia wrapper that we can tune manually to our needs from there on. It should just remove a bit of tedious manual work. But I am totally open to skip this step, too, if it's simpler.

[ranocha]

What's your take on this, @sloede?

[sloede]

One potential advantage of Clang.jl is that it also handles macros (at least "sane" ones) and structs. How would you handle those?

Another potential advantage of Clang.jl-generated bindings is that the bindings are actually "human readable" with concrete line numbers, which makes it potentially easier to debug them. I wonder what kind of error message you get right now if, e.g., you use a wrong argument type, and if it is still possible for a non-expert user to understand what needs to be changed to fix it.

[jmark]

One potential advantage of Clang.jl is that it also handles macros (at least "sane" ones) and structs. How would you handle those?

You implement and document macros and structs manually. This works just fine.

Another potential advantage of Clang.jl-generated bindings is that the bindings are actually "human readable" with concrete line numbers, which makes it potentially easier to debug them.

Not exactly sure what you mean by that, but I get the feeling that this statement contests the use of macros in Julia. :)

I wonder what kind of error message you get right now if, e.g., you use a wrong argument type, and if it is still possible for a non-expert user to understand what needs to be changed to fix it.

The error message is not that bad. Not on point, but with proper documentation the user will steer through the swamp.

Example:

# This calls a 't8code' function which takes a c-pointer and an int32 and returns a c-pointer.
@t8_ccall(t8_cmesh_new_periodic, Ptr{Cvoid}, comm :: Ptr{Cvoid}, ndim :: Cint)

# If the user calls it with a float64 ...
cmesh = t8_cmesh_new_periodic(mpi_com().val, 42.123)
# ... you get the following error output:

ERROR: LoadError: InexactError: Int32(2.1)
Stacktrace:
 [1] Int32
   @ ./float.jl:791 [inlined]
 [2] convert
   @ ./number.jl:7 [inlined]
 [3] cconvert
   @ ./essentials.jl:417 [inlined]
 [4] t8_cmesh_new_periodic(comm::Ptr{Nothing}, ndim::Float64)
   @ Main ~/codes/T8code.jl/examples/playground/2d_box_ccall.jl:48
 [5] top-level scope
   @ ~/codes/T8code.jl/examples/playground/2d_box_ccall.jl:454
in expression starting at /home/jmark/codes/T8code.jl/examples/playground/2d_box_ccall.jl:454

At least you get the proper name of the routine and you can then look up the correct use in the documentation.

[jmark]

We're using Clang.jl for binding generation.