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)