Fork me on GitHub
#missionary
<
2023-10-02
>
denik06:10:14

Struggling to translate this core async based prepl example to missionary. any pointers? https://gist.github.com/eerohele/e06551b115c6a31d1280a115c4c2abb2

denik06:10:27

ultimately I’d like to end up with a synchronous simple eval fn that takes a string and returns the remote-prepl result for use in a local repl

reedho12:10:06

I think using atom and m/watch to create flow as input mechanism, then process the flow as usual.

reedho12:10:46

(def input (atom {}))

(def eval-task
  (->> (m/ap (let [x (m/?> (m/watch input))]
               ;; process, e.g. use read-string here
               (try (println "RESULT>>" (read-string x))
                    (catch Exception _e
                      (println "RESULT>> invalid input:" x)))))
       (m/reduce {} nil)))

(def dispose!
  (eval-task #(prn ::done)
             #(do (if (instance? missionary.Cancelled %)
                    (prn ::done)
                    (prn ::error %))
                  ;; cleanup here
                  )))

(reset! input 1)
(reset! input (pr-str "hello"))

leonoel12:10:45

the interesting part is to make it work over a socket

leonoel12:10:00

I have something working, I will publish a gist

reedho12:10:47

Very nice, as always.

reedho13:10:35

Fantastic, thank you Sir 🙏

reedho14:10:18

Pretty much every thing i know about missionary just in a page. There are tons more of course. 💯

denik15:10:10

very helpful, thank you @U053XQP4S !

denik19:10:11

@U053XQP4S this implementation seems to have an issue (even when running the server locally). The initial evals all work but after a few minutes the task deadlocks

denik20:10:22

not yet sure if this is related to the impl or missionary. it also only happens after and idle period of a few minutes. I’ve run evals every second on a loop and it holds up

leonoel05:10:37

I updated the gist. I learned PipedReader considers the pipe broken as long as the last writer thread is dead, which is a common scenario when writing is done via a thread pool. The bug can be reproduced consistently by sending a message and waiting for 60s (the default keepalive time for pooled threads). This means a single writer thread must be allocated for the entire pipe lifecycle. The core.async gist is likely broken in the same way, and propel uses a single writer thread probably for the same reason https://github.com/Olical/propel/blob/407ccf1ae507876e9a879239fac96380f2c1de2b/src/propel/core.clj#L120-L125

❤️ 1
👏 1
denik17:10:37

pro level debugging. thank you!