This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-02
Channels
- # announcements (13)
- # babashka (42)
- # beginners (29)
- # calva (39)
- # cider (15)
- # clerk (10)
- # clojure (67)
- # clojure-europe (18)
- # clojure-hungary (2)
- # clojure-nl (1)
- # clojure-norway (12)
- # clojure-uk (7)
- # clojuredesign-podcast (14)
- # clojurescript (19)
- # datalevin (1)
- # datascript (5)
- # emacs (4)
- # events (2)
- # fulcro (5)
- # graalvm (5)
- # hyperfiddle (23)
- # incanter (3)
- # jobs (2)
- # lsp (8)
- # missionary (15)
- # off-topic (45)
- # portal (41)
- # practicalli (1)
- # re-frame (3)
- # reitit (6)
- # releases (2)
- # remote-jobs (1)
- # sci (1)
- # shadow-cljs (35)
- # solo-full-stack (8)
- # tools-deps (4)
Struggling to translate this core async based prepl example to missionary. any pointers? https://gist.github.com/eerohele/e06551b115c6a31d1280a115c4c2abb2
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
I think using atom and m/watch to create flow as input mechanism, then process the flow as usual.
(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"))
Pretty much every thing i know about missionary just in a page. There are tons more of course. 💯
very helpful, thank you @U053XQP4S !
@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
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
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