Problem with installing maxima-jupyter
Closed this issue · 14 comments
Hello,
I have an Ubuntu 18.04.1 system, Jupiter version 4.4.0, Jupiter notebook version 5.7.4 python version 3.7.1 and libczmq-dev is also available. I use Jupiter notebook as a part of JupyterLab.
I've installed the maxima using sudo apt install maxima. The installed version is
$ maxima --version
Maxima 5.41.0
I also downloaded The Clozure CL and installed it from here. the command ccl64 now works fine for me.
# ccl64
Clozure Common Lisp Version 1.11.5/v1.11.5 (LinuxX8664)
For more information about CCL, please see http://ccl.clozure.com.
CCL is free software. It is distributed under the terms of the Apache
Licence, Version 2.0.
?
but the ccl command has this error
# ccl
/usr/local/bin/ccl: 48: exec: /usr/local/src/ccl/lx86cl: not found
the command sbcl is working fine as well
# sbcl
WARNING: Setting locale failed.
Check the following variables for correct values:
LC_MONETARY=az_IR
LC_NUMERIC=az_IR
This is SBCL 1.4.5.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
*
I also installed quick lisp following the steps from here
I have zero knowledge of maxima and lisp so I don't know how to follow the steps you suggested in Method 2 especially
Note that in order for this method to work, Quicklisp needs be loaded by default in every Maxima session.
By using Method 1 I also get this error:
# maxima -l ccl
/usr/bin/maxima: 185: exec: openmcl: not found
# maxima -l ccl64
/usr/bin/maxima: 196: exec: dx86cl64: not found
# maxima -l sbcl
WARNING: Setting locale failed.
Check the following variables for correct values:
LC_MONETARY=az_IR
LC_NUMERIC=az_IR
could not open file "/usr/lib/maxima/5.41.0/binary-sbcl/maxima.core"
open: No such file or directory
please help me solving the problem and installing maxima core for Jupiter notebook.
Thank you very much for your help and time.
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.
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.
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.
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.
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.
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.
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.
with the --user flag the error remains the same.
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` --userYes, 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.
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.
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.
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.
Closing this issue since OP's problems seem to have been resolved. I've moved the final comment to a new thread: #86