Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommend using cl-package-locks instead of #+sb-package-locks (:lock t) #66

Open
minghu6 opened this issue Jul 23, 2020 · 3 comments
Open

Comments

@minghu6
Copy link

minghu6 commented Jul 23, 2020

When I read the source, I find that :

#+sb-package-locks (:lock t)

However, there is a cl-package-locks have provided a uniform way of dealing with package-locks across implementations.

Why not just import it from defsystem and replace the sbcl-package-lock using (cl-package-locks:lock-package 'serapeum) on package.lisp?

@ruricolist
Copy link
Owner

For two reasons:

  1. cl-package-locks is very old and probably obsolete (hasn't been touched in 10 years, doesn't even mention ECL)
  2. I use the feature of SBCL's package locks that lets one package implement parts of another; not all Lisps that support package locks support that.

However there may be a better, more portable way to do this so I will leave this issue open for the present.

@minghu6
Copy link
Author

minghu6 commented Jul 24, 2020

cl-package-locks is indeed very old and keeps unmaintained for a long time...
(I just use it in sbcl, and still works fine for package lock function)

Maybe we can try to email the author (if still alive 😂) and take over it? en... maybe some day, waiting for Godot

@elliottjohnson
Copy link

elliottjohnson commented Apr 10, 2024

Hi. Reviving an old topic becauseI just found this via a random Google search.

No updates in a long time because there hasn't been a need on my end. Let me know if you have a pull request for your needs.

Best,
Elliott

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants