The original author is involved with PyPy afaik

this is a read-only transaction https://gist.github.com/michiakig/1093917#file-ants-clj-L265

I would like to write something more complete than the following belief at some point, but I am pretty sure that having atoms/refs/agents nested within the values 'contained within' other things of those kinds, can lead to incorrect behavior of updates to their contents.

@U0CMVHBL2, would love to see the more complete follow up! I assumed that nested refs should be technically possible, but would love to have more details how that would or wouldn't work either way

I suspect it is simpler to create cases where atom-within-atom has update bugs, and then see if that generalizes to single-ref within single-ref examples.

well, atoms within atoms definitely fails for trying to obtains a consistent snapshot

I'll definitely ping you if I do write up anything there, but isn't among the hottest 10 things on my plate right now.

awesome!

I realize I'm definitely off in the weeds, but it's fun to explore!

I wouldn't answer if they weren't weeds I would like to understand in more detail myself 🙂

@U0CMVHBL2, one last question if you ever get time: In the ants simulation, the https://gist.github.com/michiakig/1093917#file-ants-clj-L34. if the model did allow the world to shrink and expand, how would that be modeled? My assumption was that you would simply use a ref for the world rather than a var, but I would love to know if there is a better approach or if using a ref which contains other refs is fundamentally broken.

If you stop the simulation in some suitably clean way, then you could re-bind the var to a larger world, I would think. Are you asking about how one might model the world to change size in a concurrency-safe way?

I am not sure if this makes sense, but if you access every ref in the entire world in a way that would update the contents of every ref (i.e. every cell), then it seems like it might be safe to change the size of the world during such a transaction, but that is just me guessing out loud, so far.

Adding new cells seems like it might be easier in some sense, since you know the new cells cannot be involved in any transactions until after they have been added to the world. Removing cells/refs seems trickier to get right.

I've made a version of the original ants that allows the world to grow and shrink that seems to work :https://github.com/phronmophobic/ants/blob/master/src/ants/ants.clj Overview of changes: • world is now a ref:

(def world
  (ref
   {:places
    (apply vector 
           (map (fn [_] 
                  (apply vector (map (fn [_] (ref (struct cell 0 0))) 
                                     (range initial-dim)))) 
                (range initial-dim)))}))

(defn set-world-dim! [new-dim]
  (dosync
   (alter world
          update :places
          (fn [places]
            (apply vector 
                   (map (fn [i] 
                          (apply vector (map (fn [j]
                                               (get-in places [i j]
                                                       (ref (struct cell 0 0)))) 
                                             (range new-dim)))) 
                        (range new-dim))))
          ))
  nil)

I understand putting most mutable objects within a ref would have issues, but are there issues specifically with nesting refs?

refs are subject to write skew, so if you are going to nest them you should at least use ensure

that's good to know!

but like, if your interest is in guis, you should look at elm, and thing about the state being passed around as an immutable database, with each phase (or whatever elm calls them) returning a possibly updated database

I have indeed spent a bunch of time looking at Om, Om next, elm, react, reagent, fulcro, hoplon, cljfx, re-frame, svelte, and others

it is a perennial thing that people keep trying to build these dataflowy mutable cell things for doing uis

the rock they all founder on is starting from mutable stuff, regardless of how much you put around the mutability (stm, etc) to try and make it "safe"

the references for this would be at the edges

instead of trying to bind a ui component to a mutable cell, instead bind a ui component to a query on an immutable database and an update message to change the state of that database

ui components aren't bound to mutable cells. they're still pure functions. the idea would be to use refs as a model and produce a single immutable value from the model before handing it to the ui component

I'd also suggest that is a the universe telling you not to use create threadpools using static initializers

available=12 (ryzen power)

not using statics means drilling it down from the first Singleton parent object to make sure its created only once

Maybe I should just stick to common pool. No one should go crazy with their callbacks anyway, thx

I would maybe replace that while loop and whatever consumers is with a loop polling a linkedblockingqueue

collapsing all the weird conditions into a single x = q.poll(); if(x == null) ... else ...

I wouldn't be surprised it changing it to a static initializer altered the timing enough that it exposed some races/deadlocks

vim / nvim has had undo-tree for ages

(as a plugin for ui, but the underlying tree structure was always there IIRC)

yeah, confirmed, the tree is built in, the UI is a plugin

Do you actually use the tree structure of saved-in-memory Emacs undo state, then? Even with a graphical tool for exploring such a thing, I would personally feel a lot safer having those states in separate files, or at least separate revision-controlled branches in git or similar.

for the vim version, the tree introduces a new node for each recovered state from the tree, no action removes an item from that tree

I don't use it for long term differences, I use it when I realize something I deleted five minutes ago might be useful to restore

and yeah I git commit often, so that is my "checkpoint"

IntelliJ also tracks history, not sure I would want it in a tree. Even removed files are easily set back from the history of the folder.

Yep, eclipse does the same and I cannot remember not having been able to go back to an older state because the history was linear and not tree like.

I wonder what the advantages of a tree like undo would be?

a tree like undo means that I can undo, try changes, undo again, try other changes, undo again, try more changes, and all states since opening the file are still accessible

I would never want to create that many git branches

and I don't always know until later "oh, the fourth thing I tried is what I want here"

finally, this means I never leave weird code in a file "because I might want to try it again later"

I get it, thank you for explaining the advantages 🙂

I guess a three structure would help in that case. You can still do the same with IntelliJ. It's linear, but append only, so going back creates a 'revert' change.

oh, interesting - so it's like event-sourcing editor changes :D

(and thus the content of the editor is a materialized view...)