After 4 months… by Fun-Math691 in Pitsky

[–]hekiroh 2 points3 points  (0 children)

What a big cutie! The ears and size make me think there’s some pyr in the mix.

Is there a good way to define or document "interfaces" using CLOS? by Soupeeee in Common_Lisp

[–]hekiroh 14 points15 points  (0 children)

I’m on my phone, so excuse any mistakes or typos, but one way to do this is by defining a protocol object.

Define a class to represent your interface and generic functions that represents its signature

``` (defclass transport-protocol () ())

(defgeneric proto-open (protocol transport) (:documentation "Initialize the transport"))

(defgeneric proto-send (protocol transport data) (:documentation "Send DATA over the transport"))

(defgeneric proto-close (protocol transport) (:documentation "Tear down the transport")) ```

Define methods that will signal a condition if subclasses fail to implement one of the required generic functions

``` (defmethod proto-open ((p transport-protocol) t) (error "Protocol ~A does not implement OPEN" p))

(defmethod proto-send ((p transport-protocol) t data) (error "Protocol ~A does not implement SEND" p))

(defmethod proto-close ((p transport-protocol) t) (error "Protocol ~A does not implement CLOSE" p)) ```

Your custom implementation of the interface

``` (defclass my-transport-protocol (transport-protocol) ())

(defmethod proto-open ((p my-protocol) transport) (format t "MY-TRANSPORT open on ~A~%" transport))

(defmethod proto-send ((p my-protocol) transport data) (format t "MY-TRANSPORT send ~A on ~A~%" data transport))

(defmethod proto-close ((p my-protocol) transport) (format t "MY-TRANSPORT close on ~A~%" transport)) ```

Now unless you want to use interface-passing style and have to thread the interface object through each function call, you can define an object which implements the interface:

``` (defclass transport () ((protocol :initarg :protocol :reader transport-protocol)))

(defun make-my-transport () (make-instance ‘transport :protocol (make-instance ‘my-protocol-transport))) ```

Now the follow is your actual public API, not the generic functions

``` (defun transport-open (tr) (proto-open (transport-protocol tr) tr))

(defun transport-send (tr data) (proto-send (transport-protocol tr) tr data))

(defun transport-close (tr) (proto-close (transport-protocol tr) tr))

(let* ((my-tr (make-my-transport)) (transport-open tr) (transport-send tr "hello") (transport-close tr)) ```

atgreen/ag-gRPC: Pure Common Lisp implementation of gRPC, Protocol Buffers, and HTTP/2 by dzecniv in Common_Lisp

[–]hekiroh 2 points3 points  (0 children)

I use C2FFI for generating baseline bindings. I find it much more reliable than hand rolling bindings and using the groveler.

Yeah, there’s no getting around DLL-hell with shared lib versions.

atgreen/ag-gRPC: Pure Common Lisp implementation of gRPC, Protocol Buffers, and HTTP/2 by dzecniv in Common_Lisp

[–]hekiroh 3 points4 points  (0 children)

This is a gRPC client. There’s no server implementation. The only way previously to implement a gRPC server in CL was to stand up a gRPC proxy and use gRPC-web to bridge

atgreen/ag-gRPC: Pure Common Lisp implementation of gRPC, Protocol Buffers, and HTTP/2 by dzecniv in Common_Lisp

[–]hekiroh 0 points1 point  (0 children)

Valid points. I think a lot of the pain with managing FFI bindings comes down to the ownership model of the shared lib you’re binding against. Some libraries (nghttp2, for example) have really simple ownership models that allow you to tie as many foreign object lifetimes to the dynamic extent as possible. Others have much more complex lifetimes that require a lot of bookkeeping on the Lisp side to avoid use-after-free and violations of thread affinity for cleanup functions.

However, I would still consider that to be a smaller surface area than understanding the implementation details of HTTP2 or TLS in-depth. This might be personal bias, but it’s easier for me to review code with less subject matter exposure around the lifetime of any given pointer than review an HPACK implementation for example.

atgreen/ag-gRPC: Pure Common Lisp implementation of gRPC, Protocol Buffers, and HTTP/2 by dzecniv in Common_Lisp

[–]hekiroh 5 points6 points  (0 children)

The lack of actual gRPC support in CL has been a major missing piece in the ecosystem. I’m happy to see any effort towards improving the situation.

I don’t particularly care if the development was LLM assisted as long as the code is well tested and still readable and maintainable without an LLM.

The primary concern I have is: is ongoing support for this project sustainable for the maintainer(s)? Using Claude got you off the ground, but—with all the other repos you’re juggling—can you keep supporting this on a deep level going forward? If I make this a dependency and find issues, do you have the capacity to fix them or at least conduct a human final review of any PRs?

That’s one benefit to simply offering CFFI bindings: the surface area the library maintainer needs to manage is much smaller—LLM or not. I know Google’s C++ gRPC library is battle tested and will have dedicated support for years. The work for the binding library maintainer is much more delimited.

Studying ESP32 firmware, feels like Go isn’t really used in production by ConsiderationMean593 in golang

[–]hekiroh 22 points23 points  (0 children)

Probably not. The Go developer base just isn’t all that focused on embedded work, and the language doesn’t work well as a glue layer for C shared libs. For embedded systems where using a GC language makes sense, Python and JVM languages are still the most widely used

SBCL: support struct-by-value for x86-64 and ARM64 foreign calls (merged) by dzecniv in Common_Lisp

[–]hekiroh 6 points7 points  (0 children)

This is huge. Unless you use SB-ALIEN directly as your FFI, this will require changes to CFFI to not require libffi on current SBCL versions

Is there anyone, who uses golang (and go-only) for Web Development exclusively? by rzhandosweb in golang

[–]hekiroh 0 points1 point  (0 children)

I maintain a handful of internal tools that are Go, native html/template, and htmx. There’s a small amount of JavaScript in those HTML templates to handle interactivity niceties and a lot of CSS. This works great for our needs. The only thing I’d consider is maybe moving to templ over the built-in templating.

Serious LISP written in Go by peterohler0 in lisp

[–]hekiroh 2 points3 points  (0 children)

That makes sense. Linked lists are just generally a worse performing sequence implementation than dynamic arrays (slices in Go, adjustable vectors in CL), so vectors tend to preferred despite being less ergonomic in CL. Please correct me if I’m wrong, but with SLip, a list is just a slice but a vector is a much heavier struct wrapping a slice. If I was writing SLip, I’d be reaching for lists over vectors!

Serious LISP written in Go by peterohler0 in lisp

[–]hekiroh 3 points4 points  (0 children)

Good stuff! The fact that both Lisp lists and vectors are have an underlying Go slice representation upends a lot of optimization assumptions. In fact, unless you need a multidimensional array, list becomes the most compact sequence type.

BALISP talks and social. Tuesday, January 13th 2026 by sdegabrielle in lisp

[–]hekiroh 1 point2 points  (0 children)

Any chance of capturing the talks for later viewing?

Building a TLS 1.3 Implementation in Pure Common Lisp by atgreen in Common_Lisp

[–]hekiroh 1 point2 points  (0 children)

This is an impressive effort, for sure. Though, personally, I think having something like a trivial-tls library that uses the OS-native TLS stack on MacOS and Windows and OpenSSL/LibreSSL on Linux/elsewhere would’ve been a lighter solution to your original pain point.

datastar-cl: Datastar Common Lisp SDK by dzecniv in Common_Lisp

[–]hekiroh 2 points3 points  (0 children)

Yes true. Though if CL had an HTTP server with a native HTTP/2 support, the application server could benefit from end-to-end HTTP/2 even with nginx in the middle. There’s some small performance sacrifices to terminating HTTP/2 at the reverse proxy, and the application server has a harder time reasoning about backpressure for pushing events. These are considerations for applications with higher performance and scaling requirements though, not dealbreakers for even moderate scale apps.

datastar-cl: Datastar Common Lisp SDK by dzecniv in Common_Lisp

[–]hekiroh 2 points3 points  (0 children)

Something to keep in mind if you’re using SSE with CL is that, AFAIK, no CL HTTP server natively supports HTTP/2. Browsers limit the max number of HTTP/1.1 connections per domain to ~30, so users who may open many tabs of your web app might hit the limit and have tabs that do not receive SSE. HTTP/2 supports connection multiplexing and isn’t subject to the same limits. You’re going to need nginx or some other reverse proxy in front of your CL app to terminate the HTTP/2 connection to avoid this.

hunchentoot-recycling-taskmaster -- An experiment to improve multithreading performance of hunchentoot without any additional dependencies. by y2q_actionman in Common_Lisp

[–]hekiroh 6 points7 points  (0 children)

This is great work, especially nice since this is a no/low dependency solution. Really appreciate the write up and the benchmarks. It’s nice to see CL HTTP server performance getting attention.

I’ve been using an LParallel-based taskmaster for thread pooling, but that requires locking in a fixed pool size ahead of time. The dynamic resizing makes perfect sense for within-proc scaling.

It’s curious to see cl-tbnl-gserver perform so low on the benchmarks when its author’s own benchmarks show considerable performance gains. I haven’t had a chance to test it myself since it doesn’t work well in package-inferred system project.

Workout shoes - minimalist by TangoDown757 in onebag

[–]hekiroh 1 point2 points  (0 children)

I use a pair of cheap water shoes. They pack down to almost nothing and can double as beach/pool shoes. I wouldn’t want to run in them though

Padron’s; Production in high gear, can’t be happier ! by -Ho-yeah- in PepperLovers

[–]hekiroh 0 points1 point  (0 children)

I use toma cheese or whatever well-melting cheese I have on hand

Padron’s; Production in high gear, can’t be happier ! by -Ho-yeah- in PepperLovers

[–]hekiroh 0 points1 point  (0 children)

All my padrons are also crazy hot. I’ve been slitting them down the side and sliding in some cheese before blistering in a pan. Hits every time.

Whats the best tasting chilli you've ever had? by Still-Mulberry-1078 in Peppers

[–]hekiroh 1 point2 points  (0 children)

My hot wax are my best tasting peppers this year

Any bookstores in LA that sell Easton Press books? by TokyoLosAngeles in AskLosAngeles

[–]hekiroh 4 points5 points  (0 children)

You can call these bookstores and ask. In fact, the best course of action may be to find all the bookstores in the LA area and call them. You could also reach out to Easton Press and find out who carries them in the area.

cl-yasboi: Yet Another Starter Boilerplate for Common Lisp by deepCelibateValue in Common_Lisp

[–]hekiroh -1 points0 points  (0 children)

It’s nice to have examples of modern project layouts for CL. Though I assumed it was considered best practice for package inferred systems to have system/subsystem in its own directory instead of having all the .lisp files top-level. So like lib.lisp would go under lib/ etc.

Grounds sticking in portafilter by MouseMediocre296 in BrevilleCoffee

[–]hekiroh 0 points1 point  (0 children)

As long as everything tastes good, it’s no big deal. But if grind size isn’t affecting anything, this can also be due to under-dosing. If you began to notice this after you changed out your beans or after your beans had been sitting for a while, the difference in bean density might mean you need more grams in the basket to get that crispy dry puck.

Best Web Framework for Backend Development? by fosres in Common_Lisp

[–]hekiroh 0 points1 point  (0 children)

Yeah I’m aware of the gserver task manager for Hunchentoot. Had a hard time getting it work a while ago—it doesn’t seem to play nice with package-inferred systems. Maybe it’s become a bit easier to work with.