local web server is one way. You can sometimes/usually configure a localhost URL for the redirect, at least for dev purposes. Mobile apps often register a unique URI scheme/handler and redirect to <app://callback> or whatever. You can also see if your OAuth provider supports the device authorization flow which allows the user to complete the auth flow in a browser while your script polls for a token.

There's #C01AZBR8HHT but it hasn't had any activity for more than a year... I think a good starting point is to choose a project you use personally (assuming you're not a beginner in Clojure), go through its open issues and offer to work on it and either get the go ahead or move on to another project (or even fork it and do your own thing 🤷).

Do you have a preferred problem domain?

How experimental versus mainstream do you want to be?

Web development; I could do with a lot of experimenting, as far as we are using cutting-edge technology and trying the optimal solution.

I could work with mathematical/engineering-related problems as well, since I have the background. So, scientific computing and the like. I'm open, just want to learn more, and build practical applications, at the same time that I collaborate.

Would you prefer to work on productivity tools? Developer tools? Business-style application?

Either or. I have more experience building business-style applications.

For productivity applications, I would suggest Logseq.

Great, I will give it a try. Thanks!

probably worth discussing in #C04SCGV2ATX

I don't have an authoritative answer, but personally I try to eliminate laziness in performance critical code wherever I can. I use various strategies to do that. Very often I switch to using transducers via (into [] f source) , which is both lower overhead and better for tracing. Occasionally I use transient directly together with reduce, especially when I am concatenating a sequence or building a set from multiple sources/transforms. Fundamentally I don't think there is a way around cleaning up laziness in your program if it's performance critical and you want to be able to profile it accurately. At least not that I know of.

Hello Tom! Laziness is indeed a big hurdle to overcome when profiling and reasoning about the performance. Unfortunately, there are no shortcuts to make it magically go away. All I can suggest is use more of vector-producing functions like mapv, filterv , and the like. Like @U01D37REZHP said, if it's the part of the program where you care about the performance, it's most often a good idea to get rid of laziness anyway.

Regarding something like doall for nested collections: there is a hack for that, you can call pr-str on the top-level collection and throw away the result. Of course, that itself would spend quite some time on serializing to string, but if your intermediate goal is to measure, not to make everything faster immediately, then it could be useful to you.

I think the pr-str thing that I've seen around is a bad idea. I've seen this trick find its way into at least one library. Instead of that, why not something like this?

(defn realize-recursive [data]
  (doall (tree-seq coll? seq data))
  data)

(let [a (atom 0)
      x (map (fn [i] (map (fn [j] (swap! a inc)) (range (* i 2)))) (range 100))]
  [(count x) @a])
;; => [100 0]

(let [a (atom 0)
      x (map (fn [i] (map (fn [j] (swap! a inc)) (range (* i 2)))) (range 100))]
  [(count (realize-recursive x)) @a])
;; => [100 9900]

Maybe a better name would be doall!

... umm I could probably be more diplomatic! I didn't mean to be rude, I hope it wasn't taken that way! 😅

It's OK, don't worry:) I suggested pr-str as a crutch to facilitate profiling, surely it shouldn't be left around in the working code. It's main benefit is that it's already there, nothing new has to be written:)

Thanks for some ideas! Perhaps I should just go the non-lazy route everywhere I care about