3d graphs not interactive initially

[Jason Grout]

Is there an easy way to set the new JMOL from #13121 up so that 3d
graphs come up immediately, rather than having to click on a button
every time?

Thanks,

Jason

[kcrisman]

On Wednesday, August 29, 2012 12:55:55 PM UTC-4, Jason Grout wrote:

Is there an easy way to set the new JMOL from #13121 up so that 3d
graphs come up immediately, rather than having to click on a button
every time?

See the very long discussion there for why Jonathan decided not to do that, and several of us agreed to let him not do that :)

Basically, there are applet loading issues.  I defer to his technical expertise, even though I definitely agree with you that this is not ideal behavior.  I don't think there was a clear switch to turn it off (yet).

[Jason Grout]

I remember lots of discussions. As I remember it, there were several
main points:

1. people that don't have java will now be able to see the plots

2. we can fit lots of java applets on a page (like more than 10)


Now that I've been using it for a short while, I find it, definitely
less than ideal to have the default be the static image. It means that
every time I have a 3d plot, I now have to break my concentration to
click "make interactive". This is really much worse when doing an
interact, where you're just trying to drag a slider to explore some
situations. Every single time you drag the slider, you have to click to
make it interactive again.

I didn't realize how I would feel about it until I've been trying to use
it now. I guess now I have an opinion about it :).

Can we make the default be the jmol image again? People who don't have
java can click the "sleep" button, which means they now get to see the
picture, so it's a net gain for them. And people that have java will
have all the wonderful goodness the patch gives without the
interactivity negative. As for (2)---I think Jonathan programmed that
rather sophisticated system to automatically sleep applets if there were
too many, so I don't see that as an issue. Am I missing anything?

I (now) feel strongly enough about this that I'll even submit a patch to
change the default back to the java applet :), and I'll probably apply
that patch to *.sagenb.org. I've also had other people email me about
how it is hurting their productivity in the classroom.

Thanks,

Jason

[Gutow, Jonathan H]

We are working on this in the Jmol community right now. I hope we will have a more elegant solution by next Spring. Presently the issue is that when you don't start with a static image devices that do not support Java get nothing. This way they get a static image. We are working on device detection and a somewhat less capable javascript renderer that could run on devices that don't support Java. For those of you who've played around with some of this stuff, one of the pieces we are looking at is three.js. There's a lot of other ancillaries to get similar capabilities to Jmol, but we think we can split things between server side and user side calculations in a way that will give similar, if not as extensive and responsive capabilities.

In the meantime, I will look a little more into an optional switch. It would have to be worksheet or user specific, since the issue is the users device.

Jonathan

> --
> You received this message because you are subscribed to the Google Groups "sage-notebook" group.
> Visit this group at http://groups.google.com/group/sage-notebook?hl=en-US.
>
>

Dr. Jonathan H. Gutow
Chemistry Department gu...@uwosh.edu
UW-Oshkosh Office:920-424-1326
800 Algoma Boulevard FAX:920-424-2042
Oshkosh, WI 54901
http://www.uwosh.edu/facstaff/gutow/

[Jason Grout]

On 8/29/12 2:24 PM, Gutow, Jonathan H wrote:
> We are working on this in the Jmol community right now. I hope we
> will have a more elegant solution by next Spring. Presently the
> issue is that when you don't start with a static image devices that
> do not support Java get nothing. This way they get a static image.

They won't even see a "Make it sleep" or similar button, which switches
over to the jpg/png?

> We are working on device detection and a somewhat less capable
> javascript renderer that could run on devices that don't support
> Java. For those of you who've played around with some of this stuff,
> one of the pieces we are looking at is three.js. There's a lot of
> other ancillaries to get similar capabilities to Jmol, but we think
> we can split things between server side and user side calculations in
> a way that will give similar, if not as extensive and responsive
> capabilities.

Wow, awesome! That would be cool to have a webgl frontend to jmol!

> In the meantime, I will look a little more into an optional switch.
> It would have to be worksheet or user specific, since the issue is
> the users device.

That makes sense. I'll see how easy it is to switch sagenb.org back to
having a png by default, and wait for the switch so that we don't have a
regression for the users that do depend on the jmol coming up right away.

Thanks for all of you work and long hours on this!

Jason

[Gutow, Jonathan H]

Jason,

Please do not patch this to make Jmol live in interacts by default! One of the major reasons I did this was because of what happens with interacts that are being served over a network connection that is not very zippy. The problem is that interacts fire off recalculations and launch completely new Jmols every time anything is adjusted. This can cause browsers to be trying to load multiple applets in the same place and can cause serious hangs and crashes.

Again we should consider making Jmol live in interacts an option, but making it the default is dangerous.

The proper solution is to rewrite the notebook so that applets are not disposed of unless the input cell that generates them no-longer calls for an applet. Then rather than relaunching the applet we would only send a small string of commands to read in the recalculated file. I've looked into this a little, but it will require some significant work to do it correctly. My initial idea is that applets should have a separate div from the html_output div's. That are deleted more selectively. This would also make embedding Geobra easier.

Jonathan

[Jason Grout]

On 8/29/12 2:37 PM, Gutow, Jonathan H wrote:
> Jason,
>
> Please do not patch this to make Jmol live in interacts by default!
> One of the major reasons I did this was because of what happens with
> interacts that are being served over a network connection that is not
> very zippy. The problem is that interacts fire off recalculations
> and launch completely new Jmols every time anything is adjusted.
> This can cause browsers to be trying to load multiple applets in the
> same place and can cause serious hangs and crashes.
>
> Again we should consider making Jmol live in interacts an option, but
> making it the default is dangerous.
>
> The proper solution is to rewrite the notebook so that applets are
> not disposed of unless the input cell that generates them no-longer
> calls for an applet. Then rather than relaunching the applet we
> would only send a small string of commands to read in the
> recalculated file. I've looked into this a little, but it will
> require some significant work to do it correctly. My initial idea is
> that applets should have a separate div from the html_output div's.
> That are deleted more selectively. This would also make embedding
> Geobra easier.
>

It sounds like it's not really a problem for non-interact cells to
enable live applets by default. Generally, a user won't be evaluating
that cell once a second or whatever. Are we agreed with that?

Having non-interactive 3d plots by default, at least for me,
significantly cuts into the user experience of 3d graphs in interacts.
I still feel like we need to find some other solution.

I guess I never personally noticed a problem with crashing or hanging
because of rapid interact updates. It would slow down, sure, but that
was about it. I've been testing from (comparatively slow) DSL and also
a faster school connection.

Part of the problem with having outputs separate from applet divs are:

1. a change in the interact might really want to delete the applet. I
have several applets like that where a checkbox will delete the 3d graph

2. you lose the ability to nicely intertwine 3d graphs and other output

But how about something like what you suggest above? Each page has a
pool of jmol instances. When the output of a cell calls for a jmol, one
of the applets is relocated in the DOM to be in the correct place in the
cell output and reloaded with the script. When a script goes to sleep
or when output is deleted, the jmol instance is contributed back to the
pool. The pool can dynamically resize (so it can start out with 0
instances, and increase as instances are generated, up to a maximum
size). I guess bonus points if JMOL instances can update the pool with
the last time they were interacted with, so we can intelligently know
where to snatch new instances if the pool becomes empty.

What do you think of that? I guess it's pretty much your idea above
(though I may have gotten it wrong...)

Thanks,

Jason

[William Stein]

I've barely read this thread, but on the public servers (e.g.,
uw.sagenb.org), the static image is broken! See attached
screenshot...

> --
> You received this message because you are subscribed to the Google Groups
> "sage-notebook" group.
> Visit this group at http://groups.google.com/group/sage-notebook?hl=en-US.
>
>

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Jason Grout]

On 8/29/12 3:14 PM, William Stein wrote:
> I've barely read this thread, but on the public servers (e.g.,
> uw.sagenb.org), the static image is broken! See attached
> screenshot...

Ouch. I bet it has to do with the error:

(.:9224): Gtk-WARNING **: cannot open display:


Jonathan: any idea about what the error means? Why would Gtk be
complaining?

Thanks,

Jason

[Jason Grout]

Some searches reveal:

http://stackoverflow.com/questions/11796905/java-application-throws-gtk-warning-cannot-open-display-even-when-xserver

http://pd4ml.com/support/pdf-generation-troubleshooting-f4/gtk-warning-cannot-open-display-t62.html
-- seems to indicate there is a command line switch or possibly a
version upgrade would take care of it. It looks like you're actually
using -Djava.awt.headless=true, so maybe the problem is that we have GNU
jdk installed, and it's old as well.

Thanks,

Jason

[Jason Grout]

So given that the jvm apparently doesn't work on mod.math, I put in a
temporary patch to revert back to old behavior. I'll restart later
tonight to make it live.

But Jonathan, you're right that we should fix the underlying issue of
lots of applets getting started and killed. I like the idea of using a
pool and moving the applets around to where we need them.

Thanks,

Jason

[Gutow, Jonathan H]

Ouch! is correct. That error implies that something is really wrong with the version of the jmol.spkg you are using. That error used to occur using an old version of the headless application to server images. Which version is installed? The installed version is looking for an XWindows server. It shouldn't be, and shouldn't need it. If you are using the properly up-to-date versions this does not occur. I routinely run my sage server on a machine without any GUI inside a screen session and do not see this. Very odd...

Jonathan

> --
> You received this message because you are subscribed to the Google Groups "sage-notebook" group.
> Visit this group at http://groups.google.com/group/sage-notebook?hl=en-US.
>
>

[Gutow, Jonathan H]

On Aug 29, 2012, at 5:54 PM, Jason Grout wrote:

> So given that the jvm apparently doesn't work on mod.math, I put in a temporary patch to revert back to old behavior. I'll restart later tonight to make it live.

I don't think it is a jvm problem...I think something is wrong with the Jmol version you installed.

>
> But Jonathan, you're right that we should fix the underlying issue of lots of applets getting started and killed. I like the idea of using a pool and moving the applets around to where we need them.

This is a potentially workable idea. Let me think about implementation. This is slightly different than what I presently do, but not hugely different. It might also improve performance because you would only have to load new Jmols until you got to the maximum of 4-5 open Jmol applets.

The issue is that we would have to be careful about how things are passed from the server....I'm liking this idea, but may not have much time to work on it for a week or so...Semester is starting:). If somebody else has time to try this before then, go ahead.

Jonathan

[Samuel]

I agree with Jonathan. Automatically loading java applets in cell output is a bad idea because automatic loading would completely destroy all 3D outputs for any client which doesn't have java installed (eg. mobile). Secondly, the applet initiation process is slow. This is no fault of Jmol -- it's to be expected when loading any applet.

When interaction is involved, it's even worse. Every update results in a completely new applet. That would seriously impede the responsiveness of interacts which, ironically, is the entire point behind interacts.

Jonathan, I like your idea of only transmitting the necessary data to replace the graph within the same applet. As you say, this would require some changes to interaction but the fact is, all of interact should be done that way. Currently every interact evaluation involves building the HTML for the entire interact. The correct approach would be to transmit every update as a JSON and let the front-end render all of the controls and outputs.

The idea of recycling Jmol instances seems like poor form to me. I think it would make more sense to have a Jmol manager which activates/deactivates Jmol instances as necessary. In my rewrite of the Notebook front-end, I actually created a JavaScript "class" for Jmol instances but did not go as far as to create a manager. My code may not be copy-paste reusable into the Jmol library but with that approach I believe it would be a small step to create a manager class and hook things up correctly. You can see my work here: https://github.com/samuela/sagenb/blob/master/sagenb/data/sage/js/jmol.js

Samuel

[Jason Grout]

On 8/29/12 7:16 PM, Gutow, Jonathan H wrote:
> Ouch! is correct. That error implies that something is really wrong
> with the version of the jmol.spkg you are using. That error used to
> occur using an old version of the headless application to server
> images. Which version is installed? The installed version is
> looking for an XWindows server. It shouldn't be, and shouldn't need
> it. If you are using the properly up-to-date versions this does not
> occur. I routinely run my sage server on a machine without any GUI
> inside a screen session and do not see this. Very odd...

It's version 12.3.27. But the server is running java "1.5.0"
gij (GNU libgcj) version 4.2.4 (Ubuntu 4.2.4-1ubuntu3). Maybe that is
too old? Or more likely, it's not the sun jdk, and apparently the gnu
jdk has had problems supporting that headless option.

So maybe it's as simple as installing the sun jdk. But that's a
system-wide change I'd rather a more involved system admin make (you
might say it's above my pay grade, meaning I'm out of my depth in
dealing with the fallout of switching java versions :).

Thanks,

Jason

[Gutow, Jonathan H]

It might be the gnu jdk. I'd have to dig a little to check that. I know it works on my machines with the newer versions that go with linux installs in the last 6 months. You do seem to have the correct version of Jmol. Are you sure you got the .spkg with the patch that uses the -D..headless... option in the java call? I seem to remember that I lost it in one of the .spkg versions and had to make a new one.

Jonathan

[Jason Grout]

On 8/29/12 9:44 PM, Gutow, Jonathan H wrote:
> It might be the gnu jdk. I'd have to dig a little to check that. I
> know it works on my machines with the newer versions that go with
> linux installs in the last 6 months. You do seem to have the correct
> version of Jmol. Are you sure you got the .spkg with the patch that
> uses the -D..headless... option in the java call? I seem to remember
> that I lost it in one of the .spkg versions and had to make a new
> one.
>

Yes. When I wrote that, I was reading the source on mod.

Thanks,

Jason

[Gutow, Jonathan H]

Actually looking back, I put checks in and jvm 1.5 should work. If the jvm version is incompatible the code should throw an error about the jvm version. I'm really not sure what is going on. I'm trying to duplicate your problem. I'm in the process of building a VM to do the test on.

Jonathan

[Jason Grout]

On 8/30/12 6:44 AM, Gutow, Jonathan H wrote:
> Actually looking back, I put checks in and jvm 1.5 should work. If the jvm version is incompatible the code should throw an error about the jvm version. I'm really not sure what is going on. I'm trying to duplicate your problem. I'm in the process of building a VM to do the test on.
>

The check passed on mod, IIRC. It seems like the check just ran a
command, but didn't check the output of the command i.e., that the
command produced a valid file. Is that maybe the problem?

FYI, the patch I applied to mod was https://gist.github.com/3527075

Thanks,

Jason

[Gutow, Jonathan H]

It will take me a while to sort out the GIT stuff. I'm still learning that. The patch you link below does not include the code that checks for JVM compatibility. That code runs a system script that does the checking. Presently it returns an error code if the jvm is not compatible. The script is in the jmol spkg, so would not be changed by changes to jmoldata.py, unless the code doesn't call the script anymore.

I've been testing using the spkgs from trac. That may be were the problem lies. I'm on the road today, but hope to have double checked this by the end of today.

Jonathan

[Jason Grout]

On 8/30/12 8:17 AM, Gutow, Jonathan H wrote:
> It will take me a while to sort out the GIT stuff. I'm still
> learning that. The patch you link below does not include the code
> that checks for JVM compatibility. That code runs a system script
> that does the checking. Presently it returns an error code if the
> jvm is not compatible. The script is in the jmol spkg, so would not
> be changed by changes to jmoldata.py, unless the code doesn't call
> the script anymore.

The sage library patch immediately returns False from the check
condition, rather than running the system test. The system test was
returning True, though. So right now, my patch skips the check.

It sounds like, from my brief online searching, the problem was that the
gnu jdk doesn't recognize the headless option.

Thanks,

Jason

[Jason Grout]

On 8/29/12 8:14 PM, Samuel wrote:
> The idea of recycling Jmol instances seems like poor form to me. I think
> it would make more sense to have a Jmol manager which
> activates/deactivates Jmol instances as necessary. In my rewrite of the
> Notebook front-end, I actually created a JavaScript "class" for Jmol
> instances but did not go as far as to create a manager. My code may not
> be copy-paste reusable into the Jmol library but with that approach I
> believe it would be a small step to create a manager class and hook
> things up correctly. You can see my work
> here: https://github.com/samuela/sagenb/blob/master/sagenb/data/sage/js/jmol.js
>

Isn't that basically what I was saying? Have some way of managing a
pool of jmol instances. The reason for a pool is to prevent there from
being too many jmol instances open at once, since we've had big memory
problems from too many applets on the page. We have to do some sort of
memory management/recycling for java here.

On the other hand, Jonathan---did the memory problem go away when we
hide (versus destroyed) the applets? In other words, if I'm running out
of Java memory, and I hide all the applets, does that free up the java
memory? I don't think it does, but it seems like someone tested this a
long time ago. If merely hiding an applet clears its claim on memory,
then sure, recycling instances seems to be too much work.

What I had in mind is that a cell, when it wanted a jmol instance, would
ask the jmol manager for an instance and give the manager a DOM element
in which to put the applet. The manager would see if it had any
available instances, and if not, create a new applet and stick it in the
right spot.

Then, before a cell deleted its output, it would "free" the jmol
instance by calling the manager. The manager would move the applet out
of the cell's output region, clear the jmol data, and hide the applet
somewhere. The manager would consider this instance an available instance.

In the case that the manager had reached some set number of active
instances (or even better, when it realized the java memory was running
low), it could forcibly get the longest-idle instance (it'd have to keep
track of that somehow). The manager would sleep the instance, reclaim
the applet, and give it to the requesting cell.

Thanks,

Jason

[Gutow, Jonathan H]

OK, I got my noGUI server running (Ubuntu 12.04, OpenJDK-6 (jvm 1.6), Sage-5.2, sagenb 0.10 as per trac 13121 [http://trac.sagemath.org/sage_trac/ticket/13121]). I see no problems with image generation. It must be the jre environment on the mod.math.

However, I see another problem using the install of sagenb 0.10.x as per trac into 5.2. Now the "evaluate" button does not always work. I seem to recall a problem that was supposed to be fixed earlier. This seems a bit more intermittent. Now it never works if there is not a cell below the one you want to evaluate and even sometimes when there is. The <shift>-<enter> still works to cause evaluation reliably. Anybody know what is going on here?

I also still had to install the openssl spkg to get things to work. Does that mean the updates to accommodate no openssl are not in the ticket? I could pull things from git, but I would like to see things work on trac as that is how releases are built.

Jonathan

[Keshav Kini]

"Gutow, Jonathan H" <gu...@uwosh.edu> writes:

> OK, I got my noGUI server running (Ubuntu 12.04, OpenJDK-6 (jvm 1.6), Sage-5.2, sagenb 0.10 as per trac 13121 [http://trac.sagemath.org/sage_trac/ticket/13121]). I see no problems with image generation. It must be the jre environment on the mod.math.
>
> However, I see another problem using the install of sagenb 0.10.x as
> per trac into 5.2. Now the "evaluate" button does not always work. I
> seem to recall a problem that was supposed to be fixed earlier. This
> seems a bit more intermittent. Now it never works if there is not a
> cell below the one you want to evaluate and even sometimes when there
> is. The <shift>-<enter> still works to cause evaluation reliably.
> Anybody know what is going on here?

There was still something broken in 0.10.1. I just released 0.10.2 and
put the SPKG on the ticket. Can you try that?

> I also still had to install the openssl spkg to get things to work. Does that mean the updates to accommodate no openssl are not in the ticket? I could pull things from git, but I would like to see things work on trac as that is how releases are built.

The OpenSSL dependency is dropped in 0.10.2.

-Keshav

----
Join us in #sagemath on irc.freenode.net !

[Jonathan Gutow]

It will take a while to devise a new more robust scheme for interacts.

In the meantime, we need to allow people to turn on loading Jmol by default rather than an image.  I need somebody who wants a switch added to start a ticket and describe how they want the switch to work for the user.  My general thought would be a switch at the top of the worksheet like the "Typeset" checkbox that says something like "Load 3-D graphs live (do not use on non-Java capable systems or in interacts over slow connections)".

Someone who wants behavior along these lines please open a ticket where you describe what you would like on trac.  Please make sure to cc me on the ticket (trac username: gutow)

Thanks,

Jonathan