ciel-lang / CIEL

CIEL Is an Extended Lisp. Scripting with batteries included.
http://ciel-lang.org
333 stars 16 forks source link

The REPL build depends on Quicklisp, hardcoded installation details #73

Open khinsen opened 1 week ago

khinsen commented 1 week ago

repl.lisp starts with

(load "~/quicklisp/setup")

followed by

(let ((*standard-output* (make-broadcast-stream)))
  (ql:quickload "cl-readline"))

This requires Quicklisp to be installed in ~/quicklisp. Guix users (see #36) normally don't use Quicklisp at all, and even users who do have Quicklisp may have installed it elsewhere (~/.quicklisp seems to be popular as well).

I don't see immediately why Quicklisp is used here. Nor why cl-readline needs to be loaded here, ASDF should have taken care of that already.

khinsen commented 1 week ago

Update: I removed those lines and built my Guix package. I get a warning that Quicklisp is not installed, but otherwise the REPL seems to work (as far as I can tell after a few minutes).

jgarte commented 1 week ago

I removed those lines and built my Guix package.

Have your changes been upstreamed to the Guix project?

khinsen commented 1 week ago

No. I have only submitted the dependencies of ciel so far. I prefer to do a lot more testing before submitting ciel itself, in particular testing the REPL. I just noticed that it doesn't find the built-in scripts, for example.

In the end, if I find that Guix requires changes to ciel that are problematic in other environments, I'll add them as a patch to the Guix package definition.

khinsen commented 1 week ago

Back to the Quicklisp issue: I wonder if the reason for reading quicklisp/setup.lisp is that the ciel REPL doesn't read ~/.sbclrc, which is where I'd normally load Quicklisp. If so, then maybe the better solution (also Guix-friendly) is to make the REPL read ~/.cielrc on startup. There are some other things I'd happily put in there.

vindarel commented 1 week ago

There are possible improvements on this front and enabling users to use Quicklisp from CIEL out of the box is a high goal.

Having them to not rely on QL can be another.

Currently, Quicklisp is embedded in the binary but it stills relies on the user having it installed if the user wants to use it. I have some local patches, unfinished.

(load "~/quicklisp/setup") [and the other snippet] This requires Quicklisp to be installed in ~/quicklisp

quicklisp is indeed required when running the file from sources or building a binary, or when trying to quickload a library from the repl,

but not to run the CIEL repl from a binary.

have installed it elsewhere (~/.quicklisp

yes, I am testing a variable, like

(defvar *quicklisp* "~/quicklisp/setup"  ;; with or without .lisp extension.
  "Location to Quicklisp's setup.lisp init file (string). Defaults to ~/quicklisp/setup, as usual.
  See LOAD-QUICKLISP.")

we'll have to decide wether to set it before or after loading ~/.cielrc.

make the REPL read ~/.cielrc on startup

it does read this file at startup right? See load-init-file.

Quicklisp is loaded at build time and harcoded in the binary. We have to make it dynamic, it must find its home dynamically.

When we download a binary release from the CI:

ql:*quicklisp-home* 
=> #P"/root/quicklisp/"

So, in order to use QL in CIEL, we must install it, and add its snippet to our init file.

khinsen commented 1 week ago

I see two easy scenarios for Quicklisp:

  1. You build the binary with Quicklisp, for use on the same machine and account, using the path to setup.lisp that was there at build time.
  2. You don't use Quicklisp at all, creating a portable binary, and leaving it to users to load it dynamically via .cielrc if they wish.

Any other configuration is some mixture of tricky and risky.

I am going for 2. under Guix (there's no other choice), and 1. is what I did on the Mac.

And yes, .cielrc is indeed loaded, assuming you spell it correctly 😳