It is quite likely no one is using it. The output capture is implemented by eftest: https://github.com/weavejester/eftest#output-capturing But I don't remember how those options are passed in with bat-test, or if there is a support. Looks like bat-test impl passes the whole opts map to eftest, with some changes, but e.g. from boot task there probably isn't way to add extra options properties.

OK, thanks.

I'm kinda surprised http://clojure.org just allows 500 x n fast as possible requests. Is it returning 200 response codes every time? Not sure how/if error responses would effect performance though

Are you sure that keepalive might not come into play in this case. It seems to be enabled by default for http-kit https://http-kit.github.io/client.html

But also seems to be the case for Go.

http://clojure.org is static files served on cloudfront so you're at the whim of whatever edge cache you're hitting. why http and not https? former should be redirecting to the latter.

also keep in mind that we're paying for each of those requests :)

https://reqres.in/ is perhaps a better endpoint to benchmark with.

Yeah I couldn't come up with a wording for "it might not be the best etiquette" that captured the magnitude of the etiquette violation I wanted to convey

Sorry @U064X3EF3 I should switch it to http://golang.org and make El Goog pay instead haha

I mean, it's pennies, but maybe :)

https://golang.org Clojure gets 451ms vs 1.864s on GO

Tried to set Go to use HTTP/1.1 only as well, since it was also using HTTP/2 and http-kit doesn't, but I get similar results either way.

@U0K064KQV Sounds like a good story for Hacker News.

Haha, I'm scared of the comment section of such a thing 😛

Unless I missed sth more obvious, it looks like atoms ultimately delegate to https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/share/classes/sun/misc/Unsafe.java#L863-L865 (via AtomicReference) not sure of how to jump from Java code to C code :)

reset! is a volatile variable assignment, there's no way it can fail

I don't think volatile == CAS, for one thing they're different concepts/mechanisms in Java else clojure's Atom would look a lot more like clojure's own volatile!

I'm using reset! from a child process to send the result back to the main process so the main process can handle the result. I want to be sure the result gets handled eventually.

reset! doesn't use CAS

@U0232JK38BZ you can be damn sure reset! will eventually succeed, unless perhaps you intentionally place a scenario of extreme contention I thought this was more of a 'fun' theoretical question

@U053XQP4S you're right, I was chasing the path for swap! not reset! (the question made me think of retries which brought swap! to mind)

But will every reset! be handled by the watcher that watches the atom that is reset?

Looks like it https://github.com/clojure/clojure/blob/b8132f92f3c3862aa6cdd8a72e4e74802a63f673/src/jvm/clojure/lang/Atom.java#L153-L159 , there isn't branching etc

The <String> part does not exist in runtime or during compilation. Just List should be enough.

In my experience, nil and an empty collection are usually the same, semantically speaking, so I don't bother with consistency in this particular case.

Meh, I worded that poorly... I meant they're semantically the same as output types, not in every possible scenario. As in, should it matter whether filter with no matches gave back nil vs an empty collection? I don't think so

false/nil is like -1 to me [] is like 0 to me everything else is like a positive integer to me

Ι don't get the analogy. Can you elaborate?

You probably need the add-lib3 branch: https://github.com/clojure/tools.deps.alpha/tree/add-lib3

Until it is you can use the branch as a git dependency

@UGC0NEP4Y see here: https://github.com/seancorfield/dot-clojure/blob/3113dbde7e07d9ad45828259c29b58e4af79430e/deps.edn#L93

I have an add-libs in my deps.edn too, it works fine, just just have to require in the namespace

then you can use it

note 'tho, the note at the bottom about using a dynamic class loader.

Not sure how the “if we’re starting other processes via aliases ;; such as a socket REPL or Cognitect’s REBL etc” actually means.

do you use it just to try stuff, or do you later add those libs to your deps.edn?

Both, i.e. there are times when I try some lib to see if it works for me, and if it is, I'll add it to deps.edn; and there are times when it's for a throwaway code that gets deleted

ditto! Very useful for trying things out, then if the experiment works, to incorporate it into my deps.edn

Actually, I usually add lib to deps.edn and then call add-libs with that lib, so it's both available at the repl without restart and cursive indexes it to provide autocomplete

one thing we've wondered about are ratio of "temp experiment" to "know you need" and for the latter, whether it would be useful to have • runtime libs -> persist to deps.edn or • sync runtime from deps.edn (so you'd modify deps.edn, then sync) options instead

lots of thorny questions in both cases but just thinking about workflows

That's a great insight into the thoughts around the situation 🙂 Thanks for sharing.

Don't ever quote me crediting CL, but the ability to interactively "freeze" or image those dependencies could be useful, i.e. the relationship between deps.edn and the runtime can be bidirectional

this is generally, very hard to represent. any particular classpath for a project is created from a set of root deps, optionally some aliases that modify that, and then many transitive deps. the versions selected are dependent on that set of deps at classpath calculation time. adding new libs at runtime as new top-level deps is a best effort exercise (you can't "upgrade" or change a version of something you've already included, and you are adding that new dep and its transitive deps in the context of a set of "pinned" versions for all transitive deps. there are lots of ways to get different answers than if you'd started fresh and/or invalid combinations.

that sloppiness is probably ok if you mostly understand your deps tree and and how this can go wrong (if you add new deps enough times, you will eventually fall over), but that is hard to communicate to a broad range of users. you also want to avoid leading people into this as a way to start an app, so it should be a "repl-only" thing

wait, I still didn't get to the point where you replace git with a series of edits in a graph database 🙂

But enough spoilers for the next blog post 😛

maybe we should call the function try-lib instead or something to indicate it's potential for failure :)

Can you elaborate? Seems like you just need to know the {:context ...} map, which is a different kind of context - you will know it just because go-inst is something you control. I'm 95% certain regular walk will work wonderfully in your case given that you seemingly need to just replace a particular form with a wrapped version of the same form.

With walk, I'll need to find a way not to wrap with both contexts the <! of the inner go-inst. With zip it seems that it will work like this with no effort

But I might be wrong

That's only a problem with prewalk, but you can just use clojure.walk/postwalk (assuming I understand your comment correctly).

If I use postwalk I won't be able to differentiate between forms that were part of go-inst block and rewritten as a go block and forms that were orginally part of of go block

Not sure I follow. I might need an example. Wouldn't the following work?

(defn go-inst* [ctx body]
  (clojure.walk/postwalk (fn [form]
                           (if (and (list? form)
                                    (#{'<! '>!} (first form)))
                             `(do
                                (println ~(str "entering " (:context ctx)))
                                (let [val# (~(first form) ~@(rest form))]
                                  (println ~(str "leaving " (:context ctx)))
                                  val#))
                             form))
                         body))

(defmacro go-inst [ctx & body]
  `(go
     ~@(go-inst* ctx body)))

Let me clarfify what I mean with an example:

(go-inst {:context "my-context"}
                                (let [c (chan)] 
                                  (>! c :data)
                                  (<! (chan)))
                               (go-inst {:context "your-context"}
                                (let [c (chan)] 
                                  (>! c :data)
                                  (<! (chan)))) )

Is macro expanded to:

(clojure.core.async/go
 (let
  [c (chan)]
  (do
   (clojure.core/println "entering my-context")
   (clojure.core/let
    [val__12648__auto__ (>! c :data)]
    (clojure.core/println "leaving my-context")
    val__12648__auto__))
  (do
   (clojure.core/println "entering my-context")
   (clojure.core/let
    [val__12648__auto__ (<! (chan))]
    (clojure.core/println "leaving my-context")
    val__12648__auto__)))
 (go-inst
  {:context "your-context"}
  (let
   [c (chan)]
   (do
    (clojure.core/println "entering my-context")
    (clojure.core/let
     [val__12648__auto__ (>! c :data)]
     (clojure.core/println "leaving my-context")
     val__12648__auto__))
   (do
    (clojure.core/println "entering my-context")
    (clojure.core/let
     [val__12648__auto__ (<! (chan))]
     (clojure.core/println "leaving my-context")
     val__12648__auto__)))))

While it should be expanded to

(clojure.core.async/go
  (let
    [c (chan)]
    (do
      (clojure.core/println "entering my-context")
      (clojure.core/let
        [val__12648__auto__ (>! c :data)]
        (clojure.core/println "leaving my-context")
        val__12648__auto__))
    (do
      (clojure.core/println "entering your-context")
      (clojure.core/let
        [val__12648__auto__ (<! (chan))]
        (clojure.core/println "leaving your-context")
        val__12648__auto__))))

If you need nesting where inner go-inst completely supersedes the outer one, I think you can just leave any calls to go-inst in your postwalk function as they are.

If you need to be able to replace just some parameters (assuming there can be more than just :context), then you can change the go-inst form in your postwalk function so its argument is (merge outer-params inner-params).

How can I leave any calls to `go-inst` in my postwalk function as they are?

Just check that the first item of a list is go-inst and ignore that list.

hmmm. I need to think about it

Indeed, there's none.