On Wed, 26 Mar 2008 14:06:08 -0700, 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.
I have to strongly agree that I really want something with the feature
set of glib included, and that I don't think we have any business writing
it from scratch.
> 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.
This is certainly worth knowing.
>
>> 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.
I agree. And I don't think the above has been sufficiently
addressed yet.
Sorry to be a pain, but what you're proposing doing with glib is
almost the same as say taking the pyrex code and sticking it in
SAGE_ROOT/devel/sage/pyrex
under the main Sage hg repo. Doing that would amount to both
a fork and a maintenance problem. Even I didn't go that far
to entagle Pyrex with Sage when forking Pyrex.
I want to emphasize again that I strongly disagree with putting
all of glib-lite in SAGE_ROOT/devel/sage/, and I don't see
why doing that is going to make maintenance easier.
But I also want to emphasize that I strongly support glib-lite going
into Sage in some form, and I greatly greatly appreciate the hard
work you've put into making this possible.
-- William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
