This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (53)
- # boot (151)
- # cider (11)
- # cljs-dev (60)
- # cljsrn (36)
- # clojure (71)
- # clojure-austin (13)
- # clojure-berlin (2)
- # clojure-czech (11)
- # clojure-dev (35)
- # clojure-dusseldorf (2)
- # clojure-france (6)
- # clojure-japan (9)
- # clojure-russia (183)
- # clojure-uk (18)
- # clojurescript (155)
- # cursive (6)
- # datomic (25)
- # euroclojure (6)
- # funcool (6)
- # hoplon (229)
- # instaparse (10)
- # jobs (9)
- # leiningen (5)
- # off-topic (70)
- # om (29)
- # onyx (18)
- # planck (1)
- # proton (5)
- # re-frame (8)
- # reagent (32)
- # untangled (4)
Hello folks, I wanted to ask if there is any known problem with using
(alter-meta! (def ....) assoc ...)
I just discovered that I cannot do it (in
boot, and maybe there is also something else going on)
@alexmiller: any update when we can expect cljc support (https://groups.google.com/d/msg/clojure-dev/PDyOklDEv7Y/kl_oGciREAAJ)?
Noted - you will need a newer version of Clojure-maven-plugin and Maven. You should be able to get it to work locally.
I will try to bump getting that fixed up in the priority list but the earliest I'll be able to look at it late next week
Yes, and I hope you’re busy with the one this fall as well. The one on my side of the pond, that is
I’m sure you’re aware of it, but since you’ll be shaving some CI-yaks, why not do it in clojure https://github.com/flosell/lambdacd
I’m trying to clean up the API to remove the variadic signatures since they don’t compose well.
I’ve gotten through most of them (in releases 0.5.5, 0.5.6 and bug fix 0.5.7) and I’ve cleaned up
db-do-commands as well (coming in 0.5.8).
The latter has always accepted
(db-do-prepared-return-keys db transaction? sql param-group) but the former has accepted
(db-do-prepared db transaction? sql param-group param-group param-group…)…
…and elsewhere in the API the normal usage is
[sql param-group param-group] (e.g., in
So I’m leaning toward change both of the
db-do-prepared* functions to accept
[sql param-group param-group param-group] as well.
For an interim release, both sets of arguments will be accepted but the legacy form will cause a
"DEPRECATED: because reasons" message to be printed to the console (which is how the library has dealt with deprecations in the past to help people identify and fix old-style calls).
[sql param-group param-group] argument style is already a bit overloaded since the normal usage is
[sql param param param] and the only time those a vectors (and therefore param-group values instead) is for
For a single param group,
(db-do-prepared-return-keys db transaction? [sql param param param]) seems like the most natural change (as opposed to what it currently is:
(db-do-prepared-return-keys db transaction? sql [param param param]))...
The temptation would then be to have
(db-do-prepared db transaction? [sql param param param]) for a single param group as well… but it needs to support the same argument style as
execute! as well (i.e., for
@slipset I am aware of lambdacd - looks really neat. moving to that would be a giant jump though and affect every contrib project. not signing up for that yet. :)