[Top][All Lists]

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

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

From: Lukas Reichlin
Subject: Re: [OctDev] Google Summer of Code 2012: Call for projects and mentors
Date: Thu, 16 Feb 2012 19:12:20 +0100

On 16.02.2012, at 14:28, Jordi Gutiérrez Hermoso wrote:

> 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.

Hmm, I write my thesis this summer and I want to focus on that. (It includes 
implementing system identification tools for Octave :) Maybe I could serve as a 
backup mentor (if someone gets hit by a bus)?

>> - 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.

I think that Octave packages - unlike Octave itself - should be self-containing 
as they need to be installed/compiled by non-expert users. My control package 
includes the SLICOT library (as discussed on the help list on Monday, I will 
include it in a more elegant way) and it works pretty well. I don't want the 
user to worry about SLICOT installation, version conflicts … And I don't want 
to provide up-to-date SLICOT packages for every OS and packaging system.

>> 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.

I like the idea behind arpack-ng, but I think we're talking about cross 
purposes. I dont want to patch/fork/maintain
ginac or slicot. I just include a maintained library in the package in the 
sense of "batteries included". Your approach is acceptable for Octave itself, 
as only expert users compile their own binary which are able to juggle with 
dependencies. Maybe with the help of a package manager. This is not true for 
regular users which want to install a new package on platforms you dislike.

> - Jordi G. H.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]