On Dec 5, 7:20 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007 10:15 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On 05/12/2007, William Stein <[EMAIL PROTECTED]> wrote:
>
> > > On Dec 5, 2007 7:51 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> > > > I'm sure that can be done, and in fact I have suggested it myself.
> > > > The cremona.spkg contains everything that mwrank.spkg did. So whoever
> > > > put mwrank into Sage
>
> > > That would be me when I visited you for a day in Nottingham > 2 years
> > > ago.
> > > You were very helpful then :-)
>
> > > > could make some small changes and get mwrank to
> > > > do the same. The executables files (e.g. the mwrank stand-alone
> > > > program) should still be built; when it somes to linking, all you
> > > > need to know is that the mwrank version was flattened producing only
> > > > one lib*.a, while the cremona version keeps my original division into
> > > > 4 (interdependent) libraries.
>
> > > > I don't have the technical expertise to do this myself! I was not
> > > > involved in the origina mwrank packaging and wrapping (and did not
> > > > acquire the necessary knowho at SD6 either). But I am happy to answer
> > > > questions from anyone who is going to do it.
>
> > > Michael A. or I will do it. I haven't yet only due to teaching,
> > > grant-writing,
> > > etc. The quarter ends here soon though so I will have time.
>
> > > And please don't make us take cremona*.spkg out of Sage. It is to me
> > > the most exciting edition to Sage in a very long time!
>
> > Thanks, but as I'm spending a long time trying to track down memory
> > leaks in the one part of the code I didn't write myself (and which use
> > a lot of low level bit arrays and pointers) I have not got time to
> > actually do any programming which might produce some interesting new
> > mathematical results (such as modular symbols from ellitpic curves)!
>
> > I am not prepared to build gcc-4.3 from scratch, so until it gets put
> > into kubuntu I just will not support anything laterer than gcc-4.2 for
> > any of my C++ code.
>
> > Michael A, valgrind is driving me crazy. I am sure that it is telling
> > me *wrongly* that I am using some uninitialized memory. But despite
> > all the voluminous output, it doesn't seem to actually tell me the
> > address which is aparently uninitialized! If there is a command-line
> > option which will give me that, please tell me. I *have* read the man
> > page.
>
> > Many years ago I decided that I would only ever give people binaries
> > of my programs since I did not want to spend my life fixing compiler
> > errors which would arise on other people's compilers.
>
Hello John
the problem is that an issue that used to annoy only people like me
under Valgrind now causes Segfaults during the runtime of the code.
Many times in the past I have learned that even the bugs that
seemingly do not cause any harm sooner or later with different
compilers or platforms cause issues.
> You can definitely just say no to fixing any of this sort of stuff.
> Just bounce it back and say if you people want to get it fixed,
> *they* have to fix it and submit the code to you (not the other
> way around). I hope you'll at least look at fixes once they are
> made by other people though :-).
>
> > Then I started
> > to make exceptions for a few trusted people who I knew would not bug
> > me (e.g. William). Before I knew it I was distributing source code
> > packages -- as we now all do in the name of open-ness -- and exactly
> > as predicted, I am spending more time fixing stupid minor boring
> > things instead of implementing something new and interesting. It's a
> > one way street, and I know I cannot go back, but I am beginning to be
> > nostalgic for the days when I just wrote programs for myself....
>
:), but we are willing to help out. For the 4.3 build fixes see
http://fsmath.mathematik.uni-dortmund.de/~mabshoff/patches/cremona-20071124.p2-gcc-4.3-build-fixes.patch
The initial ride was pretty rough, but I am fairly confident that
things will calm down now, gcc 4.4 is way out.
> It's not a one way street, and you *can* "go back", in the sense of the
> extra work. Just refuse to fix anything at all for us for a while!
> Seriously,
> it's not a problem. I'm sure we can fix things ourselves. It's really good
> that you're clarifying how you want things to work so explicitly.
>
> So whenever we point out compiler issues, memory leaks, or whatever
> else, just say -- "hmmm, very interesting, good to know; That's probably
> not too hard to fix... so please send me a patch!" and leave it at that.
> From extensive personal experience, this strategy works well.
Yep, that does work very well. All you need to do is to give the
person who fixed the issue some small, public credit and people will
gladly fix bugs for you. That principle is what makes Sage possible.
> -- William
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
