Fork me on GitHub

what is the “x” part?


well. that’s what it normally means.


dun make sense here tho


yes x normally means cross. but what is a cross relation


I was thinking it would be akin to a projection mapping {a-lvar "foo", b-lvar "bar"}


so you’re “forming a cross relationship” between logic variables and keys


idk tho, seems less-than-applicable here


I think the place to start with xrel is


(and I think is "further reading" as they say... based on natural joins and projections and so on)


Xrel if I remember correctly is just a set of maps


Right @didibus but why "xrel"? I can't find where that shorthand comes from.


Maybe the x doesn't signify anything in particular, and xrel could equally well be named rel1. If you look at, it has xrel and yrel as its arguments.


Ya I see it just as relation x


Same as xs is used for sequence x


Are there libraries that aid in code generation? For example, eth_blockNumber is a JSON-RPC method name. What if I want to auto-generate a shim block-number in the namespace eth that will call the former method under the hood?


In the Beckman-Hickey video, Rich talks about a branching factor of 32 for the persistent data structures. Is this why lazy sequence chunks are of size 32 each?


I don't think there is any dependency either way there.


Hi, everyone Why can't we define :pre and :post conditions when implementing protocol fns ?


I would guess that both of those are chosen for having node/chunk sizes that occupy all of one cache line on most processors, and perhaps 2 or 4


and likely some performance experiments and tradeoffs between speed and memory usage.


[re-posted to #core-async as there is a different behavior for it and the difference below seems to be due to nREPL] Hello! Can anyone explain while exceptions in Clojure future / core.async are printed to stdout/err while those in native (daemon) Java threads are not even though both have the same UncaughtExceptionHandler? Thank you!!! The test: 1. Java thread

(doto (Thread. #(do (println "in java thread: exc h=" (.getUncaughtExceptionHandler (Thread/currentThread))) (throw (RuntimeException. "in J daemon"))))
  (.setDaemon true)
; [OUT] in java thread: exc h= #object[java.lang.ThreadGroup 0x223f8c82 java.lang.ThreadGroup[name=main,maxpri=10]]
; => Execution error at user/eval23697$fn (REPL:1).
; => in J daemon
2. Clojure future
@(future (println "in java thread: exc h=" (.getUncaughtExceptionHandler (Thread/currentThread))) 
         (throw (RuntimeException. "clj future")))
; [OUT] in java thread: exc h= #object[java.lang.ThreadGroup 0x223f8c82 java.lang.ThreadGroup[name=main,maxpri=10]]
; => Execution error at user/eval23715$fn (REPL:1).
; => clj future
; [STDERR] Exception in thread "JavaFX Application Thread" java.util.concurrent.ExecutionException: java.lang.RuntimeException: clj future
        at java.base/
        at java.base/java.util.concurrent.FutureTask.get(
=> the same exc. handler in both cases but the first doesn't get printed to stdout while the other one does?! Update: in clj the Clojure future exception doesn't get printed to stdout:
clj -e '@(future (throw (RuntimeException. "clj future")))'
Execution error at user/eval1$fn (REPL:1).
clj future

Full report at:
(the .edn contains the exception and stack trace) So perhaps it is nREPL who does this? Interestingly, in core.async the error gets printed to stderr and no .edn is generated:
clj -Sdeps '{:deps {org.clojure/core.async {:mvn/version "0.6.532"}}}' -e '(require \'[clojure.core.async :as a])(a/<!! (a/go (let [ch (doto (a/chan) a/close!)] (inc (a/<! ch)))))' > /dev/null
Exception in thread "async-dispatch-1" java.lang.NullPointerException
(Note: the uncaught exc. handler inside the go block is still java.lang.ThreadGroup[name=main,maxpri=10])