[Openmcl-devel] type specifier '(simple-vector n) in defmethod

Nicolas Martyanoff nicolas at n16f.net
Fri Jan 5 12:42:20 PST 2024


Tim McNerney <mc at media.mit.edu> writes:

> Since Clozure Associates dissolved its LLC and its founders retired,
> it is now up to _us as a community_ to carry the torch and maintain CCL.
> There is no "somebody else" to do it for us.
> We all have to answer questions.
> We all have to fix bugs.
> We all have to make sure bug fixes are tested, checked in, and patches created.
> There is an argument that a smaller "core" of maintainers oversee releases,
> but if we keep adding to a regression suite and are diligent about running it,
> anyone should be able to make a release, as long as they keep in communication.
> Where "release" means a carefully curated and extensively tested
> build.
I'm not disagreeing, but none of this is happening unless either Clozure
gives project admin right to someone really invested, or this someone
does the job of forking the project.

> As for CCL's "demise being greatly exaggerated," I've been seeing clear
> evidence that
> there is decreasing opportunity to run a viable business licensing proprietary
> CLs.
> Open source Common Lisps are the way to go.
> My apologies to the maintainers of SBCL, but it is weighed down by lots of pet
> projects.
Which projects are you refering to? I was pleasantly surprised by the
new optional concurrent GC recently released, this kind of initiative is
exactly what we need in the CL world.

> CCL is a highly optimized, complex-but-lean, "diamond."
> I back the "diamond" approach.
Dropping all the MacOS UI code, the editor, cleaning the mess (I still
have headaches from what I've read on the FFI layer and error handling
in the IO layer) concentrating on standard compliance and robustness
would make it a diamond in time. The amount of work to get there is
staggering; I suspect writing a new implementation (with a decent
userland thread based runtime pretty please) would be less painful and
much more interesting.

But just patching bugs and releasing regularly would be nice.

-- 
Nicolas Martyanoff
https://n16f.net
nicolas at n16f.net


More information about the Openmcl-devel mailing list