Re: [OctDev] complex error function

[Jordi Gutiérrez Hermoso]

On 21 November 2012 14:55, Steven G. Johnson <address@hidden> wrote:
> On 11/21/12 11:47 AM, Jordi Gutiérrez Hermoso wrote:
>>
>> But after you do the patch, how will we incorporate it back into our
>> own codebase, if we have a copy of it?
>
>
> "cp Faddeeva.cc octave/...../Faddeeva.cc" is pretty easy...

What if you become unresponsive to accepting patches? What if I
already had patches there? Then I can't just overwrite the local copy,
I'd have to do merges instead. And also, I or someone else in Octave
has to be remembering to periodically do this copy and make sure that
something has changed.

Please, don't trivialise this problem. I know software distribution is
a chore and hard work, but it can't be avoided.

>> I'd rather just link to your
>> library than to have cut-and-paste code.
>
> The question is ease for users, not for us.

For us too. Users don't have to worry about linking or building
themselves. They should get pre-compiled at best or compilation
recipes like Gentoo's emerge at worst. And we need ease for us,
because software maintenace is boring and difficult.

> 2) make it optional. In which case most users won't install it (at
> least, not until it is included in distros by default, which may
> take a long time even if Octave suggests it, and even then only for
> GNU/Linux distro users),

I know you're eager to get your super important library to everyone
right now this minute, but you should exercise a little humility. The
fact is that most people don't care about your library or we would
have had a lot more people clamouring for complex erf. Instead, I've
had to personally defend myself a number of times how erf is an
analytic function, etc. Users are usually surprised that they would
want this functionality at all.

Thus it makes sense for everyone to wait for the software release
cycle to take its time to release. This has worked for Arpack and
other libraries. Yours isn't more important than them.

> the core Octave functionality will vary with installation.

This already happens and nothing terrible has ensued.

>> If you wish, I can help you with setting up the software
>> distribution mechanism.
>
> I know how to distribute libraries. You are already using a little
> library of mine called FFTW.

Great, why don't you make this part of FFTW, then? Seems easiest this
way. A reasonable case could be made for saying why fft needs the
Faddeeva function and relatives.

>> Octave builds for Windows, Mac OS X, most flavours of GNU, some
>> BSDs, and the occasional AIX, Solaris, and HP-UX here and there.
>> Does your Makefile work on all of those, on all versions of
>> possible libc's and compilers that it may encounter? If yes, then
>> autotools is overkill. If not, build systems suck, but we have to
>> use them.
>
> In practice, a single Makefile + a compiled binary for Windows will
> work for 99.99% of users (Windows, GNU, BSD, and OSX) these days.

This 99.99% seems to have been obtained via the Stetson-Harrison
estimator. If what you say were true, build systems would have already
vanished long ago, since we all hate them.

>  Or a single cmake file, for that matter.

A single CMake file is quite different, and if you prefer to use CMake
to autotools to distribute, go right ahead. I don't care which build
system you use as long as you pick one that reasonably works well.
Handcrafted Makefiles can also be a build system if you actually go
through the pain of making them general enough.

> It's bad to have no upstream and multiple downstreams, I agree, but
> that seems orthogonal to whether it is distributed as a library or
> as source code. I don't follow you.

Your situation is similar to gl2ps, which we also want to unbundle.
Whether the library has one file or 100 is of little import here. We
do not want to be maintaining the library, we do not want everyone to
be bundling their own slightly differently patched version of it.
Incorporate it somewhere central that we are all already using.

This isn't just for Octave's benefit, but for everyone else.

- Jordi G. H.