Re: type specifier '(simple-vector n) in defmethod
Tim McNerney <[email protected]> Fri, 5 Jan 2024 16:01:26 -0500
| Newsgroups | gmane.lisp.openmcl.devel |
|---|---|
| Message-ID | <[email protected]> |
[When I write "I shouldn't be saying this," I should stop right there. Likewise for "my apologies to"...] Hayley Patton /who comes highly recommended to us as a potential contributor to CCL/ is the computer scientist who wrote the Concurrent GC for SBCL <https://zenodo.org/records/7816398> that you so highly praise. We would be /honored/ if someone did something this hard and integrated it into the CCL kernel. --Tim On 1/5/24 3:42 PM, Nicolas Martyanoff wrote: > Tim McNerney<[email protected]> 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. >