This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-10
Channels
- # admin-announcements (1)
- # aleph (1)
- # asami (9)
- # babashka (30)
- # beginners (83)
- # calva (8)
- # cherry (4)
- # cider (4)
- # clj-kondo (15)
- # cljs-dev (11)
- # cljsrn (8)
- # clojure (85)
- # clojure-europe (87)
- # clojure-losangeles (9)
- # clojure-nl (4)
- # clojure-norway (4)
- # clojure-spec (3)
- # clojurescript (12)
- # community-development (5)
- # conjure (1)
- # core-typed (3)
- # datomic (21)
- # docker (13)
- # emacs (13)
- # funcool (1)
- # google-cloud (1)
- # graalvm (12)
- # gratitude (14)
- # holy-lambda (6)
- # introduce-yourself (18)
- # lsp (15)
- # malli (6)
- # matcher-combinators (15)
- # nbb (15)
- # off-topic (37)
- # pathom (31)
- # portal (23)
- # rdf (3)
- # releases (2)
- # reveal (2)
- # sci (4)
- # scittle (3)
- # shadow-cljs (14)
- # squint (2)
- # tools-deps (29)
does anyone know if crac is applicable to clojure stuff? https://www.youtube.com/watch?v=0evEs_3yaEI
I don't see a channel for core match, so I'll ask here: I have a case where the macro expanded match form succeeds but the unexpanded form fails to find any matching case.
(defn uneval-neutral
[n uenv]
(match n
(['NVar x] :seq) 1
(['NApp n v] :seq) 2))
(uneval-neutral '(NApp (NVar f0) (N (NApp (NVar f0) (N (NVar x0))))) {})
Throws
No matching clause: (NApp (NVar f0) (N (NApp (NVar f0) (N (NVar x0)))))
But if I macroexpand it, the match succeeds.
Checked with core.match 1.0.0.
Any insights?Interesting! You don't even have to macroexpand - you can just replace that n
with the value and it works that way.
Not related to that, but trying to macroexpand match I found that it even fails for things like (macroexpand-1 '(match ["coffee"] [(:or foo "bar")] :yes :else :no))
I get Syntax error macroexpanding match at (cider-repl my-projects/hansel:localhost:34779(clj):14:6). No method in multimethod 'to-source' for dispatch value: null``
I'm surprised that it's not allowed to shadow in that case
What's a nice way to turn a sequence of strings like ["foo" "bar"]
into a string of the vector with commas inserted: "[\"foo\",\"bar\"]"
? I have:
(->> ["foo" "bar"]
(map pr-str)
(clojure.string/join ",")
(#(str "[" % "]")))
yeah i'd just use a json printer
maybe he just wants commas, which clojure doesn't provide control over 😞 zprint might help for a generalized solution
Thanks! I'll consider a JSON serializer, but in choosing between adding a dependency and the solution I came up with, I think I'll stick with the latter... Then again, I might need a JSON serializer for something else later, idk. I don't need performance, if that is why I should go the JSON way.
I did have a solution using clojure.pprint
a while, but then didn't want to rely on that it will keep adding those commas (which I think is a strange thing for it to do in the first place). 😃
Ah, yeah - if you don't depend on any JSON library then I'd go with your solution as well. But without that #()
- I'd extract it into its own function.
Thanks! One of the things I tried, btw:
(->> ["foo" "bar"]
(interpose \,)
vec
pr-str)
;; => "[\"foo\" \\, \"bar\"]"
😃(let [almost (->> ["foo" "bar"]
(interpose \,)
vec
pr-str)]
(clojure.string/replace almost #" \\," ","))
;; => "[\"foo\", \"bar\"]"
¯\(ツ)/¯Another one:
(string/replace (pr-str ["foo" "bar"])
#"\"\s\""
"\",\"")
;; => "[\"foo\",\"bar\"]"
I have no idea but I will try to say something useful 🙂 Maybe this function (or source code) can be useful https://clojuredocs.org/clojure.core/interpose
(str/join (concat [\[] (interpose \, (map pr-str ["a" "b"])) [\]]))
.
A tad ugly because of concat
though. But it doesn't use replace
, which you should never use in such tasks because it can replace things within a string.

> it can replace things within a string It's exactly what I am using it for. Not following.
> It's exactly what I am using it for. Not following. You're using it with the intent to fix up the resulting string. But it can potentially change one of the input strings. Not sure about that particular usage of yours, but I prefer simply not to rely on it at all rather than carefully analyzing what can and cannot happen in each use case. It's a very generic rule - instead of creating bad data and fixing it, you should create good data in the first place. Otherwise, all sorts of things can potentially go wrong.
As a demonstration - I had to remove one space in your pattern for replace
because it seems that in this particular case it makes everything work just fine. But what if you didn't care about that space:
(let [almost (->> ["foo" "bar\\, baz"]
(interpose \,)
vec
pr-str)]
(prn almost)
(prn (str/replace almost #"\\," ",")))
"[\"foo\" \\, \"bar\\\\, baz\"]"
"[\"foo\" , \"bar\\, baz\"]"
=> nil
Notice how the second input string got changed.Thanks for elaborating, @U2FRKM4TW 🙏 . In my use case I know I don't have that problem, but for sure it is good to be aware of this, generally.
@U0WL6FA77, in my use case for this I don't have a performance requirement. But could be interesting still to compare some solutions regarding this.
How can I point tools.deps
at a different Maven settings.xml
? I know it obeys the properties in ~/.m2/settings.xml
, but for various reasons I can't use that default path (`${HOME}/.m2/settings/xml`), I need to have my settings file elsewhere. The Internet talks a lot about M2_HOME
, but mostly that talk is along the lines of "It's deprecated and causes all sorts of issues, don't use it", and I don't know if tools.deps
obeys it anyway
#C6QH853H8 🙂
just wondering how would one represent the protocol buffer oneof type (which is like c++ union type) in clojure? the main issue being unable to automatically 'clears' away other values when i set one of it
I had a little protocol buffer library that did this:
{:foo 42
:the-one-of-field :foo}
nice! thought it might break when the outer scope also has a variable named :foo, but looks like such duplicated name in different scope wasn't allow
syntax = "proto3";
message A {
string abc = 1;
oneof test {
uint32 abc = 2;
bool def = 3;
}
}
compiling above gives
temp.proto:6:12: "abc" is already defined in "A".
@U050ECB92 if you don't mind and if your lib in public repo, can you share the link?
Protocol buffers aren't fun, but you can try Pronto https://github.com/AppsFlyer/pronto#one-ofs
Is there anything wrong with:
(def cli-options
[["-n" "--name NAME" "Network name"
:default "wg0"]
["-c" "--cidr CIDR" "Network cidr"
:default "10.5.5.0/24"]
["-h" "--hostname HOST" "Remote host"
:required "HOST"]
["-p" "--port PORT" "Port number"
:default 51820
:parse-fn #(Integer/parseInt %)
:validate [#(< 0 % 0x10000) "Must be a number between 0 and 65536"]]
["-h" "--help"]])
When running main I get:
Exception in thread "main" java.lang.AssertionError: Assert failed: (distinct?* (remove nil? (map :short-opt %)))
Since there isn't a channel for nubank matcher-combinators, I'll try it here. 🧵 I noticed that it pulls in dependencies I'm not interested in:
$ lein test :only babashka.error-test/debug-exception-print-test
Retrieving nubank/matcher-combinators/3.6.0/matcher-combinators-3.6.0.pom from clojars
Retrieving midje/midje/1.10.6/midje-1.10.6.pom from clojars
Retrieving marick/suchwow/6.0.3/suchwow-6.0.3.pom from clojars
Retrieving nubank/matcher-combinators/3.6.0/matcher-combinators-3.6.0.jar from clojars
Retrieving marick/suchwow/6.0.3/suchwow-6.0.3.jar from clojars
It seems to be e.g. midje could be made optional?sounds great, I think was never priorized, a issue would be a good start. c/c @U0ENYLGTA @U02G8N0EX44
We've talked about it, but it becomes a breaking change for users that rely on midje, so we haven't moved that forward yet.
A matcher-combinators channel is a great idea!
@U04V15CAJ, I always do like so: nubank/matcher-combinators {:mvn/version "3.5.1" :exclusions [midje/midje]}
, maybe as a short-term compromise, matcher-combinators readme could add a tip on how to exclude midje?
yeah, I know about exclusions, but I was thinking "good defaults". I suspect it won't be that breaking since midje users will likely pull in midje themselves
One issue with including the midje dep by default is also that I get a clj-kondo configuration for a library I don't use
.clj-kondo/marick/
My, perhaps naive, perspective is that by not including midje as dep, matcher-combinators would only be breaking libs that don't include midje as a dep. And that those libs should really be including midje as a dep. So the break would be totally acceptable.
Yes, agreed. Relying on midje to be there while only including matcher combinators seems weird
Is this a bug?
• Client Library io.kubernetes/client-java {:mvn/version “16.0.2”}
• calling static method (ClientBuilder/cluster) inside defonce in the calva repl causes a Execution error (NumberFormatException) at java.lang.Integer/parseInt (Integer.java:614)
• But if I run it outside of a defonce in main execution, it works.
hard to say without the stack trace. it is not obvious wherever this exception got thrown
this is all I get
io.kubernetes.client.util.ClientBuilder/setBasePath (ClientBuilder.java:261)
io.kubernetes.client.util.ClientBuilder/cluster (ClientBuilder.java:247)
viasat.sdp.api.impl.secret-manager-k8s-secretstore/eval7683 (NO_SOURCE_FILE:14)
clojure.lang.Compiler/eval (Compiler.java:7177)
clojure.core/eval (core.clj:3214)
clojure.core/eval (core.clj:3210)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.core/apply (core.clj:665)
clojure.core/with-bindings* (core.clj:1973)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.main/repl (main.clj:437)
clojure.main/repl (main.clj:458)
clojure.main/repl (main.clj:368)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:84)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:56)
nrepl.middleware.interruptible-eval/interruptible-eval (interruptible_eval.clj:152)
nrepl.middleware.session/session-exec (session.clj:218)
nrepl.middleware.session/session-exec (session.clj:217)
java.lang.Thread/run (Thread.java:834)
i see that cluster method is using env variables. probably calva (actually vscode) doesn't get the same env as the process that runs main
also there is a #CBE668G4R channel where the chances to resolve your issue will be a bit higher
thanks
The part that is problematic though is it happens also when I run a build clj -T:build myjar
try to refactor your code and instead of making global var which refer to cluster make a function that should return it when called
I’ve define that in a (defonce) , I have it now in a function, but not sure how to invoke it just once.
make a binding with let in main and pass it as an argument to other functions that needs it. another, probably simpler way, is to declare dynamic top level var, use binding
in main to "set" it and then rest of your code will see actual value.
however the best way is to adopt one of dependency injection library. there are few i know : component, integrant, mount
Thanks for the recommendations. I don’t think I’ll try them as it involves just too much code change for such a simple thing. Putting it in a function which I will call over and over again, is ok for now. but pretty bad behavior.
@ptaoussanis what's a good way to debug nippy deserialization? We're seeing an error on deserializing a type that was serialized without issue. It serialized as a sequence of tuples, and the first tuple reads just fine, but the second one fails with a type id of -67, which I've determined is treated as a custom byte id by nippy, although we haven't defined that as a custom type (we have one custom type, but it doesn't appear to be that one). I'm at a little bit of a loss on how exactly to figure this one out, even stepping through the nippy code. The only weird types we're seeing is joda time instants which appear later in the data than where the error occurs and work fine, and mongo ids which we have custom types defined for which seems to work fine. 🧵
So I've been able to look more into the bytes on the wire and I have been able to identify what looks like the type id for a clojure vector before the first tuple and it looks like that type id for the next vector starts just two bytes too late, but I'm unsure.
We're using nippy 3.1.1 for reference here
Since no one else replied. do you have a minimal reproduction? Especially if you know what types might cause errors, test.check
can work magic for finding minimal repros.
no, all I have is the raw (and proprietary) nippy data that caused it, along with no inclination of where a weird data type would've gotten into the system, since this has only happened after processing some 60 million messages
was the data encoded with the same version as the decoder?
yes, by the same application too.
different deployments of it I think, but the code didn't change much and none of the dependencies changed
so is your goal? 1. get the original data that was encoded 2. try to prevent future encoding issues 3. both
for #2, I would definitely use test.check