Re: [OctDev] Google Summer of Code 2012: Call for projects and mentors

[Jordi Gutiérrez Hermoso]

Hi, Lukas.

2012/2/16 Lukas Reichlin <address@hidden>:
> On 14.02.2012, at 23:15, Jordi Gutiérrez Hermoso wrote:
>
>> Note that I think we should also consider Octave-Forge projects.
>> Please add Octave-Forge projects to the wiki as you deem appropriate.

> I do have an idea for an Octave-Forge project: Improve the
> "symbolic" package:
> - use objects & classes of Octave to enable stuff like overloaded
> methods for symbolic matrices. This could be done in C++ in a way
> similar to Michele Martone's new "sparsersb" package.

This sounds worthwhile. If you're able to mentor such a project, add
it to the wiki. We do get frequent requests for a working symbolic
package, so it would be nice if it were actually useful for something.

> - include the ginac library into the package such that there are no
> external libraries required. External libraries are often a pain in
> the proverbial on certain platforms.

This isn't a solution. Bundling of libraries presents its own problem.
It's the solution that proprietary software prefers, because
proprietary software doesn't know how to cooperate very well with
other software, proprietary or not (e.g. Windows and MacOS don't have
a native packaging system). When everything's hidden and forbidden,
everything hates everything else and it produces disharmony in the OS
instead of collaboration between different parts.

The solution is to properly package GiNaC in whatever packaging system
you personally happen to prefer for MacOS, which I think is the
platform you regrettably are using.

> An example of included libraries is the "odepkg" package which
> includes some tgz archives that are compiled upon package
> installation.

I wasn't aware that it was doing this, but already it's possible to
see how this is a problem. You will observe that it's patching the
bundled libraries, implementing fixes that apparently are unique to
Octave. Who else is using these libraries? Who else might want these
fixes? Why are we maintaining our own patch set instead of
collaboratively maintaining it with anyone else who might be
interested? Are we all in the numerical community independently
reimplementing again and again the same fixes in these packages?

Such was the situation with ARPACK, which everyone was using, and
everyone was independently patching over and over again, in the same
way, in effect, everyone creating their own fork. It took a lot of
communication and collaboration between different free software users,
but now we have a centrally-located and community-maintained version
of it. This is the right thing to do. I don't know how feasible it is
to do this for the bundled libraries of odepkg, but it should be
considered. If they are completely abandoned libraries and nobody but
us is using them, like what happens in libcruft in Octave, then it's
an acceptable compromise to bundle them, but if there is any sort of
upstream maintenance or a community of users, they should be
collaboratively maintained.

- Jordi G. H.