Irc log for Bug Squash Day 2
[Sun Sep 2 2007] [11:19:41] <sage> I don't remember, to be honest. [Sun Sep 2 2007] [11:19:53] <sage> You could remove setting it and do a complete build of SAGE and see if it works. [Sun Sep 2 2007] [11:20:03] <mabshoff> I could :) [Sun Sep 2 2007] [11:20:30] <mabshoff> Problem might be that "LIBRARY_PATH=/tmp/Work2/sage-2.8.3.rc3/local/lib/:" has the trailing ":" [Sun Sep 2 2007] [11:20:39] <sage> ah. you could change that too [Sun Sep 2 2007] [11:21:06] <mabshoff> If LD_WHATEVER is empty skip the $LD_WHATEVER on export : [Sun Sep 2 2007] [11:21:08] <mabshoff> . [Sun Sep 2 2007] [11:22:13] <mabshoff> Removing the trailing ":" makes configure work. [Sun Sep 2 2007] [11:22:42] <mabshoff> May be a bug in the configure macro, [Sun Sep 2 2007] [11:23:01] <mabshoff> because "empty string" after the separator ":" is not equal to "." [09:05] --> You have joined the channel #sage-devel ([email protected]). [09:05] [Channel] [freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg [09:05] *** Channel modes: secret, no messages from outside [09:05] *** This channel was created on 08/17/2007 01:03:33 PM. [09:05] <mabshoff> Yep, just did my math. [09:05] <mabshoff> hi wstein. [09:05] <mabshoff> M2 r5870 now builds out of the box on Linux :) [09:05] <wstein> hi [09:05] <mabshoff> And there is a google group for M2 now, too. [09:06] <wstein> yep, i'm glad they set that up. [09:06] <mabshoff> I got an invite, so I assume you got one, too. [09:06] <wstein> mabshoff -- can i make you an admin of the sage-devel google group? [09:06] <mabshoff> And all my issues I reported in less than 6 hours each. [09:06] <wstein> the main reason is that new posters are moderated, and having more moderators make [09:06] <wstein> this easier. [09:07] <mabshoff> Sure, at your own risk, power corrupts, absolute power corrupts absolute. [09:07] <wstein> and sage-devel keeps groowing. [09:07] <mabshoff> Sure, go ahead, being in a different time zone kind of fills the gap. [09:07] <mabshoff> And I am online wayyy to much, but hey. [09:08] <wstein> done. [09:09] <mabshoff> Okay, looks like it works. [09:09] <mabshoff> I can see "settings" [09:09] <mabshoff> I will browse a little and ask questions as I see them down the road. [09:11] <dmharvey> okay, I'm going to start looking at the gmp gcd thing (#424). I'm going to start by making a plain text patch for the 4.2.1 tarball which at least puts all the right files in the right places, but doesn't touch the autoconf stuff yet. [09:11] <mabshoff> Shouldn't we considering rebasing against 4.2.2? [09:11] <mabshoff> It will add official support for Solaris/Opteron. [09:11] <mabshoff> And gcc 4.3 :) [09:12] <mabshoff> gmp 4.2.2rc3 is the latest, but that should become 4.2.2 today or tomorrow. [09:14] <dmharvey2> ok, well it does look imminent, so I'll try against that instead [09:15] <mabshoff> Sure, the question is how difficult it will be to rebase. [09:15] <mabshoff> The new improved gcd stuff and so on is pretty much "just" a drop new file in the right directory kind of operation. [09:15] <dmharvey2> almost [09:15] <dmharvey2> a few files replaced too [09:15] <dmharvey2> and some lines inserted into a file somewhere [09:15] <mabshoff> okay. [09:15] <dmharvey2> and then the makefile mess [09:16] <dmharvey2> which someone like you can help me with :-) [09:16] <mabshoff> But no need to touch the autohell? [09:16] <dmharvey2> autohell is necessary unfortunately [09:16] <mabshoff> well, I have done stuff like that before. [09:16] <mabshoff> eek, I the the gmp autohell is worst than most [09:16] <mabshoff> I was attempting to use yasm for gmp assembly files instead of gcc-as [09:17] <mabshoff> Most of the assembly files crashed yasm, [09:17] <mabshoff> until I found out that most asm files in the gmp tree are written in m4! [09:17] <dmharvey2> there's some documentation to help us [09:17] <mabshoff> Good. [09:17] <dmharvey2> in the 4.2.2 tarball, in doc/configuration [09:18] <dmharvey2> grep for "Adding an mpn file" [09:18] <mabshoff> I think it wil be a while before 5.0 arrives, so using the new stuff and getting it some testing is a good idea. [09:18] <dmharvey2> and then later on there's a section called "The configure system" [09:18] <dmharvey2> which might mean somethingt o you [09:18] <dmharvey2> (yes, 5.0 will be a while I think.) [09:19] <dmharvey2> if we get the gcd code successfully into SAGE, I'm going to contact the author and let them know [09:19] <mabshoff> The adding an mpn file is pretty harmless, [09:19] <mabshoff> at least compared to some of the "real" macros they use. [09:20] <mabshoff> We should acutally keep a set of patches in the spkg, so that updating against a "vanilla" gmp is easy. [09:20] <mabshoff> And document it properly, I have no idea how the current gmp spkg looks like, [09:20] <dmharvey2> yes, good ide [09:20] <dmharvey2> idea [09:20] <mabshoff> but some of the other leave a lot to be desired. [09:20] <dmharvey2> my first mission is just to get GMP building with the new code, separately from SAGE [09:21] <dmharvey2> and demonstrate that it works and is fast [09:21] <mabshoff> Sure, give me a minute, I will read up on what is new. [09:21] <dmharvey2> does that sound reasonable? [09:21] <mabshoff> Sure [09:21] <mabshoff> I need to run out to get some groceris in the next hour or so, but that takes about 20 minutes. [09:21] <mabshoff> Overall I am ready to work the next 16 or so hours ; [09:21] <mabshoff> . [09:22] <sage> mabshoff -- the current gmp spkg has /src a 100% vanilla gmp. [09:22] <mabshoff> Great, so Martin's patch is applied conditonally= [09:22] <mabshoff> ? [09:22] <sage> i just bought groceries... [09:22] <mabshoff> That makes things much easier. [09:22] <sage> yes. [09:23] <mabshoff> pheeww. [09:23] <sage> It is total hell if you pre-apply anything to the gmp package... as [09:23] <dmharvey2> ummm.... so I'm thinking, should we separate the task of "including gcd code" from "upgrading to gmp 4.2.2"? [09:23] <sage> I *discovered* when in San Diego last month! [09:23] <dmharvey2> like, let's not try to do them at the same time? Or should we just try both? [09:23] <sage> dmharvey2 -- definitely, yes. [09:23] <sage> separate! [09:24] <dmharvey2> ok, well then I propose we leave upgrading to gmp 4.2.2 for a separate day [09:24] <dmharvey2> mainly because that's going to require test building on lots of different systems [09:24] <dmharvey2> whereas the gcd stuff, if it works on one system, is likely to work everwhere [09:25] <mabshoff> Sure, the only real improvement of gmp 4.2.2 in my opinion is the gcc 4.3 fix. [09:25] <wstein> yes. [09:25] <mabshoff> And that won't be an issue for most people for at least 3 months. [09:25] <dmharvey2> okay, in that case, I will make patches against 4.2.1, and we'll ignore 4.2.2. for today [09:25] <mabshoff> Yep. 4.2.2. is already a ticket in regards to the gcc 4.3 issue. [09:25] --> burcin has joined this channel ([email protected]). [09:26] <mabshoff> It was just dumn luck that gcc 4.2.2 came out and my suggestion got merged, [09:26] <mabshoff> hey burcin [09:26] <burcin> hello [09:26] <mabshoff> How are things on your end? [09:27] <burcin> I'm preparing for a late night :) [09:27] <mabshoff> Jep, I got up about 2.5 hours ago. [09:27] <wstein> i slept about 4-5 hours.... [09:27] <wstein> because I was up very late release sage-2.8.3.6 [09:27] <mabshoff> And with the added help of caffeine & sugar I shall not rest for a while. [09:28] <wstein> which has all my last few days of number fields code. [09:28] <mabshoff> Oh, I missed that one. [09:28] <mabshoff> Time to upgrade. [09:28] <wstein> sage -upgrade [09:28] <burcin> yes.. I also got up an hour ago.. :) [09:28] <burcin> .6 was a surprise.. [09:28] <wstein> did you upgrade? [09:28] <mabshoff> I did some timing on testall on 2.8.3 vs. 2.8.3.3 vs. 2.8.3.5 and they were in the same range. [09:28] <burcin> I'd left the others building before I slept.. [09:28] <burcin> now I'm upgrading :) [09:28] <mabshoff> ;) [09:29] <mabshoff> Are you in the student housing units? [09:29] <burcin> yes.. you can probably tell by my ip.. raabheim [09:29] <mabshoff> They are pretty nice, I was there for CoCoA VII this summer. [09:30] <mabshoff> true about the IP [09:31] <burcin> I'm in the one in linz.. you must have stayed in hagenberg.. but the rooms are the same.. [09:31] <mabshoff> Okay, I see. [09:31] <mabshoff> Yeah, we were at "Bobo's castle" [09:31] <mabshoff> :) [09:31] <mabshoff> Or is it Bubu? [09:31] <burcin> I work in the attic of that castle :) [09:32] <burcin> he's bookie mountain.. [09:32] <mabshoff> it is quite a nice place to work, but I hope it won't get too hot in the summer. [09:32] <mabshoff> ok, haven't heard that one. [09:32] <mabshoff> I will spend a lot more time in Hagenberg starting next summer. [09:33] <burcin> the attic is the hottest place in the castle.. in summer and winter.. but it's also the quitest.. [09:33] <burcin> next summer? risc summer I suppose.. [09:34] <burcin> someone should make a presentation at issac this time.. [09:34] <burcin> I've already talked to the program chair :) he says ok :) [09:34] <mabshoff> Maybe that, but Algebraic Oil works with Risc. [09:34] <mabshoff> ISAAC is at Hagenberg next year? Nice. [09:34] <burcin> really? risc software? or the institute? [09:34] <mabshoff> Well, nothing is written in stone yet, [09:35] <burcin> hmm.. it's issac.. intl. symposium on symbolic and algebraic computation [09:35] <burcin> I think isaac is some applied maths thing.. [09:35] <mabshoff> Sorry, butterfingers. [09:35] <mabshoff> Yeah, if you do CAS you ought to go to ISSAC. [09:36] <mabshoff> 2 years ago it was in Genoa, this year was Montreal I believe. [09:36] <mabshoff> How is chair next year? [09:36] <burcin> it was in toronto at waterloo [09:36] <burcin> franz (winkler), my adviser [09:36] <mabshoff> Well, Canada. [09:36] <mabshoff> Oh good [09:37] <mabshoff> How far along are you with your PhD? [09:37] <burcin> I am starting.. I came to risc last year.. [09:37] <mabshoff> Okay, 2 or 3 years to go then? [09:37] <burcin> had to take courses.. thinking, speaking, writing... bruno's ideas [09:38] <mabshoff> :) [09:38] <mabshoff> I heard about that one. [09:38] <burcin> so any bugs I can look at? memory leaks maybe? [09:38] <mabshoff> There are 15 tickets open. [09:38] <mabshoff> for memleaks. [09:39] <mabshoff> They are all listed at http://sagetrac.org/sage_trac/milestone/sage-2.8.4 [09:39] <burcin> I'm looking at that now.. [09:39] <mabshoff> ok [09:39] <mabshoff> Do you have valgrind installed? [09:39] <burcin> I suppose we should rank them by the size of the leak :) [09:40] <mabshoff> There is an experimental spkg, but I think wstein did't put it up yet. [09:40] <burcin> yes.. but I don't have python built without it's memory allocation.. [09:40] <mabshoff> Certainly, but the noise small ones are just as annoying. [09:40] <mabshoff> That doesn't matter too much for the leaks. [09:40] <mabshoff> You just get a bunch of noise at the start of the logfile you can just ignore. [09:41] <burcin> do you get these links when you run a something specific? [09:41] <mabshoff> #566 is something nice to do. [09:41] <mabshoff> Yep, ususally it says in the report which command I ran. [09:42] <mabshoff> I.e. for #559 and most of the others it is right on top. [09:43] <mabshoff> #519 is very similar to #566 [09:43] <mabshoff> You need to move some of the code and write a proper deallocation function, that is called from sage/all.py upon exit. [09:43] <burcin> deallocation function on exit? [09:44] <burcin> on exit from sage? [09:44] <mabshoff> Yep, look at sage/all.py and there at "sage.matrix.matrix_mod2_dense.free_m4ri()" [09:44] <mabshoff> But wstein should say a couple things on where to move things. [09:45] --> timothyclemans has joined this channel ([email protected]). [09:45] <mabshoff> I haven't had a proper look at sagelib, so I cannot give and recommendations. [09:45] <mabshoff> Hello timothy [09:45] <timothyclemans> hi [09:46] <mabshoff> The free_m4ri() routine just illustrated how to write the "dealloc on exit"-routines for the gmp_rand state that we would otherwise leak. [09:46] <timothyclemans> is it ok to add bugs to sage-2.9 milestone? [09:46] <mabshoff> And for #566 you need to call a bunch of mpz_clear() and so on. [09:46] <mabshoff> Sure, what do you have in mind? [09:47] <timothyclemans> http://www.sagemath.org:9002/sage_trac/ticket/228 [09:47] <mabshoff> #519 and #566 should have most of that info in the comments, but feel free to ask wstein about the technical stuff. [09:48] <burcin> ok, thanks.. [09:48] <mabshoff> re #228: if boothby ask him to do it today :) [09:48] <burcin> I still don't get why just importing a module would leak memory... [09:48] <burcin> I'll look at the code a bit now [09:48] <mabshoff> We had some offline discussion and the problem is reference counting in sys/module [09:48] <mabshoff> At least that is what be believe. [09:49] <mabshoff> it isn't very pressing to solve because we do not leak any memory and the amount is constant (assuming constant number of modules) [09:49] <mabshoff> But solving that issue is more a longer term design issue for Cython. [09:50] <mabshoff> To really figure that out I probabyl need to read python sources for a couple weeks. [09:51] <dmharvey2> #424: I've made a patch which I think puts the right code in the right places. Next for the "autohell" stuff. [09:51] <dmharvey2> actually I'm going to get some lunch now [09:52] <mabshoff> Good, I will go grocery shopping, back in about 20. [09:52] --> syazdani has joined this channel ([email protected]). [09:52] <mabshoff> Then we can look at autohell in gmp ;) [09:52] *** mabshoff is now known as mabshoff|away. [09:54] <syazdani> Hello all. [09:55] <malb> hi [09:55] <wstein> hi syazdani [09:55] <wstein> we'll "start" in 5 minutes officially. [09:55] <syazdani> cool [09:56] <syazdani> that should give me enough time to catch up on my emails [09:56] --> robertwb has joined this channel ([email protected]). [09:57] <mhansen> Hello [09:57] <mhansen> Are we going to be using 2.8.3.6? [09:58] <malb> yes [09:58] <wstein> yes. [10:00] <wstein> hey, it's 10. [10:00] <wstein> I declare Bug Squash Day 2 officially started. [10:00] <wstein> Let's see if SAGE is ready for prime time or not. [10:00] <wstein> Could everybody maybe just mention where they are physically right now? [10:00] <wstein> I'm in Seattle. [10:00] <robertwb> Seattle [10:01] <wstein> (2 feet from me.) [10:01] <syazdani> Hamilton [10:01] <burcin> linz, austria [10:01] <-- dmharvey2 has left this server. [10:03] <wstein> make sure to do a "sage -upgrade" if you havne't already. [10:03] <burcin> even from .6? [10:03] <wstein> no sage-2.8.3.6 is the latest. [10:03] <burcin> yes.. it just told me now :) [10:04] <wstein> And if you'rein a hurry, doing hg_sage.pull() form sage 2.8.3.5 is fine. [10:04] <malb> London [10:04] <mhansen> Madison, WI [10:05] <wstein> Our ultimate goal is to close every genuine bug attached to sage-2.8.4 and 2.9 in trac. [10:05] --> dmharvey2 has joined this channel ([email protected]). [10:05] <wstein> Of course, working on other things is fine.... [10:05] <dmharvey> boston, USA [10:06] --> boothby has joined this channel ([email protected]). [10:06] <timothyclemans> so is there a way to share vmware files over network? [10:06] <malb> FTP? [10:07] <boothby> web 2.0! gmail! [10:07] <malb> where does sage -valgrind write the logfile? [10:07] <wstein> david joyner emailed me that he has posted fixes for trac #568, #569 #570. Does anybody want to verify that these work. [10:07] <wstein> Be nice. You maybe mean NFS. This is off topic for sage-devel though. [10:08] <timothyclemans> i know but i don't have working linux so i'm stuck with vmware for development [10:08] <wstein> I'm looking at #568 [10:09] <malb> I am looking at #558 [10:09] <wstein> By the way, if you weren't here last time, basically scan the list of open bugs listed at trac for sage-2.8.4 or sage-2.9. [10:09] <wstein> When you're working on one note that in irc. [10:09] <mabshoff|away> Well, I am back for a second: I am in Dortmund/Germany. [10:09] <boothby> I'm working on #503 [10:09] <wstein> When you refer to one in chat prefix the message with tthe trac number, e.g., [10:09] <wstein> #568: this is nuts. [10:10] <wstein> Since lots of different bugs will get discussed at the same time. [10:10] <wstein> Also, if you want to help somebody say -- [10:10] <wstein> #568 -- that looks interesting, I'm looking at it too. [10:10] <burcin> I'm trying #563.. [10:10] <wstein> #503 - is the "0^0" issue. comments welcome. [10:11] <mabshoff|away> Is anybody doing the official logging? [10:11] <mabshoff|away> Who wants to keep track of the bugs fixed? Or are we just using trac to sort that out after? [10:11] <wstein> I think keeping trac would be very good. [10:11] <wstein> Though trac does do it. [10:11] <wstein> Hmmm. [10:12] <wstein> mabshoff -- you're still marked as "away" [10:12] <mabshoff|away> I think mostly to aassign proper credit. [10:12] <wstein> I can log. [10:12] <wstein> yep. [10:12] <mabshoff|away> I know, just got out the shower, going shopping now. [10:12] <mabshoff|away> And on the internet I could be mabshoff's cat, just incredibly lucky that it can spell and type ;) [10:14] <malb> mabshoff where does sage-valgrind but its logfile? [10:14] <-- dmharvey2 has left this server. [10:16] <wstein> also, I will update the official sage repo as things are closed, so people can do hg_sage.pull() to get the fixes. [10:17] <wstein> #568 -- closed; thanks to David Joyner. [10:17] <burcin> malb: local/bin/sage.$PID [10:17] <malb> ah, thanks [10:18] <wstein> that's a dumb plce, no? [10:18] <wstein> maybe it should be in the current directory? [10:18] <malb> yes, or SAGE_ROOT [10:18] <wstein> make moving that a trac enhancement. [10:18] <malb> maybe one doesn't have write access there, so cwd would be good [10:18] <wstein> yep! [10:18] <wstein> I'm working on #569 now. [10:21] <burcin> SAGE_ROOT is better I think.. [10:21] <burcin> who's opening the ticket? [10:21] <malb> can we assume that we have write access there? [10:21] <malb> think about a system-wide SAGE install [10:21] <burcin> hmm.. good point.. no [10:21] <burcin> ok, so cwd? [10:22] <malb> sounds good to me, or .sage/<something> [10:22] <wstein> I've mad #599 the valgrind log file issue. [10:22] <burcin> as soon as we agree on the place.. I can implement it.. [10:23] <wstein> #569 -- closed (David Joyner had fixed it and his patch looks good). [10:23] <malb> I vote for $HOME/.sage/sage-memcheck.PID [10:24] <wstein> #599: +1 [10:24] <burcin> ok.. $HOME/.sage/sage-memcheck.$PID it is then [10:25] <malb> mabshoff might have strong feelings about it [10:25] <wstein> #594 -- I'm working on incorporating and testing this patch "Teach the MAGMA interface how to handle GF(q) conversions" [10:25] <malb> cool [10:26] <-- craigcitro has left this server. [10:26] --> pdehaye has joined this channel ([email protected]). [10:26] <wstein> hi pdehaye -- welcome to bug squash day 2. [Sun Sep 2 2007] [11:19:41] <sage> I don't remember, to be honest. [Sun Sep 2 2007] [11:19:53] <sage> You could remove setting it and do a complete build of SAGE and see if it works. [Sun Sep 2 2007] [11:20:03] <mabshoff> I could :) [Sun Sep 2 2007] [11:20:30] <mabshoff> Problem might be that "LIBRARY_PATH=/tmp/Work2/sage-2.8.3.rc3/local/lib/:" has the trailing ":" [Sun Sep 2 2007] [11:20:39] <sage> ah. you could change that too [Sun Sep 2 2007] [11:21:06] <mabshoff> If LD_WHATEVER is empty skip the $LD_WHATEVER on export : [Sun Sep 2 2007] [11:21:08] <mabshoff> . [Sun Sep 2 2007] [11:22:13] <mabshoff> Removing the trailing ":" makes configure work. [Sun Sep 2 2007] [11:22:42] <mabshoff> May be a bug in the configure macro, [Sun Sep 2 2007] [11:23:01] <mabshoff> because "empty string" after the separator ":" is not equal to "." [10:30] --> You have joined the channel #sage-devel ([email protected]). [10:31] *** Channel modes: secret, no messages from outside [10:31] *** This channel was created on 08/17/2007 01:03:33 PM. [10:31] <malb> I see [10:31] <dmharvey> back [10:31] <sage-log> sage-log == "William's home desktop" [10:33] <burcin> #599: it's a very simple change in local/bin/sage-valgrind [10:33] <burcin> #599: one can do it by hand, but there is a patch in trac too [10:33] <wstein> good. [10:34] <burcin> is there a way of making the sage shell not print out the output, without using assignments? [10:35] <wstein> no [10:35] <wstein> ; [10:36] <wstein> put a semicolon at the end of the line? [10:37] *** syazdani is now known as syazdani|away. [10:37] <-- pdehaye has left this server. [10:39] <wstein> #599 -- why is it "sage-memcheck" instead of "sage-valgrind"? [10:40] <wstein> #599 -- also, why remove the pid from the filename? [10:40] <burcin> valgrind puts the pid itself.. [10:40] <wstein> oh, good. [10:40] <malb> there are several valgrind tools [10:40] <malb> we are using memcheck right now [10:40] <sage-log> ok, that's clear. [10:40] <malb> but there is also massif and cachegrind and so on [10:41] <malb> so its good to allow different names for different valgrind tools [10:41] <mabshoff|away> hi [10:41] *** mabshoff|away is now known as mabshoff. [10:41] <mabshoff> I have patches for the proper place of logfiles, [10:41] <mabshoff> and massif + cachegrind [10:41] <mabshoff> support. [10:41] <dmharvey> hi mabshoff, do you want to work on gcd now? [10:42] <mabshoff> Give me about half am hour for valgrind patches. [10:42] <dmharvey> ok [10:42] <mabshoff> And I have two Solaris build issues I would like to get merged ASAP. [10:42] <mabshoff> 1 is in scons: prefer g++ over SunPro for compiler, [10:42] <mabshoff> the other two are build fixes in sage_lib for Solarisl [10:42] <mabshoff> . [10:43] <mabshoff> For valgrind: -valgrind becomes an alias for -memcheck [10:43] <mabshoff> I also add -massif and -cachegrind. [10:43] <mabshoff> For now they use the "default" flags I use, but we could add env variables to overwrite. [10:44] <mabshoff> That is not implemented yet. [10:44] <mabshoff> Should I send you the patch?? [10:44] <mabshoff> Or does anybody prefer something different? [10:45] <mabshoff> re pid & valgrind: That can be changed per default. [10:45] <malb> I am all for PID [10:46] <malb> maybe printing the PID at startup when run with valgrind would be nice [10:46] <mabshoff> Of which process? [10:46] <timothyclemans> i'm working on 549 [10:46] <mabshoff> The problem is that the output from 3.3.0svn no longer put the pid *inside* the logfile. [10:46] <mabshoff> But that let's you potentially diff output from different runs much better. [10:47] --> dmharvey2 has joined this channel ([email protected]). [10:47] <malb> process: SAGE the most interesting one [10:47] <wstein> #594 -- it's closed (and in) -- this is Malb's magma ideal patch. [10:47] <malb> cool [10:47] <wstein> malb -- i added a docstring to your magma.py ideal function. hg_sage.pull() and look to make sure it is ok. [10:47] <mabshoff> Is there an obvious non-racy way to getermine the SAGE pid? [10:48] <mabshoff> Also for the patch: Where is the official sage-script hg repo in the tarball? [10:48] <wstein> #549 -- I'm trying to replicate that too. [10:49] <timothyclemans> i see it [10:49] <timothyclemans> empty lines need <br /> [10:50] <timothyclemans> maybe do a loop and if i == '\n' add '<br />' ? [10:52] <malb> wstein, magma docstring looks good [10:53] <wstein> #549 -- no. [10:53] <wstein> since it's a pre environment. [10:54] <timothyclemans> in the html code i see the line spaces but they need to be <br /> [10:54] <wstein> #549 -- maybe the css is broken. [10:54] <timothyclemans> huh to do a line space don't you do <br /> [10:55] <wstein> In a pre that isn't needed. [10:55] <wstein> Try it by itself. [10:55] <timothyclemans> i am [10:56] <timothyclemans> i see [10:57] <wstein> #549 -- look at pre.shrunk in css.py. [10:58] <wstein> it has "display:inline" [10:58] <wstein> which evidently gets rid of blank spaces. [10:58] <wstein> If you comment it out, then the blank *lines* come back. [10:58] <wstein> Unfortunately there is way too much padding around the pre then. [10:58] <timothyclemans> also tidy says that you can't have span around pre [11:01] <mabshoff> malb, burcin: Suggestion now is: log to sage-memcheck.PID, sage-massif.PID, sage-cachegrind.PID in $SAGE_ROOT [11:01] <mabshoff> depending on the tool used. [11:01] <malb> no, not in $SAGE_ROOT we might not have write access there [11:01] <dmharvey2> #424: apart from the new files and lines of code, it looks like the following files *may* need to be modified: configure, configure.in, gmp-h.in, mpn/asm-defs.m4, mpn/Makefile.am, mpn/Makefile.in. I don't totally understand the relationship between these files, I know that automake or autoconf or something generates some of these files from others. But we don't want SAGE to depend on automake/autoconf etc, correct? So does that m [11:01] <mabshoff> true. [11:01] <mabshoff> $SAGE_RC? [11:02] <burcin> mabshoff: $HOME/.sage/ was suggested.. [11:02] <mabshoff> Okay, that works. [11:02] <mabshoff> but how about sage-$TOOL.$PID? [11:02] <wstein> #549 -- thanks timothy -- good point! [11:02] <burcin> mabshoff: yes.. I think that was the spirit of malb's sage-memcheck idea [11:03] <wstein> #549 -- your hint about span and pre was enough for tom to claim to know what to do. [11:03] <wstein> I'm going to stop working on #549 and let you and he work on it. [11:03] <mabshoff> Yep, will do. [11:03] <mabshoff> And I wil add the extra -massif & -cachegrind flags. [11:03] <mabshoff> -valgrind will stay an alias for memcheck [11:04] <mabshoff> Everybody happy that way? [11:04] <wstein> #424 -- SAGE can't depend on autoconf. [11:04] <burcin> mabshoff: yep, that great [11:04] <burcin> sorry.. can't type :) [11:04] <wstein> So whatever files you get when you do autoreconf --all you have to copy out to patches, then copy in during spkg-install. [11:04] <wstein> This is for #424 [11:05] <dmharvey> #424: I remember last time I tried using autoconf for this I had problems with a version mismatch [11:05] <dmharvey> #424: so maybe I'll try doing it manually [11:05] <wstein> #549 -- boothby has actually fixed this before and it got lost, evidently... [11:05] <wstein> dmharvey -- if possible you may want to work on sage.math for this, so others can look directly at what you're doing... [11:06] <dmharvey> wstein: okay, good idea, I'll move over there. Everything will be in /home/dmharvey/424/. (in a few minutes) [11:07] <timothyclemans> I'm unable to fix #549 from the html [11:08] <timothyclemans> i do see that display:inline gets rid of the line spaces like william said [11:11] --> janwil has joined this channel ([email protected]). [11:11] <-- dmharvey2 has left this server. [11:12] <mhansen> Does anyone know how to fix a "not previously declared in definition part of extension type" error? [11:12] <janwil> hello [11:12] <mabshoff> hi janwil [11:13] <wstein> #518 dmharvey -- i can't apply your patch. [11:13] <wstein> mhansen -- declare whatever it is in the corresponding .pxd file. [11:14] <mhansen> Thanks. I figured it out -- I had been looking in the wrong pxd file. [11:15] <dmharvey> #518: incorrect parent or something? [11:15] <wstein> #106 -- I'm working on this: "maple (etc?) tab completion -- asking for a list of all completions gives a bad error message if maple isn't installed" [11:15] <wstein> no. [11:15] <wstein> #518 -- see the trac ticket. [11:15] <wstein> #518 -- way too many conflicts to merge [11:15] <wstein> if it were an .hg bundle there might be hope. [11:16] <wstein> or maybe you had made other changes and "patches don't commute" [11:16] <wstein> this is a typical example of where bundles are better than .patch... [11:16] <wstein> (maybe) [11:18] <timothyclemans> regarding notebook is huge white space between buttons and worksheet area on purpose? [11:18] <dmharvey> #518: okay, I guess I'll just go through and do it again at some point. I think the real problem here is to do with trac. I posted the patch a while back, but it didn't get rolled into the repository until now. But meanwhile you and robert had done a bunch of things. [11:19] <sage-log> yep. [11:19] <boothby> #549 is fixed, I'll put a patch up in a minute [11:19] <sage-log> dmharvey -- by the way #549 was your bug report. [11:20] <sage-log> #518: yep. [11:20] <sage-log> I hope it isn't too hard fixing the spacing. [11:23] <dmharvey> #518: no it's just boring [11:23] <sage-log> write a script to do it? [11:23] <boothby> #549 has patch up in trac. [11:24] <dmharvey> #518: would take longer than just doing it [11:24] <wstein> #518 -- but would be more fun :-) [11:24] <dmharvey> #518: i've got other funner things to do :-) [11:24] <malb> robertwb could you look at #558 I've posted a first patch to address the leak in the integer_pool [11:25] <robertwb> ok [11:26] <boothby> I'm gonna take a crack at #518 with sed. [11:27] <dmharvey> #518: boothby, ok but be careful, because only *some* of the file needs to be re-indented, some of it is fine already [11:27] *** syazdani|away is now known as syazdani. [11:27] <mabshoff> Just use emacs ;) [11:27] <robertwb> malb: what happens if there are integers laying around that are deallocated after exit is called? [11:27] <timothyclemans> since i can't look at the results of #549 patch could a notebook be ran with examples of the spacing? [11:28] <robertwb> this needs to be copied over to RDF as well [11:28] <boothby> ok, that's not gonna work. [11:28] <malb> robert: memleak I guess [11:28] <mabshoff> technically: missing deallocation. [11:28] <mabshoff> for robert. [11:29] <malb> So I should set the the counter to full and hope no integers are allocated afterwards? [11:31] <wstein> I propose creating a file sage/module_cleanup.py [11:31] <robertwb> Maybe set the pool size to 0 [11:31] <wstein> This will have a function that calls cleanup methods on modules that need them. [11:31] <wstein> This will be guaranteed to be called on exit. [11:32] <wstein> what do you think? [11:32] <boothby> #518 would take way more regular expression than I've got in me today. [11:32] <malb> isn't that the same as the quit stuff right now? [11:33] <dmharvey> #518: right, which is why I did it by hand :-) [11:33] <mabshoff> malb, burcin: massif output in txt or html? create ps visualization per default? [11:33] <robertwb> we should set integer_pool_size and integer_pool_count to 0 [11:34] <malb> mabshoff: don't know massif enough to answer [11:34] <malb> robertwb: ack [11:34] <mabshoff> ok [11:34] <mabshoff> let's go with txt for now. [11:34] <mabshoff> problem is that massigf always write the aux file to cwd :( [11:35] <burcin> mabshoff: test is good.. [11:35] <burcin> mabshoff: text.. :) [11:35] <burcin> mabshoff: but there should be a pointer to a document explaining how to get the others.. [11:36] <robertwb> malb: ??? [11:36] <malb> that meant: yes [11:37] <mabshoff> burcin: I am about to open a ticket for "Sage & valgrind doc" [11:37] <mabshoff> I wrote something in sage-devel a while ago, but I think I should start a wiki page first. [11:37] <robertwb> ah... you're not disgusted... [11:37] <wstein> malb: awesome. [11:37] <mabshoff> Then after some editing move it into sagedoc [11:38] <malb> malb: disgusted? [11:38] <malb> erm robertwb: disgusted? [11:38] <boothby> lol [11:38] <mabshoff> talkig to yourself already :) [11:38] <burcin> mabshoff: wiki is a good idea.. [11:39] <burcin> I wouldn't mind if the developer documentation was only in a wiki actually.. [11:39] <mabshoff> Yeah, throw some text in there, sort it all out .. [11:40] <mabshoff> hmm, cachegrind doesn't honour --log-file=$HOME/.sage/.. either. [11:40] <mabshoff> time to file some bugs. [11:42] <wstein> #106 -- closed. [11:42] <wstein> a vintage bug. [11:42] <mabshoff> :) [11:46] <malb> robertwb: I've uploaded a patch to make sure nothing gets added to the pool once its free, but there are still memleaks in there somewhere [11:46] <robertwb> hmm... [11:46] --> jbmohler_ has joined this channel ([email protected]). [11:47] <malb> these might be caused by optimizations in higher level code, though [11:49] <robertwb> valgrind still tracks it down to the integer pool though? [11:49] <robertwb> they might be integers still in use... [11:49] <malb> true [11:49] <syazdani> I was trying to upgrade sage, and it seems to fail on building maxima. [11:50] <mabshoff> Which platform? [11:50] <mabshoff> Upgrading from which version? [11:50] <syazdani> Hold on, I'm checking. [11:50] <malb> __pyx_f_7integer_fast_tp_dealloc (integer.c:14315) [11:50] <malb> tupledealloc (tupleobject.c:169) [11:50] <malb> initmatrix_integer_dense (matrix_integer_dense.c:18898) [11:50] <mabshoff> What is the exact error message? [11:50] <syazdani> going from 2.8.2 [11:50] <wstein> what operating system!?!?! [11:50] <malb> if I do the small example from my comment for the ticket [11:50] <syazdani> Linux, [11:50] <syazdani> 32 bit, [11:50] <syazdani> Linux ms017 2.6.12-25mdksmp-pfaff-20060906 #1 SMP Wed Sep 6 16:49:16 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz unknown GNU/Linux [11:51] <syazdani> I will post the error message in a second... [11:51] <mabshoff> Isn't that the 5.12->5.13 upgrade? [11:51] <wstein> which linux distribution? [11:51] <wstein> mandriva? [11:51] <mabshoff> mandrake [11:51] <syazdani> Yes, Mandriva or Mandrake. [11:52] <syazdani> I guess this is a known problem then? [11:52] <wstein> I'm trying an upgrade on my mandriva box right now (32bit). [11:52] <janwil> I tried to download 2.8.3 binary distribution for Mandriva this morning and run ./sage, but I got a bunch of Floating point exceptions [11:52] <wstein> I hadn't tested upgrading from sage-2.8.3 on. [11:52] <mabshoff> Nope, you can see it by the name of tke kernel. [11:53] <syazdani> Summary: [11:53] <syazdani> clisp enabled. Executable name: "clisp" [11:53] <syazdani> clisp runtime is "" [11:53] <syazdani> default lisp: clisp [11:53] <syazdani> wish executable name: "wish" [11:53] <syazdani> make[1]: Entering directory `/1/scratch/syazdani/sage/spkg/build/maxima-5.13.0/src' [11:53] <syazdani> Making all in src [11:53] <wstein> maxima-5.13.0 built fine before on my mandriva box. [11:53] <syazdani> make[2]: Entering directory `/1/scratch/syazdani/sage/spkg/build/maxima-5.13.0/src/src' [11:53] <syazdani> test -d binary-clisp || mkdir binary-clisp [11:53] <syazdani> clisp -norc -q -x '(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t))' && \ [11:53] <syazdani> clisp -norc -q -x '(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :load :verbose t) (ext:saveinitmem "binary-clisp/maxima.mem" :init-function (function cl-user::run)))' [11:53] <syazdani> clisp: /1/scratch/syazdani/sage/sage-2.6/local/lib/clisp/base/lisp.run: No such file or directory [11:53] <syazdani> make[2]: *** [binary-clisp/maxima.mem] Error 1 [11:53] <syazdani> make[2]: Leaving directory `/1/scratch/syazdani/sage/spkg/build/maxima-5.13.0/src/src' [11:53] <syazdani> make[1]: *** [all-recursive] Error 1 [11:53] <syazdani> make[1]: Leaving directory `/1/scratch/syazdani/sage/spkg/build/maxima-5.13.0/src' [11:53] <wstein> Did you move your install? [11:53] <syazdani> *********************************************************** [11:53] <syazdani> Failed to make Maxima. [11:53] <syazdani> sorry for that giant post... [11:53] <syazdani> the problem seems to be in clisp. [11:54] <syazdani> I don't think so... [11:54] <wstein> hmmm. [11:54] <syazdani> Hmm, actually, maybe.. [11:54] <syazdani> let me check. [11:54] <wstein> How about if you force rebuild of the clisp package too. [11:54] <wstein> Just do rm spkg/installed/clisp* [11:54] <mabshoff> wstein: #473 has four valgrind patches attached. [11:54] <wstein> then "sage -upgrade" [11:54] <mabshoff> That also covers #599 [11:55] <mabshoff> But there are bugs in valgrind, some file for cachegrind and massif still end up in $CWD [11:55] <syazdani> ok, I will try that. [11:55] <-- timothyclemans has left this server ("leafChat IRC client: http://www.leafdigital.com/Software/leafChat/"). [11:56] <wstein> syazdani -- I am also building a 32-bit mandriva binary, which will take about 10-14 minutes... [11:56] <dmharvey> #424: when running a program in linux, how do I tell which shared libraries are actually being loaded; specifically how do I tell whether it's using the new GMP I just built, or the system one? [11:56] <mabshoff> ldd [11:56] --> pdehaye has joined this channel ([email protected]). [11:57] <wstein> ldd [11:57] <syazdani> was: ok, right now I'm rebuilding clisp... [11:57] <dmharvey> thanks [11:57] <mabshoff> dmharvey: I gotta make three more (easy) patches, then I can help out. [11:58] <mabshoff> Hey Oliver [11:58] <wstein> #473 -- I'm taking a look [11:58] <mabshoff> Cool, it is classic diffs. [11:59] <mabshoff> but you can actually commit via hg commit -u mabshoff :) [12:00] <wstein> #549 -- closed and pushed out. [12:01] <wstein> But caused #601 (a new bug). [12:01] <boothby> Exposed, not caused. [12:01] <wstein> mabshoff -- re valgrind, can you just send me an hg patch bundle? [12:01] <wstein> #473. [12:02] <mabshoff> I tried, but I have other changes in that directory. [12:02] <wstein> then I can merge if necessary. [12:02] <mabshoff> Where is the official hg repo for sage-script in the tree? [12:02] <wstein> its in local/bin/ [12:02] <mabshoff> ok [12:02] <wstein> Or you can do "hg_scripts.ci(); hg_scripts.send('scripts.hg') [12:02] <wstein> from in sage. [12:02] <mabshoff> Once sec. [12:04] <mabshoff> Okay, problem is that hg shows lots and lots of files with "?" [12:04] <janwil> I am trying to build 2.8.3.6 on Ubuntu ... let's see whether I will have more luck than 12 hours ago with 2.8.3.5 on Arch .. [12:04] <mabshoff> I did hg add on the new files. [12:05] <mabshoff> hg diff now shows my changes [12:05] <dmharvey> #424: breakthrough. It compiles and works. And it's pretty friggin fast. I think I know what to do from here. Mabshoff: when I've made a proper patch I'll ask you to take a look. [12:06] <mabshoff> :) [12:06] <mabshoff> very nice. [12:06] <mabshoff> wstein: Now I have [12:06] <mabshoff> changeset: 392:ca63d81a880b [12:06] <mabshoff> tag: tip [12:07] <mabshoff> user: mabshoff [12:07] <mabshoff> date: Thu Sep 06 21:18:50 2007 +0200 [12:07] <mabshoff> summary: add cachegrind and massif support from valgrind [12:07] <mabshoff> changeset: 391:d4b5e94af89d [12:07] <mabshoff> user: mabshoff [12:07] <mabshoff> date: Thu Sep 06 20:23:19 2007 +0200 [12:07] <mabshoff> summary: rename logfiles and store them in $HOME/.sage/ per default [12:07] <mabshoff> How do I send the last two changesets? [12:07] <dmharvey> heh and that's without the AMD64 patches.... will be interesting to compare against Magma when they're in there too :-) [12:07] <syazdani> wstein: It compiles. [12:07] <syazdani> thanks [12:08] <wstein> hg_scripts.send('foo.hg') will send me all changesets you've recorded [12:08] <mabshoff> Yep, the AMD64 patches brought about 10% for GBasis computations over Q [12:08] <wstein> then just make foo.hg available to me. [12:08] <mabshoff> ok, I will try . [12:09] <mabshoff> wstein: trac_ticket_473.hg is on the way. [12:11] <boothby> patch up for 601 [12:14] <wstein> thanks. [12:16] <dmharvey> wstein: so if I modify the gmp spkg, how do I tell SAGE to rebuild from that spkg? Is it something like sage -i path/to/new-package.spkg? [12:16] <mabshoff> add "-f" [12:17] <dmharvey> sage -f -i path/to/package.spkg? [12:17] <mabshoff> In case the time stamp doesn't change [12:17] <mabshoff> Yep, that should work. [12:17] <mabshoff> -f is "force" [12:17] <dmharvey> ok [12:17] <mabshoff> And instead of "time stamp" I mean spkg name. [12:18] <malb> I am looking into #566 now [12:18] <wstein> I am dealing with the proof=True/False option in number fields sage-devel, before the serious number theorists kill me. [12:19] <mabshoff> malb: What was the discussion with Robert about "pools" about - somehting different than #566? [12:19] <malb> yes, 566 are leaks in gmp.pxi [12:19] <mabshoff> Does Sage use a slab allocator for mpz's? [12:19] <mabshoff> ok [12:19] <malb> the pool leaked by itself [12:20] <mabshoff> Okay, then I understood that correctly. [12:20] <malb> I am not confided I killed all leaks in the pool, though [12:20] <mabshoff> burcin, are you still on #519? [12:20] <mabshoff> Well, every little bit of progress is good. [12:20] <dmharvey> wstein: btw I agree with nils etc [12:21] <burcin> mabshoff: #559.. [12:21] <wstein> #602 -- boothby is working on that. [12:21] <burcin> it might have been a better idea to look at the linear algebra directly though... too late now [12:22] <burcin> I didn't now sage had so much code for modular symbols.. [12:22] <mabshoff> Okay, I thing #559 isn't too bad. [12:23] <mabshoff> It looks like we leak a single mpz of 8 bytes a bunch of times. [12:24] <mabshoff> If you want I can post the correspinding pyx line number where the leak is. [12:24] <mabshoff> The run were done before the sage_lib scons rework, so they might be a little off. [12:24] <burcin> mabshoff: for #559? [12:25] <mabshoff> yep [12:25] <mabshoff> Or are you sure where the problem is? [12:27] <burcin> I know several functions leak in sage.modular.modsym.relation_matrix [12:27] <burcin> I don't know why.. [12:27] <mabshoff> :) [12:27] <mabshoff> You are not alone, but #559 is a single mpz. [12:30] <wstein> hi -- I've pushed out a clean proof=True by default, but easy to change, option for number fields. [12:33] <wstein> #473 -- mabshoff -- where is the bundle? [12:33] <wstein> I didn't get it in email. [12:33] <mabshoff> I send it, but who knows what happened. [12:33] <mabshoff> Let me check the logs on that box. No sendmail/postfix running as daemon. [12:33] <jbmohler_> I'm getting doc_test failures on vanilla 2.8.3.6 for sage/rings/number_field/number_field.py and sage/rings/number_field/number_field_ideal.py [12:33] <wstein> could you post a link? I didn't get the email. [12:33] <wstein> 32-bit? [12:33] <wstein> maybe I screwed up. [12:33] <mabshoff> How do I save the bundle? [12:34] <wstein> hg_scripts.send('a.hg') creates the file. [12:34] <mabshoff> Found it in $SAGE_LOCAL [12:34] <jbmohler_> Yes, 32-bit, it looks like precision issues on one of them [12:34] <wstein> then you send the file a.hg. [12:34] <mabshoff> ehh SAGE_ROOT [12:34] <wstein> I ust got that on a machine -- i'll fix it in a minute. [12:34] <wstein> jbmohler_ -- I did a huge amount on number fields. I added hundreds of doctests. [12:35] <mabshoff> burcin: opened #603, i.e. valgrind doc and assigned it to you. [12:35] <wstein> so some issues will creap up on some platforms with doctests. [12:35] <mabshoff> The abuse of power :) [12:35] <jbmohler_> wstein: Yes, I thought so, did they pass for you? [12:35] <wstein> on 64-bit linux. [12:35] <wstein> and a few other platforms. [12:35] <burcin> mabshoff: thanks.. :) [12:35] <wstein> but I just noticed a problem on 32-bit osx. [12:35] <mabshoff> Well, I can send more your way if you prefer ... [12:36] <jbmohler_> common failure: [12:36] <wstein> I'll fix it in 10 minutes or so and push it so you can do hg_sage.pull() [12:36] <jbmohler_> Expected: Fractional ideal (-2*a^2 - 1) of Number Field in a with defining polynomial x^4 + 3 [12:36] <jbmohler_> Got: Fractional ideal (2*a^2 - 1) of Number Field in a with defining polynomial x^4 + 3 [12:36] <mabshoff> But I will help out on the documentation, it is just better if we have more input. [12:36] <wstein> yep -- pari give slightly different results on 32 versus 64 bit. [12:36] <jbmohler_> 3 of these (with slightly different fractional ideas (but all having to do with a minus sign different) [12:36] <burcin> mabshoff: I'd prefer non documentation bugs... [12:38] <mabshoff> Oh, in that case wait a minute ;) [12:38] <mabshoff> We can assign it to malb *ducks* [12:38] <wstein> jbmohler_ -- yep. [12:38] <wstein> It would be desirable to somehow normalize the generators, I guess. [12:38] <mabshoff> wstein: send the bundle to you gmail address. [12:38] <mabshoff> brb [12:38] <wstein> But otherwise we should just mark the output as slightly random for now. [12:39] <wstein> #473 -- got it. [12:40] <wstein> ok, #473 is officially in. [12:41] <mabshoff> :) [12:41] <wstein> jbmohler_ -- could you try hg_sage.pull() then do the doctests in number_field? [12:42] <wstein> syazdani -- did sage build for you on mandriva. [12:42] <wstein> ? [12:45] <wstein> #601 -- now closed. [13:07] <sage-log>