Clojurians Log v2
clojure
I just discovered something I should have already known.
I’m sometimes using (System/exit 0) to exit immediately from a script written in clojure because otherwise it takes far to long to quit. However, if there is anything that has been printed using printf which hasn’t been actually flushed to stdout, then it gets lost. Therefore it seems one should always call flush before calling System/exit.
Why does it take too long to exit? Maybe you need to call this? https://clojuredocs.org/clojure.core/shutdown-agents
or use babashka for scripting, it not only quits fast, it also starts fast babashka 😅
An extension to that is that you can have exactly one (System/exit 0), which is implicit - by letting the body of the main function end.
Doing that while still having early interrupts can be achieved with exceptions that you catch in -main, maybe report, and exit with a (flush).
A beneficial side-effect is that you can also call any procedure that wants to exit early without exiting the whole program. So, you can use it from other scripts, have retries, use it from a REPL.
I was just adding an *exit-fn* hook to one of my libraries so (System/exit 1) won't be called in the REPL
So, you'd call it like (*exit-fn* 1) instead, and make it be System/exit in scripts and something like #(throw (ex-info "stopping early" {:status %})) in REPL?
yeah
I have a similar thing in deps.clj
> or use babashka for scripting, it not only quits fast, it also starts fast I’ve never used babashka. and I’ve never had problems with startup time. That being said, I’m not opposed to refactoring my code to use babashka if there are some interesting benefits. However, I’d need some help (from a human being).
@jimka.issy I was half-joking. If you don't have a problem, keep on going :) But if you do need help, #CLX41ASCS is available for you.
I was just triggered by the word "script". that's bb's main thing
> Why does it take too long to exit? Maybe you need to call this?
I put the System/exit in my code long ago. I don’t remember exactly what was triggering the slowness. Is that something you’d (@ed) recommend investigating tracking down?
that's what ed already mentioned, you should look into shutdown-agents. you're likely using a promise or future somewhere which triggers those threadpools
@borkdude > If you don’t have a problem, keep on going on the other hand, one (me) shouldn’t use that excuse for avoiding learning something new. I more and more find it easier to write scripts in clojure than in python, especially when it is just me who will be using them. However, I prefer writing the scripts in python if I’m going to distribute them to other people, especially to my students.
makes sense. on the other hand, your clojure students may also enjoy writing scripts for themselves in clojure
I seem to recall that you (@jimka.issy) were doing something with long running processes running your student's code on a threadpool or something? If it's that, then you probably need to shut that threadpool down when you want to exit? Just finishing the main thread doesn't necessarily stop all the other threads from running.
@borkdude I have two sorts of students at the moment. 1) Students of my Functional programming techniques in Clojure course. and 2) first year math and informatics students. The FP students might indeed be interested. However, for the 1st year students, it would be far over their heads.
sure, you can decide if it's suited for them once you know how to use it yourself
BTW, I submitted a proposal for presentation for clojure.conj to report on my FP in clojure course. do you have an oracle to predict who’ll be accepted and who’ll be cast into the deep?
I'm afraid bb can't help you with that... unless... you teach them bb and also report about that, maybe it'll give some juice to the talk :P
but seriously no, that process is shielded from me :)
@jimka.issy Despite being involved in the CFP process, I don't have an oracle either, but if you DM me your abstract, I can give you feedback to point out anything I notice that would hurt its chances of being accepted.
Hey all! Just confirming some language on the deps.edn https://clojure.org/reference/deps_edn#procurer_mvn page - are :mvn/repos evaluated in order?
E.g., a dependency not found in central would then be checked in clojars? (following the reference example)
Similarly, would an override of central in a project's deps.edn encourage the artifact resolver(probably not the right term) to check their first? I'm trying to sort out some artifact repository priority and just want to make sure I have my arms around some of the tradeoffs if we move to an internal cache
they're defined in hashmaps so there's no predetermined order in that respect. that a given map may or may not be an "array-map" doesn't mean you can expect or assume that it will stay that way
They are not ordered but the built in repos central and clojars are always checked first, in that order
If you move to an internal repository (a great idea), you should use the built-in Maven proxy feature - this is used by tools.deps/CLI
If needed, you can “remove” the central repo by setting it to nil in the deps map
Gotcha, that makes sense! Thanks a ton Noah and Alex!