[: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