Honestly, independent of the spkg vs libcsage issue, which is really an issue of semantics in my opinion, Sage has no high speed implementations of C algorithms. Sage can not escape this forever. Either someone will have to write their own at some point or we can use glib as a starting block. It is a big chunk of code, but Sage needs fast lists, hash tables, etc. Using glib as a starting point dramatically reduces debugging time, and is therefore preferable. I don't see how blocking a glib patch because of maintenance issues really helps solve this problem in the long run. Is it really preferable that I code up custom versions of the things so that I can have fast symbolic implementations?
Most of the bloat in glib is internationaliztaion, which is not included in this patch. The parts that are included are simple enough and well documented enough (either in the code or in glib documents) that anyone should be able to easily maintain it. Furthermore, I intend to help maintain the C algorithms. I fully intend to work on them actively if their speed is not sufficient. Making a seperate spkg dramatically increases the difficulty of active development. On Wed, Mar 26, 2008 at 12:26 PM, William Stein <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 26, 2008 at 11:16 AM, didier deshommes <[EMAIL PROTECTED]> > wrote: > > > > > > On Wed, Mar 26, 2008 at 1:52 PM, mabshoff > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > On Mar 26, 6:43 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > > > On Wed, Mar 26, 2008 at 10:09 AM, mabshoff > > > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Mar 26, 6:02 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > > > > > Is any of the code gpl v3+ only? > > > > > > > > > No. > > > > > > > > That's good. > > > > > > > > > > > > > > > > > > How difficult will it be to update our version whenever > upstream > > > > > > changes? Do only you know how to do this? > > > > > > > > > Not particularly hard. > > > > > > > > You didn't answer my second question. > > > > > > Gary did it and I didn't pay much attention to it. I assume it will > be > > > documented. I don't consider such a thing "hard" once it has been > > > documented. > > > > > > > > > > > > Why put this in c_lib instead of a separate spkg called > glib-min? > > > > > > Couldn't such a package be useful outside of sage? > > > > > > > > > It is easiest if we put it into libcsage. > > > > > > > > That's not a good enough answer. Until now almost all code in > libcsage and > > > > the main sage library has been new code we've written -- except a > few > > > > exceptions, > > > > where we greatly regretted them greatly and moved the code out > later. > > > > So from experience I'm very opposed to this code being in c_lib. > > > > > > > > I vote -1 to this code going into sage unless: > > > > (1) it is put in a separate spkg, and > > > > > > We can certainly do that. > > > > > > > > > > (2) the process of extracting glib-min from the official glib > > > > tarball is automated. > > > > > > That is unlikely to happen since it requires manual interaction. It > > > will break in the next release in six months and writing automated > > > tools will take longer than actually doing the work in the first > > > place. > > > > How frequent are the glib releases? If they're not that frequent, this > > should less than an issue as long as Gary documents what he's done > > somewhere :) > > If you've been maintaining packages for Sage for three years, and expect > to be maintaining them for years to come, you'de view this as a much > bigger deal. It's really bad when there is a big chunk of code in Sage > that gets out of stream with "up stream", but no easy way to resolve that > problem. > > -- William > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
