Thanks, added to my watch list

You can try it like this: bb.edn

{:deps {lambdaisland/kaocha {:mvn/version "1.71.1119"}
        org.babashka/spec.alpha {:git/url ""
                                 :git/sha "1a841c4cc1d4f6dab7505a98ed2d532dd9d56b78"}}
 }

bb -m kaocha.runner

clojure -M:babashka/dev -m kaocha.runner

Type:     java.lang.Exception
Message:  Unable to resolve classname: clojure.lang.DynamicClassLoader

----- Stack trace --------------------------------------------------------------
dynapath.defaults            - dynapath/defaults.clj:4:3
dynapath.util                - dynapath/util.clj:3:3
kaocha.classpath             - kaocha/classpath.clj:5:3
kaocha.testable              - kaocha/testable.clj:3:3
kaocha.plugin.capture-output - kaocha/plugin/capture_output.clj:2:3
kaocha.report                - kaocha/report.clj:92:3
kaocha.config                - kaocha/config.clj:2:3
kaocha.api                   - kaocha/api.clj:4:3
kaocha.runner                - kaocha/runner.clj:5:3
user                         - <expr>:1:10

kaocha is quite a complex project. If you can't get it to work, I recommend running the cognitect test runner which works with bb today

Thx. So master has java.lang.Error now? I'll give it a try. Pretty sure I read something in the Koacha docs about disabling the classloader stuff.

Ran the script to install bb master, and still see java.lang.Error missing. I found the info about Koacha's ClassLoader. It is there to allow the option of specifying test source paths in test.edn instead of deps.edn. It is easily disabled with a config option on the test suite.

;; test.edn
#kaocha/v1
 {:tests [{:id :unit
           :skip-add-classpath? false}]}

What did you do to install bb master ?

bash < <(curl -s )

You need to specify the snapshot version

where do i find the snapshot version?

you should get it from https://github.com/babashka/babashka/blob/master/resources/BABASHKA_VERSION

Got it. Thanks.

😞 First try, it is still crashing on code about the ClassLoader. Hopefully I am just misunderstanding where/how to specify the config option. Otherwise, I guess I'll file an issue with Kaocha, and hope. Then use cognitect in the meantime.

You could try asking in the #CCY2V0U6A channel too?

sorry, was afk but yes that's where you should use the version from

Custom build of bb with DynamicClassLoader class, just to see how far I can get when importing doesn't break, and .. Crashed again, on code still trying to do ClassLoader shenanigans, despite my config saying "don't do that". 😒

@U90R0EPHA To make progress on this, it's probably best to run with a local checkout of kaocha and remove stuff that works around the classloader stuff

it's probably just a number inside indicating the repl port. should be safe to delete.

Yes, it is that, but is it normal that they're hanging around like this, or does it indicate some problem in my setup?

The polite thing to do is mark those files as deleteable when the vm exits. If you have any processes running, stop them and see if the files remain. If so you should raise an issue I think

@UPWHQK562 which pod causes this?

I think it's {epiccastle/spire {:version "0.1.1"}}, but I know I should be moving to https://github.com/epiccastle/bbssh, so maybe it's a moot point... just haven't had the time to upgrade yet.

Perhaps make an issue there : the way it should be implemented is: when their process shuts down, they should remove the file. Indeed what @U11BV7MTK says: mark it as delete on shutdown

Okay, so it's definitely an irregularity then. Alright, I'll try to confirm/get more detail about it and will report. Thanks, all.

https://github.com/epiccastle/spire/issues/153 for reference

Right gotcha.

There is a shutdown hook to delete it. I wonder why its not working? https://github.com/epiccastle/spire/blob/master/src/clj/spire/pod/core.clj#L105-L108 :thinking_face:

I will do some testing thanks @UPWHQK562

you can do this instead maybe: https://github.com/babashka/fs/blob/master/API.md#babashka.fs/delete-on-exit

if you implement the "shutdown" operation, then the pod is shutdown more gracefully, might also help

https://github.com/babashka/pods#shutdown

This is the pod mainline, not running in babashka. I thing shutdown operation will be the best thing.

not sure what you meant with "this is the pod mainline ..."

I don't have babashka.fs as a dep atm in the code.

its the clojure graal compiled code

what I meant was: you can just do what that function does (or add fs as a dep)

yeah I figured looking into what its doing under the hood

https://github.com/babashka/fs/blob/5098aa7187ddb7b6eaf159a5d3dfd95796c7329f/src/babashka/fs.cljc#L589

easy.

ok that .deleteOnExit works.

Thanks for checking this out, @U1QQJJK89. Not sure if you've concluded this, but just FYI, I updated the repro to use (pods/load-pod 'epiccastle/spire "0.1.2") and I'm still getting the port files left over in my directory after the process is done.

@UPWHQK562 ah damn. Was working when running the pod under JVM. But as graal native-image binary deleteOnExit doesn't work. I've come up with something now that seems to work with native image to. I will re-tag and release 0.1.2. Hold on.

Should also work in a graal binary, but did you also implement the shutdown op?

I tried the shutdown too. It was never called.

it could be that in a shutdown that is forced, the delete on exit doesn't have time to execute

It's strange. I don't even reach the EOF exception

if you implement the shutdown op, it should imo work

yeah it didnt work

but what Im doing now is deleting it after socket is established, while its still running

ok, that should work too... still weird that the shutdown op didn't work, it should.

after the first read

yeah... something strange going on. And it worked on JVM which is doubley strange. Don't have time to dig in atm. This early delete seems to work for now.

https://github.com/babashka/pods/blob/decf791000081ca9e6d2fbea9f20a0aa3fae902e/src/babashka/pods/impl.clj#L259-L263

ah do I have to set an option? to get the shutdown hook

yes, you need to declare it in your describe message that you implement the shutdown op. RTFM dude ;)

hehe kidding

haha no time! 😉

hack hack

skim reading is the new reading

let me give it a whirl

"If the pod does not support the shutdown op, the pod process is killed by the pod client"

that explains it. It's nuking it before it can do anything. Wow, reading is quite useful, hey 😄

> The optional ops value communicates which ops the pod supports, beyond describe and invoke. It is a map of op names to option maps. In the above example the pod declares that it supports the shutdown op.

the docs could be clearer of course, sorry for that ;)

probably the pods thing can also remove the file after it connects, this seems more reliable than asking people to do this

issue welcome as well

I think bb could mark the file as delete on exit

as well

and when it doesn't exist anymore, that won't crash either I think so it will be a double safety measure

ok, compiling with a shutdown hook now...

yeah. I will test .delete ing a non existent file and if there is no exception then I could patch bb to delete it after connection

I think just marking it as delete on exit in bb will be sufficient, not actually deleting it

yeah. its probably good to not delete it early in bb, as it is the pod that makes it

who knows what the pod is doing

but makes sense in cleanup

alright, got the shutdown message calling me. and file deleted nicely from that message. 🎉

@UPWHQK562 I have rebuilt and rereleased 0.1.2 with a working file cleanup. You will need to delete your local pod repository ~/.babashka/pods/repository/epiccastle/spire/0.1.2/ to have babashka fetch the new 0.1.2 binary.

Thanks, @U1QQJJK89. Looks like it worked! I closed the issue.

Made an issue here too https://github.com/babashka/pods/issues/59