Hey, Avon!

> I am trying to install the linear algebra module and running into 
> the following error when running (ql:quickload 
> 'up.mage.fern.linear-algebra):

So, in the debugger, it should also show which file it was loading when
the error happened. Could you look that up? There should be a mention
somewhere like this:

> #<CL-SOURCE-FILE "up.mage.utils" <---some file name--->>

(If there isn't, it's probably one of the dependencies then.)

> As I mentioned in the previous reply, one interesting aspect of the 
> automerge system is that it's underlying data structures have been fine 
> tuned for performance, as in the case of collaborative rich text 
> editing, documents can quickly gain thousands of operations which need 
> to be tracked. It will be interesting to see if you could take some of 
> these data structures (for example their binary document format: 
> https://automerge.org/automerge-binary-format-spec/#_introduction, and 
> the B-tree format they use to store operations) and re-use them in 
> specialized Hero repositories for certain data types. In general, I 
> think it would be quite interesting to see how CRDTs could inform the 
> design of new VCSs, and vice versa.

What I can tell is that in an environment of human-oriented structural
editing, it's a rather safe bet that documents will tend to have an

Hi, Avon,

So, the basic problem statement here is how one would go about
constructing an editor where multiple parties can participate (possibly
in real time, but that's really just a question of interactivity).

I am quite convinced this is not a problem which could be delegated to a
foreign library. Such a move would complicate the implementation, likely
hurt performance, and prevent the user from introspection. Delegating
the interactive problem of merging would as well be avoiding the problem
instead of facing it. The Upwelling article points out some issues that
emphasize these.

I mean, this stuff is destined to be native.

Hey, Yury,

> I'm developing modal editing with chords and tap dance that goes beyond convetional.
> I need a better engine. It could be used for Mage just as well as for Emacs. 
> Single minor roadblock is lack of KR documentation.  How is it going? Do you need help proofreading?

Well, KR by itself is essentially only a fancy object system. After it's
ready, then still comes the GUI-specific backend stuff (Fern) which will
actually enable working with user input and key events.

To answer your question directly, at this point, there are no up-to-date
docs for KR, but I will ping you once they are out just in case you
might be interested in proofreading then.

Yury Kholodkov <uristmclisper@yandex.ru> writes:

> Wouldn't it be nice to have them like in clojure? And fancy destructuring (https://clojure.org/guides/destructuring#_namespaced_keywords).

I think it's quite neat. But this approach seems limiting if you go
beyond symbols (or even if you just want to differentiate between
keywords and non-keyword symbols). KR objects use CL hash tables, and
those support specializing on eq, eql, equal, and equalp. In other
words, you could use any object for a key, and that can actually be very
nice. It's not clear what would be the consistent counterpart interface
for such keys in accordance with the namespaced keywords.

What's more, while the namespaced keyword approach would be slightly
more consise for short read commands aka

Hi, Avon!

So, to put your message in perspective, so far I see the problem of
syncing rather simply (if not crudely): as customizable repositories
that push and merge -- just as the usual decentralized repositories like
git, but with the added benefit of programmability and extensibility
within an interactive environment. And, indeed, KR objects will be used
as the basic units of interactivity when using such repositories.

Now, if I understand correctly, the Bramble protocol seems to work not
unlike torrent in some ways, but if I am getting it correctly, its
fundamental goal is to be a communications channel that's easy to use,
with a focus on message-passing over unreliable channels, with any
latency and with multiple actors. So, that's pretty cool, of course.

"Eric S. Londres" <ericlondres@outlook.com> writes:

Hi, Eric!

Thanks for the patch (the first one here!), but I am afraid you are
looking at the old code.  The new code is on the new-kr branch.

https://git.sr.ht/~project-mage/fern.kr/log/new-kr

I will merge that branch with master in a just a few days, once I have
added several other features first.

Cheers!