This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-25
Channels
- # adventofcode (5)
- # announcements (2)
- # babashka (10)
- # beginners (25)
- # calva (2)
- # clojure (23)
- # clojure-europe (1)
- # clojure-nl (3)
- # clojure-uk (5)
- # clojurescript (6)
- # community-development (5)
- # core-async (16)
- # core-logic (17)
- # datomic (9)
- # defnpodcast (1)
- # duct (6)
- # emacs (4)
- # leiningen (3)
- # off-topic (99)
- # planck (1)
- # shadow-cljs (3)
- # sql (1)
- # tools-deps (6)
- # vrac (2)
what does xrel mean in http://clojuredocs.org/clojure.set/project
I think the place to start with xrel
is http://clojuredocs.org/clojure.set/index
(and I think https://en.wikipedia.org/wiki/Relational_algebra is "further reading" as they say... based on natural joins and projections and so on)
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 http://clojuredocs.org/clojure.set/join, it has xrel
and yrel
as its arguments.
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)
(.run))
; [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/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
=> 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:
/var/folders/kg/r_8ytg7x521cvlmz_47t2rgc0000gn/T/clojure-1544501903780485808.edn
(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]
)