Problem with installing maxima-jupyter about maxima-jupyter HOT 14 CLOSED

My advice is to build Maxima from source code using SBCL. That is a key preliminary step; after that we can continue with the maxima-jupyter installation.

First uninstall the Maxima package which was installed by apt-get, in order to avoid confusion later.

Obtain a Maxima source tar.gz from the project web site: https://sourceforge.net/projects/maxima/files/Maxima-source/
You can get the most recent (at present 5.42.2) there.

Unpack the tar.gz in some directory, it doesn't matter where. Then set configuration parameters, compile it, and install it.

$ tar xvzf maxima-5.mm.nn.tar.gz
$ cd maxima-5.mm.nn
$ configure --enable-sbcl
$ make
$ sudo make install

At that point try to execute maxima and if that works then try run_testsuite(); and other stuff like that.

If that all works then we'll go from there.

from maxima-jupyter.

Hi, thanks a lot for your interest in maxima-jupyter. Before anything else, may I ask you to tell me the output from build_info(); ? You can just copy and paste the output here.

Some background which will be relevant after I know the output of build_info();. Maxima is written in Common Lisp, and many implementations of Common Lisp create a so-called "binary image" or "image dump" which is essentially a copy of a program as it exists in computer memory. Then that image is loaded into memory and the program is ready to go. Such images must be loaded by some executable; the image itself is not an executable program. So this is somewhat different than, let's say, C programs which are compiled into executables.

The binary image approach makes an incremental form of programming very useful. One can load an image, create new functions and variables, and then save the image again. Now you have an image that contains the new stuff in addition to whatever there was before. This incremental process is the one I have suggested to create maxima-jupyter.

Not all Common Lisp implementations are suitable for maxima-jupyter. In addition to supporting the image dump approach, it is also necessary that the implementation also support POSIX threading. I know that SBCL and Clozure CL can support both requirements. GCL does not support POSIX threads, so it cannot be used for maxima-jupyter.

By the way, Common Lisp is a language with multiple implementations -- SBCL, CCL, GCL, etc. are all implementations of ANSI (standardized) Common Lisp.

Hope this helps. When I hear back from you about build_info(); we'll go from there.

from maxima-jupyter.

Thank you.
The post was very informing for me.
the output of build_info(); command in Maxima:

(%i1) build_info();
(%o1) 
Maxima version: "5.41.0"
Maxima build date: "2018-04-09 18:33:03"
Host type: "x86_64-pc-linux-gnu"
Lisp implementation type: "GNU Common Lisp (GCL)"
Lisp implementation version: "GCL 2.6.12"
(%i2) 

I see that my version is using GCL. How can I fix this?
Thank you very much.

from maxima-jupyter.

Ok.
It is done.

(%i1) build_info();
(%o1) 
Maxima version: "5.42.2"
Maxima build date: "2019-04-15 07:58:24"
Host type: "x86_64-unknown-linux-gnu"
Lisp implementation type: "SBCL"
Lisp implementation version: "1.4.5.debian"

run_testsuit(); is passed. No unexpected errors found out of 11,591 tests.
and maxima works fine.

from maxima-jupyter.

Terrific. So far, so good. At this point I think the next step you must carry out is to install Quicklisp. Please take a look at https://www.quicklisp.org/beta/ and follow the instructions there.
When you have Quicklisp installed, then you can go back to the maxima-jupyter installation instructions and continue there.

from maxima-jupyter.

Ok. With the second method, I managed to install the maxima-jupyter. Thank you very much for this useful step by step help. Just one other thing.
When I was installing the maxima and sbcl and other stuff. I did all these stuff with the root user. the maxima and sbcl work for other users as well. jupyter kernelspec list shows maxima as a kernel for jupyter as well but the jupyter console --kernel=maxima has this error on other users except root:

While evaluating the form starting at line 11, column 0
Maxima encountered a Lisp error:

 The file "/usr/local/maxima-jupyter/system-index.txt" is not writable.

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
  of #P"/usr/local/maxima-jupyter/load-maxima-jupyter.lisp":
While evaluating the form starting at line 11, column 0
  of #P"/usr/local/maxima-jupyter/load-maxima-jupyter.lisp":

debugger invoked on a SB-INT:SIMPLE-CONTROL-ERROR in thread
#<THREAD "main thread" RUNNING {10006305B3}>:
  attempt to THROW to a tag that does not exist: RETURN-FROM-DEBUGGER

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file "/usr/local/maxima-jupyter/load-maxima-jupyter.lisp".
  2: [ABORT   ] Abort loading file "/usr/local/maxima-jupyter/load-maxima-jupyter.lisp".
  3:            Ignore runtime option --eval "(cl-user::run)".
  4:            Skip rest of --eval and --load options.
  5:            Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT    ] Exit SBCL (calling #'EXIT, killing the process).

(SB-C:UNWIND)
0] 
(%i1) jupyter_kernel_start("/home/alireza/.local/share/jupyter/runtime/kernel-14141.json")
Traceback (most recent call last):
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/ptshell.py", line 323, in init_kernel_info
    reply = self.client.get_shell_msg(timeout=1)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_client/client.py", line 77, in get_shell_msg
    return self.shell_channel.get_msg(*args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_client/blocking/channels.py", line 57, in get_msg
    raise Empty
_queue.Empty

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/anaconda3/bin/jupyter-console", line 11, in <module>
    sys.exit(main())
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_core/application.py", line 266, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/traitlets/config/application.py", line 657, in launch_instance
    app.initialize(argv)
  File "<decorator-gen-116>", line 2, in initialize
  File "/usr/local/anaconda3/lib/python3.7/site-packages/traitlets/config/application.py", line 87, in catch_config_error
    return method(app, *args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/app.py", line 141, in initialize
    self.init_shell()
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/app.py", line 114, in init_shell
    client=self.kernel_client,
  File "/usr/local/anaconda3/lib/python3.7/site-packages/traitlets/config/configurable.py", line 412, in instance
    inst = cls(*args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/ptshell.py", line 272, in __init__
    self.init_kernel_info()
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/ptshell.py", line 326, in init_kernel_info
    raise RuntimeError("Kernel didn't respond to kernel_info_request")
RuntimeError: Kernel didn't respond to kernel_info_request

if I give the write permission to the /usr/local/maxima-jupyter/system-index.txt the error changes to this:

While evaluating the form starting at line 11, column 0
Maxima encountered a Lisp error:

 Failed to find the TRUENAME of /root/quicklisp/local-projects/:
   Permission denied

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
  of #P"/usr/local/maxima-jupyter/load-maxima-jupyter.lisp":
While evaluating the form starting at line 11, column 0
  of #P"/usr/local/maxima-jupyter/load-maxima-jupyter.lisp":

debugger invoked on a SB-INT:SIMPLE-CONTROL-ERROR in thread
#<THREAD "main thread" RUNNING {10006305B3}>:
  attempt to THROW to a tag that does not exist: RETURN-FROM-DEBUGGER

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file "/usr/local/maxima-jupyter/load-maxima-jupyter.lisp".
  2: [ABORT   ] Abort loading file "/usr/local/maxima-jupyter/load-maxima-jupyter.lisp".
  3:            Ignore runtime option --eval "(cl-user::run)".
  4:            Skip rest of --eval and --load options.
  5:            Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT    ] Exit SBCL (calling #'EXIT, killing the process).

(SB-C:UNWIND)
0] 
(%i1) jupyter_kernel_start("/home/alireza/.local/share/jupyter/runtime/kernel-14173.json")
Traceback (most recent call last):
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/ptshell.py", line 323, in init_kernel_info
    reply = self.client.get_shell_msg(timeout=1)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_client/client.py", line 77, in get_shell_msg
    return self.shell_channel.get_msg(*args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_client/blocking/channels.py", line 57, in get_msg
    raise Empty
_queue.Empty

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/anaconda3/bin/jupyter-console", line 11, in <module>
    sys.exit(main())
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_core/application.py", line 266, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/traitlets/config/application.py", line 657, in launch_instance
    app.initialize(argv)
  File "<decorator-gen-116>", line 2, in initialize
  File "/usr/local/anaconda3/lib/python3.7/site-packages/traitlets/config/application.py", line 87, in catch_config_error
    return method(app, *args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/app.py", line 141, in initialize
    self.init_shell()
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/app.py", line 114, in init_shell
    client=self.kernel_client,
  File "/usr/local/anaconda3/lib/python3.7/site-packages/traitlets/config/configurable.py", line 412, in instance
    inst = cls(*args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/ptshell.py", line 272, in __init__
    self.init_kernel_info()
  File "/usr/local/anaconda3/lib/python3.7/site-packages/jupyter_console/ptshell.py", line 326, in init_kernel_info
    raise RuntimeError("Kernel didn't respond to kernel_info_request")
RuntimeError: Kernel didn't respond to kernel_info_request

I know that is too much to ask, but do you know How can I fix this problem?

Thank you very much for the help.

from maxima-jupyter.

It appears that installing as root is broken because the changes to load-maxima-jupyter.lisp in #46. I am personally not really a fan of installing as root since quicklisp only installs files on a per user basis. This means that a root install may have references to the root user's quicklisp installation.

Maybe you should try installing the Jupyter kernel as a user using the '--user' flag. Just a thought.

@robert-dodier FYI I'm still looking at the details of user vs root installations as part of the updates to common-lisp-jupyter installation.

from maxima-jupyter.

with the --user flag the error remains the same.

from maxima-jupyter.

Sorry for not being more clear, but you need to remove any existing installations first. The system installation is probably in /usr/share/jupyter/kernels/maxima or /usr/local/share/jupyter/kernels/maxima. In either case just delete the maxima folder and all of its contents. More details about where the kernel files are located is here. You may consider removing the user kernel in ~/.local/share/jupyter/kernels/maxima also.

After the system is all cleaned up then execute the following in your local user account in the maxima-jupyter directory.

python3 ./install-maxima-jupyter.py --root=`pwd` --user

from maxima-jupyter.

Yes, I know that. The problem wasn't the kernel. the problem was the Quicklisp. for every user, it should be installed separately and then it is necessary to install the kernel with the --user flag.
By the way, Thank you very much for your help and support. You have done a very good job, making maxima-jupyter so good.
The root installation is really necessary for multi-user uses. For example, I have a JupyterLab configuration with many different languages (e.g. Julia, Matlab, octave, python, bash, Scilab, latex, etc) each time there is a different class of students who should use these programs and languages. Imagine how hard it will be to install and config the Quicklisp and maxima-jupyter kernel for each one of them manually.

I look forward to hearing from you if you have any suggestion for me solving this problem.

The main problem I think the contents of ~/quicklisp directory. is it a way to set the Quicklisp settings once for all users? I think this may solve the problem.

from maxima-jupyter.

Okay, I've got a few ideas on how to do this. I am hoping that Quicklisp bundles will work. Once I get it to work in common-lisp-jupyter I'll see what Robert thinks of it in the context of Maxima-Jupyter.

from maxima-jupyter.

Hi, thanks to everybody for working on this problem. I'm having trouble understanding what is the central problem here. Can someone else explain why Quicklisp is an issue here? I am imagining that Quicklisp, and anything loaded by Quicklisp, will be present in the Maxima image. Maybe I have misunderstood how maxima-jupyter is being installed.

from maxima-jupyter.

I think that there are several issues going on here. I'll try to explain what I see from my perspective.

In #46 I changed the loading mechanism from using asdf:*central-registry* to using ql:*local-project-directories*. For a user based kernel installation this is fine, but it appears to have broken system-wide kernel installations because /usr/local/maxima-jupyter/system-index.txt is only writable by root. (Quicklisp uses this as the ASD system index).

To fix this we can revert this change, but I think that this is just fixing the symptom and not really the core issue. Basically, I don't think we should be using Quicklisp in system-wide installations.

First consider a system-wide installation that is not image based. If we put the the Maxima-Jupyter files in /usr/share/maxima-jupyter and have the kernel spec file load from there then each user that tries to access the kernel will have to have quicklisp setup before they run the kernel. The support libraries (babel, ironclad, etc) will be installed on a user specific basis into ~/quicklisp. This is because Quicklisp doesn't have a concept of a system-wide library.

Second consider a system-wide installation that is based on an image. That image will be generated in the Quicklisp environment for a specific user. This means that references to ~/quicklisp will be preserved in the image. Furthermore, if the root user creates the the kernel image then there will be references to /home/root/quicklisp in the kernel.
In either of these cases, Quicklisp will only be functional if the image is loaded by the user who created it. The Maxima-Jupyter kernel will still work, but if the user tries to use ql:quickload it probably won't work.

I am hoping that the solution to all of these issues is to use Quicklisp's ql:bundle-systems to create a Quicklisp independent bundle of dependencies for system-wide installations. For non-image based kernels we just dump the bundle into /usr/share/maxima-jupyter. For image based kernels we generate the bundle, then re-run Maxima, load the bundle and dump the image. In either case the resulting kernel won't have any references to a user based Quicklisp and will work even if the user has not installed Quicklisp.

For user based kernels nothing would change. We keep using Quicklisp.

from maxima-jupyter.

Closing this issue since OP's problems seem to have been resolved. I've moved the final comment to a new thread: #86

from maxima-jupyter.