There are non trivial changes involved in getting compilation without internationalization, primarily because their error handling system uses internationalization in many places. Its not just a copy and paste job, but now that I've figured out exactly what headers we need and set up autoconf replacement its not too difficult either (I'd say I could probably do it in an hour and someone not familiar in two or three). On the other hand applying individual patches to files would be very easy. I also noticed many changes but most of them did not seem to be centered around the algorithms that I actually added. I do not agree with the maintence argument for a seperate spkg, but I would be more then willing to move it out of libcsage if others are interested in using the algorithms for other Sage SPKGs. I have not yet benchmarked hash tables (nor actually tried them out), but one of the big advantages is that they avoid much of the memory management issues, so I don't expect them to be slower (and if they are, I may have to fix that).
On Wed, Mar 26, 2008 at 3:06 PM, Robert Bradshaw < [EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
