should be, we’ve use similar stuff (CRIU) successfully with clojure

Interesting! You don't even have to macroexpand - you can just replace that n with the value and it works that way.

I figured it out, it was a name collision with the n

What collided with it?

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``

n collided with itself, it appears as an argument as a pattern

Oh, shoot, right. Wow, now I can't fathom how I didn't see it in the first place.

you needed to go cook pasta, that's what I did

I'm surprised that it's not allowed to shadow in that case

bug?

Are you into cheats? JSON serialize 😛

I'm not sure that it's a cheat - sounds like a proper solution to me. :)

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\"]"

replace is yuk.

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.

I use replace all over my code. What's wrong with it?

> it can replace things within a string It's exactly what I am using it for. Not following.

I think this kind of operations on strings are low performance

*this - like replace

> 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

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.

#C6QH853H8 🙂

Ahha, ta 🙂

I had a little protocol buffer library that did this:

{:foo 42
 :the-one-of-field :foo}

the oneof field is an annoying construct

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;
  }
}

@U050ECB92 if you don't mind and if your lib in public repo, can you share the link?

it's not, sorry

Protocol buffers aren't fun, but you can try Pronto https://github.com/AppsFlyer/pronto#one-ofs

Damn, I'm blind, I used the same argument twice

cc @UKFSJSM38

sounds great, I think was never priorized, a issue would be a good start. c/c @U0ENYLGTA @U02G8N0EX44

https://github.com/nubank/matcher-combinators/pull/174 🙂

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?

@U0ENYLGTA aren't midje users already including midje as a dep?

I was very bold and created a #C04ABMF89D3 channel. Hope folks don't mind!

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

> yeah, I know about exclusions yeah, mostly mentioning for lurkers and the curious.

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

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

see here https://github.com/kubernetes-client/java/blob/master/util/src/main/java/io/kubernetes/client/util/ClientBuilder.java#L247

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.

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