rune
immer
rune | immer | |
---|---|---|
8 | 25 | |
387 | 2,431 | |
- | - | |
9.6 | 6.2 | |
13 days ago | 6 days ago | |
Emacs Lisp | C++ | |
GNU General Public License v3.0 only | Boost Software License 1.0 |
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.
rune
-
The Emacsen family, the design of an Emacs and the importance of Lisp (2023)
Two projects that may be of interest, related to this topic:
- Rune (https://github.com/CeleritasCelery/rune) - A re-implementation of Emacs but in Rust (like Remacs, but actively developed)
- Pimacs (https://github.com/federicotdn/pimacs) - Same, but using Go (created by me, but developed in a very slow pace)
-
Text Editor Data Structures
[2] https://github.com/CeleritasCelery/rune/issues/17#issuecomme...
- rune: Rust VM for Emacs
-
Design of Emacs in Rust
I second this ! I had trouble finding the github link, but here is is https://github.com/CeleritasCelery/rune
- Rune: An experimental Emacs Lisp interpreter written in Rust
-
Implementing a safe garbage collector in Rust
> How is anything rooted here? The lifetime changed from 'arena to 'root but I don't see a root being created.
In this example, the Vec has been rooted previously. So pushing an object into the Vec will make it "transitively" rooted (accessible from the root). You would root a struct with the root_struct![1] macro, which works very similar to the root! macro shown in the post.
However you made you realize one error; The rooted `Vec` in the example you pointed is a by value type, but in the implementation you can only get references to rooted structs, so that example needs to be updated.
> But later we see roots not obeying a LIFO order, under "Preventing escapes" where roots are dynamically created and destroyed in an arbitrary order.
Objects are just a copyable wrapper around a pointer, so they are not the part that has the LIFO semantics. inside the root! macro[2] there is a `StackRoot` type that is the actual "root". The object just borrows from that so that is has a 'root lifetime and is valid post gc. The actual root struct is not exposed outside of the macro.
I hope this makes the distinction between "roots" and "objects" clearer. Objects are just pointers to heap data. When we root an object we store the data it points to on the root stack and create a new `StackRoot`. Then we say this object is rooted. But the struct that "does the rooting" is inside the macro and not exposed. Rooting a struct works similarly.
[1] https://github.com/CeleritasCelery/rune/blob/5a616efbed763b9...
-
I came to the conclusion that I wont learn Elisp...unless...
Hack on Rune
immer
-
Text Editor Data Structures: Rethinking Undo
I've been working on an editor (not text) in C++ and pretty early got into undo/redo. I went down the route of doIt/undoIt for commands but that quickly got old. There was both the extra work needed to implement undo separately for every operation, but also the nagging feeling that the undo operation for some operation wasn't implemented correctly.
In the end, I switched to representing the entire document state using persistent data structures (using the immer library). This vastly simplified things and implementing undo/redo becomes absolutely trivial when using persistent data structures. It's probably not something that is suitable for all domains, but worth checking out.
https://github.com/arximboldi/immer
-
Show HN: A hash array-mapped trie implementation in C
How does this compare to https://github.com/arximboldi/immer (other than the C/C++ difference)?
Also, it's my understanding that, in practice, persistent data structures require a garbage collector in order to handle deallocation when used in a general-purpose way. How does your implementation handle that?
-
Text Editor Data Structures
You might be interested in ewig and immer by Juan Pedro Bolivar Puente:
https://github.com/arximboldi/ewig
https://github.com/arximboldi/immer
See the author instantly opening a ~1GB text file with async loading, paging through, copying/pasting, and undoing/redoing in their prototype “ewig” text editor about 27 minutes into their talk here:
https://m.youtube.com/watch?v=sPhpelUfu8Q
It’s backed by a “vector of vectors” data structure called a relaxed radix balanced tree:
https://infoscience.epfl.ch/record/169879/files/RMTrees.pdf
That original paper has seen lots of attention and attempts at performance improvements, such as:
https://hypirion.com/musings/thesis
https://github.com/hyPiRion/c-rrb
-
value semantics and spans/views
You’re absolutely right, however people have been putting in the “extra efforts” required for efficiency. Check out immer if you’re interested.
-
How to synchronize access to application data in multithreaded asio?
The C++ immer library: https://github.com/arximboldi/immer
-
Purely Functional Data Structure by Chris Okasaki [pdf]
For C++ check this one out - https://github.com/arximboldi/immer
- Persistent and immutable data structures written in C++14
-
Introducing B++ Trees, a C++ B+ Tree library
Yeah I agree that I should link that wikipedia page in the docs, I'll do that as soon as I get a chance. immer (https://github.com/arximboldi/immer) also links that page in its docs, for the exact same reason I'm sure. Interestingly, there is a lot of overlap between persistent data structures in the functional programming sense and persistent data structures in the persisted-to-disk sense because persistent data structures in the FP sense are one of the best ways to guarantee atomic updates and safe failure recovery in a persisted-to-disk system! Btrfs and ZFS, as well as many databases, are at their core basically just copy-on-write B+ trees.
-
What are some architectural patterns for creating a game editor.
I’ve never tried it, but I love the idea of implementing editor scene state using immutable data structures like https://github.com/arximboldi/immer With that, every edit would append a new node to a list of scene states. Undo/redo becomes iterating your view of the scene up and down through that list. Can’t screw up an undo function if there’s never any work to do :P
-
TypeScript Without Side Effects
I have! I think it's related to the C++ immer library which I used several years ago in Vortex. It's kinda like the previous generation of ValueScript. 🍻
What are some alternatives?
dotemacs
babashka - Native, fast starting Clojure interpreter for scripting
c-rrb - RRB-tree implemented as a library in C.
clj-kondo - Static analyzer and linter for Clojure code that sparks joy
gc-arena - Incremental garbage collection from safe Rust
graalvm-clojure - This project contains a set of "hello world" projects to verify which Clojure libraries do actually compile and produce native images under GraalVM.
racket - The Racket repository
ewig - The eternal text editor — Didactic Ersatz Emacs to show immutable data-structures and the single-atom architecture
boa - Boa is an embeddable and experimental Javascript engine written in Rust. Currently, it has support for some of the language.
deprecated-coalton-prototype - Coalton is (supposed to be) a dialect of ML embedded in Common Lisp.
mmtk-core - Memory Management ToolKit
awesome-modern-cpp - A collection of resources on modern C++