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

[Tim McNerney]

[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<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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20240105/01bca6e7/attachment.htm>