Continued development of GSL.jl

package

#1

I would like to check if anybody knows what the status is of the GSL package, and what the community interest is for continued development.

Currently there has not been any development in a while, things are not working at all on Julia 1.0, and a number of pull requests (#69, #71, #74) trying to move things forward have been left hanging.

I find GSL.jl very useful in my work, and would hate to see it abandoned. I would be more than happy to help contribute, if we can get a dialogue going with the maintainers about what needs to be done, and how it should be done.


#2

If you don’t get a response, you can always fork the package.


#3

I’m happy to have @ludvigak help maintain! I’m the original author of GSL.jl and sadly don’t have the time to work on it anymore. It’s one of the few packages that has been developed and maintained since Julia v0.0, and I would hate to see it lose relevance.


#4

I’ve created a builder using BinaryBuilder: https://github.com/giordano/GSLBuilder.jl However, there are a couple of issues to be fixed for this to completely work, in particular MacOS support:


#5

That’s great @jiahao and @giordano !

In order to get GSL back online again quickly, I would suggest we first get out a release using the existing build script, that just fixes the syntax to be compatible with Julia 1.0. That does not seem to be too far off, if we start from one of the existing pull requests. We could even temporarily disable features that currently use pointer_from_objref, to get things running as soon as possible.

As a second step, switching to BinaryBuilder absolutely makes sense.

Going forward, I think it would make sense to restructure the package, and base it on wrappers generated from the GSL headers, perhaps using Clang.jl. Then we could add a second wrapping layer on those, that does some input checking and adds convenience, and that doesn’t get overwritten if the wrappers are regenerated.

For now though, I’ll look at the pull requests and try to put something together that has the correct syntax, and builds and runs on Julia 1.0 with most of the features intact.


#6

The PR to switch to BinaryProvider is ready: https://github.com/JuliaMath/GSL.jl/pull/77

Note that GSL.jl is currently based on GSL 1.16, which is some 5 year-old. It may be nice to upgrade to a newer version of the library at some point, after development of the package restarts.


#7

I recommend that you make the upgrade now. There is no need to delay that because GSL.jl is not available to the current release, v1.0.

(v1.0) pkg> add GSL
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package GSL [92c85e6c]:
 GSL [92c85e6c] log:
 ├─possible versions are: [0.0.1, 0.1.0-0.1.2, 0.2.0, 0.3.0-0.3.6] or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions [0.0.1, 0.1.0-0.1.2, 0.2.0, 0.3.0-0.3.6]
 └─restricted by julia compatibility requirements to versions: uninstalled — no versions left

#8

I’ve already prepared a build for GSL 2.5: https://github.com/giordano/GSLBuilder.jl/releases/tag/v2.5 but I’m not sure it’s a good idea to upgrade it now. I think the priority should be to get GSL.jl to work as it is now, then upgrade to a newer version. I didn’t check, but APIs may have been changed since version 1.16


#9

Purely from a code organization point of view, I think it is better to make upgrades to 1.0 separate from other changes. Makes it easier to bisect etc later on.


#10

I’ve created a pull request merging @giordano’s work on BinaryBuilder with previous pull requests that have syntax updates for Julia 1.0: https://github.com/JuliaMath/GSL.jl/pull/78

What’s the best way of moving forward? Is there someone in JuliaMath who can merge pull requests and create releases on GSL, or can someone new be added as maintainer?


#11

Apparently @simonbyrne was around to keep things running, so all is good!