Am 14.07.2017 um 15:40 schrieb Sébastien Villemot:
Dear Kay,
Le jeudi 06 juillet 2017 à 09:16 +0200, Kay F. Jahnke a écrit :
Package: wnpp
Severity: wishlist
Owner: "Kay F. Jahnke" <[email protected]>
User: [email protected]
Usertags: field..mathematics
* Package name : vspline
Version : 0.1.1
Upstream Author : Kay F. Jahnke <[email protected]>
* URL : https://bitbucket.org/kfj/vspline
* License : EXPAT
Programming Lang: C++11
Description : generic C++ code for uniform b-splines, remap functions
[…]
When I started working on b-splines a few years ago, I worked a lot with
libeinspline, which is also available as a debian package, but is coded
in C and only offers cubic b-splines in up to three dimensions. I wanted
a wider scope and a modern code base in C++, and I wanted to use the
signal processing approach to b-splines rather than the linear algebra
approach used in libeinspline, so I set out on vspline.
I am the maintainer of einspline in Debian (under the Debian Science
umbrella).
I am wondering what should be done with that package. It seems
abandoned upstream, does not compile against upcoming GCC 7 (see
#853385), and I personally no longer use it.
As someone who has a deep knowledge of various B-Spline codes, what is
your opinion? Should we remove it from Debian, since it is abandoned
upstream, or is it worth keeping it by adding our own patches? Has
someone created a lively fork? Would you be interested in maintaining
it (upstream and/or in Debian)?
Dear Sébastien!
Sorry to take so long to reply, I was offline for a few weeks.
I haven't touched libeinspline in a while myself, now that I have my own
b-spline implementation, which suits my needs much better. When I
started out using it, I had very limited success communicating with it's
author, and he did not acknowledge the existence of the python interface
I wrote for it, though it was listed as to-do on libeinspline's website.
Eventually I gave up trying to build on top of libeinspline. My
impression was that the author has lost interest in his library and has
moved on to do other stuff. As you say, it seems abandoned upstream. I
have tinkered with the C code, but I haven't come up with anything worth
publishing, and I know of no fork. I would not like to maintain it, in
fact I'm glad to have my own code to work with now.
On the other hand, when only cubic splines in up to three dimensions are
needed to be used with C or fortran code, it provides a usable code
base. The basics - prefiltering, and evaluation - work well enough, but
there are also some ideas which were begun and seem not to have been
properly finished. It could do with a cleanup job, if it were to be
continued. I was surprised to find it as a debian package in the current
state, there are too many loose ends for my taste. What probably sets it
apart is the clear focus on b-splines, which fits the unix philosphy of
providing a specific tool for a specific task, and currently there seems
to be no other package available specifically for uniform b-splines.
With this unix focus, I have written vspline. The code, being generic
C++, covers more ground, but omits a few specifics of libeinspline which
I feel don't really belong into a b-spline package. But my code is new
and complex, and the API will probably go through a few changes before
stabilizing properly. And so far I haven't managed to elicit much
interest for it, let alone find a sponsor. I did intend to ask you,
Sébastien, if you might not be interested in considering sponsoring my
package, since you are libeinspline's maintainer and therefore might
have a good idea about the topic.
I am of course biased, but I feel vspline has the potential to fill the
niche for a uniform b-spline library in debian. I'd rather invest
development time there than trying to patch up libeinspline. If anyone
needs it specifically they should come forward and do the task - from
briefly looking at the gcc7 compilation errors (#853385) it looks to me
that the affected code is merely performance testing code (sorry, I
don't have gcc7 here). The minor changes to libeinspline when debianized
(as far as I know just one bug fix) and the packaging effort can
probably be written off without too much regret, and anyone needing
libeinspline can still access the code from upstream, so I'd say that
removing it from debian would not be a great loss.
With regards,
Kay F. Jahnke
