Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-23 Thread Volker Braun
On Sunday, November 23, 2014 11:36:02 AM UTC, Jeroen Demeyer wrote: > > 1) Keep preparse() in Sage as it is. > 2) Use IPython, which calls preparse(), to keep track of the relation > between unpreparsed and preparsed source code. > 3) Don't try to change the raw traceback (as returned by the Pyt

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-23 Thread Jeroen Demeyer
On 2014-11-23 12:11, Volker Braun wrote: Whoever puts stuff last in the line cache wins, obviously. IPython obviously puts the current input there just before executing. OK, for the first time in this thread I think I actually understand your argument. Am I right that you're arguing: 1) Keep

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-23 Thread Volker Braun
On Sunday, November 23, 2014 10:53:44 AM UTC, Jeroen Demeyer wrote: > > > Also, the commandline interface would then have to override IPython's > > use of the linecache. > I don't see why. You can have two libraries (Sage and IPython) both > using the Python linecache library, why is that a prob

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-23 Thread Jeroen Demeyer
On 2014-11-22 22:53, Volker Braun wrote: IPython is, at its core, a library to apply transformations to sources No, sage.misc.preparser.preparse() applies transformations, IPython just calls that function. and evaluate them A one-liner in Python, no need for IPython here. with easy-to-read

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-22 Thread Volker Braun
On Saturday, November 22, 2014 6:05:47 PM UTC, Jeroen Demeyer wrote: > > but then you're essentially forced to tie (un)preparsing closer to > IPython. I doubt that this is the right thing to do. Why not? IPython is, at its core, a library to apply transformations to sources and evaluate them wi

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-22 Thread Jeroen Demeyer
On 2014-11-22 13:51, Volker Braun wrote: IPython colorizes the tracebacks (at least by default, unless you turn it off) and adds the source line for command-line input. I think unpreparsing could easily be added on top of that: Of course it *could* be done (assuming upstream accepts it of course)

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-22 Thread Volker Braun
On Saturday, November 22, 2014 8:53:16 AM UTC, Jeroen Demeyer wrote: > > > 5) beautify the traceback > I assume with "beautify" you mean the graphical layout of the traceback? > Because IPython doesn't really change the contents of the traceback > (like unpreparsing). > IPython colorizes the t

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-22 Thread Jeroen Demeyer
Let me explain further: #71 is mostly about displaying unpreparsed code in tracebacks. Currently, IPython doesn't do this. Given that we also need to support this for code from load() and attach(), I think the following three should be implemented in the same place (either all in Sage or all i

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-22 Thread Jeroen Demeyer
On 2014-11-21 18:21, Volker Braun wrote: Its not brain surgery, but you want 1) Apply the preparser, possibly other input transformations 2) handle syntax errors from the preparser and show an appropriate error (not: a traceback inside the preparser) 3) handle errors from the string -> ast com

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-21 Thread Volker Braun
Its not brain surgery, but you want 1) Apply the preparser, possibly other input transformations 2) handle syntax errors from the preparser and show an appropriate error (not: a traceback inside the preparser) 3) handle errors from the string -> ast compilation and show an appropriate error

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-21 Thread Jeroen Demeyer
On 2014-11-21 15:29, Volker Braun wrote: You don't have to use IPython interactively, just use its machinery for evaluating code-from-a-string instead of reinventing the wheel. What's wrong with exec(compile())? There is not much reinvented in that. Note that it's not just code evaluated from a

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-21 Thread Volker Braun
You don't have to use IPython interactively, just use its machinery for evaluating code-from-a-string instead of reinventing the wheel. Really, why doesn't SageNB just do the equivalent of sage.repl.interpreter.get_test_shell().run_cell('1+1'), instead there is multiple temporary files with som

Re: [sage-devel] Re: Better tracebacks (#71)

2014-11-21 Thread Jeroen Demeyer
On 2014-11-21 14:00, Volker Braun wrote: IMHO this would better be solved upstream. I don't want to make this specific to IPython. I also want to use it for sage-run and sagenb and perhaps other places too which don't use IPython. -- You received this message because you are subscribed to th

[sage-devel] Re: Better tracebacks (#71)

2014-11-21 Thread Volker Braun
IMHO this would better be solved upstream. * IPython input transformers should also keep a map from the original source lines to the transformed lines. By default, that would just be the identity map. * IPython already hooks into the linecache used for tracebacks in get_ipython().compile.cache