#quicklisp — Public Fediverse posts

Need help from Lisp wizards — looks like I'm missing something simple and obvious (but not so obvious for beginner). I'm trying to build (with ECL) the simple program, which uses ql:quickload to load parse-number, then prints "Hello world". It builds without errors, but resulting binary could not be executed — it prints error message about unknown "ql:quickload" function.

QuickLisp was installed like described in the official documentation. It works in SBCL, it works in ECL REPL and it has the necessary lines in the ~/.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)))
(ql:quickload '(:slite) :silent t)

The program, itself, runs successfully if I just evaluate the next code in the REPL:

(ql:quickload '(:parse-number) :silent t)

(defpackage :test
(:use :cl))

(in-package :test)

(defun toplevel ()
(print "Hello world"))

(progn
(toplevel)
(ext:quit))

And it compiles:

ecl --eval '(progn (compile-file "test.lisp" :system-p t) (c:build-program "test" :lisp-files '"'"'("test.o")) (quit))'
;;; Loading #P"/home/drag0n/quicklisp/setup.lisp"
;;; Loading #P"/usr/local/lib/ecl-24.5.10/asdf.fas"
;;;
;;; Compiling test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Finished compiling test.lisp.
;;;

But doesn't print "Hello world":

./test

Condition of type: UNDEFINED-FUNCTION
The function QUICKLISP-CLIENT::QUICKLOAD is undefined.
No restarts available.

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

#AskFedi #CommonLisp #ECL #QuickLisp

Need help from Lisp wizards — looks like I'm missing something simple and obvious (but not so obvious for beginner). I'm trying to build (with ECL) the simple program, which uses ql:quickload to load parse-number, then prints "Hello world". It builds without errors, but resulting binary could not be executed — it prints error message about unknown "ql:quickload" function.

QuickLisp was installed like described in the official documentation. It works in SBCL, it works in ECL REPL and it has the necessary lines in the ~/.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)))
(ql:quickload '(:slite) :silent t)

The program, itself, runs successfully if I just evaluate the next code in the REPL:

(ql:quickload '(:parse-number) :silent t)

(defpackage :test
(:use :cl))

(in-package :test)

(defun toplevel ()
(print "Hello world"))

(progn
(toplevel)
(ext:quit))

And it compiles:

ecl --eval '(progn (compile-file "test.lisp" :system-p t) (c:build-program "test" :lisp-files '"'"'("test.o")) (quit))'
;;; Loading #P"/home/drag0n/quicklisp/setup.lisp"
;;; Loading #P"/usr/local/lib/ecl-24.5.10/asdf.fas"
;;;
;;; Compiling test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Finished compiling test.lisp.
;;;

But doesn't print "Hello world":

./test

Condition of type: UNDEFINED-FUNCTION
The function QUICKLISP-CLIENT::QUICKLOAD is undefined.
No restarts available.

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

#AskFedi #CommonLisp #ECL #QuickLisp

Need help from Lisp wizards — looks like I'm missing something simple and obvious (but not so obvious for beginner). I'm trying to build (with ECL) the simple program, which uses ql:quickload to load parse-number, then prints "Hello world". It builds without errors, but resulting binary could not be executed — it prints error message about unknown "ql:quickload" function.

QuickLisp was installed like described in the official documentation. It works in SBCL, it works in ECL REPL and it has the necessary lines in the ~/.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)))
(ql:quickload '(:slite) :silent t)

The program, itself, runs successfully if I just evaluate the next code in the REPL:

(ql:quickload '(:parse-number) :silent t)

(defpackage :test
(:use :cl))

(in-package :test)

(defun toplevel ()
(print "Hello world"))

(progn
(toplevel)
(ext:quit))

And it compiles:

ecl --eval '(progn (compile-file "test.lisp" :system-p t) (c:build-program "test" :lisp-files '"'"'("test.o")) (quit))'
;;; Loading #P"/home/drag0n/quicklisp/setup.lisp"
;;; Loading #P"/usr/local/lib/ecl-24.5.10/asdf.fas"
;;;
;;; Compiling test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Finished compiling test.lisp.
;;;

But doesn't print "Hello world":

./test

Condition of type: UNDEFINED-FUNCTION
The function QUICKLISP-CLIENT::QUICKLOAD is undefined.
No restarts available.

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

#AskFedi #CommonLisp #ECL #QuickLisp

Need help from Lisp wizards — looks like I'm missing something simple and obvious (but not so obvious for beginner). I'm trying to build (with ECL) the simple program, which uses ql:quickload to load parse-number, then prints "Hello world". It builds without errors, but resulting binary could not be executed — it prints error message about unknown "ql:quickload" function.

QuickLisp was installed like described in the official documentation. It works in SBCL, it works in ECL REPL and it has the necessary lines in the ~/.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)))
(ql:quickload '(:slite) :silent t)

The program, itself, runs successfully if I just evaluate the next code in the REPL:

(ql:quickload '(:parse-number) :silent t)

(defpackage :test
(:use :cl))

(in-package :test)

(defun toplevel ()
(print "Hello world"))

(progn
(toplevel)
(ext:quit))

And it compiles:

ecl --eval '(progn (compile-file "test.lisp" :system-p t) (c:build-program "test" :lisp-files '"'"'("test.o")) (quit))'
;;; Loading #P"/home/drag0n/quicklisp/setup.lisp"
;;; Loading #P"/usr/local/lib/ecl-24.5.10/asdf.fas"
;;;
;;; Compiling test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Finished compiling test.lisp.
;;;

But doesn't print "Hello world":

./test

Condition of type: UNDEFINED-FUNCTION
The function QUICKLISP-CLIENT::QUICKLOAD is undefined.
No restarts available.

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

#AskFedi #CommonLisp #ECL #QuickLisp

Need help from Lisp wizards — looks like I'm missing something simple and obvious (but not so obvious for beginner). I'm trying to build (with ECL) the simple program, which uses ql:quickload to load parse-number, then prints "Hello world". It builds without errors, but resulting binary could not be executed — it prints error message about unknown "ql:quickload" function.

QuickLisp was installed like described in the official documentation. It works in SBCL, it works in ECL REPL and it has the necessary lines in the ~/.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)))
(ql:quickload '(:slite) :silent t)

The program, itself, runs successfully if I just evaluate the next code in the REPL:

(ql:quickload '(:parse-number) :silent t)

(defpackage :test
(:use :cl))

(in-package :test)

(defun toplevel ()
(print "Hello world"))

(progn
(toplevel)
(ext:quit))

And it compiles:

ecl --eval '(progn (compile-file "test.lisp" :system-p t) (c:build-program "test" :lisp-files '"'"'("test.o")) (quit))'
;;; Loading #P"/home/drag0n/quicklisp/setup.lisp"
;;; Loading #P"/usr/local/lib/ecl-24.5.10/asdf.fas"
;;;
;;; Compiling test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Finished compiling test.lisp.
;;;

But doesn't print "Hello world":

./test

Condition of type: UNDEFINED-FUNCTION
The function QUICKLISP-CLIENT::QUICKLOAD is undefined.
No restarts available.

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

#AskFedi #CommonLisp #ECL #QuickLisp

"If there is one thing that confuses newcomers to Common Lisp, it is the interplay of built-in CL functionality, add-ons like Quicklisp and ASDF, and what all the words mean." by Cees de Groot

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#lisp #commonlisp #quicklisp #asdf

"If there is one thing that confuses newcomers to Common Lisp, it is the interplay of built-in CL functionality, add-ons like Quicklisp and ASDF, and what all the words mean." by Cees de Groot

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#lisp #commonlisp #quicklisp #asdf

"If there is one thing that confuses newcomers to Common Lisp, it is the interplay of built-in CL functionality, add-ons like Quicklisp and ASDF, and what all the words mean." by Cees de Groot

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#lisp #commonlisp #quicklisp #asdf

"If there is one thing that confuses newcomers to Common Lisp, it is the interplay of built-in CL functionality, add-ons like Quicklisp and ASDF, and what all the words mean." by Cees de Groot

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#lisp #commonlisp #quicklisp #asdf

"If there is one thing that confuses newcomers to Common Lisp, it is the interplay of built-in CL functionality, add-ons like Quicklisp and ASDF, and what all the words mean." by Cees de Groot

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#lisp #commonlisp #quicklisp #asdf

🤯 Ah yes, the riveting saga of Common Lisp packaging: where we untangle the ancient hieroglyphics of #ASDF and #Quicklisp so you can finally figure out how to install a library from the '80s. ⚙️🕰️ Because nothing screams "modern programming" like deciphering terms minted before your parents met. 📜
https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html #CommonLisp #Packaging #ProgrammingHistory #ModernDevelopment #HackerNews #ngated

🤯 Ah yes, the riveting saga of Common Lisp packaging: where we untangle the ancient hieroglyphics of #ASDF and #Quicklisp so you can finally figure out how to install a library from the '80s. ⚙️🕰️ Because nothing screams "modern programming" like deciphering terms minted before your parents met. 📜
https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html #CommonLisp #Packaging #ProgrammingHistory #ModernDevelopment #HackerNews #ngated

🤯 Ah yes, the riveting saga of Common Lisp packaging: where we untangle the ancient hieroglyphics of #ASDF and #Quicklisp so you can finally figure out how to install a library from the '80s. ⚙️🕰️ Because nothing screams "modern programming" like deciphering terms minted before your parents met. 📜
https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html #CommonLisp #Packaging #ProgrammingHistory #ModernDevelopment #HackerNews #ngated

🤯 Ah yes, the riveting saga of Common Lisp packaging: where we untangle the ancient hieroglyphics of #ASDF and #Quicklisp so you can finally figure out how to install a library from the '80s. ⚙️🕰️ Because nothing screams "modern programming" like deciphering terms minted before your parents met. 📜
https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html #CommonLisp #Packaging #ProgrammingHistory #ModernDevelopment #HackerNews #ngated

Common Lisp, ASDF, and Quicklisp: packaging explained

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#HackerNews #CommonLisp #ASDF #Quicklisp #packaging #programming

Common Lisp, ASDF, and Quicklisp: packaging explained

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#HackerNews #CommonLisp #ASDF #Quicklisp #packaging #programming

Common Lisp, ASDF, and Quicklisp: packaging explained

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#HackerNews #CommonLisp #ASDF #Quicklisp #packaging #programming

Common Lisp, ASDF, and Quicklisp: packaging explained

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#HackerNews #CommonLisp #ASDF #Quicklisp #packaging #programming

Common Lisp, ASDF, and Quicklisp: packaging explained

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#HackerNews #CommonLisp #ASDF #Quicklisp #packaging #programming

Cees de Groot @cdegroot explains what Common Lisp library building and packaging problems ASDF and Quicklisp solve. A clear overview of these tools and what they do.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#asdf #quicklisp #CommonLisp #lisp

Cees de Groot @cdegroot explains what Common Lisp library building and packaging problems ASDF and Quicklisp solve. A clear overview of these tools and what they do.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#asdf #quicklisp #CommonLisp #lisp

Cees de Groot @cdegroot explains what Common Lisp library building and packaging problems ASDF and Quicklisp solve. A clear overview of these tools and what they do.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#asdf #quicklisp #CommonLisp #lisp

Cees de Groot @cdegroot explains what Common Lisp library building and packaging problems ASDF and Quicklisp solve. A clear overview of these tools and what they do.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#asdf #quicklisp #CommonLisp #lisp

Cees de Groot @cdegroot explains what Common Lisp library building and packaging problems ASDF and Quicklisp solve. A clear overview of these tools and what they do.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#asdf #quicklisp #CommonLisp #lisp

I spent some pleasant hours yesterday hacking on my #openbsd port
of #lem. The dependency on async-process led me to forking that
project and making a version which will build the .so it needs if it's
not one of the three pre-built so. I had to do the same with with the
terminal extension in Lem itself.

The #quicklisp and #qlot tools are new to me, and I'm learning just
enough to be dangerous. I did run into an issue where a qlot git
dependency will break if the top level program, lem in this case, has
a .gitignore file. It appears that the qlot cloning will honor the
parent gitignore.

All of this makes me very grateful for the work done on the
#commonlisp tooling over the last decade or so. It's also really
apparent how much this is all a gift, from others -- because the
community is so small. I have had to adjust my expectations, and it
made me realize just how much I take for granted in the software
ecosystem, and the level of polish and work I have come to feel
entitled too.

I spent some pleasant hours yesterday hacking on my #openbsd port
of #lem. The dependency on async-process led me to forking that
project and making a version which will build the .so it needs if it's
not one of the three pre-built so. I had to do the same with with the
terminal extension in Lem itself.

The #quicklisp and #qlot tools are new to me, and I'm learning just
enough to be dangerous. I did run into an issue where a qlot git
dependency will break if the top level program, lem in this case, has
a .gitignore file. It appears that the qlot cloning will honor the
parent gitignore.

All of this makes me very grateful for the work done on the
#commonlisp tooling over the last decade or so. It's also really
apparent how much this is all a gift, from others -- because the
community is so small. I have had to adjust my expectations, and it
made me realize just how much I take for granted in the software
ecosystem, and the level of polish and work I have come to feel
entitled too.

I spent some pleasant hours yesterday hacking on my #openbsd port
of #lem. The dependency on async-process led me to forking that
project and making a version which will build the .so it needs if it's
not one of the three pre-built so. I had to do the same with with the
terminal extension in Lem itself.

The #quicklisp and #qlot tools are new to me, and I'm learning just
enough to be dangerous. I did run into an issue where a qlot git
dependency will break if the top level program, lem in this case, has
a .gitignore file. It appears that the qlot cloning will honor the
parent gitignore.

All of this makes me very grateful for the work done on the
#commonlisp tooling over the last decade or so. It's also really
apparent how much this is all a gift, from others -- because the
community is so small. I have had to adjust my expectations, and it
made me realize just how much I take for granted in the software
ecosystem, and the level of polish and work I have come to feel
entitled too.

I spent some pleasant hours yesterday hacking on my #openbsd port
of #lem. The dependency on async-process led me to forking that
project and making a version which will build the .so it needs if it's
not one of the three pre-built so. I had to do the same with with the
terminal extension in Lem itself.

The #quicklisp and #qlot tools are new to me, and I'm learning just
enough to be dangerous. I did run into an issue where a qlot git
dependency will break if the top level program, lem in this case, has
a .gitignore file. It appears that the qlot cloning will honor the
parent gitignore.

All of this makes me very grateful for the work done on the
#commonlisp tooling over the last decade or so. It's also really
apparent how much this is all a gift, from others -- because the
community is so small. I have had to adjust my expectations, and it
made me realize just how much I take for granted in the software
ecosystem, and the level of polish and work I have come to feel
entitled too.

I spent some pleasant hours yesterday hacking on my #openbsd port
of #lem. The dependency on async-process led me to forking that
project and making a version which will build the .so it needs if it's
not one of the three pre-built so. I had to do the same with with the
terminal extension in Lem itself.

The #quicklisp and #qlot tools are new to me, and I'm learning just
enough to be dangerous. I did run into an issue where a qlot git
dependency will break if the top level program, lem in this case, has
a .gitignore file. It appears that the qlot cloning will honor the
parent gitignore.

All of this makes me very grateful for the work done on the
#commonlisp tooling over the last decade or so. It's also really
apparent how much this is all a gift, from others -- because the
community is so small. I have had to adjust my expectations, and it
made me realize just how much I take for granted in the software
ecosystem, and the level of polish and work I have come to feel
entitled too.

Suppose I use SBCL to develop a Common Lisp project to be built with ASDF and loaded with Quicklisp. To simplify things and leverage defaults should the source tree go under ~/quicklisp/local-projects/ or ~/common-lisp/?

#CommonLisp #quicklisp #lisp

Suppose I use SBCL to develop a Common Lisp project to be built with ASDF and loaded with Quicklisp. To simplify things and leverage defaults should the source tree go under ~/quicklisp/local-projects/ or ~/common-lisp/?

#CommonLisp #quicklisp #lisp

Suppose I use SBCL to develop a Common Lisp project to be built with ASDF and loaded with Quicklisp. To simplify things and leverage defaults should the source tree go under ~/quicklisp/local-projects/ or ~/common-lisp/?

#CommonLisp #quicklisp #lisp

Suppose I use SBCL to develop a Common Lisp project to be built with ASDF and loaded with Quicklisp. To simplify things and leverage defaults should the source tree go under ~/quicklisp/local-projects/ or ~/common-lisp/?

#CommonLisp #quicklisp #lisp

Suppose I use SBCL to develop a Common Lisp project to be built with ASDF and loaded with Quicklisp. To simplify things and leverage defaults should the source tree go under ~/quicklisp/local-projects/ or ~/common-lisp/?

#CommonLisp #quicklisp #lisp

@hairylarry

I respect your adventure.

It's unfortunate that people are still using portacle.
It's 8 years old. It's #emacs build is not current, the build flags are ancient!

The packages do work, but there have been improvements in the last 8 years.

The emacs config is here. Crufty.
Slime, Company, Magit, Paredit and Ag.

https://github.com/portacle/emacsd

Common lisp, #sbcl and #quicklisp are not difficult to install.

The portacle issues should give anyone pause.

https://github.com/portacle/portacle/issues

Portacle doesn't do that much. I think it would be better to install things yourself so you know what you have and avoid the cruft.

My experience may give me a bad POV.

@hairylarry

I respect your adventure.

It's unfortunate that people are still using portacle.
It's 8 years old. It's #emacs build is not current, the build flags are ancient!

The packages do work, but there have been improvements in the last 8 years.

The emacs config is here. Crufty.
Slime, Company, Magit, Paredit and Ag.

https://github.com/portacle/emacsd

Common lisp, #sbcl and #quicklisp are not difficult to install.

The portacle issues should give anyone pause.

https://github.com/portacle/portacle/issues

Portacle doesn't do that much. I think it would be better to install things yourself so you know what you have and avoid the cruft.

My experience may give me a bad POV.

@hairylarry

I respect your adventure.

It's unfortunate that people are still using portacle.
It's 8 years old. It's #emacs build is not current, the build flags are ancient!

The packages do work, but there have been improvements in the last 8 years.

The emacs config is here. Crufty.
Slime, Company, Magit, Paredit and Ag.

https://github.com/portacle/emacsd

Common lisp, #sbcl and #quicklisp are not difficult to install.

The portacle issues should give anyone pause.

https://github.com/portacle/portacle/issues

Portacle doesn't do that much. I think it would be better to install things yourself so you know what you have and avoid the cruft.

My experience may give me a bad POV.

@hairylarry

I respect your adventure.

It's unfortunate that people are still using portacle.
It's 8 years old. It's #emacs build is not current, the build flags are ancient!

The packages do work, but there have been improvements in the last 8 years.

The emacs config is here. Crufty.
Slime, Company, Magit, Paredit and Ag.

https://github.com/portacle/emacsd

Common lisp, #sbcl and #quicklisp are not difficult to install.

The portacle issues should give anyone pause.

https://github.com/portacle/portacle/issues

Portacle doesn't do that much. I think it would be better to install things yourself so you know what you have and avoid the cruft.

My experience may give me a bad POV.

@hairylarry

I respect your adventure.

It's unfortunate that people are still using portacle.
It's 8 years old. It's #emacs build is not current, the build flags are ancient!

The packages do work, but there have been improvements in the last 8 years.

The emacs config is here. Crufty.
Slime, Company, Magit, Paredit and Ag.

https://github.com/portacle/emacsd

Common lisp, #sbcl and #quicklisp are not difficult to install.

The portacle issues should give anyone pause.

https://github.com/portacle/portacle/issues

Portacle doesn't do that much. I think it would be better to install things yourself so you know what you have and avoid the cruft.

My experience may give me a bad POV.

@jackdaniel is the current #quicklisp release of #mcclim good?

@jackdaniel is the current #quicklisp release of #mcclim good?

@jackdaniel is the current #quicklisp release of #mcclim good?

@jackdaniel is the current #quicklisp release of #mcclim good?

@jackdaniel is the current #quicklisp release of #mcclim good?

Finally we have got an update of Quicklisp distribution.

A multiple Common Lisp libraries were added in this release:

http://blog.quicklisp.org/2024/10/october-2024-quicklisp-dist-update-now.html

Please read the list and send in the comments the 3 lisp libraries that you consider the most interesting!

#commonlisp #quicklisp #update

Finally we have got an update of Quicklisp distribution.

A multiple Common Lisp libraries were added in this release:

http://blog.quicklisp.org/2024/10/october-2024-quicklisp-dist-update-now.html

Please read the list and send in the comments the 3 lisp libraries that you consider the most interesting!

#commonlisp #quicklisp #update

Finally we have got an update of Quicklisp distribution.

A multiple Common Lisp libraries were added in this release:

http://blog.quicklisp.org/2024/10/october-2024-quicklisp-dist-update-now.html

Please read the list and send in the comments the 3 lisp libraries that you consider the most interesting!

#commonlisp #quicklisp #update

Finally we have got an update of Quicklisp distribution.

A multiple Common Lisp libraries were added in this release:

http://blog.quicklisp.org/2024/10/october-2024-quicklisp-dist-update-now.html

Please read the list and send in the comments the 3 lisp libraries that you consider the most interesting!

#commonlisp #quicklisp #update

Finally we have got an update of Quicklisp distribution.

A multiple Common Lisp libraries were added in this release:

http://blog.quicklisp.org/2024/10/october-2024-quicklisp-dist-update-now.html

Please read the list and send in the comments the 3 lisp libraries that you consider the most interesting!

#commonlisp #quicklisp #update

There's finally a new Quicklisp dist after literally a year, even though there's no post on the Quicklisp blog #Quicklisp #CommonLisp #Lisp