#11812: traceback with load and attach of .sage files
-----------------------+----------------------------------------------------
Reporter: mstreng | Owner: jason
Type: defect | Status: new
Priority: major | Milestone: sage-4.7.2
Component: misc | Keywords:
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
-----------------------+----------------------------------------------------
Description changed by mstreng:
Old description:
> When debugging code that is loaded into or attached to a Sage session
> from a .sage file,
> the tracebacks are not very informative: they refer to <string> instead
> of to the file name, and give no line numbers or code snippets. This
> makes it hard to find out where the error is.
>
> Example:
>
> Suppose I have some files loaded with "load" or "attach", and one of them
> is a .sage file with
> {{{
> class Bar():
> def function_with_common_name(self):
> # lots of lines of code
> 1/0
> # lots of lines of code
>
> # other classes that also have functions named function_with_common_name
>
> def foo():
> # lots of lines of code
> a = Bar()
> a.function_with_common_name()
> # lots of lines of code
> }}}
>
> Now I do
> {{{
> sage: foo()
> ---------------------------------------------------------------------------
> ZeroDivisionError Traceback (most recent call
> last)
>
> /home/marco/<ipython console> in <module>()
>
> /home/marco/<string> in foo()
>
> /home/marco/<string> in function_with_common_name(self)
>
> /usr/local/sage/sage-4.6.2/local/lib/python2.6/site-
> packages/sage/structure/element.so
> in sage.structure.element.RingElement.__div__
> (sage/structure/element.c:11981)()
>
> /usr/local/sage/sage-4.6.2/local/lib/python2.6/site-
> packages/sage/rings/integer.so
> in sage.rings.integer.Integer._div_ (sage/rings/integer.c:11944)()
>
> /usr/local/sage/sage-4.6.2/local/lib/python2.6/site-
> packages/sage/rings/integer_ring.so
> in sage.rings.integer_ring.IntegerRing_class._div
> (sage/rings/integer_ring.c:5142)()
>
> ZeroDivisionError: Rational division by zero
> }}}
>
> Then to find the bug using this traceback, I would need to search my
> files to find all functions named "function_with_common_name" that are
> called from functions named "foo" for a line that could cause a division
> by zero...
>
> The cause of the problem was pinpointed by Conrado PLG and he gives the
> following fix:
>
> Search preparser.py for {{{elif fpath.endswith('.sage')}}} and change to
> the code below:
> {{{
> elif fpath.endswith('.sage'):
> s = preparse_file(open(fpath).read())
> f = open(fpath + '.py', 'w')
> f.write(s)
> f.close()
> execfile(fpath + '.py', globals)
> }}}
>
> After that change, the traceback contains the information that I want:
> {{{
> /Users/marcostreng/tmp/foo.sage.py in foo()
> 10 def foo():
> 11 # lots of lines of code
> 12 a = Bar()
> ---> 13 a.function_with_common_name()
> 14 # lots of lines of code
>
> /Users/marcostreng/tmp/foo.sage.py in function_with_common_name(self)
> 3 def function_with_common_name(self):
> 4 # lots of lines of code
> ----> 5 _sage_const_1 /_sage_const_0
> 6 # lots of lines of code
> 7
> }}}
>
> For an explanation of why this works, and for a discussion of what would
> be the best way to fix this, see
> [http://groups.google.com/group/sage-
> devel/browse_thread/thread/761f69944e21efd4]
New description:
When debugging code that is loaded into or attached to a Sage session from
a .sage file,
the tracebacks are not very informative: they refer to <string> instead
of to the file name, and give no line numbers or code snippets. This
makes it hard to find out where the error is.
Example:
Suppose I have some files loaded with "load" or "attach", and one of them
is a .sage file with
{{{
class Bar():
def function_with_common_name(self):
# lots of lines of code
1/0
# lots of lines of code
# other classes that also have functions named function_with_common_name
def foo():
# lots of lines of code
a = Bar()
a.function_with_common_name()
# lots of lines of code
}}}
Now I do
{{{
sage: foo()
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call
last)
/home/marco/<ipython console> in <module>()
/home/marco/<string> in foo()
/home/marco/<string> in function_with_common_name(self)
/usr/local/sage/sage-4.6.2/local/lib/python2.6/site-
packages/sage/structure/element.so
in sage.structure.element.RingElement.__div__
(sage/structure/element.c:11981)()
/usr/local/sage/sage-4.6.2/local/lib/python2.6/site-
packages/sage/rings/integer.so
in sage.rings.integer.Integer._div_ (sage/rings/integer.c:11944)()
/usr/local/sage/sage-4.6.2/local/lib/python2.6/site-
packages/sage/rings/integer_ring.so
in sage.rings.integer_ring.IntegerRing_class._div
(sage/rings/integer_ring.c:5142)()
ZeroDivisionError: Rational division by zero
}}}
Then to find the bug using this traceback, I would need to search my
files to find all functions named "function_with_common_name" that are
called from functions named "foo" for a line that could cause a division
by zero...
The cause of the problem was pinpointed by Conrado PLG and he gives the
following fix:
Search preparser.py for {{{elif fpath.endswith('.sage')}}} and change to
the code below:
{{{
elif fpath.endswith('.sage'):
s = preparse_file(open(fpath).read())
f = open(fpath + '.py', 'w')
f.write(s)
f.close()
execfile(fpath + '.py', globals)
}}}
After that change, the traceback contains the information that I want:
{{{
/Users/marcostreng/tmp/foo.sage.py in foo()
10 def foo():
11 # lots of lines of code
12 a = Bar()
---> 13 a.function_with_common_name()
14 # lots of lines of code
/Users/marcostreng/tmp/foo.sage.py in function_with_common_name(self)
3 def function_with_common_name(self):
4 # lots of lines of code
----> 5 _sage_const_1 /_sage_const_0
6 # lots of lines of code
7
}}}
For an explanation of why this works, and for a discussion of what would
be the best way to fix this, see
[http://groups.google.com/group/sage-
devel/browse_thread/thread/761f69944e21efd4]
Of course a patch should also include a doctest to prevent all this from
happening again.
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11812#comment:2>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
