SAGE Bug Squash Day 2

The event will take place on THURSDAY September 6th, 2007 and officially start around 10 am pacific standard time. It will go on for up to 16 hours and some people will usually meet the day after and finish up some of the leftovers.

Remember the "Twisted Rule" -- Don't work on anything unless there is a trac ticket for it. 

From Linux you can chat via a text console by installing "irssi", running it, and typing 
  /SERVER add irc.freenode.net 
  /SERVER irc.freenode.net
  /join #sage-devel

Participants (with area they would like to work on)

IRC

Irc log for Bug Squash Day 2

[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 (n=[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 (n=[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 (n=[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 (n=[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 (n=[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 (n=[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 (n=[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 (n=[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*a2 - 1) of Number Field in a with defining polynomial x4 + 3 [12:36] <jbmohler_> Got: Fractional ideal (2*a2 - 1) of Number Field in a with defining polynomial x4 + 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 (n=[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 (n=[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 (n=[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 (n=[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 (n=[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 (n=[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 [14:57] <mabshoff> Does it work mannually? [14:58] <mabshoff> maybe the "-pX" level is wrong. i.e. X=2 [15:00] <malb> #566 -- fixed, see trac [15:00] <dmharvey> yeah, and magma is now faster than sage at basic arithmetic, where it should just be using GMP [15:01] <dmharvey> so why should AMD64 patches have become broken? [15:01] <jbmohler_> mabshoff: Did you notice Kiran's latest post on sage-devel where he says that passing the environment straight through fixes his LONG_BIT? [15:01] <dmharvey> does anyone have a pre-2.8 build available on sage.math? [15:02] <mabshoff> yep, that is very odd. [15:02] <mabshoff> dmharvey: you might have to patch with a different directory depth. [15:02] <mabshoff> Do you have the spkg around somewhere? [15:03] <mabshoff> Have you checked in /home/was? [15:03] --> pdehaye has joined this channel (n=[email protected]). [15:03] <-- pdehaye has left this server (Client Quit). [15:03] <mabshoff> malb: I found another issue with valgrind: sage -t -valgrind doesn't work properly yet. [15:03] <mabshoff> Will fix that next. [15:03] <mabshoff> it spews the log files all over the place. [15:05] <dmharvey> mabshoff: yeah I think I see what's going wrong. I just don't understand why something like that broke and why no-one noticed. That's really annoying. Who knows how long it's been like that. [15:05] --> pdehaye has joined this channel (n=[email protected]). [15:06] <mabshoff> Well, external patches have a tendancy to break, and the gmp project is reluctant to merge stuff like the better AMD64 assembly. [15:06] <mabshoff> gmp 4.1.4 just sucked on Opterons. [15:06] <-- pdehaye has left this server (Client Quit). [15:07] <wstein> dmharvey -- locate sage-2.7 finds many [15:07] <dmharvey> well what must have happened is that someone rearranged the gmp spkg and didn't bother reading the warning messages that bash was spitting out [15:07] <mabshoff> malb: your patch also fixes #519, I believe. [15:07] <wstein> what's up with gmp? [15:07] <wstein> warning -- the gmp spkg pre 2.8 is bad bad bad. [15:07] <dmharvey> it's not applying the AMD64 patches [15:07] <wstein> ah [15:08] <dmharvey> probably not the core 2 duo either [15:08] <mabshoff> wstein: a little time for that Solaris patch again? [15:08] <wstein> this wouldn't have mattered pre 2.8, since they were pre-applied to the src/ directory. [15:08] <wstein> mabshoff - sure, what's the latest? [15:08] <mabshoff> This is the original, with one file merged that shouldn't [15:08] <mabshoff> same url [15:08] <mabshoff> http://fsmath.mathematik.uni-dortmund.de/~mabshoff/patches/Sage-2.8.3-roundf+isinf_workaround_on_Solaris.patch [15:09] <mabshoff> I am working on more fixes for -valgrinf [15:09] <mabshoff> d [15:09] <mabshoff> the doc-test case needs the same fixes as the sage-sage case. [15:09] <dmharvey> wstein: right, for sage 2.7 we have: [15:10] <dmharvey> sage: a = ZZ.random_element(2^100000) [15:10] <dmharvey> sage: b = ZZ.random_element(2^100000) [15:10] <dmharvey> sage: timeit c = a * b [15:10] <dmharvey> 1000 loops, best of 3: 872 µs per loop [15:10] <dmharvey> for sage 2.8.3.6 we have: [15:10] <dmharvey> 1000 loops, best of 3: 1.18 ms per loop [15:10] <wstein> dmharvey -- ok. [15:10] <wstein> we can fix that. [15:10] <dmharvey> they were pre-applied?? [15:10] <wstein> yes. [15:11] <dmharvey> even on the wrong system? [15:11] <wstein> this caused some major problems. [15:11] <wstein> YES. [15:11] <dmharvey> since both of them touched x86_64? [15:11] <wstein> It meant, e.g., that binaries built on one system would not work on others. [15:11] <wstein> In some cases. [15:11] <wstein> So now I test that src is exactly identical to the vanilla gmp distro. [15:12] <dmharvey> so what's the right way to fix this? [15:12] <malb> mabshoff: it probably also fixes this one [15:13] <wstein> dmharvey -- which trac ticket is this? [15:13] <jbmohler_> mabshoff: Did you get your scons compiler selection issue resolved in a nice way? [15:13] <dmharvey> doesn't have one yet, should I make one? [15:13] <dmharvey> i only just noticed it while working on #424 [15:13] <wstein> i'll make one now. [15:13] <dmharvey> ok [15:14] <dmharvey> if you have time to do that now, I can do the stupid monsky-washnitzer one, and come back for #424 when you're done with that [15:14] <wstein> it's now http://trac.sagemath.org/sage_trac/ticket/605 [15:15] <mabshoff> malb: you mean #519 - it believe so because the rand_state_init() was moved. [15:15] <malb> yes, but it's not free'd on clear yet [15:15] <mabshoff> jbmohler_: haven't gotten around to it. Want to get the Solaris patches merged first before I start building again. [15:15] <malb> but only leaks one instance now [15:15] <mabshoff> malb: exactly. [15:16] <mabshoff> instead of about 40! [15:16] --> pdehaye has joined this channel (n=[email protected]). [15:16] <mabshoff> Once your patch is in for the gmp issues I will rerun some tests just to see how much of the noise has disappeared. [15:17] <malb> also you might consider a python suppression file [15:17] <malb> I've added one at it's much easier on the eyes [15:17] <burcin> malb: where can I get your gmp patch? [15:18] <wstein> I want to finish up #396 since I was halfway through it. [15:18] <wstein> mabshoff -- your patch is applied and pushed. [15:18] <mabshoff> Yeah about that supression, I have also thought about using --pydebug. [15:18] <mabshoff> Cool, did you revert the one "Blah" bit? [15:18] <malb> its not a gmp patch, its for c_lib and gmp.pxi, but you can get it at http://www.sagemath.org:9002/sage_trac/ticket/566 [15:18] <wstein> dmharvey -- i should be able to do #396 in about 15 minutes. Then I'll work on gmp with you. [15:19] <dmharvey> wstein: ok [15:19] <burcin> malb: thanks.. I got that.. the linear algebra leaks seem to point to gmpz_realloc [15:19] <burcin> malb: so I want to run a test with your patch too [15:19] <-- pdehaye has left this server (Client Quit). [15:19] <mabshoff> malb: There is some old docs at the python site that show how to use pydebug macros to look at reference counts and so on. [15:19] <mabshoff> I think we should add those as a debug option to the Cython generated code, but this is a long term issue. [15:20] <malb> burcin: the gmpz_realloc thing should be unrelated [15:20] <mabshoff> doesn't sage "hook" gmp_alloc? [15:20] <malb> somehow module level ZZs are not deallocated properly sometimes I guess [15:20] <malb> yeah, but we seldomly realloc by hand only in the integer_pool [15:20] <mabshoff> Then I assume we would also have to hook realloc. [15:21] <mabshoff> ok. [15:21] <mabshoff> where is the integer_pool? (codewise) [15:21] <boothby> patch up for #602 [15:21] <malb> integer.pyx [15:21] <mabshoff> ok, thanks [15:21] <mabshoff> wstein needs to patch faster ;) [15:21] <wstein> :-) [15:22] <mabshoff> And he doesn't scale past one core *ducks* [15:23] <wstein> hey, how many people are subscribed to sage-devel :-) [15:23] <mabshoff> About 197, but 40 are banned spammers. [15:24] <burcin> malb: do you have time to look at modules/vector_rational_sparse_c.pxi [15:25] <burcin> I can't understand what's happening with add_mpq_vector_init [15:25] <malb> ytes [15:25] <malb> which ticket is that [15:25] <sage> burcin -- if you can't figure it out, I might be able to, since I wrote that... [15:25] <sage> at least you can blame me. [15:25] <malb> by the way: burcin nice to meet you in real time [15:26] <burcin> we free only the entries of z at the end of the function [15:26] <burcin> malb: yes.. how's london? [15:27] <malb> good, well, 1:30h to and from uni sucks big time but besides that, it's great [15:27] <dmharvey> wstein: I think I can manage both #424 and #605 myself [15:28] <sage> cool -- #396 is more involved than I expected. [15:28] <dmharvey> but i'll need a linux core 2 duo to try it out on [15:28] <sage> dmharvey -- would a xeon mac running linux work? [15:28] <malb> so what exactly is the problem ith ad_mpq_vector_init? [15:28] <dmharvey> ummmm I don't know, I can see [15:28] <dmharvey> you mean bsd? [15:29] <dmharvey> wait a second, that's not linux [15:29] <burcin> malb: we do mpq_vector_init(z), but no mpq_vector_clear [15:29] <dmharvey> all I mean is, we don't have any 64-bit support on mac OS's as far as I know [15:30] <malb> and you wonder where that should happen? [15:30] <sage> dmharvey -- i have about 10 vmware linux's running on bsd under vmware. [15:30] <burcin> but I don't get why we're clearing the entries anyway.. isn't z the sum? [15:30] <mabshoff> burcin: That is partially by design, but there is one ticket which I thought it needed a clear at the end. [15:30] <mabshoff> Which ticket are you looking at? [15:31] <malb> okay, will read source now [15:31] <dmharvey> wstein: how do I log into one of those? [15:31] <burcin> mabshoff: I saw #564.. I also don't have a test case.. [15:32] <mabshoff> one second .. checking [15:33] <mabshoff> "for n in range(10,100): a=ModularSymbols(n,sign=1).decomposition(); print n, get_memory_usage()" [15:33] <dmharvey> #424: I just got the fast gcd code running in SAGE on my laptop :-) [15:33] <mabshoff> it is right at the top of the ticket. [15:33] <mabshoff> It had two out of three leaks closed. [15:33] <craigcitro> >dmharvey: do you have sage on your laptop? did you get a new laptop? [15:33] <mabshoff> And #533 seemed to trigger the other issue. [15:33] <craigcitro> i thought you were still working remotely ... [15:34] <dmharvey> craig: yes! about two weeks old I think [15:34] <malb> burcin: did you test the code actually works? [15:34] <mabshoff> Those leaks all hit similar code paths, so it might be a good idea to rerun the tests and see which ones are left/the bif ones. [15:34] <mabshoff> bif->big [15:35] <burcin> mabshoff: i'm still tracking that one.. echelonize is leaking.. [15:35] <mabshoff> burcin: For the test case under valrgind reduce the range() thingy. [15:35] <mabshoff> cool. [15:35] <burcin> mabshoff: will try to narrow it down further [15:36] --> bobmoretti has joined this channel (n=[email protected]). [15:36] <bobmoretti> hello bug squashers [15:36] <malb> hi [15:37] <mabshoff> Yeah, try to create a specific test case for say echelonize [15:38] <wstein> hi bobmoretti. [15:38] <mabshoff> Hello [15:38] <malb> burcin: "but I don't get why we're clearing the entries anyway.. isn't z the sum?" we are only clearing the entries > k [15:38] <wstein> bobmoretti -- when using screen, how do you go to the beginning of the line in bash without going nuts? [15:38] <mabshoff> CTRL-A + escape [15:39] <wstein> that switches to scroll mode. [15:39] <wstein> I just want to do what "ctrl-a" does when not using screen. [15:39] <mabshoff> okay, I misunderstood. [15:39] <bobmoretti> CTRL-A A [15:39] <bobmoretti> I think [15:39] <mabshoff> lol [15:39] <wstein> bobmoretti ctrl-a a goes to the previous screen window. [15:39] <malb> burcin: we definitely don't want to clear that vector at the end of the function call it is our result [15:39] <bobmoretti> yeah, it's \C-a a [15:39] <bobmoretti> not \C-a \C-a [15:40] <burcin> malb: ok.. I got it now.. thanks.. [15:40] <wstein> ah! thanks! [15:40] <bobmoretti> no problem. Are seattle people meeting somewhere physically? [15:40] <dropdrive> wstein: You can also use C-something-else for the escape in screen. Handy if you use C-a a lot. [15:41] <wstein> dropdrive -- i couldn't figure out how to change that to something I liked. [15:41] <wstein> The man page explains how to change it, but the "something-else" uses a very strange [15:41] <wstein> notation, which isn't explained at all. So I had no clue how to actually do it. [15:41] <dropdrive> wstein: I personally use C-\ which I like a lot. [15:41] <wstein> how do you change to that? [15:42] <dropdrive> wstein: Put "escape ^\\\" in ~/.screenrc [15:42] <dropdrive> wstein: It's a bit disconcerting if you use keyboards with "\" in different positions though :) [15:43] <bobmoretti> wstein: are you folks in your office or the SAGE lab or somewhere else? [15:43] <wstein> bobmoretti -- we're at my house. [15:43] <wstein> feel free to come by [15:43] <bobmoretti> doh! I just biked back from capitol hill [15:44] <wstein> doh! [15:44] <mabshoff> In a Nelson voice: ha ha [15:44] <bobmoretti> how late will you guys be going at this tonight? [15:44] <sage> don't know.... probably 8pm ? [15:45] <bobmoretti> well, it's probably not worth it for me to come by then [15:45] <mabshoff> wstein: "sage -valgring -t blah" works but not "sage -t -valgring blah" doesn't [15:45] <bobmoretti> I can just work over IRC [15:45] <wstein> ok. [15:45] <mabshoff> Would you consider that a problem? [15:45] <wstein> mabshoff: sage-sage would do well to be rewritten to parse args better... [15:46] <mabshoff> Oh well, somebody elses problem then I guess ;) [15:46] <mabshoff> I also found out that "--help" was broken for ./sage - fix is coming. [15:48] <dmharvey> arrggggh. I just did a totally clean build of sage-2.8.3.6, and it's having that same import error from before, with libcsage or whatever it was. [15:48] <wstein> you have this in your default path: [15:48] <wstein> declare -x LD_LIBRARY_PATH="/home/dmharvey/gmp/install/lib/" [15:48] <wstein> This could cause trouble... [15:49] <dmharvey> ah [15:49] <jbmohler_> sage-sage rewritten to parse args .... that would make me utterly ecstatic! [15:49] <sage> jbmohler -- we could rewrite it in python... [15:49] <sage> that would be much nicer. [15:49] <malb> I am looking into #532 (memleak I caused) [15:49] <dmharvey> wstein: oh and that explains some totally weird stuff I noticed a few weeks ago too..... [15:50] <jbmohler_> yes, I think it will be necessary to write it in python to handle the gnu long-options correctly (optparse is a wonderful module and would make it quite easy to write) [15:51] <mhansen> wstein: #230/#236 can be closed. I can add an enhancement ticket to allow for the loading of spyx/pyx files. [15:51] <dmharvey> oh does that mean I have to rebuild AGAIN???? [15:51] <mhansen> wstein: #387 can be closed [15:52] <mhansen> wstein: I attached patches for #334 and #553 [15:53] <wstein> mhansent -- I'm working on #396 [15:53] <mhansen> wstein: I have a patch for #396 which throws an error when multiplying two vectors. Instead, I moved all that functionality to .pairwise_product(). [15:53] <wstein> mhansen -- ok, make it an enhancement. [15:54] <wstein> dmharvey -- just rebuild your libcsage. [15:54] <mhansen> wstein: sage -testall passes with my patch for #396. [15:54] <wstein> maybe ntl too [15:54] <wstein> mhansen -- * should be defined. [15:55] <wstein> Also, there are 6 places where vector * vector is implemented. [15:55] <mhansen> wstein: I changed all of those. [15:55] <wstein> These need to all be changed to componentwise_product. [15:55] <wstein> to what? [15:55] <mhansen> _pairwise_product_c_impl [15:55] <wstein> there is nothing attached to ticket #396. [15:56] <wstein> did you implement dot products though, and leave _vector_times_vector_c_impl as dot product? [15:56] <wstein> _vector_times_vector_c_impl should return the dot product [15:57] <wstein> #396 -- i think we just replicated work in different directions for #396. [15:57] <mhansen> didn't implement the dot products [15:58] <wstein> can you send me your patch for #396. [15:58] <wstein> I'll take your _pairwise_product_c_impl code. [15:58] <wstein> But I'll keep the _vector_time_vector_c_impl dot product code I've written. [15:58] <wstein> That will work well together. [15:59] <mabshoff> wstein: I send you additional support for valgrind with sage-doctest [16:00] <mhansen> wstein: I attached it to #396. I changed all the doctests to show my error when doing v*v, but there are relatively few of them. [16:01] <wstein> ok, i'll merge it in. [16:03] <mabshoff> #396, my patch or both? [16:04] <dmharvey> wstein: I'm going out for some dinner. I'll be back in < 2 hours probably, I'm planning to finish off #424, #605, and probably #518 tonight. I think I've got #424 and #605 covered, I've just got to wait for some things to finish building. [16:04] <wstein> cu [16:04] <mabshoff> cu [16:09] <malb> mhh, are module level variables (e.g. "RR = RealField()") free'd at the end or does Python just not bother? [16:09] <mabshoff> Might be a reference count issue, we haven't really gotten that deep into the code. [16:10] <malb> I see [16:10] <mabshoff> Or is that are of the code just missing deallocation routines? [16:10] <malb> nope [16:10] <mabshoff> Well, reference counts in python is an advanced topic. At least for me. [16:11] <malb> Pyrex doesn't seem to clean them up [16:11] <malb> robertwb are you around -- oh Cython guru [16:11] <robertwb> hi [16:11] <mabshoff> come speak with is mortals. [16:12] <robertwb> so, let me get up to speed [16:12] <malb> module level PyObjects in Cython [16:12] <robertwb> yes [16:12] <mabshoff> Some of us might buy you some real beer in England, st SD6 [16:12] <mabshoff> at [16:12] <malb> i.e. real_mpfr.pyx [16:12] <malb> RR = RealField() [16:12] <robertwb> uh huh [16:13] <malb> any hook to clean it up again? [16:13] <robertwb> oh, this is probably related to that dict issue that we were seeing before [16:13] <robertwb> RR lives in the dict that was never garbage collected [16:13] <malb> Pyx_InternTabEntry? [16:14] <malb> that's an array [16:14] <malb> I am looking at the C code [16:14] <malb> there are three occurences of "RR" [16:14] <robertwb> The dict that belongs to the module [16:14] <malb> cannot find where it is added to it [16:15] <robertwb> It's being created in Py_InitModule4 [16:16] <robertwb> see line 14700 or real_mpfr.c [16:17] <malb> so basically, if we manage to garbage collect that dictionary we get rid of most of the noise valgrind produces right now for a clean start-up and close? [16:17] <robertwb> a lot of it [16:17] <robertwb> if there are cdef module level objects, those would probably still be hanging around [16:17] <malb> sure [16:17] <robertwb> but those are rare [16:18] <malb> can you estimate how difficult this would be: the garbage collecting? [16:20] <robertwb> I have no idea... [16:20] <mabshoff> It might be very interesting to try this on a small stand alone cython module as robert suggested. [16:20] <robertwb> can you instruct me on how to run valgrind? [16:20] <mabshoff> plus --pydebug & reference count macros. [16:20] <robertwb> yeah [16:20] <mabshoff> ./sage -valgrind [16:20] <malb> first, you'll need valgrind [16:20] <mabshoff> spkg -i ... [16:20] <malb> mabshoff has an optional SAGE package [16:20] <robertwb> ah [16:21] <mabshoff> Yeah, but somebody needs to upload it to the official repo. [16:21] <mabshoff> You can get it from [16:21] <malb> if you quit sage right away you'll get the import memleaks only [16:21] <malb> they are written to SAGE_LOCAL/bin right now as sage.PID [16:21] <mabshoff> http://fsmath.mathematik.uni-dortmund.de/~mabshoff/sage/valgrind-3.3.0svn-r1787.spkg [16:21] <mhansen> Is the documentation in a separate repository? [16:22] <robertwb> on exit, we could always decref the dict until its count is 0, but bad things might happen if you ever need to use it again [16:22] <malb> mhansen: yes [16:22] <dmharvey> how do I rebuild libcsage? [16:22] <mabshoff> if you upgrade they do get written to $HOME/.sage [16:22] <mabshoff> wstein merged that patch already. [16:22] <craigcitro> dmharvey: scons install in c_lib [16:22] <mabshoff> including massif and cachegrind support. [16:23] <craigcitro> or, first, rm -f c_lib/libcsage.* [16:23] <craigcitro> then scons install [16:23] <dmharvey> scons is installed in the sage tree somewhere? [16:23] <craigcitro> oh, yeah, sorry [16:23] <craigcitro> source $SAGE_ROOT/local/bin first [16:23] <craigcitro> er [16:23] <craigcitro> $SAGE_ROOT/local/bin/sage-env [16:23] <mabshoff> the above valgrind spkg needs automake-1.9 installed, haven't corrected that I believe. [16:24] <craigcitro> it's just sage_root/local/bin/scons i believe [16:24] <mabshoff> (the external dependency. [16:24] <mabshoff> ) [16:24] <craigcitro> how was dinner? [16:24] <dmharvey> this is driving me so crazy. I've spent like 6 hours on this gcd thing, just because I'm a unix idiot [16:24] <dmharvey> haven't had dinner yet [16:24] <dmharvey> still fighting unix [16:24] <craigcitro> grin [16:24] <craigcitro> unix is mighty [16:25] <mabshoff> it gives you enough rope to hang yourself [16:25] <robertwb> sage: An error occurred while installing valgrind-3.3.0svn-r1787 [16:25] <mabshoff> That is its strength and weakness at once. [16:25] <robertwb> configure: error: cannot find install-sh or install.sh in . ./.. ./../.. [16:25] <robertwb> error configuring valgrind 3.3.0svn [16:25] <mabshoff> Yep, that is the automake problem. [16:26] <mabshoff> You can rerun autogen.sh in src [16:26] <malb> mabshoff how to I produce pictures with massif? [16:26] <sage-log> c [16:31] [Nick] Nickname already in use. Trying wstein. [16:31] [error] Closing Link: 127.0.0.1 (Connection Timed Out) [16:31] --> You have joined the channel #sage-devel (n=[email protected]). [16:31] [Error] sage-dev: No such channel. [16:31] <mabshoff> There goes UW [16:31] <craigcitro> is sage-log our new logging bot? [16:31] *** Channel modes: secret, no messages from outside [16:31] *** This channel was created on 08/17/2007 01:03:33 PM. [16:32] <mabshoff> Nope, just another irssi session. [16:32] <craigcitro> ah, ok [16:32] <burcin> well.. you got dropped.. not us :) [16:32] <mabshoff> trac has a pretty cool irc log extesion. [16:32] <mabshoff> 8) [16:32] <mabshoff> your 4 vs, us 8, I guess not. [16:33] <mabshoff> anyway: [16:33] <mabshoff> malb: the ps output still ends up in local/bin, that seems to be a bug in valgrind. [16:33] <mabshoff> in case you didn't get it. [16:33] <mabshoff> I will report that bug. [16:33] <mabshoff> The same happens with cachegrind. [16:35] <malb> which filename? [16:35] <malb> got it [16:35] <mabshoff> massif$PID.ps [16:35] <malb> sorry for the noise [16:35] <mabshoff> np [16:36] <mabshoff> malb: you migth want to increase "--depth=<number> [default: 3]" [16:36] <mabshoff> I set it to 6 in sage for now. [16:37] <malb> the number of heaps watched? [16:37] <malb> this ps stuff is really cool [16:37] <mabshoff> depth of the call chain. [16:37] <mabshoff> The deeper the more detail, but the slower it gets. [16:38] [CTCP] Received Version request from freenode-connect. [16:38] <mabshoff> The svn build I package is substancially faster for code with lots of allocs. [16:38] <mabshoff> And for our gmp on Core Duo we need some SS2/3 fixes that are not in 3.2.3 [16:39] <malb> that's why I use your package instead of the debian one [16:39] <mabshoff> :) [16:40] --> bobmoretti has joined this channel (n=[email protected]). [16:40] <malb> robertwb are you looking into that module dict deallocation thing? [16:40] <robertwb> upgrading my copy of SAGE on sage.math (which I presume has valgrind installed) [16:41] <malb> cool, so I stop working on memleaks involving module loading for now [16:41] <robertwb> ok [16:41] <mabshoff> Add /usr/local/valgrind-3.3.0svn-r6793/bin/ to $PATH on sage.math [16:41] <mabshoff> w00000t [16:41] <mabshoff> Nice. [16:44] <mabshoff> hehe, we can also add callgrind support to sage for profiling. [16:44] <malb> definitely! [16:44] <malb> I used it before, its quite valueable [16:45] <malb> I used it before *with* SAGE [16:45] <mabshoff> Sage, more debugging/profiling tools than any other CAS. [16:45] <mabshoff> Good. [16:45] <mabshoff> I put it on my list. [16:45] <mabshoff> Once my last patch is merged. [16:45] <malb> that's the beauty of not reinventing-the-wheel [16:46] <mabshoff> Oh, I can't even express how much I agree with that point. [16:47] <sage> :-) [16:47] <mabshoff> wb [16:48] <malb> strange, just debugging a function I've -- apparently -- written (solve_iml) [16:48] <mabshoff> :) [16:48] <malb> forgot about it, that was in a coffee shop in Seattle [16:48] <mhansen> sage: I attached a patch for #544. [16:48] <sage> thanks. [16:48] <sage> i'm *still* working on #396. [16:48] <sage> that was a very painful merge. [16:49] <sage> almost there. [16:49] <sage> then I can apply everything else. [16:49] <mabshoff> Good [16:49] <mhansen> Cool. [16:51] <robertwb> where is the valgrind output? [16:51] <mabshoff> What did you run? [16:51] <robertwb> sage -valgrind [16:51] <mabshoff> If you upgrade it is in $HOME/.sage [16:51] <mabshoff> otherweis in $SAGE_LOCAL/bin [16:51] <robertwb> what's it called? [16:52] <mabshoff> sage.PID[.THREAD] [16:52] <mabshoff> ls -altr [16:52] <mabshoff> then it is at the end of the listing [16:53] <mabshoff> There are usually at least three logs from one run. [16:53] <mabshoff> The big one is Sage's python process itself [16:53] <mabshoff> Skip over the first 3rd or so, that is from pymalloc being active. [16:54] <mabshoff> There are some small issues in there, but those are not related to the dictionary issue. [16:54] <mabshoff> search for ini$NAME_OF_CYTHON_CLASS and you should find the dictionary leak. [16:54] <mabshoff> init$NAME_OF_CYTHON, sorry [16:57] <-- bobmoretti has left this server (Read error: 110 (Connection timed out)). [16:58] <mabshoff> robertwb: One more fun fact: before the first valgrind cleanup patches the start up & quit default valgrind log was about 5.5MB, now it is less than 2.5MB [16:59] <robertwb> wow [16:59] <mabshoff> I can show you some before and after output for LinBox some time. [16:59] <mabshoff> Pretty scary. [16:59] <mabshoff> There is still one example in LinBox that leaks 8MB in about 3 seconds. [17:01] <sage> hi -- i finished and pushed out #396 [17:01] <mhansen> Nice work! [17:01] <sage> now I'm applying patches. [17:01] <boothby> does anybody use power_series_mpoly? the file says that it should be deleted. [17:02] <sage> mhansen -- you may want to revert your then pull. [17:02] <sage> I copied a lot of your work in manually. [17:02] <sage> leave it. [17:03] <sage> don't delete. [17:03] <mhansen> I have it in a separate branch. [17:03] <sage> good. [17:03] <sage> #602 -- i'm applying this. [17:05] <burcin> I still can't find where echelonize leaks, can anybody help? [17:06] <mabshoff> We should wait for malb's patch to be applied and have another look. [17:06] <malb> which echelonize? [17:06] <mabshoff> Do you have a simple exmaple that does just echelonize? [17:06] <mabshoff> Sparse or dense? [17:06] <malb> I am looking into solve_iml right now, and actually it doesn't leak [17:07] <burcin> matrix2.pyx echelonize.. [17:07] <mabshoff> isn't that the "abstract" class= [17:07] <mabshoff> ? [17:07] <malb> over which field are you working? [17:07] <malb> but abstract in a sense that it is implemented but slow [17:07] <mabshoff> ok [17:08] <burcin> over integers, or mod p.. doesn't seem to make a difference [17:08] <mabshoff> Has anybody ever tested the IML itself? [17:08] <malb> they all have their own implementations [17:08] <burcin> matricies are sparse in my case.. [17:08] <malb> ah, okay [17:08] <malb> they don't have their own implementations [17:08] <malb> I'll have a look [17:09] <malb> the solve_iml stuff DOES NOT leak [17:09] <mabshoff> Did you tests? [17:09] <malb> yes [17:09] <mabshoff> ok [17:09] <burcin> yes.. it uses _echelon_in_place_classical in matrix2.pyx [17:09] <malb> its just that the result has a reference from the prompt which doesn't get cleared for some reason [17:10] <mabshoff> Okay, but even if you create a bunch of object in python they get destroyed at exit if the reference count is zero. [17:10] <malb> if C is the result from _solve_iml then [17:11] <malb> if you "del C" right away ==> No leak [17:11] <mabshoff> So there might be (another) reference count issue around there somewhere. [17:11] <mabshoff> But C gets passed into python? [17:11] <malb> if tou print C, and del afterwards ==> leak [17:11] <malb> sure, C prompt [17:11] <malb> I'll write it down in the ticket [17:11] <mabshoff> How is C printed? Python? [17:11] <mabshoff> Cython? [17:13] <malb> Cython [17:13] <malb> I'll look at it [17:13] <-- jbmohler_ has left this server ("using sirc version 2.211+KSIRC/1.3.12"). [17:15] <malb> if I do c = str(C); del c, del C it also doesn't leak [17:15] <mabshoff> mmh, robertwb - any input on this? [17:16] <robertwb> so, you have something that doesn't leak if you delete it right away, but does if you leave it laying around? [17:17] <malb> if I print it [17:17] <malb> i.e. sage: C [17:17] <malb> ipython maybe? [17:17] <robertwb> oh, if you print it [17:17] <robertwb> yeah, I've run into this too, I think [17:18] <robertwb> I think it affects the notebook too though [17:18] <malb> burcin: GF(p) has its own sparse implementation [17:18] <malb> robertwb: okay so the problem seems to be deeper [17:18] <mhansen> sage: #606 replaces #236 [17:19] <malb> I think we'll need to assign someone to reading Python source :-) [17:19] <burcin> malb: it's Zmod(p) [17:19] <robertwb> FYI, a very simple cython module, loaded with "load simple_c.spyx" does not seem to leak [17:19] <wstein> mhansen -- closed #236 [17:19] <mabshoff> python startup+quit leaks about 500kb. [17:20] <mabshoff> So there are definitely issues there, too. [17:20] <malb> burcin: but that's GF(p)? [17:20] <mabshoff> Also the parser: some doctests just segfault when python is compiled without pymalloc. [17:22] <burcin> malb: ok.. Zmod(n) then.. the library doesn't detect that p is prime, and use a GF(p) instead [17:22] <malb> I see [17:22] <malb> so you are working over rings instead of fields and then it leaks [17:23] <burcin> yes.. I think it is just the function _echelon_in_place_classical, nothing special about the domain [17:26] <malb> so if we are working with say ZZ we are actually working over QQ [17:26] <-- robertwb has left this server (Read error: 104 (Connection reset by peer)). [17:26] --> robertwb has joined this channel (n=[email protected]). [17:28] <malb> burcin: ZZ --> QQ (special implementation), GF(p) --> special implementation, Z/modN --> Exception [17:29] <malb> what are you using as base ring/field? [17:29] <burcin> I use _mod_int to get the matrix.. I didn't tried generating one directly [17:29] <mabshoff> wstein: around? [17:30] <mabshoff> I have a fixed lie.spkg which now links against ncurses except for Solaris. [17:30] <mabshoff> See http://fsmath.mathematik.uni-dortmund.de/~mabshoff/sage/lie-2.2.2.p3.spkg [17:30] <mhansen> wstein: patch added for #606 [17:31] <mabshoff> The Lie problem is #595. [17:31] <malb> you are actually working with mod_n_sparse (which only works for mod_p sparse) [17:31] <malb> matrix2.spyx is not involved as far as I can see [17:31] <malb> and there is a leak in matrix_modn_sparse.pyx [17:34] <burcin> the implementation of the echelonize is in matrix2.pyx.. but that doesn't matter... [17:35] <-- boothby has left this server (Read error: 104 (Connection reset by peer)). [17:35] <burcin> so what do you mean by a leak in matrix_modn_sparse.pyx? [17:36] <malb> Let's agree on an example first: [17:36] <malb> sage: A = random_matrix(ZZ,10,10) [17:36] <malb> sage: B = A._mod_int(7) [17:37] <malb> now B is of type: Matrix_modn_sparse [17:37] --> soroosh has joined this channel (n=[email protected]). [17:37] <mabshoff> welcome back [17:37] <soroosh> thanks [17:37] <malb> A.echelonize is in matrix2.spyx you are right [17:37] <malb> it calls A._echelon_in_place_classical in matrix_modn_sparse.pyx [17:38] <malb> and there seems to be at least one leak (according to valgrind) [17:38] <burcin> yes.. we're on the same example.. [17:39] <malb> so we should look at echelon_in_place_classical in matrix_modn_sparse [17:39] <burcin> ModularSymbols(n,sign=1) calls this, so I'm hoping this will get rid of some of the leaks there [17:40] <malb> also at modules/vector_modn_sparse_c.pxi [17:41] <burcin> ?? but verbose doesn't produce the output I see in that function.. [17:41] <burcin> hmm.. just a sec [17:42] <soroosh> wstein: you told me you made a binary for Mandrake. Where is it again? [17:43] <burcin> ok.. you're right.. [17:47] <malb> the leak should be related to add_c_vector_modint_init ? [17:47] <wstein> on sagemath.org in the linux 32-bit binaries. [17:48] <mabshoff> wstein: I will be working on a new M2 spkg next, this might take a while. [17:48] <burcin> I can only reproduce it without the _mod_int now.. I don't know where I messed up my example code [17:48] <sage> does sage have any bugs left? [17:48] <mabshoff> Well, I am sure. [17:49] <mabshoff> Do you really mean sage by the way? [17:49] <burcin> sage: I get a memory leak besides an exception.. it's very useful [17:49] <sage> yes. :-) [17:49] <malb> reproduce the leak you were working on in somethign != GF(p)? [17:49] <sage> I'm trying to figure out what to do next.. [17:49] <burcin> malb: not it leaks if I echelonize over the integer ring [17:50] <mabshoff> close #595, apply the patch for #606 [17:50] <sage> jbmohler found a nice bug -- trac #608 -- core dump. [17:50] <sage> I'm going to work on that now. [17:50] <mabshoff> or is there even more outstanding/with patch/ready to go in. [17:50] <sage> oh, I'll look at 595 and 606 first. [17:50] <soroosh> There is a bit of problem with rings/morphisms on my build. [17:50] <mabshoff> I see if valgrind says anything about #608, or gdb [17:50] --> dmharvey_ has joined this channel (n=[email protected]). [17:51] <soroosh> I'm checking to see if it exists in the build you have on sagemath as well. [17:51] <dmharvey_> back [17:51] <mabshoff> #wb [17:52] <sage> #595 -- posted and closed. [17:52] <sage> it would be good if he could test it though... [17:52] <mabshoff> it goes boom in libpari (#608) [17:52] <sage> on sagemath.org when I try to install lie I get: [17:52] <sage> /usr/bin/ld: cannot find -lncurses [17:52] <sage> collect2: ld returned 1 exit status [17:52] <sage> make[1]: *** [Lie.exe] Error 1 [17:52] <sage> so I will reopen #595. [17:53] <mabshoff> it is still open. [17:53] <mabshoff> I can do something a little bit more sophisticated then. [17:53] <mabshoff> i.e. test to link against each lib, but pick ncurses over curses. [17:53] <sage> is it supposed to build without curses? [17:53] <sage> is curses a dependency? [17:53] <mabshoff> Damn Debian people. [17:54] <sage> I don't have that installed on sagemath.org. [17:54] <mabshoff> Yep, cannot be build without [n]curses [17:54] <mabshoff> readline depends on it. [17:54] <mabshoff> at least the current version. [17:54] <sage> i didn't have any curses installed with or without an n. [17:54] <sage> readline depends on it??? [17:54] <mabshoff> ncurses is pretty small, so we could make it a standard package. [17:55] <sage> readline doesn't. [17:55] <malb> burcin, maybe it doesn't even leak? e.g. the modn_sparse leak I was look into: If I delete "A" right away, it doesn't leak [17:55] <mabshoff> maybe you are right, but lie does need [n]curses. [17:55] <malb> the interpreter seems to hold on to global stuff [17:55] <sage> so it's a bug in the build that it requires ncurses or curses?! [17:55] <burcin> malb: let me see.. [17:55] <mabshoff> Nope, lie is just a little old. [17:56] <sage> ok. [17:56] <mabshoff> I couldn't even get it to build on neron without readline and curses. [17:56] <sage> it installed fine for me once I installed ncurses. [17:56] <mabshoff> It might be that lie has some magic defined to avoid readline & libcurses. [17:56] <mabshoff> Haven't looked at the sources in great detail. [17:57] <sage> I'll open a new ticket for moving lie to standard, which involves either removing [17:57] <burcin> malb: over the integers I still get a leak, even if I delete A right away [17:57] <sage> the curses dependency, or packaging curses for SAGE. [17:57] <malb> okay, so at least you got a real leak [17:57] <malb> that's good, I guess [17:57] <mabshoff> Couldn't we reuse the old ticket? [17:58] <sage> different though. [17:58] <sage> it's different. [17:58] <sage> getting it to build is different than moving it into standard. [17:58] <mabshoff> So we use ncurses for now, but once it becomes standard we should remove the dependency. [17:58] <sage> moving into standard presupposes removing dependencies, worrying about longterm quality and stability, etc. [17:58] <soroosh> sage: I can't run the binary version I downloaded off of sagemath.org (gives me floating point exceptions) Maybe the mandrive I'm running on is too old (2006.0)? [17:59] <mabshoff> Do we use lie via pexpect or as a library? [17:59] <sage> pexpect [17:59] <mabshoff> Okay, so that makes it likely that we need at least readline. [18:00] <mabshoff> Haha, read http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/185359 [18:00] <sage> soroosh -- your processor is probably too different, and the mandriva too old. [18:00] <sage> oh well. [18:00] <sage> You could try http://sagemath.org/SAGEbin/linux/32bit/sage-2.8.2-OLD-32bit-i686-Linux.tar.gz [18:00] <sage> bit O dpm [18:00] <sage> It'll likely run, but I'm not sure what the point will be. [18:00] <mabshoff> Well, I meant not to be gloating. Getting a litle tired, making some tea [18:00] <sage> sage includes readline. [18:00] <sage> pexpect hates readline. [18:01] <mabshoff> I hate pexpect :) [18:01] <mabshoff> I am invariant about readline, though [18:01] <sage> ok -- see trac #609 [18:01] <mabshoff> the bt for #608 looks very odd by the way. [18:02] <mabshoff> Damn, why me? But for sage-3 I have some time :) [18:02] <soroosh> oh well. Then my build has the funny feature that when I run "sage -t sage/rings/morphism.py" it fails on line 514, but running the same code in sage prompt gives the right answer. Any ideas what I should do about it? [18:03] <mabshoff> Does it actually crash or "just" fail? [18:03] <soroosh> It just fails. Returns (a-b+1) instead of (a-b) [18:04] <mabshoff> mmh, this is another odd one, just like janwil's issue. Sorry, no clue. [18:04] <sage> soroosh -- i saw that before. [18:04] <sage> Did you do an upgrade? [18:05] <sage> I saw that after an upgrade on an osx machine recently. [18:05] <sage> That same input even gives the right result on the command line. [18:05] <soroosh> I did an upgrade before joining the chat room [18:05] <sage> Too bad you didn't start a clean build. [18:05] <sage> It would be fine. [18:05] <soroosh> so, if I was starting from a clean build, this should be fine? [18:05] <sage> yes. [18:06] <-- dmharvey has left this server (Read error: 110 (Connection timed out)). [18:06] <soroosh> ok, so maybe we can just ignore it. :) [18:06] <sage> perhaps. [18:06] <malb> I'm out [18:06] <sage> Doing "sage -ba" might fixing it... [18:07] <sage> see you later malb. [18:07] <sage> thanks. [18:07] <burcin> thanks malb, now I'm lost with my leaks :) [18:07] <robertwb> malb: I added a function to get the refcount of and object [18:07] <malb> cool, any results yet? [18:08] <robertwb> no, but it might help with the issue you've been looking at above [18:08] <robertwb> the module function seems to be an exiting issue [18:08] <soroosh> ok, I'm doing that now. It is going to take a while though... [18:09] <robertwb> I'm making a ticket for the patch [18:09] <mabshoff> cu malb, [18:12] <sage> mhansen -- your patch for #606 is bogus. [18:12] <robertwb> ticket #611 [18:12] <robertwb> is the refcount patch [18:13] <mhansen> sage: What arch does it fail on? [18:13] <mabshoff> Hey wstein - wanna participate in a LinBox devel conference call? [18:13] <wstein> mabshoff -- sure. [18:14] <mabshoff> You should have gotten the LinBox-devel email, too. [18:14] <wstein> #606 --mhansen -- loading/attaching spyx files in the notebook is not so trivial as a one line patch. [18:14] <mabshoff> saunders likes the idea of switching LinBox's buildsystem to SCons :) [18:14] <mabshoff> weeeee [18:16] <dmharvey_> #424: patch attached. Also addresses #605 I hope. See comments on ticket #424. Only tested on OSX so far, I'm still trying to fix my sage.math build. [18:18] *** dmharvey_ is now known as dmharvey. [18:18] *** dmharvey is now known as dmharvey_. [18:18] *** dmharvey_ is now known as dmharvey. [18:21] <mabshoff> re 608: nothing jumps out, but there are a couple "invalid read of size 4" reports from within the coercion model. [18:21] <mabshoff> I have seen those before, but they never cause a crash as far I can tell. [18:21] <mabshoff> Does " *** not an integer argument in an arithmetic function" come from within Sage or is that pari already? [18:26] <mabshoff> strings on libpari didn't turn up anything at all, so it must be in Sage's code? [18:27] <sage> I just posted #611 -- [18:27] <mabshoff> Can anybody decode " [18:27] <mabshoff> find_module (fullname=0x7fffa6400e60 "c", subname=0xac6d140 "", path=<value optimized out>, [18:27] <mabshoff> buf=0x7fffa63ffde1 ".pyc", buflen=4097, p_fp=0x7fffa6400da0, p_loader=0xacce908) at Python/import.c:1427 [18:27] <mabshoff> " [18:27] <mabshoff> You mean you merge it? [18:27] <sage> yes. [18:28] <mabshoff> Cool, one more tool in our arsenal :) [18:28] <mabshoff> I will be off for 30 minutes, getting some air. [18:28] <mabshoff> You guys in Seattle have to leave soon? Going camping tomorrow or something? [18:29] <sage> i can fix #608 [18:29] <mabshoff> :) [18:29] <sage> i caused #608 --- the mobius function was *insanely* slow before, and I needed it to [18:29] <sage> be fast for the course I was teaching on the Riemann Hypothesis. [18:29] <sage> But I didn't correctly deal with the non-integer case. [18:29] <dmharvey> #518: new patch attached (monsky-washnitzer indentation) [18:29] <mabshoff> Well, that is different. If you broke it you usually know where to look . [18:29] <sage> I didn't realize it even made sense then. [18:30] <mabshoff> ok, cu in about 30 [18:30] *** mabshoff is now known as mabshoff|away. [18:30] <sage> cu [18:30] <dmharvey> wstein: please get #518 in soon if possible, I don't want to have to indent that file a third time :-) [18:34] <craigcitro> so apparently i don't understand something ... [18:34] <craigcitro> if i have class Foo [18:34] <craigcitro> and someone does Foo(3) [18:34] <craigcitro> that calls Foo.call, right? [18:34] <craigcitro> so if Foo.call?? shows "print 'hi'" as the first line [18:35] <craigcitro> Foo(3) should print "hi" ? [18:35] <sage> ok, #608 is fixed. [18:35] <dmharvey> craig: I would think so [18:35] <craigcitro> k [18:36] <dmharvey> no hang on [18:36] <dmharvey> craig: if X is an *instance* of a Foo [18:36] <dmharvey> Foo(3) calls init [18:36] <craigcitro> ohh [18:36] <craigcitro> right, k [18:36] <craigcitro> thank you. ;) [18:37] <soroosh> well, finished with "sage -ba", but still has the same error. [18:37] <soroosh> It also got an error regarding (1/2)(2100) [18:38] <soroosh> For some odd reason my sage is returning 1. [18:38] <soroosh> this is true for command prompt as well. [18:38] <sage> soroosh -- that's because I just added a doctest to expose a bug. [18:38] <soroosh> right... [18:38] <sage> it has been that way for years due to an overflow. [18:38] <soroosh> thats #602. [18:38] <sage> if you did hg_sage.pull() it fixes it. [18:38] <sage> however, you might have to wait a while to rebuild if you do that... [18:39] <sage> note, of course, that (1/2)(2100) would not fit in your memory -- it's supposed to give an error. [18:39] <dmharvey> ok this makes no sense. I unpacked a fully built copy of sage 2.8.3 that works perfectly well. Then I upgrade using sage -upgrade. And I get all those crazy import errors now whenever I try to run it. [18:39] <sage> is there anything i need to apply anybody? [18:39] <dmharvey> i'm going to have to keep working with only sage-2.8.3 for the moment, since I can't get 2.8.3.6 working. [18:39] <dmharvey> wstein: yes, try #518 now [18:40] <sage> dmharvey. where? [18:40] <dmharvey> on the ticket [18:40] <sage> And does "all those crazy import errors" mean exactly that one error involving libcsage.so? [18:40] <dmharvey> yes [18:40] <sage> on what system? [18:40] <sage> sage.math? [18:40] <dmharvey> sage.math [18:40] <sage> your laptop? [18:40] <dmharvey> no, my laptop is fine, as is my desktop [18:40] <sage> let me check your environment. [18:41] <sage> which directory is your build in? [18:41] <dmharvey> ~/sage-2.8.3 [18:41] <sage> I'll fix it again. [18:41] <dmharvey> but why does it keep doing this? I don't understand what's going on. [18:42] <dmharvey> is there still something wrong in my environment? [18:43] <sage> Ok, fixed. [18:43] <sage> no. [18:43] <sage> I think there was when you first built. [18:43] <sage> Doing "sage -ba", etc., doesn't redo the scons stuff. [18:43] <sage> All I did was: (1) . local/bin/sage-env [18:43] <dmharvey> Here's what I just did: [18:43] <sage> (2) 515 scons -c ../../../local/lib/ 516 scons install ../../../local/lib/ [18:43] <sage> I just did a clean scons in c_lib, and all was immediately fixed. [18:43] <dmharvey> I don't understand what all that means [18:44] <sage> That isn't in sage -ba, but I'll add it right now. [18:44] <sage> OK -- (1) cd SAGE_ROOT [18:44] <sage> (2) . local/bin/sage-env # setup the sage environment [18:44] <sage> (3) cd devel/sage/ [18:44] <sage> (4) cd c_lib [18:44] <sage> (5) scons -c $SAGE_LOCAL/lib/ # delete target [18:44] <sage> (6) scons install $SAGE_LOCAL/lib/ # rebuild all c_lib stuff and install it in target. [18:45] <dmharvey> but why do I get this problem whenever I do sage -upgrade? Does anyone else get this problem? [18:45] <sage> Nobody else got that. [18:45] <dmharvey> maybe my old sage-2.8.3 build was screwed [18:45] <sage> I'm sure it has to do with your LD_LIBRARY_PATH grabbing the wrong gmp. [18:45] <sage> or something else like that. [18:45] <dmharvey> probably my LD_LIBRARY_PATH was wrong for my *old* build [18:45] <dmharvey> which I just upgraded [18:45] <dmharvey> anyway, [18:46] <sage> That said, I think "sage -ba" should be changed so it would fix your problem, hence "sage -upgrade" [18:46] <dmharvey> I'm going to ignore this now, since I'll build from scratch again in a day or two once all the patches are in [18:46] <sage> would fix your problem. I'll make that chagne right now. [18:46] <dmharvey> I just want to test the gcd thing now [18:46] <dmharvey> thanks for your help [18:46] <sage> I can't wait! [18:46] <sage> I can help as soon as I fix "sage -ba". [18:50] <dmharvey> it's building now.... seems to be okay so far..... [18:51] <burcin> what does _pari_ do exactly? [18:51] <craigcitro> returns the pari version of your object [18:52] <burcin> is there a specific implementation for matricies? dense integer matricies.. [18:52] <burcin> where is it defined? [18:52] <dmharvey> #424: BINGO. Check this out: [18:53] <dmharvey> Magma V2.13-5 Thu Sep 6 2007 18:49:13 on sage [Seed = 2094699641] [18:53] <dmharvey> > a := Random(210000000); b := Random(210000000); [18:53] <dmharvey> > time t := XGCD(a, b); [18:53] <dmharvey> Time: 16.550 [18:53] <dmharvey> sage: a = ZZ.random_element(210000000); b = ZZ.random_element(210000000); [18:53] <dmharvey> sage: time t = XGCD(a, b) [18:53] <dmharvey> CPU times: user 16.03 s, sys: 0.39 s, total: 16.42 s [18:53] <dmharvey> Wall time: 16.41 [18:53] <dmharvey> sage: t[0] == t[1]*a + t[2]*b [18:53] <dmharvey> True [18:53] <craigcitro> burcin: it's defined in each class. do M._pari_?? to see, if your obj is M [18:54] <dmharvey> wstein: how do I log into the vmware thing on bsd? [18:54] <burcin> craigcitro: I didn't know about the ?? trick.. that's very useful [18:54] <burcin> craigcitro: thanks a lot :) [18:54] <craigcitro> ? and ?? are both good [18:54] <dmharvey> wstein: actually.... maybe I'm done for tonight. I've got patches for #424, #518, and probably #605 read to go. [18:54] <craigcitro> no sweat [18:57] <dmharvey> bye guys, I'm spent [18:57] <-- dmharvey has left this channel. [19:00] <burcin> I'm also leaving.. [19:00] <burcin> At the moment, A = random_matrix(ZZ, 100, 120); leaks.. [19:00] <burcin> A._pari_() also does.. and that's why echelonize (or echelon_form) is leaking.. [19:00] <sage> burcin -- just creating it. [19:01] <sage> anyidea why? [19:01] <burcin> I have no experience about what the function pari does.. [19:02] <burcin> I got to look at the linear algebra code a lot today though.. [19:02] <burcin> do you still need a fast hermite normal form implementation? or is pari good enough? [19:02] <burcin> I was thinking of doing that as homework for a symbolic linear algebra course.. [19:03] <burcin> i.e., bug #174 [19:03] <sage> burcin -- i'm not sure. i think a certain student in canada is actually working on that. [19:04] <sage> also, i think linbox is going to get one soon. [19:04] <sage> But honestly I've been waiting a very long time for one and don't have anything yet. [19:04] <sage> if you want to try, that would be good. [19:05] <burcin> I didn't think of it so seriously.. I'll see what I can do.. [19:06] <burcin> I'm a bad student, just trying to get around solving exercises for homework.. [19:06] <burcin> anyway.. I'll try to get back to the leaks tomorrow.. [19:06] <burcin> bye for now.. [19:07] <craigcitro> see ya burcin [19:07] <mhansen> sage: I put a real patch for #606 ;) [19:12] <-- burcin has left this server ("Leaving"). [19:16] <sage> mhanse -- i'm looking at #606 now. [19:20] <sage> I just tried David's xgcd in sage on the same machine, but without his patch: [19:20] <sage> CPU times: user 954.37 s, sys: 0.08 s, total: 954.46 s [19:21] <sage> It's very very curious that magma is the same speed as GPL-only patched GMP. I wonder if [19:21] <sage> they are violating the GPL... [19:22] <craigcitro> that's some crazy good code that GMP has [19:22] <craigcitro> it would be pretty interesting if magma was violating the gpl ... [19:22] <craigcitro> so i just fixed ticket #376 [19:23] <craigcitro> it took me an inordinate amount of time to figure out *what* to fix ... i suppose this is always the case. [19:26] <mabshoff|away> Magma has allegedly written some arbitrary precision code on their own. [19:26] <mabshoff|away> And then they put out some special benchmarks claiming superiority over the gmp. [19:26] <mabshoff|away> That went over really well on the gmp mailing list as you can imagine,. [19:28] *** mabshoff|away is now known as mabshoff. [19:28] <craigcitro> sage -- you around? [19:28] <craigcitro> or soroosh -- you here? [19:29] <wstein> I'm around. [19:29] <craigcitro> hey [19:29] <craigcitro> can you try out the patch for 376 when you get a chance? i'm pretty sure it's solid. [19:29] <wstein> mabshoff -- maybe the gmp people are aiming to beat magma's timings, which would explain [19:29] <craigcitro> i even added doctests! ;) [19:29] <wstein> why they are so close. [19:30] <wstein> i'm working on mhansen's patch for loading spyx files in the notebook. [19:30] <wstein> it sort of worked but was too broad and didn't work when the file contained an error message. [19:30] <craigcitro> ah, ok [19:30] <craigcitro> well, put it in your queue of patches to check out. ;) [19:31] <sage> it'll only be a minute.. [19:31] <soroosh> Hey Craig, I'm around. [19:31] <soroosh> I can try doing it. [19:31] <soroosh> Is the patch on the trac? [19:32] <craigcitro> yep [19:32] <craigcitro> just try out some various finite field homomorphisms [19:32] <craigcitro> let me know if they fail or succeed [19:32] <craigcitro> (or, if they do correctly, that is) [19:32] <mabshoff> Okay, caught uo. [19:32] <mabshoff> up [19:32] <soroosh> ok, first let me see if I can apply the patch. [19:33] <craigcitro> grin ... if you can't, i might cry. [19:33] <craigcitro> because i think i've finally stopped making broken patches. [19:33] <mabshoff> wstein: At least some of the INRIA people release their code that is GPLed for gmp 5 at the moment also under a BSD license [19:33] <wstein> interesting. [19:33] <mabshoff> So it might be the same code in Magma, but I seriously doubt that they violate the GPL. [19:34] <mabshoff> They are pretty adament in listing the LGPLed bits they use like ATLAS and gmp. [19:35] <wstein> they build magma statically, so you can't drop in your own gmp, which is annoying. [19:36] <mabshoff> Well, I can understand that. [19:36] <sage> maple and mathematica don't do that. [19:36] <craigcitro> ooh ... i just found a bug that my fix exposed: the homomorphisms can be defined just fine, and their definition looks good ... but they don't work. [19:36] <sage> and the lgpl requires one to make available a version that doesn't do that. [19:36] <mabshoff> Back during 4.1.4 the default alloc was alloca. So you could pretty much smash the stack at will with anything that linked dynamically. [19:36] <sage> mhansen -- #606 is closed. [19:37] <mhansen> Thanks for cleaning up my stuff. [19:37] <sage> welcome. [19:37] <sage> Thanks for finally writing that -- it's absense was a problem for a long long time. [19:37] <sage> #376 -- i'm checking it out right now. [19:37] <mabshoff> They habe to make changes available to people who request it, and depending on one's interpretation that might only inlucde customers. [19:39] <wstein> They don't say they will make the modified version of GMP available anywhere. [19:39] <wstein> They only say they will make a version of magma that can link against GMP so [19:40] <wstein> This is the code specifically under discussion " This is Niels Möller's sub-quadratic GCD code, implementing both plain gcd and extended gcd. It is believed to be quite stable at this point." [19:40] <wstein> as listed on http://gmplib.org/devel/ [19:40] <mabshoff> Is the gmp an official gnu project, i.e. with copyright assignment to the FSF? [19:40] <sage> i think so.. [19:40] <mabshoff> I don't think so, but in that case I think Granlund would have done something about that by now if he intended to do so. [19:41] <sage> maybe not. [19:41] <sage> looking at random code it does have FSF copyrights... [19:41] <mabshoff> I think people like Zimmermann and Granlund were very possed. [19:41] <mabshoff> ok [19:41] <mabshoff> maybe it is time to write RMS an email :) [19:42] <craigcitro> hey william -- here's another question [19:42] <craigcitro> a lot of this morphism code has functions named with underscores before and after the name [19:42] <craigcitro> _internal_func_ instead of _internal_func [19:42] <craigcitro> is this just an old habit? or is it someone else's code? [19:43] <sage> This is for functions that are supposed to be viewed like Python * functions... [19:43] <sage> E.g., _add_ [19:44] <craigcitro> ahh, ok [19:44] <soroosh> Craig: I applied your patch. It is a bit late for me to think properly, but running the example on the ticket, what should I get back? [19:44] <soroosh> I get "Not valid homomorphism" exception. [19:44] <craigcitro> ok, so that's bad [19:44] <craigcitro> you should get back two valid homomorphisms [19:45] <soroosh> hmm, maybe I haven't quite applied that patches yet. [19:45] <sage> I'm trying too. [19:45] <mabshoff> Did burcin open another ticket for the leak in echelonize? It seems like a pretty good isolated leak to look at. [19:45] <sage> it works! [19:45] <sage> I don't know. [19:45] <mabshoff> Ok, will check [19:45] <soroosh> I ran, hg_sage.apply, heads, merge, and then commit [19:46] <craigcitro> yeah, but you can't yet *apply* morphisms [19:46] <craigcitro> does hg heads tell you that you only have one head? [19:46] <sage> I added that one as a doctest. [19:46] <sage> to apply morphisms you have to implement a function on elements. See number_field_element.pyx for [19:46] <sage> an example. [19:47] <craigcitro> k ... i'm working on doing that right now. [19:47] <craigcitro> ah, i can probably just copy-paste that code. :P [19:47] <soroosh> Oh, it works now. [19:48] <soroosh> I forgot to rebuild it. :P [19:48] <craigcitro> awesome [19:48] <craigcitro> hahah [19:48] <craigcitro> that'll get you every time. ;) [19:48] <soroosh> :) [19:48] <sage> i've closed this ticket and pushed out the patch. [19:48] <mabshoff> wstein: could you apply the patch by malb for #566 [19:49] <sage> 25 tickets closed today so far. [19:49] <mabshoff> That one also fixes most of #519, i.e. we leak only one rand_state in total. [19:49] <sage> #566 -- looking into it now. [19:49] <mabshoff> Yep, pretty good night so fat. [19:49] <mabshoff> far [19:49] <soroosh> Wow! That's impressive. [19:50] <mabshoff> The last bug Day + the next day closed a totol of 70 tickets. [19:50] <mabshoff> But there were many worksforme [19:50] <mabshoff> but today has been very impressive, because many of the bugs were harder. [19:50] <mabshoff> (in my humble opinion= [19:50] <mabshoff> ) [19:59] --> boothby has joined this channel (n=[email protected]). [19:59] <sage> and those are just closed tickets. that doesn't count, e.g., #566 [19:59] <sage> I couldn't apply the patch since it depends on another. [19:59] <sage> but I'll track that down. [19:59] <sage> #558 [20:00] <mabshoff> So there is also a patch fir #558? malb was very busy. [20:00] <sage> yep! [20:01] <mabshoff> Just answered Saunder's linbox-devel email. Mentioned the problem with Solaris vs. that SunOS_5_9 broken fix. [20:05] <mabshoff> Wow, #33 closed, that is a rather old one. [20:06] <mhansen> sage: Do you want some more patches at the moment? [20:08] <sage> i've applied and pushed 558 and 560. [20:08] <mabshoff> #566? [20:08] <sage> yes. that's what I'm doing now is applying patche.s [20:09] <mhansen> There's one for 544. [20:10] <sage> but I'm also cooking spaghetti right now :-) [20:10] <mhansen> Mmm... [20:10] <mhansen> I made a curry that was way spicier than I intended. [20:10] <mabshoff> I am getting near the end. [20:10] <sage> mhansen -- thanks for fixing #544!!!! [20:10] <sage> that was driving me crazy forever. [20:10] <sage> mabshoff -- of all sage bugs :-) [20:11] <mabshoff> ? [20:11] <mabshoff> Oh, I think I got it now. [20:11] <mabshoff> My brain is getting tired. [20:11] <mabshoff> I think I will do some more work on M2. [20:11] <mabshoff> Just to get something compiling out the door. [20:12] <mabshoff> Dan is subscribed to sage-devel by the way. [20:12] <mhansen> There's also ones for 553, but I feel kind of iffy about the solution. I couldn't think of anything better to do though. [20:12] <mabshoff> Good that I never wrote anything bad about M2 :) [20:13] <boothby> dammit, timothy's never around when you need him. [20:13] <mhansen> There is also one for #334. [20:13] <craigcitro> hey sage ... i have another patch that makes it so you can apply finite field morphisms [20:13] <craigcitro> should i make a ticket just to post it? [20:13] <craigcitro> or tag it on 376? [20:14] <sage> mabshoff -- did I accidently close #560 thinkingit was #566?!?! [20:14] <sage> pasta calls... [20:14] <mabshoff> ok [20:15] <mabshoff> I reopened #560 [20:17] <craigcitro> so i think 539 is a dead ticket [20:17] <craigcitro> i'm pretty sure i fixed that when i fixed up the c_lib install stuff [20:17] <mabshoff> sage: there is a patch attached to #604 that fixes a memleak. [20:17] <craigcitro> can someone check that for me? [20:17] <craigcitro> x = 3 [20:18] <craigcitro> x.int?? [20:18] <craigcitro> make sure you see pyintlong ;) [20:18] <mabshoff> Yeah, that problem sounds familiar. [20:18] <craigcitro> it was causing a weird issue -- actually, i think on kiran's machine [20:18] <craigcitro> man, we need to get an account and do tests on kiran's machine [20:18] <craigcitro> oh, no, that's not right [20:18] <craigcitro> it was the one on 64 bit linux [20:19] <craigcitro> because there was code duplication with c_lib and sage/ext/ [20:19] <mabshoff> That issue got solved with the LONG_BIT problem or whatever. [20:19] <mabshoff> Or which issue are you talking about? [20:19] <mabshoff> I am currently rebuilding, will take a little while. [20:20] <mabshoff> With malb's gmp.pxi changes a lot of code has to be recompiled. [20:20] <craigcitro> nah, it was something else [20:20] <craigcitro> grin nods [20:20] <mabshoff> ticket? [20:20] <craigcitro> 539 [20:20] <mabshoff> But that code duplication was fixed after 2.8.3.x? [20:21] <mabshoff> Okay, never mind. [20:21] <craigcitro> yeah, i got rid of it a while back [20:21] <mabshoff> Read the ticket in details. [20:21] <craigcitro> i forget what version ... too many versions. ;) [20:21] <mabshoff> well, let was decide. [20:21] <mabshoff> it is just one blurry continuum for me. [20:21] <sage> craig -- #539 isn't dead. it's still commented out. [20:22] <craigcitro> hmm ... it's not on my machine. [20:22] <sage> look at int integer [20:23] <craigcitro> yeah, this is apparently a fix i never pushed back your way. [20:23] <craigcitro> but that made it into my sage-main ... *shrugs* [20:23] <craigcitro> what should i do with this other finite field patch? add it to 376? [20:23] <sage> no -- unless you *open* 376. [20:23] <craigcitro> make a new ticket then? [20:24] <sage> regarding #539 -- i just fixed that, so good. [20:24] <sage> yes, a new ticket. [20:24] <craigcitro> k, good times. [20:26] <sage> i'm now building the latest hg_sage.pull() on 3 machines and doing a full doctest. [20:26] <sage> dinner... [20:26] <mabshoff> ok [20:26] <craigcitro> k, 612 made and ready to be closed. ;) [20:26] <sage> back in 20 or 30 minutes. [20:26] <sage> ... [20:26] <craigcitro> cool [20:26] <mabshoff> I did a build about 10 minutes ago and running doctest before I revisit the valgrind issues. [20:26] <sage> ok. [20:30] <soroosh> I am looking at #252, regarding creating number fiels when polynomial not integral, and I was wondering, is there a danger of modifying polynomial in init function, or should I be a bit more careful? [20:30] <soroosh> I have a small patch that modifies the polynomial to be monic. [20:31] <craigcitro> william is the person to ask about this -- he's just spent the last two days combing the number fields code [20:33] <soroosh> ok, then I should wait a bit. [20:33] <soroosh> How does one make a patch, btw? [20:33] <craigcitro> so the right way is within sage : [20:33] <craigcitro> hg_sage.send('new_bundle.hg') [20:34] <craigcitro> that will look at the main sage repo, pack up everything it needs, and ask you to edit a description [20:34] <craigcitro> some monkeys like me tend to do it with hg from the command line, and annoy william to death with our hg bundles that can't be applied. ;) [20:35] <craigcitro> but hg_sage.send?? tells all: [20:35] <soroosh> cool. [20:35] <soroosh> thanks [20:35] <craigcitro> hg bundle name.hg http://www.sagemath.org/hg/sage-main/ [20:35] <craigcitro> that works from the command line, and does the same thing [20:38] <craigcitro> hey, so ticket 461 also seems to be fixed. [20:38] <craigcitro> can you guys look at that and tell me if it works for you? [20:38] <craigcitro> M = ModularForms(17,4) ; N = M.new_subspace() [20:38] <craigcitro> that's what you need to run ... working means not throwing an error in this case. ;) [20:40] <mhansen> No error for me. [20:40] <craigcitro> k [20:40] <craigcitro> william has also finished 585 [20:41] <craigcitro> 585 612 461 all ready to go [20:41] <sage> hi [20:41] <soroosh> craig: it works for me too. [20:41] <sage> now suffering from memory leak fixes.. [20:41] <sage> sage -t devel/sage-main/sage/coding/linear_code.py *** glibc detected *** /home2/sage/s/local/bin/python: double free or corruption (out): 0x00000000017d7c50 *** [20:41] <craigcitro> grin [20:42] <soroosh> :) [20:42] <craigcitro> yeah, when you have time william -- 585 612 461 ready to go, soroosh has a number field question [20:42] <soroosh> oh yeah, I was looking at #252, regarding non-monic polynomials, [20:42] <sage> craigeciro -- i already did 585 a day or 2 ago... [20:42] <sage> oops. [20:42] <sage> it should be in hg_sage.pull() [20:43] <craigcitro> oh, well, the ticket is ready to be closed. ;) [20:43] <craigcitro> yeah, that was the one you did the other day while we were talking -- but the ticket was open [20:43] <soroosh> and I was wondering if I should add another variable in the class, defining_polynomial, [20:43] <craigcitro> how was the pasta? [20:43] <sage> we even chose the same examples, but I got rid of the numerical parts. [20:43] <sage> i also put a warning about denominators. [20:43] <soroosh> and have polynomial be a monic, integral polynomial all the time. [20:43] <sage> pasta was good. [20:44] <sage> soroosh -- we're going to do a major rewrite of number fields... [20:44] <sage> that's one of the plans. [20:44] <sage> but it should be transparent to the user. [20:45] <soroosh> oh, so I shouldn't worry too much about this fix. [20:47] <soroosh> ok, it's getting late in here. [20:48] <soroosh> I think I'm going to go to sleep. [20:48] <soroosh> Cheers guys. [20:48] <-- soroosh has left this channel. [20:49] <sage> goodnight soroosh. [20:49] <sage> the crash above was caused by the integer freeing memleak "fix". [20:50] <craigcitro> grin [20:54] <-- robertwb has left this server. [20:54] <sage> #461? [20:55] <mhansen> Craig nor I were able to reproduce 461. [21:00] <sage> maybe I just fixed it. [21:01] <sage> i fixed some things just like this recently when adding doctests. [21:01] <sage> cool -- taht can be closed. [21:01] <mhansen> Surprise bug fixes are always fun. [21:03] <sage> ok. is anything else left for me to close... [21:03] <sage> ? [21:03] <mhansen> Could you look at 553 and 334? [21:03] <sage> #503 -- robertwb just finished that with tom b. [21:04] <sage> i'm going to check out #503. [21:04] <sage> it would be great if somebody else could too. [21:04] <sage> hey, i already applied that. [21:04] <sage> never mind. [21:05] <craigcitro> grin [21:05] <sage> ok, on to #553. [21:05] <craigcitro> so 461 also worked for you? [21:05] <mhansen> #553: The solution in that patch was the most reasonable thing I could come up with. [21:05] <sage> mhansen -- what if a variable name happens to be "substitute" ? :-) [21:06] <sage> yes #461 works. [21:06] --> mabshoff_ has joined this channel (n=[email protected]). [21:07] <mhansen> sage: Then they have more problems than I know what to do with ;-] [21:07] <sage> no seriously. [21:08] <mhansen> I guess you could also add a check that subtitute==True [21:08] <sage> yes, that's reasonable. [21:08] <sage> i'll add that. [21:08] <mhansen> Thanks [21:10] <mhansen> It's still possible to get the unexpected behavior, but this takes out a few of the cases where it could happen. [21:10] <-- boothby has left this server (Read error: 110 (Connection timed out)). [21:10] <sage> this segfaults: sage -t devel/sage-main/sage/modular/abvar/torsion_subgroup.py [21:10] <sage> ouch. [21:11] <sage> i've pushed the change out. [21:11] <sage> and closed the ticket #553. [21:11] <sage> now looking at #334 [21:12] <sage> with the current bugfixes (do hg_sage.pull()) the following doctests all fail: [21:12] <sage> sage -t devel/sage-main/sage/modular/modsym/space.py [21:12] <sage> sage -t devel/sage-main/sage/modular/modsym/subspace.py [21:12] <sage> sage -t devel/sage-main/sage/modular/abvar/abvar.py [21:12] <sage> sage -t devel/sage-main/sage/modular/abvar/cuspidal_subgroup.py [21:12] <sage> sage -t devel/sage-main/sage/modular/hecke/submodule.py [21:12] <sage> sage -t devel/sage-main/sage/modular/hecke/module.py [21:12] <sage> sage -t devel/sage-main/sage/modular/hecke/ambient_module.py [21:12] <sage> sage -t devel/sage-main/sage/modular/modform/cuspidal_submodule.py [21:12] <sage> sage -t devel/sage-main/sage/structure/element.pyx [21:12] <sage> sage -t devel/sage-main/sage/combinat/sloane_functions.py [21:12] <sage> ouch. [21:12] <craigcitro> whoa [21:12] <sage> #334 -- looks good. [21:12] <mhansen> Yikes -- hopefully it's all for the same underlying reason. [21:12] <craigcitro> i'll start looking at the modform stuff [21:12] <sage> some will be because of 0^0. [21:13] <sage> Others will be because of memleak cleanups, I bet. [21:13] <sage> I'm going to see what I can do about them now. [21:13] <sage> help would be appreciated. [21:13] <sage> ? [21:13] <craigcitro> well, i'm familiar with the modular/modform code right now [21:13] <craigcitro> so i'll get on those. [21:13] <sage> if you do hg_sage.pull() [21:13] <sage> then doctest something about, see what happens. [21:13] <craigcitro> nod [21:14] <mhansen> Will do. [21:14] <sage> is anybody else working on anything? [21:15] <mhansen> #387 can be closed [21:15] <sage> sure? [21:15] <sage> it could be a 64 or 32-bit only problem. [21:16] <mhansen> Hmm... both mabshoff and I tested it out a few days ago, and I did today as well. [21:16] <sage> it works on my 64-bit laptop. [21:16] <sage> it works on my 32-bit os x box. [21:16] <sage> ok, closing it. [21:17] <sage> #607 -- looks fixed. [21:17] <sage> I'll apply that. [21:18] <mhansen> sloane_functions is just 0^0, I'll do a ticket and patch for that. [21:18] <sage> mhansen go. [21:18] <sage> go go. [21:18] <sage> thanks. [21:18] --> robertwb has joined this channel (n=[email protected]). [21:18] <-- mabshoff has left this server (Read error: 110 (Connection timed out)). [21:22] <sage> robertwb -- we're trying to fix all the errors caused by the 0^0 patch and other bug fixes. [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/modsym/space.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/modsym/subspace.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/abvar/abvar.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/abvar/cuspidal_subgroup.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/hecke/submodule.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/hecke/module.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/hecke/ambient_module.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/modular/modform/cuspidal_submodule.py [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/structure/element.pyx [21:22] <sage> after applying your hyperelliptic_padic_field patch, it also crashes on exit. [21:22] <robertwb> ok [21:22] <sage> 21:15 < sage> sage -t devel/sage-main/sage/combinat/sloane_functions.py [21:22] <sage> these fail [21:23] <mhansen> patch attached for #613 [21:23] <robertwb> pull to get the latest? [21:23] <sage> this is a bad interaction -- it's becaue you actually have examples.. [21:23] <sage> yes hg_sage.pull() [21:23] <sage> mhansen -- thanks. [21:23] <sage> craigcitro, me, mhansen, and you are working on this. [21:24] <sage> all other doctests pass except those listed above. [21:24] <mhansen> I'll do element.pyx. [21:25] <robertwb> I'll look at modsym/* [21:25] <sage> I'm going to apply a few more very easy patches. [21:25] <sage> i.e., the indentation fix of monsky_washnitzer. [21:25] <sage> i'll apply your #613 first. [21:26] <craigcitro> is the system-wide sage on sage.math up to date? [21:26] <sage> ok, #613 is good. [21:26] <craigcitro> i was trying doctests there while i wait for my sage -br [21:26] <sage> craigcitro -- no. [21:26] <craigcitro> k [21:29] --> boothby has joined this channel (n=[email protected]). [21:29] <sage> #570 -- robertwb -- I'm applying your patch for that now. [21:29] <robertwb> ok [21:29] <sage> I guess I already got it with the 0^0 stuff. [21:30] <robertwb> that makes sense [21:30] <mhansen> sage: #614 (element.pyx) patch is up. [21:30] <sage> thanks! [21:31] <sage> applying it... [21:31] <craigcitro> geez ... i'm still waiting on my sage -br. do you guys just have faster systems? ;) [21:32] <sage> we've been doing it all along. [21:32] <sage> you maybe hadn't pulled in a while [21:32] <mhansen> I'm running the tests on the modular stuff. [21:33] <sage> robertwb -- did you fix #573 [21:33] <robertwb> let's see [21:33] <robertwb> yes [21:34] <sage> looks good. i'll close it now. [21:34] --> pdehaye has joined this channel (n=[email protected]). [21:37] <robertwb> having trouble getting an error for /sage/modular/modsym/space.py [21:37] <mhansen> I segfault on space.py [21:37] <-- pdehaye has left this server (Client Quit). [21:38] <sage> robertwb -- it doesn't segfault on osx intel. [21:38] <sage> weird. [21:38] <robertwb> ok [21:38] <robertwb> someone else better take those ones then [21:38] <sage> these all fail on osx in intel: [21:38] <sage> sage -t devel/sage-main/sage/modular/abvar/torsion_subgroup.py [21:38] <sage> sage -t devel/sage-main/sage/modular/hecke/ambient_module.py [21:38] <sage> sage -t devel/sage-main/sage/modular/hecke/hecke_operator.py [21:38] <sage> sage -t devel/sage-main/sage/modular/modsym/space.py [21:39] <craigcitro> oh, we're down to just those four? [21:39] <craigcitro> or just on a diff arch? [21:39] <sage> no -- on just x86 os x it's those four. [21:39] <mhansen> I'm looking at modsym/subspace.py and failures are not being consistently reproducible. [21:40] <sage> it must be a memory leak cleanup causes hell issue then. [21:40] <sage> dang. [21:42] <mhansen> For example, on space.py, sometimes I get the sage segfault message, and sometimes I get this: [21:42] <mhansen> fatal error: [21:42] <mhansen> Internal error: can't free this _ntl_gbigint [21:42] <mhansen> exit... [21:43] <robertwb> ok, I was able to get a segfault on modsym/space.py once, though nothing by piping it into sage -gdb [21:44] <mhansen> I got subspace.py to pass on one of the attempts ;) [21:45] <sage> hi. [21:45] <sage> I've applied every patch for sage-2.8.4 and moved all tickets not for sage-2.8.4 to sage-2.9. [21:45] <sage> If you look at http://trac.sagemath.org/sage_trac/milestone/sage-2.8.4 [21:45] <sage> you'll see that everything (all 60 tickets) are closed, except 1, which is David Harvey's [21:46] <sage> GMP patches, which vastly speed up big rational number arithmetic. [21:46] <sage> If you do hg_sage.pull() you'll get this version. [21:46] <sage> It has the fixes of mhansen from a few minutes ago too. [21:46] <sage> It'll take a few minutes to compile though. [21:46] <sage> Then to release sage-2.8.4, all that we need to do is fix the above doctest failures. [21:46] <sage> what is _ntl_gbigint? [21:48] <mhansen> No idea -- I've never looked at the NTL code before. [21:48] <craigcitro> where does it say it's appearing? or does it? [21:49] <mhansen> That was an error I had on one of the crashes of modsym/space.py [21:49] <sage> ah. [21:49] <craigcitro> k [21:49] <sage> the error happens on exit/cleanup for me. [21:50] <craigcitro> the only references to "bigint" i could find in the sage source tree are all in mwrank [21:51] <craigcitro> does that get called at all in your modular symbols doctests? weight two spaces? [21:52] <sage> gmp gives this on crash: [21:52] <sage> Program received signal SIGSEGV, Segmentation fault. [21:52] <sage> [Switching to Thread 47729433847536 (LWP 12470)] [21:52] <sage> 0x00002b68e0b88070 in gmpn_submul_1 () from /home/was/s/local/lib/libgmp.so.3 [21:52] <sage> (gdb) Hangup detected on fd 0 [21:52] <sage> no [21:52] <sage> mwrank is not used. [21:52] <craigcitro> k [21:53] <sage> i made a cutdown version of the input doctest, and get a serious hang. [21:53] <sage> let me see if it is reproducible. [21:53] <sage> it's a double free. [21:53] <robertwb> try commenting out the code that frees the integer pool (patch 7284d5caf725 is mis-labeled) [21:53] <sage> it's not reproducible. [21:53] <sage> i did -- that doesn't help. [21:54] <sage> this time I got this: [21:54] <sage> Program received signal SIGSEGV, Segmentation fault. [21:54] <sage> [Switching to Thread 47931549828848 (LWP 12567)] [21:54] <sage> visit_decref (op=0x1, data=0x0) at Modules/gcmodule.c:270 [21:54] <sage> 270 Modules/gcmodule.c: No such file or directory. [21:54] <robertwb> the pool, not just the mpz_globals? [21:54] <sage> yes, but I'll try again just in case. [21:55] <sage> no, that doesn't fix the problem. [21:55] <craigcitro> what machine had the larger set of failures? is it one we can log into? [21:56] <sage> sometime free_module.py fails. [21:56] <sage> sometimes not. [21:57] <mhansen> This is fun :) [21:57] <craigcitro> hey, so here's a good question: when sage -t with a sigsegv, is there an easy way to find out which doctest did it? [21:57] <sage> free_module.py crashes about 10% of the time. [21:57] <craigcitro> or a quick way to run it interactively or the like? [21:57] <sage> sage -t --verbose [21:57] <sage> sage -t --gdb [21:58] <sage> these are your friends. [21:58] <craigcitro> grin ... indeed [21:58] <robertwb> ooooh, I've been wanting sage -t --gdb for a long time [21:59] <sage> i suspect matrix_integer_dense.pyx is a problem. [21:59] <sage> I'll try reverting it to an old version. [22:00] <sage> that didn't help. [22:01] <sage> doing this a few times always leads to problems: [22:01] <sage> sage -t --verbose free_module.py [22:01] <sage> mhansen -- by the way your subst fix breaks piecewise.py [22:02] <sage> matrix_integer_dense.pyx hasn't changed recently. [22:03] <robertwb> no, the only change in the 6000's is a comment [22:03] <mhansen> I'll look at piecewise now. [22:03] <sage> maybe martin's gmp.pxi changes got us? [22:03] <sage> that move to libcsage.so [22:04] <robertwb> that'd be my guess... [22:05] <robertwb> too bad we're not using darcs [22:05] <sage> robertwb -- do you see any problems, by the way? [22:05] <sage> on osx? [22:05] <sage> robertwb -- i can record the inverse of a changeset, e.g., of 6207, to undo [22:05] <robertwb> yes, I got free_module.py to crash now [22:05] <sage> martin's thing. [22:05] <robertwb> nothing regular though [22:06] <sage> record ==> apply. [22:06] <craigcitro> i've got inconsistent crashes in modular/modsym/space.py on osx ppc [22:07] <sage> craigcitro -- subspacepy now fails. [22:07] <sage> what happend? [22:07] <sage> it's not a crash issue at all. [22:07] <sage> it's never mind -- it is a crash issue. [22:08] <craigcitro> so i've had space.py have one crash, then work fine for a while, and now a different crash elsewhere in the file [22:08] <mhansen> I have like 4 logs of different "flavors" of subspace.py crashes. [22:08] <sage> hg backup. [22:09] <craigcitro> sage: S = ModularSymbols(389,sign=1)[3]; S [22:09] <craigcitro> File "/sage/local/lib/python/site-packages/sage/modular/hecke/module.py", line 305, in getitem [22:09] <craigcitro> D = self.decomposition() [22:09] <craigcitro> File "/sage/local/lib/python/site-packages/sage/modular/hecke/module.py", line 560, in decomposition [22:09] <craigcitro> height_guess=height_guess, proof=proof) [22:09] <craigcitro> File "matrix2.pyx", line 1682, in matrix2.Matrix.decomposition_of_subspace [22:09] <craigcitro> File "matrix_rational_dense.pyx", line 1158, in matrix_rational_dense.Matrix_rational_dense.decomposition [22:09] <craigcitro> File "matrix_rational_dense.pyx", line 1250, in matrix_rational_dense.Matrix_rational_dense._decomposition_rational [22:09] <craigcitro> File "/sage/local/lib/python/site-packages/sage/rings/polynomial/polynomial_element_generic.py", line 1142, in floordiv [22:09] <craigcitro> return Polynomial.floordiv(self, right) [22:09] <craigcitro> File "polynomial_element.pyx", line 855, in polynomial_element.Polynomial.floordiv [22:09] <craigcitro> File "/sage/local/lib/python/site-packages/sage/rings/polynomial/polynomial_element_generic.py", line 1042, in quo_rem [22:09] <craigcitro> v = self.poly.quo_rem(right.poly) [22:09] <craigcitro> RuntimeError [22:09] <craigcitro> ********************************************************************** [22:09] <craigcitro> ooh, i feared that would boot me. sorry about the spam. [22:10] <mhansen> sage: for piecewise.py, do you want me to change the doctests to use substitute=True? [22:10] <sage> sure. [22:11] <robertwb> oh, I got something with gdb in free_module.py [22:11] <sage> i'm waiting for the backup of martin's patch to finish building. it takes a while. [22:11] <robertwb> (I think you've seen it before) [22:11] <robertwb> visit_decref (op=0x1, data=0x0) at Modules/gcmodule.c:270 [22:11] <sage> yep. [22:12] <sage> there's definitely a lesson here. [22:13] <sage> any time anything purports to address a memleak, it has to be fully tested in isolation on the [22:13] <sage> entire doctest suite. [22:13] <mhansen> That sounds like a good plan. [22:13] <craigcitro> yeah, seriously. [22:13] <robertwb> I concur [22:14] <craigcitro> so the thing i posted above, i just did with sage -gdb [22:14] <craigcitro> and it's actually throwing the error in an NTL function [22:14] <craigcitro> so assuming it's not really an NTL issue, does that mean we're calling into NTL with something we accidentally freed? [22:14] <sage> craig -- is it sporadic? [22:15] <sage> was it from subspace.py? [22:15] <sage> i backed out martin's patch and the problem vanishes with space.py!!!! [22:16] <mhansen> Excellent news! [22:16] <craigcitro> this is modsym/space.py, and yep, it's sporadic [22:16] <sage> that's probably the cause of the all the problems. [22:16] <sage> robertwb -- thoughts? [22:16] <mhansen> sage: patch for #615 up [22:16] <sage> what should I do. [22:17] <sage> thanks. [22:17] <sage> hmmm. [22:17] <sage> (1) just leave it backed out. [22:17] <sage> (2) try to fix the problem by understanding what he did. [22:17] <sage> hmmm. [22:18] <robertwb> so, how sure are you that you didn't have a lucky run? [22:18] <robertwb> If it is, I bet that's all our issues [22:18] <sage> space.py failed for me every single time. [22:18] <sage> now it passes every single time. [22:18] <sage> so 100% [22:18] <robertwb> excellent [22:18] <sage> i'll doctest modsym directory, to be surer. [22:19] <sage> all tests pass. [22:19] <robertwb> so, I'd say release without that patch, and ask him to take a closer look at it/work with him [22:20] <sage> except I applied 25 patches after it and hg has no extract patch from the past command. [22:20] <sage> so it's a little werid. [22:20] <sage> actually maybe just recording the inverse is fine. [22:21] <sage> but then how does he undo that. [22:21] <robertwb> Yeah, I'd just record the inverse. [22:21] <robertwb> He can extract the patch as a diff to play with it. [22:21] <sage> good point. [22:22] <sage> he can probably backout my backout, actually! [22:22] <robertwb> it's not a patch that merges into a lot of other stuff... [22:23] <sage> interestingly, if i remove it, then anybody who pull from me would not have it removed from theirs. [22:24] <sage> i'm very very curious though what was going wrong... [22:25] <robertwb> me too [22:25] <sage> i'm going to try for a few minutes to fix his code. [22:25] <robertwb> ok [22:26] <robertwb> I wonder if one of the global variables leaked out into a sage object... [22:26] <robertwb> that would mean its not really his patch's fault, but it just exposed another bug [22:26] <sage> interesting. [22:27] <robertwb> brb [22:32] <sage> very interesting -- there is a libcsage.a in $SAGE_LOCAL/lib/ [22:32] <sage> that is bad news waiting to happen. [22:32] <sage> if anything links that in, then there are multiple copies of "global unique data", [22:32] <sage> and only one copy is initialized!!!!! [22:33] <sage> weird -- on one of my build machines getting rid of libcsage*a seems to have fixed the problem... [22:33] <sage> nope. [22:33] <sage> false alarm [22:40] <craigcitro> but that is a good point ... maybe the sage install should try to clean those up? [22:40] <wstein> they were left from the pre-scons days on that install, I think. [22:43] <craigcitro> nods ... but it might be that way on several machines in the world [22:43] <wstein> it doesn't really cause a problerm. [22:43] <craigcitro> k [22:45] <boothby> sage -- python has trademarked their logo + the word python. debian has a wierd license on their logo. [22:45] <wstein> we should. [22:45] --> boothby_ has joined this channel (n=[email protected]). [22:46] <boothby_> wstein / sage -- python has trademarked their logo + the word python. debian has a wierd license on their logo. [22:46] <-- boothby has left this server ("leaving"). [22:46] <-- boothby_ has left this server (Client Quit). [22:47] --> boothby has joined this channel (n=[email protected]). [22:47] <wstein> robertwb -- i've made a slight modification to gmp.pxi that restores the old behavior, [22:48] <wstein> but makes it easy to switch to the new behavior. [22:48] <wstein> I pushed it out. [22:54] --> janwil has joined this channel (n=[email protected]). [22:55] <craigcitro> hey william -- i added the functionality we were talking about to sage -coverage [22:55] <craigcitro> so the way i have it working is this [22:56] <craigcitro> if the doctests for a function don't contain the name of the function, it adds it to another list [22:56] <wstein> great! [22:56] <craigcitro> and then prints that list at the end in a set called "possibly wrong (missing name of function in doctests)" [22:56] <craigcitro> but then if you have an environment variable called "SAGE_IGNORE_NAMEFREE_DOCTESTS" [22:56] <craigcitro> then it doesn't do that printing [22:56] <craigcitro> is that reasonable? [22:56] <sage> i don't like the enviro variable thing. [22:56] <sage> nobody will want to use that. [22:57] <janwil> good morning everyone [22:57] <craigcitro> well, you want to be able to ignore it sometimes [22:57] <craigcitro> morning janwil [22:57] <sage> it's too long, and if you go to the trouble of defining it just to cheat... [22:57] <sage> it would be better to have a notation, e.g., [22:57] <sage> def foo(...): # doctest doesn't involve foo [22:57] <sage> or [22:57] <craigcitro> ah, ok [22:57] <sage> def foo(...): # indirect doctest [22:57] <sage> then it's clear what's up when you look at the code. [22:57] <craigcitro> that works [22:57] <sage> and it works the same for everybody. [22:58] <craigcitro> sure, i just wanted some way of overriding the extra output [22:58] <craigcitro> so where does that comment have to go? in one of the doctests? [22:58] <craigcitro> (i'm just figuring out where to put the search for it.) [22:59] <sage> that's a good idea. [22:59] <sage> if the word "indirect" is anywhere in the docstring, then just [22:59] <craigcitro> so i'll search for it at the same time i search for the function name? [22:59] <sage> don't knock the function for not doctesting exactly that name of function. [22:59] <sage> simple. [22:59] <craigcitro> well, we might want something less likely to occur than just that word [22:59] <craigcitro> because i could imagine that occurring anyway [22:59] <craigcitro> doctest_indirect ? [23:00] <sage> "indirect doctest". [23:00] <craigcitro> indirect_doctests [23:00] <sage> NO -- it should be english. [23:00] <craigcitro> k [23:00] <sage> and if it happened accidently it isn't a problem really. [23:00] <craigcitro> i'll look for the string 'indirect doctest' [23:00] <craigcitro> oh, sure, as long as it's pretty unlikely [23:00] <craigcitro> a single english word seems to likely, though [23:01] <craigcitro> too, rather [23:02] <craigcitro> k, that's good to go. i'll make a ticket and submit a patch. [23:04] <craigcitro> and i'm going to tag the scons -Q onto that same patch, unless you tell me you've recently decided against it. [23:05] <sage> From somebody using sage.math for serious work: " Anyway, I do want to say thanks for letting [23:05] <sage> me use the machine. I'ts a huge improvement ovver trying to [23:05] <sage> use the Westgrid machine where you have to submit your job [23:05] <sage> to a queue and then, well, I've been waiting 6 dayws now for [23:05] <sage> craigcitro -- good. [23:05] <sage> one job to start. It's just hopeless to try to develope [23:05] <sage> code on that network when you have to wait days for a job to start."" [23:05] <craigcitro> hah that's awesome [23:06] <robertwb> hi [23:06] <robertwb> I like the indirect doctest thing [23:06] <robertwb> special functions (e.g. add) should all be indirect by default [23:06] <sage> robertwb -- hyperellipic_padic still crashes for me. [23:07] <robertwb> william: I'm trying to understand your gmp_globals patch [23:07] <sage> All I did was comment out what was added, and put back what was there before in gmp.pxi. [23:07] <sage> I didn't touch anything else (hopefully). [23:08] <robertwb> what about the "add gmp_globals" patch? [23:08] <craigcitro> ooh, good point robert [23:08] <craigcitro> so do we have a list of what functions i should totally skip? or everything wrapped in ? [23:08] <robertwb> that still uses gmp_globals.c, right? [23:09] <robertwb> everything wrapped in is probably safe [23:09] <craigcitro> k [23:09] <robertwb> oh, but _add_c_impl and stuff too... hmm... maybe there should be a big list [23:09] <sage> cdef methods are all skipped. [23:10] <robertwb> looking at hyperelliptic_padic ... sage -t --gdb brings you to a gdb prompt, how do you go from there? [23:10] <sage> r [23:10] <sage> type "r" [23:10] <robertwb> ah [23:11] <robertwb> stuff like _add_c_impl should still have a doctest (to test it), right? [23:14] <robertwb> hyperelliptic_padic looks like it has nothing to do with my patch... [23:15] <wstein> your doctests expose the problem. [23:15] <robertwb> some memory error in free modules over Q, still looking into it [23:15] <robertwb> lesson: doctests are bad :) [23:15] <wstein> when i use gmp i get an error in GCD in doing arithmetic over QQ. [23:15] <wstein> maybe you should delete teh doctests... [23:16] <robertwb> yep, same here, but at least its reproducible and in the same spot every time [23:16] <robertwb> it worked on the previous version of SAGE

bug/02 (last edited 2017-02-02 04:08:28 by mrennekamp)