lparallel
Eclector
Our great sponsors
lparallel | Eclector | |
---|---|---|
4 | 4 | |
239 | 104 | |
- | 0.0% | |
0.0 | 7.8 | |
over 1 year ago | about 2 months ago | |
Common Lisp | Common Lisp | |
BSD 3-clause "New" or "Revised" License | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
lparallel
-
Request for help merging PR to lparallel
A while ago (pretty long while actually) i've found this inconsistency in setting thread bindings in lparallel. Fixed it with this little PR https://github.com/lmj/lparallel/pull/41
-
Consuming HTTP endpoint using Common Lisp
Parallel First package to use is lparallel to enable parallel processing without much coding on my side. Thing are easy here, you define lparallel:*kernel* with number of workers available for parallel tasks, define channel to receive results and start coding. I have actually used approach that does not even require channel for results.
-
A vision of a multi-threaded Emacs
Users should work with higher level primitives like tasks, parallel loops, asynchronous functions etc. Think TBB, Thrust, Taskflow, lparallel for CL, etc.
-
Are there public experiments with parallel and concurrent lisp 'engines'?
Observe, I am not asking for libraries or frameworks to enable writing threaded or task based and concurrent user applications, I am aware of those myself, for example lparallel for CL. What I am interested about is, if it is worth, or even possible, to parallelize core lisp runtime itself.
Eclector
-
Csexp: S-Expressions over the Network
I think this should be safe: https://github.com/phoe/safe-read
This doesn’t provide such functionality out of the box, but it makes it pretty trivial to produce a custom READ that only has the features you want: https://github.com/s-expressionists/Eclector
-
Re-targeting (Lisp) compilers
There is significant overlap with SICL and its associated pieces which supply many of the other parts needed to make a Common Lisp. Some of these are Cluster which provides a portable and extensible assembler, Eclector which supplies a portable and extensible reader, Concrete-Syntax-Tree that supports source code tracking during compilation, ctype that implements the Common Lisp type system, and Clostrum that provides first-class environments for e.g. run-time, evaluation, and compilation. The SICL project has as one of its goals the creation of portable infrastructure for implementing Common Lisp, and these pieces are novel building blocks that were created as part of the project.
-
Are there public experiments with parallel and concurrent lisp 'engines'?
You mean the parts of the reader that is capable of reading from a stream object and returns strings, booleans, numbers? These are just functions that accept a stream and they return Lisp objects. See e.g. Eclector for an implementation of a Lisp reader as an external library.
-
Lowercased version of Common Lisp with case preserving readtable (:PRESERVE)
I'm aware of eclector; hoping to take a look some day.
What are some alternatives?
oneTBB - oneAPI Threading Building Blocks (oneTBB)
SICL - A fresh implementation of Common Lisp
nyxt - Nyxt - the hacker's browser.
Taskflow - A General-purpose Parallel and Heterogeneous Task Programming System
luckless - Lockless data structures for Common Lisp
emacs-request - Request.el -- Easy HTTP request for Emacs Lisp
wat-js - Concurrency and Metaprogramming for JS
Thrust - [ARCHIVED] The C++ parallel algorithms library. See https://github.com/NVIDIA/cccl
ctype - CL type system implementation
HVM - A massively parallel, optimal functional runtime in Rust
cl-secure-read - Securing a reader in spirit of Let Over Lambda