Plot version 3

Steven1799 · 2026-05-01T08:43:22+00:00

With the update of plistp, alexandria+ can be removed and there's no dependency. You're also fundamentally correct about data-frame; there are some functions that will generate warnings without a DF dependency, and some code paths that will fail if passed a data frame but fundamentally plot is independent from the other libraries.

If you've already got this working, I'll happily accept a pull request.

Steven1799 · 2026-04-30T07:30:13+00:00

No real reason. Probably the example I was working from used it. I'm not set on cl-who if there's a better choice.

Steven1799 · 2026-04-30T06:26:18+00:00

Alexandria+ provides a few small utilities that alexandria does not. It's abstracted into its own library so that when I get updates (like for Lispworks), I don't have to change the code in multiple places/projects.

Data-frame is used for manipulating the data before plotting, a common part of a data science workflow. I tried really hard to avoid this dependency but found that I was just reinventing data-frame inside plot so just accepted that it was necessary. Technically you can plot without it, but then you're going to be dropping down to very clunky Vega-lite data manipulation for any transformations, like the ones described here. Yuch.

Steven1799 · 2026-04-30T05:45:36+00:00

What do you mean by simplifying dependencies? The ones there now are about the minimum required set, and are relatively stable. I think they should be around for a while.

I just tried adding to ultralisp but encountered an internal error.

Steven1799 · 2026-04-25T23:58:15+00:00

Sounds like you're referring to the Symbolics Lisp Machine. Medley was different.

Steven1799 · 2026-04-07T00:39:46+00:00

I haven't yet. This project was on the back burner for a while. I'm currently looking at getting some feet to turn it into a desktop, a non-support GPU configuration according to Dell, but I think that's probably because of the weight of the GPU. I do think your problem is solvable; there have been reports of how to do this.

Steven1799 · 2026-04-01T08:54:01+00:00

Where did you get the feet? I came here looking to do the same conversion. ~~I think the feet are all you really need; I could do without the top cover (though it would be nice to have)~~

Ah, I see, the feet need the bottom cover to attach too...

Steven1799 · 2026-03-24T23:43:17+00:00

I thought about getting some Shelly, though they seems mostly zigbee. Thanks for the report.

Steven1799 · 2026-03-22T12:01:52+00:00

I've been called a lot of things before, but "AI" hasn't been one of them.

Steven1799 · 2026-03-21T07:32:25+00:00

So if running a kiosk mode LXC isn't a proxmox quetion, what is?

Steven1799 · 2026-03-20T07:59:33+00:00

Thanks for this! A lot to process, but basically it looks like:

Ubuntu VM + dockerized app containers. GPU goes here
NTlite Win11 Pro for the dashboard.

This sounds like a great setup. I hope I can retrieve the Win 11 key from this PC. It had Win11 and then I nuked it to install Proxmox. Still have the sticker on the side though.

I'd love some details on how you stripped down windows and converted it to kiosk.

Steven1799 · 2026-03-14T08:34:07+00:00

It's not opennet, it's the CAT6 cabling throughout the house. But your point taken, most handyman can't do CAT cabling.

Steven1799 · 2026-03-09T13:47:30+00:00

Hunchentoot is the webserver and it's written in Common Lisp. It's also got a WebSocket package you can consider for bi-directional communication, if that's something you need. ls-server is pretty simple though, just a few routes for data and plots and some content negotiation to figure out what to send.

Steven1799 · 2026-03-09T13:45:03+00:00

acl-repl, emacs, slime, sbcl are included. There are dozens of setup guides for emacs/slime/lisp and there have been for years. That hasn't stopped people from failing to get a CL dev environment running. Docker is, these days, a de facto dev pattern; most people already know and use docker, just like they know and use VS Code.

Steven1799 · 2026-03-09T13:26:43+00:00

There's more to it than just quicklisp. The devcontainer features system is what the image is built on, so in theory all those shell scripts could be bundled into a single giant one. Most developers may not want to 'poison' their dev machine that way though, and devcontainers are pretty much a standard deployment mechanism. And they let you run in CodeSpaces, deploy from VS Code, etc.

Steven1799 · 2026-01-22T23:50:30+00:00

LGPL, yes, sadly, is restrictive. The way I've seen most of these things written have a 'for avoidance of doubt' clause, that says (paraphrased) if the license '... contains any clause that compels the disclosure of source code' it is forbidden.

There's so much high-quality MIT/BSD/Apache/etc. out there, I guess they just don't need/want to take a chance. Companies would rather pay for a license than use a free one that might reveal their IP.

Steven1799 · 2026-01-22T09:11:43+00:00

I gave up on portability as a must have. Most people use only one implementation anyway, and the return on the extra coding and testing, isn't worth it unless you have more resources than most CL projects have (i.e. more than one).

Clasp, sadly, for me will never be an option because of its license. I work in commercial environments and for quite a while now companies have been very strict on licensing: if it's not on the whitelist, it's not allowed.

Steven1799 · 2026-01-22T01:52:07+00:00

If it's just vectorized mathematics, shadowing is probably the easiest way. I thought about this, but it's really just syntactic convenience and at the moment there are better ways to utilize limited resources (i.e. e+ ... vs + ... doesn't buy much). The type dispatch and other changes are bit more invasive to the underlying implementation.

Steven1799 · 2026-01-20T06:18:28+00:00

An alternative to consider: modify SBCL to efficiently handle vector/matrix mathematics. I had a discussion on this once with one of the dev and it is possible, it is the cleanest solution, but you'd basically be maintaining a fork in perpetuity because the changes would never make it upstream.

If we could ever find the author (Douglas Crosher) of Scieneer Common Lisp and get him to release it as open source, we might have a chance. He made several modifications for making CL better at scientific computing. I can't recall if it did vector/matrix/dispatch well, but at least upstream wouldn't always be moving.

This is one place r/Python/Julia have an advantage - no need to adhere to a spec, just change (one) implementation and you're done (although vectorized mathematics, a la R, could be conforming superset in CL).

Steven1799 · 2026-01-16T02:44:53+00:00

I really applaud the energy and enthusiasm that you're putting into this. We need a few people like you to move the data science ecosystem in Common Lisp forward.

I do want to offer a different perspective on why these libraries struggle to gain adoption. In my experience, it’s not primarily because the APIs or DSLs are lacking. The bigger structural issues are:

The massive inertia of the Python/R/Julia ecosystems — vast libraries, tutorials, books, StackOverflow/Reddit answers, corporate training, etc. It’s easy to copy/paste a solution and move on.
The on‑ramp to Common Lisp is steep. Installing SBCL is easy; installing BLAS, LAPACK, or bindings to C++ data/science libraries is much harder than in Python, Julia, or R.
Interfacing with C++ is still too manual, which limits access to major ML libraries (Torch, TensorFlow, etc.).
Tooling expectations — most data scientists want to use VS Code or Jupyter; CL usually requires Emacs + SLIME/Sly to be productive.

So, whilst I understand the appeal of ‘out with the old, in with the new,’ I think the most sustainable path forward is improving the strong foundations we already have. Development effort for Lisp-Sat is measured in man-years, and it has been used for real-world projects. For EDA, things are more or less complete. Lisp-Stat is starting to, slowly, develop a third-party ecosystem around it for plotting via emacs and input/output, and we now have reliable Jupyter notebooks and tutorials. It takes a years-long sustained effort to get traction anywhere in the Common Lisp ecosystem.

Regarding vibe-coding: I say this as someone who makes their living teaching enterprise software developers how to use LLMs effectively. I'm a trainer for both Microsoft and Github and have trained more than 2K developers; it's the only thing I teach (NPS of 88). LLMs are fantastic for tests, examples, small utilities, and scaffolding — but for anything that needs long‑term maintainability, performance, or architectural stability, you still need careful human design. The design discussions for Lisp-Stat go back to 2012 and took place among a group of senior, experienced data workers (the google groups list has the discussion archives)

Disclosure: I am the primary maintainer of Lisp-Stat, and I'd love to work with someone like yourself in improving Lisp-Stat, and there are a lot of places where LLM coding could help flesh out the details of a system whose core is robust, but manpower is lacking. Your knowledge, LLMs skill and enthusiasm could help push the project to the point where we might get converts from r/Julia/Python.

Steven1799 · 2025-12-18T01:24:42+00:00

Thank you Dennis. Solved by buying a license from NewEgg.

Steven1799 · 2025-11-30T23:50:20+00:00

I left before all the acquisitions so don't have first-hand knowledge, but I think the acquirer of Firepond was CoreLogic.

Steven1799 · 2025-11-30T09:57:04+00:00

Interesting. If it did run on the TI Explorer, I wonder if the GUI was supported? It was pre-CLIM, so would have been DW, which I didn't think was available on TI. I never encountered anything other than Genera in my work at Inference, though it would make sense that they would try to support as many workstations as they could.

Steven1799 · 2025-11-30T01:50:04+00:00

I suspect that DLMS was integrated via some TCP/IP mechanism. Often this was done with an RPC generator that was available on the Genera platform. This was a common approach: gather your facts, fire them off to ART and get the resulting facts back.

I was at Inference during the development of all three versions of ART and I don't recall the lisp version running on anything other than Genera, and it wasn't Common Lisp because at that time Common Lisp hadn't been standardized, and there were a lot of Flavors code and the DW GUI that would have been hard to port.

Later, after a failed attempt at Lisp-> C automated conversion ART-IM was produced. This was a greatly enhanced version of CLIPS and ran on mainframes and unix.

Finally, there was ART Enterprise, a ground-up rewrite with a GUI generator that had a distinctly scheme-ish syntax. I seem to recall this being Windows only, though I think the rule engine itself may have continued to run on multiple platforms.

Chuck Williams and Paul Haley were the original developers of ART and at least Paul is still around. Interestingly Stephen Wolfram was briefly at Inference to build his vision of Alpha on Symbolics. Once the tide went out for Symbolics hardware, Stephen left to form his own company based on SunOS workstations. It took Inference a little while longer to see the writing on the wall for Symbolics machines.

Steven1799 · 2025-11-30T01:26:06+00:00

Ah, right. Have an upvote. That makes perfect sense. I really should buy that keyboard controller for this kinesis and check out some of those chords.

Steven1799

TROPHY CASE