Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

constructor/accessor API to be friendlier to non-C languages? #86

Closed
stevengj opened this issue Apr 7, 2021 · 2 comments · Fixed by #89
Closed

constructor/accessor API to be friendlier to non-C languages? #86

stevengj opened this issue Apr 7, 2021 · 2 comments · Fixed by #89

Comments

@stevengj
Copy link
Contributor

stevengj commented Apr 7, 2021

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.

cc @fverdugo, @blegat

@blegat
Copy link

blegat commented May 5, 2021

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.

@cbbarber
Copy link
Collaborator

Good idea. On the list for the next version (2022 or 2023).

Please consider suggesting code changes or creating a pull request.

                           --Brad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants