Opened 9 years ago

Closed 9 years ago

## #13121 closed enhancement (fixed)

Reported by: Owned by: kini jason, mpatel, was major sage-5.4 notebook sagenb jhpalmieri, gutow, jyeo, rbeezer sage-5.4.beta0 Keshav Kini John Palmieri, Jonathan Gutow N/A #11080, #9774, #11913, #12299, #13384

This is a followup to #11080. During the review process of #11080, which stretched for quite a while, at some point we decided to have a feature freeze on the version of sagenb 0.9.x associated with #11080, just to simplify the review process. The purpose of this ticket is to incorporate some new features, bugfixes, code refactoring, etc. into the version of sagenb shipped with Sage, beyond what was reviewed in #11080. sagenb 0.10 contains the following (among other things):

• refactoring of the startup code, uWSGI and Tornado added as possible WSGI servers
• code allowing .sws files to be uploaded by supplying a URL pointing to the .sws as an argument to the upload page's URL
• new dependency on webassets for js/css autominification (not currently used in the master branch)
• the mathjax branch, and a doctest fix in sphinxify.py (#9774 depends on and contributed to this)
• support for uploading .sws files from the local disk via the command line (#8473 basically is this)
• refactoring of sageinspect to not have a duplication of code between the notebook and the Sage library (#11913 depends on this)
• Upgrading Jmol again and allowing for advanced interactive features more easily, solve some memory issues (#12299)
• Remove strict dependency on pyOpenSSL; allow for graceful failure of HTTPS functionality when pyOpenSSL is not installed (#13384 and #13385 coordinate with this)

Changes not in sagenb itself but in how sagenb is incorporated into sage:

• No repository will be installed with sagenb - developers will need to clone sagenb themselves and install the new clone into their Sage installation manually (which is not difficult).

Instructions for installing this and its dependencies into >=sage-5.2.beta0 :



### comment:12 Changed 9 years ago by jhpalmieri

On my Mac (OS X 10.7), I can't get worksheets to actually evaluate anything. With Chrome, Firefox, and Safari, I see an evaluate button, but clicking on it does nothing. Hitting 'shift-enter' either does nothing (Firefox) or gives me a new line in the current cell (Chrome and Safari), and does not evaluate anything. Hitting 'Save & quit' does nothing (Chrome and Safari) or actually quits the current worksheet (Firefox).

I think I see some of the same behavior with 0.9.0, but not as severe: it works in Firefox, but not in Chrome or Safari. I'm not sure about that, though; I'm not sure my 0.9.0 install was clean, or whether I corrupted it with 0.9.1 related things.

Does it matter that there is no directory for this version of sagenb in SAGE_LOCAL/lib/python/site-packages/? After installing 0.9.0 and then 0.9.1, I see

  drwxr-xr-x    4 palmieri  admin    136 Jun 19 11:13 sagenb-0.8.29-py2.7.egg
drwxr-xr-x    4 palmieri  admin    136 Jun 21 16:47 sagenb-0.9.0-py2.7.egg


### comment:13 Changed 9 years ago by kini

I was able to duplicate this on linux. The problem went away when I did a hard refresh of the page, forcing my browser to reload all javascript. The problem is probably caused by this or this.

Does a hard refresh solve the problem on your end too?

### comment:14 Changed 9 years ago by jhpalmieri

A hard refresh helps to get 0.9.0 to work, but not 0.9.1.

By the way, when the notebook is running, how can I tell which version is running? I would suggest having a variable, or displaying it somewhere when the notebook opens.

### comment:15 Changed 9 years ago by kini

• Description modified (diff)
• Status changed from needs_review to needs_work
• Summary changed from Upgrade sagenb to 0.9.1 to Upgrade sagenb to 0.10
• Work issues set to fix js typo, make new spkg

Um, wow. Silly typo in this commit. I'll fix this, and actually I think I'm going to call this 0.10. Our version numbers are moving too slowly. Adding mathjax is a lot more substantial of a change than a bump to the patch level should cause a user to expect.

Last edited 9 years ago by kini (previous) (diff)

### comment:16 Changed 9 years ago by kini

• Summary changed from Upgrade sagenb to 0.10 to Upgrade sagenb to 0.10.0

### comment:17 Changed 9 years ago by kini

• Authors set to Keshav kini
• Description modified (diff)
• Report Upstream changed from Fixed upstream, but not in a stable release. to N/A
• Status changed from needs_work to needs_review
• Work issues fix js typo, make new spkg deleted

OK, new SPKG is up.

By the way, when the notebook is running, how can I tell which version is running? I would suggest having a variable, or displaying it somewhere when the notebook opens.

sagenb.misc.misc.SAGENB_VERSION should tell you that, but it's sort of a hack. I probably could have changed that in the packaging rewrite...

### comment:18 Changed 9 years ago by jhpalmieri

Okay, now a hard refresh is getting everything to work, on all three browsers. Now, is there any way to set it up to avoid the hard refresh? Otherwise users may be frustrated when they first switch to the new notebook.

scripts repo

### comment:19 Changed 9 years ago by jhpalmieri

• Description modified (diff)

I've attached a patch to put "webassets" into the .hgignore file.

### comment:20 Changed 9 years ago by kini

Thanks for the .hgignore patch.

As for avoiding hard refreshes, it might be possible to make Flask set some HTTP headers to the date/time when the server was started, to advise client-side caching. I'm not sure of the details, but it's probably not a one-liner like the typo fix I just made was; I'd also consider it more of a feature than a bugfix, so probably it won't go into 0.10.

### comment:21 Changed 9 years ago by kini

• Authors changed from Keshav kini to Keshav Kini

### comment:22 Changed 9 years ago by kini

(I've set myself as the author since this ticket is just about making an SPKG - there are many more important contributors to the new version of sagenb than me, for the record.)

### comment:23 follow-up: ↓ 28 Changed 9 years ago by jhpalmieri

This is mostly working for me on OS X Lion, except issues with #8473. Otherwise, the spkg looks good to me. People should test it on other platforms.

### comment:24 Changed 9 years ago by jdemeyer

• Priority changed from major to blocker

Any objections to making this a blocker for sage-5.2? It feels to me like sage-0.9.0 is a kind of "beta version" for sage-0.10.0, so I would really prefer to have sage-0.10.0 in the final release.

### comment:25 Changed 9 years ago by jason

Actually, I think of 0.9.0 as sort of the stable, LTS release where we had a *long* feature freeze and concentrated on stability. 0.10.0 is like the release just after LTS stable release, where we merged in a bunch of new functionality that was put off during the long feature freeze. There are some important bugfixes in 0.10.0 (IIRC), but there is a lot of new functionality in 0.10 too.

### comment:26 follow-up: ↓ 27 Changed 9 years ago by jason

That said, I would prefer 0.10 to be in 5.2, but I think it's probably more important to have 0.9 out by the time school starts.

There is still one or two rather frustrating known bugs in 0.9 (and 0.10): some sort of leak where worker processes don't get killed, and sometimes creating a new worksheet actually just gets an old worksheet. If we solve those in 0.10.1 or something, it would be great to have that as our before-semester release.

### comment:27 in reply to: ↑ 26 Changed 9 years ago by kcrisman

That said, I would prefer 0.10 to be in 5.2, but I think it's probably more important to have 0.9 out by the time school starts.

Correct.

### comment:28 in reply to: ↑ 23 ; follow-up: ↓ 29 Changed 9 years ago by kcrisman

This is mostly working for me on OS X Lion, except issues with #8473. Otherwise, the spkg looks good to me. People should test it on other platforms.

Just for reference, this was (or will be, when it's merged) dealt with - see this pull request on sagenb.

### comment:29 in reply to: ↑ 28 Changed 9 years ago by jhpalmieri

This is mostly working for me on OS X Lion, except issues with #8473. Otherwise, the spkg looks good to me. People should test it on other platforms.

Just for reference, this was (or will be, when it's merged) dealt with - see this pull request on sagenb.

Right. Keshav, when you have a chance, could you make a new 0.10.0 spkg for us to test? Any notebook fans: can you positively review the last change at #11080 (the one which allows building on Solaris)?

### comment:30 Changed 9 years ago by kcrisman

To clarify for whoever makes the "final" spkg here - to make sure #8473 is a-ok, we would need this pull request and this one to fix the minor issues John mentioned.

Last edited 9 years ago by kcrisman (previous) (diff)

### comment:31 Changed 9 years ago by jhpalmieri

I'm confused about the location of JMOL. It used to be (before #11080) part of sagenb. Now it isn't (or at least I don't see it anywhere). Does it need to be distributed as a separate spkg, and thus included in spkg/standard/deps? Or should the new JMOL spkg from #12299 be part of this spkg?

Oh, I see: it is now in spkg/standard/deps, and it needs to be included as a separate spkg.

Last edited 9 years ago by jhpalmieri (previous) (diff)

### comment:32 follow-up: ↓ 34 Changed 9 years ago by kini

See #11503, where the deps file is patched to require the new JMOL spkg from #11503. For some reason #12299 seems to require a newer version of the SPKG, a version which is not on #11503 or anywhere else. I posted a comment on #11503 about it.

### comment:33 Changed 9 years ago by jhpalmieri

The spkg here needs work: when it gets installed, SAGE_ROOT/devel may not yet exist. So something like this:

• ## spkg-install

diff --git a/spkg-install b/spkg-install
 a BASENAME=${BASENAME%.tar.gz} #easy_install -H None -f src "sagenb" || die "Error installing sagenb !" # Extract sagenb into$SAGE_ROOT/devel and set up the symlink mkdir -p "$SAGE_ROOT/devel" cd "$SAGE_ROOT/devel" if [ -d "$SAGE_ROOT/devel/sagenb-main" ]; then echo "Moving old SageNB package to '$SAGE_ROOT/devel/sagenb-main-old'..."

### comment:34 in reply to: ↑ 32 Changed 9 years ago by kcrisman

See #11503, where the deps file is patched to require the new JMOL spkg from #11503. For some reason #12299 seems to require a newer version of the SPKG, a version which is not on #11503 or anywhere else. I posted a comment on #11503 about it.

As far as I know, this is on purpose, because the newest Jmol at #12299 needs the many updates to Jmol there. In that sense #11503 is a 'hard' prereq for #11080 and hence this ticket. I am pretty sure Jonathan was careful about exactly which version of Jmol needed to be with which other patches.

### comment:35 Changed 9 years ago by kini

OK, I see, thanks.

### comment:36 Changed 9 years ago by kcrisman

jhpalmieri or others:

When you ran into the problem with the evaluate button not working, did you find that other buttons also stopped working? For instance, the Stop and Archive buttons on the main worksheet list page. I must have done something wrong because even a hard refresh isn't getting things to work for me, but I wanted to ask if anyone had tried those.

### comment:37 follow-up: ↓ 38 Changed 9 years ago by jhpalmieri

For me, on some browsers, everything stopped working. A hard refresh did fix it (Firefox or Chrome: cmd-shift-r. Safari: hold the option key down while hitting the little "refresh" symbol at the right end of the address box).

### comment:38 in reply to: ↑ 37 Changed 9 years ago by kcrisman

For me, on some browsers, everything stopped working.

Ok.

A hard refresh did fix it (Firefox or Chrome: cmd-shift-r. Safari: hold the option key down while hitting the little "refresh" symbol at the right end of the address box).

Yup, that's what I tried, and that didn't work. But like I said on those commits in sagenb, maybe I just destroyed my installation anyway.

Edit: I did finally manage to get the upstream commit of the parenthesis fix in to make it work with the "hard refresh". That definitely needs some big warning somewhere... Strange that doing it "by hand" didn't work, but getting from upstream did.

Last edited 9 years ago by kcrisman (previous) (diff)

### comment:39 Changed 9 years ago by kini

• Description modified (diff)

### comment:40 Changed 9 years ago by jhpalmieri

• Status changed from needs_review to needs_work
• Work issues set to create SAGE_ROOT/devel

### comment:41 Changed 9 years ago by kini

• Description modified (diff)
• Summary changed from Upgrade sagenb to 0.10.0 to Upgrade sagenb to 0.10.x
• Work issues changed from create SAGE_ROOT/devel to wait for 0.10.1

Sorry for the delay, John.

I'm going to release a 0.10.1 with the fixes for #8473 and also hopefully a fix for Jason Yeo's javascript event shuffling (see comments at the bottom of PR #69 on github), so I'm leaving this ticket as needs_work.

### comment:42 Changed 9 years ago by jdemeyer

• Priority changed from blocker to major

### comment:43 Changed 9 years ago by kini

• Description modified (diff)
• Status changed from needs_work to needs_review
• Work issues wait for 0.10.1 deleted

Anything else?

### comment:44 Changed 9 years ago by jhpalmieri

• Reviewers set to John Palmieri
• Status changed from needs_review to positive_review

I think this looks good now. The main parts have already been positively reviewed (as parts of the prerequisite tickets). The spkg-install script is in good shape, as is SPKG.txt. Let's merge it to get MathJax into Sage.

### comment:45 Changed 9 years ago by jdemeyer

• Dependencies changed from #11080, #9774, #8473, #11913, #12299 to #11080, #9774, #11913, #12299

### comment:46 Changed 9 years ago by kcrisman

Probably meaningless, but I do get the following weirdness on OS X PPC when upgrading from 5.2.alpha0 (not beta0!) by using just the latest 0.10.1 spkg.



or similar.

### comment:107 Changed 9 years ago by jdemeyer

• Status changed from needs_work to positive_review

### comment:108 Changed 9 years ago by novoselt

I have just noticed that I cannot stay connected to two notebook servers: both are on the same machine on different ports (usernames and passwords are also different). One is 5.2, another 5.3.rc1+this notebook. When I login to one, another one logs out. This is a bit annoying and such interaction between servers may be dangerous, i.e. now they drop connection because of the other - can there be a situation when logging into one server will trigger logging into another?

### comment:109 Changed 9 years ago by jason

Huh. This sounds like a cookie problem. The cookie should be tied to the port.

### comment:110 Changed 9 years ago by novoselt

Cookie names seem to include the port number.

Also, while it is a bug, I don't think that it should delay this and related tickets: switch to MathJax is awesome for using classroom podium computers, as I have just confirmed ;-)

### comment:111 follow-up: ↓ 127 Changed 9 years ago by jason

I should mention on this ticket, as I mentioned on the mailing list (https://groups.google.com/forum/?fromgroups=#!topic/sage-notebook/sQBBiHygG9E) that a design issue in this version of the notebook really bothers me (and others that have emailed me). Basically, 3d graphs do not show up as jmol instances initially, but always require an extra click to "activate". See the mailing list thread above for discussion, but the end result is that I apply these patches: https://gist.github.com/3527075 to *.sagenb.org and my personal Sage server.

### comment:112 Changed 9 years ago by kini

I fixed the issue Jeroen pointed out, but forgot to mention I had uploaded a new SPKG. Looks like Jeroen noticed it anyway, though :)

### comment:113 Changed 9 years ago by jdemeyer

The current plan is to merge this in sage-5.4.beta0, so it's better not to do any changes anymore (unless serious problems are discovered of course).

### comment:114 follow-up: ↓ 115 Changed 9 years ago by jason

I'm not sure if jdemeyer's comment was answering mine or kini's. As for my comment, I'm happy to just apply the patches I mentioned to *.sagenb.org and my personal servers; I personally don't need them to be in the official notebook. However, I think it's a big regression for those that don't have the patches applied.

### comment:115 in reply to: ↑ 114 ; follow-up: ↓ 116 Changed 9 years ago by jdemeyer

I'm not sure if jdemeyer's comment was answering mine or kini's.

None, I was just making a statement.

However, I think it's a big regression for those that don't have the patches applied.

Then I guess we need to decide whether that issue is serious enough not to merge this and related tickets (my gut feeling is: no, it's not that serious).

### comment:116 in reply to: ↑ 115 Changed 9 years ago by jason

However, I think it's a big regression for those that don't have the patches applied.

Then I guess we need to decide whether that issue is serious enough not to merge this and related tickets (my gut feeling is: no, it's not that serious).

I'll leave that vote to others, as I'm happy to apply the patches reverting the behavior to installs that I administer. I'd suggest, for example, that kini and others try doing an interact that has a slider and a 3d graph and see how smooth of an experience it is. Imagine trying to present something to a class, or trying to change the slider to investigate a property. I think the regression basically makes this use-case unusable.

### comment:117 Changed 9 years ago by kcrisman

I would love the previous behavior as well, but I just want to make sure that Jonathan's concerns are at least partially addressed. Maybe we could raise some kind of warning?

I wish some other people would have commented at the time; we raised this on sage-devel as well as on the relevant ticket, if I recall correctly, and there was little response. I felt like my voice was the only one for the original behavior, and I was very hesitant to override a change due to a technical failing on the vote of one person.

### comment:118 Changed 9 years ago by jason

kcrisman: I realize that I didn't have time to participate as much as I would have liked in the original discussion.

As for a warning---we're just reverting back to original behavior, so I don't think it's any worse than it was before. I agree something needs to be done moving forward, but I don't think we need to raise a warning for continuing the same behavior as before.

### comment:119 Changed 9 years ago by kcrisman

Sorry, by "warning" I meant a warning that using an interact with Jmol over the web (not on a local computer) might lead to horrible massive desynchronization (if I understand the issue correctly).

On the other hand, I haven't used that in production environments yet; maybe it turns out not to be a problem using e.g. *.sagenb.org or your Drake server etc.

### comment:120 Changed 9 years ago by ppurka

The problem with having jmol come up by default was faced by us when we had many jmols in a single page. I had to grade some assignments last year, and it wasn't a pleasant experience. You could be sitting there twiddling your fingers all the while the browser seems completely frozen.

### comment:121 Changed 9 years ago by jason

I have not noticed any problems.

### comment:122 Changed 9 years ago by jason

But the new jmol implementation *will* automatically sleep instances when you reach a certain number, right? So "many jmols on a page" should be fixed, right?

Can you try it on sagenb.org (which has my patch) and see if it is a problem still?

### comment:123 Changed 9 years ago by ppurka

Hmm.. it froze firefox once, but it is otherwise quite smooth now. I forgot about the fact that not all jmols are loaded now. This definitely helps.

### comment:124 Changed 9 years ago by gutow

The old behavior hangs most of the time in interacts for me using anything but a local instance. Thus I still consider the old behavior a bug. For me interacts work faster and more smoothly using the on server image generation. Only if I want to rotate the image do I need to load the applet. The problem seems to be browser/OS/JVM independent so I think it is a network timing issue.

That said, I certainly think it is reasonable for people to want access to the old behavior. I suggest we start a new ticket and develop a good patch that provides a per-worksheet switch that allows one to turn on live Jmol loading in a worksheet. However, I strongly recommend against defaulting to the old behavior, which is broken except under special circumstances on devices that have a reasonably up-to-date JVM installed.

In the meantime, I suggest people who want the old behavior use Jason's patch.

### comment:125 follow-up: ↓ 128 Changed 9 years ago by jhpalmieri

Yes, definitely open up a new ticket. Once this is merged, we will get lots of questions about how to get the old behavior back, and so implementing a solution should have a very high priority.

### comment:126 Changed 9 years ago by jdemeyer

• Merged in set to sage-5.4.beta0
• Resolution set to fixed
• Status changed from positive_review to closed

OK, so this is ready to go?

### comment:127 in reply to: ↑ 111 Changed 9 years ago by kcrisman

OK, so this is ready to go?

As long as Jason and Jonathan can commit to figuring out what to do about this issue, then yes. One would hope that the 5.4 beta sequence would be long enough to accommodate this. The Jmol upgrade is otherwise really worth the effort.

I should mention on this ticket, as I mentioned on the mailing list (https://groups.google.com/forum/?fromgroups=#!topic/sage-notebook/sQBBiHygG9E) that a design issue in this version of the notebook really bothers me (and others that have emailed me). Basically, 3d graphs do not show up as jmol instances initially, but always require an extra click to "activate". See the mailing list thread above for discussion, but the end result is that I apply these patches: https://gist.github.com/3527075 to *.sagenb.org and my personal Sage server.

So *.sagenb.org is running Sage 5.2, but with sagenb 0.10.x? See also 192:ticket:12299 where I predicted this discussion :) On the plus side, this hasn't been merged into a released Sage yet, right?

### comment:128 in reply to: ↑ 125 ; follow-up: ↓ 134 Changed 9 years ago by gutow

Yes, definitely open up a new ticket. Once this is merged, we will get lots of questions about how to get the old behavior back, and so implementing a solution should have a very high priority.

OK, Jason please open a ticket in trac (I'm still getting my feet wet with GIT). Please describe the options you think would be useful to you, remembering that I have not found a way to make live Jmols in interacts reliable over the network without a major rewrite of how interacts work (something I'm not in a position to commit to doing, but think should be done). Personally, I vote for some kind of a switch. Please make sure to cc me on the new ticket.

### comment:129 Changed 9 years ago by novoselt

What will be the behaviour of Sage Cell Server? Will interacts also require clicking a button for interaction every time? Or is it possible perhaps to have a switch between 2D/3D modes which persists over changes of other parameters?

### comment:130 Changed 9 years ago by jason

The cell server will default to live jmol (in fact, that's the only option right now). It doesn't include the advanced functionality Jonathan has put into sagenb.

Last edited 9 years ago by jason (previous) (diff)

### comment:131 follow-up: ↓ 132 Changed 9 years ago by mmarco

When you try to recover a forgotten password in the new notebook, you are asked for the username, and then get the response "invalid username" even if the username is valid, and the email has been confirmed.

I think that the problem is in the file authentication.py

The function forgot_pass() has the following lines:

def forgot_pass():
if not g.notebook.conf()['email']:
return current_app.message('The account recovery system is not active.')

return render_template(os.path.join('html', 'accounts', 'account_recovery.html'))

def error(msg):
return current_app.message(msg, url_for('forgot_pass'))

try:
except KeyError:

if not user.is_email_confirmed():
return error("The e-mail address hasn't been confirmed.")

#XXX: some of this could be factored out into a random passowrd
#function.  There are a few places in admin.py that also use it.
from random import choice
import string
chara = string.letters + string.digits
password = ''.join([choice(chara) for i in range(8)])

from sagenb.notebook.smtpsend import send_mail
# TODO: make this come from the server settings

port = g.notebook.port
try:
except ValueError:
# the email address is invalid



But

    try:


   username = request.values.get('username', '').strip()


### comment:132 in reply to: ↑ 131 Changed 9 years ago by kcrisman

When you try to recover a forgotten password in the new notebook, you are asked for the username, and then get the response "invalid username" even if the username is valid, and the email has been confirmed.

Just fyi to the authors, mmarco has also already opened #13536 to track this, but put this here for more visibility. See this pull request for a pull version of his patch. (@kini - ok, I do like being able to just edit on the fly! Not a convert to github yet, though :) )

### comment:133 Changed 9 years ago by kini

• Description modified (diff)