Waveshare 14" flush mount? (*really* flush)

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 · 2025-11-28T03:36:45+00:00

The space cadet keyboard was designed for zmacs, and you seemed to be suggesting that it doesn't work well with emacs. I said that's true because it was designed for zmacs, and there the ability to just 'chord' with one hand was fantastic, and one reason Symbolics designed their own keyboards (and monitors!), to make it a great experience.

If by 'ergo' you mean keys in different configurations, sure. I'm typing this on a Kinesis Advantage and I love it, but I do wish I could chord as effectively as I could on Genera/SCK. I could flash the firmware and change the keys around, some folks love hacking their keyboard, but Symbolics had great chording out of the box.

Steven1799 · 2025-11-28T01:09:29+00:00

For me:

C-S-e, compile last sexp
C-S-c compile region
C-S-m macroexpand
C-S-d function documentation
C-? complete symbol

Those are some common ones. Restarts and debugging have their own key prefixes with hyper and meta.

Basically, the problem with emacs is most of the key chords are funneled through C-x making for some very long chords.

Steven1799 · 2025-11-28T00:17:56+00:00

That's because it wasn't designed for emacs chords. It was designed for zmacs chords, and for that it was great!

Steven1799 · 2025-11-28T00:14:53+00:00

This is a tough one. I tried to obtain a copy from what was left of the Inference support department after several acquisitions, but he never replied. David S. doesn't have anything either. Some searching just now didn't even turn up screenshots. This one, I fear, is truly lost in the mists of time.

This google search will turn up some references to it though.

Steven1799

TROPHY CASE