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> [13:07] <sage-log> [13:08] [CTCP] Received Version request from freenode-connect. [13:08] --> You have joined the channel #sage-devel ([email protected]). [13:08] [Error] sage-dev: No such channel. [13:09] *** Channel modes: secret, no messages from outside [13:09] *** This channel was created on 08/17/2007 01:03:33 PM. [13:09] <dmharvey> ummm how does that work? [13:09] <mabshoff> What does "ulimit -n" say [13:09] <dmharvey> 256 [13:10] <mabshoff> Try to raise that: "ulimit -n 512" [13:10] <dmharvey> ok [13:10] <mabshoff> might have to do that as suo. [13:10] <mabshoff> sudo [13:10] <mabshoff> I think you can set those permanently on OSX; I don't remember the details, though. [13:10] <mabshoff> The limits on OSX are pretty tight and cause easily trouble when building Sage. [13:11] <dmharvey> nah that doesn't help. I must be getting in an infinite loop in the spkg-install script or something. [13:11] <dmharvey> i'm trying to make it apply my patch in the gmp install script [13:11] <mabshoff> ok, that would explain the problem. [13:11] <mabshoff> That is a bash script? [13:11] --> pdehaye has joined this channel ([email protected]). [13:11] <mabshoff> Then set "#!/bin/bash -x" as shebang [13:12] <mabshoff> it activates debug output for bash, i.e. each line is printed as it is executed. [13:12] <dmharvey> ok thanks i'll try that [13:12] <sage> mabshoff -- what is Solaris9-fixes.hg a bundle for / against, etc? [13:12] <mabshoff> 2.8.3ish [13:13] <dmharvey> meanwhile: i tried sage -ba on sage.math, still getting stupid import errors. I might just have to rebuild the whole bloody thing [13:13] <mabshoff> It fixes two missing symbol problems when starting sage on neron. [13:13] <sage> no. [13:13] --> boothby has joined this channel ([email protected]). [13:13] <mabshoff> It doesn't apply? [13:13] <sage> dmharvey -- i can take a look (as you). [13:13] <sage> which directory. [13:14] <dmharvey> in /home/dmharvey/sage-2.8.3 [13:14] <dmharvey> i was just upgrading in preparation for trying to apply my gcd stuff (i'm working on the gcd stuff locally instead right now) [13:15] <sage> You have colorful prompts ;-) [13:15] <dmharvey> colourful actually [13:15] <sage> did you do a "sage -ba"? [13:16] <mhansen> sage: for #396, I have a patch disabling support for vector multiplication and moving it instead to .pairwise_product(). [13:16] <mhansen> sage: it passes all doc tests [13:17] <dmharvey> wstein: yes I did, same thing happened [13:18] <sage> that's weird -- I've never seen that error. [13:18] <sage> What is "stack_chk_fail" [13:18] <syazdani> Hmm, I ran the command "./sage -t" about an hour ago, and the tests are still happening. [13:19] <syazdani> Is it supposed to take this long? [13:19] <mabshoff> where is it at? [13:19] <sage> you moved your install. [13:19] <mabshoff> caculus.py? [13:19] <sage> and it is having trouble maybe finding something in ntl? [13:20] <dmharvey> I can't remember [13:21] <dmharvey> mabshoff: can you take a look at /home/dmharvey/temp/spkg-install? That's the install script I'm working on, from the gmp spkg. I added the lines after "# apply fast gcd patch". For some reason it's getting into an infinite loop. I don't really know how to write shells scripts. Can you see what's going wrong? [13:21] <sage> DAVID! [13:21] <sage> I figured it out. [13:21] <sage> dmharvey -- stack_chk_fail is defined in libgmp. [13:21] <sage> You are screwing with your libgmp, so you suddenly don't have it for some reason. [13:22] <sage> Hence libcsage.so, which wants it, can't find it. [13:22] <dmharvey> but I haven't touched gmp in there yet! [13:22] <dmharvey> ???? [13:22] <mabshoff> I will take a look at the script. [13:22] <sage> On my system my libgmp has it and on yours it doesn't. [13:22] <sage> for me: [13:22] <sage> was@ubuntu:~/s/local/lib$ nm libgmp.so.3 |grep stack_c U __stack_chk_fail@@GLIBC_2.4 [13:22] <mabshoff> maybe it picks up the "wrong one" [13:22] <sage> for you -- nothing: [13:22] <sage> sage$ nm /home/dmharvey/sage-2.8.3/local/lib/libgmp.so.3 |grep stack_chk [13:23] <dmharvey> well that's just weird [13:23] <sage> weird. [13:23] <sage> sage = (william stein, by the way) [13:24] <sage> anyway, stack_chk is in gmp. [13:24] <sage> so your problem has something to do with gmp. [13:24] <dmharvey> i guess i might have accidentally overwritten something in there [13:24] <dmharvey> but I can't remember ever touching it [13:24] <sage> you didn't change it recently. [13:25] <sage> weird. [13:25] <sage> the mod time is aug 31. [13:25] <dmharvey> i'll try rebuilding the usual gmp package to see if that helps [13:25] <jbmohler_> dmharvey: Do you have gmp outside your sage tree? [13:25] <dmharvey> yes I have multiples GMPs outside the sage tree [13:25] <dmharvey> i mess around with GMP all the time [13:25] <jbmohler_> Which the scons build is finding for some reason... [13:25] <sage> wait -- on my sage.math gmp I also don't have stack_chk. [13:26] <dmharvey> well that's no good [13:26] <sage> It's only my my laptop gmp that I have it. [13:26] <sage> and libcsage doesn't link it in for me on sage.math. [13:26] <dmharvey> im' rebuilding from gmp-4.2.1.p9.spkg now [13:26] <sage> I.e., it doesnt have that symbol. [13:26] <mabshoff> dmharvey: you have a procedure called patch() in spkg-install, but you want to invoke the external patch command. [13:26] <mabshoff> Instand inifinte loop :) [13:27] <dmharvey> mabshoff!!!!!!!! thanks [13:27] <mabshoff> I am here to serve [13:27] <dmharvey> i should have my programming license taken away [13:27] <sage> dmharvey -- don't use patch. [13:27] <sage> it's not a dependency of SAGE [13:27] <mabshoff> Don't worry. I have had more than enough "brown paperbag over my head" moments [13:27] <dmharvey> oh [13:27] <mabshoff> In fact, once was just last week, got scooled by malb. [13:28] <mabshoff> schooled [13:28] <sage> i prefer that prepatched versions of files be put in the patches directory, [13:28] <sage> since otherwise people have to install patch to build SAGE, which is annoying. [13:28] <sage> stack_chk_fail is part of libc: http://www.fabbrication.net/pro/indexed-source/glibc24/html/stack__chk__fail_8c-source.html [13:28] <dmharvey> well it starts getting a little dangerous when you have all these patches interacting [13:28] <sage> maybe. [13:29] <dmharvey> especially since my patch touches all the auto/config related fiels [13:29] <dmharvey> can hg patch things? [13:31] <sage> jbmohler -- how do you force scons to rebuild everything? [13:31] <dmharvey> ok, well i suppose as long as my patch doesn't touch the same files as the AMD64 or core duo patches, we should be okay (for now) [13:32] <sage> got it -- just scons -c [13:32] <sage> then scons install [13:32] <dmharvey> wstein: I'm going to leave that sage-2.8.3 alone for the moment, in case you want to play with it. [13:32] <sage> i'm stuck on it. you should try reinstalling ntl too [13:33] <jbmohler_> sage: right, they don't have a force option like make does [13:34] <sage> dmharvey -- i rebuild your libcsage.so and now it doesn't have any stack_* stuff in it. [13:34] --> craigcitro has joined this channel ([email protected]). [13:34] <mabshoff> Hey Craig [13:34] <craigcitro> hey michael [13:34] <dmharvey> wstein: sage still doesn't start though [13:34] <craigcitro> how goes the bug squash? i just got back from climbing, gonna eat and shower real quick [13:35] <mabshoff> Check out the roadmap .) [13:35] <mabshoff> Is anybody around here familiar with bober's partition code? [13:35] <mabshoff> I have an off linking issue at runtime on Solaris [13:36] <mabshoff> off->odd [13:36] <craigcitro> >mabshoff: where's the roadmap? [13:36] <sage> scons is a pain in the ass. [13:36] <sage> how do I get it to *actually* copy libcsage.so over? [13:36] <syazdani> craig: http://sagemath.org:9002/sage_trac/roadmap [13:36] <sage> It just refuses... [13:37] <syazdani> (Hi Craig!) [13:37] <sage> dmharvey -- i fixed your problem! [13:37] <sage> With 1 line: [13:37] <sage> ~/sage-2.8.3/devel/sage/c_lib [13:37] <sage> sage$ cp libcsage.so ../../../local/lib/libcsage.so [13:37] <sage> That this was needed is deeply annoying. [13:37] <jbmohler_> yes, you need to specify the actual install directory as a target [13:37] <sage> i see. [13:37] <sage> so dmharvey -- your sage now works on sage.math [13:37] <dmharvey> ok thanks [13:37] <jbmohler_> or, we often alias with Alias [13:38] <dmharvey> i hope you guys understand what actually happened [13:38] <sage> too bad that wasn't a ticket... [13:38] <jbmohler_> The default target is '.' -- the current directory [13:38] <sage> syazdani -- are you up to speed? [13:38] <sage> if not i built a mandriva binary. [13:38] <syazdani> I think so. [13:38] <sage> it's in sagemath.org under linux 32-bit binaries... [13:39] <syazdani> I'm running the tests one directory at a time, [13:39] <jbmohler_> sage: Was there a scons issue, or a confusion? [13:39] <syazdani> and it seems to work fine. [13:39] <sage> syazdani -- did you do "sage -t" from the SAGE_ROOT? [13:39] <sage> 'cause if so, that makes no sense. [13:39] <sage> YOu have to do "make test" [13:39] <sage> Or cd into devel/sage/sage and do "sage -t". [13:39] <syazdani> yes, I did... [13:40] <syazdani> that explains why it was running so many tests, I guess. [13:40] <craigcitro> (hey soroosh!) [13:41] <mabshoff> "partitions.so: symbol _Z4cosle: referenced symbol not found" is the Solaris problem. [13:41] <mabshoff> Any ideas? [13:42] <sage> mabshoff -- still. ick. [13:42] <mabshoff> I never looked at it. [13:42] <mabshoff> So I was hoping that somebody in here would pay it forward ;) [13:43] <mabshoff> sage: How about another try about the other Solaris fixes? [13:44] <mabshoff> Okay, I see the trouble with the last bundle. [13:45] <craigcitro> sage: i'm just coming into this in the middle, but where are you having the scons copy problem? [13:46] <sage> mabshoff -- on it regarding solaris. [13:46] <sage> craigcitro -- "scons install" doesn't know the target, which confused me. [13:47] <craigcitro> yeah, it only copies it over to $SAGE_ROOT/local/lib if it actually does something to update it [13:47] <craigcitro> that's exactly the problem we were having with branch switching [13:47] <craigcitro> in fact, if you do scons branch_switch [13:47] <craigcitro> it'll force the copy [13:47] <mabshoff> sage: the bundle was only the last uncomitted workaround to avoid doctesting the singulat interface. [13:49] <sage> mabshoff -- yeah, it sucks. [13:49] <sage> it hardcodes your paths for CC. [13:49] <sage> chick in something good and send it to me. [13:49] <sage> or? [13:49] <mabshoff> Yeah, that bit sucked. [13:50] <mabshoff> I got a better fix for scons that switches the preferred compiler on Solaris to gcc vs. SunPro [13:50] <wstein> hard coding it to your home directory always isn't good :-) [13:51] <mabshoff> That was after about 10 hours, I didn't care anymore, I just wanted to make it compile. [13:51] <sage> :-) [13:51] <jbmohler_> craigcitro: Why did you have to hard-code the copies? [13:51] <mabshoff> An hour later I found the real workaround, but I never reverted the earlier "fix" [13:52] <jbmohler_> Scons should check the actual file contents to see if things are out of date ... or is this more complicated? [13:52] <mabshoff> wstein: I can export the two relevant fixes and send them to you. [13:52] <sage> ok. [13:52] <mabshoff> At least they are hg patches ;) [13:54] <-- mhansen has left this server (Remote closed the connection). [13:55] <craigcitro> >jbmohler_: i didn't know how to tell scons that it should check to see if $SAGE_ROOT/local/lib was up to date. [13:55] <craigcitro> so when we'd switch branches, it would see sage-branch/c_lib/libcsage.dylib was up to date [13:55] <craigcitro> and not do the Install [13:56] <craigcitro> i asked in the scons-dev channel, and they suggested the forced copy. [13:56] <craigcitro> i'm just curious where you guys ran into a situation that it was updated but not copied, so i can fix it. ;) [13:57] <wstein> jbmohler -- did you see Kiran's email? [13:57] <wstein> I want to do: [13:57] <wstein> env = Environment(ENV = os.environ) [13:57] <mabshoff> That is quite interesting [13:57] <mabshoff> He should post his "env" [13:58] <jbmohler_> wstein: Feel free, it feels like the right thing in our context. In general, scons devs don't copy the environment so that funny user environment variables don't corrupt the build. [13:59] <jbmohler_> However, the whole sage "chroot" relies on funny user environment variables [13:59] <jbmohler_> craigcitro: was there a situation when it didn't copy and should have? It seems like a bug in sage [13:59] <craigcitro> no, it wasn't a bug in sage. it was just whenever you do sage -b [13:59] <jbmohler_> oops, not sage scons [13:59] <craigcitro> the issue is this [14:00] <craigcitro> whenever you switch branches, you don't care about file timestamps or anything [14:00] <jbmohler_> right, scons actually hashes the file contents [14:00] <craigcitro> you just *always* need to make sure that the $SAGE_ROOT/local/lib is a copy of sage-branch/c_lib/libcsage.dylib [14:00] <mabshoff> wstein: check out http://fsmath.mathematik.uni-dortmund.de/~mabshoff/patches/Sage-2.8.3-roundf%2Bisinf_workaround_on_Solaris.patch [14:00] <craigcitro> but scons doesn't know to check the install target [14:00] <craigcitro> it only knows to check the local target [14:01] <craigcitro> or, at least, this is what it always does [14:01] <jbmohler_> What if you called 'scons install'? [14:01] <craigcitro> it says sage-branch/c_lib/libcsage.dylib looks up to date, i must be done [14:01] <craigcitro> even if you call scons install [14:01] <craigcitro> because it decides to run commands based on seeing that sage-branch/c_lib/libcsage.dylib does or does not need updating [14:02] <jbmohler_> but, that's not true ... or, I'm confused [14:02] <craigcitro> at least, this is what i found by experimenting with scons [14:02] <mabshoff> Craig: who "maintains" the scons package? [14:02] <mabshoff> (in Sage) [14:02] <wstein> mhansen #396 -- are you around? [14:03] <craigcitro> oh, i have no idea ... i've never played with it. i had assumed joel did. ;) [14:03] <wstein> applying /home/was/Desktop/Sage-2.8.3-roundf+isinf_workaround_on_Solaris.patch [14:03] <wstein> /usr/bin/patch: **** malformed patch at line 37: --- a/sage/rings/rqdf_fix.h Tue Sep 04 08:51:32 2007 -0400 [14:03] <wstein> sage/modular/modsym/solaris_fix.h: No such file or directory [14:03] <wstein> mabshoff -- your patch doesn't work... [14:03] <mabshoff> Arrg, damn mercurial [14:04] <mabshoff> Wait one second, I removed one hunk. [14:04] <wstein> #396 -- i'm working on it. [14:04] <jbmohler_> mabshoff: What do you mean by "maintains"? Google for scons and you'll get their main page [14:04] <jbmohler_> The scons spkg is pretty much vanilla [14:05] <wstein> jbmohler_ is the official scons spkg maintainer. [14:05] <mabshoff> I wanted to add a patch that switched the default Compiler on Solaris to g++ [14:05] <mabshoff> away fom sun's cc & CC [14:05] <mabshoff> On neron there is a "dummy" cc which just says: please install the real cc [14:05] <jbmohler_> I hope we could do that in the SConstruct [14:06] <mabshoff> And since we cannot build with Sun's CC anyway. [14:06] <jbmohler_> We already have exceptions for darwin there [14:06] <mabshoff> I tried, it worked for C, but not for C++ [14:06] <mabshoff> I imported CXX from env, no dice. [14:06] <mabshoff> But you might get it to work. [14:07] <craigcitro> jbmohler_: what was the error that sage & dmharvey ran into above? i came in just as they working around it, so i didn't see what the problem was [14:07] <jbmohler_> let me look at the docs a bit for cc switch [14:07] <mabshoff> ok, np. [14:08] <jbmohler_> I didn't quite understand sage & dmharvey's problem ever [14:08] <mabshoff> I have a local workaround that I can just patch into "my" scons on Solaris package for now. [14:08] <-- pdehaye has left this server. [14:08] <dmharvey> and I don't understand it at all :-( [14:08] <craigcitro> hahahah [14:08] <craigcitro> hey david [14:08] <craigcitro> so what was happening? [14:10] <dmharvey> my sage broke [14:10] <dmharvey> i would run it and weird error messages came up [14:10] <mabshoff> wstein: I got the original patch up on fsmath. [14:10] <mabshoff> But there is one hung in there which shouldn't go in. [14:10] <dmharvey> william logged in as me and fixed it [14:10] <craigcitro> by just recopying c_lib/libcsage.so into place? [14:10] <mabshoff> The bit about "b/sage/rings/real_rqdf.pyx" [14:10] <mabshoff> was a mismerge. [14:11] --> mhansen has joined this channel ([email protected]). [14:11] <craigcitro> dmharvey: had you done a sage -b or anything recently? do you maintain multiple branches? [14:12] <dmharvey> i've forgotten [14:12] <dmharvey> it's all way too complicated [14:12] <craigcitro> grin ok [14:12] <wstein> off for lunch (with Robertwb and boothby) [14:12] <dmharvey> sorry craig, i'm planning to ignore the problem for now [14:12] <craigcitro> hah, it's all good [14:14] <jbmohler_> mabshoff: Environment( CC='<desired compiler>', CXX='<your desired compiler>' ) would appear the correct thing to me [14:15] <dmharvey> hmmmm.... now when I do sage -i gmp-4.2.1.p9.spkg, it doesn't seem to be applying the AMD64 patches correctly [14:15] <dmharvey> it's sending them to entirely the wrong directory, whcih doesn't even exist [14:15] <mabshoff> odd, got an update spkg-install? [14:16] <mabshoff> jbmoehler_: I will try that. [14:16] <dmharvey> no I mean even with the original gmp-4.2.1.p9.spkg [14:16] <dmharvey> not with my modifications [14:16] <mabshoff> jbmoehler_: I did something very similar, but it might be that the shell on William's Solaris box if fubar [14:16] <jbmohler_> craigcitro: Where is scons actually called from now? [14:17] <dmharvey> crap my build is such a mess, maybe I should start from scratch [14:17] <jbmohler_> found it -- sage-build [14:18] <craigcitro> jbmohler_: $SAGE_ROOT/local/bin ... [14:18] <craigcitro> i moved it there so that i didn't have to pass flags around about whether or not we were switching branches [14:18] <craigcitro> because it's where you know whether or not you're switching [14:18] <craigcitro> ok, i'm afk for a few to shower, and then i'll be back and ready to work [14:19] <mabshoff> Is anybody working on the Lie.spkg? [14:19] <mabshoff> I want to fix the curses vs. ncurese issue. [14:20] <-- mhansen has left this server (Remote closed the connection). [14:23] --> mhansen has joined this channel ([email protected]). [14:27] <syazdani> Ok, after several hours, I finally got sage to build, and run bunch of tests. [14:28] <syazdani> I mean, run "make test" [14:28] <mabshoff> And, how is it going? [14:28] <syazdani> All of the tests, except for 7 of them passed: [14:28] <syazdani> sage -t devel/sage-main/sage/modular/modform/ambient_g1.py [14:28] <syazdani> sage -t devel/sage-main/sage/modular/modform/eisenstein_submodule.py [14:28] <syazdani> sage -t devel/sage-main/sage/modular/modform/submodule.py [14:28] <syazdani> sage -t devel/sage-main/sage/rings/number_field/number_field.py [14:28] <syazdani> sage -t devel/sage-main/sage/rings/number_field/number_field_ideal.py [14:28] <syazdani> sage -t devel/sage-main/sage/rings/morphism.py [14:28] <syazdani> These ones failed. [14:28] <mabshoff> Did you do a "sage -upgrade" [14:29] <syazdani> I did "sage -upgrade" few hours ago. [14:29] <mabshoff> I believe those were issues with 32 bit only and fixed in the meantime. [14:29] <syazdani> I'm doing it again. [14:29] <mabshoff> try again :) [14:29] <syazdani> Ok, I just did sage upgrade. [14:29] <syazdani> Let me check. [14:29] <mabshoff> Bug Day is special, rapid progress. [14:29] *** dmharvey is now known as dmharvey|away. [14:29] *** dmharvey|away is now known as dmharvey. [14:30] <mabshoff> With the upgrade from about 30 minutes ago I have a failure in "sage -t coding/guava.py2 [14:30] <burcin> is anybody looking at the memleaks in linear algebra? [14:30] <burcin> #533? [14:30] <mabshoff> In a while. [14:30] <mabshoff> ------------------------------------------------------------ [14:30] <syazdani> no, I just did "./sage upgrade", and ran these tests, and they still fail. [14:30] <mabshoff> Unhandled SIGSEGV: A segmentation fault occured in SAGE. [14:30] <mabshoff> This probably occured because a *compiled* component [14:30] <mabshoff> of SAGE has a bug in it (typically accessing invalid memory) [14:30] <mabshoff> or is not properly wrapped with _sig_on, _sig_off. [14:30] <mabshoff> You might want to run SAGE under gdb with 'sage -gdb' to debug this. [14:30] <mabshoff> SAGE will now terminate (sorry). [14:30] <mabshoff> ------------------------------------------------------------ [14:30] <mabshoff> Okay, interesting. [14:31] <mabshoff> wstein is at lunch, and he added a lot of doctest in that area. [14:31] <syazdani> make there are some packages that I need to force it to upgrade again? [14:31] <syazdani> well, I looked at the one in morphism.py just now, [14:31] <mabshoff> Try a hg_sage.pull() [14:31] <syazdani> and the the doctest is correct, and sage is returning the incorrect value. [14:32] <mabshoff> If there are any updates exit sage and do a ./sage -b [14:32] <syazdani> hmm, there were 21 changes.... [14:32] <mabshoff> You can rerun those failed tests. [14:33] <syazdani> ok, I will wait for it to recompile, and then try again. :) [14:33] <mabshoff> okay [14:34] <mabshoff> Phew, adding -t the failed test with guave no longer makes it segfault, [14:34] <mabshoff> but there are failed tests. [14:35] <mabshoff> burcin: #533 is quite hard. [14:35] <mabshoff> William and I looked at it for about 2 hours and he fixed two leaks. But there is still one more. [14:36] <burcin> mabshoff: I think #563 is caused by something similar.. [14:38] <burcin> mabshoff: anyway.. I'm looking at sparse matricies now.. [14:38] <mabshoff> ok [14:38] <mabshoff> the guava issue goes away once you nuke the gap workspace. [14:38] <mabshoff> I though that was fixed. Damn it. [14:39] <mabshoff> Hehe, #563 is deep in LinBox. [14:39] <mabshoff> I reported that one and another one to LinBox-use in the hope that they would fix it. [14:42] <syazdani> Ok, out of those seven, the first six now pass, [14:42] <syazdani> but the morphism bug is still there. [14:42] <mabshoff> Interesting. [14:44] <syazdani> Hmm, running the same commands on sage gives the right answer. [14:44] <syazdani> Let me try the tests again... [14:44] <mabshoff> :) [14:45] <syazdani> I'm very confused... [14:46] <syazdani> it still fails when I run "sage -t .../morphism.py", [14:46] <syazdani> but running the tests inside sage works fine. [14:47] <mabshoff> Hmm, definitely very odd. [14:47] <mabshoff> That is with mandriva or whatever it is called these days. [14:47] <mabshoff> Which doctest fails? Is it always the same? [14:48] <craigcitro> hey soroosh -- which test is it that's failing? [14:48] <syazdani> Yes, it's always the same. It fails on line 514 [14:48] <syazdani> Also, when I ask for verbose output, it passes. [14:48] <craigcitro> it's sage/modular/morphism.py ? [14:48] <craigcitro> err, probably not, since that doesn't exist ;) [14:49] <mabshoff> +devel [14:49] <craigcitro> oh, sage/ring/morphism.py [14:49] <syazdani> devel/sage-main/sage/rings/morphism.py [14:49] <syazdani> :) [14:52] <syazdani> I'm heading out right now [14:53] <syazdani> I will be back in few hours though. [14:53] <syazdani> quit [14:53] <syazdani> :) [14:53] <syazdani> \quit [14:53] <syazdani> Ok, how does one quit from the irc channel? :) [14:54] <craigcitro> forward slash quit [14:54] <mabshoff> "/" instead of \ [14:54] <dmharvey> I could tell you but I would have to kill myself [14:54] <syazdani> thanks [14:54] <mabshoff> :) [14:54] <craigcitro> hah [14:54] <syazdani> :) bye for now. [14:54] <-- syazdani has left this server ("leaving"). [14:54] <craigcitro> i think it would have been funny if mabshoff and i had logged out in response, since we'd typed the right command. [14:54] <dmharvey> that's what I almost did [14:54] <craigcitro> grin [14:54] <craigcitro> then come back in and say "just like that!" [14:55] <mabshoff> Hey, this isn't bash.org [14:55] <jbmohler_> The moebius function used to accept polynomial arguments, but now it only takes integer arguments -- is that a good change? [14:55] <mabshoff> And you can play games with noobies so they log themselves out. [14:56] <mabshoff> classic line: How do I install X [14:56] <jbmohler_> The polynomials I was using it for where over a finite field ... if that makes a difference [14:56] <mabshoff> answer: First quit all programs. [14:56] <mabshoff> Then user who asked question drops out of channel - brilliant. [14:56] <dmharvey> Moving .asm files that are to be replaced to .asm.disabled ... [14:56] <dmharvey> mv: cannot stat `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x8\ [14:56] <dmharvey> 6_64/addmul_1.asm': No such file or directory [14:57] <dmharvey> mv: cannot stat `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x8\ [14:57] <dmharvey> 6_64/submul_1.asm': No such file or directory [14:57] <dmharvey> mv: cannot stat `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x8\ [14:57] <dmharvey> 6_64/add_n.asm': No such file or directory [14:57] <dmharvey> mv: cannot stat `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x8\ [14:57] <dmharvey> 6_64/sub_n.asm': No such file or directory [14:57] <dmharvey> mv: cannot stat `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x8\ [14:57] <dmharvey> 6_64/x86_64-defs.m4': No such file or directory [14:57] <craigcitro> did anyone else run into soroosh's problem? [14:57] <dmharvey> Copying new .asm and x86_64-defs.m4 files ... [14:57] <dmharvey> cp: target `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x86_64/\ [14:57] <dmharvey> ' is not a directory: No such file or directory [14:57] <dmharvey> cp: target `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x86_64/\ [14:57] <dmharvey> ' is not a directory: No such file or directory [14:57] <dmharvey> Copying new gmp-mparam.h... [14:57] <dmharvey> cp: target `/home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp/mpn/x86_64/\ [14:57] <wstein> hi -- we're back. [14:57] <dmharvey> ' is not a directory: No such file or directory [14:57] <dmharvey> Done. [14:57] <dmharvey> You can now go to /home/dmharvey/sage-2.8.3.6/spkg/build/gmp-4.2.1.p9/gmp and c\ [14:57] <mabshoff> Nope, cannot reproduce it (the doctest failure) [14:57] <dmharvey> onfigure/make/make_check as usual. [14:57] <dmharvey> oops [14:57] <dmharvey> well, what I was trying to say was: [14:57] <dmharvey> I don't think the AMD64 patch is being applied properly [14:57] <dmharvey> in 2.8.3.6 [14:57] <mabshoff> Does it work mannually? [14:58] <mabshoff> maybe the "-pX" level is wrong. i.e. X=2