[sympy-live] More helpful error messages (#64)

[David Li]

Fixes/helps with issue 3570.

Changes:

• Exceptions during evaluation that are not caught (i.e. exceptions that occur in the Live code and not the user code) are sent back
• Error handler displays the proper error message now (timeout/HTTP error message)

---

You can merge this Pull Request by running:

  git pull https://github.com/lidavidm/sympy-live error_messages

Or view, comment on, or merge it at:

  https://github.com/sympy/sympy-live/pull/64

Commit Summary

• More helpful error messages

File Changes

• M shell.py (26)
• M static/live-core.js (30)
• M templates/shell.html (3)

Patch Links

• https://github.com/sympy/sympy-live/pull/64.patch
• https://github.com/sympy/sympy-live/pull/64.diff

—
Reply to this email directly or view it on GitHub.

[David Li]

Demo at http://64.sympy-live-tests.appspot.com/

[Aaron Meurer]

A timeout shows the traceback now.

[Aaron Meurer]

In templates/shell.html:

> @@ -198,7 +198,8 @@
>  		</div>
>  		</div>
>  		 <div id="footer2">
> -              <div class="align_left">Copyright &copy; 2012 SymPy Development Team.</div>
> +              <div class="align_left">Copyright &copy; 2012 SymPy
> +              Development Team. SymPy Live version {{application_version}}</div>

Thanks. Wasn't there a way to parse the decimal part into something meaningful, though?

[David Li]

Alright, now it parses the second part of the version to show the date deployed and should handle timeouts correctly.

[Aaron Meurer]

Looks good. Just one question. Is there a way to enable some kind of verbose mode or logging when debugging locally, so that I can see the full traceback of an error?

[David Li]

Okay. For local instances, setting DEBUG = True in settings.py will give you the full traceback rather than the last 5 entries.

[David Li]

Changes:

• The hash (e.g. #settings) is now used to open the corresponding sidebar.
• Add ?evaluate=statement to run a statement on page load
• Add toolbar button that will take current input and generate such a URL

Fixes issue 3574.

[David Li]

Example: http://64.sympy-live-tests.appspot.com/?evaluate=def%20axn_ln2(n)%3A%20return%201.0*(-1)**(n%2B1)%2Fn%0A%0A%0Asum(%5B%20axn_ln2(n)%20%20for%20n%20in%20range(1%2C1000000)%20%5D)

[Aaron Meurer]

It seems to be rendering the arguments of sum in latex.

[Aaron Meurer]

It seems that pressing SymPy live at the top should clear the URL

[Aaron Meurer]

Thanks for fixing he hash behavior. I've long thought it should work that way.

[Aaron Meurer]

Closed #64.

[Aaron Meurer]

Reopened #64.

[Aaron Meurer]

The one off URL button should perhaps be a little less prominent, since it's a bit of a niche feature. I'll think about what a good ui would be. Maybe some way to select inputs from the history.

[David Li]

Perhaps right-align it, and if the console is blank offer up history choices as a combo box? Or perhaps as a list of checkboxes so you can combine multiple statements.

[Ivan Savov]

I don't think we need the "make one off command" button.
I found it counter-intuitive that the button uses the current command line as input, not the full session history which would be expected from a "create a permalink to this session" kind of functionnality.

Perhaps a better UI would be to have a new sidebar item which helps with the escaping.

Create a permalink for this calculation
-->
text field to enter commands  ( tell them to use ; to separate multiple commands) 
(or list of recent commands with checkboxes next to them as prev. suggested)
--> 
escapes ; to %0A, etc.. and then offers the link.

BTW, I am amazed with the quick turn around time for my suggestion. It seems just yesterday I wished for a permalink functionality and BAM! you guys cooked it up in a second. Impressive.

[David Li]

Well ; isn't needed, newlines can be URL-escaped so that's not a problem. Perhaps have the text field automatically populated with the history and then the user can edit it as he/she likes? Note that only the output of the very last statement is shown (it's how SymPy Live works). I suppose it would be possible to run the input line-by-line but that creates problems with multiline statements.

[Ivan Savov]

Perhaps have the text field automatically populated with the history
and then the user can edit it as he/she likes

This is a very good idea (compared to checkboxes)-- I guess you would need a textarea + show entry in shell.history on a separate line.

Not sure how multiline inputs will work. If it were me, I would convert multipline input to single line separated by ; form.

def ax(n):
    a=4
    return a+n

-->

def ax(n): a=4; return a+n

so that we follow the one-command-per-line convention.

Finally, I think the button for this should be attached to the ''sympy-live-output'' div rather than the ''sympy-live-prompt'' since it is the session that is what you want turn into a permalink.

Note that only the output of the very last statement
is shown (it's how SymPy Live works).

That is not exactly the expected behaviour, but should work for 90% of things.
If you want to compare two numbers you can always pring n1,n2 on the last line.

[David Li]

Actually, I suppose we could execute each history item individually, that way intermediate outputs would still be shown as long as the user didn't combine multiple statements into the same input.

Finally, I think the button for this should be attached to the ''sympy-live-output'' div rather than the ''sympy-live-prompt'' since it is the session that is what you want turn into a permalink.

So have a little overlay button in the corner such as "Make URL for session"? That would work. I think keeping it in the toolbar would be more consistent but it really doesn't matter.

[Ivan Savov]

I suppose we could execute each history item individually

That would be the best.

"Make URL for session"? That would work.
I think keeping it in the toolbar would be more consistent but it really doesn't matter.

My thinking was that "session commands" belong close to the session UI, but then again "Clear" and "Full screen" are already down there so you are right that it will be more consistent to have it there, but then again it is not such and important button so let's not make it too prominent.

[David Li]

Updated with your suggestions: http://64.sympy-live-tests.appspot.com/?evaluate=a%20%3D%2030%0A%23--%0Ab%20%3D%2060%0A%23--%0Asin(a%20%2B%20b)%0A%23--%0A(sin(a)*cos(b)%20%2B%20cos(a)*sin(b)).evalf()%0A%23--%0Asin(a%2Bb).evalf()%0A%23--%0A

[Ivan Savov]

http://64.sympy-live-tests.appspot.com/?evaluate=print(%22This%20is%20awesome!%22)%0A%23--%0A

[David Li]

I think you want a
$(history).click( function(event) {
event.stopPropagation();
});
to prevent the modal from closing if you try to edit the commands.

Oops! Good idea. Fixed.

[Aaron Meurer]

Custom URLs don't work in the mobile version.

Other than that, this seems ready to go.

[David Li]

Alright, custom URLs now work in the mobile version: http://64.sympy-live-tests.appspot.com/shellmobile?evaluate=integrate(tan(x))%0A%23--%0A

However, you can't make them in mobile.

[Aaron Meurer]

But shouldn't desktop urls pass through to the mobile version?

[David Li]

Err, apparently they don't. I'll fix that when I can.

[David Li]

Fixed. Sorry that took so long, life intervened.