Neither particularly short nor particularly clever:
(defn nil-coalesce [coll subs]
(loop [[c cs :as coll] coll
[s ss :as subs] subs
acc []]
(if coll
(recur cs
(if (nil? c) ss subs)
(conj acc (if (nil? c) s c)))
acc)))
On Tue, Aug
I did some Googling and came across this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6366468
It implicates jar file corruption, possibly caused by modifying jar
files while the VM is running. Seems consistent with the
ZipFile/URLClassLoader entries in the stack trace.
j
Hi Michal,
I needed to change your containsKey implementation to always return
true in order to support the merge-with use case.
Hi Stu,
merge-with* seems like a useful addition, though its semantics differ
slightly from merge-with's. The original merge-with modifies the vals
only if there are
clojure.core/byte was modified a couple weeks ago as follows:
(defn byte
Coerce to byte
{:tag Byte
:inline (fn [x] `(. clojure.lang.RT (byteCast ~x)))}
- [^Number x] (. x (byteValue)))
+ [^Number x] (clojure.lang.RT/byteCast x))
byteValue and byteCast behave differently with
When it useful to be able to deref inside a dosync without ensuring?
When you deref and alter/set the same ref, the ref is protected from
modification as well.
I couldn't think of an example of what I think you had in mind,
something that requires a transaction but is tolerant of modification
On Sep 23, 9:23 am, Dave Jack dav...@gmail.com wrote:
Maybe @ should expand to ensure rather
than deref inside a transaction, instead?
Should've thought about this more. How is the reader supposed to know
that this code is called in a transaction? And it would leak if you
deref'd inside