search

JuliaGeometry / Triangle

Upstream source for J. R. Shewchuk's Triangle mesh generator
0 stars 0 forks source link

Duplicate? #1

Closed juliohm closed 1 year ago

juliohm commented 1 year ago

Can you explain why another repository for the Triangle library?

Should we mark some of these repositories as deprecated? Contact authors to join efforts?

j-fu commented 1 year ago

Ok thanks for asking...

Joining efforts, cvdlab/Triangle.jl

A couple of years ago, I contacted the author @furio of https://github.com/cvdlab/Triangle.jl and @konsim83 of https://github.com/konsim83/TriangleMesh.jl see https://github.com/j-fu/VoronoiFVM.jl/issues/2

The idea was to have a wrapper to Triangle which is as close to the "bare metal" of Shewchuk's code as possible. https://github.com/JuliaGeometry/Triangulate.jl emerged from this effort.

Both https://github.com/cvdlab/Triangle.jl and https://github.com/konsim83/TriangleMesh.jl provide "Julian" interfaces to some aspects of Triangle, and something like this appears to have some demand, see e.g. the request of @fonsp: https://github.com/JuliaGeometry/Triangulate.jl/issues/12

I am pretty sure that both Triangle.jl and TriangleMesh.jl could build upon Triangulate.jl, at once solving the build problem for the C source.

Triangulate.jl

This is now the Julia wrapper for the Triangle C code which I maintain. The API is array based and very close to to the API of the C code.

Triangle_jll.jl

This is the jll containing the code used by Triangulate.jl (and which could be used also by the other higher level packages either directly or transitively via Triangulate.jl). I maintain the corresponding build_tarballs.jl .

This repo, JuliaGeometry/Triangle

In the moment, the C source of Triangle is in deps/src of Triangulate.jl , which is not very transparent and workflow-wise hard to track. Moreover, we need some additions and improvements to the C source. This repo is intended to hold the upstream C source + improvements, so that it can work as a GitSource in build_tarballs. Triangle itself has no repo, the definitive source is the shar/zip from netlib.

The situation

I indeed find the situation a bit puzzling. I for my side intend to keep Triangulate.jl going. My primary interest is the array based interface I implemented, so there is plenty of space for packages working on top of that or taking advantage of Triangle_jll.jl.

juliohm commented 1 year ago

What I don't understand is why we need to copy the C code here in the JuliaGeometry organization? Is it really the place? Also is it allowed by the license of the original project? Isn't the Triangle_jll binary enough?

j-fu commented 1 year ago

Well, the binary library is built from the upstream source from netlib + some additions for the Julia wrapper which can be only written in C. So this needs some place to be besides of the upstream download. IMHO, the alternatives are the following: a) Keep netlib as the upstream source (I think this is reliable), check the md5sums of the downloaded stuff. Have patches with sed in the build_tarballs + keep some C sources for wrapping in Yggdrasil/T/Triangle. b) Have the sources git-wise in the Triangulate.jl repo (as it is now) c) Have a dedicated repo for C source+updates as the present one. (I guess there are more cases like this and there might be some canonical place for these repos - I could put this to my github.com/j-fu, but I don't think this is a solution, as these kind of codes should be open to shared maintenance).

What do you suggest ?

Just as a note: I don't expect many (any) update from the author (I contacted him as well but as far as I know him he responds only to interesting requests (this is no criticism) ). His code is battle proven as far as I can tell.

j-fu commented 1 year ago

I have no problem to rename this repo to whatever is more appropriate, e.g. TriangleUpstream .

juliohm commented 1 year ago

I recently built OpenCL_jll and OpenCl_Headers_jll and didn't have to copy the original source to a new repository. I think an approach like that could address your needs?

Em qui., 6 de out. de 2022 20:22, Jürgen Fuhrmann @.***> escreveu:

I have no problem to rename this repo to whatever is more appropriate, e.g. TriangleUpstream .

— Reply to this email directly, view it on GitHub https://github.com/JuliaGeometry/Triangle/issues/1#issuecomment-1270835973, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3J5FFROATX4PVLTK2LWB5NKVANCNFSM6AAAAAAQ7AUM3E . You are receiving this because you authored the thread.Message ID: @.***>

j-fu commented 1 year ago

Yeah but these don't seem to need Julia specific patches and wrappers in C or C++. I entirely can work with a) or b), preferably a) . But this is kind of less transparent for possible other maintainers.

EDIT: and there is a github source.

juliohm commented 1 year ago

What I understand is that the Julia wrapper can be generated automatically with Clang.jl nowadays given te jll package. The only missing part is the patch the you can apply directly in the build_tarballs.jl script?

Em qui., 6 de out. de 2022 20:44, Jürgen Fuhrmann @.***> escreveu:

Yeah but these don't seem to need Julia specific patches and wrappers in C or C++. I entirely can work with a) or b), preferably a) . But this is kind of less transparent for possible other maintainers.

— Reply to this email directly, view it on GitHub https://github.com/JuliaGeometry/Triangle/issues/1#issuecomment-1270847472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3PJRR3YOANYCRDQEMDWB5P53ANCNFSM6AAAAAAQ7AUM3E . You are receiving this because you authored the thread.Message ID: @.***>

j-fu commented 1 year ago

Ok "nowadays" it may be but then again I would ask: does Clang.jl support the passing of a Julia function to be called to C/C++ ? Would take some time for me to figure out to be spent better otherwise, at least in the moment.
And this does not answer the question where to put the patched and updated code: As I see from

https://github.com/JuliaSparse/KLU.jl/blob/c4bea7b5fbc7f3ac13b4880b4a4a38a9a057dc88/gen/generator.jl#L14

there needs to be an artifact with the patched source. So the question would remain: where to put the patched and enhanced upstream source ? I mean what is running now is perfectly working but not very transparent, and having this upstream repo would contribute to help possible maintainers in case I have a bicycle crash...

I have the pleasure to meet @giordano tonight, we will try to find a common position on this over a couple of beers...

j-fu commented 1 year ago

My takeaway from the discussion: in lieu of the fact that the upstream source has no clear versioning it is indeed better to have some place safely serving a stable version, and I don't have an idea for a better one.

juliohm commented 1 year ago

It makes sense to provide a safe home for the code assuming you have the permission to do so in the software license. It would be nice to contact the author of the project as well to see if he/she has a better home that is also safe? IMHO, storing a C project in a Julia organization isn't ideal. Wrappers make total sense though.

j-fu commented 1 year ago

Well I contacted the author (whom I happen to know personally) in 2020 and informed him about Triangulate.jl. I assume that he is now busy with other things more important to him and that by providing the source to netlib he already delegated the responsibility for the code conservation.

Grepping Yggdrasil for similar cases (using netlib stuff) shows:

Upstream source in contributor repo:

SLATEC: https://github.com/sabjohnso/slatec

Unversioned upstream source directly from netlib:

ASL: http://netlib.org/ampl/solvers.tgz DASKR: https://www.netlib.org/ode/daskr.tgz DecFP: https://www.netlib.org/misc/intel/IntelRDFPMathLib20U2.tar.gz

Upstream source replaced by complete scipy download for lack

of versioning: Diercks: https://github.com/scipy/scipy/releases/download/v1.7.2/scipy -1.7.2.tar.xz

Other projects using Triangle (and solving similar problems)

https://github.com/libigl/triangle/ https://github.com/drufat/triangle-c https://github.com/wo80/Triangle https://github.com/pradeep-pyro/triangle

We could use the initial commit of one of them (preferably igl) as upstream source and then patch... Feels like the third best variant...

Conclusion

IMHO the "big solution" would be some org tracking upstream netlib sources, may be specifically for Julia.

Lacking the resources for this I think second best is a repo like this for keeping things consistent. Putting this into JuliaGeometry makes this maintainable by more potential contributors. Putting this into j-fu or into my institute's org probably wouldn't trigger this discussion, but for reason of long term maintainability I still stick to JuliaGeometry.

May be @giordano or @staticfloat have an opinion here ?

giordano commented 1 year ago

Yes, netlib is a terrible hosting option since it's completely unversioned, old versions are lost, making build recipes unreproducible. I just noticed https://github.com/JuliaPackaging/Yggdrasil/blob/aee14752bf5f7981f112e21bac8757e0162e058e/A/ASL/build_tarballs.jl is broken because a new version of ASL has been released in the meantime, this is unacceptable

j-fu commented 1 year ago

So let us keep this in JuliaGeometry for the time being, I am ready to move this repo to some other org for netlib upstream sources where future shared maintenance is possible.