Why does sagenb need 2 temporary files for every "evaluate"?

[Jeroen Demeyer]

Context: I am working on #71, and while I have a proof-of-concept for
the command line, the notebook is bringing additional complications.


When I execute the command "f(x) = foo", I get the following traceback:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "_sage_input_2.py", line 10, in <module>
exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8
-*-\\n" +
_support_.preparse_worksheet_cell(base64.b64decode("Zih4KSA9IGZvb3h5"),globals())+"\\n");
execfile(os.path.abspath("___code___.py"))
File "", line 1, in <module>

File "/tmp/tmpWxdHDQ/___code___.py", line 2, in <module>
exec compile(u'__tmp__=var("x"); f =
symbolic_expression(fooxy).function(x) #sage_pp#f(x) = fooxy
File "", line 1, in <module>

NameError: name 'fooxy' is not defined


From this traceback, we see lots of levels of indirection:

A file _sage_input_2.py which preparses and compiles some code and
executes it. This code writes a file ___code___.py which is then
executed. This file in turn compiles the code which is then executed.

This uses 2 temporary files, 2 compiles and 3 execs!
Is this complexity really needed? In particular, the current way of
doing things here prevents any useful traceback, since the *actual* code
(preparsed or not) is not in the traceback apart from the exec compile
statement!

[Volker Braun]

I've seen it before, and I agree that it is a huge mess.

IMHO you shouldn't worry about making the tracebacks more informative in SageNB, just don't break evaluation.

[Thierry]

Hi,

On Thu, Nov 20, 2014 at 03:56:30AM -0800, Volker Braun wrote:
> I've seen it before, and I agree that it is a huge mess.
>
> IMHO you shouldn't worry about making the tracebacks more informative in
> SageNB, just don't break evaluation.

I do not really mind about temporary files, but having the same
traceback with the notebook and the command line is very important :
newcommers usually use the notebook and they have to learn where the
problems are coming from as well.

Ciao,
Thierry

> --
> You received this message because you are subscribed to the Google Groups "sage-notebook" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-noteboo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-notebook.
> For more options, visit https://groups.google.com/d/optout.

[kcrisman]

I've seen it before, and I agree that it is a huge mess.

IMHO you shouldn't worry about making the tracebacks more informative in SageNB, just don't break evaluation.

Yes, I wouldn't worry too much about this; for those of us still thinking about sagenb, there are bigger fish to fry.  That could be a separate ticket, and reported upstream ;)

 

Context: I am working on #71, and while I have a proof-of-concept for

 

Impressive!  There are only three two-digit tickets left open, one of which is also notebook related, and the other of which has had very long (intermittent) discussion and is still relevant.

[kcrisman]

> IMHO you shouldn't worry about making the tracebacks more informative in
> SageNB, just don't break evaluation.

I do not really mind about temporary files, but having the same
traceback with the notebook and the command line is very important :
newcommers usually use the notebook and they have to learn where the
problems are coming from as well.

Sorry, didn't see this - in general this is true, but I don't know that it currently does this, at least not fully.  (See below.)  So as long as Jeroen's fix to #71 doesn't make things worse on this front, I think it's okay.

CL:

sage: 1/0

---------------------------------------------------------------------------

ZeroDivisionError                         Traceback (most recent call last)

<ipython-input-1-6f88eab09598> in <module>()

----> 1 Integer(1)/Integer(0)

/Users/.../sage/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__div__ (sage/structure/element.c:16046)()

/Users/.../sage/local/lib/python2.7/site-packages/sage/rings/integer.so in sage.rings.integer.Integer._div_ (sage/rings/integer.c:13768)()

/Users/.../sage/local/lib/python2.7/site-packages/sage/rings/integer_ring.so in sage.rings.integer_ring.IntegerRing_class._div (sage/rings/integer_ring.c:6000)()

ZeroDivisionError: Rational division by zero 

NB:

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "_sage_input_3.py", line 10, in <module>

    exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n" + _support_.preparse_worksheet_cell(base64.b64decode("MS8w"),globals())+"\\n"); execfile(os.path.abspath("___code___.py"))

  File "", line 1, in <module>

    

  File "/tmp/tmprvtY0W/___code___.py", line 3, in <module>

    exec compile(u'_sage_const_1 /_sage_const_0 

  File "", line 1, in <module>

    

  File "element.pyx", line 1797, in sage.structure.element.RingElement.__div__ (sage/structure/element.c:14834)

  File "integer.pyx", line 1786, in sage.rings.integer.Integer._div_ (sage/rings/integer.c:13151)

  File "integer_ring.pyx", line 347, in sage.rings.integer_ring.IntegerRing_class._div (sage/rings/integer_ring.c:5715)

ZeroDivisionError: Rational division by zero

[Jeroen Demeyer]

On 2014-11-20 14:00, Thierry wrote:
> newcommers usually use the notebook and they have to learn where the
> problems are coming from as well.

The tracebacks in the sage notebook are absolutely unreadable and surely
not possible to be understood by newcomers. So #71 cannot possibly make
the situation any worse.