This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-11
Channels
- # 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)
and I have to do (do (def ...) (alter-meta! (var ...) assoc )
instead...
I was curious to understand the problem in depth
@bronsa: it was your force push btw, should be fixed now
@alexmiller: any update when we can expect cljc support (https://groups.google.com/d/msg/clojure-dev/PDyOklDEv7Y/kl_oGciREAAJ)?
No update. Are you waiting on it?
@alexmiller: I’m working on http://dev.clojure.org/jira/browse/DCSV-13
Noted - you will need a newer version of Clojure-maven-plugin and Maven. You should be able to get it to work locally.
the part that doesn't work is doing the builds in our hudson server
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
just 2 this 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
check the site :)
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
Folks, I need some input on clojure.java.jdbc
...
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).
I’m struggling with db-do-prepared
and db-do-prepared-return-keys
.
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 execute!
with :multi? true
.
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).
But the [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 execute!
with :multi? true
.
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 :multi? true
).
@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. :)
(I guess I could add a trailing options map to both, to allow :multi? true
to be specified as needed?)