This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-31
Channels
- # admin-announcements (4)
- # alda (3)
- # aws (1)
- # beginners (2)
- # boot (33)
- # braid-chat (4)
- # braveandtrue (20)
- # cider (52)
- # cljs-dev (13)
- # cljsrn (55)
- # clojure (111)
- # clojure-belgium (4)
- # clojure-brasil (6)
- # clojure-dusseldorf (1)
- # clojure-greece (116)
- # clojure-mexico (1)
- # clojure-nl (3)
- # clojure-russia (56)
- # clojure-spec (72)
- # clojure-uk (13)
- # clojurescript (66)
- # community-development (2)
- # component (24)
- # core-async (1)
- # cursive (19)
- # datomic (27)
- # devcards (5)
- # emacs (1)
- # funcool (34)
- # hoplon (313)
- # jobs (1)
- # lein-figwheel (11)
- # luminus (5)
- # mount (30)
- # off-topic (63)
- # om (375)
- # onyx (67)
- # perun (8)
- # proton (1)
- # reagent (4)
- # rum (1)
- # specter (55)
- # spirituality-ethics (7)
- # test-check (2)
- # untangled (34)
- # yada (20)
hi all. Can someone explain this:
(alet [a (ei/right 1) b (inc a)] a)
2
Why not 1
or #<Right 1>
?because (inc a) is 2, not #<Right 2> and doesn't have context. I remember someone (probably niwinz) already explained this to me
if one expresion depends on other is evaluated differently if the both are just parallel paths
@niwinz: thank you for explanation again, will wait for a new version. But actually it's very rare case that I use something like that, most of the time all results of functions are wrapped already
anyone here that is familiar with suricatta? i'm running into issues while trying to UPDATE ... SET key = NULL
-- apparently, jooq tries to cast the null value to a varchar
so I was thinking that there perhaps was some clojure <-> java incompatibility that jooq uses to test for null ?
I was found the same issue some days ago but I don't k now if I can solve it from suricatta part
this is a real issue for me now, so it makes sense for me to spend some time debugging it
apparently (fmt/sql) returns SET foo = NULL, where (fmt/sqlvec) return SET foo = (CAST null AS CHARACTER VARYING)
hmm, if it works properly with default dialect, but when a connection is used with postgresql dialect it does not works