On Wed, 26 Mar 2008 11:57:26 -0700, Gary Furnish <[EMAIL PROTECTED]> 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. > 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? I'm not trying to block the patch in order to solve the problem. I'm just hoping to convince you that putting this code in libcsage is the wrong approach for numerous reasons. That a "glib-lite" derivative of glib is best done as a separate spkg, and that this has by far the best chance of living, being useful outside of Sage, etc. Also, from my point of view almost _everybody_ involved in Sage has come and gone, at one point or another, and I want *nothing* in Sage whose maintenance depends on only one person. I'm scared of a bus factor of 1 for anything in Sage. > 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. That's very good to know. > 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. Why??? I could have said the same about Pyrex two years ago, and it would have been silly. So could you please explain why this is true of glib-lite. I'm not saying it isn't try! I just don't see why it should be. I know you're extremely good at writing and arguing points, so please be patient with me and explain why "Making a seperate spkg dramatically increases the difficulty of active development." Again, I'm *not* at all sure I'm right! And you've been much closer to that code than I am, so you're much more likely to be right. That said, you've not given any argument, and this is the time to work these things out -- that's why we have a vote, etc., for packages. -- William > > 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 >> >> > >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
