Nixpkgs: sagemath8.6 inotebook cannot load jmol

[ghasshee]

Issue description

in sage interpreter, it can call jmol correctly.
But in inotebook mode, it does not.

Steps to reproduce

open browser inotebook with :

sage -inotebook

Then create new sheet and
copy paste and run :

x,y,z = var('x,y,z')
f = x^3-x*z^2+y^2*z
g = x^2+y^2+z^2-1
implicit_plot3d(g*f,(x,-1,1),(y,-1,1),(z,-1,1))

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

• system: "x86_64-linux"
• host os: Linux 5.1.5, NixOS, 19.03.172765.55df3fe5f3f (Koi)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.2.2
• channels(ghasshee): "nixos-19.03.172765.55df3fe5f3f, nixpkgs-19.03pre161900.61c3169a0e1"
• channels(root): "nixos-19.03"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

[FRidh]

cc @timokau

[timokau]

Apparently the legacy sage notebook has some special handling for jmol, which probably needs patching (probably tries to run a java applet in the browser? I have no experience with such things).

However since that notebook is deprecated and jmol is out of favor too, I'm not willing to invest much time into fixing this. I'll support you if you try to fix it yourself, but I suggest you try using the ipython notebook and threejs instead.

[ghasshee]

@timokau
Thank you for the clarification.
Would you give me the way how to install threejs into /nix/store/ as the sage environment?

[timokau]

Its supposed to be included by default, but it didn't work. The interactive parts of sage are a bit under-tested (while everything else is over-tested). https://github.com/NixOS/nixpkgs/pull/63375 will fix that. Backport in https://github.com/NixOS/nixpkgs/pull/63376.

[timokau]

The fix should now be in the 19.03 binary channel. Can you confirm it works for you?

[ghasshee]

It showed only the cubical skelton of 3-dimensional space and its parameters, but did not show the graph,
with this code;

sage: parametric_plot3d([cos(x),sin(x),x/10], (x,0,4*pi), color='red', viewer='threejs')

Does it mean that it has worked correctly as a test?

[timokau]

I don't know how it should behave. @paulmasson as you know much more about the threejs backend, would you mind commenting? Does this sound like correct behaviour?

[paulmasson]

@timokau that is not the correct behavior. It sounds like the backward incompatibility introduced in r91 of Three.js. This will be fixed in Sage 8.8 which is due for release in the next couple weeks.

When I wrote the Three.js backend it never occurred to me that distributions would separately download a newer version of the library. One solution is to keep the Sage version up to date, but I'd like to understand why a distribution overrides the Sage default. This is not the first time it's come up and prompted the upgrade to r100.

[timokau]

Thank you, that is very helpful! I'm backporting the threejs r91 ticket to sage 8.6 (https://github.com/NixOS/nixpkgs/pull/63561, in our latest stable release) and sage 8.7 (https://github.com/NixOS/nixpkgs/pull/63560, our unstable). Seems to be working. While I'm at it I also noticed that the cdn wasn't working properly, so I included a hotfix for that until https://trac.sagemath.org/ticket/26434 is resolved.

So as soon as those two PRs are merged (and built by hydra if you rely on the binary channels) offline and online threejs should work properly.

[timokau]

I'd like to understand why a distribution overrides the Sage default

Distributions usually aren't using sages build system for several reasons. A few of them are:

• hard to make the build system work properly and interact with the system packages reliably
• would create a very bloated package with lots of duplication (sage having its own version of gcc, python etc. while the user will still have system versions of them installed)
• we would rely on sage to keep dependencies up to date and secure

Its the whole point of a package manager to easily install packages and manage dependencies. It shouldn't be sages job to do that. The sage build system is fine as a sort of "reference implementation" / common ground for sage developers, but shouldn't be the default for end users. If it was my decision, I'd even remove it completely and instead use one of the package managers as the common ground.

Since we do not use the sage build system, we need to provide our own threejs version. That version is expected to be usable by other packages too (the reason for https://trac.sagemath.org/ticket/28007) and is kept up to date (for various reasons: security, features and simple practicality since the node package set is updated automatically).

For compatibility with newer dependencies, we usually backport the appropriate sage tickets to older sage versions. Its usually obvious when to do that (since the sage test suite will fail), its just problematic in this case since visual stuff is hard to test automatically.

[timokau]

The fix is in the 19.03 binary channel. Please retest.

[ghasshee]

Wow, it did! Thank you for the fix and open discussions !

[timokau]

Happy I could help :)