I have fixed the smallest of the mwrank/g0n issues in trac # 1403; patch attached to the trac. This could be applied to either qrank/getcurve.cc in the new cremona package, or to getcurve.cc in the old mwrank package.
On to the next one! John On 05/12/2007, mabshoff <[EMAIL PROTECTED]> wrote: > > > > 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 > > > -- John Cremona --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
