|
Size: 1701
Comment:
|
← Revision 29 as of 2017-02-02 04:08:57 ⇥
Size: 138150
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from bug03 ## page was renamed from bug3 |
|
| Line 7: | Line 9: |
| * [:bug3/status: STATUS] * [:bug3/irc: IRC log] * [:bug3/Results: Results] * The base version of SAGE we'll start with is here: sage-2.x, which you can upgrade to. |
The results: http://trac.sagemath.org/sage_trac/milestone/sage-2.8.5 * [[bug3/status| STATUS]] * [[bug3/irc| IRC log]] * [[bug3/Results| Results]] * The base version of SAGE we'll start with is here: sage-2.8.4.2.1, which you can upgrade to using "sage -upgrade" |
| Line 37: | Line 41: |
| 1. Martin Albrecht: | 1. Martin Albrecht: memleaks & maybe libSINGULAR enhancements |
| Line 43: | Line 47: |
| 1. Timothy Clemans: Notebook bugs | 1. Timothy Clemans (evening maybe): Notebook bugs |
| Line 57: | Line 61: |
[[ImageLink(bugs.jpg)]] |
1. Tom Boothby (10am -- 5pm; 6pm -- 10pm): AbelianGroup 1. David Harvey: yeah bugs and stuff [[attachment:bugs.jpg|{{attachment:bugs.jpg}}]] = IRC = BUG3 irc log: [10:08] <ncalexan> pulling from /Users/ncalexan/sage/spkg/build/sage-2.8.4.2 [10:08] <ncalexan> searching for changes [10:08] <ncalexan> adding changesets [10:08] <ncalexan> adding manifests [10:08] <ncalexan> adding file changes [10:08] <ncalexan> added 592 changesets with 1040 changes to 321 files [10:09] <ncalexan> (run 'hg update' to get a working copy) [10:09] <ncalexan> abort: there is nothing to merge, just use 'hg update' or look at 'hg heads' [10:09] <ncalexan> nothing changed [10:09] <ncalexan> remote changed .hgtags which local deleted [10:09] <ncalexan> (k)eep or (d)elete? k [10:09] <william_stein> ok, so it isn't leaking. [10:09] <ncalexan> remote changed export which local deleted [10:09] <ncalexan> (k)eep or (d)elete? k [10:09] <ncalexan> 288 files updated, 0 files merged, 7 files removed, 0 files unresolved [10:09] <ncalexan> Any ideas? [10:09] <ncalexan> (While sage -upgrade was running) [10:09] <william_stein> so? [10:10] <william_stein> sage: b = a.__copy__() [10:10] <william_stein> sage: get_memory_usage() - s [10:10] <william_stein> 1.57421875 [10:10] <william_stein> sage: b = a.__copy__() [10:10] <william_stein> sage: get_memory_usage() - s [10:10] <william_stein> 1.98828125 [10:10] <william_stein> sage: b = a.__copy__() [10:10] <william_stein> sage: get_memory_usage() - s [10:10] <william_stein> 1.83203125 [10:10] <william_stein> oh, so copy is ok. sorry I'm a little slow getting started here, and saying dumb things. [10:11] <william_stein> burcin: [10:11] <william_stein> sage: s = get_memory_usage(); a = M.zero_matrix(); del a; get_memory_usage() - s [10:11] <william_stein> 0.0 [10:11] <william_stein> sage: s = get_memory_usage(); a = M.zero_matrix(); del a; get_memory_usage() - s [10:11] <william_stein> 0.0 [10:11] <william_stein> So there is no leak here. Move along. [10:11] *** mabshoff_ is now known as mabshoff|Cooking. [10:11] <william_stein> Anyway, could people introduce themselves quickly, say where they are, etc. [10:11] <burcin> I don't assign to any object.. and it keeps increasing.. [10:12] <william_stein> That could be IPython caching output. [10:12] * ncalexan is Nick Alexander, in Irvine, California. [10:12] * mhansen is Mike Hansen in Madison, Wisconsin, U.S. [10:12] <william_stein> in fact it is: [10:12] <william_stein> sage: M.zero_matrix() [10:12] <william_stein> 500 x 500 dense matrix over Integer Ring [10:12] <william_stein> sage: _ [10:12] <william_stein> 500 x 500 dense matrix over Integer Ring [10:13] <william_stein> The last few outputs are cached... [10:13] <burcin> burcin erocal, linz, austria [10:13] <burcin> can we turn that off somehow? [10:13] <ncalexan> william_stein: actually a lot more than the last few are cached. [10:13] <ncalexan> burcin: yes, it can be configured. [10:13] <william_stein> burcin -- yes -- see ipythonrc in .sage [10:13] <burcin> yes.. I think all are cached.. [10:13] <malb_> /me is Martin Albrecht, London, UK [10:13] <william_stein> I'm william stein in Seattle, WA [10:14] <william_stein> who is boothby? [10:14] <william_stein> and where is he? [10:14] <boothby> I'm boothby. [10:14] <boothby> Right here. [10:14] <jkantor> jkantor is josh kantor, usually seattle, WA but currently on vacation in buffalo, NY. [10:15] <boothby> Okfine, I'm Tom Boothby, in Seattle [10:15] <william_stein> OK, so the rules are (1) don't work on anything that isn't a trac ticket; (2) try to prefix lines with the trac #. [10:15] <william_stein> The goal is to fix as many bugs in Sage as possible today. [10:15] <mabshoff|Cooking> Michael Abshoff in Dortmund, Germany. [10:16] <william_stein> as bugs get fixed, I'll upload the fixes to the official hg repo, and people can hg_sage.pull() them... [10:16] <ncalexan> Could we have a trac triage page again? That was fantastic. [10:17] <mabshoff|Cooking> Well, there are a bunch of patches qued at the 2.8.4.3 milestone. [10:17] <mabshoff|Cooking> And I think it would be great if mhansen's combinatorics patch could go in early. [10:17] *** mabshoff|Cooking is now known as mabshoff_. [10:17] <mabshoff_> Last time I checked it wasn't in trac (yet) [10:17] <burcin> does the upgrade work correctly for you? [10:18] <william_stein> I haven't finished upgrading yet. [10:18] <burcin> <type 'exceptions.ImportError'>: No module named sage.misc.preparser_ipython [10:18] <burcin> WARNING: Failure executing code: 'import sage.misc.preparser_ipython; sage.misc.preparser_ipython.magma_colon_equals=True' [10:18] --> roed_ has joined this channel (n=roed@MACLAURIN-SIXTEEN-NINETY-FOUR.MIT.EDU). [10:18] <janwil> (Jan Willemson, Tartu, Estonia, but I will probably mostly be rather quiet:)) [10:18] <william_stein> Did "sage -br" fail for you. [10:18] <mhansen> mabshoff: #630. I didn't have time to finish it last night, but that's what I'll work on first. [10:18] <ncalexan> Hi Jan, I don't recognize you from the list. Welcome! [10:19] <william_stein> the upgrade failed for me. not good. [10:19] <william_stein> i rushed this release. [10:19] <william_stein> and made it while on the linbox call. [10:19] <william_stein> sorry [10:19] <william_stein> hold on. [10:19] <ncalexan> Don't worry -- this will focus the bug day like nothing else. [10:19] <william_stein> problem is flint. [10:20] <william_stein> should I disable it or fix that it isn't installed correctly? [10:20] <janwil> Hi ... I actually have a SAGE issue that really bothers me, but that is documented only in the devel mailing list and is not a trac ticket (yet), so probably it is out of the focus today anyway [10:21] <william_stein> ah, maybe it isn't in the makefile. [10:21] <william_stein> janwil -- put it in trac. [10:21] <ncalexan> janwil: do you have a trac account? [10:21] <janwil> no [10:21] <william_stein> ok, I fixed the upgrade problem almost... not quite. [10:21] <ncalexan> janwil: if it's easy to describe, message me and I will add it to trac. William might be a few minutes adding your account. [10:22] <ncalexan> Actually, just use mine: [10:22] <ncalexan> Hmm... perhaps not. [10:22] <janwil> well, it's not easy to describe :( [10:22] <ncalexan> :( [10:22] <william_stein> janwil -- email me with your requested login and low-quality password for fun. [10:22] <mabshoff_> I think janwil's issue is in trac with a patch by malb. [10:22] <william_stein> ah [10:23] <janwil> well, that patch did not help the main issue I had [10:23] <mabshoff_> the maxima vs. your Linux distro issue, checking for th e number. [10:23] <malb_> I will be looking at #445 this bothers me quite a lot, I'm not sure how far I'll get though [10:23] <mabshoff_> The script issue? That is also in trac. [10:23] <janwil> oh, with the long script? [10:24] <mabshoff_> I think #445 is more or less a pexpect and Signal delivery issue. [10:24] <mabshoff_> We might need to modify it to just send SIGKILL [10:25] <mabshoff_> But I might be completely wrong :) [10:25] <mabshoff_> janwil: can you find the issues you have in trac? [10:25] <mabshoff_> I think #507 is one of them. [10:26] <malb_> mabshoff_ / #445: yes something along the line of that [10:26] <william_stein> Do "sage -upgrade" then "sage -br". [10:26] <janwil> #507 is a simple case .. I also have a problem that is reproducible in 4 cases out of 5 [10:26] <mabshoff_> Well, in the end we need to write a proper pexpect replacemnt anyway. [10:27] <janwil> ok, I will try to put it to trac [10:27] <mabshoff_> janwil: could you build a Arch Linux vmware image? That way we could test on it regulary. [10:27] <janwil> and this 4 out of 5 occurs on Ubuntu [10:28] <jkantor> William/700 where should the doctests for cvxopt and scipy go ? [10:28] <william_stein> Hi everybody -- I fixed the upgrade issue. If you just do "sage -upgrade" again then "sage -br" you'll be good. [10:28] <mabshoff_> okay, post the issues, hopefully someone will be able to reproduce them. [10:28] <mabshoff_> :) [10:28] <william_stein> jkantor -- good question. [10:28] <william_stein> In a file somewhere. [10:28] <janwil> william_stein: is your gmail account ok to use for trac username application? [10:28] <william_stein> janwil -- yes. [10:29] <william_stein> jkantor -- I think there should be a SAGE_ROOT/devel/sage/sage/numerical directory [10:29] <mabshoff_> while you are at it: can you change my trac password to something less obvious and send me the updated password? [10:29] <jkantor> I was about to say that [10:29] <william_stein> Inside there you could put a .py file with a big triple quoted string that has tests of numpy, scipy, cvxopt, etc. [10:30] <jkantor> ok [10:31] <william_stein> #445 -- I'll work on that too right now. [10:31] <william_stein> I think it will be easy to fix. [10:31] <ncalexan> jkantor: could I suggest you define somewhat relevant method names rather than one big string? In future, the testing interface will probably provide detailed feedback about what method the test was in. [10:32] <william_stein> We're not testing methods. [10:32] <william_stein> We're just testing that two libraries were actually installed. [10:32] <william_stein> The thing is that cvxopt and scipy like to silently pretend to be installed, but with most of their functionality [10:32] <janwil> willam_stein: ok, sent it from my gmail account, so it should be delivered quite fast [10:32] <william_stein> gone if something goes slightly wrong when building. [10:32] <mabshoff_> :) [10:32] <william_stein> #445 -- has anybody replicated it? [10:33] <william_stein> jkantor -- make a trac ticket for what you're doing, so we will get one more extra point when you finish it :-) [10:33] <dmharvey> hi, i'm david harvey, cambridge MA.... ten minutes walk away from the next sage days [10:34] <malb_> I replicate this on a daily basis with SINGULAR [10:34] <ncalexan> william_stein: in that case, shouldn't the doctests be testing that the missing functionality really is there? [10:34] <malb_> that was about #445 [10:34] <jkantor> Most of the problems are missing symbols on importing modules [10:34] <jkantor> So if there is no exception, the functionality is there [10:34] <-- roed_ has left this server (Read error: 110 (Connection timed out)). [10:35] <dmharvey> i'm starting with #635, which should be straightforward I hope [10:36] <william_stein> robert miller just showed up (in my office) [10:36] <william_stein> #635 -- good [10:39] <william_stein> #445 -- I just replicated with this input. It's evil. [10:39] <william_stein> R=QQ['x'] [10:39] <william_stein> f = R.random_element(5000) [10:39] <william_stein> g = magma(f) [10:39] <william_stein> g.IsIrreducible() [10:40] --> millster has joined this channel (n=robert@mdhcp175.math.washington.edu). [10:40] <william_stein> Important not on #445 -- it *only* happens in the notebook. [10:40] <malb_> #445 I calculate GBs on a daily basis, equally evil [10:40] <william_stein> #445 -- malb -- do you agree? [10:40] <malb_> really? [10:41] <malb_> let me check [10:41] <william_stein> Yes. The same example pasted above works fine in the console. [10:41] <malb_> hang on, need to rebuild SAGE (connection to sage.math is very slow) [10:41] <william_stein> ok [10:43] <william_stein> #445 -- probably the notebook is so agressively interrupting the sage process that is running magma, [10:43] <william_stein> that it interrupts it in the middle of actually killing the running magma. [10:43] <william_stein> It's two levels of pexpect going on. [10:44] <malb_> so we should send a command first (kill-your-children) and interrupt then? [10:44] <william_stein> definitely not. [10:44] <william_stein> In fact that magma process shouldn't even get killed. [10:44] <william_stein> It should just get interrupted. [10:45] <william_stein> We should probably just send 1 interrupt signal from the notebook server to the Python process. [10:45] <william_stein> I.e., one "control C". [10:45] <william_stein> Let me look at the code. [10:45] <william_stein> line 1328 of server/notebook/worksheet.py [10:45] <william_stein> right now 3 ctrl-c's are sent when you hit escape or click "interrupt" in the notebook. [10:45] <william_stein> I'll try changing to 1. [10:46] <malb_> okay, still building [10:47] <mabshoff_> Sorry, I was gone, but should be do any upgrade from 2.8.4.2 or is there another tarball? [10:48] <william_stein> #445 that workec well [10:49] <malb_> good, my Singular problem seems unrelated then [10:50] <malb_> P = PolynomialRing(QQ,10,'x') [10:50] <malb_> I = sage.rings.ideal.Katsura(P) [10:50] <malb_> I.groebner_basis() # forever! [10:50] <malb_> Ctrl-C [10:50] <malb_> from the command line [10:51] <malb_> what function handles signals? [10:52] <william_stein> It's just keyboardinterrupt being handled in expect.py or possible singular.py [10:52] <jkantor> william/709 To be doctested the file just needs to be in the source tree, i don't need an all.py to import it or anything right? [10:52] <william_stein> yes. [10:52] <william_stein> #709 -- yes [10:55] <william_stein> #445 -- expect.py: interupt(...) is very relevant to what happens after ctrl-c is received... [10:55] <william_stein> I think. [10:56] <janwil> william_stein: did you get my email? [10:56] <ncalexan> Hmm, clisp.pdf missing stops the build. [10:56] <williamstein> janwil -- yep. [10:56] <williamstein> ncalexan you've had that problem before, no? [10:56] <williamstein> you have a weird setup of pdf tools. check sage-devel. [10:57] <ncalexan> Yes... oh, thanks for the reminder. [10:57] <mabshoff_> That problem is related to some missing tool [10:57] <malb_> #445 I got it [10:57] <williamstein> janwil -- you should have a trac account. [10:57] <williamstein> My "fix" for #445 breaks other things, so not good. [10:57] <williamstein> Weird. [10:58] <mabshoff_> ncalexan: You had the same problem at http://groups.google.com/group/sage-devel/browse_thread/thread/af701e5f8d428ad2 [10:58] <janwil> williamstein: thanx, I have it now ... will try to create a ticket [10:58] <ncalexan> thankx. [10:59] <mabshoff_> you need to fix your dvipdf :) [10:59] <ncalexan> I do, but there's actually a hairy problem in the middle (with fink and X11) that I don't want to fix :) [10:59] <ncalexan> but maybe now is the time. [10:59] <mabshoff_> interstingly the second google hit for "clisp.pdf missing" :) [11:00] <malb_> #445 I figured out my problem with Singular, Singular has a signal handler which asks what to do [11:01] <ncalexan> One wonders what the first hit is :) [11:01] <mabshoff_> http://www.google.de/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fftp6.tw.freebsd.org%2FFreeBSD%2Fdevelopment%2FFreeBSD-CVS%2Fports%2Flang%2Fclisp%2Fpkg-plist%2Cv&ei=MrXyRv2OPI38nQP7lvnDDg&usg=AFQjCNHZRGUz_mjLv8ZnyL2s5uJAjAp66w&sig2=omEH8PW3FYRcm7xemWq7Tw :) [11:01] <mabshoff_> But I thing that varies depending on which country you google from :) [11:02] <dmharvey> #635: not only did chris wuthrich change the precision in the doctests, he changed all the answers too. I have no idea what to make of all this. [11:02] <william_stein> #445 -- malb -- could you post an example that illustrates your porlbme at singular GB's? [11:02] <malb_> the one I posted earlier: [11:02] <malb_> P = PolynomialRing(QQ,10,'x') [11:03] <malb_> I = sage.rings.ideal.Katsura(P) [11:05] <mabshoff_> I am off for the next hours or so, commuting home. [11:05] <mabshoff_> cu in a bit [11:05] <william_stein> cu [11:05] <-- mabshoff_ has left this server (Read error: 104 (Connection reset by peer)). [11:06] <dmharvey> wstein: #635, it's very strange. I'm looking at a diff where chris changed the normalisation by 2p, which is what we had agreed, but I'm sure I also did the same thing! So I guess you probably never merged in my changes. [11:06] <william_stein> sorry. [11:08] <dmharvey> that's okay. It's hard working on code like this where various people have different goals. Like chris probably doesn't care too much about whether the last digit is there or not; but when I'm playing with large primes, the last digit takes a lot of extra time! [11:08] <william_stein> #445 -- i just checked in a change that fixes the problem in the notebook. [11:08] <william_stein> I found another related bug while I was at it, that I'll pos. [11:10] <malb_> good, I am still playing with Singular's special treatment [11:10] <william_stein> malb -- check out http://trac.sagemath.org/sage_trac/ticket/710 [11:11] <william_stein> sage: n=factor(2^997-1) # then hit control C [11:11] <william_stein> then do [11:11] <malb_> ouch [11:11] <william_stein> sage: gp.eval('factor(2^997-1)') # then hit control C [11:11] <william_stein> and boom!! [11:11] <malb_> how can those two be related? [11:11] <william_stein> and it happens with any interface -- not just gp. [11:12] <william_stein> somehow the pari signal handling if seriously foobaring something about the state of Sage. [11:13] <malb_> mhh, can you Ctrl-C twice for factor(2^997-1)? [11:14] <william_stein> for me factor(2^997-1) with 1 control-c immediately interrupts. [11:14] <william_stein> #710: on os x interrupting gp.eval('factor(2^997-1)') then fails [11:14] <william_stein> #710: on linux 64-bit it seg faults. [11:15] <william_stein> I'm going to close #445, since that's now fixed. [11:15] <william_stein> But we need a ticket for your katsura example. I'll try to replicate it and if so, open a ticket. [11:15] <malb_> okay [11:15] <janwil> should I include the script as a snippet in the ticket or should I attach it as a file? [11:15] <william_stein> Your choice. If a snippet, use {{{ and .[11:16] <janwil> yes, I did use them, thanx [11:16] <william_stein> malb -- replicated. [11:16] <william_stein> Your bug will be easy to fix, I think. [11:17] <william_stein> #711 -- malb, your bug is now 711. [11:17] <william_stein> #445 is now fixed (unless people claim differently). [11:17] <william_stein> brb. [11:19] <janwil> ok, submitted -- #712 (the reference to the component is probably wrong -- please excuse me) [11:23] <william_stein> janwil -- is it possible that your problem is a bug in maxima itself? [11:24] <william_stein> when I try your system it fails right off. [11:27] <william_stein> #712 -- ok, I'm working on this now. [11:28] <william_stein> it's a bug in maxima. [11:28] <william_stein> it's outputing "CAR: 2 is not a list" and dieing. [11:29] <william_stein> janwil -- we should make a clean file that inputs something into Maxima (not involving sage) and [11:29] <william_stein> produces that error, and report it on the maxima list. [11:29] <malb_> william_stein: See #713 (the Singular interface bug with patch) [11:30] <william_stein> that's no fix. [11:30] <william_stein> #713 -- rejected. [11:30] <william_stein> We should never ever leave a process running that a user has to kill manually. [11:30] <malb_> why? [11:30] <william_stein> No matter what. [11:30] <malb_> i.e. Ctrl-D is not an option? [11:31] <william_stein> No. But the print "WARNING: -- unable to kill %s. You may have to do so manually."%self [11:31] <william_stein> i don't like. [11:31] <malb_> thats just copied from expect.py [11:31] <malb_> I didn't write that [11:31] <william_stein> In that case, shouldn't we kill -9 the sucker or something and make sure it didn't work. [11:31] <william_stein> Ok, well then I reject the code I wrote :-) [11:31] <malb_> better :-) [11:32] <william_stein> Who wrote it? [11:32] <william_stein> me. [11:33] <william_stein> well that should still be replaced by kill -9. [11:33] <william_stein> new ticket. [11:33] <malb_> okay, will do [11:33] <william_stein> i'm making the ticket now. [11:34] <william_stein> #714 -- that kill -9 thing. [11:34] <william_stein> I'll apply your #713 now [11:41] <jkantor> #709-is done, (together with the fix for 700 so the doctests actually pass) [11:42] <ncalexan> william_stein: where is the bug triage list? [11:42] <ncalexan> Or the correct trac view? [11:42] <william_stein> ncalexan: http://trac.sagemath.org/sage_trac/milestone/sage-2.8.4.3 [11:42] <ncalexan> Thanks. [11:43] <william_stein> Our goal is basically to deal everything marked for 2.8.4.3. [11:43] <william_stein> Also, look a lot at the 2.9 bugs. [11:43] <william_stein> there isn't much of a handwritten page yet though. [11:43] <william_stein> volunteer to make one?? [11:43] <william_stein> (I'm not sure it is needed.) [11:44] <malb_> wstein, #714 close(force=1) already sends a SIGKILL [11:44] <malb_> so this exception actually should never happen [11:45] <william_stein> How about in the exception check for the process first and if it is still there send more kills? [11:45] <william_stein> Or is this getting overly paranoid, given that when sage quits it will *definitely* kill the process. [11:45] <william_stein> (the zombie killed) sage-cleaner. [11:45] <william_stein> I just replicated janwil's bug entirely in maxima. [11:45] <malb_> I would suggest: propagate the exception up and wait for bugreports [11:46] <malb_> this way we have something to replicate [11:46] <william_stein> #712 -- It has absolutely nothing whatever to do with Sage or the pexpect interface [11:46] <william_stein> And for me it isn't sporadic. [11:46] <william_stein> malb -- good idea! [11:46] <william_stein> That's fine by me. [11:46] <malb_> okay, will attach patch to #714 [11:46] <william_stein> Please add to the exception: "THIS IS A BUG -- PLEASE REPORT. This should never happen." [11:47] <malb_> okay [11:50] <william_stein> #712 -- I'm done working on http://trac.sagemath.org/sage_trac/ticket/712 [11:50] <william_stein> #712 Janwil, I hope you can report this bug to the maxima list. [11:51] <william_stein> I think if you just provide the input file I attached there -- which should make it easy for anybody [11:51] <william_stein> to replicate the problem, then you'll have a chance. [11:51] <janwil> william_stein: thanx for your work! yes, I can report this as a Maxima problem [11:52] * ncalexan is working on 228, a small notebook bug to do with the preparser. [11:53] <william_stein> ncalexan -- thanks!! [11:53] <william_stein> #228 -- That's a long open bug that needs to be fixed. [11:54] <william_stein> Ralph Greenberg just dropped by my office. He wants us to fix some bugs in his house... [11:54] <william_stein> #713: closed. [11:55] --> robertwb has joined this channel (n=robert@D-69-91-158-249.dhcp4.washington.edu). [11:57] <william_stein> malb -- I'm looking at #507 (which you fixed) [12:00] <malb_> good, also I've attached a patch to #714 [12:01] --> roed_ has joined this channel (n=roed@RANDOM-FOUR-SEVENTY-FIVE.MIT.EDU). [12:02] <william_stein> hi david roed_ [12:03] <roed_> hey [12:03] <william_stein> #714: closed. [12:04] <roed_> cool. Did anyone have suggestions on the design? [12:04] <janwil> william_stein: I do not quite understand the maxima_bug that you uploaded ... solve(sage3, sage7); refers to sage3, but that is not defined ... am I reading something wrong? [12:05] <william_stein> I forgot to put it in the script. [12:05] <william_stein> Hold on. [12:06] <dmharvey> roed: design of what? [12:06] <william_stein> sage3 : [sage0,sage1,sage2] [12:07] <janwil> ok, that makes sense :) and sage9 and sage10 are not actually needed? [12:07] <william_stein> now the bug doesn't happen for me. Drat. [12:07] <william_stein> what the heck. [12:08] <janwil> ok, so you were able to reproduce my sometimes-bug-sometimes-not behavior? [12:08] <william_stein> now I am, which sucks. [12:08] <janwil> well, that was really annoying when I stepped onto it, too [12:09] <janwil> I was already ready to blame some race conditions or timing or something like that [12:09] <roed_> dmharvey: I wrote a way to globally control default proof behavior last night [12:10] <roed_> http://trac.sagemath.org/sage_trac/ticket/704 [12:12] <william_stein> janwil -- bug #712 -- please try loading the file j attached to #712. [12:12] <william_stein> (%i1) batchload("/home/was/tmp/j"); [12:12] <william_stein> Maxima encountered a Lisp error: [12:12] <dmharvey> roed: also would be nice to have global spelling="british" to prevent ugliness like "behavior" :-) [12:12] <william_stein> every time. [12:12] <william_stein> :-) [12:13] <william_stein> #704 -- proof stuff -- I'm putting that in Sage now. [12:14] <roed_> dmharvey: lol. There are plenty of other global settings that one might want to control. I'll stick to proof=True/False for now [12:14] <william_stein> roed_: EXAMPLES are supposed to be indented 4 spaces. [12:14] <william_stein> EXAMPLES: [12:14] <william_stein> [4 spaces]sage: input [12:15] <william_stein> [4 spaces]output [12:16] <roed_> ok [12:17] <janwil> william_stein: maxima -b j gives something different for me ... [12:18] <janwil> Inconsistent equations: (2 3) [12:18] <janwil> -- an error. Quitting. To debug this try debugmode(true); [12:18] <william_stein> Cool. [12:19] <janwil> well, I did not use SAGEs maxima, but Ubuntu's ... [12:19] <william_stein> ah. [12:19] <william_stein> Try sage's: "sage -maxima". [12:19] <william_stein> It could be a new bug in maxima and sage's maxima is newer. [12:20] <janwil> ok, now I get CAR: 2 is not a list [12:21] <janwil> so this "inconsistent equations" shouldn't be happening either? [12:21] <william_stein> janwil -- i don't know. [12:21] <roed_> dmharvey: do you know if Sage currently includes ZZ_pEX? [12:21] <janwil> ok :) [12:22] <william_stein> But "CAR: 2 is not a list" is definitely a Maximma bug, since that's a lisp error, and maxima [12:22] <william_stein> should never produce a lisp error. [12:22] <dmharvey> roed: I don't believe it does [12:22] <william_stein> roed_ -- did you do "make test" or "sage -testall" after making your proof patch? [12:22] <janwil> ok, I will try to put together a bug report for maxima [12:22] <william_stein> janwil -- thanks. [12:23] <dmharvey> grep -R "ZZ_pEX" * -- nope [12:23] <roed_> william_stein: I had that remaining issue with sage/rings/morphism.py that was different between sage -t and grep "sage: [12:23] <roed_> " morphism.py | sage [12:25] <william_stein> ok. [12:25] <roed_> But I'm running a make test now [12:25] <roed_> We'll see if it's still there. [12:25] <william_stein> I want to put robert miller's [a..b] patch in. [12:25] <william_stein> Any objections :-) ? [12:26] <william_stein> oops -- robert bradshaw. [12:26] <william_stein> roed -- I'll work on that morphism.py thing as I've applied your patch now. [12:27] <william_stein> sage -t morphism.py [12:27] <william_stein> works fine form me. [12:29] <roed_> good [12:29] <roed_> :-) [12:32] --> grout has joined this channel (n=grout@good.math.iastate.edu). [12:32] <william_stein> hi jason. Welcome to SAGE! [12:32] <grout> thanks! [12:33] <millster> hi jason, i'm writing an answer to your questions on google groups [12:33] <grout> the one about the mercurial error? [12:33] <millster> aye [12:33] <dmharvey> #635: I'm basically done with this, I'm just running ./sage -t -long on sage.math now [12:36] <dmharvey> I'm going to continue working on #528 now. This will probably be a few hours work I imagine. [12:37] --> mabshoff_ has joined this channel (n=mabshoff@p5090C126.dip.t-dialin.net). [12:37] <mabshoff_> Hey, looks pretty busy now. [12:39] <dmharvey> does sage -t -long time out after five minutes for a whole file? [12:40] <mabshoff_> I am not sure, but I think there is a bug in the timeout code when python just "spins" [12:41] <william_stein> probably. [12:41] <mabshoff_> After you interrupt it (way past 180 seconds) it then tells you that it timed out after [12:41] <mabshoff_> you send the CRTL-C [12:41] <mabshoff_> I have seen that behavior with the lazy rings on Solaris 9 [12:41] <dmharvey> because it looks like sage -t -long is giving up on ell_rational_field.py after 294.6 seconds, with *** *** Error: TIMED OUT! *** *** [12:42] <william_stein> dmharvey: oops. [12:42] <william_stein> It's probably a bug. [12:42] <mabshoff_> (there is a bug or miscompilations happening there9 [12:42] <william_stein> dmharvey: I'll fix that. [12:42] <william_stein> it is a bug. [12:42] <mabshoff_> Some of the regular doctests with elliptic curves come close to the 3 minute timeout on [12:42] <mabshoff_> on neron by the way [12:43] <william_stein> or a mistake in design. [12:43] <william_stein> mabshoff_ -- ell_rational_field.py *desparately* needs to be broken into smaller files. [12:43] <mabshoff_> I guess it is ticket time then. [12:44] <mabshoff_> I will write some summary of the LinBox teleconference first, though. [12:44] <mabshoff_> And post it to LinBox devel. [12:44] <dmharvey> wstein: how do you break a file into pieces when it's all one class? [12:46] <william_stein> dmharvey -- you make it into multiple classes. [12:46] <roed_> I'd like to work on ell_rational_field.py [12:46] <dmharvey> roed: just hang on a few minutes at least..... I'm touching bits of that file now [12:46] <roed_> because we need a new class for elliptic curves over number fields [12:46] <william_stein> E.g., instead of E.L[tab] giving all kinds of l-series crap, one should instead maybe have [12:46] <william_stein> a class for "L-series of an elliptic curve", then all code related to L-series goes in that file. [12:48] <janwil> william_stein: your last j script was missing references to sage1 and sage2 ... when I added those from the Maxima_bug script, I got a script that worked fine for me every time both in SAGE's Maxima and in Ubuntu's one [12:49] <william_stein> hmm. [12:49] <william_stein> interesting. [12:50] <janwil> well, Maxima should probably never throw a lisp bug, but this still means we have not cracked #712 ... or? [12:50] <malb_> I was looking into #325 which involves NTL, it doesn't make sense to touch it now, doesn't because of the NTL break-up? [12:53] <ncalexan> william_stein: please do that L-series refactoring, it's badly needed. [12:54] <dmharvey> well shite. Now when I run sage -t -long on my modified ell_rational_curve.py, it segfaults. It wasn't doing that five minutes ago. [12:54] <william_stein> ncalexan: volunteers are needed :-) [12:54] <william_stein> malb_- the new ntl is I think ready to be tested and included in sage. [12:55] <william_stein> Check it out. [12:55] <ncalexan> Okay, I'm almost finished this bug, so maybe I'll look at that next. [12:55] <william_stein> #697. [12:55] <dmharvey> ncalexan: wait till I've put in #635, it's almost done, it touches ell_rational_field.py [12:55] <william_stein> #697 -- ntl -- malb, want to referee it :-) [12:55] <malb_> okay, applying the NTL and trying #325 then [12:55] <ncalexan> Okay, dmharvey, please ping me and send me the bundle/post it on sage.math. [12:57] <dmharvey> malb: I'll be working on top of joel's NTL patch too, i.e. continuing on #528 [12:59] <william_stein> dmharvey -- do "sage -t --verbose --long" -- it'll tell you a lot more. [12:59] <dmharvey> yeah I'm already doing verbose [13:00] <roed_> ncalexan: what are you planning on doing with ell_rational_field.py? [13:00] <dmharvey> wstein: do you run sage -t -long often? [13:00] <william_stein> dmharvey: once in a blue moon. [13:00] <ncalexan> roed_: not much, just factor out the L-series stuff into a separate class and file. [13:00] <william_stein> I should run it every night. [13:00] <ncalexan> It could wait. [13:01] <william_stein> Last time I ran it (about 2 weeks ago) I found a doctest by David Joyner. [13:01] <william_stein> It took a *long* time. [13:01] <william_stein> In fact, he told me it was _supposed_ to take about a day to run. [13:01] <william_stein> :-) [13:01] <roed_> ncalexan: why don't I do that. I need to refactor other stuff as well in order to split off an ell_number_field class [13:01] <william_stein> It was some record-breaking calculation in Gap. [13:01] <ncalexan> roed_: if you'd like. [13:01] <william_stein> roed_ -- could you make a plan first and post it for discussion? [13:01] <roed_> sure [13:02] <roed_> I'll make a new ticket [13:02] <william_stein> By the way, if people do "hg_sage.pull()" they will get Robert Bradshaw's complete-ish implementation of the [13:02] <william_stein> new [a..b] and (a..b) notation. [13:02] <william_stein> Try it out. [13:02] <william_stein> It's fun. [13:02] <william_stein> Try to break it. [13:02] <ncalexan> william_stein: did you already create an L-series ticket? [13:03] <william_stein> ncalexan -- no. go for it. [13:03] <william_stein> there might be a "break up ell_ational_field" ticket; I don't know. [13:03] <ncalexan> roed_: go for it, make the L-series ticket. [13:03] <william_stein> I want to fix the timeout stuff for doctesting. It's really weird. I'll make a trac ticket. [13:04] <dmharvey> wstein: this is annoying.... there's a failure in the long doctests now for EllipticCurve("123a1").sha_an_padic(41). But the only changes I made should have *increased* the precision of p-adic regulators and such. Is there an easy way to tell whether the old answer was correct, or the new answer is correct? [13:05] <william_stein> trac #717 -- issues with the timeouts. [13:05] <-- jkantor has left this server (Read error: 110 (Connection timed out)). [13:06] <william_stein> Well the answer should be a unit at 41. [13:06] <william_stein> Actually it should be 1, right? [13:06] <dmharvey> yeah I'm now getting 40 instead of 1 [13:06] <william_stein> -1. [13:07] <dmharvey> It's listed under "exceptional cases" -- I don't know what that means [13:07] <dmharvey> line 3226 [13:09] <william_stein> I think the normalization of the p-adic L-series is currently up to sign. [13:09] <dmharvey> is that "exceptional" as in "multiplicative"? [13:11] <janwil> william_stein: so I won't file a maxima bug yet? [13:11] <william_stein> janwil -- yes, definitely don't yet. [13:11] <william_stein> I'll get back to your problem in a minute. [13:11] <ncalexan> Please wait while the SAGE Notebook server starts... [13:12] <ncalexan> Traceback (most recent call last): [13:12] <ncalexan> File "/Users/ncalexan/sage/local/bin/sage-notebook", line 9, in <module> [13:12] <ncalexan> from sage.server.notebook.all import notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/all.py", line 13, in <module> [13:12] <ncalexan> from notebook_object import notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/notebook_object.py", line 17, in <module> [13:12] <ncalexan> import run_notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/run_notebook.py", line 26, in <module> [13:12] <janwil> ok, no problem ... will go make some tea ... [13:12] <ncalexan> import notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/notebook.py", line 21, in <module> [13:12] <ncalexan> from sage.structure.sage_object import SageObject, load [13:12] <millster> grout: hopefully that response will clear things up a bit [13:12] <ncalexan> sage -ba needed? [13:13] <william_stein> ncalexan -- what are you doing? [13:13] <ncalexan> Fixing 228: I changed a function in worksheet.py, added a few module level test data variables, and added doctests. [13:13] <ncalexan> sage -notebook fails; sage -t works. [13:14] <william_stein> it sounds like you broke the notebook. Maybe a circular import? [13:14] <ncalexan> Possible, I suppose. I removed nodoctest (why is that there, anyway?) so that my doctests were run. [13:15] <malb_> well the NTL patch conflicts already big time [13:15] <malb_> anybody familiar with number_field_element.pyx? [13:15] <william_stein> yes. [13:15] <william_stein> I just changed it a lot, with robert. [13:15] <william_stein> I'll try applying the ntl patch, since Robert is with me right now. [13:15] <malb_> _parent_poly_c_ doesn't work anymore (doesn't compile after the merge) [13:16] <dmharvey> wstein: if you're happy with the sha_an_padic() changing sign like that on one example, then I'm happy to post my patch for #635, otherwise I can try and investigate it further... but I probably don't know the theory well enough to figure out what's going on. [13:17] <-- robertwb has left this server. [13:17] <malb_> mhh,in the original code it is raise NotImplementedError anyway [13:18] --> jkantor has joined this channel (n=jkantor@cpe-76-180-115-46.buffalo.res.rr.com). [13:18] <william_stein> dmharvey -- please mark the doctest clearly (with words). [13:18] <william_stein> The fix is to normalize modular symbols correctly. [13:19] <william_stein> Craig Citro or I can fix that eventually and should. [13:19] <dmharvey> wstein: ok I'll do that and post the patch [13:22] <grout> is there anyone here who wants to talk about the graph.py code? I have a question about the order of an elif statement [13:22] <grout> Related to #716 [13:23] <millster> grout: what's your question? [13:24] <dmharvey> millster == robert miller? [13:24] <millster> yes [13:25] <grout> ah, just the person. [13:25] <grout> I'm looking in the init function of DiGraph and Graph [13:25] <grout> Why is there a test for the more general class DiGraph before the subclass XDiGraph? [13:25] <grout> Shouldn't it be the other way around? [13:26] <grout> (i.e., if we have an XDiGraph, just set _nxg and return, otherwise there's more work to do. [13:26] <william_stein> malb_ -- every conflict so far involves Robert Bradshaw's code, so we're in luck. [13:27] <william_stein> (no bug days on Sundays!) [13:27] <millster> actually, there's something you probably don't know: networkx.Graph never gets used [13:27] <millster> nor does networkx.DiGraph [13:27] <malb_> okay, it is compiling now, let's see what make test thinks about it [13:27] <millster> only .XGraph and .XDiGraph [13:27] <grout> Right, I realize that. [13:28] <ncalexan> william_stein: I reverted my worksheet change, but I still cannot load sage -notebook. [13:28] <ncalexan> I'm -upgrade-ing again. [13:28] <grout> millster: However, will a networkx function return a Graph or DiGraph object? [13:29] <grout> millster: then we'd need the init cases for those. [13:29] <millster> i'm not sure what the problem is [13:29] <grout> I've documented it in #716. [13:29] <millster> we have init cases for those [13:30] <grout> If I pass an XDiGraph with multiple edges, then that setting is lost because it is trapped in a more generic case. [13:30] <millster> ok, i think the problem is in the copy function [13:30] <grout> I already changed the copy function. [13:30] <grout> That's one problem, this is another. [13:30] <grout> (I think) [13:31] <millster> you [13:31] <grout> Well, I changed it in my local copy... [13:31] <millster> 're correct- half the problems are in copy, the other half in init [13:32] <grout> (and added a doctest function to check g.copy()==g [13:32] <mabshoff_> william_stein: Can you have a quick look at #718 - if you think it is as obvious a fix as I assume? [13:32] <millster> grout: hang on a sec [13:33] --> robertwb has joined this channel (n=robert@D-69-91-158-249.dhcp4.washington.edu). [13:37] <grout> millster: Actually, I think changing the order of the elif in the init fixes the copy problem as well. [13:37] <mabshoff_> And #719: also libpari related regarding the size of the internal libpari stack and its behavior [13:37] <mabshoff_> when calling pari.allocatemen() [13:38] <millster> oh of course, because in networkx, an xdigraph IS a digraph [13:38] <millster> of course of course [13:38] <grout> Right---test for the subclass before the class :) [13:38] <millster> that makes perfect sense [13:38] <millster> so switching the two in both init functions fixes everything? [13:38] <grout> I'm testing that... [13:38] <millster> ps, did you find my reply helpful? [13:39] <grout> Yes, very much so (in the few seconds that I scanned it...I think it ought to go in the developer's handbook [13:39] <millster> I'm in the process of doing that now [13:40] <mhansen> william_stein: I have mercurial branch on sage.math with the combinatorics stuff in it. It also has patches against other files that it breaks. I ran -testall and there were 3 errors that came up, but are unrelated to my stuff. [13:43] <william_stein> mhansen -- cool! [13:44] <william_stein> malb_ -- robert and I resolved the merge problems with the ntl bundle, hopefully. [13:44] <mhansen> Do you want a bundle? [13:44] <william_stein> mhansen -- yes. post it to trac. [13:44] <malb_> O really, I didn't so far (lots of doctest failures) [13:44] <malb_> good then, are you pushing it soon? [13:45] <william_stein> we just got it to build. haven't doctested yet! [13:45] <william_stein> But the build problems were mainly caused by new things Robert and I had done. [13:45] <william_stein> I'll push in about 10 minutes, I hope. [13:45] <malb_> good, reverting my stuff then [13:46] <grout> millster: Okay, so I have two different changes (this init fix and a to_simple function). Can I commit just *one* of them? [13:46] <mhansen> william_stein: http://sagemath.org:9002/sage_trac/ticket/630 [13:46] <grout> Does mercurial allow me to pick a hunk to commit, or do I have to commit all the changes in a file? [13:46] <william_stein> all the changes in a file. sorry. [13:47] <william_stein> But you can commit individual files. [13:47] <roed_> william_stein, ncalexan, dmharvey: I just skimmed through ell_rational_field. Just extracting the Lseries functions won't do all that much to shorten it. If we actually want to split it up, there are a bunch of classes of functions that we could split off: padic_height, padic_sigma, etc; functions related to the Tate-Shafarevich group and the BSD conjecture; functions related to various reduction properties (kodaira_type, etc); function [13:47] <millster> it's ok to commit both though, in this case, since they're both things that need to go in... [13:48] <grout> grr...oh well, I suppose that feature will come in time. That's one thing I like about git, svk, darcs, etc. [13:48] <ncalexan> roed_: I don't think it's important to shorten it. I do think it is important to make it more object oriented. I want SAGE to have a concept of an L-series, and that means an object. Do you agree? [13:49] <roed_> I do [13:49] <roed_> For l-series [13:49] <roed_> But not necessarily for some of the other ones [13:50] <roed_> And I do think that shortening it is a valid goal, if only so that it's easier to find and modify code there. [13:50] <ncalexan> Well, should the Tate-Sha group be an associated object, like the formal group? [13:50] <roed_> I think I like that idea [13:51] <william_stein> malb_ -- do hg_sage.pull() [13:51] <millster> grout: awesome idea on ticket 698 [13:51] <grout> Well, it certainly provides enough work to do... [13:51] <millster> grout: you should take a look at the new Maple, too [13:51] <millster> there's a lot of new stuff there [13:52] <grout> millster: I've been meaning to install it for a long time. I heard there were quite a few graph functions in there now. [13:52] <millster> also, i'm working on a graph generator to be included soon [13:52] <grout> I'm just really comfortable with Mathematica. [13:52] <dmharvey> #635: done, kind of. I've posted a patch. It passes all regular doctests, but for -long doctests a few weird things happen. I'm getting spurious segfaults, glibc realloc invalid size errors, sometimes. I'm only touching pretty high level python code so I have no idea why that is happening. [13:52] <grout> millster: graph generator? what do you mean? [13:52] <millster> do you mind sending me a patch with the to_simple and init fixes? [13:53] <millster> i mean an algorithm to quickly generate non-isomorphic graphs subject to some constraints [13:53] <grout> Yes, that's my next question: what should I do with it? post it to #716? [13:53] <dmharvey> roed_, wstein, ncalexan: the patch I just posted for #635 touches ell_rational_field.py, so please take it into account before doing anything else with that file. [13:53] <grout> millster: Nice...up to this point I've used nauty [13:53] <millster> for graph stuff, probably the best idea is to send it to me [13:53] <roed_> what did you do? [13:53] <mhansen> millster: I changed some stuff related to cyclic_permutations_ [13:54] <millster> mhansen - did something break? [13:54] <dmharvey> roed: some slight changes to padic_height related stuff, fixed some precision losses that had occurred with either chris wuthrich's changes or some padic changes [13:54] <roed_> ok [13:55] <mhansen> millster: No, I changed it to use the new CombinatorialClass interface that I wrote. It also handles the cases where there are duplicate elements in the list correctly. [13:56] <millster> just make sure that the graph classes pass doctests- there is some genus code that depends on that [13:56] <mhansen> Yeah, I changed those files and they pass the tests. [13:57] <dmharvey> #697: what's the status with the NTL rewrite? [13:57] <millster> sweet [13:58] <janwil> ok, it's midnight for me and I need to get up early tomorrow ... have a nice BD ... and maybe I will still meet some of you in the morning :) [13:58] <mhansen> Good night. [13:58] <mabshoff_> william_stein: could you merge #680? I need that one for Solaris 9. [13:58] <-- janwil has left this channel. [13:58] <mabshoff_> It isn't needed any more for Solaris 10, so I need to implement some workaround on the SCons level. [13:59] --> jaap has joined this channel (n=jaap@cc73571-a.emmen1.dr.home.nl). [13:59] <mabshoff_> But on Solaris 10 it ought to only print some warning.- [14:01] <grout> When you do hg_sage.bundle('blah'), does it take the last thing that was committed and bundle that? [14:01] <millster> not quite [14:01] <millster> it compares your version against the official version at sage.math [14:01] <grout> Aah, so you get _all_ my changes, then, right? [14:01] <millster> and bundles everything necessary to bring a copy of the official version up to speed with yours [14:01] --> malb has joined this channel (n=malb@host86-141-245-221.range86-141.btcentralplus.com). [14:02] <millster> correct, all your changes to the branch you've been working on [14:02] <grout> Okay, well, it's just these two changes, so that should be fine. [14:03] <grout> How do you want me to send this to you? [14:03] <mabshoff_> Okay, I am out. I have to leave for the airport in about 5 hours so it wouldn't be bad to catch [14:03] <mabshoff_> a little sleep. [14:03] <mabshoff_> If anybody could comment on #470, #718 & #719 which are all libpari related to memory [14:03] <mabshoff_> consumption. [14:04] <mabshoff_> I will read the logs in a couple hours, so see you. [14:04] <william_stein> cu. have a great trip to italy or wherever. [14:04] <millster> you can just e-mail it to me [14:04] <mabshoff_> Sorry I couldn't close any significant ticket tonight. [14:04] *** mabshoff_ is now known as mabshoff|away. [14:05] <grout> millster: I also changed to_(un)directed to be pass name, pos, and boundary, just like copy did. [14:06] <millster> awesome [14:06] <ncalexan> william_stein: I've attached a patch for 228, added a note, added [with patch], and changed it to 2.8.4.3. [14:06] <william_stein> awesome [14:06] <grout> I assume that that is correct behavior. [14:06] <millster> yeah [14:08] <grout> hmmm...how long is sage -t graph.py supposed to take? [14:09] <grout> millster: How come the digraph class uses "arc" instead of "edge"? I'm always forgetting that and getting mixed up. [14:10] <millster> testing graph.py should take about a minute [14:10] <grout> Especially since networkX uses "edge", so the initial option is "multiedges=True", but ever after it's "arc" [14:10] <millster> it's actually taken some work to enforce that too [14:10] <grout> enforce "arc" instead of "edge"? [14:11] <millster> yeah [14:11] <grout> It seems like it'd be more friendly and consistent to call everything an edge. [14:11] <millster> the original motivation was actually my first teacher for graph theory [14:11] <grout> ahh. [14:11] <millster> he was dogmatic about the distinction, so by default so was i [14:12] <grout> Well, it sure is confusing for me. They look the same (an ordered list in Python). [14:12] <grout> Can I add "edge" functions to DiGraph to either supplement the "arc" functions? [14:14] <-- malb_ has left this server (Read error: 110 (Connection timed out)). [14:15] <grout> Is there any way to run the doctests in verbose mode? I think something's not quite right and it's taking a long time for sage -t graph.py [14:15] <william_stein> sage -t --verbose graph.py [14:17] <william_stein> #228 -- ncalexan -- I'm importing that nnow. [14:19] <millster> by the way, if a doctest fails it will print to screen, so doctesting proceeding silently is good [14:19] <millster> also, if something is wrong, typically it is much faster [14:20] <-- ncalexan has left this server (Read error: 104 (Connection reset by peer)). [14:21] <millster> grout: you should do one thing at a time, but i'm not really opposed changing every "arc" to "edge" [14:21] <millster> don't write *more* functions that do the same thing, though [14:22] <grout> yes, I know...I won't do it today. I also don't want to step on someone's toes if they love the arc functions. [14:22] <millster> nobody has defended them to date [14:22] <millster> anyway, let's have that patch, yes? [14:23] <grout> Sure, I'll post it. The doctest is having a problem, though. [14:23] <grout> is_circular_planar isn't returning the right result. [14:24] <millster> one sec [14:24] <millster> i think that might be an unrelated failure [14:24] <grout> hmmm, all the doctests were passing before. [14:25] <grout> I figured it had something to do with "boundary" not being passed somewhere. [14:25] <millster> send me the patch and i'll take a look [14:25] <malb> wstein, I just dotested the NTL stuff it is all good, however: [14:26] <malb> devel/sage-ntl/sage/monoids/string_monoid_element.py [14:26] <malb> devel/sage-ntl/sage/interfaces/tachyon.py [14:26] <malb> devel/sage-ntl/sage/rings/number_field/order.py [14:26] <malb> failed [14:26] <malb> erm william_stein [14:26] <william_stein> malb -- do hg_scripts.pull() [14:28] <grout> millster: I posted the patch to #716 [14:28] <malb> william_stein: good, only number_field/order.py still fails [14:28] <malb> I won't bother for now, will put some work in LLL [14:28] <malb> #325 [14:28] <dmharvey> malb: REAL programmers have THREE trailing underscores [14:28] <mhansen> number_field/order.py fails for me as well [14:29] <malb> dmharvey yeah because they run Linux on a Macbook Pro == crappy drivers [14:29] <william_stein> malb do hg_sage.pull() [14:32] <malb> all good now [14:33] <grout> millster: sage -t graph_genus1.py fails for the nice_copy function now. [14:33] <millster> grout: i'm still building a 'pull' so i can take a look, hang on a sec [14:34] <boothby> +1 (to robertwb) [14:34] <robertwb> I think everything should be an edge and node (or vertex) [14:34] <millster> +1 to boothby for whatever he says next [14:34] <robertwb> are you reading my mind??? [14:35] * boothby agrees with robert. [14:35] <william_stein> irc is so much fun when you're all in the same room... [14:35] <grout> yeah...and in Iowa too. [14:35] <dmharvey> boothby how did you do that IRC thing [14:36] <mhansen> grout: Iowa? [14:36] <boothby> wha? [14:36] <boothby> OH! /me blablabla [14:36] * boothby blablabla [14:36] <dmharvey> ah [14:36] * dmharvey gets it [14:36] <grout> mhansen: yeah [14:36] [Error] boothby: Unknown command. [14:37] * boothby says hi [14:37] * dmharvey wonders whether one can reflexively /me [14:37] <mhansen> grout: Where in Iowa? [14:37] <dmharvey> nope [14:37] * william_stein picks up sword. [14:37] <grout> Iowa State U. [14:37] * dmharvey is already bored with this new toy [14:38] <malb> /me tries it too [14:38] <mhansen> grout: I'm originally from Waterloo, and have a brother who is a freshman at ISU. [14:38] <malb> mhh, my client doesn't do it [14:38] <dmharvey> huh? [14:38] <malb> escaped or something [14:38] <dmharvey> i thought you had figured out string escaping or something [14:38] <grout> mhansen: huh...is he taking calc? (like calc 2?) [14:39] <mhansen> grout: Nah, he's only in Calc I. He's not as fond of math as his older brother. I think he'll be taking that next semester though. [14:40] * millster verbs profusely [14:40] <grout> mhansen: that's great. Maybe I'll teach calc 2 next semester too. [14:42] <millster> grout: still waiting for stuff to build... [14:42] <grout> millster: I think the problem is that nice_copy in graph_genus1 depends on the copy function to forget the boundary. [14:42] <grout> I made a change so that copies of a graph keep the boundary. [14:42] <millster> i know, i can fix the problem once i'm done building [14:42] <grout> What's a boundary anyway? :) [14:42] <millster> a privileged subset of the vertices ;) [14:42] <roed_> How is the lambda series of an elliptic curve related to the l-series? [14:43] <grout> ahh...I figured that _every_ property ought to be preserved when making a copy, but apparently nice_copy doesn't think so. [14:43] <millster> nice copy was a quick fix to avoid exactly what you fixed [14:44] <millster> but yes, everything about the graph should be copied over, and g == h should check everything [14:45] <roed_> william_stein: How is the lambda series of an elliptic curve related to the l-series? [14:45] <grout> so does that mean that nice_copy is no longer needed? [14:45] <grout> millster: since nice_copy also changes the vertices to be consecutive integers, maybe a new function that relabels the vertices to some list is in order. Don't we already have that? [14:46] <millster> that can be factored out, yeah [14:46] <millster> just give me a moment [14:46] <grout> okay, sorry. [14:47] <william_stein> _hi_ [14:47] <grout> mhansen: what's your brother's name, in case I see him? [14:48] <mhansen> grout: Andrew Hansen [14:48] <grout> I'll keep my eyes open. [14:48] <mhansen> william_stein: Did you want someone to look over my combinatorics patch? [14:48] <william_stein> sure! [14:48] <william_stein> any volunteers? [14:48] <millster> me me me [14:49] <william_stein> I'm finishing up fixing some issues with Robert Bradshaw's patch and will look at yours some next. [14:49] <william_stein> But I'd love somebody else to look first. [14:50] <mhansen> I put a bundle on the trac server, but it's also at /home/mhansen/sage/ on sage.math [14:50] <millster> mhansen: #630? [14:50] <mhansen> millster: Yep -- that's the one. [14:50] <william_stein> what's the issue with "c interface to symmetrica"? [14:50] <millster> cool [14:51] <william_stein> What is symmetrica? [14:51] <william_stein> Do we need to make an spkg? [14:51] <mhansen> There's already one (but its optional at the moment). [14:51] <mhansen> It needs to be installed first. It's a software package for package for doing things related to the symmetric group. [14:52] <william_stein> of course. thanks. [14:52] <william_stein> Should we make symmetrica a standard spkg? [14:53] <millster> hmm, copy is still losing multiple edges [14:53] <mhansen> Yeah, I would like to. It is the backend for symmetric functions and Schubert polynomials. [14:53] <millster> sorry, hang on a sec [14:54] <william_stein> ok. it takes 30 seconds to build on sagemath.org [14:54] <millster> mhansen - anything about kazhdan lutztig poly's? [14:55] <mhansen> millster: For the symmetric group? [14:55] <william_stein> what does symmetrica depend on? [14:55] <millster> yeah, just out of curiosity [14:56] <mhansen> william_stein: I think just gcc. [14:56] <william_stein> on a scale of 1 to 10, how do you rank the quality of symmetrica? [14:56] <grout> millster: copy seems fine here. The code in the comment of #716 works great. [14:57] <millster> no, i was stupid [14:57] <mhansen> millster: I don't think it has that, but I believe I have some routines around for calculating them. [14:57] --> dfdeshom has joined this channel (n=dfdeshom@adsl-068-153-240-182.sip.int.bellsouth.net). [14:57] <dfdeshom> hey guys [14:57] <millster> grout: i see what you mean about graph.py taking forever to test [14:58] <william_stein> mhansen -- what is the license? [14:58] <william_stein> ah, public domain. [14:58] <mhansen> william_stein: 8. The last released version was a little while ago, but I just talked with the author in June, and he has his own CVS version that he's been working on. It is public domain. [14:58] <millster> it was 27secs before the patch, but now it seems to be taking forever [14:59] <mhansen> william_stein: He was interested in the SAGE interface for it since it is just a C library. [14:59] <william_stein> cool. [14:59] <mhansen> william_stein: Magma uses it for its symmetric functions. [14:59] <william_stein> ok, it's in. [15:00] <grout> millster: sage -t --verbose graph_genus1.py tells where the problem is, I think. [15:00] <grout> I like how william approves whatever is in Magma ;) [15:01] <millster> so all i have to do is wrap my code in molten rock? [15:02] <william_stein> could a few people type "sage -i symmetrica-0.2" and let me know if it builds for them? [15:02] <millster> grout: did you ever get testing graph.py to finish? [15:02] <grout> It just worked for me. [15:02] <grout> (symmetrica did) [15:02] <boothby> hey william -- I hear Magma is going to switch to a perl-like language. Can we do the same? [15:02] <grout> um, I vote for lua or ruby :) [15:02] <grout> millster: no, I killed it. [15:03] <millster> oy [15:03] <grout> adding graph.set_boundary([]) after graph.copy() in nice_copy doesn't seem to fix the problem. [15:03] <millster> what a mess [15:04] * grout bangs head against stone floor, in dobby-like fashion [15:04] <grout> sorry [15:04] <william_stein> mhansen -- how can Symmetrica be version "0.2" after 15 years?! [15:05] <william_stein> Or is the 0.2 something you made up? [15:05] <mhansen> It was my second version of the spkg. [15:05] <mhansen> I don't know if there is an official versioning scheme ;-] [15:06] <grout> Is there a way to examine the changes in a bundle? I'd like to see what I just applied from the combinat bundle. [15:06] <william_stein> hg_sage.incoming('foo.hg'), but this only works if done from a repo that doesn't have those changes [15:06] <william_stein> already applied. [15:06] <grout> oops. [15:08] <mhansen> millster: Here is an example of what the new combinatorics interface looks like. It's heavily inspired by MuPAD-Combinat. [15:08] <william_stein> mhansen, i've now officially included symmetric for the next release of Sage. [15:08] <mhansen> millster: http://wiki.sagemath.org/Combinatorics [15:08] <mhansen> Excellent [15:09] <millster> grout: why did you remove loops from the copy command? [15:10] <grout> I don't think we need them (and the doctests back that up). [15:10] <millster> ok [15:10] <grout> If a XDiGraph is passed, then the structure is set and we never look at the loops parameter. [15:10] <millster> nx takes care of it? [15:11] <grout> Everything except for boundary and pos is stored in _nxg, to my understanding. [15:11] <grout> We had to have them before because we were calling the superclass constructor, which defaulted to no loops. [15:12] <grout> (so we had to pass in the current status) [15:12] <grout> But please double-check everything in case I missed something. [15:12] <grout> (this is my first patch, after all :) [15:12] <millster> i'm getting very funny copy behavior [15:12] <grout> like what? [15:13] <millster> shallow copying [15:13] <grout> an example? [15:14] <millster> one sec [15:15] <millster> got it [15:16] <grout> an example or a fix? [15:16] <millster> both [15:16] <grout> yeah! [15:16] <grout> care to elaborate? [15:17] * millster begs for patience [15:18] <grout> sorry, sorry :) [15:19] <millster> sorry to keep you in suspense, i'm cleaning up the rest of the doctests - apparently, we were constructing two sage graph objects that pointed to the same networkx object [15:21] <grout> oops, I guess we should call "copy" in the copy functions...duh. [15:22] <millster> it's amazing how many doctests can break when you make such a small change [15:22] <william_stein> #228 -- excellent work ncalexan [15:23] <grout> millster: are you calling the networkx copy function in our copy function or our init function? [15:31] <roed_> ncalexan, william_stein: track 721 outlines a plan for splitting ell_rational_field [15:34] <grout> millster: I guess all of the tests that depended on to_directed or to_undirected to not pass the name fail, plus one with an extra space. Is that what you got? [15:35] <william_stein> roed_ -- i'll check it out shortly. [15:35] <roed_> ok [15:38] <william_stein> roed_ looks good to me. Robert Bradshaw is also looking the plan over. [15:39] <william_stein> mhansen -- gees that's a big patch! [15:39] <millster> grout: essentially, yeah [15:40] <mhansen> william_stein: Yeah, it feels a little weird calling it a 'patch' [15:40] <grout> millster: do you want to send me back a new patch (or please tell me somehow how to get it?) [15:40] <millster> still ironing out the kinks, but i'm almost done [15:41] <grout> mhansen: that's giganormous...I'd call it a quit at least :) [15:41] <grout> I man, quilt [15:41] <grout> I mean, quilt [15:41] <millster> grout: All tests passed! [15:41] <mhansen> Yay! [15:41] <grout> yeah! I presume that they're correct too :)... [15:42] <millster> that's another matter entirely [15:42] <grout> I really like the "new" feature that sage: H = G.subgraph([0,1,2]); H returns Subgraph of (Complete graph): Graph on 3 vertices [15:42] <grout> (the name indicates how you got the graph) [15:42] <millster> it was supposed to do that all along, and i couldn't figure out why it wasn't [15:43] <william_stein> mhansen -- you'll want to do some work to get the relevant autogenerated docs from your code into the reference manual, ok? [15:43] <william_stein> that can wait a little until things stabilize, though. [15:43] <william_stein> this means editing SAGE_ROOT/devel/doc/ref/ [15:43] <william_stein> mhansen -- all tests pass in combinat/ [15:43] <grout> millster: If you'd send me the patch, I'd love to do one more---the changing arcs to edges, if we're all unanimous on that :) [15:44] <grout> Of course, such a huge change probably requires approval from our supervisors... [15:44] <mhansen> william_stein: Great! [15:47] <millster> grout: check ticket 716 again [15:47] --> malb_ has joined this channel (n=malb@host86-141-245-221.range86-141.btcentralplus.com). [15:48] <millster> grout: if you're doing the arc to edge change, the only file you'll need to touch is graph.py itself [15:48] <millster> it should be as simple as a find/replace where you make sure you're not catching words like search [15:49] <millster> ps - consider it approved [15:50] <millster> grout: have you used hg_sage.browse() yet? [15:50] <grout> hmmm...I'm not sure. I don't think so. [15:50] <millster> it's great [15:51] <millster> you apply the bundle i posted, then do that, and your web browser will open up and you can see only what was changed [15:51] <grout> oh yeah, I've seen it, but not used it. [15:51] <mhansen> william_stein: I also have a patch for tut.tex. [15:52] <mhansen> I attached it to #630 [15:55] <grout> millster: um, I think we should call the copy in the init function, like networkX does. [15:55] <grout> so if g is a graph, calling Graph(g) makes a copy of g. [15:56] <grout> instead of calling the copy in the "copy" function. [15:57] <millster> that's not how it happens [15:57] <grout> I must be confused. [15:57] <grout> networkx_graph() returns a copy. [15:57] <millster> sage: G = Graph() [15:57] <millster> sage: G == Graph(G) [15:57] <millster> True [15:57] <millster> sage: G is Graph(G) [15:57] <millster> False [15:58] <millster> you mean we should use ._nxg.copy() instead of .networkx_graph()? [15:59] <grout> Yeah, but what if G is a _nxg? Then it's not copied in Graph(g) [15:59] <william_stein> mhansen -- interestingly the *old* partitions function is way faster than your new one...?? [15:59] <william_stein> old: [15:59] <william_stein> sage: time v=list(partitions(30)) [15:59] <william_stein> CPU times: user 0.03 s, sys: 0.00 s, total: 0.03 s [15:59] <millster> aha [15:59] <william_stein> new: [15:59] <william_stein> sage: time v=Partitions(30).list() [15:59] <william_stein> CPU times: user 0.46 s, sys: 0.02 s, total: 0.48 s [15:59] <millster> grout: now i get it [15:59] <-- malb has left this server (Read error: 110 (Connection timed out)). [16:00] <millster> so replace "self._nxg = data" with "self._nxg = data.copy()" twice? [16:01] <grout> hang on a sec, I got a phone call... [16:01] <malb_> william_stein: I've added some code to #325 [16:01] <william_stein> I'll take a look. [16:01] <malb_> It doesn't integrate pari yet but the pari function is callable from SAGE [16:02] <mhansen> Yeah, I haven't done any real optimization yet. It'll get there though. But, the new one provides an actual iterator so that you don't need to store all of them in memory at once. [16:02] <william_stein> the old one was an iterator. [16:02] <william_stein> I posted the code on trac. [16:02] <grout> millster: Yes, that was what I was thinking. [16:02] <william_stein> Maybe have both functions... [16:03] <grout> millster: and remove the .copy from the copy function. [16:03] <millster> sounds fair [16:04] <william_stein> #325 -- malb, looking at it now. [16:04] <william_stein> mhansen -- I think just including your code in the next Sage is a good idea. [16:04] <william_stein> It will be very helpful to get a lot of feedback. [16:04] <grout> millster: Of course, it's slower, though. For example, to_directed then makes a copy of a copy. [16:04] <william_stein> But I think you should send me a patch that puts the old partitions function back in too (as an alternative to Partitions(n).list()), [16:04] <william_stein> and similarly for other things you might have deprecated. ??? [16:05] <grout> millster: hmm...It might be better to have it the way you have it, even if it's not consistent with networkX [16:06] <william_stein> malb -- your patch is weird. [16:06] <millster> consistency with networkx is not one of my concerns- they do some things very silly [16:06] <grout> If g is a Sage Graph, then Graph(g) is a copy. [16:06] <william_stein> #325 -- It implements pari lll, but then implements lll over ZZ using ntl. [16:06] <grout> millster: If g is a networkX graph, then Graph(g) is a wrapper around that exact graph. [16:06] <malb_> yes [16:06] <malb_> exactly [16:07] <william_stein> Did you do timings and NTL always crushes PARI? [16:07] <grout> millster: That's how it works now with your patch, if I understand things right. [16:07] <malb_> no not at all [16:07] <mhansen> william_stein: I just see the partitions wrapping GAP (not an iterator). I can add back the old functions in combinat.py that I replaced. A lot of them are still there -- just wrapped in CombinatorialClass objects. [16:07] <malb_> I went for NTL first because I understood better what needs to be done [16:07] <millster> yes, the way it is now [16:07] <william_stein> so shouldn't the lll for mat over ZZ always have an option "algorithm = " that can also call PARI? [16:07] <william_stein> mhansen -- see trac #630. [16:07] <william_stein> The partitions function doesn't have anything to do with Gap. [16:07] <mhansen> william_stein: I just found the partitions generator. [16:07] <malb_> yes it should, but I might have to do that later [16:08] <malb_> it is not finished yet [16:08] <william_stein> It's from the cookbook. [16:08] <william_stein> ok, good. [16:08] <malb_> but the ticket could change to improve LLL [16:08] <grout> millster: I guess that makes sense, since people shouldn't deal with the underlying networkX object, so they won't have surprises, and we'll just be careful to make copies when we mean to make copies. [16:08] <william_stein> malb -- #325 -- good, i understand. [16:08] <william_stein> got it. [16:08] <william_stein> malb -- new ticket. [16:08] <william_stein> i'll apply and post #325 now. [16:08] <millster> the only reason someone is going to start playing aroung with networkx graphs is if they're pretty advanced [16:08] <malb_> okay, I gotta bail out for tonight that's why I am posting it already [16:09] <william_stein> I'm also posting mhansen's code, so peoplke will have to install symmetrica to do hg_sage.pull(). [16:09] <william_stein> ah, malb_ cu [16:09] <malb_> cu [16:09] <millster> grout: can you add something to the documentation about all this? specifying that the behavior is on purpose, why, and a docstring exemplifying it? [16:09] <millster> it's a pretty subtle point [16:09] <grout> millster: okay, let's do it the way the patch is now. Are we sure that there are no more problems with not copying when we mean to. [16:09] <-- malb_ has left this server (Read error: 104 (Connection reset by peer)). [16:10] <millster> all doctests pass, that's the best thing [16:10] <grout> millster: hmmm, then again, every other way of constructing the graph makes a copy. [16:11] <millster> i think we're fine [16:11] <grout> okay. [16:12] <millster> grout: can you document this decision? [16:12] <grout> I'm doing it now. [16:12] <millster> awesome [16:13] <grout> All of sudden I'm getting errors when doing sage -br. I just did a hg_sage.pull(). The errors come from "building 'sage.libs.flint.fmpz_poly' extension" [16:14] <grout> gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/grout/sage/sage-2.8.3/local/include/FLINT/ -I/home/grout/sage/sage-2.8.3/local//include -I/home/grout/sage/sage-2.8.3/local//include/python -I/home/grout/sage/sage-2.8.3/devel//sage/sage/ext -I/home/grout/sage/sage-2.8.3/local/include/python2.5 -c sage/libs/flint/fmpz_poly.c -o build/temp.linux-i686-2.5/sage/libs/flint/fmpz_poly.o -std=c99 -w [16:14] <millster> do sage -i flint-0.2.p2 [16:14] <grout> sage/libs/flint/fmpz_poly.c:30:19: error: flint.h: No such file or directory [16:14] <william_stein> grout -- you have to install flint. [16:14] <william_stein> And symmetrica in a few minutes. [16:15] <grout> okay, working better now. Thanks. [16:16] --> tornaria has joined this channel (n=tornaria@r190-0-137-63.dialup.adsl.anteldata.net.uy). [16:16] <grout> millster: Are you sure it's okay to completely break backward compatibility and change "arc" functions to "edge" functions? Shouldn't we at least include them for one more release, in a deprecated state? [16:17] <grout> Is there a way to mark a function as deprecated, so that it maybe prints out a warning each time it's used, but it still works? Seems like some scripting language does this (python?), and it's handy for the transition. [16:17] <millster> nobody will miss it [16:18] <grout> okay, okay. [16:18] <millster> i think it's a bit early to worry about backwards compatibility yet [16:18] <grout> hmmm...I should remember that---I already put SAGE code in my dissertation and a few papers... [16:19] <millster> just say what version you were using [16:19] <grout> I did. I'm glad william archives the versions. [16:20] <grout> Part of the reason for including the code was to give people a taste for SAGE---some examples of code. [16:21] <william_stein> the archives also on all of the mirror sites. [16:21] <william_stein> seriously though, stability of the interface to Sage will be a very important goal for Sage once there [16:21] <william_stein> are more users. [16:21] <william_stein> There are still probably < 1000 users. [16:22] <mhansen> william_stein: I made it so that Partitions(n).list() uses (a modifed version of) partitions. I'll include that with a patch restoring the old functions in combinat.py once the new stuff is ready to pull(). [16:23] <william_stein> it's ready to pull [16:23] <mhansen> sage: time v = Partitions(30).list() [16:23] <mhansen> CPU times: user 0.04 s, sys: 0.01 s, total: 0.04 s [16:23] <mhansen> Wall time: 0.04 [16:23] <william_stein> sweet! [16:25] <dmharvey> #528 progress report: things are starting to work. Already multiplying (2*x+4) by 3 is about 4x faster, just from improved overhead. Still a factor of 3 or 4 behind magma, to the extent that the comparison makes sense. [16:26] <grout> millster: Am I not understanding something? How come I'm getting false with the following? [16:26] <grout> sage: g = networkx.Graph({0:[1,2,3], 2:[5]}) [16:26] <grout> sage: G = Graph(g) [16:26] <grout> sage: H = Graph(g) [16:26] <grout> sage: G._nxg is H._nxg [16:26] <grout> False [16:27] <william_stein> what about G._nxg == H._nxg? [16:27] <grout> still false. [16:28] <grout> sage: G._nxg [16:28] <grout> <networkx.xgraph.XGraph object at 0x9d360ac> [16:28] <grout> sage: H._nxg [16:28] <grout> <networkx.xgraph.XGraph object at 0x9d3602c> [16:28] <grout> They appear to be two different networkx objects. [16:30] <william_stein> They *are* two differnet objects. [16:30] <millster> yeah, but they shouldn't be [16:30] <grout> I found it. I should do g=networkx.XGraph... [16:30] <millster> oh i see [16:31] <grout> sage: G._nxg is G._nxg [16:31] <grout> True [16:31] <grout> sage: G._nxg is H._nxg [16:31] <grout> True [16:31] <millster> subtlety on subtlety [16:32] <william_stein> dmharvey -- excellent. [16:33] <millster> grout: try True + Ture [16:33] <grout> error...Ture is not defined [16:34] <grout> ?? [16:34] <william_stein> sage: True + True [16:34] <grout> True+True==True [16:34] <grout> (two truths make a lie?) [16:35] <william_stein> mhansen -- is this right? [16:35] <william_stein> sage: a = Partitions(6) [16:35] <william_stein> sage: a.rank() [16:35] <millster> right, stop that, the lot of you! this has gotten entirely too silly! [16:35] <william_stein> <type 'exceptions.TypeError'>: rank_from_iterator() takes exactly 2 arguments (1 given) [16:35] <william_stein> a.rank? [16:35] <william_stein> nothing [16:35] <-- jkantor has left this server (Read error: 110 (Connection timed out)). [16:36] <mhansen> rank takes in a partition, and returns its position in the list. [16:36] <william_stein> i see. [16:37] <mhansen> sage: a = Partitions(6) [16:37] <mhansen> sage: a.rank([6]) [16:37] <mhansen> 0 [16:38] <mhansen> I still need to add documentation to CombinatorialClass. It provides default implementations for subclasses which don't provide a more specialized method. [16:38] <william_stein> mhansen -- why do you do: [16:38] <william_stein> sage: a = Partitions(6) [16:38] <william_stein> [16:37] <mhansen> sage: a.rank([6]) [16:38] <william_stein> [16:37] <mhansen> 0 [16:38] <william_stein> rank = rank_from_iterator [16:38] <william_stein> I mean, why do you do? "rank = rank_from_iterator"? [16:39] <mhansen> That's the default implementation. [16:39] <mhansen> Subclasses should override rank if there's a better algorithm for computing the rank of an object. [16:39] <william_stein> Yes, but why do you do "rank = rank_from_iterator"? [16:39] <william_stein> What does that accomplish? [16:39] <william_stein> Why not just define rank? [16:41] <mhansen> To detect when the method has been overwritten. [16:42] <william_stein> ah, I see. Interesting. [16:42] <william_stein> Wow, there's a lot of new code you've written. Over 20000 lines. Gees. [16:42] <mhansen> A lot is doctests though. [16:42] <mhansen> def iterator(self): [16:42] <william_stein> good. [16:42] <mhansen> if ( self.first != self.first_from_iterator and [16:42] <mhansen> self.next != self.next_from_iterator ): [16:42] <mhansen> return self.iterator_from_next() [16:42] <mhansen> elif ( self.last != self.last_from_iterator and [16:42] <mhansen> self.previous != self.previous_from_iterator): [16:42] <mhansen> return self.iterator_from_previous() [16:42] <mhansen> elif self.unrank != self.unrank_from_iterator: [16:42] <mhansen> return self.iterator_from_unrank() [16:42] <mhansen> elif self.list != self.list_from_iterator: [16:43] <mhansen> return self.iterator_from_list() [16:43] <mhansen> else: [16:43] <mhansen> raise NotImplementedError, "iterator called but not implemented" [16:43] <william_stein> ahhh [16:43] <william_stein> ok. [16:49] <grout> millster: is there a way to send you just the changes I just made? [16:49] <grout> (the doc changes_) [16:49] <millster> bundle [16:49] <millster> put it on trac, or e-mail it to me [16:52] <grout> okay, it's on trac. Do you want to take a look? [16:52] <grout> doctests pass for me. [16:52] <millster> looking now [16:53] <william_stein> fyi: If you do "sage -upgrade" right now, you'll get updated symmetrica and linbox. [16:53] *** mabshoff|away is now known as mabshoff_. [16:53] <mabshoff_> Hi, I am back. [16:53] <william_stein> This will be needed for hg_sage.pull() in a moment. [16:53] <william_stein> mabshoff_: are you about to go to the airport? [16:54] <millster> grout: looks good [16:54] <mabshoff_> william_stein: I gotta get ready in about 75 minutes [16:54] <william_stein> i'm trying out sparse mod p linear algebra from Linbox in Sage now, via Martin's patch. [16:54] <mabshoff_> I just released gmp 4.2.2 and mpfr 2.3 on Windows binaries. [16:54] <mabshoff_> I promised to do that and I woke up after 3 hours of sleep. [16:55] <mabshoff_> Now I will try to do the IML spkg and finish the LinBox teleconference summary. [16:57] <dmharvey> mabshoff_: I had always assumed you just never slept at all! How disappointing. [16:57] <mabshoff_> Well, maybe I have a team of gnomes work in shifts to pretend it is me :) [16:57] <mabshoff_> But I am just as suprised as you that I woke up that early, I had hope I would sleep 2 more hours. [16:57] <william_stein> mabshoffbot. [16:58] <mabshoff_> :) [16:58] <mabshoff_> Initially I wasn't sure if I had ignored my alarm and that it was way too late to catch the plane. [16:58] <mabshoff_> But that wasn't the case. [16:58] <mabshoff_> william_stein: #629 (DSage fixes) is ready to go int. [16:58] <mabshoff_> in [16:59] <mabshoff_> I also tested it on PPC 32 and it works fine. [16:59] <william_stein> excellent. [16:59] <mabshoff_> All doctests for 2.8.4.2 passed on PPC 32, but that was yesterday :) [16:59] <mabshoff_> And I talked to the admin at the univeritsy today. I might soon get a 1.8GHz G5 to play with. [17:00] <mabshoff_> i.e. 64 bit PPC Linux with 100 mbit hookup and me as root :) [17:00] --> jkantor has joined this channel (n=jkantor@cpe-76-180-115-46.buffalo.res.rr.com). [17:01] <william_stein> nice. [17:03] <mhansen> william_stein: I added patches to #630. [17:06] <william_stein> #629 -- applying now. [17:06] <mabshoff_> Coo, how about #680? [17:08] <william_stein> done. [17:08] <millster> grout: i just changed all arcs to edges [17:08] <grout> grr, I'm only half-way through. [17:08] <mabshoff_> ok, that needs a little work for Solaris 10 down the road, but I can fix that, too. [17:08] <millster> don't worry about it [17:08] <grout> But I'm also deleting redundant code and redundant docs [17:08] <grout> did you do that too? [17:08] <millster> aha [17:09] <millster> wait a sec [17:09] <grout> :) [17:09] <millster> i'll send you a bundle [17:09] <millster> i did arc -> edge but not redundant code [17:09] <millster> so you can do that part [17:09] <grout> I figured it was much easier to spot the redundant code while changing arcs to edges, so I didn't do the fast search/replace first. [17:09] <grout> basically a lot of the product functions are half the size now. [17:10] <-- dfdeshom has left this server (Read error: 113 (No route to host)). [17:10] <william_stein> mhansen -- i've applied the rest of #630 [17:10] <millster> grout: okay, go for it [17:10] <william_stein> mabshoff -- new iml spkg? [17:10] <william_stein> #656 [17:11] <mabshoff_> Working on it. Ran out of space on /home. fixing that right now. [17:11] <grout> thank goodness for emacs recursive editing while searching and replacing, as well as the block indenting/unindenting :) [17:12] <millster> grout: once you finish eliminating the redundancies, i think we should close ticket 716 [17:19] <grout> yeah, we've kind of gone beyond 716 now. [17:19] <grout> Which reminds me...I'll open up another ticket, but I ran into something a while ago. [17:19] <grout> I was reading in a graph6 string that had a backslash. [17:20] <millster> oh god [17:20] <grout> apparently Python intepreted the backslash to be an escape character. [17:20] <grout> Yeah, it was ugly. [17:20] <millster> ok - open a ticket, i'll deal with it later [17:20] <grout> I know now to use r" " [17:20] <millster> i know about this issue, but... [17:20] <grout> I think the graph6 code ought to generate an error when the string is too short. [17:20] <grout> you should be able to detect that. [17:21] <grout> (Brendan does, anyway, and my Mathematica code does) [17:21] <grout> or when the string is too long. [17:21] <millster> ? [17:21] <william_stein> MemoryError: too much memory [17:21] <grout> You know exactly how many bits you need from the first character of the graph6 string. [17:22] <millster> this is definitely a ticket for the future [17:22] <grout> Is that what the ? refers to? [17:22] <millster> there isn't much checking in the to/from graph6 stuff [17:22] <grout> Yeah, I noticed. [17:22] <grout> I didn't realize the backslash was an escape character until much later, when I realized my graphs were corrupt. [17:23] <grout> Well, they were still valid graphs, but they weren't the graphs I had put in. [17:23] <grout> (I thought didn't interpret escape characters, like in bash) [17:24] <william_stein> mhansen -- i'm looking at #691 now. [17:25] <william_stein> good. [17:25] <grout> I hope these changes from arc to edge don't affect a huge amount of stuff elsewhere in SAGE [17:26] <millster> i wouldn't worry about that [17:26] <william_stein> Try search_src('\.arc') [17:27] <mhansen> Heh, I used it in a couple of places ;-] [17:27] <william_stein> combinat/skew_partition.py: sage: dag.arcs() [17:27] <grout> Thanks, that's exactly what I needed! [17:27] <grout> (the search_src) [17:27] <william_stein> search_src and search_doc are your friends. [17:27] <millster> rather, i would worry about that [17:27] <william_stein> mhansen -- did you use it only in skew_partition? [17:28] <grout> Yup, I had a doctest failing, somewhere, something was using arc. Using search_src, easy as cake to find! [17:28] <millster> grout: do you still have my e-mail address? [17:28] <mhansen> I also use it in permutation.py. [17:29] <mabshoff_> william_stein: iml 1.0.1 vs 1.0.1.p6.spkg diff is about 420 lines. [17:29] <mabshoff_> I plan to send that to Arne & Clement, so hopefully they will do a 1.0.3 release with the added featurs. [17:29] <william_stein> cool. [17:29] <mhansen> You'll also want to search for "add_arc". [17:29] <mabshoff_> porvided you and malb release the changes officially which I assume will happen :) [17:30] <millster> "_arc" and "\.arc" should cover everything [17:30] <grout> what you do *not* want to search for is "search"...I can't believe how many times we used "search"! [17:30] <mabshoff_> I will just patch in the bits from 1.0.1->1.0.2 diff expect the new configure crap [17:30] <mabshoff_> because the used autoconf 2.61 vs. 2.59, so the diff is huge. [17:30] <mabshoff_> If it breaks I will fix it down the road :) [17:31] <mabshoff_> (and we will skip the update for now) [17:31] <grout> millster: I think I have your email from your email to the newsgroup. [17:32] <millster> i thought we had had correspondence before, but i can't find any messages [17:32] <tornaria> ? [17:32] <grout> oh yeah, something about a bug in the graph drawing code. [17:32] <grout> (the colors dictionary or something) [17:33] <grout> okay, all doctests pass with the arc->edge functions for the graph.py [17:33] <mhansen> Do you want me to posts patches for my stuff? [17:33] <millster> all doctests in graph.py, or all doctests everywhere? [17:34] <grout> no, just sage -t graph.py [17:34] <millster> because i already tested graph.py [17:34] <grout> (which required also changing the isomorphism file) [17:34] <millster> does this include removing redundancies? [17:34] <grout> yes. [17:34] <millster> sweet [17:34] <grout> I'll post a bundle right away. [17:34] <millster> mike h's code too? [17:34] <grout> uh, no, just graph.py and the NICE file. [17:35] <millster> ok [17:35] <grout> okay, it's up on #716. [17:35] <grout> Do we wait to close #716 until it's been officially integrated into the main SAGE? [17:35] --> tclemans has joined this channel (n=Miranda@68.178.77.126). [17:36] <tclemans> I'm Timothy Clemans Seattle, WA Currently in Vancouver, Washington [17:36] <william_stein> grout: yes. [17:36] <william_stein> hi tclemans. [17:37] <tclemans> working on #643 [17:38] <grout> okay, I'll leave it to others to close 716 whenever is proper. [17:39] <mabshoff_> We should really spend some time on all the open notebook issues. [17:39] <grout> I've got to run, but thanks everyone for being so friendly and helpful. This has been a great experience---so good that I put off everything else that I should have done today! [17:39] <tclemans> #643: my example pages do not use table at top but divs is it best to rewrite top that way or use current table? i know that current table has nested tables and when i made an id for it js did not find true height of it [17:40] <mhansen> grout: See ya! :) [17:40] <mabshoff_> by [17:40] <grout> quit [17:40] <william_stein> by [17:40] <grout> grrr...need to figure out how to quite irss [17:40] <-- grout has left this server ("leaving"). [17:41] <mhansen> I added at patch on #716 for my code. [17:42] <millster> grout: one comment [17:42] <millster> the distinction between vertex and node [17:42] <mabshoff_> he is gone :( [17:42] <millster> i think of vertices as the points of graphs [17:42] <millster> oh [17:42] <millster> right [17:42] * millster grins sheepishly [17:43] <millster> for those of you listening, i think of nodes as parts of the search tree in isomorphism testing... [17:43] <mabshoff_> Well, he might read the log at some point :) [17:43] <mhansen> millster: http://math.univ-lyon1.fr/~ducloux/coxeter/coxeter3/english/coxeter3_e.html does KL polynomials for arbitrary Coxeter groups. [17:44] <millster> i was aware of this program, but thanks [17:45] <millster> mhansen -- can you do me a favor? [17:45] <mhansen> I have code to do it for S_n, I just need to track it down. [17:45] <mhansen> Sure. [17:47] <millster> i'm about to pull all the new stuff together [17:47] <tclemans> #643: my current example page is http://tclemans.nonlogic.org/snb/notebook-top-091407-0310.html [17:47] <millster> there will be a few issues with arc -> edge stuff [17:47] <millster> but i am now waiting for a 15 minute build... [17:48] <-- robertwb has left this server. [17:50] <-- jkantor has left this server ("leaving"). [17:53] <mhansen> Be right back. [17:53] <-- mhansen has left this server ("Leaving"). [17:56] <tclemans> #643: it would be nice if the notebook css was tidied http://floele.flyspray.org/csstidy/css_optimiser.php [17:57] <tornaria> I'm looking at #710 [17:57] --> mhansen has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [17:58] <millster> still building [18:02] <-- tclemans has left this server ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org"). [18:09] <mabshoff_> william_stein: new IML spkg attached to #656 [18:09] <mabshoff_> passes sage -ba, still waiting on .testall [18:09] <mabshoff_> -testall obviously. [18:10] <mabshoff_> But it is a hack, once your's and malb's changes are merged back in we should rebase against 1.0.3 [18:10] <william_stein> #656: awesmoe [18:10] <mabshoff_> I am sending an email about the diff 1.0.1.p6 vs. vanilla 1.0.1 now. [18:11] <mabshoff_> The diff is at http://sage.math.washington.edu/home/mabshoff/iml-1.0.1-1.0.1_sage-diff [18:11] <millster> mhansen -- i'll run a sage -t on the combinat module, is there anything else i should check? [18:11] <mabshoff_> about 420 lines, so it isn't too bad to merge back in manually. [18:12] <mhansen> millster: Nope -- that should be enough. [18:12] <millster> easy enough [18:13] <tornaria> on #710 [18:13] <tornaria> seems a bit nasty, not sure how to fix it. [18:14] <william_stein> yep. [18:14] <william_stein> it's been there for a long time. [18:14] <william_stein> but nobody reported it. [18:14] <william_stein> at least it is easy to replicate. [18:15] <tornaria> thing is [18:15] <mabshoff_> Okay, IML email is out. [18:15] <tornaria> I wrote replacements for _sig_on and _sig_off [18:15] <william_stein> mhansen -- your symmetric package won't build on osx :-( [18:16] <tornaria> They are called "_pari_sig_on" and "_pari_sig_off" [18:16] <william_stein> I made a new version of it, by the way vesion 0.3. So use that instead of whatever you have... [18:16] <tornaria> But they are supposed to be run in pairs. [18:17] <mhansen> william_stein: Your package fixes the error on OSX? [18:17] <tornaria> However, functions in gen.pyx call _sig_on (which is somehow rewritten as _pari_sig_on) but don't call _sig_off [18:17] <tornaria> Somewhere it is called implicitly. [18:18] <william_stein> not yet. [18:18] <william_stein> I just discovered the error. [18:18] <william_stein> I'm working on fixing it. [18:18] <william_stein> I hope symmetrica works on os x! [18:18] <william_stein> P.new(...) calls _sig_off. [18:18] <william_stein> P.new_gen [18:18] <tornaria> Maybe it's not being rewritten as _pari_sig_off [18:18] <tornaria> Will check... [18:19] <william_stein> Yep. it calls _sig_off! [18:20] <william_stein> but that shouldn't matter, since you make _pari_sig_off and _sig_off the same in pari_err.pxi [18:20] <william_stein> It's line 5595, by the way... [18:22] <tornaria> yes.. the gen.c is correct.. :( [18:23] <tornaria> misc.h defines _pari_sig_on and _pari_sig_off [18:24] <tornaria> it's roughly _sig_on and _sig_off with an extra pair of _pari_catch and _pari_endcatch [18:24] <tornaria> the latter should set the signal handler and reset it resp. [18:24] <tornaria> defined in pari_err.h [18:24] <tornaria> (I believe stolen from gp code) [18:24] <william_stein> idea: let's just try it with the classical _sig_on / _sig_off and see if the error still happens. [18:25] <william_stein> It'll be a good test. [18:25] <william_stein> ... trying now. [18:25] <william_stein> mhansen -- i got it to build on os x. [18:25] <tornaria> s/signal handler/pari error handler/ [18:25] <mhansen> william_stein: Excellent -- what was the issue? [18:26] <tornaria> ok, I'll do that. [18:26] <william_stein> http://sagemath.org/packages/standard/symmetrica-0.3.1.spkg [18:26] <william_stein> malloc.h isn't in /usr/include or the standard include path on osx. had to add a -I to the makefile. [18:28] <william_stein> tornaria that didn't work :-( [18:28] <tornaria> malloc should be defined in <stdlib.h>, isn't it? [18:29] <mhansen> william_stein: symmetrica-0.3.1.spkg builds fine for me. [18:29] <tornaria> Are you sure it did recompile? I have to touch lots of files (still compiling) [18:29] <tornaria> (I probably touched some .pxd files that forced too much to be recompiled) [18:29] <william_stein> there are a lot of mallocs on os x (and my machine): [18:29] <william_stein> bsd:~ was$ locate "/malloc.h" | wc -l [18:29] <william_stein> 16 [18:30] <tornaria> I guess gen.pyx should be recompiled at least. [18:30] <william_stein> All I did was replace the line that includes pari_err.pxi with including interrupt.pxi in gen.pyx. [18:30] <william_stein> So only gen.pyx must be recompiled. [18:30] <tornaria> yep... [18:31] <tornaria> I changed misc.h and recompiled lots of stuff, but still SEGV [18:32] <tornaria> at least I'm not to be blamed... :) [18:32] <mabshoff_> william_stein: -testall passes with the new IMP spkg on sage.math [18:32] <tornaria> (for the pari_catch stuff, I mean) [18:33] <mabshoff_> there were some failures in one of the tex files, but those were related to algebra [18:33] <mabshoff_> In const.tex [18:33] <william_stein> i've tested it some too. [18:33] <william_stein> it's in. [18:33] <mabshoff_> But I haven't updated since the initial build about 8 hours or so ago. [18:34] <mabshoff_> cool [18:34] <william_stein> close it. [18:34] <mabshoff_> will do [18:34] <mabshoff_> I ticket a day ... [18:35] <dmharvey> mabshoff: are you on a plane now? [18:35] <mabshoff_> not yet, about to leave in 10 minutes. [18:35] <mabshoff_> And I am going by train first, then two short hops Düsseldorf->Zürich, Zürich->Milano. [18:35] <dmharvey> heh..... so soon we get to see you simultaneously fly, code, and sleep [18:36] <mabshoff_> Maybe, I have to work on the simultaneous. [18:36] <dmharvey> well I can press two keys on my keyboard at the same time [18:36] <mabshoff_> :) [18:37] <mabshoff_> #656 is closed. [18:38] <mabshoff_> I would like to hear William's opinion on #718 and maybe #719 [18:38] <mabshoff_> I got 10 more minutes :) [18:39] <mabshoff_> #672 and #673 should also be easy to fix, it seems Solaris prints NaN instead of nan and inf vs. Infinity [18:39] <william_stein> I totally agree with #718. [18:39] <william_stein> Though one has to be very careful with state and precision. [18:39] <mabshoff_> okay, I assume you just have to import the right instance [18:39] <mabshoff_> and use that. [18:40] <mabshoff_> In other places of the code they do use the same pari instance. [18:40] <william_stein> no on #719. [18:40] <mabshoff_> ok [18:40] <william_stein> Lots of pari is unusable with < 100MB stack. [18:40] <william_stein> And it's a *serious* pain to have to do it randomly in the middle of computations. [18:40] <mabshoff_> really? That sucks. [18:40] <william_stein> PARI doesn't automatically double the stack. [18:40] <william_stein> The pari memory system is absolutely terrible. [18:40] <mabshoff_> Well, but the doubling of the stack past 512MB seems crazy [18:41] <mabshoff_> I can second that, I actually looked at some of the code and oooooooooooooooooooh [18:41] <william_stein> Usually when asked about PARI and memory, the response on the mailing list is "just allocate a 2GB stack" [18:41] <mabshoff_> lol [18:41] <mabshoff_> Maybe it is time for pari 3 with a sane memory model. [18:41] <dmharvey> yeah but it saves valuable cycles at very low levels [18:41] <mabshoff_> Well, but that mode is so '60s [18:41] <dmharvey> actually maybe that's not true [18:42] <dmharvey> hmmmmmm [18:42] <mabshoff_> stack allocation sucks. [18:42] <mabshoff_> slab allocators are much better and I believe their garbage collection might hmm, [18:42] <mabshoff_> let's say can be improved. [18:42] <mabshoff_> Valgrind croaks on if it busts its heap, so I am sure there are some gremlins in there. [18:43] <mabshoff_> Well, gotta go. [18:43] <mabshoff_> Should be online at some point on Friday, but only dial up, so that will suck [18:43] <mabshoff_> cu [18:43] <-- mabshoff_ has left this server (Remote closed the connection). [18:43] <william_stein> cu [18:45] <william_stein> changing the pari memory model is nearly impossible. Seriously. [18:45] <william_stein> I wouldn't dare. [18:45] <william_stein> It means rewriting essentially every function in the entire library. [18:49] <tornaria> on pari stack: [18:50] <tornaria> if you allocate a very large stack, but don't use it, it won't actually use real memory [18:50] <tornaria> (hopefully you are 64bits where virtual memory space is big) [18:51] <tornaria> however, pari functions don't know about using the stack conservatively. [18:52] <tornaria> I.e. pari functions will use plenty of memory in the stack (tipically half of the available space when they are invoked) [18:53] <tornaria> So, memory will be trashed, and then all the stack becomes real memory (well... or trash in the disc) [18:54] <tornaria> The way GP addreses this is: the stack is reallocated every input [18:55] <tornaria> I.e. when eval an expression, pari stack is allocated, expression is eval'ed using the stack, result is copied to heap, the stack is freed. [18:55] <tornaria> (or so I believe) [18:56] <william_stein> mhansen -- are you around? [18:59] <mhansen> Yeah [18:59] <william_stein> did you doctest partition.py ? [19:00] <mhansen> I still have some stuff left to do in it. [19:00] <william_stein> didn't think so :-) [19:00] <-- mhansen has left this channel ("Leaving"). [19:00] --> mhansen has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:00] <william_stein> come back [19:01] <mhansen> Wait, are you talking about after a patch? [19:01] <william_stein> Yes. [19:01] <william_stein> it broke some things. [19:01] <william_stein> we just fixed them. [19:01] <william_stein> the problems were all in interator(...) [19:03] <mhansen> That's weird. [19:03] --> tclemans has joined this channel (n=Miranda@68.178.77.126). [19:03] <william_stein> maybe you checked in before finishing and sent us a broken patch. [19:03] <tclemans> ok i'm back from dinner [19:04] <tclemans> any news on notebook bugs I know that #228 was fixed thanks to Nick [19:04] <mhansen> Hmm... possibly. I remember doctesting after that and testing it interactively. Is it taken care of now or do you want me to make some changes? [19:05] <william_stein> it's taken care of. [19:05] <william_stein> nothing new on the notebook [19:05] <mhansen> Sorry about that. [19:06] <william_stein> np -- it took 1 minute to fix. [19:07] <millster> ok, bye everyone [19:07] <william_stein> bye [19:07] <tclemans> do you want to fix #643 with the current table and nested tables at top? [19:07] <-- millster has left this server. [19:12] --> mhansen_ has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:12] <-- mhansen has left this server (Read error: 104 (Connection reset by peer)). [19:13] <tclemans> why is slide_controls in html? I don't think it is enabled in the twisted notebook [19:16] <boothby> You can cut that out. [19:16] <-- mhansen_ has left this server (Read error: 104 (Connection reset by peer)). [19:16] --> mhansen has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:19] <tclemans> apparently in the notebook css there is a bunch of stuff that isn't used in the notebook anymore like "top_control_bar" [19:24] --> mhansen_ has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:24] <-- mhansen has left this server (Read error: 104 (Connection reset by peer)). [19:29] <dmharvey> #528: patch uploaded [19:29] <william_stein> cool. [19:29] <dmharvey> #528: still pretty ugly, and I'm not convinced it passes all doctests yet, but it's a start [19:29] <dmharvey> I should go [19:29] <dmharvey> I was just getting that in before I went off to bed [19:29] <william_stein> ok. [19:29] --> ncalexan has joined this channel (n=ncalexan@pv109051.reshsg.uci.edu). [19:30] <william_stein> Is this something I should put into SAGE now? [19:30] <william_stein> Is it safe? [19:30] <william_stein> Should I wait? [19:30] <william_stein> It sounds like it. [19:30] <dmharvey> I don't know [19:30] <dmharvey> basically, I got all doctest passing, except for the ones currently failing in the repository :-) [19:30] <dmharvey> but I didn't check too carefully which were which [19:30] <william_stein> ah, ok. [19:31] <william_stein> so i could maybe do that, or wait a day for you to? [19:31] <dmharvey> either way [19:31] <william_stein> cool. [19:31] <william_stein> I'll post a remark to trac if I merge yur patch in now. [19:32] <dmharvey> ok [19:32] <dmharvey> bye [19:32] <-- dmharvey has left this channel. [19:32] <ncalexan> 660: has a patch, which looks fine (it's trivial) but applier should add doctests. [19:33] <william_stein> i'll take a look [19:34] <william_stein> #660 -- no doctests... [19:34] <william_stein> but it's right iff original is. [19:34] <william_stein> want to add a few doctests too it? [19:35] <william_stein> i'll do it. [19:36] <william_stein> #666 -- i'm looking at it now. [19:37] <william_stein> tornaria -- any ideas about that very nasty pari c-library bug issue? [19:37] <tornaria> I'm looking at it... had to sort out some issues at home (kids...) [19:38] <william_stein> :-) [19:38] <william_stein> I think that is the most interesting serious bug of the day. [19:38] <william_stein> ncalexan did you see it? http://trac.sagemath.org/sage_trac/ticket/710 [19:38] <william_stein> Very unprofessional. [19:39] <tornaria> Maybe one should try an old version of sage to see if it's still there... Has someone tried? [19:39] <william_stein> I tried 2.7 and it was there. [19:39] <tclemans> #643: I'm putting a div right around the main tables at the top [19:39] <william_stein> It would be wise to try 2.0 or so. [19:39] <ncalexan> 710: urgh. [19:39] <william_stein> I don't have any ancient sage's around... [19:40] <william_stein> But they are easy to find on sage.math.washington.edu in people's home directories :-) [19:40] <william_stein> #725 -- burcin, I'm looking at your patch... [19:40] <burcin> it's very simple.. [19:41] <william_stein> nice. great work! [19:42] <burcin> I can't figure out where the big one in #621 comes from.. [19:43] <mhansen_> 710: It does it on 2.5.3 (which I think is the oldest I have around) [19:43] <burcin> there's another simple memleak fix in 559.. but that doesn't close any bugs.. [19:44] <william_stein> #621 is nasty. [19:44] <william_stein> #710 -- i want to fix that damn thing. [19:45] <william_stein> It is now the one open ticket in http://trac.sagemath.org/sage_trac/milestone/sage-2.8.4.3 [19:45] <william_stein> And it is nasty. [19:45] <william_stein> #710 -- I'm going to work on it right now. If anybody has any ideas, let me know. [19:45] <william_stein> One thing I did figure out is that if one does pari('factor(2^997-1)'), then press control c, [19:45] <william_stein> then import the lines about getting signals from sage/all.py, then SAGE does *not* segfault. [19:46] <tornaria> I'm compiling 1.0 and 2.0 [19:46] <william_stein> when the following control-c is pressed. Instead it ignored it. [19:46] <tornaria> The one thing that happens to me is this: [19:46] <tornaria> sage: gp.eval('factor(2^997-1)') [19:46] <tornaria> Interrupting GP/PARI interpreter... [19:46] <tornaria> Interrupting GP/PARI interpreter... [19:47] <tornaria> I.e. if I try gp.eval(...) thing (without doing the factor(..) first) [19:47] <tornaria> I press CTRL-C (ONCE) and I get that message twice [19:47] <tornaria> but nothing stops [19:47] <william_stein> For me it stops fine. [19:47] <tornaria> now if I press CTRL-C again (even after some time) then it stops with KeyboardInterrupt [19:47] <william_stein> All it does is send the control-c on to pari. [19:48] <william_stein> For me it stops right off. [19:48] <william_stein> I'm using 64-bit linux. [19:48] <tornaria> I'm 64-bit debian [19:48] <william_stein> #710 -- it is *not* present in sage-1.4 [19:48] <william_stein> I found a working version in /home/aklemm/sage-1.4 on sage.math [19:49] <tornaria> good.. [19:49] <william_stein> so hmmm. [19:49] <william_stein> that was a long long time ago though. [19:49] <tornaria> I wonder whether we should try to bisect the bug, or try to fix it by pure thought... :-) [19:49] <william_stein> But that is a definite hint. [19:49] <tornaria> I'm compiling 2.0 [19:49] <tornaria> (will abort 1.0) [19:50] <tornaria> (I'm abusing sage.math, anyway) [19:52] <william_stein> 1.4 used your pari_err code. [19:52] <william_stein> but I think martin albrecht totally rewrote interrupt.pxi to be vastly faster after sage-1.4. [19:52] <william_stein> So that's probably where the problem comes from. [19:53] <william_stein> I'll try using the old interrupt.pxi in sage-2.8* [19:53] <william_stein> (actually interrupt.h) [20:00] <william_stein> tornaria -- do you get the segfault with the newest version of Sage? [20:00] <william_stein> I just tried reverting all the interrupt stuff *just* for the pari c library. [20:00] <tclemans> #643: after I resolve the conflict with my example page js and the js from the notebook I should be able to easily fix this and make a patch [20:01] <william_stein> Interestingly everything *now* works -- i.e., this "fixes" #710 -- but I do have to hit control-c twice to interrupt [20:01] <william_stein> the gp.eval(...) line. [20:01] <tornaria> mmm... [20:01] <william_stein> But only the *first* time. [20:02] <tornaria> The _sig_on // _sig_off don't seem to be reentrant... are we sure they are not used nested? [20:02] <william_stein> then the first interrupt works. [20:02] <burcin> there is a comment in the new interrupt.h.. [20:02] <tornaria> (I mean, they use a global _signal ) [20:02] <william_stein> they *should* never ever be used re-entrant. [20:02] <william_stein> But that could be a problem. [20:02] <burcin> which says that if these _sig_{on,off} are not in pair, the program will segfault. [20:03] <tornaria> (actually, the pari_sig_on are also NOT reentrant, so...) [20:03] <william_stein> They are always in pairs surrounding pure C code that should never raise exceptions, etc. [20:03] <tclemans> #643 http://tclemans.nonlogic.org/snb/092007.html just div around head tables little change to css and some js [20:03] <william_stein> note that reverting to the older implementation of interrupt.* does fix the problem. [20:03] <william_stein> This must tell us something. [20:03] <burcin> but one can always interrupt the c code.. as in this case.. [20:04] <mhansen_> tclemans: I get a horizontal scroll bar on that HTML file. [20:05] <burcin> hmm.. where do I get an old version of that file? [20:05] <-- boothby has left this server (Read error: 110 (Connection timed out)). [20:06] <mhansen_> tclemans: Right, but there is a horizontal scrollbar for the worksheet area for me. [20:06] <mhansen_> tclemans: I didn't know if that's supposed to be there. [20:09] <mhansen_> tclemans: Weird, I guess I just never noticed it in the current notebook before. [20:12] <mhansen_> #726 [20:15] <mhansen_> It depends whether or not the file you were working on since the last upgrade changed. [20:15] <mhansen_> hg_sage.pull() [20:15] <william_stein> regarding #710, I think I will just revert the interrupt handler to the old version and [20:15] <william_stein> get martin to try to fix the problem. [20:15] <william_stein> He was the one to totally rewrite the handler, so he might best be able to fix the problem.. [20:15] <mhansen_> But, for the current code you get with hg_sage.pull(), you may need to install some extra packages ( flint and symmetrica ?) [20:16] <william_stein> Do "sage -upgrade". [20:19] <tornaria> william: ok on #710 [20:21] <william_stein> functionally the old and new interrupt code are supposed to be the same. The difference is that [20:21] <william_stein> the old code is faster. [20:21] <william_stein> I mean -- the new code is faster. [20:21] <tornaria> I know. The old code sets the signal handler each time. [20:21] <tornaria> that is slow. [20:21] --> boothby has joined this channel (n=boothby@D-69-91-159-227.dhcp4.washington.edu). [20:21] <tornaria> but maybe pari is playing with the signals somehow? [20:22] <william_stein> it shouldn't, but it's definitely possible. [20:22] <william_stein> that could cause a problem like we see. [20:22] <william_stein> It would be good to isolate things, etc. [20:22] <william_stein> I wonder if it's just control-c or other things that trigger the problem? [20:23] <william_stein> also, is it really related to expect? [20:24] <william_stein> pari('1/0') [20:24] <william_stein> then everything is messed up or seg faults. [20:24] <tornaria> uh... [20:25] <william_stein> even in sage-1.4 after pari('1/0') the gp.eval('factor(2^997-1)') afterwards would hang. [20:26] <mhansen_> Yeah, email them to me at mhansen@gmail.com [20:27] <tornaria> mmmm.. [20:27] <tornaria> Is it an option that CTRL-C in gp.eval('factor(2^997-1)') is messing things and maybe longjmp'ing to the setjmp in pari('1/0') ? [20:27] <tornaria> or something like that... [20:28] <william_stein> gp.eval should have absolutely nothing at all to do with gen.pyx. It's pexpect interface to a separate process. [20:28] <william_stein> But -- what your suggesting is probably exactly what is actually happening. [20:28] <william_stein> I.e., that is what would happen if _sig_on were called twice say. [20:29] <tornaria> yep [20:29] <tornaria> or the signal handler is called before _sig_on (somehow) [20:29] <tornaria> Or after the last _sig_on has run out of scope. [20:30] <tornaria> (so its process stack is invalid) [20:30] <william_stein> if you do pari('factor(2^997-1)') repeatedly you can interrupt it over and over and it works fine. [20:30] <william_stein> Which suggests the signal handler has been set to the one for gen.pyx and not changed. [20:31] <william_stein> what I don't understand is why the problem only appears when using expect. [20:32] <william_stein> gonzalo -- try this. [20:32] <william_stein> tornaria -- try this. [20:32] <william_stein> Do pari('factor(2^997-1)'), then control-c [20:32] <william_stein> Then type "get_sigs()" [20:32] <william_stein> Then things work fine again. [20:32] <ncalexan> william_stein: you could alter the _sig_on, _sig_off code to tell if you it is being called twice, just for testing. [20:32] <william_stein> good idea. how? [20:33] <ncalexan> A global variable that counts up and down? [20:33] <ncalexan> I wasn't thinking anything fancy, just a quick hack. [20:33] <ncalexan> It's just a few lines of cython, if I recall. [20:33] <william_stein> good idea. [20:33] <tornaria> Can we print from _sig_on / _sig_off ? [20:34] <william_stein> where are they defined these days? [20:34] <ncalexan> For debugging, no reason not to. [20:35] <burcin> the function that handles sigint seems to be the same, before and after pari('factor(...)') [20:35] <william_stein> c_lib/interrupt.h [20:35] <tornaria> Another idea: have a sigsetjmp somewhere as close to main as possible, copy that jmp_buf to _signals.env in _sig_off [20:35] <william_stein> burcin -- that can't be. [20:36] <burcin> I'm missing something.. [20:36] <tornaria> (so, siglongjmp'ing from outside _sig_on/_sig_off pair will jump to a predictable place. [20:36] <burcin> signal.getsignal(2) should give you the handler.. no? [20:36] <william_stein> it might only be Python's view of the signal. [20:37] <william_stein> I.e., I'm not sure that it is necessarily right. [20:37] <william_stein> by the way, typing this is enough, since this just calls pari immediately: [20:37] <william_stein> sage: factor(2^997-1) [20:38] <mhansen_> tclemans: Yeah, I'm doing the patches now. [20:40] <tornaria> For the record: there seems to be a potential race condition in interrupt.h (although I don't think it is causing the problem) [20:40] <tornaria> If I understand correctly, the _signals.mpio = 1+2 assignment tells the signal handler to use longjmp. [20:41] <tornaria> however, the sigsetmp is issued *after* that... It should be the other way around, I thin. [20:41] <william_stein> why? [20:41] <mhansen_> william_stein: I get this now with symmetrica-0.3.1 /usr/bin/ld: /opt/sage-2.8.3.rc3/local//lib/libsymmetrica.a(boe.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC [20:41] <tornaria> Because if a signal is triggered between _signals.mpio = 1+2 and sigsetmp(_signals.env,1) [20:41] <william_stein> tornaria -- i get it. [20:41] <william_stein> That could definitely happen. [20:42] <tornaria> etc [20:42] <william_stein> i see. [20:42] <tornaria> (very unlikely, and #710 is too deterministic) [20:42] <william_stein> But on the other had, if you did it the other way around, wouldn't it be possible that a signal would cause a jump to the wrong place? [20:43] <william_stein> No -- since _sig_on/_sig_off can't be nested. [20:43] <tornaria> exactly. [20:43] <william_stein> and sigint would use the Python signal handler. [20:43] <tornaria> The assumption is that _signals.mpio = 0 at time of _sig_on [20:44] <william_stein> It's tie to do nick's suggestion. [20:44] <mhansen_> william_stein: -fPIC is missing from make.unix for symmetrica-0.3.1 [20:44] <william_stein> is it needed? [20:45] <mhansen_> Yeah, I get this error without it: [20:45] <mhansen_> I get this now with symmetrica-0.3.1 /usr/bin/ld: /opt/sage-2.8.3.rc3/local//lib/libsymmetrica.a(boe.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC [20:45] <william_stein> ok, i'll add it in. [20:45] <mhansen_> Did you remove it for the OS X issue? [20:46] <william_stein> sage -i symmetrica-0.3.2 [20:46] <william_stein> I didn't realize it got removed. I think I modifed make.unix in src/ then copied that to the patches directory, [20:46] <william_stein> hence overwriting your patched version of it. [20:47] <mhansen_> Oh, I see. [20:47] <william_stein> What else did you do to it? [20:47] <mhansen_> Just that. [20:47] <william_stein> I'm testing the build right now. [20:48] <mhansen_> I guess I also added -O3 [20:48] <mhansen_> 0.3.2 worked for me. [20:49] <william_stein> I've added -O3 for 0.3.3. [20:49] <tornaria> (_sig_on)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_on) [20:49] <tornaria> This is JUST starting up sage... [20:50] <william_stein> what does that factor thing do!?!?!! i can't wait. [20:50] <tornaria> you can already see a nested _sig_on/_sig_off right before the prompt. [20:50] <william_stein> sh87)(*&t! [20:50] <mhansen_> tclemans: What's the bug number? [20:50] <tornaria> there are at least a couple more. [20:50] <tclemans> mhansen_: 643 [20:51] <tornaria> Do you know how to obtain the current instruction pointer from C? [20:51] <tornaria> (i.e. I want to fprintf(stderr,"_sig_on(%p)", current_position) ) [20:52] <mhansen_> Patch is up for #643. [20:52] <william_stein> no clue. [20:54] <william_stein> are those the sig things just from pari?! [20:54] <tornaria> I think so [20:55] <william_stein> It depends on whether you rebuilt just gen.pyx. [20:55] <tornaria> because I changed interrupt.h and touched libs/pari/*.py* [20:55] <william_stein> I'm trying now to see if I get similar results. [20:55] <william_stein> yep, replicated. [20:55] <tornaria> In fact, gp.eval(...) doesn't print the sig stuff... dunno what I have to rebuild [20:56] <william_stein> gp.eval doesn't involve _sig_on _sig_off in any way. [20:56] <tornaria> More curious is that pari('1/0') calls sig_str but no sig_off [20:56] <ncalexan> Ah, I see there are a ton of _sig_on _sig_on repeats. [20:56] <tornaria> ah... [20:56] <william_stein> yep. [20:56] <william_stein> so parierror isn't calling sig_off. [20:57] <tornaria> yep... [20:57] <tornaria> that's the thing... [20:57] <tornaria> Then signal handler is trying to longjmp [20:57] <william_stein> I mean pari trap doesn't call _sig_off. [20:57] <william_stein> oops. [20:57] <tornaria> back to some place which has been invalidated. [20:57] <william_stein> yep. [20:57] <william_stein> I'm trying with _sig_off at the top of the errorhandler. [20:58] <tornaria> I guess that didn't show up before since the signal handlers where different or something. [20:58] <william_stein> i bet it didn't show up *as much*. [20:58] <william_stein> since there were so many handlers, maybe. [20:58] <william_stein> pari('1/0') is now ballanded for me, but pari('factor(...)') is *NOT*. [21:02] <tornaria> ok [21:02] <tornaria> inside the "sigsetmp(...)" [21:02] <william_stein> *anywhere* with the new sig handling code, if you hit control-c it doesn't call _sig_off. [21:03] <tornaria> just before return(0), you have to of course _sig_off [21:03] <william_stein> sage: m = random_matrix(ZZ,500,501) [21:03] <william_stein> sage: m.echelonize() [21:03] <tornaria> (I mean _signals.mpio = 0 ) [21:03] <tornaria> that fixes it. [21:03] <william_stein> because the signal handler does that. [21:03] <william_stein> or... doesn't like it should. [21:03] <william_stein> yep. [21:04] <william_stein> I bet that was in my old code... but martin messed it up. [21:04] <tclemans> tom: could you referee the 643 patch? http://sagetrac.org/sage_trac/attachment/ticket/643/643.patch [21:04] <william_stein> actually, it was not in my old code. [21:05] <tornaria> now, I'm still having to interrupt twice the "gp.eval('factor(2^997-1)') [21:05] <boothby> yeah, I'll look at it. [21:05] <tornaria> OTOH, it doesn't happen like that on sage.math, so it's either [21:06] <tornaria> a) a problem with my build [21:06] <tornaria> b) just something I broke with all the debugging crap I added. [21:06] <boothby> looks good to me. [21:08] <tclemans> 643 is now resolved as fixed [21:08] <boothby> No. [21:08] <boothby> Don't close bugs -- let William do that. [21:08] <tclemans> ok [21:08] <tclemans> reopened [21:08] <boothby> Also -- what happens when you resize the window? [21:09] <william_stein> or change font size. [21:09] <william_stein> but your patch is still an improvement [21:09] <boothby> I say apply the patch anyway... but work on the resize / font size change issues. [21:09] <william_stein> sounds good. [21:09] <tclemans> opps i forgot to change that to set_main_top() [21:10] <tclemans> there is a window.onresize i added [21:10] <tclemans> i just have setMain(); instead of set_main_top(); [21:11] <william_stein> tornaria -- can you replicate the following? [21:11] <william_stein> Do factor(2^997-1) and hit controlc [21:11] <william_stein> then do gp.eval('factor(2^997-1)') and hit controlc [21:11] <william_stein> then Do factor(2^997-1) and hit controlc ... it hangs. [21:12] <tornaria> william: yes, it hangs on me... [21:12] <william_stein> i bet it has to do with us calling _sig_on twice in a row by accident a few ties. [21:12] <tornaria> we've still a problem, since _pari_catch traps and returns without _sig_off [21:13] <william_stein> yep. [21:13] <william_stein> yep, since it called that code in the if before return(0); in interrupt.h [21:14] <-- roed_ has left this server. [21:14] <william_stein> tornaria -- I'm changing interrupt.h so additional calls to sig_on are ignored to see what happens... [21:15] <tornaria> ok, so the jmp_buf is always the "outer" one. [21:15] <william_stein> yep. [21:15] <tornaria> I'm changing pari_catch so it _sig_offs when it traps something. [21:15] <william_stein> not needed? [21:16] <tornaria> that didn't fix the hang. [21:16] <william_stein> i think it isn't needed. [21:16] <tclemans> 643: do i need to attach a new patch with the change from setMain() to set_main_top() ? [21:16] <william_stein> mine didn't fix the hang either. but it seems like a good idea (making it only the outer one). [21:16] <tornaria> but otherwise we miss one _sig_off, don't we? [21:17] <william_stein> hmm. [21:17] <william_stein> you're right. [21:17] <william_stein> Maybe Sage should just die if they aren't matched. [21:17] <william_stein> :-) [21:17] <william_stein> i.e., call PyErr as in interrupt.c [21:17] <william_stein> That's a good idea actually. [21:19] <boothby> tclemans: yeah [21:19] <boothby> put a note about it. [21:24] <william_stein> tornaria -- i'm writing code to detect unbalanced _sig_on off and raise an error when it happens. [21:25] <tornaria> good [21:25] <william_stein> done, I think. want it? [21:26] [Error] home/was/tmp/interrupt.h: Unknown command. [21:26] <william_stein> It's in /home/was/tmp/interrupt.h on sage.mat [21:27] <tornaria> will have a look. I actually have a few changes in interrupt.h myself. [21:27] <william_stein> yep. [21:28] <william_stein> check it out: [21:28] <william_stein> --> 526 self.poly = pari([]).Polrev() [21:28] <william_stein> 527 [21:28] <william_stein> 528 if x is None: [21:28] <william_stein> /home/was/s/local/bin/gen.pyx in gen.PariInstance.call() [21:28] <william_stein> <type 'exceptions.RuntimeError'>: Unbalanced _sig_on/_sig_off [21:28] <william_stein> cool, eh! [21:28] <tornaria> uh... very good... :-) [21:29] <william_stein> cool!!! [21:29] <william_stein> check this out: [21:29] <william_stein> was@ubuntu:~$ sage -python [21:29] <william_stein> Python 2.5.1 (r251:54863, Sep 13 2007, 11:50:35) [21:29] <william_stein> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 [21:29] <william_stein> Type "help", "copyright", "credits" or "license" for more information. [21:29] <william_stein> >>> import sage.libs.pari.gen [21:29] <william_stein> >>> sage.libs.pari.gen.pari('[]') [21:29] <william_stein> ok [21:30] <william_stein> >>> sage.libs.pari.gen.pari([]) [21:30] <william_stein> RuntimeError: Unbalanced _sig_on/_sig_off [21:30] <william_stein> gotcha! [21:30] <tornaria> good... hope this catches the factor(...) culprit... [21:30] <william_stein> >>> sage.libs.pari.gen.pari.vector(5) [21:31] <william_stein> goes boom! [21:31] <william_stein> that culprit doesn't have a chance against us. [21:34] <-- boothby has left this server (niven.freenode.net irc.freenode.net). [21:34] <-- tornaria has left this server (niven.freenode.net irc.freenode.net). [21:34] <-- jaap has left this server (niven.freenode.net irc.freenode.net). [21:35] --> boothby has joined this channel (n=boothby@D-69-91-159-227.dhcp4.washington.edu). [21:35] --> tornaria has joined this channel (n=tornaria@r190-0-137-63.dialup.adsl.anteldata.net.uy). [21:35] --> jaap has joined this channel (n=jaap@cc73571-a.emmen1.dr.home.nl). [21:35] <boothby> wtf [21:35] <-- burcin has left this server (niven.freenode.net irc.freenode.net). [21:35] --> burcin has joined this channel (n=burcin@heim-032-216.raab-heim.uni-linz.ac.at). [21:35] <william_stein> wtf [21:37] <william_stein> tornaria. i got it. [21:37] <william_stein> Check out _new_gen. [21:37] <william_stein> It starts by calling _sig_on! [21:37] <william_stein> Damn it. [21:37] <william_stein> But it is called immediately by self.new_gen(...) [21:37] <william_stein> and there are very often _sig_on's right before self.new_gen(...) [21:38] <william_stein> (ok, I maybe got it) [21:40] <william_stein> tornaria -- if you delete the _sig_on in _new_gen, then all the unbalanced _sig_on/_sig_off's in startup go away. [21:42] <william_stein> Unfortunately, factor(2^997-1) can still be made to lock by hitting control-c during gp.eval('...') [21:42] <-- boothby has left this server ("leaving"). [21:45] <tclemans> when i do hg_sage.import_patch('643.patch') i get abort: no diffs found it is the patch that mhansen_ made [21:51] <tornaria> So.... I think the sage_signal_handler is being hijacked by pari... [21:51] <tornaria> I put a printf at the very top of sage_signal_handler [21:52] <tornaria> After the gp.eval(..) + CTRL-C, it shows as running the signal_handler, but only the first time! [21:52] <william_stein> i was just testing that too! [21:52] <william_stein> Try this -- put this line in interfaces/get_sigs.py in my_sigint: [21:52] <william_stein> import sage.ext.sig [21:52] <william_stein> sage.ext.sig.get_bad_sigs() [21:52] <william_stein> Then all known problems go away. [21:53] <william_stein> it's perfect now. [21:53] <william_stein> WOW. [21:54] <william_stein> weird -- get_bad_sigs calls init_csage... [21:55] <william_stein> which eventually calls setup_signal_handler(). [21:55] <william_stein> so I'm basically hacking around what you're really finding. [21:56] <william_stein> setup_signal_handler steals signal handlers back. [21:56] <tornaria> it works for me... [21:56] <mhansen_> Nice work you two on tracking down the issue(s). Pretty impressive. [21:56] <william_stein> cool. [21:56] <william_stein> I'm excited. [21:56] <william_stein> This has been a major bug for a long time. [21:56] <tornaria> bah, I still need two CTRL-C in my box. [21:57] <william_stein> what is your box exactly? [21:57] <william_stein> your laptop? [21:57] <tornaria> (for interrupting gp.eval(...) ) [21:57] <tornaria> yes, my laptop, core 2 duo 64 bits. [21:57] <william_stein> for gp.eval I need that too. [21:57] <william_stein> That's completely reasonable. [21:57] <william_stein> well, not reasonable... but it's an unrelated problem, probably. [21:57] <tornaria> ok [21:57] <tornaria> I don't need two CTRL-C on sage.math. [21:57] <william_stein> does factor(2^997-1) always require one control-c [21:57] <william_stein> it's a timing sort of issue, I think. [21:57] <tornaria> yes, definitely only one control-C [21:58] <william_stein> great. we did it! [21:58] <mhansen_> And just before the 10pm "deadline" :) [21:59] <william_stein> I bet make test will uncover lots of bugs with mismatched _sig_on/_sig_off!! [21:59] <william_stein> Yep found one already. [21:59] <william_stein> sage -t devel/sage-ranges/sage/rings/complex_double.pyx [21:59] <william_stein> do you guys want to help fix them? [21:59] <william_stein> actually, so far only 1. [21:59] <william_stein> so maybe not so exciting. [21:59] <tornaria> now that I come to think about it: aren't we supposed to reset signals when they are issued? [22:00] <mhansen_> Yeah, sure, I'll help. But, I'll need a brief intro course on what exactly needs to be done to fix them. [22:01] <william_stein> I just pushed out the change to the official repo. [22:01] <william_stein> there are several segfaults too. [22:01] <tornaria> I mean, " Upon arrival of a signal with number signum the following happens. ... Finally, if the handler is [22:01] <tornaria> set to a function sighandler then first either the handler is reset to SIG_DFL or an implemen‐tation-dependent blocking of the signal..." [22:02] <tornaria> from signal(2) [22:02] <tornaria> This didn't use to be a problem since _sig_on would set all the signals anyway. [22:02] <william_stein> ah [22:04] --> roed_ has joined this channel (n=roed@RANDOM-FOUR-SEVENTY-FIVE.MIT.EDU). [22:05] --> tclemans951 has joined this channel (n=Miranda@68.178.77.126). [22:05] <william_stein> with my current fix for signals, this now seg faults: sage: k.<a> = FiniteField(9); charpoly(a,'y') [22:05] <tornaria> IOW, one "simpler" fix could be to put "signal(sage_signal_handler, sig)" at some point in sage_signal_handler. [22:05] <william_stein> try it and see if it works. [22:11] <william_stein> sage: pari([2r,2r,1r]) [22:11] <tornaria> doesn't seem to work :-( [22:11] <william_stein> segfault [22:12] <william_stein> The "2r" means "raw integers", i.e., not preparsed. [22:12] <william_stein> this also fails: pari([2,2,1]) [22:12] <william_stein> does it fail for you? [22:12] <tornaria> It works. [22:12] <william_stein> ah, v=pari([1,2,3]) works. [22:12] <william_stein> so something in printing is broken. [22:12] <tornaria> But I have your hack disabled [22:13] <tornaria> (changed by my hack, which doesn't fix the problem) [22:13] <william_stein> ah, ok. [22:13] <william_stein> even with no change to get_sigs.py, I still have my problem. [22:13] <william_stein> I think it might be detecting mismatches sig_on/sig_off -- which causes a boom. [22:13] <tornaria> I don't have a problem, even reinstating your change to get_sigs.py [22:14] <william_stein> it's unrelated. [22:14] <tornaria> I don't have your code for detecting mismatches. [22:14] <william_stein> I wrote code to print out a traceback with _sig_on/_sig_off mismatches. [22:14] <william_stein> But of course printing a traceback in the middle of some weird code might just cause a problem and segfault. [22:14] <tornaria> yes, you told me to get it, but I didn't... :) [22:15] [Error] home/was/tmp/interrupt.h: Unknown command. [22:15] <william_stein> it's /home/was/tmp/interrupt.h on sage.math [22:15] <william_stein> i'm going to change it to also fprintf to stderr. [22:16] <william_stein> yep, the segfault is caused by a balance problem. [22:16] <william_stein> i posted a new version. [22:17] <william_stein> you have to be sure to touch gen.pyx [22:17] <-- wstein has left this server (Read error: 110 (Connection timed out)). [22:17] <william_stein> there is an extra _sig_on in GEN_to_str... [22:18] <william_stein> getting rid of that fixes the problem. [22:19] <william_stein> but I want a _sig_on there, so users can control-c out of str(pari(big thing)) [22:19] <-- tclemans has left this server (Read error: 110 (Connection timed out)). [22:21] <william_stein> you know, it doesn't matter if there are two _sig_on's in a row. [22:21] <-- roed_ has left this server (Read error: 110 (Connection timed out)). [22:21] --> wstein has joined this channel (n=was@c66-235-37-221.sea2.cablespeed.com). [22:21] <william_stein> The key thing is just that there is a _sig_off. [22:22] <william_stein> right? [22:22] <tornaria> mmm... [22:22] <william_stein> It *used* to matter with my old signal handler, since that just used "the last one". [22:22] <-- tclemans951 has left this server (Read error: 104 (Connection reset by peer)). [22:22] <tornaria> So, current _sig_on only remembers the outer call. [22:23] <william_stein> I'm still fuzzy. [22:23] <william_stein> But I don't think they have to be exactly ballanced. [22:23] <william_stein> Maybe it remembers only the innermost call? [22:23] <tornaria> well... sig_off is idempotent, so... [22:23] <william_stein> oh -- you're right, because of the if I added. [22:24] <tornaria> However, this will still be problematic, i.e.: [22:24] <tornaria> (1) _sig_on [22:24] <tornaria> (2) _sig_on [22:24] <tornaria> (2) _sig_off [22:24] <william_stein> why/ [22:24] <tornaria> (3) _sig_on [22:24] <tornaria> (3) _sig_off [22:24] <tornaria> (1) _sig_off [22:25] <tornaria> This is a perfectly balanced example. The numbers are the stack context. [22:25] <tornaria> It's meant that (2) is below (1) and (3) is also below (1), but (2) and (3) are "parallel" [22:25] <tornaria> (so stack context 2 is invalid while executing (3) [22:26] <tornaria> When you call _sig_off in (2), you are setting _signals.mpio = 0, then when you call _sig_on from (3), you think "there's no handler active, lets install one" [22:26] <william_stein> But then it would be as if there were no _sig_on/_sig_off code for part of (1). [22:26] <tornaria> actually, it's fine... when you (3) _sig_off you disable. [22:27] <tornaria> Yes, the problem is that after the first _sig_off you are not catching anymore. [22:27] <william_stein> yep. [22:27] <tornaria> Now, the other thing is to have a nest counter. [22:27] <william_stein> If I have a block of C code and I do _sig_on ... _sig_on ... _sig_on and at the end _sig_off, [22:27] <tornaria> only _sig_on at 0 [22:27] <william_stein> that is fine. [22:27] <tornaria> only _sig_off at 0. [22:28] <william_stein> Code with _sig* currently never calls into other functions that are *python* and involve _sig_, and expect [22:28] <william_stein> them to not call _sig. [22:29] --> roed_ has joined this channel (n=roed@c-24-128-48-246.hsd1.ma.comcast.net). [22:35] <william_stein> tornaria -- shall we declare partial victory. [22:35] <tornaria> yep :-) [22:35] <william_stein> then I declare SAGE Bug Day 3 over and a success :-) [22:36] <tornaria> I tried signal(sig, sage_signal_handler) in sage_signal_handler again [22:36] <tornaria> (w/o your hack in my_sigint) [22:36] <william_stein> what happened? [22:36] <tornaria> and it works... [22:36] <william_stein> which hack? [22:36] <william_stein> oh, i know. [22:36] <william_stein> that's better. [22:36] <tornaria> the one of calling get_bad_sigs [22:36] <william_stein> where precisely did you put it? [22:36] <tornaria> two places: [22:37] <tornaria> one right before comment "//where to go next?" [22:38] <tornaria> the second right before the second-to-last closing brace [22:38] <tornaria> (i.e. as late as possible, in each branch of the if(_signals.mpio && 1) ) [22:38] <williamstein> i just accidently clicked "snapshot" in my vmware image and i can't work for a minute... [22:38] <tornaria> :) [22:38] <william_stein> ok, back. [22:38] <william_stein> ? [22:40] <tornaria> //notify 'calling' function [22:40] <tornaria> [22:40] <tornaria> _signals.mpio |= 4; [22:40] <tornaria> [22:40] <tornaria> + signal(sig, sage_signal_handler); [22:40] <tornaria> + [22:40] <tornaria> //where to go next? [22:40] <william_stein> testing. [22:40] <tornaria> - if ( _signals.mpio && 2 ) { [22:40] <tornaria> + if ( _signals.mpio & 2 ) { [22:40] <tornaria> This is a piece of the patch... (first case) [22:40] <william_stein> && versus &? [22:40] <tornaria> Note also the && 2 , should be & 2 [22:40] <william_stein> interesting. [22:40] <tornaria> (it means to test bit 1) [22:40] <william_stein> yep [22:41] <tornaria> @@ -85,6 +92,8 @@ void sage_signal_handler(int sig) { [22:41] <tornaria> _signals.python_handler(sig); [22:41] <tornaria> break; [22:41] <tornaria> }; [22:41] <tornaria> + [22:41] <tornaria> + signal(sig, sage_signal_handler); [22:41] <tornaria> } [22:41] <tornaria> } [22:41] <tornaria> that's the other part... [22:41] <william_stein> worksforme [22:41] <tornaria> if(_signals.mpio && 2) is effectively the same as if(_signals.mpio) [22:42] <tornaria> however, the only places where _signals.mpio are set the values are either 1+2 or 0 [22:42] <tornaria> so it is really the same. :-) [22:42] <tornaria> AFAICT [22:43] <william_stein> i've closed #710 [22:43] <tornaria> good :-) [22:43] <william_stein> now I can release sage-2.8.4.3. [22:44] <tornaria> congrats... [22:44] <william_stein> at least after testing, etc. [22:44] <william_stein> It should really be 2.8.5, actually. [22:44] <william_stein> since there is so much that is new (e.g., 20,000 lines of combinatorics code). [22:44] <william_stein> several new packages, ec. [22:44] <william_stein> at least symmetrica. [22:45] <william_stein> I'm making an alpha0 tarball right now, to start building and testing on a bunch of machines, then going home. [22:46] <tornaria> good... [22:46] <tornaria> Is there a way to upgrade rather than starting over with the 150Mb download? [22:47] <tornaria> (I have 3Gb / month quota here...) [22:47] <william_stein> yes. [22:47] <william_stein> Just do "sage -upgrade" followed by "hg_sage.pull()" and "hg_scripts.pull()" and hg_doc.pull()". [22:47] <william_stein> Should be close enough. [22:48] <william_stein> but wait a second. [22:48] <tornaria> ok. [22:48] <william_stein> ok. [22:48] <william_stein> try now. [22:48] <tornaria> What about the having to hit CTRL-C twice in gp.eval(...) ? Is that reported? [22:48] <william_stein> make that a new ticket. [22:49] <tornaria> This is scary: [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> using frickin' slow GSL C-blas [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <william_stein> you don't have atlas devel libraries? [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> :-) [22:49] --> janwil has joined this channel (n=janwil@tartu.cyber.ee). [22:49] <tornaria> nope, didn't need them for anything. [22:49] <william_stein> gsl works fine; it's just slow for numerical linear algebra. [22:49] <janwil> good morning [22:50] <william_stein> hi [22:51] <tornaria> apt-get atlas3-base-dev wants to install gcc-3.4 [22:51] <janwil> how has the BD progressed this far? [22:51] <tornaria> (I have gcc 4.1.2 / etch) [22:51] <william_stein> we have an atlas spkg, but it takes a while (=30 minutes or so) to build. [22:52] <william_stein> it's in the optionall packages, I think. [22:52] <tornaria> don't need that for anything... :-) [22:52] <william_stein> janwil -- bd is now over. [22:52] <william_stein> I'll post the log in a moment. [22:52] <william_stein> See http://trac.sagemath.org/sage_trac/milestone/sage-2.8.5 }}} |
SAGE Bug Squash Day 3
The event will take place on THURSDAY September 20th, 2007 and officially start at 10 am pacific standard time. It will go on for 12 hours (until 10pm) 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.
The results: http://trac.sagemath.org/sage_trac/milestone/sage-2.8.5
- The base version of SAGE we'll start with is here: sage-2.8.4.2.1, which you can upgrade to using "sage -upgrade"
- The trac server with all the bugs is here:
- We will focus on the bugs listed here: TBA
- However, people with other interests can of course help out with fixing anything they want.
Write to wstein@gmail.com for an account on the bug tracker.
- We'll all be on #sage-devel at irc.freenode.net.
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)
- Michael Abshoff: Solaris port, Memleaks
Martin Albrecht: memleaks & maybe libSINGULAR enhancements
- Nick Alexander (until 3pm).
- Robert Bradshaw:
- Timothy Clemans (evening maybe): Notebook bugs
- Didier Deshommes: opensolaris (x86) port
- Burcin Erocal: memleaks
- Mike Hansen: combinatorics stuff, python-nose, misc. bug fixes.
- Robert Miller: reproducing dsage bug
- Bobby Moretti (after 5pm).
- William Stein (10am -- 10pm): Integrating all the fixes as they come in, then releasing a new Sage version.
Tom Boothby (10am -- 5pm; 6pm -- 10pm): AbelianGroup
- David Harvey: yeah bugs and stuff
IRC
BUG3 irc log:
[10:08] <ncalexan> pulling from /Users/ncalexan/sage/spkg/build/sage-2.8.4.2 [10:08] <ncalexan> searching for changes [10:08] <ncalexan> adding changesets [10:08] <ncalexan> adding manifests [10:08] <ncalexan> adding file changes [10:08] <ncalexan> added 592 changesets with 1040 changes to 321 files [10:09] <ncalexan> (run 'hg update' to get a working copy) [10:09] <ncalexan> abort: there is nothing to merge, just use 'hg update' or look at 'hg heads' [10:09] <ncalexan> nothing changed [10:09] <ncalexan> remote changed .hgtags which local deleted [10:09] <ncalexan> (k)eep or (d)elete? k [10:09] <william_stein> ok, so it isn't leaking. [10:09] <ncalexan> remote changed export which local deleted [10:09] <ncalexan> (k)eep or (d)elete? k [10:09] <ncalexan> 288 files updated, 0 files merged, 7 files removed, 0 files unresolved [10:09] <ncalexan> Any ideas? [10:09] <ncalexan> (While sage -upgrade was running) [10:09] <william_stein> so? [10:10] <william_stein> sage: b = a.copy() [10:10] <william_stein> sage: get_memory_usage() - s [10:10] <william_stein> 1.57421875 [10:10] <william_stein> sage: b = a.copy() [10:10] <william_stein> sage: get_memory_usage() - s [10:10] <william_stein> 1.98828125 [10:10] <william_stein> sage: b = a.copy() [10:10] <william_stein> sage: get_memory_usage() - s [10:10] <william_stein> 1.83203125 [10:10] <william_stein> oh, so copy is ok. sorry I'm a little slow getting started here, and saying dumb things. [10:11] <william_stein> burcin: [10:11] <william_stein> sage: s = get_memory_usage(); a = M.zero_matrix(); del a; get_memory_usage() - s [10:11] <william_stein> 0.0 [10:11] <william_stein> sage: s = get_memory_usage(); a = M.zero_matrix(); del a; get_memory_usage() - s [10:11] <william_stein> 0.0 [10:11] <william_stein> So there is no leak here. Move along. [10:11] *** mabshoff_ is now known as mabshoff|Cooking. [10:11] <william_stein> Anyway, could people introduce themselves quickly, say where they are, etc. [10:11] <burcin> I don't assign to any object.. and it keeps increasing.. [10:12] <william_stein> That could be IPython caching output. [10:12] * ncalexan is Nick Alexander, in Irvine, California. [10:12] * mhansen is Mike Hansen in Madison, Wisconsin, U.S. [10:12] <william_stein> in fact it is: [10:12] <william_stein> sage: M.zero_matrix() [10:12] <william_stein> 500 x 500 dense matrix over Integer Ring [10:12] <william_stein> sage: _ [10:12] <william_stein> 500 x 500 dense matrix over Integer Ring [10:13] <william_stein> The last few outputs are cached... [10:13] <burcin> burcin erocal, linz, austria [10:13] <burcin> can we turn that off somehow? [10:13] <ncalexan> william_stein: actually a lot more than the last few are cached. [10:13] <ncalexan> burcin: yes, it can be configured. [10:13] <william_stein> burcin -- yes -- see ipythonrc in .sage [10:13] <burcin> yes.. I think all are cached.. [10:13] <malb_> /me is Martin Albrecht, London, UK [10:13] <william_stein> I'm william stein in Seattle, WA [10:14] <william_stein> who is boothby? [10:14] <william_stein> and where is he? [10:14] <boothby> I'm boothby. [10:14] <boothby> Right here. [10:14] <jkantor> jkantor is josh kantor, usually seattle, WA but currently on vacation in buffalo, NY. [10:15] <boothby> Okfine, I'm Tom Boothby, in Seattle [10:15] <william_stein> OK, so the rules are (1) don't work on anything that isn't a trac ticket; (2) try to prefix lines with the trac #. [10:15] <william_stein> The goal is to fix as many bugs in Sage as possible today. [10:15] <mabshoff|Cooking> Michael Abshoff in Dortmund, Germany. [10:16] <william_stein> as bugs get fixed, I'll upload the fixes to the official hg repo, and people can hg_sage.pull() them... [10:16] <ncalexan> Could we have a trac triage page again? That was fantastic. [10:17] <mabshoff|Cooking> Well, there are a bunch of patches qued at the 2.8.4.3 milestone. [10:17] <mabshoff|Cooking> And I think it would be great if mhansen's combinatorics patch could go in early. [10:17] *** mabshoff|Cooking is now known as mabshoff_. [10:17] <mabshoff_> Last time I checked it wasn't in trac (yet) [10:17] <burcin> does the upgrade work correctly for you? [10:18] <william_stein> I haven't finished upgrading yet. [10:18] <burcin> <type 'exceptions.ImportError'>: No module named sage.misc.preparser_ipython [10:18] <burcin> WARNING: Failure executing code: 'import sage.misc.preparser_ipython; sage.misc.preparser_ipython.magma_colon_equals=True' [10:18] --> roed_ has joined this channel (n=roed@MACLAURIN-SIXTEEN-NINETY-FOUR.MIT.EDU). [10:18] <janwil> (Jan Willemson, Tartu, Estonia, but I will probably mostly be rather quiet:)) [10:18] <william_stein> Did "sage -br" fail for you. [10:18] <mhansen> mabshoff: #630. I didn't have time to finish it last night, but that's what I'll work on first. [10:18] <ncalexan> Hi Jan, I don't recognize you from the list. Welcome! [10:19] <william_stein> the upgrade failed for me. not good. [10:19] <william_stein> i rushed this release. [10:19] <william_stein> and made it while on the linbox call. [10:19] <william_stein> sorry [10:19] <william_stein> hold on. [10:19] <ncalexan> Don't worry -- this will focus the bug day like nothing else. [10:19] <william_stein> problem is flint. [10:20] <william_stein> should I disable it or fix that it isn't installed correctly? [10:20] <janwil> Hi ... I actually have a SAGE issue that really bothers me, but that is documented only in the devel mailing list and is not a trac ticket (yet), so probably it is out of the focus today anyway [10:21] <william_stein> ah, maybe it isn't in the makefile. [10:21] <william_stein> janwil -- put it in trac. [10:21] <ncalexan> janwil: do you have a trac account? [10:21] <janwil> no [10:21] <william_stein> ok, I fixed the upgrade problem almost... not quite. [10:21] <ncalexan> janwil: if it's easy to describe, message me and I will add it to trac. William might be a few minutes adding your account. [10:22] <ncalexan> Actually, just use mine: [10:22] <ncalexan> Hmm... perhaps not. [10:22] <janwil> well, it's not easy to describe 
[10:22] <ncalexan> [10:22] <william_stein> janwil -- email me with your requested login and low-quality password for fun. [10:22] <mabshoff_> I think janwil's issue is in trac with a patch by malb. [10:22] <william_stein> ah [10:23] <janwil> well, that patch did not help the main issue I had [10:23] <mabshoff_> the maxima vs. your Linux distro issue, checking for th e number. [10:23] <malb_> I will be looking at #445 this bothers me quite a lot, I'm not sure how far I'll get though [10:23] <mabshoff_> The script issue? That is also in trac. [10:23] <janwil> oh, with the long script? [10:24] <mabshoff_> I think #445 is more or less a pexpect and Signal delivery issue. [10:24] <mabshoff_> We might need to modify it to just send SIGKILL [10:25] <mabshoff_> But I might be completely wrong 
[10:25] <mabshoff_> janwil: can you find the issues you have in trac? [10:25] <mabshoff_> I think #507 is one of them. [10:26] <malb_> mabshoff_ / #445: yes something along the line of that [10:26] <william_stein> Do "sage -upgrade" then "sage -br". [10:26] <janwil> #507 is a simple case .. I also have a problem that is reproducible in 4 cases out of 5 [10:26] <mabshoff_> Well, in the end we need to write a proper pexpect replacemnt anyway. [10:27] <janwil> ok, I will try to put it to trac [10:27] <mabshoff_> janwil: could you build a Arch Linux vmware image? That way we could test on it regulary. [10:27] <janwil> and this 4 out of 5 occurs on Ubuntu [10:28] <jkantor> William/700 where should the doctests for cvxopt and scipy go ? [10:28] <william_stein> Hi everybody -- I fixed the upgrade issue. If you just do "sage -upgrade" again then "sage -br" you'll be good. [10:28] <mabshoff_> okay, post the issues, hopefully someone will be able to reproduce them. [10:28] <mabshoff_> [10:28] <william_stein> jkantor -- good question. [10:28] <william_stein> In a file somewhere. [10:28] <janwil> william_stein: is your gmail account ok to use for trac username application? [10:28] <william_stein> janwil -- yes. [10:29] <william_stein> jkantor -- I think there should be a SAGE_ROOT/devel/sage/sage/numerical directory [10:29] <mabshoff_> while you are at it: can you change my trac password to something less obvious and send me the updated password? [10:29] <jkantor> I was about to say that [10:29] <william_stein> Inside there you could put a .py file with a big triple quoted string that has tests of numpy, scipy, cvxopt, etc. [10:30] <jkantor> ok [10:31] <william_stein> #445 -- I'll work on that too right now. [10:31] <william_stein> I think it will be easy to fix. [10:31] <ncalexan> jkantor: could I suggest you define somewhat relevant method names rather than one big string? In future, the testing interface will probably provide detailed feedback about what method the test was in. [10:32] <william_stein> We're not testing methods. [10:32] <william_stein> We're just testing that two libraries were actually installed. [10:32] <william_stein> The thing is that cvxopt and scipy like to silently pretend to be installed, but with most of their functionality [10:32] <janwil> willam_stein: ok, sent it from my gmail account, so it should be delivered quite fast [10:32] <william_stein> gone if something goes slightly wrong when building. [10:32] <mabshoff_> [10:32] <william_stein> #445 -- has anybody replicated it? [10:33] <william_stein> jkantor -- make a trac ticket for what you're doing, so we will get one more extra point when you finish it [10:33] <dmharvey> hi, i'm david harvey, cambridge MA.... ten minutes walk away from the next sage days [10:34] <malb_> I replicate this on a daily basis with SINGULAR [10:34] <ncalexan> william_stein: in that case, shouldn't the doctests be testing that the missing functionality really is there? [10:34] <malb_> that was about #445 [10:34] <jkantor> Most of the problems are missing symbols on importing modules [10:34] <jkantor> So if there is no exception, the functionality is there [10:34] <-- roed_ has left this server (Read error: 110 (Connection timed out)). [10:35] <dmharvey> i'm starting with #635, which should be straightforward I hope [10:36] <william_stein> robert miller just showed up (in my office) [10:36] <william_stein> #635 -- good [10:39] <william_stein> #445 -- I just replicated with this input. It's evil. [10:39] <william_stein> R=QQ['x'] [10:39] <william_stein> f = R.random_element(5000) [10:39] <william_stein> g = magma(f) [10:39] <william_stein> g.IsIrreducible() [10:40] --> millster has joined this channel (n=robert@mdhcp175.math.washington.edu). [10:40] <william_stein> Important not on #445 -- it *only* happens in the notebook. [10:40] <malb_> #445 I calculate GBs on a daily basis, equally evil [10:40] <william_stein> #445 -- malb -- do you agree? [10:40] <malb_> really? [10:41] <malb_> let me check [10:41] <william_stein> Yes. The same example pasted above works fine in the console. [10:41] <malb_> hang on, need to rebuild SAGE (connection to sage.math is very slow) [10:41] <william_stein> ok [10:43] <william_stein> #445 -- probably the notebook is so agressively interrupting the sage process that is running magma, [10:43] <william_stein> that it interrupts it in the middle of actually killing the running magma. [10:43] <william_stein> It's two levels of pexpect going on. [10:44] <malb_> so we should send a command first (kill-your-children) and interrupt then? [10:44] <william_stein> definitely not. [10:44] <william_stein> In fact that magma process shouldn't even get killed. [10:44] <william_stein> It should just get interrupted. [10:45] <william_stein> We should probably just send 1 interrupt signal from the notebook server to the Python process. [10:45] <william_stein> I.e., one "control C". [10:45] <william_stein> Let me look at the code. [10:45] <william_stein> line 1328 of server/notebook/worksheet.py [10:45] <william_stein> right now 3 ctrl-c's are sent when you hit escape or click "interrupt" in the notebook. [10:45] <william_stein> I'll try changing to 1. [10:46] <malb_> okay, still building [10:47] <mabshoff_> Sorry, I was gone, but should be do any upgrade from 2.8.4.2 or is there another tarball? [10:48] <william_stein> #445 that workec well [10:49] <malb_> good, my Singular problem seems unrelated then [10:50] <malb_> P = PolynomialRing(QQ,10,'x') [10:50] <malb_> I = sage.rings.ideal.Katsura(P) [10:50] <malb_> I.groebner_basis() # forever! [10:50] <malb_> Ctrl-C [10:50] <malb_> from the command line [10:51] <malb_> what function handles signals? [10:52] <william_stein> It's just keyboardinterrupt being handled in expect.py or possible singular.py [10:52] <jkantor> william/709 To be doctested the file just needs to be in the source tree, i don't need an all.py to import it or anything right? [10:52] <william_stein> yes. [10:52] <william_stein> #709 -- yes [10:55] <william_stein> #445 -- expect.py: interupt(...) is very relevant to what happens after ctrl-c is received... [10:55] <william_stein> I think. [10:56] <janwil> william_stein: did you get my email? [10:56] <ncalexan> Hmm, clisp.pdf missing stops the build. [10:56] <williamstein> janwil -- yep. [10:56] <williamstein> ncalexan you've had that problem before, no? [10:56] <williamstein> you have a weird setup of pdf tools. check sage-devel. [10:57] <ncalexan> Yes... oh, thanks for the reminder. [10:57] <mabshoff_> That problem is related to some missing tool [10:57] <malb_> #445 I got it [10:57] <williamstein> janwil -- you should have a trac account. [10:57] <williamstein> My "fix" for #445 breaks other things, so not good. [10:57] <williamstein> Weird. [10:58] <mabshoff_> ncalexan: You had the same problem at http://groups.google.com/group/sage-devel/browse_thread/thread/af701e5f8d428ad2 [10:58] <janwil> williamstein: thanx, I have it now ... will try to create a ticket [10:58] <ncalexan> thankx. [10:59] <mabshoff_> you need to fix your dvipdf [10:59] <ncalexan> I do, but there's actually a hairy problem in the middle (with fink and X11) that I don't want to fix [10:59] <ncalexan> but maybe now is the time. [10:59] <mabshoff_> interstingly the second google hit for "clisp.pdf missing" [11:00] <malb_> #445 I figured out my problem with Singular, Singular has a signal handler which asks what to do [11:01] <ncalexan> One wonders what the first hit is [11:01] <mabshoff_> http://www.google.de/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fftp6.tw.freebsd.org%2FFreeBSD%2Fdevelopment%2FFreeBSD-CVS%2Fports%2Flang%2Fclisp%2Fpkg-plist%2Cv&ei=MrXyRv2OPI38nQP7lvnDDg&usg=AFQjCNHZRGUz_mjLv8ZnyL2s5uJAjAp66w&sig2=omEH8PW3FYRcm7xemWq7Tw [11:01] <mabshoff_> But I thing that varies depending on which country you google from [11:02] <dmharvey> #635: not only did chris wuthrich change the precision in the doctests, he changed all the answers too. I have no idea what to make of all this. [11:02] <william_stein> #445 -- malb -- could you post an example that illustrates your porlbme at singular GB's? [11:02] <malb_> the one I posted earlier: [11:02] <malb_> P = PolynomialRing(QQ,10,'x') [11:03] <malb_> I = sage.rings.ideal.Katsura(P) [11:05] <mabshoff_> I am off for the next hours or so, commuting home. [11:05] <mabshoff_> cu in a bit [11:05] <william_stein> cu [11:05] <-- mabshoff_ has left this server (Read error: 104 (Connection reset by peer)). [11:06] <dmharvey> wstein: #635, it's very strange. I'm looking at a diff where chris changed the normalisation by 2p, which is what we had agreed, but I'm sure I also did the same thing! So I guess you probably never merged in my changes. [11:06] <william_stein> sorry. [11:08] <dmharvey> that's okay. It's hard working on code like this where various people have different goals. Like chris probably doesn't care too much about whether the last digit is there or not; but when I'm playing with large primes, the last digit takes a lot of extra time! [11:08] <william_stein> #445 -- i just checked in a change that fixes the problem in the notebook. [11:08] <william_stein> I found another related bug while I was at it, that I'll pos. [11:10] <malb_> good, I am still playing with Singular's special treatment [11:10] <william_stein> malb -- check out http://trac.sagemath.org/sage_trac/ticket/710 [11:11] <william_stein> sage: n=factor(2^997-1) # then hit control C [11:11] <william_stein> then do [11:11] <malb_> ouch [11:11] <william_stein> sage: gp.eval('factor(2^997-1)') # then hit control C [11:11] <william_stein> and boom!! [11:11] <malb_> how can those two be related? [11:11] <william_stein> and it happens with any interface -- not just gp. [11:12] <william_stein> somehow the pari signal handling if seriously foobaring something about the state of Sage. [11:13] <malb_> mhh, can you Ctrl-C twice for factor(2^997-1)? [11:14] <william_stein> for me factor(2^997-1) with 1 control-c immediately interrupts. [11:14] <william_stein> #710: on os x interrupting gp.eval('factor(2^997-1)') then fails [11:14] <william_stein> #710: on linux 64-bit it seg faults. [11:15] <william_stein> I'm going to close #445, since that's now fixed. [11:15] <william_stein> But we need a ticket for your katsura example. I'll try to replicate it and if so, open a ticket. [11:15] <malb_> okay [11:15] <janwil> should I include the script as a snippet in the ticket or should I attach it as a file? [11:15] <william_stein> Your choice. If a snippet, use {{{ and .[11:16] <janwil> yes, I did use them, thanx [11:16] <william_stein> malb -- replicated. [11:16] <william_stein> Your bug will be easy to fix, I think. [11:17] <william_stein> #711 -- malb, your bug is now 711. [11:17] <william_stein> #445 is now fixed (unless people claim differently). [11:17] <william_stein> brb. [11:19] <janwil> ok, submitted -- #712 (the reference to the component is probably wrong -- please excuse me) [11:23] <william_stein> janwil -- is it possible that your problem is a bug in maxima itself? [11:24] <william_stein> when I try your system it fails right off. [11:27] <william_stein> #712 -- ok, I'm working on this now. [11:28] <william_stein> it's a bug in maxima. [11:28] <william_stein> it's outputing "CAR: 2 is not a list" and dieing. [11:29] <william_stein> janwil -- we should make a clean file that inputs something into Maxima (not involving sage) and [11:29] <william_stein> produces that error, and report it on the maxima list. [11:29] <malb_> william_stein: See #713 (the Singular interface bug with patch) [11:30] <william_stein> that's no fix. [11:30] <william_stein> #713 -- rejected. [11:30] <william_stein> We should never ever leave a process running that a user has to kill manually. [11:30] <malb_> why? [11:30] <william_stein> No matter what. [11:30] <malb_> i.e. Ctrl-D is not an option? [11:31] <william_stein> No. But the print "WARNING: -- unable to kill %s. You may have to do so manually."%self [11:31] <william_stein> i don't like. [11:31] <malb_> thats just copied from expect.py [11:31] <malb_> I didn't write that [11:31] <william_stein> In that case, shouldn't we kill -9 the sucker or something and make sure it didn't work. [11:31] <william_stein> Ok, well then I reject the code I wrote [11:31] <malb_> better [11:32] <william_stein> Who wrote it? [11:32] <william_stein> me. [11:33] <william_stein> well that should still be replaced by kill -9. [11:33] <william_stein> new ticket. [11:33] <malb_> okay, will do [11:33] <william_stein> i'm making the ticket now. [11:34] <william_stein> #714 -- that kill -9 thing. [11:34] <william_stein> I'll apply your #713 now [11:41] <jkantor> #709-is done, (together with the fix for 700 so the doctests actually pass) [11:42] <ncalexan> william_stein: where is the bug triage list? [11:42] <ncalexan> Or the correct trac view? [11:42] <william_stein> ncalexan: http://trac.sagemath.org/sage_trac/milestone/sage-2.8.4.3 [11:42] <ncalexan> Thanks. [11:43] <william_stein> Our goal is basically to deal everything marked for 2.8.4.3. [11:43] <william_stein> Also, look a lot at the 2.9 bugs. [11:43] <william_stein> there isn't much of a handwritten page yet though. [11:43] <william_stein> volunteer to make one?? [11:43] <william_stein> (I'm not sure it is needed.) [11:44] <malb_> wstein, #714 close(force=1) already sends a SIGKILL [11:44] <malb_> so this exception actually should never happen [11:45] <william_stein> How about in the exception check for the process first and if it is still there send more kills? [11:45] <william_stein> Or is this getting overly paranoid, given that when sage quits it will *definitely* kill the process. [11:45] <william_stein> (the zombie killed) sage-cleaner. [11:45] <william_stein> I just replicated janwil's bug entirely in maxima. [11:45] <malb_> I would suggest: propagate the exception up and wait for bugreports [11:46] <malb_> this way we have something to replicate [11:46] <william_stein> #712 -- It has absolutely nothing whatever to do with Sage or the pexpect interface [11:46] <william_stein> And for me it isn't sporadic. [11:46] <william_stein> malb -- good idea! [11:46] <william_stein> That's fine by me. [11:46] <malb_> okay, will attach patch to #714 [11:46] <william_stein> Please add to the exception: "THIS IS A BUG -- PLEASE REPORT. This should never happen." [11:47] <malb_> okay [11:50] <william_stein> #712 -- I'm done working on http://trac.sagemath.org/sage_trac/ticket/712 [11:50] <william_stein> #712 Janwil, I hope you can report this bug to the maxima list. [11:51] <william_stein> I think if you just provide the input file I attached there -- which should make it easy for anybody [11:51] <william_stein> to replicate the problem, then you'll have a chance. [11:51] <janwil> william_stein: thanx for your work! yes, I can report this as a Maxima problem [11:52] * ncalexan is working on 228, a small notebook bug to do with the preparser. [11:53] <william_stein> ncalexan -- thanks!! [11:53] <william_stein> #228 -- That's a long open bug that needs to be fixed. [11:54] <william_stein> Ralph Greenberg just dropped by my office. He wants us to fix some bugs in his house... [11:54] <william_stein> #713: closed. [11:55] --> robertwb has joined this channel (n=robert@D-69-91-158-249.dhcp4.washington.edu). [11:57] <william_stein> malb -- I'm looking at #507 (which you fixed) [12:00] <malb_> good, also I've attached a patch to #714 [12:01] --> roed_ has joined this channel (n=roed@RANDOM-FOUR-SEVENTY-FIVE.MIT.EDU). [12:02] <william_stein> hi david roed_ [12:03] <roed_> hey [12:03] <william_stein> #714: closed. [12:04] <roed_> cool. Did anyone have suggestions on the design? [12:04] <janwil> william_stein: I do not quite understand the maxima_bug that you uploaded ... solve(sage3, sage7); refers to sage3, but that is not defined ... am I reading something wrong? [12:05] <william_stein> I forgot to put it in the script. [12:05] <william_stein> Hold on. [12:06] <dmharvey> roed: design of what? [12:06] <william_stein> sage3 : [sage0,sage1,sage2] [12:07] <janwil> ok, that makes sense and sage9 and sage10 are not actually needed? [12:07] <william_stein> now the bug doesn't happen for me. Drat. [12:07] <william_stein> what the heck. [12:08] <janwil> ok, so you were able to reproduce my sometimes-bug-sometimes-not behavior? [12:08] <william_stein> now I am, which sucks. [12:08] <janwil> well, that was really annoying when I stepped onto it, too [12:09] <janwil> I was already ready to blame some race conditions or timing or something like that [12:09] <roed_> dmharvey: I wrote a way to globally control default proof behavior last night [12:10] <roed_> http://trac.sagemath.org/sage_trac/ticket/704 [12:12] <william_stein> janwil -- bug #712 -- please try loading the file j attached to #712. [12:12] <william_stein> (%i1) batchload("/home/was/tmp/j"); [12:12] <william_stein> Maxima encountered a Lisp error: [12:12] <dmharvey> roed: also would be nice to have global spelling="british" to prevent ugliness like "behavior" [12:12] <william_stein> every time. [12:12] <william_stein> [12:13] <william_stein> #704 -- proof stuff -- I'm putting that in Sage now. [12:14] <roed_> dmharvey: lol. There are plenty of other global settings that one might want to control. I'll stick to proof=True/False for now [12:14] <william_stein> roed_: EXAMPLES are supposed to be indented 4 spaces. [12:14] <william_stein> EXAMPLES: [12:14] <william_stein> [4 spaces]sage: input [12:15] <william_stein> [4 spaces]output [12:16] <roed_> ok [12:17] <janwil> william_stein: maxima -b j gives something different for me ... [12:18] <janwil> Inconsistent equations: (2 3) [12:18] <janwil> -- an error. Quitting. To debug this try debugmode(true); [12:18] <william_stein> Cool. [12:19] <janwil> well, I did not use SAGEs maxima, but Ubuntu's ... [12:19] <william_stein> ah. [12:19] <william_stein> Try sage's: "sage -maxima". [12:19] <william_stein> It could be a new bug in maxima and sage's maxima is newer. [12:20] <janwil> ok, now I get CAR: 2 is not a list [12:21] <janwil> so this "inconsistent equations" shouldn't be happening either? [12:21] <william_stein> janwil -- i don't know. [12:21] <roed_> dmharvey: do you know if Sage currently includes ZZ_pEX? [12:21] <janwil> ok [12:22] <william_stein> But "CAR: 2 is not a list" is definitely a Maximma bug, since that's a lisp error, and maxima [12:22] <william_stein> should never produce a lisp error. [12:22] <dmharvey> roed: I don't believe it does [12:22] <william_stein> roed_ -- did you do "make test" or "sage -testall" after making your proof patch? [12:22] <janwil> ok, I will try to put together a bug report for maxima [12:22] <william_stein> janwil -- thanks. [12:23] <dmharvey> grep -R "ZZ_pEX" * -- nope [12:23] <roed_> william_stein: I had that remaining issue with sage/rings/morphism.py that was different between sage -t and grep "sage: [12:23] <roed_> " morphism.py | sage [12:25] <william_stein> ok. [12:25] <roed_> But I'm running a make test now [12:25] <roed_> We'll see if it's still there. [12:25] <william_stein> I want to put robert miller's [a..b] patch in. [12:25] <william_stein> Any objections ? [12:26] <william_stein> oops -- robert bradshaw. [12:26] <william_stein> roed -- I'll work on that morphism.py thing as I've applied your patch now. [12:27] <william_stein> sage -t morphism.py [12:27] <william_stein> works fine form me. [12:29] <roed_> good [12:29] <roed_> [12:32] --> grout has joined this channel (n=grout@good.math.iastate.edu). [12:32] <william_stein> hi jason. Welcome to SAGE! [12:32] <grout> thanks! [12:33] <millster> hi jason, i'm writing an answer to your questions on google groups [12:33] <grout> the one about the mercurial error? [12:33] <millster> aye [12:33] <dmharvey> #635: I'm basically done with this, I'm just running ./sage -t -long on sage.math now [12:36] <dmharvey> I'm going to continue working on #528 now. This will probably be a few hours work I imagine. [12:37] --> mabshoff_ has joined this channel (n=mabshoff@p5090C126.dip.t-dialin.net). [12:37] <mabshoff_> Hey, looks pretty busy now. [12:39] <dmharvey> does sage -t -long time out after five minutes for a whole file? [12:40] <mabshoff_> I am not sure, but I think there is a bug in the timeout code when python just "spins" [12:41] <william_stein> probably. [12:41] <mabshoff_> After you interrupt it (way past 180 seconds) it then tells you that it timed out after [12:41] <mabshoff_> you send the CRTL-C [12:41] <mabshoff_> I have seen that behavior with the lazy rings on Solaris 9 [12:41] <dmharvey> because it looks like sage -t -long is giving up on ell_rational_field.py after 294.6 seconds, with *** *** Error: TIMED OUT! *** *** [12:42] <william_stein> dmharvey: oops. [12:42] <william_stein> It's probably a bug. [12:42] <mabshoff_> (there is a bug or miscompilations happening there9 [12:42] <william_stein> dmharvey: I'll fix that. [12:42] <william_stein> it is a bug. [12:42] <mabshoff_> Some of the regular doctests with elliptic curves come close to the 3 minute timeout on [12:42] <mabshoff_> on neron by the way [12:43] <william_stein> or a mistake in design. [12:43] <william_stein> mabshoff_ -- ell_rational_field.py *desparately* needs to be broken into smaller files. [12:43] <mabshoff_> I guess it is ticket time then. [12:44] <mabshoff_> I will write some summary of the LinBox teleconference first, though. [12:44] <mabshoff_> And post it to LinBox devel. [12:44] <dmharvey> wstein: how do you break a file into pieces when it's all one class? [12:46] <william_stein> dmharvey -- you make it into multiple classes. [12:46] <roed_> I'd like to work on ell_rational_field.py [12:46] <dmharvey> roed: just hang on a few minutes at least..... I'm touching bits of that file now [12:46] <roed_> because we need a new class for elliptic curves over number fields [12:46] <william_stein> E.g., instead of E.L[tab] giving all kinds of l-series crap, one should instead maybe have [12:46] <william_stein> a class for "L-series of an elliptic curve", then all code related to L-series goes in that file. [12:48] <janwil> william_stein: your last j script was missing references to sage1 and sage2 ... when I added those from the Maxima_bug script, I got a script that worked fine for me every time both in SAGE's Maxima and in Ubuntu's one [12:49] <william_stein> hmm. [12:49] <william_stein> interesting. [12:50] <janwil> well, Maxima should probably never throw a lisp bug, but this still means we have not cracked #712 ... or? [12:50] <malb_> I was looking into #325 which involves NTL, it doesn't make sense to touch it now, doesn't because of the NTL break-up? [12:53] <ncalexan> william_stein: please do that L-series refactoring, it's badly needed. [12:54] <dmharvey> well shite. Now when I run sage -t -long on my modified ell_rational_curve.py, it segfaults. It wasn't doing that five minutes ago. [12:54] <william_stein> ncalexan: volunteers are needed [12:54] <william_stein> malb_- the new ntl is I think ready to be tested and included in sage. [12:55] <william_stein> Check it out. [12:55] <ncalexan> Okay, I'm almost finished this bug, so maybe I'll look at that next. [12:55] <william_stein> #697. [12:55] <dmharvey> ncalexan: wait till I've put in #635, it's almost done, it touches ell_rational_field.py [12:55] <william_stein> #697 -- ntl -- malb, want to referee it [12:55] <malb_> okay, applying the NTL and trying #325 then [12:55] <ncalexan> Okay, dmharvey, please ping me and send me the bundle/post it on sage.math. [12:57] <dmharvey> malb: I'll be working on top of joel's NTL patch too, i.e. continuing on #528 [12:59] <william_stein> dmharvey -- do "sage -t --verbose --long" -- it'll tell you a lot more. [12:59] <dmharvey> yeah I'm already doing verbose [13:00] <roed_> ncalexan: what are you planning on doing with ell_rational_field.py? [13:00] <dmharvey> wstein: do you run sage -t -long often? [13:00] <william_stein> dmharvey: once in a blue moon. [13:00] <ncalexan> roed_: not much, just factor out the L-series stuff into a separate class and file. [13:00] <william_stein> I should run it every night. [13:00] <ncalexan> It could wait. [13:01] <william_stein> Last time I ran it (about 2 weeks ago) I found a doctest by David Joyner. [13:01] <william_stein> It took a *long* time. [13:01] <william_stein> In fact, he told me it was _supposed_ to take about a day to run. [13:01] <william_stein> [13:01] <roed_> ncalexan: why don't I do that. I need to refactor other stuff as well in order to split off an ell_number_field class [13:01] <william_stein> It was some record-breaking calculation in Gap. [13:01] <ncalexan> roed_: if you'd like. [13:01] <william_stein> roed_ -- could you make a plan first and post it for discussion? [13:01] <roed_> sure [13:02] <roed_> I'll make a new ticket [13:02] <william_stein> By the way, if people do "hg_sage.pull()" they will get Robert Bradshaw's complete-ish implementation of the [13:02] <william_stein> new [a..b] and (a..b) notation. [13:02] <william_stein> Try it out. [13:02] <william_stein> It's fun. [13:02] <william_stein> Try to break it. [13:02] <ncalexan> william_stein: did you already create an L-series ticket? [13:03] <william_stein> ncalexan -- no. go for it. [13:03] <william_stein> there might be a "break up ell_ational_field" ticket; I don't know. [13:03] <ncalexan> roed_: go for it, make the L-series ticket. [13:03] <william_stein> I want to fix the timeout stuff for doctesting. It's really weird. I'll make a trac ticket. [13:04] <dmharvey> wstein: this is annoying.... there's a failure in the long doctests now for EllipticCurve("123a1").sha_an_padic(41). But the only changes I made should have *increased* the precision of p-adic regulators and such. Is there an easy way to tell whether the old answer was correct, or the new answer is correct? [13:05] <william_stein> trac #717 -- issues with the timeouts. [13:05] <-- jkantor has left this server (Read error: 110 (Connection timed out)). [13:06] <william_stein> Well the answer should be a unit at 41. [13:06] <william_stein> Actually it should be 1, right? [13:06] <dmharvey> yeah I'm now getting 40 instead of 1 [13:06] <william_stein> -1. [13:07] <dmharvey> It's listed under "exceptional cases" -- I don't know what that means [13:07] <dmharvey> line 3226 [13:09] <william_stein> I think the normalization of the p-adic L-series is currently up to sign. [13:09] <dmharvey> is that "exceptional" as in "multiplicative"? [13:11] <janwil> william_stein: so I won't file a maxima bug yet? [13:11] <william_stein> janwil -- yes, definitely don't yet. [13:11] <william_stein> I'll get back to your problem in a minute. [13:11] <ncalexan> Please wait while the SAGE Notebook server starts... [13:12] <ncalexan> Traceback (most recent call last): [13:12] <ncalexan> File "/Users/ncalexan/sage/local/bin/sage-notebook", line 9, in <module> [13:12] <ncalexan> from sage.server.notebook.all import notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/all.py", line 13, in <module> [13:12] <ncalexan> from notebook_object import notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/notebook_object.py", line 17, in <module> [13:12] <ncalexan> import run_notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/run_notebook.py", line 26, in <module> [13:12] <janwil> ok, no problem ... will go make some tea ... [13:12] <ncalexan> import notebook [13:12] <ncalexan> File "/Users/ncalexan/sage-2.7.2/devel/sage-bugs/sage/server/notebook/notebook.py", line 21, in <module> [13:12] <ncalexan> from sage.structure.sage_object import SageObject, load [13:12] <millster> grout: hopefully that response will clear things up a bit [13:12] <ncalexan> sage -ba needed? [13:13] <william_stein> ncalexan -- what are you doing? [13:13] <ncalexan> Fixing 228: I changed a function in worksheet.py, added a few module level test data variables, and added doctests. [13:13] <ncalexan> sage -notebook fails; sage -t works. [13:14] <william_stein> it sounds like you broke the notebook. Maybe a circular import? [13:14] <ncalexan> Possible, I suppose. I removed nodoctest (why is that there, anyway?) so that my doctests were run. [13:15] <malb_> well the NTL patch conflicts already big time [13:15] <malb_> anybody familiar with number_field_element.pyx? [13:15] <william_stein> yes. [13:15] <william_stein> I just changed it a lot, with robert. [13:15] <william_stein> I'll try applying the ntl patch, since Robert is with me right now. [13:15] <malb_> _parent_poly_c_ doesn't work anymore (doesn't compile after the merge) [13:16] <dmharvey> wstein: if you're happy with the sha_an_padic() changing sign like that on one example, then I'm happy to post my patch for #635, otherwise I can try and investigate it further... but I probably don't know the theory well enough to figure out what's going on. [13:17] <-- robertwb has left this server. [13:17] <malb_> mhh,in the original code it is raise NotImplementedError anyway [13:18] --> jkantor has joined this channel (n=jkantor@cpe-76-180-115-46.buffalo.res.rr.com). [13:18] <william_stein> dmharvey -- please mark the doctest clearly (with words). [13:18] <william_stein> The fix is to normalize modular symbols correctly. [13:19] <william_stein> Craig Citro or I can fix that eventually and should. [13:19] <dmharvey> wstein: ok I'll do that and post the patch [13:22] <grout> is there anyone here who wants to talk about the graph.py code? I have a question about the order of an elif statement [13:22] <grout> Related to #716 [13:23] <millster> grout: what's your question? [13:24] <dmharvey> millster == robert miller? [13:24] <millster> yes [13:25] <grout> ah, just the person. [13:25] <grout> I'm looking in the init function of DiGraph and Graph [13:25] <grout> Why is there a test for the more general class DiGraph before the subclass XDiGraph? [13:25] <grout> Shouldn't it be the other way around? [13:26] <grout> (i.e., if we have an XDiGraph, just set _nxg and return, otherwise there's more work to do. [13:26] <william_stein> malb_ -- every conflict so far involves Robert Bradshaw's code, so we're in luck. [13:27] <william_stein> (no bug days on Sundays!) [13:27] <millster> actually, there's something you probably don't know: networkx.Graph never gets used [13:27] <millster> nor does networkx.DiGraph [13:27] <malb_> okay, it is compiling now, let's see what make test thinks about it [13:27] <millster> only .XGraph and .XDiGraph [13:27] <grout> Right, I realize that. [13:28] <ncalexan> william_stein: I reverted my worksheet change, but I still cannot load sage -notebook. [13:28] <ncalexan> I'm -upgrade-ing again. [13:28] <grout> millster: However, will a networkx function return a Graph or DiGraph object? [13:29] <grout> millster: then we'd need the init cases for those. [13:29] <millster> i'm not sure what the problem is [13:29] <grout> I've documented it in #716. [13:29] <millster> we have init cases for those [13:30] <grout> If I pass an XDiGraph with multiple edges, then that setting is lost because it is trapped in a more generic case. [13:30] <millster> ok, i think the problem is in the copy function [13:30] <grout> I already changed the copy function. [13:30] <grout> That's one problem, this is another. [13:30] <grout> (I think) [13:31] <millster> you [13:31] <grout> Well, I changed it in my local copy... [13:31] <millster> 're correct- half the problems are in copy, the other half in init [13:32] <grout> (and added a doctest function to check g.copy()==g [13:32] <mabshoff_> william_stein: Can you have a quick look at #718 - if you think it is as obvious a fix as I assume? [13:32] <millster> grout: hang on a sec [13:33] --> robertwb has joined this channel (n=robert@D-69-91-158-249.dhcp4.washington.edu). [13:37] <grout> millster: Actually, I think changing the order of the elif in the init fixes the copy problem as well. [13:37] <mabshoff_> And #719: also libpari related regarding the size of the internal libpari stack and its behavior [13:37] <mabshoff_> when calling pari.allocatemen() [13:38] <millster> oh of course, because in networkx, an xdigraph IS a digraph [13:38] <millster> of course of course [13:38] <grout> Right---test for the subclass before the class [13:38] <millster> that makes perfect sense [13:38] <millster> so switching the two in both init functions fixes everything? [13:38] <grout> I'm testing that... [13:38] <millster> ps, did you find my reply helpful? [13:39] <grout> Yes, very much so (in the few seconds that I scanned it...I think it ought to go in the developer's handbook [13:39] <millster> I'm in the process of doing that now [13:40] <mhansen> william_stein: I have mercurial branch on sage.math with the combinatorics stuff in it. It also has patches against other files that it breaks. I ran -testall and there were 3 errors that came up, but are unrelated to my stuff. [13:43] <william_stein> mhansen -- cool! [13:44] <william_stein> malb_ -- robert and I resolved the merge problems with the ntl bundle, hopefully. [13:44] <mhansen> Do you want a bundle? [13:44] <william_stein> mhansen -- yes. post it to trac. [13:44] <malb_> O really, I didn't so far (lots of doctest failures) [13:44] <malb_> good then, are you pushing it soon? [13:45] <william_stein> we just got it to build. haven't doctested yet! [13:45] <william_stein> But the build problems were mainly caused by new things Robert and I had done. [13:45] <william_stein> I'll push in about 10 minutes, I hope. [13:45] <malb_> good, reverting my stuff then [13:46] <grout> millster: Okay, so I have two different changes (this init fix and a to_simple function). Can I commit just *one* of them? [13:46] <mhansen> william_stein: http://sagemath.org:9002/sage_trac/ticket/630 [13:46] <grout> Does mercurial allow me to pick a hunk to commit, or do I have to commit all the changes in a file? [13:46] <william_stein> all the changes in a file. sorry. [13:47] <william_stein> But you can commit individual files. [13:47] <roed_> william_stein, ncalexan, dmharvey: I just skimmed through ell_rational_field. Just extracting the Lseries functions won't do all that much to shorten it. If we actually want to split it up, there are a bunch of classes of functions that we could split off: padic_height, padic_sigma, etc; functions related to the Tate-Shafarevich group and the BSD conjecture; functions related to various reduction properties (kodaira_type, etc); function [13:47] <millster> it's ok to commit both though, in this case, since they're both things that need to go in... [13:48] <grout> grr...oh well, I suppose that feature will come in time. That's one thing I like about git, svk, darcs, etc. [13:48] <ncalexan> roed_: I don't think it's important to shorten it. I do think it is important to make it more object oriented. I want SAGE to have a concept of an L-series, and that means an object. Do you agree? [13:49] <roed_> I do [13:49] <roed_> For l-series [13:49] <roed_> But not necessarily for some of the other ones [13:50] <roed_> And I do think that shortening it is a valid goal, if only so that it's easier to find and modify code there. [13:50] <ncalexan> Well, should the Tate-Sha group be an associated object, like the formal group? [13:50] <roed_> I think I like that idea [13:51] <william_stein> malb_ -- do hg_sage.pull() [13:51] <millster> grout: awesome idea on ticket 698 [13:51] <grout> Well, it certainly provides enough work to do... [13:51] <millster> grout: you should take a look at the new Maple, too [13:51] <millster> there's a lot of new stuff there [13:52] <grout> millster: I've been meaning to install it for a long time. I heard there were quite a few graph functions in there now. [13:52] <millster> also, i'm working on a graph generator to be included soon [13:52] <grout> I'm just really comfortable with Mathematica. [13:52] <dmharvey> #635: done, kind of. I've posted a patch. It passes all regular doctests, but for -long doctests a few weird things happen. I'm getting spurious segfaults, glibc realloc invalid size errors, sometimes. I'm only touching pretty high level python code so I have no idea why that is happening. [13:52] <grout> millster: graph generator? what do you mean? [13:52] <millster> do you mind sending me a patch with the to_simple and init fixes? [13:53] <millster> i mean an algorithm to quickly generate non-isomorphic graphs subject to some constraints [13:53] <grout> Yes, that's my next question: what should I do with it? post it to #716? [13:53] <dmharvey> roed_, wstein, ncalexan: the patch I just posted for #635 touches ell_rational_field.py, so please take it into account before doing anything else with that file. [13:53] <grout> millster: Nice...up to this point I've used nauty [13:53] <millster> for graph stuff, probably the best idea is to send it to me [13:53] <roed_> what did you do? [13:53] <mhansen> millster: I changed some stuff related to cyclic_permutations_ [13:54] <millster> mhansen - did something break? [13:54] <dmharvey> roed: some slight changes to padic_height related stuff, fixed some precision losses that had occurred with either chris wuthrich's changes or some padic changes [13:54] <roed_> ok [13:55] <mhansen> millster: No, I changed it to use the new CombinatorialClass interface that I wrote. It also handles the cases where there are duplicate elements in the list correctly. [13:56] <millster> just make sure that the graph classes pass doctests- there is some genus code that depends on that [13:56] <mhansen> Yeah, I changed those files and they pass the tests. [13:57] <dmharvey> #697: what's the status with the NTL rewrite? [13:57] <millster> sweet [13:58] <janwil> ok, it's midnight for me and I need to get up early tomorrow ... have a nice BD ... and maybe I will still meet some of you in the morning [13:58] <mhansen> Good night. [13:58] <mabshoff_> william_stein: could you merge #680? I need that one for Solaris 9. [13:58] <-- janwil has left this channel. [13:58] <mabshoff_> It isn't needed any more for Solaris 10, so I need to implement some workaround on the SCons level. [13:59] --> jaap has joined this channel (n=jaap@cc73571-a.emmen1.dr.home.nl). [13:59] <mabshoff_> But on Solaris 10 it ought to only print some warning.- [14:01] <grout> When you do hg_sage.bundle('blah'), does it take the last thing that was committed and bundle that? [14:01] <millster> not quite [14:01] <millster> it compares your version against the official version at sage.math [14:01] <grout> Aah, so you get _all_ my changes, then, right? [14:01] <millster> and bundles everything necessary to bring a copy of the official version up to speed with yours [14:01] --> malb has joined this channel (n=malb@host86-141-245-221.range86-141.btcentralplus.com). [14:02] <millster> correct, all your changes to the branch you've been working on [14:02] <grout> Okay, well, it's just these two changes, so that should be fine. [14:03] <grout> How do you want me to send this to you? [14:03] <mabshoff_> Okay, I am out. I have to leave for the airport in about 5 hours so it wouldn't be bad to catch [14:03] <mabshoff_> a little sleep. [14:03] <mabshoff_> If anybody could comment on #470, #718 & #719 which are all libpari related to memory [14:03] <mabshoff_> consumption. [14:04] <mabshoff_> I will read the logs in a couple hours, so see you. [14:04] <william_stein> cu. have a great trip to italy or wherever. [14:04] <millster> you can just e-mail it to me [14:04] <mabshoff_> Sorry I couldn't close any significant ticket tonight. [14:04] *** mabshoff_ is now known as mabshoff|away. [14:05] <grout> millster: I also changed to_(un)directed to be pass name, pos, and boundary, just like copy did. [14:06] <millster> awesome [14:06] <ncalexan> william_stein: I've attached a patch for 228, added a note, added [with patch], and changed it to 2.8.4.3. [14:06] <william_stein> awesome [14:06] <grout> I assume that that is correct behavior. [14:06] <millster> yeah [14:08] <grout> hmmm...how long is sage -t graph.py supposed to take? [14:09] <grout> millster: How come the digraph class uses "arc" instead of "edge"? I'm always forgetting that and getting mixed up. [14:10] <millster> testing graph.py should take about a minute [14:10] <grout> Especially since networkX uses "edge", so the initial option is "multiedges=True", but ever after it's "arc" [14:10] <millster> it's actually taken some work to enforce that too [14:10] <grout> enforce "arc" instead of "edge"? [14:11] <millster> yeah [14:11] <grout> It seems like it'd be more friendly and consistent to call everything an edge. [14:11] <millster> the original motivation was actually my first teacher for graph theory [14:11] <grout> ahh. [14:11] <millster> he was dogmatic about the distinction, so by default so was i [14:12] <grout> Well, it sure is confusing for me. They look the same (an ordered list in Python). [14:12] <grout> Can I add "edge" functions to DiGraph to either supplement the "arc" functions? [14:14] <-- malb_ has left this server (Read error: 110 (Connection timed out)). [14:15] <grout> Is there any way to run the doctests in verbose mode? I think something's not quite right and it's taking a long time for sage -t graph.py [14:15] <william_stein> sage -t --verbose graph.py [14:17] <william_stein> #228 -- ncalexan -- I'm importing that nnow. [14:19] <millster> by the way, if a doctest fails it will print to screen, so doctesting proceeding silently is good [14:19] <millster> also, if something is wrong, typically it is much faster [14:20] <-- ncalexan has left this server (Read error: 104 (Connection reset by peer)). [14:21] <millster> grout: you should do one thing at a time, but i'm not really opposed changing every "arc" to "edge" [14:21] <millster> don't write *more* functions that do the same thing, though [14:22] <grout> yes, I know...I won't do it today. I also don't want to step on someone's toes if they love the arc functions. [14:22] <millster> nobody has defended them to date [14:22] <millster> anyway, let's have that patch, yes? [14:23] <grout> Sure, I'll post it. The doctest is having a problem, though. [14:23] <grout> is_circular_planar isn't returning the right result. [14:24] <millster> one sec [14:24] <millster> i think that might be an unrelated failure [14:24] <grout> hmmm, all the doctests were passing before. [14:25] <grout> I figured it had something to do with "boundary" not being passed somewhere. [14:25] <millster> send me the patch and i'll take a look [14:25] <malb> wstein, I just dotested the NTL stuff it is all good, however: [14:26] <malb> devel/sage-ntl/sage/monoids/string_monoid_element.py [14:26] <malb> devel/sage-ntl/sage/interfaces/tachyon.py [14:26] <malb> devel/sage-ntl/sage/rings/number_field/order.py [14:26] <malb> failed [14:26] <malb> erm william_stein [14:26] <william_stein> malb -- do hg_scripts.pull() [14:28] <grout> millster: I posted the patch to #716 [14:28] <malb> william_stein: good, only number_field/order.py still fails [14:28] <malb> I won't bother for now, will put some work in LLL [14:28] <malb> #325 [14:28] <dmharvey> malb: REAL programmers have THREE trailing underscores [14:28] <mhansen> number_field/order.py fails for me as well [14:29] <malb> dmharvey yeah because they run Linux on a Macbook Pro == crappy drivers [14:29] <william_stein> malb do hg_sage.pull() [14:32] <malb> all good now [14:33] <grout> millster: sage -t graph_genus1.py fails for the nice_copy function now. [14:33] <millster> grout: i'm still building a 'pull' so i can take a look, hang on a sec [14:34] <boothby> +1 (to robertwb) [14:34] <robertwb> I think everything should be an edge and node (or vertex) [14:34] <millster> +1 to boothby for whatever he says next [14:34] <robertwb> are you reading my mind??? [14:35] * boothby agrees with robert. [14:35] <william_stein> irc is so much fun when you're all in the same room... [14:35] <grout> yeah...and in Iowa too. [14:35] <dmharvey> boothby how did you do that IRC thing [14:36] <mhansen> grout: Iowa? [14:36] <boothby> wha? [14:36] <boothby> OH! /me blablabla [14:36] * boothby blablabla [14:36] <dmharvey> ah [14:36] * dmharvey gets it [14:36] <grout> mhansen: yeah [14:36] [Error] boothby: Unknown command. [14:37] * boothby says hi [14:37] * dmharvey wonders whether one can reflexively /me [14:37] <mhansen> grout: Where in Iowa? [14:37] <dmharvey> nope [14:37] * william_stein picks up sword. [14:37] <grout> Iowa State U. [14:37] * dmharvey is already bored with this new toy [14:38] <malb> /me tries it too [14:38] <mhansen> grout: I'm originally from Waterloo, and have a brother who is a freshman at ISU. [14:38] <malb> mhh, my client doesn't do it [14:38] <dmharvey> huh? [14:38] <malb> escaped or something [14:38] <dmharvey> i thought you had figured out string escaping or something [14:38] <grout> mhansen: huh...is he taking calc? (like calc 2?) [14:39] <mhansen> grout: Nah, he's only in Calc I. He's not as fond of math as his older brother. I think he'll be taking that next semester though. [14:40] * millster verbs profusely [14:40] <grout> mhansen: that's great. Maybe I'll teach calc 2 next semester too. [14:42] <millster> grout: still waiting for stuff to build... [14:42] <grout> millster: I think the problem is that nice_copy in graph_genus1 depends on the copy function to forget the boundary. [14:42] <grout> I made a change so that copies of a graph keep the boundary. [14:42] <millster> i know, i can fix the problem once i'm done building [14:42] <grout> What's a boundary anyway? [14:42] <millster> a privileged subset of the vertices 
[14:42] <roed_> How is the lambda series of an elliptic curve related to the l-series? [14:43] <grout> ahh...I figured that _every_ property ought to be preserved when making a copy, but apparently nice_copy doesn't think so. [14:43] <millster> nice copy was a quick fix to avoid exactly what you fixed [14:44] <millster> but yes, everything about the graph should be copied over, and g == h should check everything [14:45] <roed_> william_stein: How is the lambda series of an elliptic curve related to the l-series? [14:45] <grout> so does that mean that nice_copy is no longer needed? [14:45] <grout> millster: since nice_copy also changes the vertices to be consecutive integers, maybe a new function that relabels the vertices to some list is in order. Don't we already have that? [14:46] <millster> that can be factored out, yeah [14:46] <millster> just give me a moment [14:46] <grout> okay, sorry. [14:47] <william_stein> _hi_ [14:47] <grout> mhansen: what's your brother's name, in case I see him? [14:48] <mhansen> grout: Andrew Hansen [14:48] <grout> I'll keep my eyes open. [14:48] <mhansen> william_stein: Did you want someone to look over my combinatorics patch? [14:48] <william_stein> sure! [14:48] <william_stein> any volunteers? [14:48] <millster> me me me [14:49] <william_stein> I'm finishing up fixing some issues with Robert Bradshaw's patch and will look at yours some next. [14:49] <william_stein> But I'd love somebody else to look first. [14:50] <mhansen> I put a bundle on the trac server, but it's also at /home/mhansen/sage/ on sage.math [14:50] <millster> mhansen: #630? [14:50] <mhansen> millster: Yep -- that's the one. [14:50] <william_stein> what's the issue with "c interface to symmetrica"? [14:50] <millster> cool [14:51] <william_stein> What is symmetrica? [14:51] <william_stein> Do we need to make an spkg? [14:51] <mhansen> There's already one (but its optional at the moment). [14:51] <mhansen> It needs to be installed first. It's a software package for package for doing things related to the symmetric group. [14:52] <william_stein> of course. thanks. [14:52] <william_stein> Should we make symmetrica a standard spkg? [14:53] <millster> hmm, copy is still losing multiple edges [14:53] <mhansen> Yeah, I would like to. It is the backend for symmetric functions and Schubert polynomials. [14:53] <millster> sorry, hang on a sec [14:54] <william_stein> ok. it takes 30 seconds to build on sagemath.org [14:54] <millster> mhansen - anything about kazhdan lutztig poly's? [14:55] <mhansen> millster: For the symmetric group? [14:55] <william_stein> what does symmetrica depend on? [14:55] <millster> yeah, just out of curiosity [14:56] <mhansen> william_stein: I think just gcc. [14:56] <william_stein> on a scale of 1 to 10, how do you rank the quality of symmetrica? [14:56] <grout> millster: copy seems fine here. The code in the comment of #716 works great. [14:57] <millster> no, i was stupid [14:57] <mhansen> millster: I don't think it has that, but I believe I have some routines around for calculating them. [14:57] --> dfdeshom has joined this channel (n=dfdeshom@adsl-068-153-240-182.sip.int.bellsouth.net). [14:57] <dfdeshom> hey guys [14:57] <millster> grout: i see what you mean about graph.py taking forever to test [14:58] <william_stein> mhansen -- what is the license? [14:58] <william_stein> ah, public domain. [14:58] <mhansen> william_stein: 8. The last released version was a little while ago, but I just talked with the author in June, and he has his own CVS version that he's been working on. It is public domain. [14:58] <millster> it was 27secs before the patch, but now it seems to be taking forever [14:59] <mhansen> william_stein: He was interested in the SAGE interface for it since it is just a C library. [14:59] <william_stein> cool. [14:59] <mhansen> william_stein: Magma uses it for its symmetric functions. [14:59] <william_stein> ok, it's in. [15:00] <grout> millster: sage -t --verbose graph_genus1.py tells where the problem is, I think. [15:00] <grout> I like how william approves whatever is in Magma [15:01] <millster> so all i have to do is wrap my code in molten rock? [15:02] <william_stein> could a few people type "sage -i symmetrica-0.2" and let me know if it builds for them? [15:02] <millster> grout: did you ever get testing graph.py to finish? [15:02] <grout> It just worked for me. [15:02] <grout> (symmetrica did) [15:02] <boothby> hey william -- I hear Magma is going to switch to a perl-like language. Can we do the same? [15:02] <grout> um, I vote for lua or ruby [15:02] <grout> millster: no, I killed it. [15:03] <millster> oy [15:03] <grout> adding graph.set_boundary([]) after graph.copy() in nice_copy doesn't seem to fix the problem. [15:03] <millster> what a mess [15:04] * grout bangs head against stone floor, in dobby-like fashion [15:04] <grout> sorry [15:04] <william_stein> mhansen -- how can Symmetrica be version "0.2" after 15 years?! [15:05] <william_stein> Or is the 0.2 something you made up? [15:05] <mhansen> It was my second version of the spkg. [15:05] <mhansen> I don't know if there is an official versioning scheme ;-] [15:06] <grout> Is there a way to examine the changes in a bundle? I'd like to see what I just applied from the combinat bundle. [15:06] <william_stein> hg_sage.incoming('foo.hg'), but this only works if done from a repo that doesn't have those changes [15:06] <william_stein> already applied. [15:06] <grout> oops. [15:08] <mhansen> millster: Here is an example of what the new combinatorics interface looks like. It's heavily inspired by MuPAD-Combinat. [15:08] <william_stein> mhansen, i've now officially included symmetric for the next release of Sage. [15:08] <mhansen> millster: http://wiki.sagemath.org/Combinatorics [15:08] <mhansen> Excellent [15:09] <millster> grout: why did you remove loops from the copy command? [15:10] <grout> I don't think we need them (and the doctests back that up). [15:10] <millster> ok [15:10] <grout> If a XDiGraph is passed, then the structure is set and we never look at the loops parameter. [15:10] <millster> nx takes care of it? [15:11] <grout> Everything except for boundary and pos is stored in _nxg, to my understanding. [15:11] <grout> We had to have them before because we were calling the superclass constructor, which defaulted to no loops. [15:12] <grout> (so we had to pass in the current status) [15:12] <grout> But please double-check everything in case I missed something. [15:12] <grout> (this is my first patch, after all [15:12] <millster> i'm getting very funny copy behavior [15:12] <grout> like what? [15:13] <millster> shallow copying [15:13] <grout> an example? [15:14] <millster> one sec [15:15] <millster> got it [15:16] <grout> an example or a fix? [15:16] <millster> both [15:16] <grout> yeah! [15:16] <grout> care to elaborate? [15:17] * millster begs for patience [15:18] <grout> sorry, sorry [15:19] <millster> sorry to keep you in suspense, i'm cleaning up the rest of the doctests - apparently, we were constructing two sage graph objects that pointed to the same networkx object [15:21] <grout> oops, I guess we should call "copy" in the copy functions...duh. [15:22] <millster> it's amazing how many doctests can break when you make such a small change [15:22] <william_stein> #228 -- excellent work ncalexan [15:23] <grout> millster: are you calling the networkx copy function in our copy function or our init function? [15:31] <roed_> ncalexan, william_stein: track 721 outlines a plan for splitting ell_rational_field [15:34] <grout> millster: I guess all of the tests that depended on to_directed or to_undirected to not pass the name fail, plus one with an extra space. Is that what you got? [15:35] <william_stein> roed_ -- i'll check it out shortly. [15:35] <roed_> ok [15:38] <william_stein> roed_ looks good to me. Robert Bradshaw is also looking the plan over. [15:39] <william_stein> mhansen -- gees that's a big patch! [15:39] <millster> grout: essentially, yeah [15:40] <mhansen> william_stein: Yeah, it feels a little weird calling it a 'patch' [15:40] <grout> millster: do you want to send me back a new patch (or please tell me somehow how to get it?) [15:40] <millster> still ironing out the kinks, but i'm almost done [15:41] <grout> mhansen: that's giganormous...I'd call it a quit at least [15:41] <grout> I man, quilt [15:41] <grout> I mean, quilt [15:41] <millster> grout: All tests passed! [15:41] <mhansen> Yay! [15:41] <grout> yeah! I presume that they're correct too :)... [15:42] <millster> that's another matter entirely [15:42] <grout> I really like the "new" feature that sage: H = G.subgraph([0,1,2]); H returns Subgraph of (Complete graph): Graph on 3 vertices [15:42] <grout> (the name indicates how you got the graph) [15:42] <millster> it was supposed to do that all along, and i couldn't figure out why it wasn't [15:43] <william_stein> mhansen -- you'll want to do some work to get the relevant autogenerated docs from your code into the reference manual, ok? [15:43] <william_stein> that can wait a little until things stabilize, though. [15:43] <william_stein> this means editing SAGE_ROOT/devel/doc/ref/ [15:43] <william_stein> mhansen -- all tests pass in combinat/ [15:43] <grout> millster: If you'd send me the patch, I'd love to do one more---the changing arcs to edges, if we're all unanimous on that [15:44] <grout> Of course, such a huge change probably requires approval from our supervisors... [15:44] <mhansen> william_stein: Great! [15:47] <millster> grout: check ticket 716 again [15:47] --> malb_ has joined this channel (n=malb@host86-141-245-221.range86-141.btcentralplus.com). [15:48] <millster> grout: if you're doing the arc to edge change, the only file you'll need to touch is graph.py itself [15:48] <millster> it should be as simple as a find/replace where you make sure you're not catching words like search [15:49] <millster> ps - consider it approved [15:50] <millster> grout: have you used hg_sage.browse() yet? [15:50] <grout> hmmm...I'm not sure. I don't think so. [15:50] <millster> it's great [15:51] <millster> you apply the bundle i posted, then do that, and your web browser will open up and you can see only what was changed [15:51] <grout> oh yeah, I've seen it, but not used it. [15:51] <mhansen> william_stein: I also have a patch for tut.tex. [15:52] <mhansen> I attached it to #630 [15:55] <grout> millster: um, I think we should call the copy in the init function, like networkX does. [15:55] <grout> so if g is a graph, calling Graph(g) makes a copy of g. [15:56] <grout> instead of calling the copy in the "copy" function. [15:57] <millster> that's not how it happens [15:57] <grout> I must be confused. [15:57] <grout> networkx_graph() returns a copy. [15:57] <millster> sage: G = Graph() [15:57] <millster> sage: G == Graph(G) [15:57] <millster> True [15:57] <millster> sage: G is Graph(G) [15:57] <millster> False [15:58] <millster> you mean we should use ._nxg.copy() instead of .networkx_graph()? [15:59] <grout> Yeah, but what if G is a _nxg? Then it's not copied in Graph(g) [15:59] <william_stein> mhansen -- interestingly the *old* partitions function is way faster than your new one...?? [15:59] <william_stein> old: [15:59] <william_stein> sage: time v=list(partitions(30)) [15:59] <william_stein> CPU times: user 0.03 s, sys: 0.00 s, total: 0.03 s [15:59] <millster> aha [15:59] <william_stein> new: [15:59] <william_stein> sage: time v=Partitions(30).list() [15:59] <william_stein> CPU times: user 0.46 s, sys: 0.02 s, total: 0.48 s [15:59] <millster> grout: now i get it [15:59] <-- malb has left this server (Read error: 110 (Connection timed out)). [16:00] <millster> so replace "self._nxg = data" with "self._nxg = data.copy()" twice? [16:01] <grout> hang on a sec, I got a phone call... [16:01] <malb_> william_stein: I've added some code to #325 [16:01] <william_stein> I'll take a look. [16:01] <malb_> It doesn't integrate pari yet but the pari function is callable from SAGE [16:02] <mhansen> Yeah, I haven't done any real optimization yet. It'll get there though. But, the new one provides an actual iterator so that you don't need to store all of them in memory at once. [16:02] <william_stein> the old one was an iterator. [16:02] <william_stein> I posted the code on trac. [16:02] <grout> millster: Yes, that was what I was thinking. [16:02] <william_stein> Maybe have both functions... [16:03] <grout> millster: and remove the .copy from the copy function. [16:03] <millster> sounds fair [16:04] <william_stein> #325 -- malb, looking at it now. [16:04] <william_stein> mhansen -- I think just including your code in the next Sage is a good idea. [16:04] <william_stein> It will be very helpful to get a lot of feedback. [16:04] <grout> millster: Of course, it's slower, though. For example, to_directed then makes a copy of a copy. [16:04] <william_stein> But I think you should send me a patch that puts the old partitions function back in too (as an alternative to Partitions(n).list()), [16:04] <william_stein> and similarly for other things you might have deprecated. ??? [16:05] <grout> millster: hmm...It might be better to have it the way you have it, even if it's not consistent with networkX [16:06] <william_stein> malb -- your patch is weird. [16:06] <millster> consistency with networkx is not one of my concerns- they do some things very silly [16:06] <grout> If g is a Sage Graph, then Graph(g) is a copy. [16:06] <william_stein> #325 -- It implements pari lll, but then implements lll over ZZ using ntl. [16:06] <grout> millster: If g is a networkX graph, then Graph(g) is a wrapper around that exact graph. [16:06] <malb_> yes [16:06] <malb_> exactly [16:07] <william_stein> Did you do timings and NTL always crushes PARI? [16:07] <grout> millster: That's how it works now with your patch, if I understand things right. [16:07] <malb_> no not at all [16:07] <mhansen> william_stein: I just see the partitions wrapping GAP (not an iterator). I can add back the old functions in combinat.py that I replaced. A lot of them are still there -- just wrapped in CombinatorialClass objects. [16:07] <malb_> I went for NTL first because I understood better what needs to be done [16:07] <millster> yes, the way it is now [16:07] <william_stein> so shouldn't the lll for mat over ZZ always have an option "algorithm = " that can also call PARI? [16:07] <william_stein> mhansen -- see trac #630. [16:07] <william_stein> The partitions function doesn't have anything to do with Gap. [16:07] <mhansen> william_stein: I just found the partitions generator. [16:07] <malb_> yes it should, but I might have to do that later [16:08] <malb_> it is not finished yet [16:08] <william_stein> It's from the cookbook. [16:08] <william_stein> ok, good. [16:08] <malb_> but the ticket could change to improve LLL [16:08] <grout> millster: I guess that makes sense, since people shouldn't deal with the underlying networkX object, so they won't have surprises, and we'll just be careful to make copies when we mean to make copies. [16:08] <william_stein> malb -- #325 -- good, i understand. [16:08] <william_stein> got it. [16:08] <william_stein> malb -- new ticket. [16:08] <william_stein> i'll apply and post #325 now. [16:08] <millster> the only reason someone is going to start playing aroung with networkx graphs is if they're pretty advanced [16:08] <malb_> okay, I gotta bail out for tonight that's why I am posting it already [16:09] <william_stein> I'm also posting mhansen's code, so peoplke will have to install symmetrica to do hg_sage.pull(). [16:09] <william_stein> ah, malb_ cu [16:09] <malb_> cu [16:09] <millster> grout: can you add something to the documentation about all this? specifying that the behavior is on purpose, why, and a docstring exemplifying it? [16:09] <millster> it's a pretty subtle point [16:09] <grout> millster: okay, let's do it the way the patch is now. Are we sure that there are no more problems with not copying when we mean to. [16:09] <-- malb_ has left this server (Read error: 104 (Connection reset by peer)). [16:10] <millster> all doctests pass, that's the best thing [16:10] <grout> millster: hmmm, then again, every other way of constructing the graph makes a copy. [16:11] <millster> i think we're fine [16:11] <grout> okay. [16:12] <millster> grout: can you document this decision? [16:12] <grout> I'm doing it now. [16:12] <millster> awesome [16:13] <grout> All of sudden I'm getting errors when doing sage -br. I just did a hg_sage.pull(). The errors come from "building 'sage.libs.flint.fmpz_poly' extension" [16:14] <grout> gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/grout/sage/sage-2.8.3/local/include/FLINT/ -I/home/grout/sage/sage-2.8.3/local//include -I/home/grout/sage/sage-2.8.3/local//include/python -I/home/grout/sage/sage-2.8.3/devel//sage/sage/ext -I/home/grout/sage/sage-2.8.3/local/include/python2.5 -c sage/libs/flint/fmpz_poly.c -o build/temp.linux-i686-2.5/sage/libs/flint/fmpz_poly.o -std=c99 -w [16:14] <millster> do sage -i flint-0.2.p2 [16:14] <grout> sage/libs/flint/fmpz_poly.c:30:19: error: flint.h: No such file or directory [16:14] <william_stein> grout -- you have to install flint. [16:14] <william_stein> And symmetrica in a few minutes. [16:15] <grout> okay, working better now. Thanks. [16:16] --> tornaria has joined this channel (n=tornaria@r190-0-137-63.dialup.adsl.anteldata.net.uy). [16:16] <grout> millster: Are you sure it's okay to completely break backward compatibility and change "arc" functions to "edge" functions? Shouldn't we at least include them for one more release, in a deprecated state? [16:17] <grout> Is there a way to mark a function as deprecated, so that it maybe prints out a warning each time it's used, but it still works? Seems like some scripting language does this (python?), and it's handy for the transition. [16:17] <millster> nobody will miss it [16:18] <grout> okay, okay. [16:18] <millster> i think it's a bit early to worry about backwards compatibility yet [16:18] <grout> hmmm...I should remember that---I already put SAGE code in my dissertation and a few papers... [16:19] <millster> just say what version you were using [16:19] <grout> I did. I'm glad william archives the versions. [16:20] <grout> Part of the reason for including the code was to give people a taste for SAGE---some examples of code. [16:21] <william_stein> the archives also on all of the mirror sites. [16:21] <william_stein> seriously though, stability of the interface to Sage will be a very important goal for Sage once there [16:21] <william_stein> are more users. [16:21] <william_stein> There are still probably < 1000 users. [16:22] <mhansen> william_stein: I made it so that Partitions(n).list() uses (a modifed version of) partitions. I'll include that with a patch restoring the old functions in combinat.py once the new stuff is ready to pull(). [16:23] <william_stein> it's ready to pull [16:23] <mhansen> sage: time v = Partitions(30).list() [16:23] <mhansen> CPU times: user 0.04 s, sys: 0.01 s, total: 0.04 s [16:23] <mhansen> Wall time: 0.04 [16:23] <william_stein> sweet! [16:25] <dmharvey> #528 progress report: things are starting to work. Already multiplying (2*x+4) by 3 is about 4x faster, just from improved overhead. Still a factor of 3 or 4 behind magma, to the extent that the comparison makes sense. [16:26] <grout> millster: Am I not understanding something? How come I'm getting false with the following? [16:26] <grout> sage: g = networkx.Graph({0:[1,2,3], 2:[5]}) [16:26] <grout> sage: G = Graph(g) [16:26] <grout> sage: H = Graph(g) [16:26] <grout> sage: G._nxg is H._nxg [16:26] <grout> False [16:27] <william_stein> what about G._nxg == H._nxg? [16:27] <grout> still false. [16:28] <grout> sage: G._nxg [16:28] <grout> <networkx.xgraph.XGraph object at 0x9d360ac> [16:28] <grout> sage: H._nxg [16:28] <grout> <networkx.xgraph.XGraph object at 0x9d3602c> [16:28] <grout> They appear to be two different networkx objects. [16:30] <william_stein> They *are* two differnet objects. [16:30] <millster> yeah, but they shouldn't be [16:30] <grout> I found it. I should do g=networkx.XGraph... [16:30] <millster> oh i see [16:31] <grout> sage: G._nxg is G._nxg [16:31] <grout> True [16:31] <grout> sage: G._nxg is H._nxg [16:31] <grout> True [16:31] <millster> subtlety on subtlety [16:32] <william_stein> dmharvey -- excellent. [16:33] <millster> grout: try True + Ture [16:33] <grout> error...Ture is not defined [16:34] <grout> ?? [16:34] <william_stein> sage: True + True [16:34] <grout> True+True==True [16:34] <grout> (two truths make a lie?) [16:35] <william_stein> mhansen -- is this right? [16:35] <william_stein> sage: a = Partitions(6) [16:35] <william_stein> sage: a.rank() [16:35] <millster> right, stop that, the lot of you! this has gotten entirely too silly! [16:35] <william_stein> <type 'exceptions.TypeError'>: rank_from_iterator() takes exactly 2 arguments (1 given) [16:35] <william_stein> a.rank? [16:35] <william_stein> nothing [16:35] <-- jkantor has left this server (Read error: 110 (Connection timed out)). [16:36] <mhansen> rank takes in a partition, and returns its position in the list. [16:36] <william_stein> i see. [16:37] <mhansen> sage: a = Partitions(6) [16:37] <mhansen> sage: a.rank([6]) [16:37] <mhansen> 0 [16:38] <mhansen> I still need to add documentation to CombinatorialClass. It provides default implementations for subclasses which don't provide a more specialized method. [16:38] <william_stein> mhansen -- why do you do: [16:38] <william_stein> sage: a = Partitions(6) [16:38] <william_stein> [16:37] <mhansen> sage: a.rank([6]) [16:38] <william_stein> [16:37] <mhansen> 0 [16:38] <william_stein> rank = rank_from_iterator [16:38] <william_stein> I mean, why do you do? "rank = rank_from_iterator"? [16:39] <mhansen> That's the default implementation. [16:39] <mhansen> Subclasses should override rank if there's a better algorithm for computing the rank of an object. [16:39] <william_stein> Yes, but why do you do "rank = rank_from_iterator"? [16:39] <william_stein> What does that accomplish? [16:39] <william_stein> Why not just define rank? [16:41] <mhansen> To detect when the method has been overwritten. [16:42] <william_stein> ah, I see. Interesting. [16:42] <william_stein> Wow, there's a lot of new code you've written. Over 20000 lines. Gees. [16:42] <mhansen> A lot is doctests though. [16:42] <mhansen> def iterator(self): [16:42] <william_stein> good. [16:42] <mhansen> if ( self.first != self.first_from_iterator and [16:42] <mhansen> self.next != self.next_from_iterator ): [16:42] <mhansen> return self.iterator_from_next() [16:42] <mhansen> elif ( self.last != self.last_from_iterator and [16:42] <mhansen> self.previous != self.previous_from_iterator): [16:42] <mhansen> return self.iterator_from_previous() [16:42] <mhansen> elif self.unrank != self.unrank_from_iterator: [16:42] <mhansen> return self.iterator_from_unrank() [16:42] <mhansen> elif self.list != self.list_from_iterator: [16:43] <mhansen> return self.iterator_from_list() [16:43] <mhansen> else: [16:43] <mhansen> raise NotImplementedError, "iterator called but not implemented" [16:43] <william_stein> ahhh [16:43] <william_stein> ok. [16:49] <grout> millster: is there a way to send you just the changes I just made? [16:49] <grout> (the doc changes_) [16:49] <millster> bundle [16:49] <millster> put it on trac, or e-mail it to me [16:52] <grout> okay, it's on trac. Do you want to take a look? [16:52] <grout> doctests pass for me. [16:52] <millster> looking now [16:53] <william_stein> fyi: If you do "sage -upgrade" right now, you'll get updated symmetrica and linbox. [16:53] *** mabshoff|away is now known as mabshoff_. [16:53] <mabshoff_> Hi, I am back. [16:53] <william_stein> This will be needed for hg_sage.pull() in a moment. [16:53] <william_stein> mabshoff_: are you about to go to the airport? [16:54] <millster> grout: looks good [16:54] <mabshoff_> william_stein: I gotta get ready in about 75 minutes [16:54] <william_stein> i'm trying out sparse mod p linear algebra from Linbox in Sage now, via Martin's patch. [16:54] <mabshoff_> I just released gmp 4.2.2 and mpfr 2.3 on Windows binaries. [16:54] <mabshoff_> I promised to do that and I woke up after 3 hours of sleep. [16:55] <mabshoff_> Now I will try to do the IML spkg and finish the LinBox teleconference summary. [16:57] <dmharvey> mabshoff_: I had always assumed you just never slept at all! How disappointing. [16:57] <mabshoff_> Well, maybe I have a team of gnomes work in shifts to pretend it is me [16:57] <mabshoff_> But I am just as suprised as you that I woke up that early, I had hope I would sleep 2 more hours. [16:57] <william_stein> mabshoffbot. [16:58] <mabshoff_> [16:58] <mabshoff_> Initially I wasn't sure if I had ignored my alarm and that it was way too late to catch the plane. [16:58] <mabshoff_> But that wasn't the case. [16:58] <mabshoff_> william_stein: #629 (DSage fixes) is ready to go int. [16:58] <mabshoff_> in [16:59] <mabshoff_> I also tested it on PPC 32 and it works fine. [16:59] <william_stein> excellent. [16:59] <mabshoff_> All doctests for 2.8.4.2 passed on PPC 32, but that was yesterday [16:59] <mabshoff_> And I talked to the admin at the univeritsy today. I might soon get a 1.8GHz G5 to play with. [17:00] <mabshoff_> i.e. 64 bit PPC Linux with 100 mbit hookup and me as root [17:00] --> jkantor has joined this channel (n=jkantor@cpe-76-180-115-46.buffalo.res.rr.com). [17:01] <william_stein> nice. [17:03] <mhansen> william_stein: I added patches to #630. [17:06] <william_stein> #629 -- applying now. [17:06] <mabshoff_> Coo, how about #680? [17:08] <william_stein> done. [17:08] <millster> grout: i just changed all arcs to edges [17:08] <grout> grr, I'm only half-way through. [17:08] <mabshoff_> ok, that needs a little work for Solaris 10 down the road, but I can fix that, too. [17:08] <millster> don't worry about it [17:08] <grout> But I'm also deleting redundant code and redundant docs [17:08] <grout> did you do that too? [17:08] <millster> aha [17:09] <millster> wait a sec [17:09] <grout> [17:09] <millster> i'll send you a bundle [17:09] <millster> i did arc -> edge but not redundant code [17:09] <millster> so you can do that part [17:09] <grout> I figured it was much easier to spot the redundant code while changing arcs to edges, so I didn't do the fast search/replace first. [17:09] <grout> basically a lot of the product functions are half the size now. [17:10] <-- dfdeshom has left this server (Read error: 113 (No route to host)). [17:10] <william_stein> mhansen -- i've applied the rest of #630 [17:10] <millster> grout: okay, go for it [17:10] <william_stein> mabshoff -- new iml spkg? [17:10] <william_stein> #656 [17:11] <mabshoff_> Working on it. Ran out of space on /home. fixing that right now. [17:11] <grout> thank goodness for emacs recursive editing while searching and replacing, as well as the block indenting/unindenting [17:12] <millster> grout: once you finish eliminating the redundancies, i think we should close ticket 716 [17:19] <grout> yeah, we've kind of gone beyond 716 now. [17:19] <grout> Which reminds me...I'll open up another ticket, but I ran into something a while ago. [17:19] <grout> I was reading in a graph6 string that had a backslash. [17:20] <millster> oh god [17:20] <grout> apparently Python intepreted the backslash to be an escape character. [17:20] <grout> Yeah, it was ugly. [17:20] <millster> ok - open a ticket, i'll deal with it later [17:20] <grout> I know now to use r" " [17:20] <millster> i know about this issue, but... [17:20] <grout> I think the graph6 code ought to generate an error when the string is too short. [17:20] <grout> you should be able to detect that. [17:21] <grout> (Brendan does, anyway, and my Mathematica code does) [17:21] <grout> or when the string is too long. [17:21] <millster> ? [17:21] <william_stein> MemoryError: too much memory [17:21] <grout> You know exactly how many bits you need from the first character of the graph6 string. [17:22] <millster> this is definitely a ticket for the future [17:22] <grout> Is that what the ? refers to? [17:22] <millster> there isn't much checking in the to/from graph6 stuff [17:22] <grout> Yeah, I noticed. [17:22] <grout> I didn't realize the backslash was an escape character until much later, when I realized my graphs were corrupt. [17:23] <grout> Well, they were still valid graphs, but they weren't the graphs I had put in. [17:23] <grout> (I thought didn't interpret escape characters, like in bash) [17:24] <william_stein> mhansen -- i'm looking at #691 now. [17:25] <william_stein> good. [17:25] <grout> I hope these changes from arc to edge don't affect a huge amount of stuff elsewhere in SAGE [17:26] <millster> i wouldn't worry about that [17:26] <william_stein> Try search_src('\.arc') [17:27] <mhansen> Heh, I used it in a couple of places ;-] [17:27] <william_stein> combinat/skew_partition.py: sage: dag.arcs() [17:27] <grout> Thanks, that's exactly what I needed! [17:27] <grout> (the search_src) [17:27] <william_stein> search_src and search_doc are your friends. [17:27] <millster> rather, i would worry about that [17:27] <william_stein> mhansen -- did you use it only in skew_partition? [17:28] <grout> Yup, I had a doctest failing, somewhere, something was using arc. Using search_src, easy as cake to find! [17:28] <millster> grout: do you still have my e-mail address? [17:28] <mhansen> I also use it in permutation.py. [17:29] <mabshoff_> william_stein: iml 1.0.1 vs 1.0.1.p6.spkg diff is about 420 lines. [17:29] <mabshoff_> I plan to send that to Arne & Clement, so hopefully they will do a 1.0.3 release with the added featurs. [17:29] <william_stein> cool. [17:29] <mhansen> You'll also want to search for "add_arc". [17:29] <mabshoff_> porvided you and malb release the changes officially which I assume will happen [17:30] <millster> "_arc" and "\.arc" should cover everything [17:30] <grout> what you do *not* want to search for is "search"...I can't believe how many times we used "search"! [17:30] <mabshoff_> I will just patch in the bits from 1.0.1->1.0.2 diff expect the new configure crap [17:30] <mabshoff_> because the used autoconf 2.61 vs. 2.59, so the diff is huge. [17:30] <mabshoff_> If it breaks I will fix it down the road [17:31] <mabshoff_> (and we will skip the update for now) [17:31] <grout> millster: I think I have your email from your email to the newsgroup. [17:32] <millster> i thought we had had correspondence before, but i can't find any messages [17:32] <tornaria> ? [17:32] <grout> oh yeah, something about a bug in the graph drawing code. [17:32] <grout> (the colors dictionary or something) [17:33] <grout> okay, all doctests pass with the arc->edge functions for the graph.py [17:33] <mhansen> Do you want me to posts patches for my stuff? [17:33] <millster> all doctests in graph.py, or all doctests everywhere? [17:34] <grout> no, just sage -t graph.py [17:34] <millster> because i already tested graph.py [17:34] <grout> (which required also changing the isomorphism file) [17:34] <millster> does this include removing redundancies? [17:34] <grout> yes. [17:34] <millster> sweet [17:34] <grout> I'll post a bundle right away. [17:34] <millster> mike h's code too? [17:34] <grout> uh, no, just graph.py and the NICE file. [17:35] <millster> ok [17:35] <grout> okay, it's up on #716. [17:35] <grout> Do we wait to close #716 until it's been officially integrated into the main SAGE? [17:35] --> tclemans has joined this channel (n=Miranda@68.178.77.126). [17:36] <tclemans> I'm Timothy Clemans Seattle, WA Currently in Vancouver, Washington [17:36] <william_stein> grout: yes. [17:36] <william_stein> hi tclemans. [17:37] <tclemans> working on #643 [17:38] <grout> okay, I'll leave it to others to close 716 whenever is proper. [17:39] <mabshoff_> We should really spend some time on all the open notebook issues. [17:39] <grout> I've got to run, but thanks everyone for being so friendly and helpful. This has been a great experience---so good that I put off everything else that I should have done today! [17:39] <tclemans> #643: my example pages do not use table at top but divs is it best to rewrite top that way or use current table? i know that current table has nested tables and when i made an id for it js did not find true height of it [17:40] <mhansen> grout: See ya! [17:40] <mabshoff_> by [17:40] <grout> quit [17:40] <william_stein> by [17:40] <grout> grrr...need to figure out how to quite irss [17:40] <-- grout has left this server ("leaving"). [17:41] <mhansen> I added at patch on #716 for my code. [17:42] <millster> grout: one comment [17:42] <millster> the distinction between vertex and node [17:42] <mabshoff_> he is gone [17:42] <millster> i think of vertices as the points of graphs [17:42] <millster> oh [17:42] <millster> right [17:42] * millster grins sheepishly [17:43] <millster> for those of you listening, i think of nodes as parts of the search tree in isomorphism testing... [17:43] <mabshoff_> Well, he might read the log at some point [17:43] <mhansen> millster: http://math.univ-lyon1.fr/~ducloux/coxeter/coxeter3/english/coxeter3_e.html does KL polynomials for arbitrary Coxeter groups. [17:44] <millster> i was aware of this program, but thanks [17:45] <millster> mhansen -- can you do me a favor? [17:45] <mhansen> I have code to do it for S_n, I just need to track it down. [17:45] <mhansen> Sure. [17:47] <millster> i'm about to pull all the new stuff together [17:47] <tclemans> #643: my current example page is http://tclemans.nonlogic.org/snb/notebook-top-091407-0310.html [17:47] <millster> there will be a few issues with arc -> edge stuff [17:47] <millster> but i am now waiting for a 15 minute build... [17:48] <-- robertwb has left this server. [17:50] <-- jkantor has left this server ("leaving"). [17:53] <mhansen> Be right back. [17:53] <-- mhansen has left this server ("Leaving"). [17:56] <tclemans> #643: it would be nice if the notebook css was tidied http://floele.flyspray.org/csstidy/css_optimiser.php [17:57] <tornaria> I'm looking at #710 [17:57] --> mhansen has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [17:58] <millster> still building [18:02] <-- tclemans has left this server ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org"). [18:09] <mabshoff_> william_stein: new IML spkg attached to #656 [18:09] <mabshoff_> passes sage -ba, still waiting on .testall [18:09] <mabshoff_> -testall obviously. [18:10] <mabshoff_> But it is a hack, once your's and malb's changes are merged back in we should rebase against 1.0.3 [18:10] <william_stein> #656: awesmoe [18:10] <mabshoff_> I am sending an email about the diff 1.0.1.p6 vs. vanilla 1.0.1 now. [18:11] <mabshoff_> The diff is at http://sage.math.washington.edu/home/mabshoff/iml-1.0.1-1.0.1_sage-diff [18:11] <millster> mhansen -- i'll run a sage -t on the combinat module, is there anything else i should check? [18:11] <mabshoff_> about 420 lines, so it isn't too bad to merge back in manually. [18:12] <mhansen> millster: Nope -- that should be enough. [18:12] <millster> easy enough [18:13] <tornaria> on #710 [18:13] <tornaria> seems a bit nasty, not sure how to fix it. [18:14] <william_stein> yep. [18:14] <william_stein> it's been there for a long time. [18:14] <william_stein> but nobody reported it. [18:14] <william_stein> at least it is easy to replicate. [18:15] <tornaria> thing is [18:15] <mabshoff_> Okay, IML email is out. [18:15] <tornaria> I wrote replacements for _sig_on and _sig_off [18:15] <william_stein> mhansen -- your symmetric package won't build on osx [18:16] <tornaria> They are called "_pari_sig_on" and "_pari_sig_off" [18:16] <william_stein> I made a new version of it, by the way vesion 0.3. So use that instead of whatever you have... [18:16] <tornaria> But they are supposed to be run in pairs. [18:17] <mhansen> william_stein: Your package fixes the error on OSX? [18:17] <tornaria> However, functions in gen.pyx call _sig_on (which is somehow rewritten as _pari_sig_on) but don't call _sig_off [18:17] <tornaria> Somewhere it is called implicitly. [18:18] <william_stein> not yet. [18:18] <william_stein> I just discovered the error. [18:18] <william_stein> I'm working on fixing it. [18:18] <william_stein> I hope symmetrica works on os x! [18:18] <william_stein> P.new(...) calls _sig_off. [18:18] <william_stein> P.new_gen [18:18] <tornaria> Maybe it's not being rewritten as _pari_sig_off [18:18] <tornaria> Will check... [18:19] <william_stein> Yep. it calls _sig_off! [18:20] <william_stein> but that shouldn't matter, since you make _pari_sig_off and _sig_off the same in pari_err.pxi [18:20] <william_stein> It's line 5595, by the way... [18:22] <tornaria> yes.. the gen.c is correct.. [18:23] <tornaria> misc.h defines _pari_sig_on and _pari_sig_off [18:24] <tornaria> it's roughly _sig_on and _sig_off with an extra pair of _pari_catch and _pari_endcatch [18:24] <tornaria> the latter should set the signal handler and reset it resp. [18:24] <tornaria> defined in pari_err.h [18:24] <tornaria> (I believe stolen from gp code) [18:24] <william_stein> idea: let's just try it with the classical _sig_on / _sig_off and see if the error still happens. [18:25] <william_stein> It'll be a good test. [18:25] <william_stein> ... trying now. [18:25] <william_stein> mhansen -- i got it to build on os x. [18:25] <tornaria> s/signal handler/pari error handler/ [18:25] <mhansen> william_stein: Excellent -- what was the issue? [18:26] <tornaria> ok, I'll do that. [18:26] <william_stein> http://sagemath.org/packages/standard/symmetrica-0.3.1.spkg [18:26] <william_stein> malloc.h isn't in /usr/include or the standard include path on osx. had to add a -I to the makefile. [18:28] <william_stein> tornaria that didn't work [18:28] <tornaria> malloc should be defined in <stdlib.h>, isn't it? [18:29] <mhansen> william_stein: symmetrica-0.3.1.spkg builds fine for me. [18:29] <tornaria> Are you sure it did recompile? I have to touch lots of files (still compiling) [18:29] <tornaria> (I probably touched some .pxd files that forced too much to be recompiled) [18:29] <william_stein> there are a lot of mallocs on os x (and my machine): [18:29] <william_stein> bsd:~ was locate "/malloc.h" | wc -l [18:29] <william_stein> 16 [18:30] <tornaria> I guess gen.pyx should be recompiled at least. [18:30] <william_stein> All I did was replace the line that includes pari_err.pxi with including interrupt.pxi in gen.pyx. [18:30] <william_stein> So only gen.pyx must be recompiled. [18:30] <tornaria> yep... [18:31] <tornaria> I changed misc.h and recompiled lots of stuff, but still SEGV [18:32] <tornaria> at least I'm not to be blamed... :) [18:32] <mabshoff_> william_stein: -testall passes with the new IMP spkg on sage.math [18:32] <tornaria> (for the pari_catch stuff, I mean) [18:33] <mabshoff_> there were some failures in one of the tex files, but those were related to algebra [18:33] <mabshoff_> In const.tex [18:33] <william_stein> i've tested it some too. [18:33] <william_stein> it's in. [18:33] <mabshoff_> But I haven't updated since the initial build about 8 hours or so ago. [18:34] <mabshoff_> cool [18:34] <william_stein> close it. [18:34] <mabshoff_> will do [18:34] <mabshoff_> I ticket a day ... [18:35] <dmharvey> mabshoff: are you on a plane now? [18:35] <mabshoff_> not yet, about to leave in 10 minutes. [18:35] <mabshoff_> And I am going by train first, then two short hops Düsseldorf->Zürich, Zürich->Milano. [18:35] <dmharvey> heh..... so soon we get to see you simultaneously fly, code, and sleep [18:36] <mabshoff_> Maybe, I have to work on the simultaneous. [18:36] <dmharvey> well I can press two keys on my keyboard at the same time [18:36] <mabshoff_> :) [18:37] <mabshoff_> #656 is closed. [18:38] <mabshoff_> I would like to hear William's opinion on #718 and maybe #719 [18:38] <mabshoff_> I got 10 more minutes :) [18:39] <mabshoff_> #672 and #673 should also be easy to fix, it seems Solaris prints NaN instead of nan and inf vs. Infinity [18:39] <william_stein> I totally agree with #718. [18:39] <william_stein> Though one has to be very careful with state and precision. [18:39] <mabshoff_> okay, I assume you just have to import the right instance [18:39] <mabshoff_> and use that. [18:40] <mabshoff_> In other places of the code they do use the same pari instance. [18:40] <william_stein> no on #719. [18:40] <mabshoff_> ok [18:40] <william_stein> Lots of pari is unusable with < 100MB stack. [18:40] <william_stein> And it's a *serious* pain to have to do it randomly in the middle of computations. [18:40] <mabshoff_> really? That sucks. [18:40] <william_stein> PARI doesn't automatically double the stack. [18:40] <william_stein> The pari memory system is absolutely terrible. [18:40] <mabshoff_> Well, but the doubling of the stack past 512MB seems crazy [18:41] <mabshoff_> I can second that, I actually looked at some of the code and oooooooooooooooooooh [18:41] <william_stein> Usually when asked about PARI and memory, the response on the mailing list is "just allocate a 2GB stack" [18:41] <mabshoff_> lol [18:41] <mabshoff_> Maybe it is time for pari 3 with a sane memory model. [18:41] <dmharvey> yeah but it saves valuable cycles at very low levels [18:41] <mabshoff_> Well, but that mode is so '60s [18:41] <dmharvey> actually maybe that's not true [18:42] <dmharvey> hmmmmmm [18:42] <mabshoff_> stack allocation sucks. [18:42] <mabshoff_> slab allocators are much better and I believe their garbage collection might hmm, [18:42] <mabshoff_> let's say can be improved. [18:42] <mabshoff_> Valgrind croaks on if it busts its heap, so I am sure there are some gremlins in there. [18:43] <mabshoff_> Well, gotta go. [18:43] <mabshoff_> Should be online at some point on Friday, but only dial up, so that will suck [18:43] <mabshoff_> cu [18:43] <-- mabshoff_ has left this server (Remote closed the connection). [18:43] <william_stein> cu [18:45] <william_stein> changing the pari memory model is nearly impossible. Seriously. [18:45] <william_stein> I wouldn't dare. [18:45] <william_stein> It means rewriting essentially every function in the entire library. [18:49] <tornaria> on pari stack: [18:50] <tornaria> if you allocate a very large stack, but don't use it, it won't actually use real memory [18:50] <tornaria> (hopefully you are 64bits where virtual memory space is big) [18:51] <tornaria> however, pari functions don't know about using the stack conservatively. [18:52] <tornaria> I.e. pari functions will use plenty of memory in the stack (tipically half of the available space when they are invoked) [18:53] <tornaria> So, memory will be trashed, and then all the stack becomes real memory (well... or trash in the disc) [18:54] <tornaria> The way GP addreses this is: the stack is reallocated every input [18:55] <tornaria> I.e. when eval an expression, pari stack is allocated, expression is eval'ed using the stack, result is copied to heap, the stack is freed. [18:55] <tornaria> (or so I believe) [18:56] <william_stein> mhansen -- are you around? [18:59] <mhansen> Yeah [18:59] <william_stein> did you doctest partition.py ? [19:00] <mhansen> I still have some stuff left to do in it. [19:00] <william_stein> didn't think so :-) [19:00] <-- mhansen has left this channel ("Leaving"). [19:00] --> mhansen has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:00] <william_stein> come back [19:01] <mhansen> Wait, are you talking about after a patch? [19:01] <william_stein> Yes. [19:01] <william_stein> it broke some things. [19:01] <william_stein> we just fixed them. [19:01] <william_stein> the problems were all in interator(...) [19:03] <mhansen> That's weird. [19:03] --> tclemans has joined this channel (n=Miranda@68.178.77.126). [19:03] <william_stein> maybe you checked in before finishing and sent us a broken patch. [19:03] <tclemans> ok i'm back from dinner [19:04] <tclemans> any news on notebook bugs I know that #228 was fixed thanks to Nick [19:04] <mhansen> Hmm... possibly. I remember doctesting after that and testing it interactively. Is it taken care of now or do you want me to make some changes? [19:05] <william_stein> it's taken care of. [19:05] <william_stein> nothing new on the notebook [19:05] <mhansen> Sorry about that. [19:06] <william_stein> np -- it took 1 minute to fix. [19:07] <millster> ok, bye everyone [19:07] <william_stein> bye [19:07] <tclemans> do you want to fix #643 with the current table and nested tables at top? [19:07] <-- millster has left this server. [19:12] --> mhansen_ has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:12] <-- mhansen has left this server (Read error: 104 (Connection reset by peer)). [19:13] <tclemans> why is slide_controls in html? I don't think it is enabled in the twisted notebook [19:16] <boothby> You can cut that out. [19:16] <-- mhansen_ has left this server (Read error: 104 (Connection reset by peer)). [19:16] --> mhansen has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:19] <tclemans> apparently in the notebook css there is a bunch of stuff that isn't used in the notebook anymore like "top_control_bar" [19:24] --> mhansen_ has joined this channel (n=mikehans@adsl-76-204-100-64.dsl.mdsnwi.sbcglobal.net). [19:24] <-- mhansen has left this server (Read error: 104 (Connection reset by peer)). [19:29] <dmharvey> #528: patch uploaded [19:29] <william_stein> cool. [19:29] <dmharvey> #528: still pretty ugly, and I'm not convinced it passes all doctests yet, but it's a start [19:29] <dmharvey> I should go [19:29] <dmharvey> I was just getting that in before I went off to bed [19:29] <william_stein> ok. [19:29] --> ncalexan has joined this channel (n=ncalexan@pv109051.reshsg.uci.edu). [19:30] <william_stein> Is this something I should put into SAGE now? [19:30] <william_stein> Is it safe? [19:30] <william_stein> Should I wait? [19:30] <william_stein> It sounds like it. [19:30] <dmharvey> I don't know [19:30] <dmharvey> basically, I got all doctest passing, except for the ones currently failing in the repository :-) [19:30] <dmharvey> but I didn't check too carefully which were which [19:30] <william_stein> ah, ok. [19:31] <william_stein> so i could maybe do that, or wait a day for you to? [19:31] <dmharvey> either way [19:31] <william_stein> cool. [19:31] <william_stein> I'll post a remark to trac if I merge yur patch in now. [19:32] <dmharvey> ok [19:32] <dmharvey> bye [19:32] <-- dmharvey has left this channel. [19:32] <ncalexan> 660: has a patch, which looks fine (it's trivial) but applier should add doctests. [19:33] <william_stein> i'll take a look [19:34] <william_stein> #660 -- no doctests... [19:34] <william_stein> but it's right iff original is. [19:34] <william_stein> want to add a few doctests too it? [19:35] <william_stein> i'll do it. [19:36] <william_stein> #666 -- i'm looking at it now. [19:37] <william_stein> tornaria -- any ideas about that very nasty pari c-library bug issue? [19:37] <tornaria> I'm looking at it... had to sort out some issues at home (kids...) [19:38] <william_stein> :-) [19:38] <william_stein> I think that is the most interesting serious bug of the day. [19:38] <william_stein> ncalexan did you see it? http://trac.sagemath.org/sage_trac/ticket/710 [19:38] <william_stein> Very unprofessional. [19:39] <tornaria> Maybe one should try an old version of sage to see if it's still there... Has someone tried? [19:39] <william_stein> I tried 2.7 and it was there. [19:39] <tclemans> #643: I'm putting a div right around the main tables at the top [19:39] <william_stein> It would be wise to try 2.0 or so. [19:39] <ncalexan> 710: urgh. [19:39] <william_stein> I don't have any ancient sage's around... [19:40] <william_stein> But they are easy to find on sage.math.washington.edu in people's home directories :-) [19:40] <william_stein> #725 -- burcin, I'm looking at your patch... [19:40] <burcin> it's very simple.. [19:41] <william_stein> nice. great work! [19:42] <burcin> I can't figure out where the big one in #621 comes from.. [19:43] <mhansen_> 710: It does it on 2.5.3 (which I think is the oldest I have around) [19:43] <burcin> there's another simple memleak fix in 559.. but that doesn't close any bugs.. [19:44] <william_stein> #621 is nasty. [19:44] <william_stein> #710 -- i want to fix that damn thing. [19:45] <william_stein> It is now the one open ticket in http://trac.sagemath.org/sage_trac/milestone/sage-2.8.4.3 [19:45] <william_stein> And it is nasty. [19:45] <william_stein> #710 -- I'm going to work on it right now. If anybody has any ideas, let me know. [19:45] <william_stein> One thing I did figure out is that if one does pari('factor(2^997-1)'), then press control c, [19:45] <william_stein> then import the lines about getting signals from sage/all.py, then SAGE does *not* segfault. [19:46] <tornaria> I'm compiling 1.0 and 2.0 [19:46] <william_stein> when the following control-c is pressed. Instead it ignored it. [19:46] <tornaria> The one thing that happens to me is this: [19:46] <tornaria> sage: gp.eval('factor(2^997-1)') [19:46] <tornaria> Interrupting GP/PARI interpreter... [19:46] <tornaria> Interrupting GP/PARI interpreter... [19:47] <tornaria> I.e. if I try gp.eval(...) thing (without doing the factor(..) first) [19:47] <tornaria> I press CTRL-C (ONCE) and I get that message twice [19:47] <tornaria> but nothing stops [19:47] <william_stein> For me it stops fine. [19:47] <tornaria> now if I press CTRL-C again (even after some time) then it stops with KeyboardInterrupt [19:47] <william_stein> All it does is send the control-c on to pari. [19:48] <william_stein> For me it stops right off. [19:48] <william_stein> I'm using 64-bit linux. [19:48] <tornaria> I'm 64-bit debian [19:48] <william_stein> #710 -- it is *not* present in sage-1.4 [19:48] <william_stein> I found a working version in /home/aklemm/sage-1.4 on sage.math [19:49] <tornaria> good.. [19:49] <william_stein> so hmmm. [19:49] <william_stein> that was a long long time ago though. [19:49] <tornaria> I wonder whether we should try to bisect the bug, or try to fix it by pure thought... :-) [19:49] <william_stein> But that is a definite hint. [19:49] <tornaria> I'm compiling 2.0 [19:49] <tornaria> (will abort 1.0) [19:50] <tornaria> (I'm abusing sage.math, anyway) [19:52] <william_stein> 1.4 used your pari_err code. [19:52] <william_stein> but I think martin albrecht totally rewrote interrupt.pxi to be vastly faster after sage-1.4. [19:52] <william_stein> So that's probably where the problem comes from. [19:53] <william_stein> I'll try using the old interrupt.pxi in sage-2.8* [19:53] <william_stein> (actually interrupt.h) [20:00] <william_stein> tornaria -- do you get the segfault with the newest version of Sage? [20:00] <william_stein> I just tried reverting all the interrupt stuff *just* for the pari c library. [20:00] <tclemans> #643: after I resolve the conflict with my example page js and the js from the notebook I should be able to easily fix this and make a patch [20:01] <william_stein> Interestingly everything *now* works -- i.e., this "fixes" #710 -- but I do have to hit control-c twice to interrupt [20:01] <william_stein> the gp.eval(...) line. [20:01] <tornaria> mmm... [20:01] <william_stein> But only the *first* time. [20:02] <tornaria> The _sig_on // _sig_off don't seem to be reentrant... are we sure they are not used nested? [20:02] <william_stein> then the first interrupt works. [20:02] <burcin> there is a comment in the new interrupt.h.. [20:02] <tornaria> (I mean, they use a global _signal ) [20:02] <william_stein> they *should* never ever be used re-entrant. [20:02] <william_stein> But that could be a problem. [20:02] <burcin> which says that if these _sig_{on,off} are not in pair, the program will segfault. [20:03] <tornaria> (actually, the pari_sig_on are also NOT reentrant, so...) [20:03] <william_stein> They are always in pairs surrounding pure C code that should never raise exceptions, etc. [20:03] <tclemans> #643 http://tclemans.nonlogic.org/snb/092007.html just div around head tables little change to css and some js [20:03] <william_stein> note that reverting to the older implementation of interrupt.* does fix the problem. [20:03] <william_stein> This must tell us something. [20:03] <burcin> but one can always interrupt the c code.. as in this case.. [20:04] <mhansen_> tclemans: I get a horizontal scroll bar on that HTML file. [20:05] <burcin> hmm.. where do I get an old version of that file? [20:05] <-- boothby has left this server (Read error: 110 (Connection timed out)). [20:06] <mhansen_> tclemans: Right, but there is a horizontal scrollbar for the worksheet area for me. [20:06] <mhansen_> tclemans: I didn't know if that's supposed to be there. [20:09] <mhansen_> tclemans: Weird, I guess I just never noticed it in the current notebook before. [20:12] <mhansen_> #726 [20:15] <mhansen_> It depends whether or not the file you were working on since the last upgrade changed. [20:15] <mhansen_> hg_sage.pull() [20:15] <william_stein> regarding #710, I think I will just revert the interrupt handler to the old version and [20:15] <william_stein> get martin to try to fix the problem. [20:15] <william_stein> He was the one to totally rewrite the handler, so he might best be able to fix the problem.. [20:15] <mhansen_> But, for the current code you get with hg_sage.pull(), you may need to install some extra packages ( flint and symmetrica ?) [20:16] <william_stein> Do "sage -upgrade". [20:19] <tornaria> william: ok on #710 [20:21] <william_stein> functionally the old and new interrupt code are supposed to be the same. The difference is that [20:21] <william_stein> the old code is faster. [20:21] <william_stein> I mean -- the new code is faster. [20:21] <tornaria> I know. The old code sets the signal handler each time. [20:21] <tornaria> that is slow. [20:21] --> boothby has joined this channel (n=boothby@D-69-91-159-227.dhcp4.washington.edu). [20:21] <tornaria> but maybe pari is playing with the signals somehow? [20:22] <william_stein> it shouldn't, but it's definitely possible. [20:22] <william_stein> that could cause a problem like we see. [20:22] <william_stein> It would be good to isolate things, etc. [20:22] <william_stein> I wonder if it's just control-c or other things that trigger the problem? [20:23] <william_stein> also, is it really related to expect? [20:24] <william_stein> pari('1/0') [20:24] <william_stein> then everything is messed up or seg faults. [20:24] <tornaria> uh... [20:25] <william_stein> even in sage-1.4 after pari('1/0') the gp.eval('factor(2^997-1)') afterwards would hang. [20:26] <mhansen_> Yeah, email them to me at mhansen@gmail.com [20:27] <tornaria> mmmm.. [20:27] <tornaria> Is it an option that CTRL-C in gp.eval('factor(2^997-1)') is messing things and maybe longjmp'ing to the setjmp in pari('1/0') ? [20:27] <tornaria> or something like that... [20:28] <william_stein> gp.eval should have absolutely nothing at all to do with gen.pyx. It's pexpect interface to a separate process. [20:28] <william_stein> But -- what your suggesting is probably exactly what is actually happening. [20:28] <william_stein> I.e., that is what would happen if _sig_on were called twice say. [20:29] <tornaria> yep [20:29] <tornaria> or the signal handler is called before _sig_on (somehow) [20:29] <tornaria> Or after the last _sig_on has run out of scope. [20:30] <tornaria> (so its process stack is invalid) [20:30] <william_stein> if you do pari('factor(2^997-1)') repeatedly you can interrupt it over and over and it works fine. [20:30] <william_stein> Which suggests the signal handler has been set to the one for gen.pyx and not changed. [20:31] <william_stein> what I don't understand is why the problem only appears when using expect. [20:32] <william_stein> gonzalo -- try this. [20:32] <william_stein> tornaria -- try this. [20:32] <william_stein> Do pari('factor(2^997-1)'), then control-c [20:32] <william_stein> Then type "get_sigs()" [20:32] <william_stein> Then things work fine again. [20:32] <ncalexan> william_stein: you could alter the _sig_on, _sig_off code to tell if you it is being called twice, just for testing. [20:32] <william_stein> good idea. how? [20:33] <ncalexan> A global variable that counts up and down? [20:33] <ncalexan> I wasn't thinking anything fancy, just a quick hack. [20:33] <ncalexan> It's just a few lines of cython, if I recall. [20:33] <william_stein> good idea. [20:33] <tornaria> Can we print from _sig_on / _sig_off ? [20:34] <william_stein> where are they defined these days? [20:34] <ncalexan> For debugging, no reason not to. [20:35] <burcin> the function that handles sigint seems to be the same, before and after pari('factor(...)') [20:35] <william_stein> c_lib/interrupt.h [20:35] <tornaria> Another idea: have a sigsetjmp somewhere as close to main as possible, copy that jmp_buf to _signals.env in _sig_off [20:35] <william_stein> burcin -- that can't be. [20:36] <burcin> I'm missing something.. [20:36] <tornaria> (so, siglongjmp'ing from outside _sig_on/_sig_off pair will jump to a predictable place. [20:36] <burcin> signal.getsignal(2) should give you the handler.. no? [20:36] <william_stein> it might only be Python's view of the signal. [20:37] <william_stein> I.e., I'm not sure that it is necessarily right. [20:37] <william_stein> by the way, typing this is enough, since this just calls pari immediately: [20:37] <william_stein> sage: factor(2^997-1) [20:38] <mhansen_> tclemans: Yeah, I'm doing the patches now. [20:40] <tornaria> For the record: there seems to be a potential race condition in interrupt.h (although I don't think it is causing the problem) [20:40] <tornaria> If I understand correctly, the _signals.mpio = 1+2 assignment tells the signal handler to use longjmp. [20:41] <tornaria> however, the sigsetmp is issued *after* that... It should be the other way around, I thin. [20:41] <william_stein> why? [20:41] <mhansen_> william_stein: I get this now with symmetrica-0.3.1 /usr/bin/ld: /opt/sage-2.8.3.rc3/local//lib/libsymmetrica.a(boe.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC [20:41] <tornaria> Because if a signal is triggered between _signals.mpio = 1+2 and sigsetmp(_signals.env,1) [20:41] <william_stein> tornaria -- i get it. [20:41] <william_stein> That could definitely happen. [20:42] <tornaria> etc [20:42] <william_stein> i see. [20:42] <tornaria> (very unlikely, and #710 is too deterministic) [20:42] <william_stein> But on the other had, if you did it the other way around, wouldn't it be possible that a signal would cause a jump to the wrong place? [20:43] <william_stein> No -- since _sig_on/_sig_off can't be nested. [20:43] <tornaria> exactly. [20:43] <william_stein> and sigint would use the Python signal handler. [20:43] <tornaria> The assumption is that _signals.mpio = 0 at time of _sig_on [20:44] <william_stein> It's tie to do nick's suggestion. [20:44] <mhansen_> william_stein: -fPIC is missing from make.unix for symmetrica-0.3.1 [20:44] <william_stein> is it needed? [20:45] <mhansen_> Yeah, I get this error without it: [20:45] <mhansen_> I get this now with symmetrica-0.3.1 /usr/bin/ld: /opt/sage-2.8.3.rc3/local//lib/libsymmetrica.a(boe.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC [20:45] <william_stein> ok, i'll add it in. [20:45] <mhansen_> Did you remove it for the OS X issue? [20:46] <william_stein> sage -i symmetrica-0.3.2 [20:46] <william_stein> I didn't realize it got removed. I think I modifed make.unix in src/ then copied that to the patches directory, [20:46] <william_stein> hence overwriting your patched version of it. [20:47] <mhansen_> Oh, I see. [20:47] <william_stein> What else did you do to it? [20:47] <mhansen_> Just that. [20:47] <william_stein> I'm testing the build right now. [20:48] <mhansen_> I guess I also added -O3 [20:48] <mhansen_> 0.3.2 worked for me. [20:49] <william_stein> I've added -O3 for 0.3.3. [20:49] <tornaria> (_sig_on)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_str)(_sig_off)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_on)(_sig_on)(_sig_off)(_sig_off)(_sig_on) [20:49] <tornaria> This is JUST starting up sage... [20:50] <william_stein> what does that factor thing do!?!?!! i can't wait. [20:50] <tornaria> you can already see a nested _sig_on/_sig_off right before the prompt. [20:50] <william_stein> sh87)(*&t! [20:50] <mhansen_> tclemans: What's the bug number? [20:50] <tornaria> there are at least a couple more. [20:50] <tclemans> mhansen_: 643 [20:51] <tornaria> Do you know how to obtain the current instruction pointer from C? [20:51] <tornaria> (i.e. I want to fprintf(stderr,"_sig_on(%p)", current_position) ) [20:52] <mhansen_> Patch is up for #643. [20:52] <william_stein> no clue. [20:54] <william_stein> are those the sig things just from pari?! [20:54] <tornaria> I think so [20:55] <william_stein> It depends on whether you rebuilt just gen.pyx. [20:55] <tornaria> because I changed interrupt.h and touched libs/pari/*.py* [20:55] <william_stein> I'm trying now to see if I get similar results. [20:55] <william_stein> yep, replicated. [20:55] <tornaria> In fact, gp.eval(...) doesn't print the sig stuff... dunno what I have to rebuild [20:56] <william_stein> gp.eval doesn't involve _sig_on _sig_off in any way. [20:56] <tornaria> More curious is that pari('1/0') calls sig_str but no sig_off [20:56] <ncalexan> Ah, I see there are a ton of _sig_on _sig_on repeats. [20:56] <tornaria> ah... [20:56] <william_stein> yep. [20:56] <william_stein> so parierror isn't calling sig_off. [20:57] <tornaria> yep... [20:57] <tornaria> that's the thing... [20:57] <tornaria> Then signal handler is trying to longjmp [20:57] <william_stein> I mean pari trap doesn't call _sig_off. [20:57] <william_stein> oops. [20:57] <tornaria> back to some place which has been invalidated. [20:57] <william_stein> yep. [20:57] <william_stein> I'm trying with _sig_off at the top of the errorhandler. [20:58] <tornaria> I guess that didn't show up before since the signal handlers where different or something. [20:58] <william_stein> i bet it didn't show up *as much*. [20:58] <william_stein> since there were so many handlers, maybe. [20:58] <william_stein> pari('1/0') is now ballanded for me, but pari('factor(...)') is *NOT*. [21:02] <tornaria> ok [21:02] <tornaria> inside the "sigsetmp(...)" [21:02] <william_stein> *anywhere* with the new sig handling code, if you hit control-c it doesn't call _sig_off. [21:03] <tornaria> just before return(0), you have to of course _sig_off [21:03] <william_stein> sage: m = random_matrix(ZZ,500,501) [21:03] <william_stein> sage: m.echelonize() [21:03] <tornaria> (I mean _signals.mpio = 0 ) [21:03] <tornaria> that fixes it. [21:03] <william_stein> because the signal handler does that. [21:03] <william_stein> or... doesn't like it should. [21:03] <william_stein> yep. [21:04] <william_stein> I bet that was in my old code... but martin messed it up. [21:04] <tclemans> tom: could you referee the 643 patch? http://sagetrac.org/sage_trac/attachment/ticket/643/643.patch [21:04] <william_stein> actually, it was not in my old code. [21:05] <tornaria> now, I'm still having to interrupt twice the "gp.eval('factor(2^997-1)') [21:05] <boothby> yeah, I'll look at it. [21:05] <tornaria> OTOH, it doesn't happen like that on sage.math, so it's either [21:06] <tornaria> a) a problem with my build [21:06] <tornaria> b) just something I broke with all the debugging crap I added. [21:06] <boothby> looks good to me. [21:08] <tclemans> 643 is now resolved as fixed [21:08] <boothby> No. [21:08] <boothby> Don't close bugs -- let William do that. [21:08] <tclemans> ok [21:08] <tclemans> reopened [21:08] <boothby> Also -- what happens when you resize the window? [21:09] <william_stein> or change font size. [21:09] <william_stein> but your patch is still an improvement [21:09] <boothby> I say apply the patch anyway... but work on the resize / font size change issues. [21:09] <william_stein> sounds good. [21:09] <tclemans> opps i forgot to change that to set_main_top() [21:10] <tclemans> there is a window.onresize i added [21:10] <tclemans> i just have setMain(); instead of set_main_top(); [21:11] <william_stein> tornaria -- can you replicate the following? [21:11] <william_stein> Do factor(2^997-1) and hit controlc [21:11] <william_stein> then do gp.eval('factor(2^997-1)') and hit controlc [21:11] <william_stein> then Do factor(2^997-1) and hit controlc ... it hangs. [21:12] <tornaria> william: yes, it hangs on me... [21:12] <william_stein> i bet it has to do with us calling _sig_on twice in a row by accident a few ties. [21:12] <tornaria> we've still a problem, since _pari_catch traps and returns without _sig_off [21:13] <william_stein> yep. [21:13] <william_stein> yep, since it called that code in the if before return(0); in interrupt.h [21:14] <-- roed_ has left this server. [21:14] <william_stein> tornaria -- I'm changing interrupt.h so additional calls to sig_on are ignored to see what happens... [21:15] <tornaria> ok, so the jmp_buf is always the "outer" one. [21:15] <william_stein> yep. [21:15] <tornaria> I'm changing pari_catch so it _sig_offs when it traps something. [21:15] <william_stein> not needed? [21:16] <tornaria> that didn't fix the hang. [21:16] <william_stein> i think it isn't needed. [21:16] <tclemans> 643: do i need to attach a new patch with the change from setMain() to set_main_top() ? [21:16] <william_stein> mine didn't fix the hang either. but it seems like a good idea (making it only the outer one). [21:16] <tornaria> but otherwise we miss one _sig_off, don't we? [21:17] <william_stein> hmm. [21:17] <william_stein> you're right. [21:17] <william_stein> Maybe Sage should just die if they aren't matched. [21:17] <william_stein> :-) [21:17] <william_stein> i.e., call PyErr as in interrupt.c [21:17] <william_stein> That's a good idea actually. [21:19] <boothby> tclemans: yeah [21:19] <boothby> put a note about it. [21:24] <william_stein> tornaria -- i'm writing code to detect unbalanced _sig_on off and raise an error when it happens. [21:25] <tornaria> good [21:25] <william_stein> done, I think. want it? [21:26] [Error] home/was/tmp/interrupt.h: Unknown command. [21:26] <william_stein> It's in /home/was/tmp/interrupt.h on sage.mat [21:27] <tornaria> will have a look. I actually have a few changes in interrupt.h myself. [21:27] <william_stein> yep. [21:28] <william_stein> check it out: [21:28] <william_stein> --> 526 self.poly = pari([]).Polrev() [21:28] <william_stein> 527 [21:28] <william_stein> 528 if x is None: [21:28] <william_stein> /home/was/s/local/bin/gen.pyx in gen.PariInstance.call() [21:28] <william_stein> <type 'exceptions.RuntimeError'>: Unbalanced _sig_on/_sig_off [21:28] <william_stein> cool, eh! [21:28] <tornaria> uh... very good... :-) [21:29] <william_stein> cool!!! [21:29] <william_stein> check this out: [21:29] <william_stein> was@ubuntu:~ sage -python [21:29] <william_stein> Python 2.5.1 (r251:54863, Sep 13 2007, 11:50:35) [21:29] <william_stein> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 [21:29] <william_stein> Type "help", "copyright", "credits" or "license" for more information. [21:29] <william_stein> >>> import sage.libs.pari.gen [21:29] <william_stein> >>> sage.libs.pari.gen.pari('[]') [21:29] <william_stein> ok [21:30] <william_stein> >>> sage.libs.pari.gen.pari([]) [21:30] <william_stein> RuntimeError: Unbalanced _sig_on/_sig_off [21:30] <william_stein> gotcha! [21:30] <tornaria> good... hope this catches the factor(...) culprit... [21:30] <william_stein> >>> sage.libs.pari.gen.pari.vector(5) [21:31] <william_stein> goes boom! [21:31] <william_stein> that culprit doesn't have a chance against us. [21:34] <-- boothby has left this server (niven.freenode.net irc.freenode.net). [21:34] <-- tornaria has left this server (niven.freenode.net irc.freenode.net). [21:34] <-- jaap has left this server (niven.freenode.net irc.freenode.net). [21:35] --> boothby has joined this channel (n=boothby@D-69-91-159-227.dhcp4.washington.edu). [21:35] --> tornaria has joined this channel (n=tornaria@r190-0-137-63.dialup.adsl.anteldata.net.uy). [21:35] --> jaap has joined this channel (n=jaap@cc73571-a.emmen1.dr.home.nl). [21:35] <boothby> wtf [21:35] <-- burcin has left this server (niven.freenode.net irc.freenode.net). [21:35] --> burcin has joined this channel (n=burcin@heim-032-216.raab-heim.uni-linz.ac.at). [21:35] <william_stein> wtf [21:37] <william_stein> tornaria. i got it. [21:37] <william_stein> Check out _new_gen. [21:37] <william_stein> It starts by calling _sig_on! [21:37] <william_stein> Damn it. [21:37] <william_stein> But it is called immediately by self.new_gen(...) [21:37] <william_stein> and there are very often _sig_on's right before self.new_gen(...) [21:38] <william_stein> (ok, I maybe got it) [21:40] <william_stein> tornaria -- if you delete the _sig_on in _new_gen, then all the unbalanced _sig_on/_sig_off's in startup go away. [21:42] <william_stein> Unfortunately, factor(2997-1) can still be made to lock by hitting control-c during gp.eval('...') [21:42] <-- boothby has left this server ("leaving"). [21:45] <tclemans> when i do hg_sage.import_patch('643.patch') i get abort: no diffs found it is the patch that mhansen_ made [21:51] <tornaria> So.... I think the sage_signal_handler is being hijacked by pari... [21:51] <tornaria> I put a printf at the very top of sage_signal_handler [21:52] <tornaria> After the gp.eval(..) + CTRL-C, it shows as running the signal_handler, but only the first time! [21:52] <william_stein> i was just testing that too! [21:52] <william_stein> Try this -- put this line in interfaces/get_sigs.py in my_sigint: [21:52] <william_stein> import sage.ext.sig [21:52] <william_stein> sage.ext.sig.get_bad_sigs() [21:52] <william_stein> Then all known problems go away. [21:53] <william_stein> it's perfect now. [21:53] <william_stein> WOW. [21:54] <william_stein> weird -- get_bad_sigs calls init_csage... [21:55] <william_stein> which eventually calls setup_signal_handler(). [21:55] <william_stein> so I'm basically hacking around what you're really finding. [21:56] <william_stein> setup_signal_handler steals signal handlers back. [21:56] <tornaria> it works for me... [21:56] <mhansen_> Nice work you two on tracking down the issue(s). Pretty impressive. [21:56] <william_stein> cool. [21:56] <william_stein> I'm excited. [21:56] <william_stein> This has been a major bug for a long time. [21:56] <tornaria> bah, I still need two CTRL-C in my box. [21:57] <william_stein> what is your box exactly? [21:57] <william_stein> your laptop? [21:57] <tornaria> (for interrupting gp.eval(...) ) [21:57] <tornaria> yes, my laptop, core 2 duo 64 bits. [21:57] <william_stein> for gp.eval I need that too. [21:57] <william_stein> That's completely reasonable. [21:57] <william_stein> well, not reasonable... but it's an unrelated problem, probably. [21:57] <tornaria> ok [21:57] <tornaria> I don't need two CTRL-C on sage.math. [21:57] <william_stein> does factor(2997-1) always require one control-c [21:57] <william_stein> it's a timing sort of issue, I think. [21:57] <tornaria> yes, definitely only one control-C [21:58] <william_stein> great. we did it! [21:58] <mhansen_> And just before the 10pm "deadline" [21:59] <william_stein> I bet make test will uncover lots of bugs with mismatched _sig_on/_sig_off!! [21:59] <william_stein> Yep found one already. [21:59] <william_stein> sage -t devel/sage-ranges/sage/rings/complex_double.pyx [21:59] <william_stein> do you guys want to help fix them? [21:59] <william_stein> actually, so far only 1. [21:59] <william_stein> so maybe not so exciting. [21:59] <tornaria> now that I come to think about it: aren't we supposed to reset signals when they are issued? [22:00] <mhansen_> Yeah, sure, I'll help. But, I'll need a brief intro course on what exactly needs to be done to fix them. [22:01] <william_stein> I just pushed out the change to the official repo. [22:01] <william_stein> there are several segfaults too. [22:01] <tornaria> I mean, " Upon arrival of a signal with number signum the following happens. ... Finally, if the handler is [22:01] <tornaria> set to a function sighandler then first either the handler is reset to SIG_DFL or an implemen‐tation-dependent blocking of the signal..." [22:02] <tornaria> from signal(2) [22:02] <tornaria> This didn't use to be a problem since _sig_on would set all the signals anyway. [22:02] <william_stein> ah [22:04] --> roed_ has joined this channel (n=roed@RANDOM-FOUR-SEVENTY-FIVE.MIT.EDU). [22:05] --> tclemans951 has joined this channel (n=Miranda@68.178.77.126). [22:05] <william_stein> with my current fix for signals, this now seg faults: sage: k.<a> = FiniteField(9); charpoly(a,'y') [22:05] <tornaria> IOW, one "simpler" fix could be to put "signal(sage_signal_handler, sig)" at some point in sage_signal_handler. [22:05] <william_stein> try it and see if it works. [22:11] <william_stein> sage: pari([2r,2r,1r]) [22:11] <tornaria> doesn't seem to work [22:11] <william_stein> segfault [22:12] <william_stein> The "2r" means "raw integers", i.e., not preparsed. [22:12] <william_stein> this also fails: pari([2,2,1]) [22:12] <william_stein> does it fail for you? [22:12] <tornaria> It works. [22:12] <william_stein> ah, v=pari([1,2,3]) works. [22:12] <william_stein> so something in printing is broken. [22:12] <tornaria> But I have your hack disabled [22:13] <tornaria> (changed by my hack, which doesn't fix the problem) [22:13] <william_stein> ah, ok. [22:13] <william_stein> even with no change to get_sigs.py, I still have my problem. [22:13] <william_stein> I think it might be detecting mismatches sig_on/sig_off -- which causes a boom. [22:13] <tornaria> I don't have a problem, even reinstating your change to get_sigs.py [22:14] <william_stein> it's unrelated. [22:14] <tornaria> I don't have your code for detecting mismatches. [22:14] <william_stein> I wrote code to print out a traceback with _sig_on/_sig_off mismatches. [22:14] <william_stein> But of course printing a traceback in the middle of some weird code might just cause a problem and segfault. [22:14] <tornaria> yes, you told me to get it, but I didn't... [22:15] [Error] home/was/tmp/interrupt.h: Unknown command. [22:15] <william_stein> it's /home/was/tmp/interrupt.h on sage.math [22:15] <william_stein> i'm going to change it to also fprintf to stderr. [22:16] <william_stein> yep, the segfault is caused by a balance problem. [22:16] <william_stein> i posted a new version. [22:17] <william_stein> you have to be sure to touch gen.pyx [22:17] <-- wstein has left this server (Read error: 110 (Connection timed out)). [22:17] <william_stein> there is an extra _sig_on in GEN_to_str... [22:18] <william_stein> getting rid of that fixes the problem. [22:19] <william_stein> but I want a _sig_on there, so users can control-c out of str(pari(big thing)) [22:19] <-- tclemans has left this server (Read error: 110 (Connection timed out)). [22:21] <william_stein> you know, it doesn't matter if there are two _sig_on's in a row. [22:21] <-- roed_ has left this server (Read error: 110 (Connection timed out)). [22:21] --> wstein has joined this channel (n=was@c66-235-37-221.sea2.cablespeed.com). [22:21] <william_stein> The key thing is just that there is a _sig_off. [22:22] <william_stein> right? [22:22] <tornaria> mmm... [22:22] <william_stein> It *used* to matter with my old signal handler, since that just used "the last one". [22:22] <-- tclemans951 has left this server (Read error: 104 (Connection reset by peer)). [22:22] <tornaria> So, current _sig_on only remembers the outer call. [22:23] <william_stein> I'm still fuzzy. [22:23] <william_stein> But I don't think they have to be exactly ballanced. [22:23] <william_stein> Maybe it remembers only the innermost call? [22:23] <tornaria> well... sig_off is idempotent, so... [22:23] <william_stein> oh -- you're right, because of the if I added. [22:24] <tornaria> However, this will still be problematic, i.e.: [22:24] <tornaria> (1) _sig_on [22:24] <tornaria> (2) _sig_on [22:24] <tornaria> (2) _sig_off [22:24] <william_stein> why/ [22:24] <tornaria> (3) _sig_on [22:24] <tornaria> (3) _sig_off [22:24] <tornaria> (1) _sig_off [22:25] <tornaria> This is a perfectly balanced example. The numbers are the stack context. [22:25] <tornaria> It's meant that (2) is below (1) and (3) is also below (1), but (2) and (3) are "parallel" [22:25] <tornaria> (so stack context 2 is invalid while executing (3) [22:26] <tornaria> When you call _sig_off in (2), you are setting _signals.mpio = 0, then when you call _sig_on from (3), you think "there's no handler active, lets install one" [22:26] <william_stein> But then it would be as if there were no _sig_on/_sig_off code for part of (1). [22:26] <tornaria> actually, it's fine... when you (3) _sig_off you disable. [22:27] <tornaria> Yes, the problem is that after the first _sig_off you are not catching anymore. [22:27] <william_stein> yep. [22:27] <tornaria> Now, the other thing is to have a nest counter. [22:27] <william_stein> If I have a block of C code and I do _sig_on ... _sig_on ... _sig_on and at the end _sig_off, [22:27] <tornaria> only _sig_on at 0 [22:27] <william_stein> that is fine. [22:27] <tornaria> only _sig_off at 0. [22:28] <william_stein> Code with _sig* currently never calls into other functions that are *python* and involve _sig_, and expect [22:28] <william_stein> them to not call _sig. [22:29] --> roed_ has joined this channel (n=roed@c-24-128-48-246.hsd1.ma.comcast.net). [22:35] <william_stein> tornaria -- shall we declare partial victory. [22:35] <tornaria> yep [22:35] <william_stein> then I declare SAGE Bug Day 3 over and a success [22:36] <tornaria> I tried signal(sig, sage_signal_handler) in sage_signal_handler again [22:36] <tornaria> (w/o your hack in my_sigint) [22:36] <william_stein> what happened? [22:36] <tornaria> and it works... [22:36] <william_stein> which hack? [22:36] <william_stein> oh, i know. [22:36] <william_stein> that's better. [22:36] <tornaria> the one of calling get_bad_sigs [22:36] <william_stein> where precisely did you put it? [22:36] <tornaria> two places: [22:37] <tornaria> one right before comment "//where to go next?" [22:38] <tornaria> the second right before the second-to-last closing brace [22:38] <tornaria> (i.e. as late as possible, in each branch of the if(_signals.mpio && 1) ) [22:38] <williamstein> i just accidently clicked "snapshot" in my vmware image and i can't work for a minute... [22:38] <tornaria> [22:38] <william_stein> ok, back. [22:38] <william_stein> ? [22:40] <tornaria> //notify 'calling' function [22:40] <tornaria> [22:40] <tornaria> _signals.mpio |= 4; [22:40] <tornaria> [22:40] <tornaria> + signal(sig, sage_signal_handler); [22:40] <tornaria> + [22:40] <tornaria> //where to go next? [22:40] <william_stein> testing. [22:40] <tornaria> - if ( _signals.mpio && 2 ) { [22:40] <tornaria> + if ( _signals.mpio & 2 ) { [22:40] <tornaria> This is a piece of the patch... (first case) [22:40] <william_stein> && versus &? [22:40] <tornaria> Note also the && 2 , should be & 2 [22:40] <william_stein> interesting. [22:40] <tornaria> (it means to test bit 1) [22:40] <william_stein> yep [22:41] <tornaria> @@ -85,6 +92,8 @@ void sage_signal_handler(int sig) { [22:41] <tornaria> _signals.python_handler(sig); [22:41] <tornaria> break; [22:41] <tornaria> }; [22:41] <tornaria> + [22:41] <tornaria> + signal(sig, sage_signal_handler); [22:41] <tornaria> } [22:41] <tornaria> } [22:41] <tornaria> that's the other part... [22:41] <william_stein> worksforme [22:41] <tornaria> if(_signals.mpio && 2) is effectively the same as if(_signals.mpio) [22:42] <tornaria> however, the only places where _signals.mpio are set the values are either 1+2 or 0 [22:42] <tornaria> so it is really the same. [22:42] <tornaria> AFAICT [22:43] <william_stein> i've closed #710 [22:43] <tornaria> good [22:43] <william_stein> now I can release sage-2.8.4.3. [22:44] <tornaria> congrats... [22:44] <william_stein> at least after testing, etc. [22:44] <william_stein> It should really be 2.8.5, actually. [22:44] <william_stein> since there is so much that is new (e.g., 20,000 lines of combinatorics code). [22:44] <william_stein> several new packages, ec. [22:44] <william_stein> at least symmetrica. [22:45] <william_stein> I'm making an alpha0 tarball right now, to start building and testing on a bunch of machines, then going home. [22:46] <tornaria> good... [22:46] <tornaria> Is there a way to upgrade rather than starting over with the 150Mb download? [22:47] <tornaria> (I have 3Gb / month quota here...) [22:47] <william_stein> yes. [22:47] <william_stein> Just do "sage -upgrade" followed by "hg_sage.pull()" and "hg_scripts.pull()" and hg_doc.pull()". [22:47] <william_stein> Should be close enough. [22:48] <william_stein> but wait a second. [22:48] <tornaria> ok. [22:48] <william_stein> ok. [22:48] <william_stein> try now. [22:48] <tornaria> What about the having to hit CTRL-C twice in gp.eval(...) ? Is that reported? [22:48] <william_stein> make that a new ticket. [22:49] <tornaria> This is scary: [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> using frickin' slow GSL C-blas [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> WARNING WARNING [22:49] <william_stein> you don't have atlas devel libraries? [22:49] <tornaria> WARNING WARNING [22:49] <tornaria> [22:49] --> janwil has joined this channel (n=janwil@tartu.cyber.ee). [22:49] <tornaria> nope, didn't need them for anything. [22:49] <william_stein> gsl works fine; it's just slow for numerical linear algebra. [22:49] <janwil> good morning [22:50] <william_stein> hi [22:51] <tornaria> apt-get atlas3-base-dev wants to install gcc-3.4 [22:51] <janwil> how has the BD progressed this far? [22:51] <tornaria> (I have gcc 4.1.2 / etch) [22:51] <william_stein> we have an atlas spkg, but it takes a while (=30 minutes or so) to build. [22:52] <william_stein> it's in the optionall packages, I think. [22:52] <tornaria> don't need that for anything... [22:52] <william_stein> janwil -- bd is now over. [22:52] <william_stein> I'll post the log in a moment. [22:52] <william_stein> See http://trac.sagemath.org/sage_trac/milestone/sage-2.8.5 }}}