You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to have an API for libqhull_r that is easier to call from non-C languages that can call out to compiled C libraries (e.g. Python's ctypes or Julia's ccall), but which can't parse C header files. This seems to require two things:
add create/destroy methods for allocating a pointer to a struct qhT, which is a huge datastructure whose size is hard to predict without running a C compiler, particularly as it has numerous jmp_buf fields (whose size is OS-dependent and perhaps compiler-dependent).
add accessor functions that take a qhT* and allow you to get fields that are part of the documented API / externally useful (as opposed to stuff that is only used internally by qhull). You could maybe have a callback API for things like FORALLpoints, but those data structures are not as terrible as qhT* to access externally.
For example, Julia has a relatively simple way to add dependencies on compiled binary packages, and in fact already has precompiled binaries of Qhull built for all supported platforms. This would make it easy for Julia packages to depend on Qhull with automated installation, even on user systems that don't have a C compiler, except that it's currently not possible to call Qhull without having a C compiler handy to parse the header file. (e.g. pyhull needs a C compiler.) One way around this is to build our own C wrapper library and distribute that (gridap/MiniQhull.jl#5), but it seems much more natural to include such an API into Qhull itself.
Is this something you would be interested in? If so, I and others could work on a PR.
I agree, currently https://github.com/JuliaPolyhedra/QHull.jl is using qhull through scipy for these reasons. If this issue is resolved then QHull.jl could use the precompiled binary that is easily accessible in Julia on all platforms as mentioned in the previous post and use the C API instead which would remove the dependency on scipy and allow more flexibility that why scipy provides.
It would be nice to have an API for libqhull_r that is easier to call from non-C languages that can call out to compiled C libraries (e.g. Python's
ctypes
or Julia'sccall
), but which can't parse C header files. This seems to require two things:add
create/destroy
methods for allocating a pointer to astruct qhT
, which is a huge datastructure whose size is hard to predict without running a C compiler, particularly as it has numerousjmp_buf
fields (whose size is OS-dependent and perhaps compiler-dependent).add accessor functions that take a
qhT*
and allow you to get fields that are part of the documented API / externally useful (as opposed to stuff that is only used internally by qhull). You could maybe have a callback API for things likeFORALLpoints
, but those data structures are not as terrible asqhT*
to access externally.For example, Julia has a relatively simple way to add dependencies on compiled binary packages, and in fact already has precompiled binaries of Qhull built for all supported platforms. This would make it easy for Julia packages to depend on Qhull with automated installation, even on user systems that don't have a C compiler, except that it's currently not possible to call Qhull without having a C compiler handy to parse the header file. (e.g. pyhull needs a C compiler.) One way around this is to build our own C wrapper library and distribute that (gridap/MiniQhull.jl#5), but it seems much more natural to include such an API into Qhull itself.
Is this something you would be interested in? If so, I and others could work on a PR.
cc @fverdugo, @blegat
The text was updated successfully, but these errors were encountered: