Please don’t post long traces in the main channel but use a gist or thread

The solution is in the README of etaoin: the babashka process library is used in etaoin and you can enable its pprint method following that

^ @U053KNT7C

I think this shouldn't happen with the newest etaoin at all anynmore since babashka.process/pprint is already required there

@U053KNT7C. The original message got a bit long for the main channel. We deleted it and I'm posting it back here now: > here's a strange message. i just installed clj and am trying to run a regular clojure program using clj which works fine locally. but it seems clojure now depends on babashka? i'm not using babashka, it's not installed, it's not referenced and yet it's trying to find it? even if i install it, i get the same error. it's beyond comprehension why it would be looking for babashka.process.Process or why that would have anything to do with clj. i wasn't sure if i should post this in this channel or the clojure channel. >

clj -M screenshot.clj 
> Starting ...
> java.lang.IllegalArgumentException: Multiple methods in multimethod 'simple-dispatch' match dispatch value: class babashka.process.Process -> interface clojure.lang.IDeref and interface clojure.lang.IPersistentMap, and neither is preferred
> at clojure.lang.MultiFn.findAndCacheBestMethod(MultiFn.java:179)
> at clojure.lang.MultiFn.getMethod(MultiFn.java:150)
> at clojure.lang.MultiFn.getFn(MultiFn.java:154)
> at clojure.lang.MultiFn.invoke(MultiFn.java:229)
> _base.clj:194)jure.pprint$write_out.invokeStatic(pprint
> at clojure.pprint$pprint_map$fn__11151$fn__11153.invoke(dispatch.clj:113)
> at clojure.pprint$pprint_map$fn__11151.invoke(dispatch.clj:113)
> at clojure.pprint$pprint_map.invokeStatic(dispatch.clj:112)
> at clojure.pprint$pprint_map.invoke(dispatch.clj:106)
> at clojure.lang.MultiFn.invoke(MultiFn.java:229)
> at clojure.pprint$write_out.invokeStatic(pprint_base.clj:194)
> at clojure.pprint$pprint_map$fn__11151$fn__11153.invoke(dispatch.clj:113)
> ke(dispatch.clj:113)print$pprint_map$fn__11151.invo
> at clojure.pprint$pprint_map.invokeStatic(dispatch.clj:112)
> at clojure.pprint$pprint_map.invoke(dispatch.clj:106)
> at clojure.lang.MultiFn.invoke(MultiFn.java:229)
> at clojure.pprint$write_out.invokeStatic(pprint_base.clj:194)
> at clojure.pprint$pprint_map$fn__11151$fn__11153.invoke(dispatch.clj:113)
> at clojure.pprint$pprint_map$fn__11151.invoke(dispatch.clj:113)
> at clojure.pprint$pprint_map.invokeStatic(dispatch.clj:112)
> 6)      at clojure.pprint$pprint_map.invoke(dispatch.clj:10
> at clojure.lang.MultiFn.invoke(MultiFn.java:229)
> at clojure.pprint$write_out.invokeStatic(pprint_base.clj:194)
> at clojure.pprint$pprint_vector$fn__11136.invoke(dispatch.clj:95)
> at clojure.pprint$pprint_vector.invokeStatic(dispatch.clj:94)
> at clojure.pprint$pprint_vector.invoke(dispatch.clj:92)
> at clojure.lang.MultiFn.invoke(MultiFn.java:229)
> at clojure.pprint$write_out.invokeStatic(pprint_base.clj:194)
> at clojure.pprint$pprint_map$fn__11151$fn__11153.invoke(dispatch.clj:113)
> .pprint$pprint_map$fn__11151.invoke(dispatch.clj:113)
> at clojure.pprint$pprint_map.invokeStatic(dispatch.clj:112)
> at clojure.pprint$pprint_map.invoke(dispatch.clj:106)
> at clojure.lang.MultiFn.invoke(MultiFn.java:229)
> at clojure.pprint$write_out.invokeStatic(pprint_base.clj:194)
> at clojure.pprint$pprint_map$fn__11151$fn__11153.invoke(dispatch.clj:113)
> at clojure.pprint$pprint_map$fn__11151.invoke(dispatch.clj:113)
> at clojure.pprint$pprint_map.invokeStatic(dispatch.clj:112)
> pprint_map.invoke(dispatch.clj:106)
> at clojure.lang.MultiFn.invoke(MultiFn.java:229)
> at clojure.pprint$write_out.invokeStatic(pprint_base.clj:194)
> at clojure.pprint$pprint$fn__10392.invoke(pprint_base.clj:249)
> at clojure.pprint$pprint.invokeStatic(pprint_base.clj:248)
> at clojure.pprint$pprint.invoke(pprint_base.clj:241)
> at clojure.pprint$pprint.invokeStatic(pprint_base.clj:245)
> at clojure.pprint$pprint.invoke(pprint_base.clj:241)
> at clojure.lang.Var.invoke(Var.java:384)
> port_error$fn__9280$fn__9281.invoke(main.clj:603)
> at clojure.main$report_error$fn__9280.invoke(main.clj:602)
> at clojure.main$report_error.invokeStatic(main.clj:601)
> at clojure.main$main.invokeStatic(main.clj:666)
> at clojure.main$main.doInvoke(main.clj:616)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.lang.Var.applyTo(Var.java:705)
> at clojure.main.main(main.java:40)

{:paths ["."]
>  :deps {org.clojure/clojure {:mvn/version "1.11.1"}
>         etaoin/etaoin       {:mvn/version "1.0.38"}}}

Yes, latest release of etaoin should address this, please let us know if you still have issues in #C7KDM0EKW

sorry, i didn't know about the traces. i'll use a snippet next time. thank u all for u'r responses

no problem. hope you found the solution to your problem?

Sharing them as a snippet is also an alternative - at least I find snippets useful for longer stacktraces.

I wonder if the admins would want to create a Clojure slack management bot? This could do things like • detect if people are sending multiple messages in a row. If it’s the first time communicating with them, show them how to thread the message. If it’s the nth time, just a gentle threading reminder. • detect if messages are extremely long / contain a stacktrace and ask them to put the subject line of the question and the detail in the thread. etc. I am sure there is a lot of admin overhead that could be added into the bot to automate the moderation a bit

Thanks for caring about the readers of this channel!

@U015Y1A1N8Y I expect the Admins would welcome someone volunteering their time and effort to help with their moderation effort -- but don't appreciate people suggesting extra work for the Admin team (who are all volunteers themselves)... @U04V15CAJ Slack does not provide any way to "move [messages] to a thread" -- we can only delete messaes.

@U04V70XH6 I know, but what we did above is start the thread, delete the top message and repost it in the thread.

Yeah, the only problem with that is the Admin then ends up in a thread they may not be interested in and the message's OP is lost (and then other people have a habit of @-ing the Admin about stuff in that thread). In the end, it just causes more work for us. I'll have a look at the permissions setup and see if we can provide a group of trusted folks as "channel owners" the ability to delete other people's messages as a way for those folks to better manage their own projects' channels...

...Hmm, the only options are "Everyone" and "Workspace owners and Admins" so we'd have to expand the pool of Admins to make that possible. Do you want to become a general Admin of the Workspace, @U04V15CAJ? 🙂

> Yeah, the only problem with that is the Admin then ends up in a thread they may not be interested in You can unsubscribe from the thread afterwards :)

> Do you want to become a general Admin of the Workspace Sure :)

I’ve seen https://github.com/brunolemos/threadbot being used at places. Kinda annoying in the beginning but people catch on 😅

This sounds almost what I want, but it doesn't have the long stacktrace detection right? ;)

Yeah, that can be contributed I think!

The thing that it does already is more complicated than long Stacktrace detection I think.

Yes: bb --describe 😂

not sure what you're after though

Haha, indeed, but something that would show intel like :config-dir etc. Context: I reached a CI situation where launching a BB task tries to create a /.clojure/.cpcache dir (and fails because it's not the right place).

try bb clojure -Sdescribe

Ah well, it seems it won't help:

$ bb clojure -Sdescribe
Picked up JAVA_TOOL_OPTIONS: -Duser.home=/var/lib/gitlab-runner

Error building classpath. Can't create directory: /.clojure/.cpcache

Hmm, -Sdescribe doesn't really need to build a classpath, I guess... what platform are you using?

as in, what os

This is on a Nix-based runner, I'm trying to figure it out with @U033F53LU0M who is our Ops angel

Hmm https://github.com/borkdude/deps.clj/blob/2d185718ba2871c96e6cb4a4181d1dcf9d8fde86/src/borkdude/deps.clj#L785

This looks really fishy doesn't it:

$ bb --version
Picked up JAVA_TOOL_OPTIONS: -Duser.home=/var/lib/gitlab-runner

Error building classpath. Can't create directory: /.clojure/.cpcache

Yes, I don't know where this is coming from ... maybe gitlibs?

Oh I see, this is coming from Clojure:

$ JAVA_TOOL_OPTIONS="-Duser.home=/tmp/dude" clj
Picked up JAVA_TOOL_OPTIONS: -Duser.home=/tmp/dude
Clojure 1.11.0

But why does it kick in with bb --version?

no from tools deps, I guess

because bb --version doesn't avoid loading deps from bb.edn I guess

you can do it like this for now: BABASHKA_CLASSPATH="" bb --version

To set the home dir for bb you can do it like this:

bb -Duser.home=/var/lib/gitlab-runner

Okay so it seems indeed that there is some trouble related to HOME, if you compare BB Vs Clojure CLI -Sdescribe: https://gist.github.com/helins/3d1fcb280e2c62df067cd8dac0fb8e3e

Yes, use the property I mentioned before your last reaction

deps.clj respects the user.home property

https://github.com/borkdude/deps.clj/blob/2d185718ba2871c96e6cb4a4181d1dcf9d8fde86/src/borkdude/deps.clj#L228-L232

Great, seems like a fix, I think we can figure out the rest now! Thanks, very helpful as always 🙂

This post might also be helpful: https://blog.wsscode.com/clojure-gitlab-cache/

but this part of the post doesn't hold anymore: > Babashka doesn’t support -Sdeps The latest version does now cc @U066U8JQJ

For the sake of posterity, the root cause of this discrepancy turns out to be https://bugs.openjdk.org/browse/JDK-8280357

tl;dr almost everything besides Java uses $HOME to find the home directory, but Java uses getpwuid. Since we run our gitlab-runners with systemd's DynamicUser setting, this causes the aforementioned discrepancy. We had worked around this discrepancy via the JAVA_TOOL_OPTIONS thing mentioned earlier, but that broke for some bb invocations. I think I may disable DynamicUser altogether and rework the isolation story for our CI runners.

They did fix this upstream in OpenJDK eventually: https://github.com/openjdk/jdk/pull/7534 but it will take forever until that makes it into an LTS release

Frex, this will work from the shell:

bb -e '(doseq [x (range 1 100)] (Thread/sleep 100) (println x))' | dialog --gauge "Testing" 0 0

@U13N2SPMZ Yes, this is possible. To do this, use process, not shell since shell is blocking

I have been but I think the order of dereferencing might be wrong? Lemme post some snippets, just a sec.

You launch dialog like this:

(process "dialog --gauge 'Testing' 0 0")

(process {:err :inherit} "dialog --gauge 'Testing' 0 0")

yes, you deref too early

and so

(process {:err :inherit} "dialog --gauge 'Testing' 0 0")

dialog displays to stdout, it uses stderr for return values

oh that's weird, but ok

let me try to make a small full example, brb

No problem, probably should've posted a simpler example myself 😅

@U13N2SPMZ

(require '[babashka.process :refer [process]]
         '[ :as io])

(let [dialog (process {:out :inherit
                       :err :string} "dialog --gauge 'Testing' 0 100")]
  (with-open [in (io/writer (:in dialog))]
    (binding [*out* in]
      (doseq [i (range 1 101)]
        (println i)
        (Thread/sleep 10))
      (println "99")))
  (println (:err @dialog))
  nil)

Try that

(made a small edit)

OK, that does work at least. The question is how can I generalize this such that someone can provide arbitrary processes. :thinking_face:

arbitrary processes?

time to cool down over here... I'll check back in tomorrow :)

I'm working on a library for working with dialog. So I've been trying to puzzle out how the API can work for stuff where the CLI version is "pipe thing to dialog"

So my initial thought was "pass :out from a process"