Welcome! Please see the About page for a little more info on how this works.

+1 vote
in REPL by

Given a pREPL client that evaluates this expr:

(do
    (-> (bound-fn []
          (dotimes [_ 4]
            (Thread/sleep 100)
            (println 1)))
        Thread.
        (doto .start))

    1)

Output will be, correctly:

{:tag :ret, :val 1, :ns user, :ms 4, :form (do
        (-> (bound-fn []
              (dotimes [_ 4]
                (Thread/sleep 100)
                (println 1)))
            Thread.
            (doto .start))

        1)}
{:tag :out, :val 1
}
{:tag :out, :val 1
}
{:tag :out, :val 1
}
{:tag :out, :val 1
}

Now, the problem is, that output that came from a thread may be printed anytime, maybe 1 minute from now.

During that time, many other pREPL requests may have been processed.

So in absence of an ID, a message like {:tag :out, :val 1} lacks sufficient context to be able to track where it's coming from.

Would adding IDs be a good idea?

1 Answer

0 votes
by

Output and error are streams and not tied to any particular request - there is no general way to correlate these, so no that does not seem like a good idea.

by
It would technically be possible to create a new *out* binding for each eval that carries that id. For CLJ at least, for CLJS due to the async nature that wouldn't be of much benefit. I agree though that it seems best to me to treat out/err streams as separate from evaluation since they can come from to many "sources".
...