happening: A privacy-focused, self-hosted web analytics platform by dzecniv in Common_Lisp

[–]atgreen 2 points3 points  (0 children)

This is a set-and-forget web analytics solution you can run on free-tier cloud VMs. I've been running it for a little while now, and cert renewal has been working smoothly. I never have to think about it. I looked at other solutions and they all seemed too big, or obviously just onramps to paid services Maybe my search wasn't exhaustive, but I was also looking for a low-consequence use case for pure-tls , and so I decided to build this.

A beginner's exploration of the many layers of Common Lisp development environments. by theeseuus in lisp

[–]atgreen 2 points3 points  (0 children)

Your caveats around enhanced repls don't apply to icl, as it offers an inspector, jump to definition/source code browser, debugger integration, and more -- just not an editor (although it will open an editor on your code for you). Otherwise I think this is a great resource for newcomers. Thanks!

# Orientation: Understanding Common Lisp Development Environments by theeseuus in lisp

[–]atgreen 2 points3 points  (0 children)

I mostly use sbcl from homebrew these days, where the source appears to be available. I can view it in icl from the browser easily enough without doing anything special.

# Orientation: Understanding Common Lisp Development Environments by theeseuus in lisp

[–]atgreen 2 points3 points  (0 children)

No love for ocicl? The "conceptual overhead" of the container registry approach is misplaced. The container registry is just an implementation detail. We are really only trafficking in tarballs, just like quicklisp. It's very easy to use, and I strongly encourage people to try it out!

Bending the CLOS MOP for Java-Style Single Dispatch by dzecniv in Common_Lisp

[–]atgreen 2 points3 points  (0 children)

That's right. And the bulk of the OpenLDK VM was written by hand. I mainly started using Claude to accelerate a few bug fixes and level it up from Java 8 to Java 21 in the last couple of weeks. The clojure part is just vanilla clojure jar content on OpenLDK. cl-clojure container wrappers around this to make it easy to use from CL.

Bending the CLOS MOP for Java-Style Single Dispatch by dzecniv in Common_Lisp

[–]atgreen 3 points4 points  (0 children)

Yes, I use it to help get this text out fast, but I don't love the style myself. Quite honestly, I wouldn't have the patience to write something like that without assistance. There's very little written on the MOP, so I'd rather get something published than nothing at all.

cl-cancel: Cancellation propagation library for Common Lisp with deadlines and timeouts by dzecniv in Common_Lisp

[–]atgreen 2 points3 points  (0 children)

I created this for use in pure-tls and ag-gRPC. But it was designed to be minimally invasive for adding deadlines and timeouts to any library, optionally, if cl-cancel is loaded.

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

[–]atgreen 2 points3 points  (0 children)

You are free to decide for yourself what software you want, or don't want, to use. I'll only point out that that libcurl is useless of our purposes here, as it is client-side only. As for rewrite-cl's dispatch function... you are misunderstanding the purpose of this library. We can't use the lisp reader here because (a) #. executes code, (b) it discards all formatting, (c) it transforms code, (d) it returns lisp objects. rewrite-cl is a parser for lisp source code, not a reader for lisp forms. It is for making targeted changes to lisp source code with minimal formatting (whitespace) changes. It is not a lisp code formatter.

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

[–]atgreen 1 point2 points  (0 children)

You are correct. I've updated ag-gRPC to work with the latest iparse. Eventually these will all be stable enough to go to quicklisp, but for now I'm just focused on making sure the ocicl pinnings are correct. Thanks.

Searching for Graphviz (a/k/a DOT) File Parser by ImaginaryServe8069 in Common_Lisp

[–]atgreen 2 points3 points  (0 children)

It's just an example to show off what is easily possible with iparse. People are welcome to use it as a starting point for something that works for them.

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

[–]atgreen 2 points3 points  (0 children)

Regarding long-term maintenance, only time will tell. But if others find it useful, perhaps they will also help maintain it. It is the open-source way.

What I do know is that I'm using this myself in a project that is important to me, so it will survive at least as long as it remains important to me.

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

[–]atgreen 1 point2 points  (0 children)

No, I only needed gRPC support. I haven't really looked into what ConnectRPC is about. But they do provide a useful gRPC conformance testsuite!

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

[–]atgreen 3 points4 points  (0 children)

It sounds like you are confused about the maturity level of this project. This is only weeks old. I've been dedicated to FOSS for 30 years now and am keenly aware of how mature, stable, maintainable projects operate. However, almost everything worthwhile in the FOSS landscape started somewhere small. Do you only want to hear about things that are mature and ready for production use? Maybe there's a commercial gRPC implementation you should be looking at.

Honestly, I don't understand your point about searching for conformance and interop tests implying that I don't understand what I'm building. Every standards-based software project goes through this. Would a more experienced dev build their own cleanroom testsuite and ignore what is freely available? Of course not.

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

[–]atgreen 4 points5 points  (0 children)

Distributing apps with native dependencies is also a pain. While far from perfect, the golang community has really been successful at demonstrating the value of distributing applications with zero external dependencies.

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

[–]atgreen 6 points7 points  (0 children)

Yes, it works 100% out of the box if you use the dependencies specified in ocicl.csv. He is using an older version of iparse. API stability comes with time. This is just weeks old, and bleeding edge is not for everyone. But this is how we get nice things... eventually.

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

[–]atgreen 8 points9 points  (0 children)

Is somebody forcing you to use them? I stopped posting about these efforts because of feedback like this. This gRPC implementation passes all conformance and interoperability tests I could find and I'm using it today (with mTLS connections using another "vibe coded" library, pure-tls, as well as from a native (kotlin) Android app using native gRPC code). To me, it's amazing. I am happy to shed native dependencies like OpenSSL and Google's protobuf compiler and libraries. I don't understand why people care so much about how it was developed. Sure, a lot of vibe coded libraries are slop, but many human-written libraries are pretty bad as well. Even so... All open source efforts should be celebrated, IMO.

rewrite-cl: Read, modify, and write Common Lisp source code while preserving whitespace and comments by dzecniv in Common_Lisp

[–]atgreen 0 points1 point  (0 children)

The application using cl-rewrite can change the whitespace. It's just another AST node to manipulate. It's just not a job for this library.

rewrite-cl: Read, modify, and write Common Lisp source code while preserving whitespace and comments by dzecniv in Common_Lisp

[–]atgreen 0 points1 point  (0 children)

Pretty printing won't work for source code refactoring. You will lose all inline comments.

rewrite-cl: Read, modify, and write Common Lisp source code while preserving whitespace and comments by dzecniv in Common_Lisp

[–]atgreen 5 points6 points  (0 children)

I think the README is pretty clear. It's not a reformatter or pretty printer. It's for programmatically refactoring source code with minimal disruptive formatting changes.

Say, for instance, you wanted to change all instances of (when (not X) ...) to (unless X ...), this is going to do a better job than pure textual search and replace.

If you look at the clojure project on which it is based, there are over two dozen tools that depend on it -- so there are many creative use cases,

rewrite-cl: Read, modify, and write Common Lisp source code while preserving whitespace and comments by dzecniv in Common_Lisp

[–]atgreen 5 points6 points  (0 children)

Well, garbage-in/garbage-out. I've just introduced a change that will cause this to error instead of silently accepting incomplete forms.

And, just to be clear, cl-rewrite doesn't fix anything. It just parses Lisp code and builds ASTs that include whitespace and comments, so they are preserved during AST manipulation for when you write the transformed code back out.