On Mar 26, 2008, at 11:57 AM, Gary Furnish wrote: > 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.
Browsing the glib documentation, looking at its features, and reading what other people have to say about it I think this is a worthy set of things to include. One question I have is how much faster glib hashtables are than python dictionaries (as accessed directly through the Python/C API, which they will be from Cython if declared as type "dict") and how much faster glib (linked or non-linked) lists are then Python lists. Have you run any tests? If there is not a significant speed difference, it would be preferable to use the Python datatypes to store Python objects when possible (for cleaner code and to minimize recounting woes). This wouldn't mean that glib isn't worth including however. > 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? No. I think the point is that before including it we should consider issues of maintenance and this may influence where we put it. (Much easier, for instance, than trying to move it later.) I agree that it should probably be a seperate spkg. > 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. I agree that making an spkg raises the barrier of working on it, but not by that much. Also, as an spkg, other components of Sage can make use of it, and I think it will be much easier to keep in sync with and contribute upstream. I'd also really like to avoid a fork, which is what this could easily turn into. I'm noticing a lot of changes from glib 2.16.1 at GNOME. Is this the version you started from? Are you simply copying a subset of the c/h files, or are there significant changes that need to be done every time glib is updated (every month or two looking at the history)? I would like to see this included, but I think these issues need to be resolved now, or they never will until it hurts us. - Robert > > > 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 -~----------~----~----~----~------~----~------~--~---
