[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#867382: ITP: vspline -- generic C++ code for uniform b-splines, remap functions



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" <kfjahnke@gmail.com>
User: debian-science@lists.debian.org
Usertags: field..mathematics

* Package name    : vspline
    Version         : 0.1.1
    Upstream Author : Kay F. Jahnke <kfjahnke@gmail.com>
* 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






Reply to: