SAGE Bug Squash Day 4

The event will take place on SATURDAY, October 20 and officially start at 10 am pacific standard time. It will "officially" go nonstop for 10 hours (until 8pm) and some people will usually meet the day after and finish up some of the leftovers.

Remember the "Twisted Rule" -- Don't work on anything unless there is a trac ticket for it.

Alternatively, do:

sage: hg_sage.pull(); hg_sage.merge();; hg_sage.update()
sage: hg_doc.pull(); hg_doc.merge();; hg_doc.update()
sage: hg_scripts.pull(); hg_scripts.merge();; hg_scripts.update()

There is a prebuilt version on sage.math here, which you'll need to hg_sage.pull() on as above:

And I'll be posting a tar'd prebuilt version there too for sage.math.

From Linux you can chat via a text console by installing "irssi", running it, and typing 
  /SERVER add 
  /join #sage-devel

Participants (with area they would like to work on)

  1. William Stein -- applying patches; organization
  2. Mike Hansen
  3. Michael Abshoff (memory leaks, Solaris port, whatever else looks interesting ;) )

  4. David Harvey -- probably won't make it due to work overload :-(

  5. John Voight -- Number field stuff
  6. Robert Bradshaw
  7. Craig Citro (after about 1PM Pacific)
  8. Jason Grout -- graphs or an interface to QEPCad.
  9. Carl Witty
  10. Joel Mohler -- small matrix and/or multi-variate poly rings
  11. Robert Miller -- nice bug

attachment:bugs.jpg attachment:compact.jpg

(from and )

IRC log

05:41 < jason_> Does anyone know the base revision for the bug day today? 05:43 < wstein> Install sage-2.8.7. Then pull hg_sage, hg_doc, and hg_scripts. 05:44 < jason_> using hg_sage.pull() (in sage) or hg pull inside the sage/devel/sage directory? 05:45 < wstein> they are identical 05:45 < wstein> sage: hg_sage.pull(); hg_sage.merge(); 05:45 < wstein> sage: hg_doc.pull(); hg_doc.merge(); 05:45 < wstein> sage: hg_scripts.pull(); hg_scripts.merge(); 05:45 < jason_> okay, it's working. Thanks. 05:48 < jason_> I presume that when it says all I have to do is update, I don't need to run merge or commit, but hg_docs.update() is all I have to do? 05:48 < jason_> Is that correct? 05:49 < wstein> yes. 05:49 < wstein> merge won't hurt. 05:49 < jason_> great, thanks. I'll go build this and hopefully be back later. Thanks! 05:50 < wstein> cu 05:50 -!- jason_ [n=[email protected]] has quit [Remote closed the connection] 06:00 < burcin> if I create two polynomial rings over the same field, what stops me from adding/multiplying polynomials from these different rings? 06:00 < burcin> i.e., at the moment, I can do this with my BooleanPolynomialRing, but not with other polynomial rings in sage 06:00 < burcin> and I don't know how to fix mine 06:02 < burcin> my rings already implement hash and "R is P" returns false 06:18 < wstein> You must implement a natural _coerce_impl method in the ring, which 06:18 < wstein> specifies how/which rings can map automatically to your BooleanPolynomialRing. 06:18 < wstein> (and conversely) 06:20 < burcin> I have a _coerce_c_impl method, which martin added.. 06:21 < burcin> should that raise an exception if the coercion is not possible? 06:26 < burcin> ok, I see that for the sage PolynomialRings I've been playing with, has_coerce_map_form returns false 06:26 < burcin> and for mine it returns true, I need to check why now.. 06:53 < fabio_> Hello all 06:53 < fabio_> is there a way to access the irc-logs? 06:59 -!- fabio_ [i=[email protected]] has quit [Read error: 104 (Connection reset by peer)] 07:00 -!- fabio_ [i=[email protected]] has joined #sage-devel 07:06 -!- fabio_ [i=[email protected]] has quit ["Verlassend"] 07:29 -!- cwitty [n=[email protected]] has joined #sage-devel 08:05 < burcin> if I implement a subclass of MPolynomialRing_generic 08:06 < burcin> and define call to "return self._coerce_c(other)" 08:06 < burcin> why doesn't my subclass use the _coerce_c_impl coded in MPolynomialRing_generic? 08:06 < cwitty> Let me look. 08:06 < burcin> or even better.. why do I get a segfault? 08:08 < cwitty> What are you coercing from? 08:08 < burcin> I'm just doing R(0), where R is my ring 08:09 < burcin> actually, why doesn't MPolynomialRing_generic, or a CommutativeRing, or something even higher in the class hierarchy have call already defined? 08:09 < cwitty> No idea. 08:09 < burcin> I thought this was common notation in sage 08:11 < cwitty> Does R.base_ring()(0) work? 08:13 < cwitty> Do you have gdb installed on your machine? If so, you can run "sage -gdb" and get a backtrace from the segfault. 08:13 < burcin> base_ring returns GF(2), so it works 08:14 < burcin> honestly, I can't make sense of the backtrace 08:14 < burcin> now, this is interesting.. 08:15 < burcin> apparently, the MPolynomialRing_generic._coerce_c_impl gets called in an infinite loop 08:15 < burcin> so scratch my first question, that function was getting called, and it was the one causing the segfault 08:18 < burcin> is it normal that MP.._generic._coerce_c_impl ends up calling "self(x)"? 08:19 < cwitty> Well, I see that in the code. But I'm not understanding it, now that you mention it. 08:20 < cwitty> (I'm really not that familiar with the coercion model...mostly I copy-and-paste, and I've been fortunate enough to have that work.) 08:20 < burcin> I think no code path uses this function, it doesn't make sense.. 08:21 < burcin> I'm trying to get familiar with the coercion model now, it hasn't been a very good day :) 08:24 < cwitty> Robert Bradshaw is signed up for Bug Day 4 (starting in a couple of hours), so he (and lots of other people) should be available for questions then. 08:26 < cwitty> It looks like polydict and libsingular mpolynomials have call methods that have knowledge of all (or many) kinds of polynomials hardcoded. Pretty annoying if you want to add a new kind of polynomial. 08:27 < burcin> yes, I've seen those 08:27 < burcin> it seems like the design went wrong somewhere 08:28 < cwitty> yep. 08:30 < burcin> ok, I'll try to make sense of this code 08:31 < burcin> and be online when the bug day starts 08:31 < burcin> though I can't stay up all night for the bug day this time 08:36 < cwitty> Univariate polynomials aren't much better. There's a lot less code involved per case (because they don't have to worry about variable names, I guess); but there's still a lot of cases in Polynomial_integer_dense_ntl.init 08:39 < burcin> let me see 08:41 < burcin> I didn't know you could do that with univariate polynomials, I mean initialize them when you're creating them 08:41 < burcin> looking at the multivariate code I thought the sage way of doing that was to coerce into the parent object, and get the desired element 08:44 < cwitty> It all seemed a lot more straightforward when I was just copy-and-pasting and not actually thinking about it :) 08:54 < burcin> ok, univariate polynomials also do the coercion in call 08:54 < burcin> at least PolynomialRing_general defines it that way 08:56 < cwitty> But if you look at the last few lines of call, it mostly just forwards to the init method of the individual class. 08:58 < burcin> yes, you're right.. 09:02 < burcin> I can't wrap my head around this at the moment 09:02 < burcin> there should be a simple way of making the coercion model handle this, without these classes having to know about their _peers_ :) 09:03 < burcin> I'll think of that on the way back home 09:03 < burcin> and try to get online again a couple of hours later 09:03 < cwitty> See you around. 09:03 < burcin> see you 09:03 -!- burcin [i=[email protected]] has quit ["Leaving"] 09:13 -!- mhansen [n=[email protected]] has joined #sage-devel 09:13 < cwitty> Good morning, mhansen. 09:13 < mhansen> Hello 09:13 < mabshoff|asleep> Hi mhansen 09:13 -!- mabshoff|asleep is now known as mabshoff 09:16 < mhansen> How did things play out the rest of the night. I fell asleep around a bit after William left. 09:16 < mabshoff> well, no release yet. 09:17 < mabshoff> But William closed #923, so the basis for today is 2.8.7 + hg_[doc|sage|script].pull() 09:17 < cwitty> There's a; did you know about that? 09:17 < cwitty> (Which I think is the same thing as what mabshoff just said, packaged in a tarball.) 09:17 < mabshoff> Nope, is it in sage.math/tmp or where? 09:18 < cwitty> 09:18 < cwitty> points to 09:18 < mabshoff> I guess 09:18 < cwitty> 09:19 < cwitty> BTW, sorry for dropping out in the middle of conversations last night; we had a storm, and the power went out in my apartment. 09:21 < mabshoff> mmh, I guess you mean mhansen with that. 09:22 < cwitty> Actually, I guess I probably mean craigcitro. 09:22 < mabshoff> Yeah, that is the way it looks from the logs. 09:41 < wstein> cwitty -- wow you guys lost power. 09:41 < wstein> ouch. 09:41 < mabshoff> wb wstein 09:41 < wstein> It was pretty windy up here but I didn't have power issues. 09:42 < mabshoff> have a look at #941, dmharvey pointed us in the right direction 09:42 < cwitty> The wind here had mostly died down when the power went out. 09:47 -!- was [n=[email protected]] has joined #sage-devel 09:48 -!- was is now known as william 09:48 < cwitty> william: ignoring "sage: " at the beginning of typed-in commands was a REALLY good idea. Thanks. 09:48 -!- william is now known as wstein2 09:49 < wstein2> Magma has an IgnorePrompts mode. 09:49 < wstein2> But it's off by default. 09:49 < wstein2> I just made it on everywhere in Sage by default. 09:49 < wstein2> It is incredibly convenient. 09:49 < mabshoff> Does it also ignore '....'? 09:50 < wstein> yes. 09:50 < wstein> sort of. 09:50 < mabshoff> Well, then one can just paste any session without reformatting or editing. 09:51 < cwitty> ipython's auto-indent screwed it up for me when I just tried it. 09:52 < cwitty> Actually, it doesn't seem to work at all. 09:53 < wstein2> maybe it doesn't work with ... 09:53 < wstein2> That could be fixed though. 09:57 -!- jvoight [n=[email protected]] has joined #sage-devel 09:58 < mabshoff> hi jvoight 09:58 < jvoight> Hi everyone! How's it going? 09:58 < jvoight> Hey Craig: got your patches, thanks! Haven't had a chance to try them out yet. 09:59 < wstein2> hi 10:03 < mabshoff> "sage -t devel/sage-main/sage/calculus/" seems to hang for me with 2.8.7+updates 10:03 -!- adam [n=[email protected]] has joined #sage-devel 10:04 < wstein2> on what systems? 10:04 < wstein2> for me it finishes in 23.6 seconds. 10:04 < mabshoff> sage.math 10:05 -!- adam [n=[email protected]] has quit [Client Quit] 10:05 < mabshoff> I have a clisp process with 9 seconds of CPU time sitting idle 10:05 -!- robert [n=[email protected]] has joined #sage-devel 10:05 < wstein2> it works fine with my clean build on sage.math in /home/was/www/tmp/ 10:06 < mabshoff> That might be it, I am building, but I tried 2.8.7+updates while I waited 10:06 < mabshoff> for that. 10:06 < cwitty> It fails for me too. My CPU load monitor went down to zero, and the test is just sitting there. 10:07 < wstein2> I'm going to rebuild the sage- tarball right now. 10:07 < cwitty> And Control-C doesn't work. 10:07 < wstein2> I've tested that test on 4 machines without a failure. Weird. 10:07 < mabshoff> yep, that is also the case for me. 10:07 < wstein2> Which test is hanging? 10:07 < wstein2> sage --verbose... 10:07 < cwitty> Trying: 10:07 < cwitty> f = expand((Integer(2)*u*v**Integer(2)-v**Integer(2)-Integer(4)*u**Integer(3))**Integer(2) * (-u)**Integer(3) * (x-sin(x))**Integer(3))###line 2080:_sage_ >>> f = expand((2*u*v2-v2-4*u3)2 * (-u)3 * (x-sin(x))3) 10:07 < cwitty> Expecting nothing 10:08 < wstein2> cwitty -- which machine are you using? 10:08 < cwitty> my laptop. 32-bit x86 Debian testing. 10:08 < wstein2> I can't test on 32-bit linux right now, since bsd seems to have gone down. 10:08 < wstein2> I'm only able to test on powerpc osx, intel osx, and 64-bit linux. 10:08 < wstein2> (Also, meccah is gone.) 10:09 < mabshoff> down or gone? 10:09 < wstein2> gone. 10:09 < wstein2> it physically broke a few weeks ago. 10:09 < wstein2> evidently. 10:09 < wstein2> Anyway, Sage Bug Day 4 starts now. 10:09 < cwitty> You could set up a 32-bit chroot on sage.math. 10:10 < mabshoff> ok, if I want to log into abel or neron: which box do I use as "proxy"? 10:10 < wstein2> I have lots of good 32-bit environments -- it's just that the machine that runs them seems to have gone offline last night (it's my office workstation). 10:10 < wstein2> mabshoff -- 10:10 < mabshoff> I don't think I have an account, not important right now. 10:11 < mabshoff> oh, maybe I do, never mind. 10:11 < robert> is there any way to do memory testing for sage on os x? 10:11 < wstein2> Is robert = robert miller? 10:11 < robert> yes 10:11 < mabshoff> OSX's libs has checks for double frees and a couple other issues, 10:12 < wstein2> mabshoff spent hours trying to do memory testing related to graphi_isom.pyx last night... 10:12 < wstein2> So he can probably fill you in. 10:12 < mabshoff> valgrind will come with Leopard, but I don't know what release. 10:12 < robert> i'm upgrading in linux, so i can wait for that... 10:12 < mabshoff> I commented all my findings to the ticket. 10:12 < wstein2> anyway, it's sage bug square day 4, and we'll focus on every *bug* from sage-2.8.8 on in the trac server. 10:12 < mabshoff> :) 10:12 < jvoight> I thought we were going to squash bugs, not square them! 10:12 < wstein2> mabshoff / cwitty -- you could try "hg_sage.pull()" again 10:13 < wstein2> :-) 10:13 < mabshoff> So it is your fault? 10:13 < wstein2> since on all my machines "sage -t" works. 10:14 < robert> mabshoff - not only is it certain graphs, but often only under certain circumstances - for example, the digraph that crashes all this works fine if you just do it alone first 10:15 < mabshoff> mk, we had some long discussion about the way you allocate arrays last night. 10:15 < wstein2> I can now replciate the problem on one machine. 10:15 < mabshoff> Good 10:18 < robert> i wonder what could have happened though, that doctest was working at the end of the summer... 10:18 < mabshoff> If there are memory issue it might work on one box but crash on another. 10:18 < wstein2> Are you sure the doctest ever worked? 10:18 < wstein2> It was sage.:'d. 10:18 < mabshoff> i.e there we coercion issues that only crashed on FC 7 32 bit. 10:19 < wstein2> Which means to me that maybe you thought it should work once in isolation, but never automatically tested. 10:19 < mabshoff> robert: Can you create a mini code snippet with the graph that crashes as well as 10:19 < mabshoff> all the code to do the computation 10:20 < mabshoff> That way I can just paste it into a session and see if anything pops up. 10:20 < robert> the problem is this 10:20 < robert> if i run all the graphs, then it crashes 10:20 < robert> but if i just do the last one, it doesn't crash 10:20 < mabshoff> Sure, but valgrind might tells us something nonetheless. 10:21 < mabshoff> I increased array sizes and then it would run for longer and crash somewhere else. 10:21 < jvoight> Craig: I just applied your patch and it had a negligible affect on my calculations. 10:21 < jvoight> So we should probably talk some more. 10:21 -!- malb [n=[email protected]] has joined #sage-devel 10:21 < jvoight> (27.7 s vs. 27.4 s--so you did gain 0.3 s. :)) 10:21 < mabshoff> So the non-crashing example might still reveal information and give us pointers. 10:21 < cwitty> wstein2: I've attached a patch to #913. 10:21 < mabshoff> Hi malb 10:21 < malb> hi everybody 10:22 < cwitty> Hi. 10:22 < robert> try this 10:22 < robert> sage: d = DiGraph({0: {0: None, 2: None}, 1: {0: None, 1: None, 2: None}, 2: {0: None, 1: None, 2: None}}) 10:22 < robert> sage: d.canonical_label() 10:22 < mabshoff> Thanks. 10:22 -!- cwitty changed the topic of #sage-devel to: SAGE Bug Days 4 in progress 10:23 < malb> has 2.8.8. been released? 10:23 < malb> what's the version I am supposed to work with for this squash? 10:23 < mabshoff> Nope, but 10:24 < wstein2> get 2.8.7 and pull in hg_sage, hg_scripts, and hg_doc 10:24 < mabshoff> It is in sage.math/mtp 10:24 < malb> no upgrade? 10:24 < mabshoff> Ehh sage.math/tmp. but you should pull 10:24 < wstein2> no upgrade. 10:24 < malb> okay 10:24 < wstein2> I might be able to release it though as an upgrade right now, since it passes doctests. 10:24 < wstein2> at least, maybe in 5-10 minutes. 10:24 < malb> okay, good 10:25 < cwitty> wstein2: for #837, "RealNumber should have abs method", I plan to add an abs method on RingElement that just forwards to the built-in abs method. So rings where abs makes no sense will not implement it, and .abs() will still fail (but tab-completion will say it's there). 10:25 < cwitty> Does that sound good? 10:25 < malb> I'll make a new spkg for Singular which fixes some bugs 10:25 < wstein2> yes. 10:25 < wstein2> thanks malb 10:25 < mabshoff> malb: Did you see the email from Hannes with the memmove fixes? 10:25 < mabshoff> (for Singular) 10:25 < malb> yes, it is in singular 3-0-3-2 10:25 < mabshoff> Cool, just making sure. 10:26 < malb> the second release just for us 10:26 < mabshoff> It is amazing that they release just for us. 10:26 < mabshoff> Exactly ;) 10:26 < malb> it is 10:26 < roed_> hello 10:26 < mabshoff> Well, I assume that many people find problems, but few report them back properly 10:26 < mabshoff> and follow up like we do. 10:26 < mabshoff> Hi roed_ 10:26 -!- giniu [n=[email protected]] has joined #sage-devel 10:27 < mabshoff> William rediscivered your #919 10:27 < roed_> I saw. He sent me an e-mail 10:27 < robert> mabshoff - any useful information from valgrind? 10:27 < mabshoff> And I also found that you do not clean up the caches memory, which became #942 10:27 < mabshoff> Not yet, had to build the optional valgrind spkg. 10:27 < roed_> I thought I did 10:27 < roed_> Let me look 10:28 < mabshoff> Well, it was without the patch for #919 10:28 < wstein2> Try hg_sage.pull() and hg_scripts.pull(), then retest 10:29 < mabshoff> Will do after I finish valgrinding robert's issue. 10:29 < roed_> Yeah, my code looks like I clean up the memory 10:29 < mabshoff> Cool 10:29 < mabshoff> In Williams test case it was about 2.1GB, so one tends to notice that. 10:30 < mabshoff> But I can retest once #919 is merged. 10:30 < wstein2> Hi -- I'm going to make an official release in a few minutes, so everybody can just "sage -upgrade" to it. 10:30 -!- fabio_ [n=[email protected]] has joined #sage-devel 10:31 < wstein2> This will be the same as "hg_sage, hg_doc, hg_scripts" pulls, along with installing the elliptic_curves standard package, which wasn't installed before. 10:31 < mabshoff> robert_: the simple example is clean. 10:31 < robert> clean? 10:31 < roed_> ah. Yeah, I think there was a bug and I wasn't using weakrefs 10:31 < robert> valgrind finds nothing? 10:31 < roed_> Now I am 10:31 < mabshoff> But in case it crashed I saw issues with pariinstances accessing uninitialized memory. 10:32 < mabshoff> The are no access violations when valgrinding the simple example, so yes. 10:32 < robert> that doesn't make any sense 10:32 < mabshoff> Well, it might not be your fault, but a side effect of something else. 10:33 < mabshoff> I am rerunning the whole doctest, that way I can look at the callchain for the pari_instamce 10:33 < mabshoff> failures. 10:33 < robert> pariinstance? 10:33 < mabshoff> The only interesting question is: Where do we end up using pari_instance in that code? 10:34 < robert> it doesn't make sense that we are at all 10:34 < robert> it's all local datastructures and stuff 10:34 < mabshoff> Did you see the remark about k growing beyond n? 10:34 < robert> yeah 10:34 < mabshoff> Or n+1 10:35 < robert> that was pretty typical for the problems i was having before 10:35 < mabshoff> That is what causes the crash itself. 10:35 < robert> but the variance on what causes that is crazy 10:36 < mhansen> passes for me with the updates. 10:36 < mabshoff> Well, it may be that some values are not properly reinitialized when calling it 10:36 < mabshoff> i.e. search whatever multiple times. 10:37 < wstein2> #919 -- I'm looking at this now. 10:37 < robert> but shouldn't valgrind pick up something like that? 10:37 < mabshoff> No, not in that case. 10:37 < robert> if it's not initialized then valgrind would catch something reading from it 10:37 < mabshoff> The first issue I see is some problem in the coercion code: 10:37 < robert> oh, because it was initialized before... 10:37 < mabshoff> Something like that. 10:39 < mabshoff> The problem with the coercion code is attached to the ticket, but it might 10:39 < mabshoff> be also k being greater than n+1. 10:40 < robert> mabshoff - here's some insight 10:41 < robert> we have to keep track of "indicator values" in that code. that lets you tell what parts of the search tree you've seen before 10:41 < robert> i think I'm using sage int's for those, that might be where coercion comes in... 10:41 < mabshoff> Well, I saw something else related. 10:41 < mabshoff> ==31660== Use of uninitialised value of size 8 10:41 < mabshoff> ==31660== at 0x42E340: PyInt_FromLong (intobject.c:88) 10:41 < mabshoff> ==31660== by 0x17DDDFCD: pyx_f_py_10graph_isom_search_tree (graph_isom.c:7607) 10:42 < mabshoff> which is 10:42 < mabshoff>

bug/04 (last edited 2017-02-02 04:09:35 by mrennekamp)