[:bug1: 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 ([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 ([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 ([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 ([email protected]).
[09:43] --> dropdrive has joined this channel ([email protected]).
[09:56] --> robert457965 has joined this channel ([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 = 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] <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 ([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(5^8))*u^2 + (1 + O(5^4))*u^3
[11:05] <william> sage: h(u)
[11:05] <william> (1 + O(5^4))*u^3 + (1 + O(5^8))*u^2 + (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(5^30)) + (1 + O(5^8))*u^2 + (1 + O(5^4))*u^3
[11:07] <william> is
[11:07] <william>
[11:07] <william> (1 + O(5^4))*u^3 + (1 + O(5^8))*u^2 + (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 ([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 ([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 :-)
[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 ([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 ([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 ([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 ([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