core.async

Clojure: log to console when code is being executed in a go block or thread

喜夏-厌秋 提交于 2019-12-12 00:20:01
问题 With many go blocks going at once, all writing to the console, the text can get jumbled/intermingled when it arrives at the console. How to avoid this, so trace output forms as correctly in the console as intended when it was emitted from within the go block? 回答1: This answer uses core.async itself. The following from a talk: ;;;;; Logging Handler ;;;;; (def log-chan (chan)) (thread (loop [] (when-let [v (<!! log-chan)] (println v) (recur))) (println "Log Closed")) (close! log-chan) (defn log

Code not called from go block, but it works from REPL

蹲街弑〆低调 提交于 2019-12-11 13:44:39
问题 I have code that updates the DOM. new-recipe! calls an API to get a new recipe string. update-recipe-state next updates this state in the screen. Finally we have a call to update-transition-buttons . (defn- add-listener-to-recipe-button! [] "Listens to go button, creates a new recipe and displays it" (create-click-event-listener! (dommy/sel1 :#button-start) #(go (new-recipe!) (<! (timeout 2000)) (update-recipe-state!) (<! (timeout 2000)) (update-transition-buttons! "onboarding")))) ;; define

Clojurescript - Uncaught Error: <! used not in (go …) block

*爱你&永不变心* 提交于 2019-12-11 09:15:25
问题 I am in Clojurescript, and trying to use core.async to get a result from a native Javascript function (I am in the browser), and conditionally integrate it into a map. I have a function to wrap a native browser call (inspired by Timothy Baldridge's talk on core.async, approx. 34 min for those interested) : (defn geolocation [] (let [c (chan) cb (fn [e] (put! c (js->clj e)))] (if (exists? js/navigator.geolocation) (.getCurrentPosition js/navigator.geolocation. cb cb) (put! c {:error

Clojure core.async. How to download lazily with go block inside with-open?

99封情书 提交于 2019-12-11 03:48:02
问题 It`s a continuation of my previous question How to produce a lazy sequence by portion in clojure? I want download data from a database by portions. Initially I download first 500 rows and then I send a request to fetch next 500 rows and so on until I receive all data from a server. I wrote the code: (jdbc/atomic conn (with-open [cursor (jdbc/fetch-lazy conn [sql_query])] (let [lazyseq (jdbc/cursor->lazyseq cursor) counter (atom 1)] (swap! lazyseq_maps assoc :session_id {:get_next? (chan 1)

How to memoize a function that uses core.async and blocking channel read?

佐手、 提交于 2019-12-08 08:21:25
问题 I'd like to use memoize for a function that uses core.async and <!! e.g (defn foo [x] (go (<!! (timeout 2000)) (* 2 x))) (In the real-life, it could be useful in order to cache the results of server calls) I was able to achieve that by writing a core.async version of memoize (almost the same code as memoize): (defn memoize-async [f] (let [mem (atom {})] (fn [& args] (go (if-let [e (find @mem args)] (val e) (let [ret (<! (apply f args))]; this line differs from memoize [ret (apply f args)]

How to memoize a function that uses core.async and non-blocking channel read?

混江龙づ霸主 提交于 2019-12-05 12:19:12
I'd like to use memoize for a function that uses core.async and <! e.g (defn foo [x] (go (<! (timeout 2000)) (* 2 x))) (In the real-life, it could be useful in order to cache the results of server calls) I was able to achieve that by writing a core.async version of memoize (almost the same code as memoize): (defn memoize-async [f] (let [mem (atom {})] (fn [& args] (go (if-let [e (find @mem args)] (val e) (let [ret (<! (apply f args))]; this line differs from memoize [ret (apply f args)] (swap! mem assoc args ret) ret)))))) Example of usage: (def foo-memo (memoize-async foo)) (go (println (<!

Clojure core.async, CPU hangs after timeout. Anyway to properly kill macro thread produced by (go..) block?

此生再无相见时 提交于 2019-12-05 05:42:32
Based on core.async walk through example , I created below similar code to handle some CPU intensive jobs using multiple channels with a timeout of 10 seconds. However after the main thread returns, the CPU usage remains around 700% (8 CPUs machine). I have to manually run nrepl-close in emacs to shut down the Java process. Is there any proper way to kill macro thread produced by (go..) block ? I tried close! each chan, but it doesn't work. I want to make sure CPU usage back to 0 by Java process after main thread returns. (defn [] RETURNED-STR-FROM-SOME-CPU-INTENSE-JOB (do... (str ...))) (let

What are the tradeoffs of the ways to do work in a clojure core.async go-loop?

喜你入骨 提交于 2019-12-04 09:12:01
As I write more core.async code, a very common pattern that emerges is a go-loop that alts over a sequence of channels and does some work in response to a message, e.g.: (go-loop [state {}] (let [[value task] (alts! tasks)] ...work... (recur state)) I don't feel like I understand the tradeoffs of the various ways I can actually do the work though, so I thought I'd try to explore them here. Inline or by calling a function: this blocks the loop from continuing until the work is complete. Since it's in a go block, one wouldn't want to do I/O or locking operations. >! a message to a channel

Isn't core.async contrary to Clojure principles?

风格不统一 提交于 2019-12-03 05:27:50
问题 I have seen many Clojure programmers enthusiastic about the new core.async library and, though it seems very interesting, I am having a hard time seeing how it conforms to Clojure principles, so I have these questions: It uses mutable state everywhere, as the function names suggest by having an exclamation mark, like alt!, put!, >!, and others. If you put or take a value from a channel, that channel is modified inplace. Isn't it contrary to Clojure philosophy of preferring immutable data

Can I make a fully non-blocking backend application with http-kit and core.async?

你离开我真会死。 提交于 2019-12-03 01:39:47
问题 I'm wondering if it's possible to put together a fully non-blocking Clojure backend web application with http-kit. (Actually any Ring-compatible http server would be fine by me; I'm mentioning http-kit because it claims to have an event-driven, non-blocking model). EDIT: TL;DR This question is a symptom of some misconceptions I had about the nature of non-blocking/asynchronous/event-driven systems. In case you're in the same place as I was, here are some clarifications. Making an event-driven