This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (1)
- # beginners (163)
- # boot (1)
- # bristol-clojurians (1)
- # cider (7)
- # clara (1)
- # cljs-dev (22)
- # cljsjs (1)
- # clojure (43)
- # clojure-denver (1)
- # clojure-finland (6)
- # clojure-italy (1)
- # clojure-nl (3)
- # clojure-russia (1)
- # clojure-spec (1)
- # clojure-uk (6)
- # clojurescript (107)
- # cursive (4)
- # data-science (2)
- # datascript (2)
- # datomic (19)
- # duct (31)
- # emacs (1)
- # fulcro (50)
- # graphql (15)
- # hoplon (3)
- # lein-figwheel (2)
- # luminus (21)
- # off-topic (74)
- # onyx (3)
- # parinfer (15)
- # portkey (2)
- # precept (9)
- # proton (1)
- # re-frame (130)
- # reagent (73)
- # reitit (7)
- # ring-swagger (5)
- # shadow-cljs (61)
- # spacemacs (18)
- # specter (12)
- # uncomplicate (1)
- # vim (88)
- # yada (2)
Is it possible to rewrite https://github.com/zjhmale/intellij-paredit/blob/master/src/zjhmale/paredit/SpliceAction.java#L9-L39 using just proxy? The nested class confuses me.
@the2bears: because I have an unhealthy obsession with preferring to rewrite libraries in Clojure instead of just modifying the java impl.
@qqq I don't see any reason why you can't rewrite this in Clojure. You just need the two types, the Action and the Handler. I would ignore the nesting/static nature of the handler, I don't think it's anything more than a logical way to organize the static class into the outer parent's name space. It is a member of the outer class, but that doesn't matter much in this example.
Hello 🙂 In some situations all of my core.async threads are either dead or stuck ( I've no idea which ), I know that they are stuck because when I connect to the remote REPL on that process, this line hang and won't return:
[[email protected] current]# rlwrap telnet localhost 5555 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. user=> (clojure.core.async/<!! (clojure.core.async/go (println "hi!")))
@elevi that is because <!! is a blocking operation. it will block until there is input on the channel to take, which will never happen here
There's a limited number of threads available to go blocks. Those 8 threads could be blocked.
@tbaldridge yea so I'm apparently cause them to hang or crash, how can I debug it ? what do you guys do in these situations ?
So I'd start with looking at your channel operations. You shouldn't be doing IO or calling
<!! inside a
go block or inside any function called by a
If you are, you can switch those
go blocks to
core.async/thread as a test, or even switch them permanently.
be aware of possible false positives. You can be blocking 9 threads, and then unblock one, and suddenly the app will work, even though the remaining 8 go blocks are still configured improperly.
Feel free to post any common code here, it's a bit hard to give other suggestions without seeing the code.
Yea I use the
go blocks extensively in my program so it will be a bit hard to share all of them
what’s the basic intuition for the overhead of an anonymous function? in my mind it should be roughly like creating a hash map for the closed-over variables, but perhaps its more expensive than that?
@lee.justin.m no it's a lot cheaper than that, it's the cost of newing up a class.
okay great. thanks. i’m creating a ton of them but the thing they represent is way more heavyweight than that so that shouldn’t be a problem
if you're using clojure.java.jdbc (which yesql uses underneath the hood), you can extend the protocol
clojure.java.jdbc/IResultSetReadColumn to handle arrays
(extend-protocol clojure.java.jdbc/IResultSetReadColumn org.postgresql.jdbc.PgArray (result-set-read-column [pgobj _ _] (vec (.getArray pgobj))))
if you want to go the other direction (i.e. use an array as a value for a
? type arg):
(extend-protocol clojure.java.jdbc/ISQLParameter clojure.lang.IPersistentVector (set-parameter [v ^java.sql.PreparedStatement stmt ^long i] (let [conn (.getConnection stmt) meta (.getParameterMetaData stmt) type-name (.getParameterTypeName meta i)] (if-let [elem-type (when (= (first type-name) \_) (apply str (rest type-name)))] (.setObject stmt i (.createArrayOf conn elem-type (to-array v))) (.setObject stmt i v)))))
for the note, I'm pretty sure that
getParameterMetaData queries the DB for information about the query, so you have an extra round trip if you use a vector as a parameter, so I'd use that pretty sparingly.
The reading of a vec has very little overhead
@elevi put! never blocks at all, but you need to make sure you handle back pressure by giving it a callback that limits how quickly future items are put onto the channel.
Is this back pressure handling you describe for ensuring you don't have too many pending puts on a channel?
@souenzzo with this library you can use a seed as a dynamic binding for it https://github.com/gfredericks/four/blob/master/src/four/stateful.clj
@elevi thread dumps can be helpful too. You can run
jstack $PID or
kill -3 $PID to get all stacktraces (to jstack's or PID's STDOUT respectively), then look for
(clojure.core.async/go (Thread/sleep 30000)) => "async-dispatch-7" #171 daemon prio=5 os_prio=0 tid=0x00007fedac005000 nid=0x4b7f waiting on condition [0x00007fed34cd7000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at user$eval412060$fn__412065$state_machine__23531__auto____412066$fn__412068.invoke(NO_SOURCE_FILE:151) at user$eval412060$fn__412065$state_machine__23531__auto____412066.invoke(NO_SOURCE_FILE:151) at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:973) at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:972) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:977) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:975) at user$eval412060$fn__412065.invoke(NO_SOURCE_FILE:151) at clojure.lang.AFn.run(AFn.java:22) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)