Clojurians Log v2
clojure
is there a shorter way to write this code? it feels like a lot of duplication.
(if-let [head ('head some-map)] head)oh wait i think this is just the same as ('head some-map) lol
Not exactly, equivalent for {head false}
(or ('head some-map) nil)
Or (get some-map 'head nil)
no, that yields false on {'head false}
Ah yes, that is right.
Could someone show me a reproducible REPL use case for num? I'm planning on redoing the tests in clojure-test-suite but have been struggling to actually find a way to make num have observable behavior, at least in the REPL. My assumption was that some combination of int-array + ints + aget would allow me to extract a primitive/unboxed value that would fail (instance? java.lang.Integer ...) but I haven't managed to do so
Looks like there's a way to avoid reflection with it, is there a way to test whether reflection was used?
you can capture *out* or *err* while compiling probably
Yeah I know there's *warn-on-reflection* and I could use binding with stdout/err like you're suggesting maybe deep_thinking
user=> (binding [*err* (java.io.StringWriter.) *warn-on-reflection* true] (load-string "(fn [x] (.length x))") (str *err*))
"Reflection warning, null:1:9 - reference to field length can't be resolved.\n"But if you're doing this for other clojure dialects: this may be a highly specific JVM Clojure thing
e.g. bb doesn't give any warnings on reflections. moreover. it always uses reflection for interop :-)
Yeah, it also appears there's a bug with how ClojureCLR handles num. I'd like to provide any sort of value to the tests for these whatsoever, but I think it'll have to be something very platform dependent to do that. My hope would be it would at least document what value, if any, is provided on a platform by platform basis for the function, which may at least save folks some effort in the future if they reach for it inappropriately
Not sure it helps at all, but
(definterface IChecker
(isLong [^long l])
(isLong [^Object l]))
(deftype Checker []
IChecker
(isLong [this ^long l] true)
(isLong [this ^Object l] false))
(let [l (long 1)
L (num l)
checker (Checker.)]
[(.isLong checker l) (.isLong checker L)])
=> [true false]instance? is always going to box its argument
I've recently taken over maintenance of #slingshot and I've been mulling this issue: https://github.com/scgilardi/slingshot/issues/24 -- try+ cannot quite be used as a drop-in replacement for try because catch Exception e stops catching ex-info exceptions (and you need catch Object o instead). I've added a note as a comment on that issue, describing a potential fix for this (confusing) behavior that trips up quite a few people when they try to use Slingshot. My experiments so far indicate the new behavior seems backward-compatible with Slingshot, while making migration easier/less surprising, but I'd like to hear from more Slingshot users. Please either respond on that issue, or in a thread in #slingshot (since that will also get more Slingshot users into that channel!). Thanks!
After the number of times slingshot has nullified our attempts at error handling causing serious escalations for customer facing issues, you won’t find me touching it with a 10 foot pole, so not really a user… but yes this sounds like an improvement over the current state of it