On Mar 10, 2009, at 5:38 PM, Nicolas M. Thiery wrote: > Dear Sage devels, dear Robert, > > From #sage-devel: > ---------------------------------------------------------------------- > -------- > 00:54 < hivert> So one more day lost because of this #(&$%#^%$^*%#$ > bug !!! I'm heading to bed. > 00:55 < hivert> I'm wondering when I'll manage to add something > interresting to sage ! Right now I'm spending my time cleaning > things and recompiling sage !!! > 00:55 < hivert> It's *very* frustrating ! > ---------------------------------------------------------------------- > -------- > > I must say that I was in the same state when working on the core of > the category stuff. There are two issues there. One is about the build > and test system for which Florent already sent an e-mail. > > The other issue is about coercion. When working on low level stuff > like categories, it often happens that you break something during the > sage initialization, and in particular when the coercions between the > basic parents (ZZ, QQ, QQbar, ...) are being setup. > > The problem is that a lot of code is imported and executed during > coercion resolutions, and within try ... catch. This leads to nasty > crashes, without proper stack trace pointing to the problem, even in > cases where it was a trivial SyntaxError in one of the imported > files. Sometimes this ends up in a state where it's not even possible > to start coercion_traceback().
It's surprising that we end up catching SyntaxErrors! > Would it be possible to reduce the exception catching to a strict > minimum, making sure that all errors that are unrelated to a normal > conversion failure are not catched? Yes, I think we could greatly reduce the number of exceptions caught. At most, TypeError, NotImplementedError, and perhaps ValueError. Also, I think I could reduce the number of places things are caught. Sometimes it would make things more messy, like not being able to catch attribute/key errors in as large of a block (or explicitly testing for them via hasattr/haskey, which is slower). > Or even: does this exception handling play any role upon startup? In > principle things should be in a fairly sane and predictible state so > that one could possible avoid all guess work. If yes, one could simply > completely disable exception catching until the initialization is > finished? Most of the errors caught are because it's trying to detect an action, i.e. given a*b, it tries out a._rmul_(b) and, if successful, registers that as an action, but otherwise goes on to try the next thing. The benefit of this is convenience to the author--you just have to implement an _rmul_ method on your elements and it works. Of course, as you have indicated, this does have its drawbacks. This may also be relevant: http://trac.sagemath.org/sage_trac/ticket/ 4986 > This issue by itself has readily wasted by accumulation at least one > if not two good weeks of developer time, so urgent help would be > really appreciated. Wish you had brought this up sooner. The other day I was looking at that code and thinking "oh, I could get rid of catching stuff there" but as it wasn't relevant to what I was doing at the time and I didn't see any urgency it went on my "todo later" list. I'll put up a patch soon. > Thanks so much in advance! > > Best regards, > Nicolas > -- > Nicolas M. Thiéry "Isil" <nthi...@users.sf.net> > http://Nicolas.Thiery.name/ > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
