SAGE Bug Day 1
Sage Bug Day 1 took place from 10 am PST August 18th until 2 am August 19th 2007.
Remember the "Twisted Rule" -- Don't work on anything unless there is a trac ticket for it.
- The base version of SAGE we'll start with is here:
- The trac server with all the bugs is here:
- We will focus on the bugs listed here:
- However, people with other interests can of course help out with fixing anything they want.
Write to [email protected] 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
IRC
SAGE Bug squash IRC LOG
[Thu Aug 16 2007] [02:11:25] <william> It'll be fixed in sage-2.8.1 [Thu Aug 16 2007] [02:11:38] <malb> sounds difficult to track down [Thu Aug 16 2007] [02:12:00] <william> I looked through all the code in our src/ versus the one in GMP's generic install, and it didn't look like anything nefarious. [Thu Aug 16 2007] [02:12:07] <william> it just looks like a patch was preapplied. [Thu Aug 16 2007] [02:12:15] <william> anyway, fixed. [Thu Aug 16 2007] [02:12:27] <william> it was hard to track. i got lucky. [Thu Aug 16 2007] [02:27:48] |Quit| malb has left this server ("Konversation terminated!"). [Thu Aug 16 2007] [02:27:55] |Join| malb has joined this channel (n=[email protected]). [Thu Aug 16 2007] [04:09:46] |Quit| malb has left this server (Remote closed the connection). [Thu Aug 16 2007] [04:28:45] <mabshoff> Hey william [08:53] --> You have joined the channel #sage-devel (n=[email protected]). [08:53] *** Channel modes: secret, no messages from outside [08:53] *** This channel was created on 08/17/2007 01:03:33 PM. [08:54] <burcin> hello? [08:55] <was_> hi. [08:55] <burcin> is there a reason why the channel is secret? [08:55] <was_> no [08:56] <was_> i hardly know anything about irc [08:56] <burcin> it's been a while since I used irc.. I was surprised when I couldn't find this channel in the list [08:56] <was_> bug 
[08:57] <burcin> if we're going to be using this often.. and it seems we will be.. [08:57] <burcin> we should also register the group with freenode... [08:58] <was_> when we made @sage-dev a while ago, bobby moretti and i tried several times [08:58] <was_> to officially register the group, but got ignored. [08:58] <was_> it was weird. [08:59] <was_> We just changed from using #sage-dev to #sage-devel a few days ago for [08:59] <was_> consistency with the mailing list name. [08:59] <was_> Maybe we were registering incorrectly. [09:00] --> pdenapo has joined this channel (i=[email protected]). [09:00] <burcin> this seems to be the first step: [09:00] <burcin> http://freenode.net/group_registration.shtml [09:00] <burcin> or maybe it's overkill... [09:01] <burcin> anyway.. I'm just making remarks about nonsense.. as I won't be able to join in the bug squash.. [09:02] <burcin> unfortunately, this weekend the dorms don't have internet access.. and I'll be leaving the institute in 30 minutes.. [09:02] <burcin> so proper questions.. [09:02] <was_> where do you live? [09:02] <burcin> is there anything I need to do, to get cython to build code with debug symbols? [09:03] <was_> cython always builds such code by default. [09:03] <burcin> I live in linz, austria.. the institute, RISC, is in Hagenberg, about 25 km's away.. long distance for this place.. [09:04] <burcin> so how does one go about attacking bug #274 [09:05] <was_> first confirm that it is still a bug. [09:05] <burcin> it is.. [09:06] <was_> yep. [09:06] <burcin> the number increases much more significantly, if one adds a couple of zeroes to the parameter of range... [09:06] <was_> i would try to simplify the loop -- take the random stuff out. [09:07] <was_> yep. [09:07] <was_> without the random stuff the leak is still there. [09:07] <was_> that's good because it is much simpler. [09:07] <was_> Is both the + and * needed? [09:08] <was_> nope. [09:08] <was_> just doing t*X exhibits a leak [09:08] <burcin> yes.. you're much faster [09:10] <-- pdenapo has left this server ("Leaving"). [09:10] <was_> the problem is also *only* over GF(10007^2) [09:10] <was_> not over GF(10007) [09:10] <was_> so it's givaro, probably. [09:11] <was_> wait -- it's pari at that size! [09:11] <was_> it's not givaro. [09:11] <was_> so now I would try to narrow it down as much as possible in this class sage.rings.finite_field.FiniteField_ext_pari [09:13] <burcin> thanks.. but I need to leave now.. [09:13] <burcin> I'll try to read the logs... [09:13] <burcin> and definitely be here for next time.. [09:13] <was_> excellent. [09:13] <was_> cu [09:14] <-- burcin has left this server ("Leaving"). [09:42] --> d has joined this channel (n=[email protected]). [09:43] --> dropdrive has joined this channel (n=[email protected]). [09:56] --> robert457965 has joined this channel (n=[email protected]). [09:57] <robert457965> any intel mac binaries? [09:58] <william> somebody somehow messed up my office computer where [09:58] <william> the intel mac binary is. [09:58] <william> I can't connect to it. [09:58] <william> either it crashed, or tom changed something or ?? [09:58] <william> I don't know. [09:59] <william> so, no intel mac binaries. [09:59] <william> there is one -- it's just no accessible. [09:59] <robert457965> ok, well my intel mac is building now [09:59] <robert457965> we could make binaries from that? [09:59] <william> please post when you are done, if you have a fast connection. [09:59] <william> yes. [09:59] <william> just do sage -bdist 2.8.1 [09:59] <robert457965> ok cool [10:01] <dmharvey> good morning/afternoon/evening [10:01] <was_> hi. [10:01] <was_> welcome. [10:01] <was_> it's 10am, so I official declare this bug squash started. [10:01] <was_> Did everybody get my email? [10:01] <was_> (from last night) [10:02] <was_> this is the key thing: http://www.sagemath.org:9001/bug1 [10:02] <dmharvey> yes [10:02] <dmharvey> so how is this going to work? [10:03] <robert457965> i'm starting on ticket 206, once my build finishes [10:03] <william> could everbody who is here maybe write where they are physically or something? [10:03] <mabshoff|away> hi [10:03] <robert457965> reporting from my gf's apartment, capitol hill seattle [10:03] <william> I'm in San Diego [10:03] *** mabshoff|away is now known as mabshoff. [10:03] <william> So you're Robert Miller? [10:03] <dmharvey> boston, in my apartment, with a somewhat flaky internet connection [10:03] <robert457965> yeah [10:03] <william> ok. [10:03] <robert457965> surprisingly the nickname "robert" was taken [10:04] <dmharvey> "william" == "was_"? [10:04] <william> i am logged in twice. [10:04] <william> I have two different irc clients. [10:04] <william> anyway, i made this page: [10:04] <dmharvey> lemme guess... one is on your iphone? [10:04] <mabshoff> I am near Dortmund, Germany with a DSL connection locally, but fat pipes at work. [10:04] <william> http://www.sagemath.org:9002/sage_trac/milestone/sage-2.8.2 [10:05] <william> what about dropdrive and d? [10:06] <robert457965> was- how is that delete script doing? [10:06] <william> 79% done. [10:06] <william> [10:06] <robert457965> oy [10:07] <robert457965> lesson learned [10:07] <william> how about if somebody chooses a specific bug and we all think about it for a few minutes? [10:08] <william> optimally, somebody will have an idea, convince everybody else it is a good way to go, and [10:08] <william> write up a patch, which everybody else could try. [10:08] <dropdrive> william: I'm just an interested observer [10:08] <dmharvey> i'm going to see if #319 still exists after all the changes to the coercion code [10:08] <william> ok. [10:08] <william> ok, i'm looking at it too. [10:08] <dmharvey> unfortunately i'm still building 2.8.1 on two machines.... [10:08] <william> just try in 2.8 [10:09] <william> Or do hg_sage.pull() [10:09] <dmharvey> yep it's fixed in 2.8 [10:09] <dmharvey> ha ha [10:09] <william> The underlying SAGE library code is almost the same in 2.8.1. [10:09] <dmharvey> one bug squashed [10:09] <william> Most packages build better. [10:09] <william> In particular ** GMP **. [10:09] <william> We found a major issue this week in how GMP was being built. [10:09] <robert457965> here's something warranting discussion [10:09] <william> The gmp-*/src directory had some patches for specific architectures already applied, [10:09] <robert457965> what is the best way to handle factoring poly [10:10] <robert457965> 's over RDF? [10:10] <william> instead of it being the generic upstream code. [10:10] <william> wait -- let's finish #319. [10:10] <robert457965> k [10:10] <william> did anybody else verify that it is fixed? [10:10] <dmharvey> sage: Matrix(QQ, 2, 2, [1, 1, 1, 1]) / 2 [10:10] <dmharvey> [10:10] <dmharvey> [1/2 1/2] [10:10] <dmharvey> [1/2 1/2] [10:11] <robert457965> same here [10:11] <william> somebody volunteer to make that a doctest and attach the patch to the bug report? [10:11] <william> then we'll close it. [10:11] <william> (same here) [10:11] <william> i volunteer. [10:12] <dmharvey> wow you are too fast for me [10:12] <william> [10:12] <robert457965> something just occurred to me [10:12] <william> question -- is this behavior generic? we should test more base rings. [10:12] <robert457965> anyone claiming to have lives outside of sage might say something... we can just say we were playing video games all day [10:12] <william> let's do it!! [10:12] <william> online gaming. [10:12] <william> or whatever it is called these days. [10:13] <robert457965> Matrix(ZZ, 2, 2, [1, 1, 1, 1]) / 2 works [10:13] <robert457965> m.m.o.r.p.g.? [10:13] <william> not so massive [10:13] <mabshoff> not yet, who knows who else will show up. [10:14] <william> i just found a bug. [10:14] <william> in sage-2.8.1 [10:14] <william> i tried to start a secure server on sage.math, and it fails. [10:15] <robert457965> RDF and RR work with the same example [10:15] <mabshoff> @william: Do you have a changelog with the changes in between 2.8 and the "bug" release? [10:15] <william> excellent. [10:15] <mabshoff> The one in sage:/bug/ is empty excpet the date. [10:15] <william> can somebody make sure nobody is in sage-dev. [10:15] <william> I think malb is there. [10:16] <william> it sage:lj/bug [10:16] <robert457965> only people who are checking... [10:17] <robert457965> so is that it for 319? [10:18] <mabshoff> That Changelog.txt starts with [10:18] <mabshoff> Sun Aug 12 14:24:58 2007 [10:18] <mabshoff>
[10:18] <mabshoff> Sun Aug 12 14:10:37 2007 [10:18] <mabshoff>
[10:18] <dmharvey> I think #319 is okay, as long as william carries through on his promise to writ a doctest [10:18] <mabshoff> And then the changes for 2.8 [10:18] <dmharvey> I am going to take a look at #350 [10:18] <william> I update the changelog on my laptop, but couldn't use my laptop all week. [10:18] <william> so no change log. [10:18] <william> yep. [10:19] <mabshoff> Ok [10:19] <william> mabshoff -- would you consider making a build change log? [10:19] <william> you know about as much as I do about it. [10:20] <mabshoff> Well, I am not exactly sure what happened in the details except: Most stuff now compiles better [10:20] <mabshoff> And I wonder about the details, i.e. die the Solaris lcalc compile fixes go in? [10:20] <william> maybe that's the entry. [10:20] <william> no. [10:21] <william> send me a new lcalc spkg [10:21] <mabshoff> Will do in a while. [10:21] <mabshoff> I had planned to work mostly on neron to see how things go with ""out of the box" sage. [10:22] <mabshoff> #389 (bug in mpfi C library) is still present. [10:22] <dmharvey> Question regarding #350. Originally you could do something like "f = x8 + x4" and then call f.change_ring(some ring). That no longer works since f is now a SymbolicArithmetic object rather than a polynomial. Does anyone think it would be good for SymbolicArithmetic objects to have a change_ring() method? My preferred answer is no, but I wanted to raise it since the example code in that bug report doesn't currently work. [10:22] <william> no. [10:22] <william> it doesn't make any sense. [10:22] <dmharvey> ok good [10:22] <william> Have to add x = polygen(QQ) at the beginning of the log. [10:22] <mabshoff> re changelog: There is always was/lj/todo.txt [10:23] <william> yes, great idea mabshoff. [10:23] <william> summarize something from that. [10:24] <dmharvey> look at that! #350 is already fixed too! I am jinxed! [10:24] <mabshoff> [10:24] <robert457965> question for #430: Would it be better to use GSL or numpy to find roots of a polynomial? [10:24] <dmharvey> I don't suppose anyone has any other bugs that they want fixed just by my magical gaze?.... [10:25] <robert457965> sorry, a polynomial of doubles [10:25] <william> doing hg_sage.pull() gets you the doctests for #319 [10:26] <william> oh yeah, somebody fixed #350. [10:26] <william> 2 down [10:26] <william> mabshoff -- want to fix #389? [10:27] <william> robert457965 -- use numpy. [10:27] <william> it will be way easier to code. [10:27] <william> however, it might be worth doing some benchmarking. [10:28] <william> what do people think aabout #190? [10:28] <william> The issue is that detecting fractional matrix indices will slow matrix indexing down. [10:28] <dmharvey> that's pretty funny [10:28] <mabshoff> Not sure yet. [10:29] <william> Maybe a[0.5] could be the average of rows 0 and 1 ?? [10:29] <mabshoff> I am checking if the patch for #226 still applies. [10:29] <robert457965> well, if it were a 0 by 0 matrix, you could just call iszero() [10:29] <dmharvey> where is the code for that indexing method? [10:29] <william> matrix/matrix0.pyx [10:29] <william> around line 538 [10:30] <william> by the way, when people fix things, if you give them to me somehow, I can post them so [10:30] <william> everybody else can get them with hg_sage.pull(). [10:30] <mabshoff> re #226 (with slight editing to account for pyrex->Cython: [10:30] <mabshoff> patching file Cython/Compiler/ExprNodes.py [10:30] <mabshoff> Hunk #1 succeeded at 2823 with fuzz 1 (offset 229 lines). [10:31] <mabshoff> I will rebuild cython and then sage-2.8 [10:31] <william> does the bug still happen? [10:32] <william> are you sure the patch is needed? [10:32] <mabshoff> you mean: is it fixed without applying the patch? [10:32] <william> yes [10:32] <mabshoff> Not yet, but I will test with the original cython. [10:32] <william> what's your test input? [10:32] <william> i'll just wait.. [10:33] <mabshoff> There is a regression.pyx attached to the ticket. Give me a minute to sort it all out. [10:34] <william> ok. [10:34] <william> dmharvey -- are you looking at #190? [10:34] <dmharvey> #190: do matrix subclasses generally override the getitem/setitme methods? [10:34] <william> one bad thing is: return self.row(int(key)) [10:35] <mabshoff> [mabshoff@m940 sage-2.8.1]$ cython regression.pyx [10:35] <mabshoff> [mabshoff@m940 sage-2.8.1]$ [10:35] <william> no, they enver do. [10:35] <mabshoff> That is without the patch. [10:35] <dmharvey> ok [10:35] <william> (regarding #190) [10:35] <mabshoff> So #226 can be closed then. [10:35] <william> not until i have the patch and have tested it too [10:36] <mabshoff> It was the original cython without the patch applied. [10:36] <dmharvey> #190: so I guess the real question is: if someone tries to index on something like a Rational, which happens to be an integer, should that be allowed? [10:36] <william> it's a simple patch. [10:36] <william> ok. [10:36] <william> #226 - oh -- it already works -- no patch needed? [10:36] <mabshoff> Yes. [10:36] <william> #190: yes. [10:37] <william> #226: where is regression.pyx [10:37] <mabshoff> The report for #226 was for pyrex 0.9.4.1, roughly 7 months old. [10:37] <william> ok. mabshoff - you can have the honors of closing the bug. [10:37] <mabshoff> attached to the ticket. [10:38] <dmharvey> #190: well then it's tricky.... at some point you need to just trying to coerce to an integer index. But floats get rounded when you do that. [10:38] <mabshoff> Mmh, I have to remember my trac password. [10:38] <william> #190: what does magma do? [10:39] <mabshoff> re #226: Reported by: was [10:39] <dmharvey> #190: actually there are two separate issues. One is speed; we could make the pathway faster by adding special code to test for Integer/int index. Second is sanity; are fractional indices allowed. [10:39] <dmharvey> #190: let me check on magma; never done matrices before so gimme a few minutes [10:39] <william> you are convincing me that we should just give an error if the input isn't int,long,Integer. [10:39] <william> wait -- can't we have a fast version, and if that doesn't work, have a slow version? [10:40] <mabshoff> william: How should we handle fixed bugs? [10:40] <mabshoff> Add some text (in this case) stating: Was fixed in a previous release of cython. [10:40] <william> for the sage library, make them available to me in any way, and I'll (1) put them in the official [10:40] <mabshoff> cython regressioin.pyx works. [10:40] <william> hg repository; for other things, I'll put them in /home/was/bug/ [10:41] <william> oh -- and post verbosely to trac! [10:41] --> ncalexan has joined this channel (n=[email protected]). [10:41] <william> hi nick. [10:41] <william> where you at? [10:41] <ncalexan> Hi folks... I can't stay long, relaxing with the family, but thought I'd see how things were. [10:41] <ncalexan> Victoria, BC. [10:41] <dmharvey> #190: magma raises an error "Runtime error in '[]': Bad argument types" [10:41] <ncalexan> You? [10:41] <william> i wonder what nick things. [10:41] <william> nick thinks. [10:42] <william> nick, if a is a matrix, and n = QQ(5), should a[n,n] be an error or not? [10:42] <dmharvey> #190: my preference is to allow only int/long/Integer [10:42] <dmharvey> hi nick [10:42] --> paulolivier_sage has joined this channel (i=8143024e@gateway/web/cgi-irc/ircatwork.com/x-f7a7e0b894111559). [10:42] <william> wait! [10:42] <-- paulolivier_sage has left this server (Client Quit). [10:42] <william> we should do whatever python lists do, shouldn't we? [10:42] <ncalexan> Yes. That's a reasonable answer. [10:43] <william> also, we should look at what numpy arrays and matrices do. [10:43] <dmharvey> sure [10:43] <ncalexan> That probably means calling int or something similar, no? [10:43] <william> python lists have an index protocol as of python 2.5. [10:43] --> pauloliviersage has joined this channel (i=8143024e@gateway/web/cgi-irc/ircatwork.com/x-539b7d4cf887a650). [10:43] <william> NO. [10:43] <ncalexan> Yeah, I think we best stick with that then. [10:43] <ncalexan> ? [10:43] <william> #190: A python list will call index and if that works, use it. otherwise fail. [10:44] <william> So anybody can make their own new class that can index into lists, etc., if they want. [10:44] <dmharvey> #190: ah that explains why you can index on an Integer [10:44] <william> I used to have to do this crap in the preparser: v = [1,2,3] [10:44] <william> v[Integer(2)] [10:44] <william> it totally sucked. [10:44] <william> We don't want to make SAGE users who make new classes suffer that way. [10:44] <william> #190 -- where? [10:45] <dmharvey> #190: sorry, I mean for a python list [10:45] <william> there must be a python/c api call to get foo.index() [10:45] <dmharvey> #190, i.e. v[Integer(2)] works, but v[2.5] doesn't [10:45] <ncalexan> Why was it bad? [10:45] <william> #190: yep, that's good. [10:45] <william> but if somebody wanted to make their own "2.5" and define an index method on it, then it would work. [10:45] <william> That's the best way to go. [10:45] <mabshoff> Ok, I close #226 [10:45] <mabshoff> +d [10:46] <william> thanks! [10:46] <william> 3 down. [10:46] <ncalexan> Ah, so it was too slow? [10:46] <mabshoff> But I think I found a bug in cython. [10:46] <william> 33 to go. [10:46] <william> report the cython bug to track [10:46] <mabshoff> cython -v doesn't work as expected. [10:46] <dmharvey> #190: so conclusion is that Matrix.getitem should use call index? instead of coercing to int? [10:46] <william> #190: no -- the problem was that it wasn't meaningful [10:46] <mabshoff> It just prints the standard help text. [10:46] <william> #190 http://www.sagemath.org:9002/sage_trac/ticket/190 [10:47] <william> mabshoff -- agreed. report it. [10:47] <william> #190: use. [10:47] <william> #190: dmharvey -- yes. [10:47] <dmharvey> #190: ok I will try to code thisup [10:48] <william> thanks!! [10:48] <william> i'm pasting this part of the transcript from irc into trac, since it explains the decision well. [10:48] <mabshoff> Which component in trac is cython? [10:49] <william> packages. [10:49] <mabshoff> ok [10:49] <william> it actually has its own bug tracker in berliOS too. see cython.org [10:49] <william> maybe that is a better place to post the bug. [10:49] <mabshoff> Too late, I gues. [10:49] <william> ? [10:49] <mabshoff> It is in now. [10:49] <william> no prob. [10:50] * pauloliviersage says hi [10:50] <mabshoff> It is #438 [10:50] <william> hi paul [10:50] <mabshoff> hello [10:50] <william> where are you at physically? [10:50] <pauloliviersage> oxford [10:50] <pauloliviersage> btw, william, if you have a chance at sage days bristol you should come around here and give a talk [10:50] <william> cool. [10:51] <pauloliviersage> let me know if you think you would have time, i am sure you will be busy [10:51] <mabshoff> the milestone pages updates itself in real time, pretty cool. [10:54] <william> i'm tracking status of what people ware working on here: http://sage.math.washington.edu/bug/status.html [10:54] <william> robert miller -- how is #430 going? [10:55] <william> I just looked at #248. it works fine now. can somebody else confirm this? [10:55] <pauloliviersage> i am working on the remote stuff [10:55] <william> I'm going to add a doctest and close it. [10:55] <william> what is "the remote stuff"? [10:55] <william> which trac number? [10:55] <dmharvey> #190: unfortunately this solution will slow down indexing, basically because I reckon the Integer.index() method is currently not all that optimised (it always goes via a python long!). Luckily Python has a special slot and fast calling convention for index, which pyrex knows about, so if we make Integer.index faster, then this shouldn't be a serious problem. Should I add an enhancement ticket to test and improve performa [10:56] <william> yes. [10:56] <william> thanks. [10:56] <pauloliviersage> doesn t have a trac number, it s the feature i had asked about: remote login to expect process (not implemented to use files right now), allowing for ssh tunneling through as many hops [10:56] <william> this is definitely the right solution, so we have to do it, despite any pain it causes. [10:56] <william> do you have a trac account? [10:57] <pauloliviersage> i have one [10:57] <pauloliviersage> pdehaye [10:57] <william> please create a trac ticket. [10:57] <pauloliviersage> ok [10:57] <william> with the twisted project they have a rule that *anything* you work on has a trac ticket. [10:57] <william> we don't, but it's perhaps a very good idea. [10:58] <dmharvey> #190: ok [10:59] <william> #190 -- did you right the code already? [10:59] <william> that was fast. [10:59] <dmharvey> #190: no, I'm just scoping out related issues still [10:59] <ncalexan> The last few patches I submitted, I created a trac -- I'm hoping that they'll live longer than my attention span that way. [10:59] <william> great idea. [11:00] <mabshoff> Yeah, a lot of the patches Didier did for the Nexenta port were lost and later recreated by William and me. [11:00] <william> (and by didier...) [11:01] <william> ok, i'm closing #248 -- it works fine now. [11:01] <mabshoff> Well, true - he must have forgotten about them by the porting sprint. [11:02] <pauloliviersage> #439 (should i add to milestone 2.8.2 so it figures in this sprint?) [11:02] <pauloliviersage> (i have added but am not sure) [11:02] <william> sure. [11:03] <william> though you make the game harder (since I hoped we would deal with everything in the list [11:03] <william> but if you can do it, then so much the better. [11:03] <dmharvey> #190: hmmmmm.... M = Matrix(3, 3, range(9)); M[1.5, 1.5]. This succeeds but for a different reason. I suppose I'll try to fix this too. [11:04] <pauloliviersage> (it s a bonus round) [11:04] <william> #190 -- yep, it must involve the implicit coercion to Py_ssize_t in the tuple extract in matrix0.pyx [11:04] <william> #254 -- dmharvey -- you reported this. [11:04] <william> #254 -- it now works fine i think david roe fixed it. it's p-adic precision loss in poly eval. [11:04] <william> I'm closing it. [11:05] <dmharvey> #254: ok thanks [11:05] <william> though one thing -- maybe it is still weird. [11:05] <william> Look: [11:05] <william> h = u + (1 + O(58))*u2 + (1 + O(54))*u3 [11:05] <william> sage: h(u) [11:05] <william> (1 + O(54))*u3 + (1 + O(58))*u2 + (1 + O(5^20))*u [11:05] <william> what about that coefficient of u? [11:06] <william> never mind -- it's padic capped, so [11:07] <william> sage: h = u*(1+O(530)) + (1 + O(58))*u2 + (1 + O(54))*u^3 [11:07] <william> is [11:07] <william> [11:07] <william> (1 + O(54))*u3 + (1 + O(58))*u2 + (1 + O(5^20))*u [11:07] <william> #254: i'm closing it. [11:08] <william> #268 -- another dmharvey bug -- is also now fixed [11:09] <mabshoff> Is that 5 down? [11:09] <william> yep. [11:09] <william> 6 down. [11:09] <william> ohh. #274 looks really hard. [11:09] <dmharvey> not all bugs are created equal though [11:09] <william> it's a memory leak. [11:10] <mabshoff> Yes, the quick ones will be gone first. [11:10] <william> i looked at this one with somebody from Austria 2 hours ago... [11:10] <william> #274: i'm going to work on this now; mabshoff and his valgrind might end up being helpful. we'll see. [11:12] <mabshoff> valgrinding python is rather tricky. [11:12] <william> yep. [11:12] <mabshoff> One needs to deallocate --py-malloc when python is build. [11:12] <mabshoff> And even then because python doesn't properly free many things upon exit it is very hard to interpret. [11:13] <mabshoff> deallocate -> deactivate [11:13] <william> i'm tracking status of people working here: [11:13] <william> http://sage.math.washington.edu/bug/status.html [11:14] <dmharvey> #190: So I've fixed M[1.5], but M.row(1.5) still works, because the prototype of row() is def row(self, Py_ssize_t i, from_list=False). [11:14] <william> actually, a wiki would be better. [11:14] <mabshoff> Ohh, a corner case in spkg-install: Call it with relative path from within the package. [11:14] <mabshoff> [mabshoff@m940 src]$ ../spkg-install > /dev/null [11:14] <mabshoff> ../spkg-install: line 6: cd: src: No such file or directory [11:14] <mabshoff> [mabshoff@m940 src]$ cd .. [11:14] <mabshoff> [mabshoff@m940 cython-20070728]$ ./spkg-install > /dev/null [11:14] <mabshoff> [mabshoff@m940 cython-20070728]$ [11:14] <william> it's not supposed to work. [11:14] <william> spkg-install must be called from the same directory in all cases. [11:14] <dmharvey> #190: william you know about matrices.... will it break things to change that prototype to pass i as a python object? [11:14] <mabshoff> ok [11:15] <ncalexan> brb [11:15] <-- ncalexan has left this server (Remote closed the connection). [11:16] <william> status is now here. [11:16] <william> http://www.sagemath.org:9001/bug1/status [11:17] <william> #190: i don't understand the question. [11:17] <mabshoff> I am looking into that cython bug right now, #438 [11:18] --> robertwb has joined this channel (n=[email protected]). [11:18] <william> hi robertwb! where you at? [11:18] <robertwb> hi, just sitting at home [11:18] <william> see http://www.sagemath.org:9001/bug1 [11:18] <william> you're probably most interested in #438 and #190. [11:19] <dmharvey> hi robertwb [11:19] <robertwb> hey there [11:20] <robert457965> hi robert [11:20] <robertwb> 457965 = miller? [11:21] <robert457965> yup [11:22] <william> I'm posting an irc log here -- robertwb might want to skim it: http://www.sagemath.org:9001/bug1/irc [11:22] <mabshoff> Re #274: I am building a valgrindable python right now. So if william has a testcase which leaks a lot of memory let me know. [11:22] <robertwb> ok, I'm off to attack #190 [11:22] <william> ok. [11:22] <william> talk to dmharvey first -- and see our big discussion. [11:23] <robertwb> yeah, I'm reading the discussion [11:23] <william> notice that http://www.sagemath.org:9001/bug1/status lists dmharvey as working on it. [11:23] <robertwb> oh [11:23] <william> you two should be able to devestate it. [11:23] <dmharvey> robertwb: also vaguely relevant to this is trac #440 that I just added [11:23] <robertwb> I didn't see that page [11:24] <william> it would be good to post some benchmark code and timings to #440. and a link from #190 to #440. [11:24] <robertwb> so, is there a quick way to pull the current bug-fixing version of sage? [11:24] <william> yes. [11:24] <william> do hg_sage.pull() [11:24] <robert457965> i am finishing a binary too [11:25] <william> there's a sage-2.8.1, in which essentially every package has changed, so upgrading is pointless. [11:25] <william> but we have binaries for everything but your laptop [11:26] --> mhansen has joined this channel (n=[email protected]). [11:26] <dmharvey> robertwb: if M is a matrix, one problem is that M.row(1.5) succeeds, because the prototype for row() uses Py_ssize_t for the index. [11:26] <robertwb> yeah... [11:26] <dmharvey> robertwb: and I'm wondering whether it would work for that prototype to be changed [11:27] <mabshoff> william: I got clisp_cvs to build on neron by adding the missing "--without-dynamic-ffi" to makemake [11:27] <mabshoff> make check still dies with an exception, [11:27] <william> mabshoff -- which gcc? [11:27] <mabshoff> 3.4.6 [11:27] <william> cool. [11:27] <mabshoff> maxima starts building, but dies with a floating point exception at some point. [11:28] <robertwb> dmharvey: perhaps there should be a fast macro that creates ints but dissallows rounding. [11:29] <mabshoff> Didier had the same problem on Nexenta: clisp + gcc 4.x is broken on Sunish systems [11:29] <mabshoff> But we should add the missing "--without-dynamic-ffi" to the spkg-install of clisp. [11:30] <william> definitel. (and poor lisp...) [11:30] <mabshoff> That cause the really odd "#define uint64_to_I(val) uint64_to_I(val) " [11:30] <dmharvey> robertwb: well there's some tradeoff here between speed and generality [11:30] <robertwb> dmharvey: yeah [11:30] <dmharvey> robertwb: even if you made such a macro, you still have to allow any python object to passed in, right? [11:30] <mabshoff> I haven't heard back from the clisp folks yet. [11:31] <robertwb> dmharvey: yes, but that is already the case (you're talking a def method, right?) [11:32] <dmharvey> robertwb: yes it's a def method. But currently the prototype is def row(self, Py_ssize_t i, from_list=False), so already it gets rounded before we even get to see it [11:33] <william> #190 -- by the way it was Chuck's Russian student Andrei Novoseltsov who reported #190... [11:33] <robertwb> dmharvey: I propose that we change cython so that Py_ssize_t calls index rather than int [11:33] <william> robertwb -- very good idea. [11:33] <william> do that. [11:33] <william> Since Py_ssize_t is supposed to be "the data type for doing indexing". [11:33] <robertwb> ok, that'll solve this issue all over the place [11:34] <dmharvey> #190: yes I think that sounds good [11:34] <william> #190: yeah bug squashing day [11:34] <robertwb> btw, I added (and fixed) the special method patch from Nick and it works great now [11:34] <robertwb> so I've got other cython changes to put upstream [11:35] <mabshoff> william - valgrind --trace-children=yes --tool=memcheck ./sage doesn't work with 2.8.1 [11:35] <william> oh. [11:35] <mabshoff> It dies with [11:35] <mabshoff> /tmp/Work2/sage-2.8.1/sage-2.8.1/local/bin/sage-ipython: line 6: [11:35] <mabshoff> SAGE IPython startup script. [11:35] <mabshoff> : command not found [11:35] <mabshoff> Should I rebuild IPython against the new python compiled with --without-pymalloc? [11:36] <william> See "sage -gdb". [11:36] <william> maybe have to run valgrind on the binary like that. [11:36] <william> Basically modify SAGE_ROOT/local/bin/sage-gdb to make a sage-valgrind. [11:36] <mabshoff> Okay, that might be worth a try. [11:39] <mabshoff> So while I am at it should I add a sage-valgrind? [11:40] <mabshoff> That would be called when you start sage with a new -valgrind option? [11:40] <william> yep. [11:40] <mabshoff> In that case we should also introduce a test for SAGE_DEBUG or something alike that conditionally builds sage's python with --without-pymalloc. [11:41] <william> yep. [11:41] <william> great ideas. [11:41] <robert457965> hooray for sage-valgrind! [11:41] <william> make a trac ticket for it. [11:41] <mabshoff> Okay, give me a while. [11:41] <mabshoff> okay. [11:41] <william> many many people would appreciate having an easy to way to create their own valgrindable sage. [11:41] <william> what a great tool for bug fixing. [11:42] <mabshoff> Well, it is still pretty hard to deciver, especially when you have leaks because of deferred deallocation. [11:42] <robert457965> better than ORDINARY bread [11:42] <-- was_ has left this server ("leaving"). [11:42] <dmharvey> #190: sage: M = Matrix(3, 3, range(9)); M[6/3] still works though, since Rational has an index method. This fails in magma, which is apparently stricter with index types. What do people think of that? [11:43] <william> i like our behavior better. [11:43] <william> magma is way too annoying that way. [11:43] <william> there are now only 995838 files left in robert's tmp directory [11:46] <mabshoff> What category for the sage-valgrind option? [11:46] <william> packages. [11:46] <robert457965> bad news about polynomial factoring in numpy [11:46] <mabshoff> ok. [11:47] <robert457965> sage: x = polygen(RDF) [11:47] <robert457965> sage: f = (x-1)^3 [11:47] <robert457965> sage: f.factor() [11:47] <robert457965> (1.0*x - 1.00000859959) * (1.0*x^2 - 1.99999140041*x + 0.999991400484) [11:47] <william> frickin' numbers. [11:48] <mabshoff> Do you want to factor univariate or multivariate polynomials? [11:48] <robert457965> univariate [11:48] <william> univariate double precision polys. [11:48] <mabshoff> Ok, so the NTL is out. [11:49] <mhansen> Has anyone done #342? It looks pretty straightforward to fix? [11:49] <william> mhansen: #342 -- go for it! [11:50] <william> nobody has looked it yet. [11:50] <dmharvey> #190: I have attached a partial fix, so now M[1.5] goes via PyNumber_index. [11:50] <william> i added you here: http://www.sagemath.org:9001/bug1/status [11:50] <dmharvey> #190: robertwb's proposal will fix a lot of other issues in #190 [11:51] <dmharvey> #190: i'm planning to look at #440 now, I want to find out if I can speed up the Integer.index() method much [11:51] <robertwb> ok [11:51] <dmharvey> #190: since that actually affects a *lot* of things [11:51] <william> I'll apply your code and post so others get it with hg_sage.pull() [11:51] <william> great. [11:51] <robertwb> 190 isn't as straightforward as I had hoped, 'cause it might have to mess with PyArg_ParseTupleAndKeywords [11:52] <william> #190 -- if you can do what you suggest, though, it will be very very nice. [11:52] <robertwb> yes, I'm still looking into it [11:54] <william> ok, i've pushed out dmharvey's patch. hg_sage.pull() to get it if you wnat. [11:59] <mabshoff> Hehe: [11:59] <mabshoff> [mabshoff@m940 sage-2.8.1]$ ./sage --valgrind [11:59] <mabshoff>
[11:59] <mabshoff> | SAGE Version 2.8.1, Release Date: 2007-08-18 | [11:59] <mabshoff> | Type notebook() for the GUI, and license() for information. | [11:59] <mabshoff>
[11:59] <mabshoff> /tmp/Work2/sage-2.8.1/sage-2.8.1/local/bin/sage-gdb-pythonstartup [11:59] <mabshoff> ==964== Memcheck, a memory error detector. [11:59] <mabshoff> ==964== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. [11:59] <mabshoff> ==964== Using LibVEX rev 1658, a library for dynamic binary translation. [12:00] <mabshoff> ==964== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. [12:00] <mabshoff> ==964== Using valgrind-3.2.1, a dynamic binary instrumentation framework. [12:00] <mabshoff> ==964== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. [12:00] <mabshoff> ==964== For more details, rerun with: -v [12:00] <mabshoff> ==964== [12:00] <mabshoff> Python 2.5.1 (r251:54863, Aug 18 2007, 20:37:45) [12:00] <mabshoff> [GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2 [12:00] <mabshoff> Type "help", "copyright", "credits" or "license" for more information. [12:00] <mabshoff> --964-- DWARF2 CFI reader: unhandled CFI instruction 0:10 [12:00] <mabshoff> --964-- DWARF2 CFI reader: unhandled CFI instruction 0:10 [12:00] <mabshoff> ==964== Source and destination overlap in strcpy(0x7FEFEE210, 0x7FEFEE210) [12:00] <mabshoff> ==964== at 0x4A06E47: strcpy (mc_replace_strmem.c:106) [12:00] <mabshoff> ==964== by 0x1C4ACEAF: feCleanUpPath(char*) (in /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/libsingular.so) [12:01] <mabshoff> ==964== by 0x1C4AD8CB: feInitResource(feResourceConfig_s*, int) (in /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/libsingular.so) [12:01] <mabshoff> ==964== by 0x1C4AE021: feInitResources(char*) (in /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/libsingular.so) [12:01] <mabshoff> ==964== by 0x1C421768: siInit(char*) (in /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/libsingular.so) [12:01] <mabshoff> ==964== by 0x1C122AAF: initmulti_polynomial_libsingular (multi_polynomial_libsingular.cpp:1103) [12:01] <mabshoff> ==964== by 0x49F3F2: _PyImport_LoadDynamicModule (importdl.c:53) [12:01] <mabshoff> ==964== by 0x49D2CE: import_submodule (import.c:2394) [12:01] <mabshoff> ==964== by 0x49D7A1: load_next (import.c:2214) [12:01] <mabshoff> ==964== by 0x49D9C3: import_module_level (import.c:1995) [12:01] <mabshoff> ==964== by 0x49DE34: PyImport_ImportModuleLevel (import.c:2066) [12:01] <mabshoff> ==964== by 0x47D268: builtin_import (bltinmodule.c:47) [12:01] <mabshoff> Didn't you chase a bug in libSingular? [12:01] <mabshoff> Anybody still alive? [12:01] <william> i am [12:01] <william> i think we're all just working on bugs
Sage Bug 1 took place from 10 am PST August 18th until 2 am August 19th. ==Participants== In order of apperance, handle in brackets William Stein (william, _was) Robert Miller (robert457965) D. Harvey (dmharvey) Michael Abshoff (mabshoff) Nick Alexander (ncalexan) Paul-Oliver Dehaye (paulolivier_sage) Robert Bradshaw (robertwb) Mike Hansen (mhansen) Alex Clemesha (agc) Yi Qiang (yi)
There we various observers present, but those have been omitted here. They can be found in the IRC log. Bugs squashed: (see also http://www.sagemath.org:9002/sage_trac/milestone/sage-2.8.2). Please complain if there are mistakes, especially regarding credit for fixes: #160: partitions -- sage dies (fixed by w stein, m hansen has code that doesn't use GAP and should be much faster.) #190 (and #440): fractional matrix indices are allowed ? (fixed by d harvey) #201: mwrank crashing (fixed via patches by j cremona, small memleak fixed by m abshoff) #206: Graphic.append() does not update xmin_ xmax etc. (fixed by r miller and agc) #226: sagex enum issue and solution (closed by m. abshoff - already fixed) #240: in notebook when refresh browser or first get page cell update list isn't sent out with running cells #248: elliptic curve constructor in funny case -- coercion issues (closed by w. stein - already fixed) #254: p-adic precision drop in evaluating a polynomial (closed by w. stein - already fixed, probably fixed by d roe) #265: Coercion of maxima float with positive exponent to python float (closed by w. stein - already fixed) #268: IntegerMod sqrt() doesn't work for non-prime moduli (closed by w. stein - already fixed) #274: memory leak --- Polynomial arithmetic over finite field (fixed by w stein, d harvey) #275: Maxtrix groups over RR don't get pushed off to GAP properly (fixed by w stein) #292: Problems with stacked polynomial rings and vector (fixed by w stein) #293: nasty memory leak in FAST_SEQ_UNSAFE macro (fixed by r bradshaw) #303: modular forms bug (fixed by w stein) #304: another modular forms bug (fixed by w stein) #312: LaTex notation in documentation does not show up in notebook doc browser #316: bug in modular symbols projection (probably really in linear algebra) (closed by m hansen - already fixed) #319: can't divide matrix over QQ by a rational (closed by d harvey - already fixed, doctest added by w stein) #321: execute button broken in some worksheets (closed by w stein - the execute button no longer exists after the notebook rewrite) #337: broken (?) discriminant of quaternion algebra (closed by m hansen - already fixed) #340: error in sageinspect: ode_solver? (already fixed, closed by n alexander) #342: ComplexNumber constructor seg faults (m hansen) #349: Tab completion on Sage() object does not work (already fixed, closed by w stein) #350: bug in rational_points on hyperelliptic curve (closed by d harvey - already fixed) #352: error in matrix creation options (already fixed, closed by m abshoff) #371: implement sage -t -gdb foo.py (patch by w stein) #374: Bug in factorization of polynomial over number field (fixed by w stein, initial patch by j mohler) #392: round() ignores the innate precision of a real number (fixed by m hansen) #393: Very strange behavior of QQ -> RealField() conversion (resolved by m hansen, report was invalid) #402: %slide directive produces segfault in dvipng (already fixed, closed by m abshoff. dvipng is a system binary and not part of Sage) #420: SAGE's optional axiom package doesn't build on os x (closed by w. stein - axiom works fine on clisp) #423: command line help() --> modules fails for *some* people (fixed by w stein) #429: cannot create empty sparse matrix over reals (fixed by w stein) #430: RDF poly's don't factor (w. stein: The factoring now works, but it depends on root finding, which currently sucks. A new ticket will be made for the root problem.) #433: Add -version, -root, and -branch for printing version, SAGE_ROOT, and branch information. () #440: Integer.index() currently goes via a python long (fixed by d harvey) #441: add sage-valgrind command line option analog to sage-gdb (patch by m. abshoff) #442: RDF roots() function gives imprecise results (duplicate) #446: in latest version of the notebook interactive documenation doesn't "interact" at all. (fixed by w stein) #447: documentation for mpfr round in SAGE sucks (fixed my m hansen with help from w stein) #456: TypeError: unable to coerce to a ComplexNumber (fixed my h. hansen) #457: gp interface: TypeError: an integer is required (fixed by w stein) #458: plot.py: NameError: name 'p1' is not defined (fixed by r miller) #459: TypeError: unsupported operand parent(s) for '*': 'Polynomial Ring in u_ v over Integer Ring' () #460: AttributeError: 'Graphics' object has no attribute 'append' (fixed by r miller)
add Details to bugs, give proper credit for each bug resolved a summary of what was good, what was bad and maybe suggestions on how things could be improved. (potentially new) sage development guide lines: see http://www.divmod.org/trac/wiki/UltimateQualityDevelopmentSystem - this maybe should go into a more general section of the wiki [12:02] <mabshoff> okay. [12:02] <mabshoff> But the -valgrind option works, [12:02] <william> frickin awesome!!!! [12:02] <mabshoff> and doesn't crash valgrind. [12:02] <mabshoff> And " ==964== Source and destination overlap in strcpy(0x7FEFEE210, 0x7FEFEE210)" [12:03] <mabshoff> might be a problem that Martin and I saw with libSingular on Opteron's in 64 bit mode. [12:03] <william> cool. [12:04] <robert457965> #430 -- fixed [12:04] <william> how? [12:04] <robert457965> at least, now factoring is implemented [12:04] <robert457965> but the roots function for RDF needs to be improved [12:04] <william> ok. [12:04] <william> post a patch. [12:07] <mabshoff> mmmh, just starting and quitting sage gives me the following: [12:07] <mabshoff> =1024== LEAK SUMMARY: [12:07] <mabshoff> ==1024== definitely lost: 2,500 bytes in 1 blocks. [12:07] <mabshoff> ==1024== possibly lost: 276,902 bytes in 769 blocks. [12:07] <mabshoff> ==1024== still reachable: 130,181,755 bytes in 159,788 blocks. [12:07] <mabshoff> ==1024== suppressed: 0 bytes in 0 blocks. [12:07] <mabshoff> ==1024== Use --leak-check=full to see details of leaked memory. [12:07] <mabshoff> That's 130MB in limbo. [12:07] <robert457965> #430 -- http://sage.math.washington.edu/home/rlmill/RDF_factor.patch [12:10] <robert457965> funny for 53 bits of precision returning answers true up to about 5 bits [12:11] <dmharvey> does anyone know the official definition of the range of the python int type? Is it the same as a C int or long? [12:11] <dmharvey> it's just a C long right? [12:12] <william> better look it up. [12:12] <dmharvey> yeah I tried and couldn't find it [12:12] <dmharvey> the best I can do is note that the C api seems to use "long" everywhere [12:13] <william> robert457965 -- try directly using numpy's roots and try to track down where the precision loss is. [12:13] <-- robertwb has left this server (Read error: 104 (Connection reset by peer)). [12:13] <william> i pushed out robert457965's changes. [12:14] <robert457965> closing ticket #430, creating a new one [12:14] <william> good. [12:14] <william> add it to the roadmap for today [12:14] <robert457965> #442 [12:15] <mabshoff> william - I set PYTHONSTARTUP=$SAGE_ROOT/local/bin/sage-valgrind-pythonstartup - now I don't get a sage prompt any more, but ">>>" [12:16] <mabshoff> With sage-gdb-pythonstartup it works, [12:16] <mabshoff> where should I look? [12:16] --> robertwb has joined this channel (n=[email protected]). [12:16] <william> ? [12:16] <william> >>> is Python's prompt. [12:16] <william> the SAGE: prompt comes from using ipython. [12:16] <mabshoff> Ok. [12:16] <mabshoff> I copied sage-gdb and renamed it sage-valgrind. [12:16] <mabshoff> Added a -valgrind option in sage-sage. [12:17] <mabshoff> When PYTHONSTARTUP is set to *gdb* (as with the old sage-gdb script) everthing works as expected. [12:17] --> ncalexan has joined this channel (n=[email protected]). [12:17] <mabshoff> But if I set it to *-valgrind* I loose the sage prompt and get the python one. [12:18] <william> oh - you have to create correctly the file sage-valgrind-pythonstartup? [12:18] <mabshoff> No, I just figured that out, too. [12:18] <mabshoff> Should I just reused the *gdb* one? [12:19] <william> i guess so. [12:19] <mabshoff> ok. [12:20] <ncalexan> 265: would it be enough to do return float(str(self.numer()).replace(' ', )) [12:20] <mabshoff> I will put a comment about that in sage-valgrind [12:20] <robert457965> #211 is related to this root finding stuff, i've added that to the milestone too [12:20] <ncalexan> In maxima.py:float? [12:20] <william> ncalexan: please elaborate? [12:21] <william> ahh. i missed your earlier remark. [12:21] <robert457965> ncalexan -- you're on ticket #211 [12:21] <william> #265, i think. [12:22] <william> n#265 -- it just works already. [12:22] <william> weird. [12:22] <william> for me at least. [12:22] <ncalexan> 265: I will try it here. [12:23] <william> yeah, for #265, it works for me already. [12:23] <robert457965> #265 -- works here too [12:24] <william> ok, closed. [12:24] <ncalexan> Works here, Mac OS X 10.4, Intel Core2. [12:24] <ncalexan> The maxima output is "better", but we still need a doctest for that behaviour. [12:25] <william> i'm adding some right now. [12:25] <ncalexan> Great! [12:25] <william> hg_sage.pull() to get it. [12:25] <mabshoff> Ok, for the valgrind option: [12:25] <mabshoff> http://fsmath.mathematik.uni-dortmund.de/~mabshoff/patches/sage-valgrind [12:26] <mabshoff> (the script itself) [12:26] <mabshoff> http://fsmath.mathematik.uni-dortmund.de/~mabshoff/patches/sage-2.8.1-add_sage_-valgrind_option.patch [12:26] <mabshoff> The patch for sage-sage. [12:26] <william> ok. [12:26] <ncalexan> william: I sent you a patch for sage-sage, -version etc, did it arrive? [12:26] <mabshoff> lightly tested, still need to work on adding the --without-pymalloc option to the python spkg-install [12:27] <william> ncalexan -- hold on. [12:30] <william> mabshoff. [12:30] <mabshoff> Yes [12:30] <william> I applied your patch to hg_scripts and pushed it out. [12:30] <ncalexan> Great! [12:31] <mabshoff> Okay. [12:31] <william> i made some changes and had to apply it manually. [12:31] <mabshoff> really? [12:31] <william> see http://www.sagemath.org/hg/scripts-main [12:31] <mabshoff> I thought I used the current packages. [12:31] <william> I moved the valgrind help message to the advanced section of the help, is all. [12:32] <mabshoff> ok [12:32] <william> ncalexan -- where is your patch. [12:32] --> dmharvey_ has joined this channel (n=[email protected]). [12:32] <ncalexan> My email must be broken, something is weird here. [12:32] <mabshoff> I just created ticket #443: libSingular: Source and destination overlap in strcpy and assigned it to malb [12:33] <william> [12:33] <william> i hope he shows up later... [12:33] <mabshoff> That should teach him not to show up in a bug fix session. [12:33] <william> ncalexan: can you just post a link here or post something to trac? [12:34] <mabshoff> The last time I didn't show up for a CoCoA meeting I got truly horrible tasks assigned. [12:35] <william> nick -- got it. [12:37] <ncalexan> william: yes, try http://www.sagemath.org:9002/sage_trac/ticket/433 [12:38] <william> nick -- got the patch, applied it, slightly changed it, and pushed it out. [12:38] <william> do hg_scripts.pull() [12:39] <william> I *can't* believe sage didn't have "sage -v" or "sage -root" until now. Stupid. [12:39] <william> thanks! [12:40] <ncalexan> n/p. [12:40] <robertwb> ok, update on the Py_ssize_t indexing stuff [12:40] <robert457965> william - all numpy does to compute roots is compute eigenvalues of the companion matrix! [12:41] <william> robert457965 -- yep. [12:41] <robert457965> it makes a bad choice of casting at some point [12:41] <robertwb> if you do "cdef Py_ssize_t k = o" it will call o.index [12:41] <william> wow! [12:41] <robert457965> actually, if you look at ticket 442, this is where [12:42] <robertwb> but if Py_ssize_t is in the method signature, it calls int deep in the python library due to PyArg_ParseTupleAndKeywords [12:42] <robertwb> any thoughts? [12:42] <william> it's an acceptable compromise for now. [12:42] <william> but you should write up a trac entry about this and/or something for the cython page. [12:43] <robertwb> ok [12:43] <mhansen> william: I just sent a bundle fixing #342. [12:44] <robertwb> it should be fairly easy to throw an error when parsing the tuple, but messing with the keywords it a bit worse [12:45] <william> ok, i'm looking at #342 now. [12:45] <dmharvey_> robertwb: I'm confused... I didn't think you could use type signatures like Py_size_t for keyword arguments [12:46] <dmharvey_> robertwb: sorry, no you're right, one can do that [12:47] <dmharvey_> robertwb: no, I'm still confused. Can you give me an example. [12:48] <robertwb> dmharvey_: ok, for the row example [12:48] <-- dmharvey has left this server (Read error: 110 (Connection timed out)). [12:48] <robertwb> dmharvey_: def row(self, Py_ssize_t k) [12:48] <william> mhansen: #342 -- great work. [12:48] <robertwb> dmharvey_: suppose I call M.row(3.5) [12:48] <william> i'm changing s_imag == None to "s_imag is None", which is slightly faster. [12:48] <robertwb> dmharvey_: that would be an error, but M.row(k=3.5) would not... [12:49] <dmharvey_> oh [12:49] <robertwb> would this be a good thing? [12:49] <mhansen> william: #342 -- sounds good. [12:49] <william> mhansen #342 -- there's something screwey with base. [12:49] <dmharvey_> no of course not; the behaviour at the user's end should be identical [12:49] <william> you harcoded something for debugging and never put it in the inputs correctly. [12:51] <william> mhansen -- only base 10 is supported, I think. [12:51] <mhansen> william: That's what I thought since I didn't see base referenced anywhere in the ComplexField code. [12:51] <william> yep. [12:51] <mhansen> It could easily be added though. [12:51] <william> hold on. [12:51] <william> how? [12:52] <robertwb> dmharvey_: of course, this would only be when int(x) != index(x) [12:52] <william> mhansen -- ok, via mpfr. [12:52] <dmharvey_> robertwb: well, this can happen, but it's a pretty borderline case [12:53] <mhansen> william: Is that something that should be added? [12:53] <william> definitely, if you want. [12:53] <william> by the way I just made some minor changes. Do hg_sage.pull() to get them. [12:53] <william> Also, it would be good to add some doctests that illustrate what pad and min_prec do. [12:53] <william> There aren't any now. [12:53] <william> Could you do that and post another patch? [12:54] <william> You can close #342 as fixed though :-). [12:54] <dmharvey_> robertwb: so can the keyword thing be fixed? Like, is it a Cython issue or a Python issue? I don't totally understand the control flow when th keyword argument is passed like that. [12:55] <mhansen> william: Sure thing. [12:55] <robertwb> dmharvey_: Cython calls PyArg_ParseTupleAndKeywords... I actually think the keyword thing might have a hope of being fixed after all (looking into it now) [12:55] <william> I'm going to work on #275 now -- i need something easy, since #274 is *really* nasty. [12:56] <mabshoff> Can I invoke the analog of sage -testall from a running sage session. [12:56] <mabshoff> The problem is that -testall and -valgrind don't mix. [12:56] <william> sage -testall does a lot of stuff. At the end of the day for each file it creaes [12:56] <william> ... [12:57] <william> see "sage -t -gdb filename.py" for what will probably get you what you want. [12:57] <mabshoff> Okay. I will have a look. [12:57] <william> i.e., sage -t filename.py creates .doctest_filename.py, and then does "python .doctest_filename.py". [12:57] <william> YOu can run valgrind on that python. [12:57] <mabshoff> i looked into sage-testall. [12:58] <mabshoff> And I switched "sage -t "@" *" to "sage "@" -t *" [12:58] <mabshoff> But it doesn't work is $@=="-valgrind" 
[12:59] <william> look in sage-doctest! [13:00] <mabshoff> Okay. [13:00] <william> (not meant as a shout if it sounded that way, btw) [13:00] <dmharvey_> ok, I've got a reasonable solution for #440, I'll post the patch as soon as the doctests finish. Meanwhile has anyone got suggestions of what to look at next, or should I just pick something.....? [13:01] <mabshoff> Well, I can always leave if I feel bullied [13:01] <william> there is a massive memory leak in polynomial creation over the pari finite field. [13:01] <william> #274. [13:01] <mabshoff> I can see if I get some data on that. [13:01] <dmharvey_> ok i'll have a look [13:02] <william> I just posted another good example to http://www.sagemath.org:9002/sage_trac/ticket/274 [13:02] <william> I shamefully suspect [13:02] <william> maybe something really dumb in gen.pyx. [13:02] <william> I really really really hope to resolve #274 today, since this is a hugely embarassing bug, whatever it is. [13:04] <mabshoff> Okay, valgrind is running with that example. [13:04] <mabshoff> It will probably take a while. [13:04] <william> excellent. [13:05] <william> you can change the 10000 to 1000 [13:05] <william> it leaks 20-30mb with 10000 on my machine. [13:05] <mabshoff> Then I will just run start & quit under valgrind and diff the two logs. [13:05] <mabshoff> Maybe something interesting will stand out. [13:05] <mabshoff> I am running it on a webserver, so let's hope I don't OOM anything. [13:09] <-- ncalexan has left this server (Read error: 110 (Connection timed out)). [13:17] <dmharvey_> #440: posted patch for this, and some profiling data. [13:17] <william> ok. i'll look in a minute. [13:19] <robert457965> #442 -- precision is an issue for the eigen functions too [13:19] <robert457965> sage: g = Matrix(RDF, 0, -9],[1,6); g [13:19] <william> looks like we have to try gsl then [13:19] <robert457965> [ 0.0 -9.0] [13:19] <robert457965> [ 1.0 6.0] [13:19] <robert457965> sage: g.eigen_left() [13:19] <robert457965> ([3.00000003183, 2.99999996817]... [13:19] <robert457965> where 0.0 == zero.zero [13:20] <william> maybe the gsl real root finder is significantly better. [13:21] <william> to use that, we'd add it maybe as a method for for ector over rdf (an underscored method) [13:22] <william> ok, trac #275 is fixed (just a matter of doing a little better exception handling) [13:23] <mabshoff> re #274: [13:23] <mabshoff> A "plain" sage session: [13:23] <mabshoff> ==2609== LEAK SUMMARY: [13:23] <mabshoff> ==2609== definitely lost: 2,500 bytes in 1 blocks. [13:23] <mabshoff> ==2609== possibly lost: 276,902 bytes in 769 blocks. [13:23] <mabshoff> ==2609== still reachable: 130,182,544 bytes in 159,833 blocks. [13:23] <mabshoff> ==2609== suppressed: 0 bytes in 0 blocks. [13:23] <mabshoff> With William's example script: [13:23] <mabshoff> ==2660== LEAK SUMMARY: [13:23] <william> dmharvey -- what's trac-440.hg' a patch against? i get unknown parent. [13:23] <mabshoff> ==2660== definitely lost: 2,767 bytes in 16 blocks. [13:23] <mabshoff> ==2660== possibly lost: 337,014 bytes in 893 blocks. [13:23] <mabshoff> ==2660== still reachable: 156,394,179 bytes in 203,126 blocks. [13:23] <mabshoff> ==2660== suppressed: 0 bytes in 0 blocks. [13:23] <william> cna you send a text version? [13:24] <mabshoff> The logs are roughly 5.5MB and 5.7MB respectively. [13:24] <william> dmharvey_ -- #440 -- i can't apply your patch. [13:24] <dmharvey_> oh [13:25] <william> wait -- it's because I got it out of track. [13:25] <william> maybe. [13:25] <william> binary patches and track don't mix well. [13:25] <dmharvey_> it's probably on top of the previous patch, sorry [13:25] <william> that possible too. [13:25] <dmharvey_> sorry I'll stick to text patches [13:26] <dmharvey_> (I was concerned that my log message wasn't coming through on the text patch, but I might be wrong about that) [13:26] <william> if you do hg_sage.send('...') its cumulative. [13:26] <william> or you could email it to me. [13:26] <william> that can happen with text patches. [13:26] <dmharvey_> ok hang on [13:26] <william> Do hg_sage.send('...') and email the bundle to me. [13:26] <dmharvey_> ummm I've already switched branches and am in the middle of debugging something else, i'll send it by text [13:27] <william> sure. [13:28] <mabshoff> There are some intersting issues with pari for exmape: [13:28] <mabshoff> For example we do not allocate 0.5 mb when instanciating libpari: [13:29] <mabshoff> ==2609== 524,288 bytes in 1 blocks are still reachable in loss record 6,975 of 6,989 [13:29] <mabshoff> ==2609== at 0x4A05809: malloc (vg_replace_malloc.c:149) [13:29] <mabshoff> ==2609== by 0xF990B2A: gpmalloc (in /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/libpari-gmp.so.2) [13:29] <mabshoff> ==2609== by 0xF991BCE: pari_init_opts (in /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/libpari-gmp.so.2) [13:29] <mabshoff> ==2609== by 0xFF07371: pyx_f_3gen_12PariInstance_init (gen.c:20988) [13:29] <mabshoff> ==2609== by 0x459FB1: type_call (typeobject.c:436) [13:29] <mabshoff> ==2609== by 0x4156B2: PyObject_Call (abstract.c:1860) [13:29] <mabshoff> ==2609== by 0x47D801: PyEval_CallObjectWithKeywords (ceval.c:3433) [13:29] <mabshoff> ==2609== by 0xFF096E8: initgen (gen.c:27669) [13:29] <mabshoff> ==2609== by 0x49F3F2: _PyImport_LoadDynamicModule (importdl.c:53) [13:29] <mabshoff> ==2609== by 0x49D2CE: import_submodule (import.c:2394) [13:29] <mabshoff> ==2609== by 0x49D7A1: load_next (import.c:2214) [13:29] <mabshoff> ==2609== by 0x49D9FE: import_module_level (import.c:2002) [13:30] <mabshoff> Mhh, we actually do that one *twice* [13:30] <dmharvey_> ok, the text patch is at /home/dmharvey/patches/trac-440.patch; the log message should be approximately "add new mpz_get_pyintlong() function which returns either python int (fast!) or python long if it doesn't fit; change some Integer methods to use this new function" [13:31] <william> how are you making patches by the way? [13:31] <william> hg_sage.export(...) makes them and they contain the comments, etc. [13:32] <robert457965> #442 -- i'm closing this ticket, since it is part of #211. [13:32] <robert457965> The example on GSL's page is much more accurate than numpy's output. [13:33] <william> ok. [13:33] <william> #440 -- david I'm applying your patch now. [13:33] <dmharvey_> usually I make them from the command line, using "hg bundle" or "hg export" or sometimes just "hg diff" to a file [13:34] <dmharvey_> I don't usually use hg_sage.export() since I'm not usually in a sage session [13:34] <william> hg_sage.export is the same as "hg export". [13:34] <william> it is better than "hg diff", since it includes the comments. [13:34] <dmharvey_> ok [13:34] <mabshoff> Ok, here is an allocation for 100MB for the stack of a pari instance: [13:34] <mabshoff> ==2660== 100,000,000 bytes in 1 blocks are still reachable in loss record 7,200 of 7,200 [13:34] <mabshoff> ==2660== at 0x4A05809: malloc (vg_replace_malloc.c:149) [13:34] <mabshoff> ==2660== by 0xFEE00BA: pyx_f_3gen_init_stack (gen.c:25497) [13:34] <mabshoff> ==2660== by 0xFF0744D: pyx_f_3gen_12PariInstance_init (gen.c:21006) [13:34] <mabshoff> ==2660== by 0x459FB1: type_call (typeobject.c:436) [13:34] <mabshoff> ==2660== by 0x4156B2: PyObject_Call (abstract.c:1860) [13:35] <mabshoff> ==2660== by 0x47D801: PyEval_CallObjectWithKeywords (ceval.c:3433) [13:35] <william> #440 is closed -- and i've applied and pushed your patch out david. [13:35] <mabshoff> ==2660== by 0xFF096E8: initgen (gen.c:27669) [13:35] <mabshoff> ==2660== by 0x49F3F2: _PyImport_LoadDynamicModule (importdl.c:53) [13:35] <mabshoff> ==2660== by 0x49D2CE: import_submodule (import.c:2394) [13:35] <mabshoff> ==2660== by 0x49D7A1: load_next (import.c:2214) [13:35] <mabshoff> ==2660== by 0x49D9FE: import_module_level (import.c:2002) [13:35] <mabshoff> ==2660== by 0x49DE34: PyImport_ImportModuleLevel (import.c:2066) [13:35] <mabshoff> Does pyx_f_3gen_init_stack have a matching deallocation? [13:35] <william> mabshoff -- yes, on initialization we allocate 100MB for the stack. [13:35] <mabshoff> Could we dealloc that upon exiting sage? [13:35] <william> It doesn't. [13:36] <william> I'll put in code to do that now. [13:36] <william> It goes in sage/sage/libs/pari/gen.pyx, probably right below the first init in that file. [13:36] <mabshoff> This is just like valgrinding LinBox: In the beginning the was so much noise I couldn't find the bugs I was hunting. [13:36] --> agc has joined this channel (n=[email protected]). [13:36] <william> hi agc! [13:36] <william> where are you at? [13:36] <mabshoff> So this might be a somewhat longer process, but in the end it should pay off. [13:36] <robert457965> i'm working on #206 now [13:37] <agc> hi, im at the ucsd library [13:37] <william> there's an irc log for today here: http://www.sagemath.org:9001/bug1/irc [13:37] <william> how was the surfing this morning [13:37] <william> i almost went to the beach [13:37] <agc> actually i seen most of it because dorian logged on earlier ... [13:38] <william> ok, good. [13:38] <william> you might like this bug: http://www.sagemath.org:9002/sage_trac/ticket/206 [13:38] <william> it's in your code, I think. [13:38] <mabshoff> Ooh, the log is life, pretty cool. [13:38] <william> David harvey reported it. [13:39] <william> I just updated the log by hand. [13:39] <mabshoff> Okay, would have been cool, though. [13:39] <william> indeed. [13:39] <mabshoff> Re the leak with the 10.000 repeats: [13:39] <mabshoff> ==2660== 23,450,392 bytes in 20,008 blocks are still reachable in loss record 7,199 of 7,200 [13:39] <mabshoff> ==2660== at 0x4A05809: malloc (vg_replace_malloc.c:149) [13:39] <mabshoff> ==2660== by 0xFF04187: pyx_f_3gennew_gen (gen.c:25711) [13:39] <mabshoff> ==2660== by 0xFF043FD: pyx_f_3gen_12PariInstance_new_gen (gen.c:21826) [13:40] <mabshoff> ==2660== by 0xFEFD4D2: pyx_f_3gen_3genmul_c_impl (gen.c:1527) [13:40] <mabshoff> ==2660== by 0xE1DEFAD: pyx_f_7element_11RingElementmul_c (element.c:8801) [13:40] <mabshoff> ==2660== by 0xE1CF814: pyx_f_7element_11RingElement_mul (element.c:8383) [13:40] <mabshoff> ==2660== by 0x41597C: binary_op1 (abstract.c:398) [13:40] <mabshoff> ==2660== by 0x419107: PyNumber_Multiply (abstract.c:669) [13:40] <mabshoff> ==2660== by 0x481113: PyEval_EvalFrameEx (ceval.c:1072) [13:40] <mabshoff> ==2660== by 0x48627F: PyEval_EvalCodeEx (ceval.c:2831) [13:40] <mabshoff> ==2660== by 0x4CFAA7: function_call (funcobject.c:517) [13:40] <mabshoff> ==2660== by 0x4156B2: PyObject_Call (abstract.c:1860) [13:40] <mabshoff> looks interesting. [13:41] <william> yep. [13:41] <mabshoff> Valgrind rocks. Don't leave home without it [13:42] <dmharvey_> #274: just noting that if A = K(1), then you can get the leak by just repeating R(A), not necessary to do R([1]), so it's probably not in the field coercion code itself, it really has something to do with the polynomials [13:42] <robert457965> #206 - closed. patch at http://sage.math.washington.edu/home/rlmill/xmin.patch [13:42] <william> yep. [13:43] --> dmharvey has joined this channel (n=[email protected]). [13:46] <william> agc -- never mind about 206 -- it just got fixed. [13:47] <agc> oh, i was messing with it ... what exactly changed? [13:47] <william> it's the patch tahar robert just posted 5 minutes ago above. [13:48] <william> HOWEVER -- robert457965 didn't post any doctests that illustrate the bugfix. [13:48] <william> do hg_sage.pull() to get all the fixes so far, including Robert's. [13:49] <robert457965> my original thinking was that the plot will show either way, but now i realize you can still get xmin etc. [13:50] <agc> my 2.8.1 build just finish any second now ... ill pull then [13:51] <agc> where 'second' <= oo [13:54] [CTCP] Received Version request from freenode-connect. [13:54] [Notice] -NickServ- This nickname is owned by someone else [13:54] [Notice] -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password> [13:54] --> You have joined the channel #sage-devel (n=[email protected]). [13:54] [Error] sage-dev: No such channel. [13:54] <william> robertwb -- with your cython patch is trac #190 now fixed. [13:54] <robert457965> yeah, those are all my fault [13:54] *** Channel modes: secret, no messages from outside [13:54] *** This channel was created on 08/17/2007 01:03:33 PM. [13:54] <robertwb> yep [13:55] <william> excellent. i'll close it. [13:56] <william> status report time! [13:56] <william> everybody write a sentence about what they're doing right now. i'll paste it into the wiki. [13:56] <-- d has left this server (Read error: 110 (Connection timed out)). [13:56] <william> william -- scanning the bug list looking for something to do before I face #274 again. [13:56] <mabshoff> Looking at #201 [13:56] --> d has joined this channel (n=[email protected]). [13:56] <robert457965> agc - GraphicPrimitives don't have xmin xmax ymin ymax? [13:56] <mhansen> william: I'm looking at 337, but it seems to be fixed already. [13:57] <william> william -- ok, i'll look at #201 with mabshoff. [13:57] <robert457965> still working on 206 [13:58] <william> mhansen -- I'll close that one. [13:58] <mabshoff> I hope that valgrind will turn something up on valgrind. [13:58] <mabshoff> I also found another alloc/dealloc problem relevant to #274 [13:59] <dmharvey> i'm currently trying to understand the code flow for #274 [13:59] <agc> yeah ... the xmax, ymin, ... only are for the axes [13:59] <mabshoff> I could upload the logs to sage.math/mabshoff if you want to have a look curself. [13:59] <william> sure. [13:59] <-- dmharvey_ has left this server (Read error: 110 (Connection timed out)). [13:59] <robert457965> agc - now i see the subtlety [14:00] <robertwb> fixing the Py_ssize_t issue for keywords in cython [14:00] <robert457965> append doesn't add a graphics object to another, it adds a primitive to the graphics object's list [14:00] * pauloliviersage still working on #439 [14:00] <mabshoff> ==2660== 1,760,704 bytes in 20,008 blocks are still reachable in loss record 7,196 of 7,200 [14:00] <mabshoff> ==2660== at 0x4A05809: malloc (vg_replace_malloc.c:149) [14:00] <mabshoff> ==2660== by 0x4B1489: _PyObject_GC_Malloc (gcmodule.c:1321) [14:01] <mabshoff> ==2660== by 0x455D09: PyType_GenericAlloc (typeobject.c:454) [14:01] <mabshoff> ==2660== by 0xE1BF810: pyx_tp_new_7element_Element (element.c:17242) [14:01] <mabshoff> ==2660== by 0xE1BF940: pyx_tp_new_7element_ModuleElement (element.c:17417) [14:01] <mabshoff> ==2660== by 0xE1BF9C0: pyx_tp_new_7element_RingElement (element.c:17570) [14:01] <mabshoff> ==2660== by 0xFEDAC50: pyx_tp_new_3gen_gen (gen.c:26726) [14:01] <mabshoff> ==2660== by 0xFF041E9: pyx_f_3gennew_gen (gen.c:25823) [14:01] <mabshoff> ==2660== by 0xFF043FD: pyx_f_3gen_12PariInstance_new_gen (gen.c:21826) [14:01] <mabshoff> ==2660== by 0xFEFD4D2: pyx_f_3gen_3genmul_c_impl (gen.c:1527) [14:01] <mabshoff> ==2660== by 0xE1DEFAD: pyx_f_7element_11RingElementmul_c (element.c:8801) [14:01] <mabshoff> ==2660== by 0xE1CF814: pyx_f_7element_11RingElement_mul (element.c:8383) [14:01] <mabshoff> is the other interesting one. [14:02] <robert457965> william - can you roll back changeset 5784? [14:03] <mhansen> william: 316 works for me as well. [14:03] <mabshoff> http://sage.math.washington.edu/home/mabshoff/sage.2609 is the valgrind log of sage just starting and quitting [14:03] <mabshoff> (5.5MB!) [14:04] <mabshoff> http://sage.math.washington.edu/home/mabshoff/sage.2660 is the valgrind log with the last example from #274 (5.6MB!) [14:05] <william> robert457965 -- rollback complete. [14:05] <robert457965> sorry bout that [14:07] <agc> robert457965, so is #206 actually a bug? what do you think [14:07] <robert457965> agc - there's definitely something to do [14:07] <robert457965> i see three ways to go [14:07] <mabshoff> william - how do I enter the curve fom #201 directly into mwrank? [14:07] <robert457965> the original intent was for the user never to see primitives, right? [14:08] <robert457965> so theoretically every primitive should have a Graphics object for a wrapper, and those keep track of the xmin xmax ymin ymax sutff [14:08] <dmharvey> #274: aah. If I create a poly by a = K(1) or a = K.gen() and then repeatedly R([a], check=False), I don't get any leaks [14:08] <mabshoff> [14:09] <agc> yeah ... that sound right [14:09] <william> mabshoff: echo "[0,0,0,3,-15675]" | mwrank [14:09] <robert457965> the actual bug is the fact that you can create two primitives by hand, append them to a graphics object, plot, and see nothing [14:09] <mabshoff> ok [14:09] <william> dmharvey -- very very interesting! [14:09] <mabshoff> I am clueless about algebraic geometry. [14:10] <william> i spent a year doing almost nothing but exercises in algebraic geometry... (at Berkeley) [14:10] <robert457965> option 1 - be adamant about using factories, and do nothing ( i don't think this is a good idea ) [14:10] <william> but i still often feel clueless about it. [14:10] <robert457965> option 2 - give every primitive an xmax etc function to be called by append [14:10] <mabshoff> Found a bug in mwrank: [14:10] <mhansen> william: #316 works for me. [14:10] <mabshoff> Mismatched free() / delete / delete [] [14:11] <robert457965> option 3 - in append, somehow produce the graphics object instead of the primitive, then simply add them [14:11] <robert457965> what do you think? [14:11] <william> mhansen -- cool I'll try it. i'm glad it's fixed! [14:11] <william> mabshoff -- awesome. report it to john cremona (and put it in trac -- he uses our trac now and has an account) [14:12] <william> mhansen -- yep that can be closed. I'll add a doctest though. [14:13] <agc> ok ... im looking at the source ... trying to figure out whats best [14:13] <william> wait -- actually that is a doctest already. so #316 is done. [14:13] <robert457965> i'm in favor of option 2 [14:13] <mabshoff> I can probably make a patch and try to fix the problem. [14:14] <william> even better. [14:14] <mabshoff> It is pretty primitive - I have seen plenty of those before. [14:16] <-- d has left this server (Read error: 104 (Connection reset by peer)). [14:16] --> d has joined this channel (n=[email protected]). [14:20] <mhansen> william: 291 looks like it has been fixed [14:22] <william> mhansen -- it's not really fixed. [14:23] <william> The thing that caused that problem was generic. [14:23] <william> polys over QQ use libsingular now, so have custom printing, which doesn't have that problem. [14:23] <william> The GENERIC code still has the problem -- I give an example in the trac now. [14:23] <william> That said, the output isn't wrong, just not as pretty, so I changed it from bug to enhancement request. [14:23] <william> ok? [14:24] <william> hi. Please everybody look at http://www.sagemath.org:9002/sage_trac/roadmap [14:24] <william> I went through and linked every trac issue to this milestone. [14:24] <william> The top green bar gives our "current score". [14:24] <mhansen> william: sounds good [14:24] <william> You can also click on the little numbers below it to see the open and closed issues. [14:25] <william> e.g., this is what's left: [14:25] <william> http://www.sagemath.org:9002/sage_trac/query?status=new&status=assigned&status=reopened&milestone=sage-2.8.2 [14:25] --> yi has joined this channel (n=[email protected]). [14:25] <robert457965> yi - wassup!? [14:25] <yi> hey [14:25] <william> hey yi! [14:26] <yi> afternoon guys [14:26] <mabshoff> hello [14:26] <yi> robert457965: want to work on that dsage thing you were telling me about? [14:26] <william> yi -- there is an irc log here http://www.sagemath.org:9001/bug1/irc [14:26] <robert457965> definitely [14:26] <robert457965> i was hoping you would be on today [14:27] <yi> robert457965: what's the trac ticket again? [14:27] <robert457965> 431 [14:27] <robert457965> there's not much info there yet [14:28] <robert457965> agc - i think the best thing to do is implement an xmin(), xmax(), etc. function for each primitive, so that Graphic.append() can call that function no matter what [14:28] <robert457965> i'm going to start working on this dsage bug [14:28] <robert457965> yi- so when it was hanging before, i had the server and client on sage.math, and the workers on Tom's computer [14:29] <dmharvey> #274: If I remove the call to normalize() in Polynomial_generic_dense.init(), then the memory leak goes away. [14:29] <dmharvey> #274: must be getting very close now. [14:29] <yi> robert457965: ok cool, can we get the same set up? [14:29] <william> ok, i'm getting back to #274 then. that is getting exciting. [14:30] <dmharvey> [14:30] <william> hg_sage.pull() gets you up to date with us, I think. [14:30] <robert457965> everything is still up to date [14:30] <dmharvey> is Py_ssize_t a signed type? [14:30] <robert457965> that is, i left things where they were on each computer when it stopped [14:30] <william> yes. [14:31] <dmharvey> well that doesn't help does it!!! [14:31] <william> ? [14:31] <william> oh shit. [14:31] <william> (excuse language) [14:31] <yi> it's ok, it's IRC [14:31] <mabshoff> damn you [14:32] <yi> robert457965: i msg'ed you, we can talk there, less noise [14:32] <mabshoff> Yes, people seem to be capable of spelling words correctly and nobody speaks l33t [14:32] <yi> robert457965: if you're using irssi just do /query yi and it should open a new window [14:33] <william> dmharvey: confirmed that the memory leak goes away -- so its in normalize. [14:33] <mhansen> william: 393 is simply due to the rational 1/2 not being preparsed [14:34] <william> you're right -- that's just lack of understanding the unfortunate subtleties of sage vs python. [14:34] <william> could you make a remark and close the bug. [14:35] <mhansen> Will do. [14:35] <william> (*and* email jon hanke.) [14:36] <robert457965> yi - i'm waiting there [14:37] <yi> i messaged you, are you getting the messages? [14:38] <robert457965> i'm getting everything [14:38] <robert457965> here, other room, gmail chat [14:38] <robert457965> pick a venue [14:39] <william> ?? [14:39] <dmharvey> #274: I think it's in is_zero() [14:39] <william> #274: that's what I think too [14:41] <agc> robert457965, i starting to think that all we want append to to what add does? thoughts [14:41] <robert457965> the problem with that is that a graphics primitive doesn't have xmin [14:42] <robert457965> that's ultimately what we want, but we need the primitive to be able to report its xmin etc [14:42] <william> #274 -- dmharvey: [14:42] <william> n = pari('x') [14:42] <william> s = get_memory_usage() [14:42] <william> for i in range(10^5): [14:42] <william> _ = n.is_zero() [14:42] <william> print get_memory_usage() - s [14:42] <william> 4.55859375 [14:42] <dmharvey> [14:42] <william> but with n = pari(1) that doesn't happen. [14:43] <agc> i guess that is the thing, you never 'show' or 'save' a primitive, so the xmin, etc shouldn't come into to play? [14:43] <dmharvey> well the implementation of is_zero for the finite field element seems to be "return not x" [14:43] <agc> i could be off my rocker though [14:43] <dmharvey> which is calling nonzero() [14:43] <william> [14:43] <dmharvey> and that seems to leak too [14:43] <william> let's focus on pari -- that's the core of the problem. [14:43] <william> there's an stoi in there that looks dangerous. [14:44] <william> line 897 of sage/libs/pari/gen.pyx [14:44] <mabshoff> Re mwrank with [0,0,0,3,-15675]: [14:44] <mabshoff> found points of rank 2 [14:44] <mabshoff> and regulator 16.9955132982626 [14:44] <mabshoff> Processing points found during 2-descent...done: [14:44] <mabshoff> now regulator = 16.9955132982626 [14:44] <mabshoff> Saturating (bound = 100)...RR: division by zero [14:44] <william> yep bool(n) leaks memory for n in pari. [14:45] <william> mabshoff -- did you see that cremona attached two files that are supposed to fix the error in that example? [14:45] <william> it's near the bottom. [14:45] <mabshoff> So I get little further, but there are issues qsieve::search() [14:45] <mabshoff> Nope, not yet. [14:45] <mabshoff> I will have a look. [14:45] <william> ut oh. [14:45] <william> let me forward you an email from him. [14:45] <dmharvey> #274: what is stoi()? [14:46] <william> time for mabshoff to laugh at us (=me). [14:46] <mhansen> dmharvey: usually string to integer [14:46] <william> mabshoff -- i just emailed cremona's email to you -- it has a fix I think for that mwrank bug, maybe. [14:46] <william> yep. [14:46] <mabshoff> Ok, there is a new options.h and a realroot.cc [14:47] <mabshoff> I will check, there was a problem in vec.cc [14:47] <dmharvey> #274: well this expression "bool(self.g != stoi(0))" makes absolutely no sense to me [14:47] <william> yep. [14:47] <dmharvey> it makes a negative amount of sense [14:47] <dmharvey> an imaginary amount [14:47] <mabshoff> Ok, but the code still needs the fixes for the leaks in vec.cc. [14:47] <william> i can't imagine what idiot could have written that (me) [14:47] <dmharvey> [14:47] --> pdenapo has joined this channel (n=[email protected]). [14:48] <dmharvey> well, I guess that's where the bug is, but I don't know how to fix it, since I don't know much about PARI programming [14:48] <william> self.g is a PARI Gen object. [14:49] <william> stoi(0) is god only knows. [14:49] <dmharvey> and C doesn't have any operator overloading, so I don't see how comparing self.g to anything makes sense [14:49] <william> we should probably look in the pari source code or something. [14:49] <william> or the library reference manual. [14:49] <dmharvey> I actually better get going, but if you like I can note down these findings on the trac page? [14:49] <william> or just have bool compare to 0. [14:49] <william> which makes sense, right? [14:50] <william> pari has gcmp [14:50] <dmharvey> yeah it has to be a function call somehow [14:50] <dmharvey> this should also be made very fast [14:50] <dmharvey> if possible [14:51] <william> the function names are in decl.pxi [14:52] <william> gcmp0 looks good [14:53] <agc> robert457965, actually maybe append shouldn't exist, what is the benefit why the add method does everthing you would want when combining graphics ... the primitives are lower level and probably should be private [14:53] <dmharvey> william: I bet you were trying to compare the string representation of the PARI object to "0", and it must have been very very late at night [14:54] <dmharvey> #274: I've noted down progress on the #274 trac page [14:54] <dmharvey> but I really should call it a day [14:54] <william> weirdness. using gcmp0 still leaks. [14:54] <william> ok -- thanks for all your help dmharvey. cu [14:54] <agc> yi and robert457965 are you guys off talking about twisted somewhere??? i want in 
[14:54] <dmharvey> ok bye [14:54] <-- dmharvey has left this channel. [14:55] <-- d has left this server (Read error: 104 (Connection reset by peer)). [14:55] --> d has joined this channel (n=[email protected]). [14:56] <yi> agc: hey man [14:56] <agc> yi: yo [14:56] <robert457965> agc - you'll have to rewrite each of the Factory functions [14:57] <yi> agc: we're not doing anything twisted related right now, just dsage debugging [14:57] <mabshoff> Ok, mwrank no longer crashes with the example from #201 [14:57] <agc> ok, im a twisted nerd ... its the bestest [14:58] <mabshoff> That is with the fixes in trac, plus a patch by me that fixes some delete vs. delete[] issues. [14:58] <mabshoff> There is still work to be done: [14:58] <mabshoff> ==7030== LEAK SUMMARY: [14:58] <mabshoff> ==7030== definitely lost: 4,536 bytes in 162 blocks. [14:58] <mabshoff> ==7030== possibly lost: 192 bytes in 3 blocks. [14:58] <mabshoff> ==7030== still reachable: 119,257 bytes in 195 blocks. [14:58] <mabshoff> ==7030== suppressed: 0 bytes in 0 blocks. [14:58] <mabshoff> ==7030== Use --leak-check=full to see details of leaked memory. [15:01] <william> hi -- #274 -- regarding my stupid stoi thing in bool; it wasn't [15:01] <william> the problem, since Python doesn't even have a bool -- that code [15:01] <william> never got run. [15:01] <william> Python has nonzero instead. [15:01] <mabshoff> [15:01] <mhansen> william: I sent a bundle for #392. [15:05] <william> mhansen -- got it. [15:08] <mabshoff> william - I am making an updated mwrank.spkg so that we can close 201. [15:08] <william> nice. thanks!! [15:09] <william> mhansen -- looking at your patch [15:09] <mhansen> william: the only thing I was iffy about was the ndigits thing. [15:10] <agc> i just realized the root of the problem, each Graphics type changes the axes in different ways ... so to keep plots looking nice we ajust the axes on a case by case basis [15:14] <william> mhansen - what if the object has a round method that could take ndigits? [15:14] <mhansen> william: I didn't see any objects with methods like that. [15:14] <william> no but your new code won't even call it. [15:15] <william> by the way, if a is a real_mpfr element then a.round says it rounds "to the nearest real". [15:15] <robert457965> agc - what should be done as a solution? [15:15] <robert457965> i'm wondering why david h was appending graphic primitives in the first place [15:15] <william> mhansen -- then there are four examples that have nothing to do with the round method! [15:17] <agc> the add method does everything one would want ... maybe lets just remove the append method ... [15:18] <william> mhansen -- ok, overall i'm ok with the new round. [15:18] <william> i'm going to fix the docs in the round mpfr method though. [15:18] <mhansen> Sounds good. [15:19] <william> actually, could you fix the example in real_mpfry.py? [15:20] <william> in each, give an actual rounding example calling round. [15:20] <robert457965> agc - since it only does one thing anyway... [15:20] <william> mhansen -- do hg_sage.pull() first. [15:20] <mabshoff> I build a new mwrank.spkg - see http://sage.math.washington.edu/home/mabshoff/mwrank-20070818.spkg [15:20] <mabshoff> This fixes #201 for me. [15:20] <mhansen> william: sure [15:20] <william> thanks! I want to integrate some more patches and get back to that memory leak. [15:21] <william> mabshoff -- i'm trying it now. [15:21] <mabshoff> I did put in John's fixes plus the deleted patch I wrote. [15:21] <mabshoff> I put my patch in trac, too, and I will write an Email to John. [15:21] <william> make sure you send him the deleted patch you wrote. he'll greatly appreciate it. [15:21] <william> thanks. [15:22] <mabshoff> The following is the changelog: [15:22] <mabshoff> *20070818: [15:22] <mabshoff> * added corrected options.h and realroots.cc by (John Cremona) [15:22] <mabshoff> * corrected delete operators in vec.cc (by Michael Abshoff) [15:23] <william> mhansen -- i made that documentation thing you're doing now http://www.sagemath.org:9002/sage_trac/ticket/447 [15:23] <mabshoff> There might be some timestamp problem as usual, I should really set the correct time on that box. [15:24] <william> from pari-dev just now for a new cvs release: " [15:24] <william> The memory model was preserved so we essentially get the same set of [15:24] <william> bugs as with GP 2.3. [15:24] <william> " [15:26] <william> yep, #201 is closed! [15:26] <mabshoff> boojjay [15:27] <mabshoff> 16 closed, 22 tickets to go. [15:27] <mabshoff> Mmmh. What should I do next. [15:27] <mabshoff> ? [15:28] <william> do the other 22 [15:28] --> alfredo has joined this channel (n=[email protected]). [15:29] <-- alfredo has left this server (Client Quit). [15:30] <mabshoff> Maybe, I will have a look which one is to my linking and expertise. [15:31] <william> exactly. [15:31] <mabshoff> Next time you talk why Sage is better than the closed competition post some part of the log demonstrating collaboration from people all over the place. [15:32] <william> [15:32] <william> it's really neat. [15:32] <william> by the way, agc -- alex -- do you have dinner plans? [15:32] <mabshoff> Yeah, this is even more fun than just with 2 or 3 people. [15:33] <agc> no [15:33] <agc> any ideas? [15:33] <william> want to meet for dinner in 3 or 4 hours? [15:33] <william> say 7pm -- wired cafe? [15:34] <agc> sure, where is the wired cafe? [15:34] <william> renaissance shopping center. [15:34] <william> near walgreen's, a japanese rest, etc., [15:34] <agc> is that by UTC? [15:35] <william> yes. [15:35] <william> down the hill. [15:35] <william> http://outside.in/places/wired-cafe-le-bistro-san-diego [15:36] <agc> ok, yeah [15:39] <pdenapo> exiexit [15:39] <-- pdenapo has left this server ("Leaving"). [15:39] <agc> so william, robert457965 can we just remove the append method, or make it do exactly what add does for ticket#206? [15:39] <william> I like making it do exactly what add does. [15:40] <robert457965> second option doesn't work, since each primitive has it's own way of doing stuff [15:40] <robert457965> rather, in order to do that, each primitive needs an xmin() function [15:40] <william> mmaybe each primitive should have an xmin function? [15:40] <william> with some sort of default. [15:41] <william> (in the base class). [15:41] <robert457965> -1, 1, -1, 1? [15:41] <william> basically for the primitives defined by a collection of points (which is a lot of them), this [15:41] <william> is easy. [15:41] <william> for others, e.g., a circle, maybe you have to do a little math. [15:41] <robert457965> networkx primitives have _xmin [15:41] <robert457965> arrow primitives have them too for some reason [15:41] <william> but a default of -1 might be ok in the base class. [15:41] <william> for text xmin could be hard.. [15:44] <robert457965> how does the graphics object for a text primitive get xmin and xmax? [15:46] <agc> it take the (x, y) position of the text and then gets added some padding [15:48] <-- d has left this server (Read error: 104 (Connection reset by peer)). [16:04] <mhansen> william: sent a bundle for #447 [16:05] <william> thanks. I'll try it momentaril. [16:05] <mabshoff> I just looked at #160 [16:06] <william> i'm hard at work on #303. [16:06] <william> I know how to fix it now... [16:06] <william> (i mean #304) [16:06] <mabshoff> 303 or 160? [16:06] <mabshoff> sage: n = 15 [16:06] <mabshoff> > sage: time P = partitions_set(range(n),3) [16:06] <william> 160 -- that looks venerable. [16:06] <mabshoff> Well, the problem is that the result seems to be huge. [16:06] <mabshoff> gap uses ~800 mb, [16:06] <william> yep. [16:07] <mabshoff> sage killed itself around 4.5GB because Swap ran out. [16:07] <william> we should add a protocol to the gap interface so we can get the value [16:07] <william> of a variable back out via a file. [16:07] <william> that would be a fix. [16:07] <william> so, e.g., if a = gap('2^10000'), then one should have the option to do: [16:07] <william> b = a.str_via_file() [16:08] <william> it would then do gap.eval('commadn to write a.name() to file') [16:08] <mhansen> I have new set partitions code that doesn't use GAP. [16:08] <william> read the file [16:08] <william> mhansen -- but of course mhansen's new package would kick the but of that ... [16:08] <william> [16:08] <mabshoff> The box I ran the code on has been swapping back in for a while now. [16:08] <william> maybe you shoudl submit that code all as a bugfix for #160. [16:09] <william> [16:10] <mabshoff> But there might be a leak in there somewhere: [16:10] <mabshoff> Virtual memory is 4191m while residential is 878m [16:11] <mabshoff> That is in the Sage part of the computation. [16:12] <william> very interesting. [16:16] <william> mhansen -- nice docs for round! [16:17] <robert457965> is anyone else having problems looking at the active tickets? [16:17] <william> wait -- mhansen -- why do you define R? [16:17] <mabshoff> Hehe, the box came back with a loadd of 30 [16:17] <mabshoff> I won't to that on production systems again . [16:18] <william> mhansend -- i deleted a spurious " cdef RealField R = self.parent()" [16:19] <mhansen> Oops -- sorry about that. That was from when I was thinking about it using the parent's rounding mode. [16:21] <-- yi has left this server (Read error: 110 (Connection timed out)). [16:21] <william> ok, i've applied your patch, modified it some and pushed it out. and updated trac. [16:22] <william> robertwb -- are you around? [16:22] <robertwb> yeah [16:22] <william> If so, could you just decide this cython-related issue is not worth our trouble? [16:22] <william> http://www.sagemath.org:9002/sage_trac/ticket/227 [16:23] <william> i want to mark it off the list, but you're the cython man. [16:23] <william> what do you think? [16:24] <william> mabshoff -- are you still looking at #160? [16:25] <william> if so, if you can figure out how to write a variable to a file in gap, I could probably write some [16:25] <william> code to do what I suggested above. [16:25] <robertwb> I think using NULL rather than 0 in the code shouldn't be too hard [16:25] <william> should we do it though? [16:25] <robertwb> but it certainly isn't a "major" bug [16:25] <robertwb> I think so [16:25] <william> i'll change it to an enhancement. [16:25] <robertwb> ok [16:25] <mabshoff> I am just surprised that sage eats a mutliple of the memory gap uses. [16:26] <mabshoff> Probably because of string vs. binary representation of the result. [16:26] <william> the comm between sage and gap is via a pseudo-tty. so there's lots of text, buffers, etc. [16:26] <mabshoff> It is still telling that there is a big difference between vir and res memory. [16:27] <mabshoff> I will ran 2.8.1 on another box with 24 GB and with smaller input n=5 for starters and see what happens. [16:27] <william> i added #160 to the list for today [16:27] <mabshoff> Oh no, more pressure. [16:27] <mabshoff> I just went though the open tickets and looked at everything with segfault. [16:28] <mabshoff> #402 might also be interestig. [16:28] <mabshoff> +n [16:28] <mhansen> Regarding the set partitions code, it depends on a bunch of other combinatorics code. All the new combinatorics stuff uses a new interface based on "combinatorial classes". It's based on MuPAD-combinat's notion of combinatorial classes. It makes it easy to do things like define algebras whose basis elements are indexed by elements of a combinatorial class. [16:29] <william> #402 works fine now. [16:29] <william> we used to include dvipng in SAGe, I think, and maybe it was broken. [16:29] <william> (for me at least) [16:29] <william> mhansen -- cool; when do you plan to make this part of SAGE? [16:30] <mabshoff> Yep, dvipng is the systems, so that might have been a fluke with an outdated/broken local copy. [16:30] <mabshoff> Should be close it then? [16:30] <william> yep. [16:30] <mabshoff> #402 that is. [16:30] <mabshoff> will do [16:30] <william> but let me attach it today's [16:31] <mabshoff> Ok, you can do it all then. [16:31] <mabshoff> a good bug triage cuts down on the number of bugs to fix [16:31] <william> first notebook bug crossed off. [16:32] <william> there sure are a lot listed there! [16:32] <william> #293 looks scare. [16:32] <mhansen> Probably in the next major release. The last major bit to do is asymptotically fast generation of derangements. It has a ton of the stuff that Sara Billey mention in her talk. For example, it includes a symmetric functions package which passes all of MAGMA's tests and more. It also has Schubert polynomials. [16:32] <mabshoff> Does Axiom depend on gcl or does it also work woth clisp? [16:32] <william> axiom works with clisp. [16:32] <william> it is easy to install. [16:32] <mabshoff> Because: [16:32] <mabshoff> Ticket #420 (new defect) [16:32] <mabshoff> Opened 1 week ago [16:32] <mabshoff> Last modified 6 days ago [16:32] <mabshoff> SAGE's optional axiom package doesn't build on os x [16:33] <william> close that. [16:33] <mabshoff> Ok [16:33] <william> I fixed that myself on the plane ride to San Diego! [16:33] <mabshoff> ok [16:33] <william> ok, i'm closing it. [16:33] <mabshoff> have fun. [16:34] <william> just out of curiosity can you reproduce #423? [16:34] <william> i just did [16:34] <mabshoff> I think that clisp alone is enough of a pain in the ass. [16:34] <william> requiring gcl... gees. [16:34] <mabshoff> Especially compated to gcl. [16:35] <william> axiom on gcl is faster. [16:35] <mabshoff> Ok. [16:35] <william> but i have the impression it's all rather slow compared to good c code. [16:35] <william> just type in SAGE: [16:35] <william> help() [16:35] <william> modules [16:35] <mabshoff> waiting on output. [16:36] <mabshoff> Some idiot on that box swapped out most of the current processes [16:36] <william> you. [16:36] <mabshoff> it goes boom. [16:36] <mabshoff> yes. [16:36] <william> --> 150 la = linear_algebra [16:37] <william> ajc and robert -- how's the graphics going? [16:37] <mabshoff> /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/python2.5/site-packages/matplotlib/numerix/init.py in <module>() [16:37] <mabshoff> 147 import('random_array', g, l) [16:37] <mabshoff> 148 import('mlab', g, l) [16:37] <mabshoff> 149 [16:37] <mabshoff> --> 150 la = linear_algebra [16:37] <mabshoff> 151 ra = random_array [16:37] <mabshoff> ok [16:37] <mabshoff> Isn't that in matplotlib? [16:37] <william> yep. but "comment it out" and other things break in other places. [16:37] <william> I think the right thing to do this time is patch python itself so it's module lister [16:37] <william> is more robust. [16:38] <william> if you go up the tree to the first thing that is in python2.5 itself, in pkgutil.py it [16:38] <william> doesn't catch enough exceptions. [16:38] <mabshoff> ok [16:41] <william> yep. [16:41] <william> if you edit sage-2.8.1/local/lib/python2.5/pkgutil.py [16:42] <william> and comment out lines 117 and 118 ("else: raise") does help() and modules work for you???? [16:42] <mabshoff> second [16:42] <william> this bug has been reported on the list about 5 or 6 times now. [16:42] <robert457965> william - I'm working on dsage with yi at the moment [16:42] <william> cool. [16:43] <robert457965> agc - still around? [16:43] <william> wow, that help() system is really really nice. [16:43] <agc> yeah [16:43] <william> i've never used it since it is always broken. [16:43] <robert457965> how's graphics? [16:43] <william> we need to "port" help() to the notebook... [16:44] <mabshoff> Yeah, with those two lines commented out it works for me. [16:44] <william> thanks. [16:44] <william> i'm going to patch python*.spkg and close that bug. [16:44] <mabshoff> one more down. [16:45] <mabshoff> have you looked at #172 - that is rather old and might be fixed by now. [16:46] <agc> im not sure about the append method ... it has to do with the axes (i.e. good-looking-ness) and i think it needs to be handle on a case by case basis like add does. [16:47] <robert457965> i agree [16:47] <robert457965> if each primitive has an xmin() function, then append can work just like add [16:47] <robert457965> something like self.xmin = min(self.xmin, primitive.xmin()) [16:48] <robert457965> right now, every time the append method gets called, it's by a factory, which then sets the xmin xmax itself, right? [16:50] <agc> no, its just a method of Graphics ... it kinda just doesn't make sense to have it ... [16:51] <mabshoff> #352 is no longer a problem, [16:51] <mabshoff> I just tested it and it works, so I closed it. [16:52] <agc> i say just remove it. [16:52] <william> i just assigned it to sage-2.8.2, so we "get credit". [16:52] <william> agc -- fine with me. [16:52] <mabshoff> Hehe [16:54] <agc> if you are making plots, then you a least want them to look semi-pretty, and appending a bunch of graphic primitives together will not produce anything visually decent. [16:54] <robert457965> go for it [17:06] [CTCP] Received Version request from freenode-connect. [17:06] [Notice] -NickServ- This nickname is owned by someone else [17:06] [Notice] -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password> [17:06] --> You have joined the channel #sage-devel (n=[email protected]). [17:07] *** Channel modes: secret, no messages from outside [17:07] *** This channel was created on 08/17/2007 01:03:33 PM. [17:07] --> mabshoff_ has joined this channel (n=[email protected]). [17:07] <robert457965> right, but not the primitive underneath it [17:07] <robert457965> c is a Graphics object, not a primitive [17:07] <agc> that is, when you do show(c), it look pretty good, but you can always fine tune the axes in the show command [17:08] <robert457965> you're missing my point [17:08] <robert457965> people want to use primitives outside of plot.py [17:08] <robert457965> the reason 206 is a ticket is exactly that [17:08] <agc> my point is that at the end of the day, the only reason you can about min and max values is so the plot looks decent [17:09] <robert457965> right [17:09] <robert457965> if i make a primitive and a graphics object, and append the primitive to the graphics object, it looks like crap [17:09] <robert457965> all we need to fix that is for the primitive to know its own size [17:13] <agc> they do, behind the scenes the primitives know their size because of the call method requires parameters for each Graphic type [17:14] <robert457965> you mean because the Factories create a Graphics object that is only a Primitive and xmin, xmax etc, right>? [17:15] <robert457965> so why aren't the latter simply part of the primitive? [17:15] <mabshoff_> william - are you at dinner or still around? [17:15] <william> i'm around for at least another 1.5 hours. [17:15] <william> i'm working on the modular forms bug. [17:15] <william> i know what to do but have to write some code. [17:15] <william> how's it going? [17:15] <mhansen> Regarding 160, there are 2375101 set partitions so they'll take a fair amount of time / memory to generate. [17:16] <mabshoff_> I am looking at #160 [17:16] <mabshoff_> sage: n=5 [17:16] <mabshoff_> sage: time P=partitions_set(range(n),2) [17:16] <agc> "behind the scenes" (so to speak) we have: class CircleFactory(GraphicPrimitiveFactory_circle) [17:16] <mabshoff_> End Of File (EOF) in read_nonblocking(). Exception style platform. [17:16] <mabshoff_> <pexpect.spawn instance at 0x243d7518> [17:16] <mabshoff_> version: 2.0 (Revision: 1.151 ) [17:16] <mabshoff_> command: /tmp/Work2/sage-2.8.1/sage-2.8.1/local/bin/gap [17:16] <mabshoff_> args: ['/tmp/Work2/sage-2.8.1/sage-2.8.1/local/bin/gap', '-b', '-p', '-T', '-o', '9999G', '/tmp/Work2/sage-2.8.1/sage-2.8.1/data//extcode/gap/sage.g'] [17:16] <agc> and then we have the "public function": circle = CircleFactory() [17:16] <mabshoff_> patterns: [17:16] <mabshoff_> gap> [17:16] <mabshoff_> buffer (last 100 chars): [17:16] <mabshoff_> before (last 100 chars): @p1.gap: cannot extend the workspace any more [17:16] <mabshoff_> So even for very small partition_sets things go haywire. [17:17] <mabshoff_> It all ends with [17:17] <mabshoff_> /tmp/Work2/sage-2.8.1/sage-2.8.1/local/lib/python2.5/site-packages/sage/interfaces/gap.py in _start(self) [17:17] <mabshoff_> 246 self._session_number = n [17:17] <mabshoff_> 247 return [17:17] <mabshoff_> --> 248 raise RuntimeError, msg [17:17] <mabshoff_> 249 [17:17] <mabshoff_> 250 if self.use_workspace_cache and self.make_workspace: [17:17] <mabshoff_> <type 'exceptions.RuntimeError'>: Unable to start gap [17:17] <robert457965> agc - i get how it works, i just don't understand why we need like six classes to do three things [17:18] <robert457965> if you make an arrow, there's two separate classes just for the function that returns the Graphics object [17:19] <agc> you are right there! we definitely could minimize the code, it we be more readable for sure [17:19] <robert457965> hmm [17:19] <robert457965> i mean, ultimately, how should it be set up? [17:21] <robert457965> each primitive has a function that tells matplotlib how to draw the primitive, right? [17:23] <agc> notice how every GraphicPrimitiveFactor_* only has a call method ... with end up using a method the eventually inherits from it ... it is pretty akward but it the beginning, we the code was first written we were going for maximum generality [17:24] <agc> god it make a lot of typing mistakes ... sorry [17:24] <agc> geez, i meant I not it ... ahhh!!!! [17:25] <-- mabshoff has left this server (Read error: 110 (Connection timed out)). [17:26] <robert457965> so maybe plot.py just needs a major makeover? [17:27] <robert457965> anyway, all i'm saying about that particular ticket is this- [17:27] <robert457965> a primitive contains instructions on how to draw itself on a figure [17:27] *** mabshoff_ is now known as mabshoff. [17:28] <agc> a makeover would be nice ... but its not that bad [17:28] <robert457965> doesn't it also make sense for it to know what the bounds of that are? [17:30] <robert457965> it's an impressive piece of work, for sure [17:34] <william> i remember when agc and i came up with the design. [17:34] <mhansen> william: I have some changes to make sure that things such as unions, intersections, etc. of Set_object_enumerated return hashable objects. Do you want it now? [17:34] <william> i always knew a conversation like we're having now would happen. [17:35] <robert457965> we've had this conversation before, too [17:35] <william> no. but you can make a trac ticket that explains the issues, and then I might want it now. [17:36] <agc> the 'public' functions inherently know their bounds by how they are used (e.g. circle((2, 2), 1) ), and bounds are really just for the end result hard-copy plot. It you want several different Graphics in one hard-copy, then add all the seperate graphic together and the code will do its best to make it look nice. I can't think of much more to say. [17:36] <robert457965> all a primitive is, is a patch of a bigger plot. that patch has a range, and a set of instructions on how to draw it. [17:37] <robert457965> the way things are written, every time you see a primitive it is inside a bigger Graphics object [17:37] <robert457965> it *makes more sense* to factor that information down to the primitive [17:37] <robert457965> that way, there is less complication, less confusion, less bugs to trac [17:38] <robert457965> anyway, i'm signing off for the day [17:38] <robert457965> RDF poly's now factor, but badly [17:38] <mabshoff> cu [17:38] <robert457965> i'll look into finding roots via GSL soon [17:38] <agc> my 'Mathematica' does work in that direction ... I kind of just followed how Mathematica does its plotting [17:38] <robert457965> yi knows of the bug i've found in dsage, and we'll work on it more, but it won't get fixed today [17:39] <william> is it a trac ticket? [17:39] <william> if not, why not? [17:39] <william> yi convinced me that anything we work on should be a track ticket. [17:39] <robert457965> #431 [17:39] <mabshoff> I agree, that way it is just very easy to keep track of things. [17:40] <robert457965> anyway, see you all at sage days X [17:40] <william> and progress is easier. [17:40] <-- robert457965 has left this channel. [17:40] <william> easier to measure. [17:40] <agc> see you robert457965 [17:40] <william> cu [17:40] <mabshoff> re #160: time P = partitions_set(range(13),3) already consumes more than 4GB on the side of sage. [17:40] <mabshoff> GAP doesn't leak memory (only 1kb) [17:41] <mabshoff> But it seems that the parser on the sage side just goes insane with memory consumption. [17:43] <mabshoff> wiliam, #433 can be closed, too. The patch has been applied by you. [17:43] <-- pauloliviersage has left this server ("CGI:IRC (Ping timeout)"). [17:44] <william> done. [17:44] <william> we're at 50% now [17:45] <mabshoff> Mmmh, roughly 7 hours in, [17:45] <mabshoff> not too shabby. [17:45] <robertwb> btw, I finished fixing cython [17:45] <robertwb> (the index thing) [17:45] <agc> william, here is the patch for #206 [17:45] <agc> http://sage.math.washington.edu/home/agc/remove_append_from_Graphics_class.hg [17:46] <william> got it. [17:53] <william> mabshoff -- is it just python evaling something big, or is it the pexpect interface? [17:53] <william> again, making a file-based transfer back easy to use might be fine if the problem is pexect [17:53] <mabshoff> I can't tell. [17:53] <william> instead of eval. [17:53] <mabshoff> Gap returns one very long list of lists. [17:53] <william> if use figure out how to write the output from gap to a file, you could load it into python and eval it. [17:53] <william> eval(open('foo').read()) in python. [17:53] <mabshoff> Okay. [17:54] <mabshoff> For some cython experts out there: #172 might be low hanging fruit. [17:54] <william> it's hard i think. [17:55] <mabshoff> And for people who know RR and corecsion: #429 might be interesting. [17:55] <mabshoff> I did cython the example, but I am not sure how it looked before. [17:55] <william> #172 -- but everything i think is really hard with cython, robertwb just does. [17:56] <william> #429 is *definitely* easy to fix. i'm sure of that. [17:56] --> pauloliviersage has joined this channel (i=8143024e@gateway/web/cgi-irc/ircatwork.com/x-bdd571a346a18dc4). [17:56] <william> RR matrices are generic whereas GF(127) isn't, so the problem probably has nothing to do with RR [17:56] <mabshoff> Ok, we just cannot convert "none" at the moment? [17:56] <william> i added #429 to the list for today. [17:57] <william> (on trac) [17:58] <mabshoff> Gap to file: [17:58] <mabshoff> The simplest, but less flexible is to use 'LogTo("filename");' [17:58] <mabshoff> and it will just copy the output from the screen to the file. [17:58] <mabshoff> In this case you may use the command 'SizeScreen([256,]);' to [17:58] <mabshoff> reach the maximum possible length of the line, but no more than 256 [17:58] <mabshoff> symbols. [17:58] <william> i just finally fixed #304, which was really a very bad bug. [17:58] <william> that's useless. [17:58] <mabshoff> We only want to write the list? [17:58] <william> we don't want the output to *ever* go to the screen. [17:58] <william> We want straight to the file. [17:58] <william> Maybe there is a command like "Write". [17:58] <william> Yes, we only want to write the list. [17:59] <william> We change the partitions thhing so it saves the answer in a gap temp variable, [17:59] <william> we then write that variable to a file. [17:59] <william> then from python we read the file. [17:59] <william> then we clear the temp variable. [17:59] <mabshoff> you may enter the next command from this example in the [17:59] <mabshoff> form [17:59] <mabshoff> output := OutputTextFile( "filename", true );; [17:59] <mabshoff> and it will create the file "filename" just in your current directory. [18:00] <mabshoff> Or is that the same conundrum re output [18:00] <mabshoff> ? [18:00] <william> PrintTo [18:01] <william> Type "gap.WriteLine?" in SAGE and look at what is there. [18:01] <william> I think PrintTo looks useful. [18:01] <mabshoff> Yeah, there is a tutorial for PrintTo [18:02] <william> agc -- i applied your patch. it works [18:02] <mabshoff> PrintTo( <filename>, <obj>); [18:02] <mabshoff> Seems kind of obvious. [18:04] <mabshoff> So the code for partition_set is "just": [18:04] <mabshoff> if k==None: [18:04] <mabshoff> ans=gap.eval("PartitionsSet(%s)") [18:04] <mabshoff> else: [18:04] <mabshoff> ans=gap.eval("PartitionsSet(%s,%s)"%(S,k)) [18:04] <mabshoff> return eval(ans) [18:05] <william> yes. [18:05] <william> note that the right place to put the PrintTo code is [18:05] <william> in sage/interfaces/gap.py [18:05] <william> since there will be lots of times it is needed in sage. [18:05] <mabshoff> So instead of eval(ans) we write PrintTo(tempfile,"PartitionsSet(%s)"); [18:06] <william> my fix for #304 automatically fixed #303 [18:06] <william> yep. [18:06] <william> but make it something like [18:06] <mabshoff> and we eval(open(tempfile).read()) [18:06] <william> yeah. [18:06] <william> precisely, we should do: [18:06] <william> a = gap('PartitionsSet(%s)') [18:07] <william> so now we have a gap temp variable named a.name(). [18:07] <mabshoff> ok [18:07] <william> Then do something like say a.str(use_file = True) [18:07] <william> ans = a.str(use_file=True) [18:08] <william> When a goes out of scope, the corr. gap data structure should be automatically garbage collected. [18:08] <mabshoff> hmm, I will have a look. [18:08] <william> So all you have to do is change the two gap.eval lines slightly (just delete the .eval part) [18:08] <william> and modify the str method in gap.py (or just add a method of your choosing) [18:09] <william> Then *that* method will have to get a temp file, and do [18:09] <william> gap.eval('PrintTo(tmpfilename, obj)') [18:09] <william> read the temp file. [18:09] <william> delete the temp file. [18:09] <william> ok? [18:09] <mabshoff> Sounds reasonable. [18:09] <mabshoff> I will give it a try, it is time for me to play with the Sage code itself. [18:09] <mabshoff> Learning by doind. [18:10] <mabshoff> -d+g [18:10] --> ncalexan has joined this channel (n=[email protected]). [18:10] <william> actually, if you can do what I wrote above, it will be very useful, because you'll have to understand how [18:11] <william> sage interface work. [18:11] <william> (under the hood). [18:11] <mabshoff> ok [18:11] <william> then you can think of a way to do it all better [18:11] <mabshoff> [18:14] <william> wow, i fixed #429 in 1 minute. [18:14] <mabshoff> cudos. [18:14] <william> it's just that low lieing fruit with sparse matrices you mentioned. [18:14] <mabshoff> I remember. [18:15] <mabshoff> If one is familiar with the code that kind of fix ought to be trivial. I am just not there yet. [18:15] <ncalexan> Could someone check 340? It's fine for me, fine in the notebook, etc, so I'm going to close it unless someone can make it break again. [18:17] *** ncalexan is now known as ncalexan-dinner. [18:17] <mabshoff> ode_solver? should just show you the help or what exactly is the issue? [18:17] <mabshoff> It works for me then. [18:17] <ncalexan-dinner> It wasn't showing the help. It does now, I'm going to close it. [18:17] <mabshoff> ok [18:18] <william> it works fine for me. close it. [18:18] <ncalexan-dinner> 340: closed. [18:18] <william> i think josh actually submited a patch to fix that a long time ago which i applied. [18:18] <william> wow, we're doing well. [18:19] <ncalexan-dinner> Oh, great. Anyway, I'll try to contribute a bit later, dinner with the parents. I wish I could have been a part of this *super cool idea*. [18:20] <william> probably i'll be off to dinner for a while in about 45 minutes, depending on what agc thinks. [18:20] <william> but i'll be back in a couple hours. [18:20] <mabshoff> ok [18:20] <william> indeed this bug squash idea of malb's was *excellent*. [18:20] <william> SAGE has really improved substantially today. [18:20] <mabshoff> I will probably be around for 3 or 4 more hours. [18:20] <william> ok. [18:20] <william> i'm working on ticket #292. [18:21] <mabshoff> But I will take a break for half an hours, too. [18:21] <william> the bug has nothing to do with all the complicated coerce looking stuff. [18:21] <agc> alright, it met you at wired cafe william [18:21] <mabshoff> Any chance for a #274 revisit? [18:21] <william> it's just the list method on polynomial quotient elements gives an infinite list. [18:21] <william> i really want #274 to be revisited too. [18:21] <william> agc -- how hungry are you? [18:21] <mabshoff> ok [18:21] <william> i'm ok working for another hour... [18:21] *** mabshoff is now known as mabshoff|on_a_br. [18:21] <william> it's still light out for a while. [18:22] *** mabshoff|on_a_br is now known as mabshoff|resting. [18:22] <william> agc? [18:22] <agc> sure [18:22] <william> ok. [18:22] <william> cool. [18:23] <agc> see you there in ~30 minutes [18:23] <william> actually i ws just saying *not* 30 minutes but longer. what do you think? [18:23] <william> i.e., not meet until 7:30. [18:24] <agc> thats fine too, im not busy [18:24] <william> cool. [18:24] <william> what are you working on now? [18:24] <william> i'm trying to remember why list(f) works when f is a polynomial... [18:24] <agc> actually just looking at the new stuff that has been putting in sage [18:24] <william> ah iter [18:24] <william> cool. [18:24] <william> i can't keep up with it all. [18:25] <william> agc -- check out cvxopt; it's pretty cool [18:25] <william> it's your kind of thing, probably. [18:27] <william> ok, trac #292 is fixed. [18:28] <william> I'm looking at #293 now -- that Python/C api memory leak thing. [18:28] <william> robertwb -- actually i bet you could easily fix #293 if you're around. [18:28] <william> thoughts? [18:28] <robertwb> hmm... I'll take a look [18:28] <william> thanks! [18:29] <robertwb> (I actually just added a comment to that) [18:29] <william> oh, let's just delete the macro. [18:30] <william> i wrote it a long time ago when I was trying to do fast list indexing before you did it right. [18:30] <william> i'll take care of this then. [18:30] <william> wow, we use it 11 times. [18:31] <william> deleting it isn't a good idea. [18:31] <william> does it really leak memory? [18:31] <robertwb> I'm not sure... [18:32] <william> if it did, then calling hash on any generic dense matrix would make that matrix never garbage collect. [18:32] <william> since it's used in hash. [18:32] <william> that could explain some linear algebra memory leaks [18:32] <robertwb> that would be bad... [18:32] <robertwb> it's defined in stdsage? [18:33] <william> do search_src('FAST_SEQ_UNSAFE') and you'll see where it is defined. [18:34] <robertwb> it's defined in sage_c_lib (not searched by search_src) [18:35] <william> indeed! [18:35] <william> david harvey is totally right about that memory leak! [18:35] <william> Try the following two distinct blocks of code, where m = get_memory_usage [18:35] <william> print m() [18:35] <william> n = random_matrix(RR, 200) [18:35] <william> n.set_immutable() [18:35] <william> hash(n) [18:35] <william> del n [18:35] <william> m() [18:35] <william> -- and -- [18:35] <william> print m() [18:35] <william> n = random_matrix(RR, 200) [18:35] <william> n.set_immutable() [18:35] <william> del n [18:35] <william> m() [18:36] <william> The first leaks about 3MB every time. The second doesn't leak at all. [18:36] <robertwb> ouch [18:36] <robertwb> yes, it's a new reference (though it may or may not be a new object) [18:36] <-- ncalexan-dinner has left this server (Read error: 110 (Connection timed out)). [18:37] <robertwb> not seeing an easy way to fix it either [18:38] <agc> william, the library im in is closing, see you around 7:30 [18:38] <william> agc -- see you at 7:30 at wired cafe for dinner. [18:38] <robertwb> you loose the reference returned from PySequence_Fast by passing it into PySequence_Fast_ITEMS, so you can never decref it [18:38] <-- agc has left this server ("Leaving"). [18:39] <robertwb> I'll go ahead and remove the macro and fix the 11 or so spots it's used [18:40] <william> thanks. [18:40] <william> I wish I had never created that macro. [18:40] <robertwb> (I guess we named it right, "unsafe" ) [18:40] <william> [18:41] <william> robertwb -- [18:41] <robertwb> yeah? [18:41] <william> why don't we leave the macro but decref it's input each time. [18:41] <william> e.g., in _hash, we just put decref(v) after we're done using w. [18:41] <william> ???? [18:42] <william> that should be easy. [18:42] <robertwb> that won't work if it has to create a list/tuple [18:42] <william> Then we add that to the docs for FAST_SEQ_UNSAFE [18:42] <william> I don't understand. [18:42] <robertwb> the problem is PySequence_Fast(v) may return v, or may construct a tuple out of v and return that. [18:42] <william> How about if we change the input to the macro to be a PyObject* [18:43] <william> ? [18:43] <robertwb> wouldn't help [18:43] <william> why not? [18:44] <william> oh, PySequence_Fast can actually make a new sequence? [18:44] <robertwb> FAST_SEQ_UNSAFE(v) may create a _new_ object which you never get a handle to [18:44] <robertwb> yes [18:44] <william> OK. you're right. [18:44] <william> I've assigned #293 to you [18:44] <robertwb> ok [18:56] <william> hi! [18:56] <william> can anybody replicate bug #349? [18:56] <william> it works fine for me now? [18:56] <william> Just do "s = Sage()", then "s.[tab]" [18:59] <mhansen> Works for me. [18:59] <william> ok. i've closed that one. [19:01] <william> #321 is easy. [19:01] <william> done. [19:07] <william> ok, i'm going to dinner with agc right now. [19:07] <william> are you'all around for a quick wrap up? [19:07] <william> is anybody around? [19:08] <william> anyway -- i updated http://www.sagemath.org:9002/sage_trac/milestone/sage-2.8.2 a lot [19:08] --> dmharvey has joined this channel (n=[email protected]). [19:08] <william> I think we fixed all but FOUR serious issues. [19:09] <william> anyway -- i updated http://www.sagemath.org:9002/sage_trac/milestone/sage-2.8.2 a lot [19:09] <william> thus we were extremely productive; more than i expected [19:09] <dmharvey> you guys finished already? [19:09] <william> essentially everything (except two spkg's) is available by doing hg_sage.pull() [19:09] <william> I'm about to go to dinner and I'm trying to do a wrap-up, though I don't know if anybody is listening... [19:10] <william> I'll probably be back in 2 hours, maybe. [19:10] <william> anyway, the main bugs remaining are: [19:10] <dmharvey> did 274 get fixed? [19:10] <william> (1) #293, which robertwb is fixing. [19:10] <william> (2) #274, which dmharvey is about to fix [19:10] <robertwb> I'm off to dinner too [19:10] <dmharvey> [19:10] <william> (3) #160, which mabshoff is working on. [19:11] <william> and (4) #446, which I'll fix later tonight (some weird notebook thing). [19:11] <william> everything else listed of consequence got dealt with, I think. [19:11] <william> very nice. [19:11] <william> so from my point of view i'd like to declare the bug squashing a success. [19:11] <william> cu [19:11] <dmharvey> ok [19:12] <william> I'll paste the whole transcript to the wiki as usual. Results
Bugs worked on
To Do