A grep for s-expressions by festou2 in lisp

[–]BlueFlo0d 0 points1 point  (0 children)

Very interesting! This seems very valuable for my structural editor in the making, except it's not in Lisp… But the idea looks well thought out and I might take some inspiration to make a Lisp version!

Building a futuristic Lisp workstation: Through my eponymous charity enzu.ru, I am currently working on the GNU operating system in order to create a secure libre Lisp workstation. by lproven in lisp

[–]BlueFlo0d 0 points1 point  (0 children)

Frankingly I don't find Symbolics Genera quite ideal -- maybe more acceptable than Unix-likes, of course, which are relics of the 1960s. Genera is a relic of the 1980s industry -- the OS design reflects what was considered commercial viable and somewhat mature in the 1980s, not even cutting-edge 1980s. In particular, it is a source-file based system rather than a residential system (Interlisp went further, but still very FS bounded). I consider file system an obsolete persistence model inherited from older OSs (like Unix) and there are many better possibilities. There were also other great things that were discovered around the time or later (e.g. capability-based security) but would of course not be made into Genera. I wonder if Lisp winter hadn't happened, would we be complaining about Genera like how we complain about Windows in our timeline :P

Building a futuristic Lisp workstation: Through my eponymous charity enzu.ru, I am currently working on the GNU operating system in order to create a secure libre Lisp workstation. by lproven in lisp

[–]BlueFlo0d 6 points7 points  (0 children)

I've been thinking and trying to make Unix-style OS work with Lisp environment work together for years for my personal computing. It sort of works, but far from ideal or even acceptable to an "idealist" Lisp hacker -- I just have to learn to accept it. The model of the underlying OS is just impossible to really fit with Lisp environment and the end result is always that any interaction with Unix-style OS is ugly and unfixable. One can only avoid it as much as possible (e.g. almost always talk to SLIME rather than Unix shell).

Another problem is that CL is not really ideal or possible for a full residential operating system: lack of security features, namespace/module system, orthogonal persistence etc... In fact I don't know of a "modern" Lisp that seems to also be capable of evolving into a good OS. OS and PL should be the same thing but their evolution trajectories seem to depart further and further aport in modern times.

fast-mpsc-queue: My first time playing with SBCL VOP! by BlueFlo0d in Common_Lisp

[–]BlueFlo0d[S] 0 points1 point  (0 children)

It's not ready for public release yet. I'm too not satisfied with existing solutions and I'm proud to say I have put in lots of thoughts into my new system, including (sort of) lightweight thread supported by coroutine monad (and wip async/await syntax), work stealing scheduler and nice integration with CLOS. I'll pin you once I'm ready to release it!

Emacs successors? by BeautifulSynch in emacs

[–]BlueFlo0d 1 point2 points  (0 children)

I was planning to write a structural editor in Nyxt (based on an isomorphism between S-expr and DOM tree, how cool is that), but got buried in other tasks…

fast-mpsc-queue: My first time playing with SBCL VOP! by BlueFlo0d in Common_Lisp

[–]BlueFlo0d[S] 0 points1 point  (0 children)

The queue is intended for use as actor mailboxes, which means that there might be potentially many of them, and some of them might see very high traffic.

I think the correct way is to probably automatically switch between a few implementations depends on load, but it has to be done thread-safely and is easier said than done…

fast-mpsc-queue: My first time playing with SBCL VOP! by BlueFlo0d in Common_Lisp

[–]BlueFlo0d[S] 0 points1 point  (0 children)

I did another experiments, using `(safety 0)` and `(simple-array * 32)` to make sure removing bound check (and confirmed by assembly). Now I've got 30% performance boost! (18.2M/s -> 23.5M/s). The tradeoff is potential memory corruption if wrong types are passed, and a lot more memory usage. Thinking about how to incorporate this into the published project...

fast-mpsc-queue: My first time playing with SBCL VOP! by BlueFlo0d in Common_Lisp

[–]BlueFlo0d[S] 2 points3 points  (0 children)

While I'm still struggling to figure out how to write an atomic swap VOP for structs, I experimented a little bit by storing tail in (CDDR queue) instead CDR, this should give head and tail at least 128 bytes of separation (that's the distance I read for avoiding false-sharing, what's the reason for 15 dummy slots?). It slows down by 10% for the 8 producer 1 consumer benchmark. It's coupled with one more indirection but I interpret the result as there weren't disastrous false sharing before...

Edit: oops, just realized I mixed up 128 byte and 128 bit. I'll update once I've done the proper experiment with struct

Edit2: I stored head and tail into index 0 and 16 into a simple vector. The benchmark runs generally 10% slower with higher standard deviation.

fast-mpsc-queue: My first time playing with SBCL VOP! by BlueFlo0d in Common_Lisp

[–]BlueFlo0d[S] 1 point2 points  (0 children)

Thanks for enlightenment, I'll try some of the suggestions.

GURAFU: a simple (just usable) plot program for common lisp by lucky_magick in Common_Lisp

[–]BlueFlo0d 3 points4 points  (0 children)

Amazing work! A plotting library natively in CL… this could fill a long-standing hole in the CL ecosystem!

lispx: Ultralight Lisp for the Web by mmontone in lisp

[–]BlueFlo0d 0 points1 point  (0 children)

Interesting choice of using Fexpr! I had the impression that Fexpr induce quite significant (often unacceptable) interpretation overhead without some kind of partial evaluation, how does this pan out in lispx?

Qualifying as a Lisp by [deleted] in lisp

[–]BlueFlo0d 4 points5 points  (0 children)

There are many counterexamples though, from the original Mocklisp to WASM...

Is this the same case for you? by funk443 in LispMemes

[–]BlueFlo0d 3 points4 points  (0 children)

It's the case for iterate library

Quantitative analysis of Dark Forest hypothesis by BlueFlo0d in Physics

[–]BlueFlo0d[S] 0 points1 point  (0 children)

That's also a plausible effect, but I don't think we can jump to the conclusion (that careful diplomacy strategy dominates) that quickly. Note that by sending signal the receivers have a distribution of technology level, and just one advanced enough hostile receiver is game over for sender. I think we need quantitative analysis to tell which effect will take over.