Hi, Lukas. 2012/2/16 Lukas Reichlin <lukas.reich...@gmail.com>: > 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. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
