## page was renamed from bug01 ## page was renamed from bug1 = 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. * [[bug1/status| STATUS]] * [[bug1/irc| IRC log]] * [[bug1/Results| Results]] * The base version of SAGE we'll start with is here: http://sage.math.washington.edu/bug/ * The trac server with all the bugs is here: http://www.sagemath.org:9002/sage_trac/report/1 * We will focus on the bugs listed here: http://www.sagemath.org:9002/sage_trac/milestone/sage-2.8.2 However, people with other interests can of course help out with fixing anything they want. * Write to wstein@gmail.com for an account on the bug tracker. * We'll all be on #sage-devel at irc.freenode.net. {{{ From Linux you can chat via a text console by installing "irssi", running it, and typing /SERVER add irc.freenode.net /SERVER irc.freenode.net /join #sage-devel }}} = IRC = SAGE Bug squash IRC LOG [Thu Aug 16 2007] [02:11:25] It'll be fixed in sage-2.8.1 [Thu Aug 16 2007] [02:11:38] sounds difficult to track down [Thu Aug 16 2007] [02:12:00] 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] it just looks like a patch was preapplied. [Thu Aug 16 2007] [02:12:15] anyway, fixed. [Thu Aug 16 2007] [02:12:27] 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=malb@p5B105CBC.dip.t-dialin.net). [Thu Aug 16 2007] [04:09:46] |Quit| malb has left this server (Remote closed the connection). [Thu Aug 16 2007] [04:28:45] Hey william [08:53] --> You have joined the channel #sage-devel (n=was@206.135.48.98). [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] hello? [08:55] hi. [08:55] is there a reason why the channel is secret? [08:55] no [08:56] i hardly know anything about irc [08:56] it's been a while since I used irc.. I was surprised when I couldn't find this channel in the list [08:56] bug :-) [08:57] if we're going to be using this often.. and it seems we will be.. [08:57] we should also register the group with freenode... [08:58] when we made @sage-dev a while ago, bobby moretti and i tried several times [08:58] to officially register the group, but got ignored. [08:58] it was weird. [08:59] We just changed from using #sage-dev to #sage-devel a few days ago for [08:59] consistency with the mailing list name. [08:59] Maybe we were registering incorrectly. [09:00] --> pdenapo has joined this channel (i=pablo@201.255.49.80). [09:00] this seems to be the first step: [09:00] http://freenode.net/group_registration.shtml [09:00] or maybe it's overkill... [09:01] anyway.. I'm just making remarks about nonsense.. as I won't be able to join in the bug squash.. [09:02] unfortunately, this weekend the dorms don't have internet access.. and I'll be leaving the institute in 30 minutes.. [09:02] so proper questions.. [09:02] where do you live? [09:02] is there anything I need to do, to get cython to build code with debug symbols? [09:03] cython always builds such code by default. [09:03] I live in linz, austria.. the institute, RISC, is in Hagenberg, about 25 km's away.. long distance for this place.. [09:04] so how does one go about attacking bug #274 [09:05] first confirm that it is still a bug. [09:05] it is.. [09:06] yep. [09:06] the number increases much more significantly, if one adds a couple of zeroes to the parameter of range... [09:06] i would try to simplify the loop -- take the random stuff out. [09:07] yep. [09:07] without the random stuff the leak is still there. [09:07] that's good because it is much simpler. [09:07] Is both the + and * needed? [09:08] nope. [09:08] just doing t*X exhibits a leak [09:08] yes.. you're much faster :) [09:10] <-- pdenapo has left this server ("Leaving"). [09:10] the problem is also *only* over GF(10007^2) [09:10] not over GF(10007) [09:10] so it's givaro, probably. [09:11] wait -- it's pari at that size! [09:11] it's not givaro. [09:11] 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] thanks.. but I need to leave now.. [09:13] I'll try to read the logs... [09:13] and definitely be here for next time.. [09:13] excellent. [09:13] cu [09:14] <-- burcin has left this server ("Leaving"). [09:42] --> d has joined this channel (n=dorian@adsl-75-11-167-13.dsl.sndg02.sbcglobal.net). [09:43] --> dropdrive has joined this channel (n=user@c-24-128-50-102.hsd1.ma.comcast.net). [09:56] --> robert457965 has joined this channel (n=rlmill@c-71-197-245-35.hsd1.or.comcast.net). [09:57] any intel mac binaries? [09:58] somebody somehow messed up my office computer where [09:58] the intel mac binary is. [09:58] I can't connect to it. [09:58] either it crashed, or tom changed something or ?? [09:58] I don't know. [09:59] so, no intel mac binaries. [09:59] there is one -- it's just no accessible. [09:59] ok, well my intel mac is building now [09:59] we could make binaries from that? [09:59] please post when you are done, if you have a fast connection. [09:59] yes. [09:59] just do sage -bdist 2.8.1 [09:59] ok cool [10:01] good morning/afternoon/evening [10:01] hi. [10:01] welcome. [10:01] it's 10am, so I official declare this bug squash started. [10:01] Did everybody get my email? [10:01] (from last night) [10:02] this is the key thing: http://www.sagemath.org:9001/bug1 [10:02] yes [10:02] so how is this going to work? [10:03] i'm starting on ticket 206, once my build finishes [10:03] could everbody who is here maybe write where they are physically or something? [10:03] hi [10:03] reporting from my gf's apartment, capitol hill seattle [10:03] I'm in San Diego [10:03] *** mabshoff|away is now known as mabshoff. [10:03] So you're Robert Miller? [10:03] boston, in my apartment, with a somewhat flaky internet connection [10:03] yeah [10:03] ok. [10:03] surprisingly the nickname "robert" was taken [10:04] "william" == "was_"? [10:04] i am logged in twice. [10:04] I have two different irc clients. [10:04] anyway, i made this page: [10:04] lemme guess... one is on your iphone? [10:04] I am near Dortmund, Germany with a DSL connection locally, but fat pipes at work. [10:04] http://www.sagemath.org:9002/sage_trac/milestone/sage-2.8.2 [10:05] what about dropdrive and d? [10:06] was- how is that delete script doing? [10:06] 79% done. [10:06] :-) [10:06] oy [10:07] lesson learned [10:07] how about if somebody chooses a specific bug and we all think about it for a few minutes? [10:08] optimally, somebody will have an idea, convince everybody else it is a good way to go, and [10:08] write up a patch, which everybody else could try. [10:08] william: I'm just an interested observer :) [10:08] i'm going to see if #319 still exists after all the changes to the coercion code [10:08] ok. [10:08] ok, i'm looking at it too. [10:08] unfortunately i'm still building 2.8.1 on two machines.... [10:08] just try in 2.8 [10:09] Or do hg_sage.pull() [10:09] yep it's fixed in 2.8 :-) [10:09] ha ha [10:09] The underlying SAGE library code is almost the same in 2.8.1. [10:09] one bug squashed [10:09] Most packages build better. [10:09] In particular ** GMP **. [10:09] We found a major issue this week in how GMP was being built. [10:09] here's something warranting discussion [10:09] The gmp-*/src directory had some patches for specific architectures already applied, [10:09] what is the best way to handle factoring poly [10:10] 's over RDF? [10:10] instead of it being the generic upstream code. [10:10] wait -- let's finish #319. [10:10] k [10:10] did anybody else verify that it is fixed? [10:10] sage: Matrix(QQ, 2, 2, [1, 1, 1, 1]) / 2 [10:10] [10:10] [1/2 1/2] [10:10] [1/2 1/2] [10:11] same here [10:11] somebody volunteer to make that a doctest and attach the patch to the bug report? [10:11] then we'll close it. [10:11] (same here) [10:11] i volunteer. [10:12] wow you are too fast for me [10:12] :-) [10:12] something just occurred to me [10:12] question -- is this behavior generic? we should test more base rings. [10:12] anyone claiming to have lives outside of sage might say something... we can just say we were playing video games all day [10:12] let's do it!! [10:12] online gaming. [10:12] or whatever it is called these days. [10:13] Matrix(ZZ, 2, 2, [1, 1, 1, 1]) / 2 works [10:13] m.m.o.r.p.g.? [10:13] not so massive [10:13] not yet, who knows who else will show up. [10:14] i just found a bug. [10:14] in sage-2.8.1 [10:14] i tried to start a secure server on sage.math, and it fails. [10:15] RDF and RR work with the same example [10:15] @william: Do you have a changelog with the changes in between 2.8 and the "bug" release? [10:15] excellent. [10:15] The one in sage:/bug/ is empty excpet the date. [10:15] can somebody make sure nobody is in sage-dev. [10:15] I think malb is there. [10:16] it sage:lj/bug [10:16] only people who are checking... [10:17] so is that it for 319? [10:18] That Changelog.txt starts with [10:18] Sun Aug 12 14:24:58 2007 [10:18] ------------------------ [10:18] Sun Aug 12 14:10:37 2007 [10:18] ------------------------ [10:18] I think #319 is okay, as long as william carries through on his promise to writ a doctest [10:18] And then the changes for 2.8 [10:18] I am going to take a look at #350 [10:18] I update the changelog on my laptop, but couldn't use my laptop all week. [10:18] so no change log. [10:18] yep. [10:19] Ok [10:19] mabshoff -- would you consider making a build change log? [10:19] you know about as much as I do about it. [10:20] Well, I am not exactly sure what happened in the details except: Most stuff now compiles better :) [10:20] And I wonder about the details, i.e. die the Solaris lcalc compile fixes go in? [10:20] maybe that's the entry. [10:20] no. [10:21] send me a new lcalc spkg :-) [10:21] Will do in a while. [10:21] I had planned to work mostly on neron to see how things go with ""out of the box" sage. [10:22] #389 (bug in mpfi C library) is still present. [10:22] Question regarding #350. Originally you could do something like "f = x^8 + x^4" 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] no. [10:22] it doesn't make any sense. [10:22] ok good [10:22] Have to add x = polygen(QQ) at the beginning of the log. [10:22] re changelog: There is always was/lj/todo.txt [10:23] yes, great idea mabshoff. [10:23] summarize something from that. [10:24] look at that! #350 is already fixed too! I am jinxed! [10:24] :) [10:24] question for #430: Would it be better to use GSL or numpy to find roots of a polynomial? [10:24] I don't suppose anyone has any other bugs that they want fixed just by my magical gaze?.... [10:25] sorry, a polynomial of doubles [10:25] doing hg_sage.pull() gets you the doctests for #319 [10:26] oh yeah, somebody fixed #350. [10:26] 2 down :-) [10:26] mabshoff -- want to fix #389? [10:27] robert457965 -- use numpy. [10:27] it will be way easier to code. [10:27] however, it might be worth doing some benchmarking. [10:28] what do people think aabout #190? [10:28] The issue is that detecting fractional matrix indices will slow matrix indexing down. [10:28] that's pretty funny [10:28] Not sure yet. [10:29] Maybe a[0.5] could be the average of rows 0 and 1 ?? :-) [10:29] I am checking if the patch for #226 still applies. [10:29] well, if it were a 0 by 0 matrix, you could just call iszero() [10:29] where is the code for that indexing method? [10:29] matrix/matrix0.pyx [10:29] around line 538 [10:30] by the way, when people fix things, if you give them to me somehow, I can post them so [10:30] everybody else can get them with hg_sage.pull(). [10:30] re #226 (with slight editing to account for pyrex->Cython: [10:30] patching file Cython/Compiler/ExprNodes.py [10:30] Hunk #1 succeeded at 2823 with fuzz 1 (offset 229 lines). [10:31] I will rebuild cython and then sage-2.8 [10:31] does the bug still happen? [10:32] are you sure the patch is needed? [10:32] you mean: is it fixed without applying the patch? [10:32] yes [10:32] Not yet, but I will test with the original cython. [10:32] what's your test input? [10:32] i'll just wait.. [10:33] There is a regression.pyx attached to the ticket. Give me a minute to sort it all out. [10:34] ok. [10:34] dmharvey -- are you looking at #190? [10:34] #190: do matrix subclasses generally override the getitem/setitme methods? [10:34] one bad thing is: return self.row(int(key)) [10:35] [mabshoff@m940 sage-2.8.1]$ cython regression.pyx [10:35] [mabshoff@m940 sage-2.8.1]$ [10:35] no, they enver do. [10:35] That is without the patch. [10:35] ok [10:35] (regarding #190) [10:35] So #226 can be closed then. [10:35] not until i have the patch and have tested it too :-) [10:36] It was the original cython without the patch applied. [10:36] #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] it's a simple patch. [10:36] ok. [10:36] #226 - oh -- it already works -- no patch needed? [10:36] Yes. [10:36] #190: yes. [10:37] #226: where is regression.pyx [10:37] The report for #226 was for pyrex 0.9.4.1, roughly 7 months old. [10:37] ok. mabshoff - you can have the honors of closing the bug. [10:37] attached to the ticket. [10:38] #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] Mmh, I have to remember my trac password. [10:38] #190: what does magma do? [10:39] re #226: Reported by: was [10:39] #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] #190: let me check on magma; never done matrices before so gimme a few minutes [10:39] you are convincing me that we should just give an error if the input isn't int,long,Integer. [10:39] wait -- can't we have a fast version, and if that doesn't work, have a slow version? [10:40] william: How should we handle fixed bugs? [10:40] Add some text (in this case) stating: Was fixed in a previous release of cython. [10:40] for the sage library, make them available to me in any way, and I'll (1) put them in the official [10:40] cython regressioin.pyx works. [10:40] hg repository; for other things, I'll put them in /home/was/bug/ [10:41] oh -- and post verbosely to trac! [10:41] --> ncalexan has joined this channel (n=user@d207-216-25-207.bchsia.telus.net). [10:41] hi nick. [10:41] where you at? [10:41] Hi folks... I can't stay long, relaxing with the family, but thought I'd see how things were. [10:41] Victoria, BC. [10:41] #190: magma raises an error "Runtime error in '[]': Bad argument types" [10:41] You? [10:41] i wonder what nick things. [10:41] nick thinks. [10:42] nick, if a is a matrix, and n = QQ(5), should a[n,n] be an error or not? [10:42] #190: my preference is to allow only int/long/Integer [10:42] hi nick [10:42] --> paulolivier_sage has joined this channel (i=8143024e@gateway/web/cgi-irc/ircatwork.com/x-f7a7e0b894111559). [10:42] wait! [10:42] <-- paulolivier_sage has left this server (Client Quit). [10:42] we should do whatever python lists do, shouldn't we? [10:42] Yes. That's a reasonable answer. [10:43] also, we should look at what numpy arrays and matrices do. [10:43] sure [10:43] That probably means calling __int__ or something similar, no? [10:43] 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] NO. [10:43] Yeah, I think we best stick with that then. [10:43] ? [10:43] #190: A python list will call __index__ and if that works, use it. otherwise fail. [10:44] So anybody can make their own new class that can index into lists, etc., if they want. [10:44] #190: ah that explains why you can index on an Integer [10:44] I used to have to do this crap in the preparser: v = [1,2,3] [10:44] v[Integer(2)] [10:44] it totally sucked. [10:44] We don't want to make SAGE users who make new classes suffer that way. [10:44] #190 -- where? [10:45] #190: sorry, I mean for a python list [10:45] there must be a python/c api call to get foo.__index__() [10:45] #190, i.e. v[Integer(2)] works, but v[2.5] doesn't [10:45] Why was it bad? [10:45] #190: yep, that's good. [10:45] but if somebody wanted to make their own "2.5" and define an index method on it, then it would work. [10:45] That's the best way to go. [10:45] Ok, I close #226 [10:45] +d [10:46] thanks! [10:46] 3 down. [10:46] Ah, so it was too slow? [10:46] But I think I found a bug in cython. [10:46] 33 to go. [10:46] report the cython bug to track [10:46] cython -v doesn't work as expected. [10:46] #190: so conclusion is that Matrix.__getitem__ should use call __index__? instead of coercing to int? [10:46] #190: no -- the problem was that it wasn't meaningful [10:46] It just prints the standard help text. [10:46] #190 http://www.sagemath.org:9002/sage_trac/ticket/190 [10:47] mabshoff -- agreed. report it. [10:47] #190: use. [10:47] #190: dmharvey -- yes. [10:47] #190: ok I will try to code thisup [10:48] thanks!! [10:48] i'm pasting this part of the transcript from irc into trac, since it explains the decision well. [10:48] Which component in trac is cython? [10:49] packages. [10:49] ok [10:49] it actually has its own bug tracker in berliOS too. see cython.org [10:49] maybe that is a better place to post the bug. [10:49] Too late, I gues. [10:49] ? [10:49] It is in now. [10:49] no prob. [10:50] * pauloliviersage says hi [10:50] It is #438 [10:50] hi paul [10:50] hello [10:50] where are you at physically? [10:50] oxford [10:50] btw, william, if you have a chance at sage days bristol you should come around here and give a talk [10:50] cool. [10:51] let me know if you think you would have time, i am sure you will be busy [10:51] the milestone pages updates itself in real time, pretty cool. [10:54] i'm tracking status of what people ware working on here: http://sage.math.washington.edu/bug/status.html [10:54] robert miller -- how is #430 going? [10:55] I just looked at #248. it works fine now. can somebody else confirm this? [10:55] i am working on the remote stuff [10:55] I'm going to add a doctest and close it. [10:55] what is "the remote stuff"? [10:55] which trac number? [10:55] #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] yes. [10:56] thanks. [10:56] 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] this is definitely the right solution, so we have to do it, despite any pain it causes. [10:56] do you have a trac account? [10:57] i have one [10:57] pdehaye [10:57] please create a trac ticket. [10:57] ok [10:57] with the twisted project they have a rule that *anything* you work on has a trac ticket. [10:57] we don't, but it's perhaps a very good idea. [10:58] #190: ok [10:59] #190 -- did you right the code already? [10:59] that was fast. [10:59] #190: no, I'm just scoping out related issues still [10:59] 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] great idea. [11:00] Yeah, a lot of the patches Didier did for the Nexenta port were lost and later recreated by William and me. [11:00] (and by didier...) [11:01] ok, i'm closing #248 -- it works fine now. [11:01] Well, true - he must have forgotten about them by the porting sprint. [11:02] #439 (should i add to milestone 2.8.2 so it figures in this sprint?) [11:02] (i have added but am not sure) [11:02] sure. [11:03] though you make the game harder (since I hoped we would deal with everything in the list :-) [11:03] but if you can do it, then so much the better. [11:03] #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] (it s a bonus round) [11:04] #190 -- yep, it must involve the implicit coercion to Py_ssize_t in the tuple extract in matrix0.pyx [11:04] #254 -- dmharvey -- you reported this. [11:04] #254 -- it now works fine :-) i think david roe fixed it. it's p-adic precision loss in poly eval. [11:04] I'm closing it. [11:05] #254: ok thanks [11:05] though one thing -- maybe it is still weird. [11:05] Look: [11:05] h = u + (1 + O(5^8))*u^2 + (1 + O(5^4))*u^3 [11:05] sage: h(u) [11:05] (1 + O(5^4))*u^3 + (1 + O(5^8))*u^2 + (1 + O(5^20))*u [11:05] what about that coefficient of u? [11:06] never mind -- it's padic capped, so [11:07] sage: h = u*(1+O(5^30)) + (1 + O(5^8))*u^2 + (1 + O(5^4))*u^3 [11:07] is [11:07] [11:07] (1 + O(5^4))*u^3 + (1 + O(5^8))*u^2 + (1 + O(5^20))*u [11:07] #254: i'm closing it. [11:08] #268 -- another dmharvey bug -- is also now fixed :-) [11:09] Is that 5 down? [11:09] yep. [11:09] 6 down. [11:09] ohh. #274 looks really hard. [11:09] not all bugs are created equal though [11:09] it's a memory leak. [11:10] Yes, the quick ones will be gone first. [11:10] i looked at this one with somebody from Austria 2 hours ago... [11:10] #274: i'm going to work on this now; mabshoff and his valgrind might end up being helpful. we'll see. [11:12] valgrinding python is rather tricky. [11:12]