filesystem error with pathname

[szazs89]

I reinstalled jupyterlab in buster chroot (debian-10) and installed maxima-sage and cl-quicklisp:

# dpkg -l  |egrep 'maxima|lisp|ecl'
ii  cl-quicklisp                  1.0-1                        all          library manager for Common Lisp
ii  ecl                           16.1.2-5                     amd64        Embeddable Common-Lisp: ...
ii  maxima-sage                   5.41.0+ds-2                  amd64        Computer algebra system -- base system

I manually installed quicklisp:

(buster)me$ ecl -load /usr/share/cl-quicklisp/quicklisp.lisp \
       -eval "(quicklisp-quickstart:install)" \
       -eval "(ql:add-to-init-file)"

then I copied the created .eclrc into /opt/src/maxima-jupyter/eclrc

;;; The following lines added by ql:add-to-init-file:
#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
                                       (user-homedir-pathname))))
  (when (probe-file quicklisp-init)
    (load quicklisp-init)))

and modified /usr/local/share/jupyter/kernel/maxima/kernel.json as follows:

{
 "language": "maxima",
 "display_name": "Maxima",
 "argv": [ "maxima-sage",
        "--very-quiet",
        "-p /opt/src/maxima-jupyter/eclrc",
        "--preload-lisp=/opt/src/maxima-jupyter/load-maxima-jupyter.lisp",
        "--batch-string=jupyter_kernel_start(\"{connection_file}\")$"  ]
}

Now, I get this in the jupyterhub.log when trying to open a new maxima notebook:

;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/sb-bsd-sockets.fas"
;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/sockets.fas"
;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/defsystem.fas"
;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/cmp.fas"
Maxima encountered a Lisp error:

 Filesystem error with pathname #P"/home/me/- ".
Either
 1) the file does not exist, or
 2) we are not allowed to access the file, or
 3) the pathname points to a broken symbolic link.

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.

Condition of type: SIMPLE-CONTROL-ERROR
THROW: The catch MAXIMA::RETURN-FROM-DEBUGGER is undefined.
No restarts available.

Top level in: #<process TOP-LEVEL>.
> 

Though, a file Untitled.ipynb is created in /home/me ... What did I wrong?

TIA, Zsolt

[robert-dodier]

It looks like ECL is trying to open a file named "/home/me/- ". That looks like a malformed name. One way to try to find out from where the name is coming is to get a stack trace. Try entering :backtrace at the ">" prompt. Does that yield some information?

[szazs89]

The problem is that the output is from the log, I have no interactive session... Maybe the kernel.json should be modified with appropriate switches for the backtrace, or the lisp scripts...?

[szazs89]

I have tried again (now from command line in xterm without --batch-script parameter):

$ maxima-sage -p eclrc -p load-maxima-jupyter.lisp
;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/sb-bsd-sockets.fas"
;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/sockets.fas"
;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/defsystem.fas"
;;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.2/cmp.fas"
now ASDF:*CENTRAL-REGISTRY*=("/opt/src/maxima-jupyter/src/"
                             #P"/home/szazs/quicklisp/quicklisp/")
To load "maxima-jupyter":
  Load 1 ASDF system:
    maxima-jupyter
; Loading "maxima-jupyter"
..
Maxima encountered a Lisp error:

 In method definition for INSERT-SEQUENCE, found an invalid specializer (ORDERED
-CONTAINER-MIXIN
                                                                         ARRAY)

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
Available restarts:

1. (TRY-RECOMPILING) Recompile basic-operations and try loading it again
2. (RETRY) Retry loading FASL for #<cl-source-file "cl-containers" "dev" "basic-
operations">.
3. (ACCEPT) Continue, treating loading FASL for #<cl-source-file "cl-containers"
 "dev" "basic-operations"> as having been successful.
4. (RETRY) Retry ASDF operation.
5. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the conf
iguration.
6. (ABORT) Give up on "maxima-jupyter"

Top level in: #<process TOP-LEVEL>.
> :backtrace
Backtrace:
  > SI:BYTECODES [Evaluation of: (QUICKLISP-CLIENT:QUICKLOAD "maxima-jupyter")]
  > si:bytecodes [Evaluation of: (run)]
>

It is quite different from the output obtained by creating a notebook in jupyter... Strange. Any hint?

[robert-dodier]

I haven't been able to try Maxima-Jupyter with ECL since I am stuck in a tangle of dependencies. I'll try again although it may be a while as I don't have time to work on it right now. Be that as it may, my only advice to you at this point is to try another Lisp other than ECL. ECL might work since apparently Bordeaux threads works with ECL and that's a crucial dependency. However, ECL has more bugs than other Lisps, and less development progress. So maybe you're better off working with another Lisp.

I have worked with Clozure CL and it works correctly with Maxima-Jupyter, maybe you can try that. I think SBCL should also work, although I haven't tried it myself. You will probably need to compile Maxima with whatever Lisp you select; that is not difficult. Basically all you have to do is unpack a tarball and then execute: sh bootstrap && ./configure --enable-foolisp && make && sudo make install where foolisp is the name of the selected Lisp. ./configure --help tells the available options.

[yitzchak]

I use SBCL so I can confirm that it works. I switched from ECL because I could not get it to work.

[szazs89]

OK, so trying to compile maxima with sbcl:

/usr/src/maxima-5.42.1# ./configure --enable-sbcl
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/usr/src/maxima-5.42.1/missing: Unknown `--is-lightweight' option
Try `/usr/src/maxima-5.42.1/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '0' is supported by ustar format... yes
checking whether GID '0' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking for emacs... no
checking for xemacs... no
checking where .elc files should go... ${datadir}/emacs/site-lisp
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for git... true
checking for sbcl... true
checking for sbcl... (cached) true
checking for iconv... true
checking for recode... false
checking POSIX shell to see that it contains getopts... trying /bin/sh
POSIX shell is /bin/sh
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for cat... /bin/cat
checking for a sed that does not truncate output... /bin/sed
checking for gawk... (cached) mawk
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/dist-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.7/d
ist-packages
checking that generated files are newer than configure... done
[config.status: creating ...]

Summary:
SBCL enabled. Executable name: "sbcl"
default lisp: sbcl
wish executable name: "wish"

However, the output of make contains 173 "undefined functions:" line, like:

[...]
; file: /usr/src/maxima-5.42.1/lisp-utils/defsystem.lisp
; in: DEFUN SYSTEM-SOURCE-SIZE
;     (MAKE::FILE-LIST-SIZE MAKE::FILE-LIST)
; 
; caught STYLE-WARNING:
;   undefined function: FILE-LIST-SIZE
; 
; compilation unit finished
;   Undefined function:
;     FILE-LIST-SIZE
;   caught 1 STYLE-WARNING condition

;  - Loading defsystem "maxima" 
;    - Loading module "package" 
;      - Loading source file "/usr/src/maxima-5.42.1/src/maxima-package.lisp" 
;      - Loading source file
;        "/usr/src/maxima-5.42.1/src/autoconf-variables.lisp"
;    - Loading module "intl" 
;      - Loading binary file
;        "/usr/src/maxima-5.42.1/src/binary-sbcl/intl.fasl"
[...]

though, the compilation and then the make install seems to be successful.

Then when trying to open a notebook in jupyterlab (under jupyterhub), I see the following in the jupyterhub.log:

Maxima encountered a Lisp error:

 Couldn't load "- ": file does not exist.

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.

debugger invoked on a SB-INT:SIMPLE-CONTROL-ERROR in thread
#<THREAD "main thread" RUNNING {10005D85B3}>:
  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: [CONTINUE] Ignore runtime option --eval "(cl-user::run)".
  1: [ABORT   ] Skip rest of --eval and --load options.
  2:            Skip to toplevel READ/EVAL/PRINT loop.
  3: [EXIT    ] Exit SBCL (calling #'EXIT, killing the process).

(THROW)
0] 
; 
; compilation unit aborted
;   caught 1 fatal ERROR condition

Now, maxima is invoked from /usr/local/share/jupyter/kernels/maxima/kernel.json:

{
 "language": "maxima",
 "display_name": "Maxima",
 "argv": ["maxima",
        "--very-quiet",
        "--preload-lisp=/opt/src/maxima-jupyter/load-maxima-jupyter.lisp",
        "--batch-string=jupyter_kernel_start(\"{connection_file}\")$"
 ]
}

Any further hint? TIA, Zsolt

[robert-dodier]

Zsolt, at this point I have broken the logjam of stale dependencies and I have successfully rebuilt maxima-jupyter using SBCL 1.4.8 + a post-5.42 Maxima version (from Git). A key point for me is that some Quicklisp packages assumed ASDF 2 while SBCL ships with ASDF 3, and the two are not compatible. I ended up erasing Quicklisp and all its projects and starting fresh. I also updated to Jupyter 4.0.2 as my installation was a year or two out of date. I am working with Python 3.4.0, on Ubuntu 14.04.

But that's a digression. Now back to your problem, my advice after re-reading your comments is to use the Python script install-maxima-jupyter.py, which creates a kernel.json file and copies it to a place where Jupyter can find it. On my system (as on yours, I guess) it is /usr/local/share/jupyter/kernels/maxima/kernel.json.

When I do that, I see that the content is different from what you obtained. Here is what I see in kernel.json:

{"display_name": "Maxima", "argv": ["/home/robert/github/github-robert-dodier/maxima-jupyter/binary/binary-sbcl/maxima-jupyter-exec", "{connection_file}"], "language": "maxima"}

I know that you have added some options for specific purposes, but maybe for the moment, until you get it running, you can omit them.

Running install-maxima-jupyter.py is mentioned in Readme.md. Can you give it a try and let us know how it turned out?

best, Robert.

PS. By the way, since this issue is getting long and has evolved somewhat since it started, I'd like to suggest that you close this one and create a new issue to handle additional problems.

[robert-dodier]

Zsolt, I'm taking the liberty of going ahead and closing this issue in the interest of focusing further discussion. Please feel free to open a new issue if you are still having a problem.