Fork me on GitHub
#clojure-dev
<
2016-04-11
>
richiardiandrea00:04:07

Hello folks, I wanted to ask if there is any known problem with using (alter-meta! (def ....) assoc ...)

richiardiandrea00:04:03

I just discovered that I cannot do it (in boot, and maybe there is also something else going on)

richiardiandrea00:04:35

and I have to do (do (def ...) (alter-meta! (var ...) assoc ) instead...

richiardiandrea00:04:01

I was curious to understand the problem in depth

alexmiller00:04:40

@bronsa: it was your force push btw, should be fixed now

jonas18:04:20

@alexmiller: any update when we can expect cljc support (https://groups.google.com/d/msg/clojure-dev/PDyOklDEv7Y/kl_oGciREAAJ)?

alexmiller18:04:18

No update. Are you waiting on it?

slipset18:04:32

and mvn test fails

slipset18:04:50

which is related to what @jonas said

alexmiller18:04:38

Noted - you will need a newer version of Clojure-maven-plugin and Maven. You should be able to get it to work locally.

alexmiller18:04:12

the part that doesn't work is doing the builds in our hudson server

alexmiller18:04:23

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

slipset18:04:50

No stress, I imagine you have a conference or two to attend to, as well

alexmiller18:04:24

just 2 this week :)

slipset18:04:34

Yes, and I hope you’re busy with the one this fall as well. The one on my side of the pond, that is

alexmiller19:04:16

check the site :)

slipset19:04:57

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

slipset19:04:25

euroclojure, that is

seancorfield19:04:44

Folks, I need some input on clojure.java.jdbc...

seancorfield19:04:06

I’m trying to clean up the API to remove the variadic signatures since they don’t compose well.

seancorfield19:04:42

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).

seancorfield19:04:58

I’m struggling with db-do-prepared and db-do-prepared-return-keys.

seancorfield19:04:07

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…)

seancorfield19:04:37

…and elsewhere in the API the normal usage is [sql param-group param-group] (e.g., in execute! with :multi? true.

seancorfield19:04:35

So I’m leaning toward change both of the db-do-prepared* functions to accept [sql param-group param-group param-group] as well.

seancorfield19:04:54

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).

seancorfield19:04:18

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.

seancorfield19:04:11

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]))...

seancorfield19:04:44

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).

alexmiller19:04:33

@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. :)

seancorfield19:04:51

(I guess I could add a trailing options map to both, to allow :multi? true to be specified as needed?)