I mean you could do something awful like this after connecting:

(defn ^java.io.PrintWriter ^:private auto-flushing-print-writer
  "Like clojure.core.PrintWriter-on, but with auto-flushing enabled."
  [flush-fn close-fn]
  (let [sb (StringBuilder.)]
    (-> (proxy [java.io.Writer] []
          (flush []
            (when (pos? (.length sb))
              (flush-fn (.toString sb)))
            (.setLength sb 0))
          (close []
            (.flush ^java.io.Writer this)
            (when close-fn (close-fn))
            nil)
          (write [str-cbuf off len]
            (when (pos? len)
              (if (instance? String str-cbuf)
                (.append sb ^String str-cbuf ^int off ^int len)
                (.append sb ^chars str-cbuf ^int off ^int len)))))
      java.io.BufferedWriter.
      (java.io.PrintWriter. true))))

(def original-err *err*)
(def my-err (auto-flushing-print-writer #(doto original-err (.write ^java.io.Writer %) .flush) nil))
(set! *err* my-err)
(set! *warn-on-reflection* true)
(.toString (identity "foo"))

Or if you control the server, you could just make your own version of io-prepl.

I do control the server 🙂

Thanks for putting the time into that answer!

looking at io-prepl I'm struggling to see how to affect the *err* flush operations in the prepl. What am I missing?

and I have tried setting *err* after starting the socket server as you suggest and I'm still not getting back any :err tags

Sorry, yeah, you'd actually need your own version of clojure.core.server/prepl, not io-prepl.

That's odd. I tried the above using nc and I did get the reflection warning back.

Or actually both io-prepl and prepl. 🙂

I didn't clean that up at all, but given that and then clojure -X clojure.core.server/start-server :name prepl :port 5556 :accept foo.core/io-prepl :server-daemon false, then nc localhost 5556, I can get the reflection warning to show up.

yes, I figured later that you must have meant prepl - thanks for getting back 🙂

kinda tedious to have to fork it but :man-shrugging::skin-tone-3:

Indeed, it's not great.

Thanks for all of your time and advice.

Sure thing, not sure how useful any of it was, though. 🙂 I just happened to have wrestled with the same thing (flushing err to make reflection warnings show up) in my own work recently.

It's useful: we arrived at the agreement that it's a simple correction but it needs to be fixed in core or we have to fork / patch it which is 😢

Given that the fix is a one liner, is it even worth making a patch? @U064X3EF3??

Can you put all this on the ask Clojure question for it? I get mentioned on dozens of threads a day, in multiple slacks. Ask Clojure is the place to create public durable conversations about requests for Clojure in a votable, trackable form

https://ask.clojure.org/index.php/10735/prepl-warnings-remain-buffered-until-explicit-flushing-client

Of particular interest are impact and need to fork/copy to work around

I don't understand the question you asked of me, are you asking if it's worth fixing or worth doing the work of making the patch? (In both cases, yes)

but I'd want to make sure we have isolated what the problem is here. is it that the error stream is flushed on delay? or that the delay is too long? or that warnings should flush? or something else.

ok thanks - I'll add some comments to the Ask Clojure posting and maybe @U4ZDX466T can weigh in too

I have posted a summary on https://ask.clojure.org/index.php/10735/prepl-warnings-remain-buffered-until-explicit-flushing-client?show=10735#q10735

I have added a patch for PrintWriter-on and prepl to that Ask Clojure question

do you want to add them to the jira?

sure but I don’t have a login AFAIK

invite sent

Thanks - I’ll post it tomorrow, getting late here now.

Done

Thanks, not going to look at it imminently, but I've added it to our 1.12 consideration list.

Thanks, looks like what I was looking for

I think I'm doing something wrong. If I want to invoke a method I should lookup in an object with a method type which includes only the arguments?

When you find time, I'd appreciate a simple example. Perhaps with a StringBuilder?

Show what you tried, also search this slack for “signature polymorphism”

I actually don't need signature polymorphism for my specific use case, just trying to pull teeth working with gRPC

I'll send it over tomorrow, falling off my feet

Okay, I managed something like:

(let [lu (.in (MethodHandles/lookup) String)] (.invokeWithArguments (.findVirtual lu String "toUpperCase" (MethodType/methoType String)) ["abc"]))

if there a clean way to parse json from a channel that would be amazing. The channel is made up of many raw strings that may be made up of json fragments (e.g. messages 1-3 can make up 1 json blob)

so channel messages can look like:

temp (async/chan 10)
(async/>! temp "{ \"a\":")
(async/>! temp "5 }")

result-ch (async/chan 10)
(println (async/<! result-ch))
; prints {:a 5}

I have a utility that does this that I can scrounge up @U01BK5E5ESY . Can I ask what the application is?

@U050ECB92 that would be super useful

the specific application is for reading streamed responses from an api thats sending json events

https://github.com/cognitect-labs/aws-api/blob/f1dc97e3cab612e23ad1604e9cce75a081e9042c/src/cognitect/aws/chanutil.clj#L6-L56

@U01BK5E5ESY this differs from what you want in one way: it is adapting a channel of byte[]s to an InputStream, whereas you are looking for a channel of Strings or char[] adapted into a Reader

both InputStream and Reader are blocking I/O sources

this is one of the wickedest fns I've written.

interesting:

{:inputstream (proxy [InputStream] []
                     (close [] (error! nil))
                     (read
                       ([] (read1))
                       ([b] (readN b 0 (count b)))
                       ([b off len] (readN b off len))))

What is the downside of this approach here:

body-chan
   chan-to-lazy-seq!!
   (map (fn [chunk] (-> chunk .getBytes ByteArrayInputStream.)))
   Collections/enumeration
   SequenceInputStream.
   InputStreamReader.

does it work?

yes

I don't know what chan-to-lazy-seq!! is

(defn chan-to-seq!!
  "Takes a channel and returns a lazy sequence of channel messages"
  [c]
  (lazy-seq
    (when-some [v (async/<!! c)]
      (cons v (chan-to-seq!! c)))))

seems ok, I haven't thought too deeply about it

Can't you extend https://docs.oracle.com/javase/8/docs/api/java/io/Reader.html instead?

(proxy [java.io.Reader] []
  (read [chars offset length] ...) ;; Here you take from channel and put into chars
  (close [] ...) ;; Here you close the channel

chars is an array, offset is the array index you need to start at for inserting the chars into, and length is the max number of chars you can insert for a call to read

So basically, take length number of char from the channel and aset them into the chars array starting at index offset

And when close is called, just close the channel.

You can now use this proxy with parse-seq on cheschire I believe. Or if not, wrap it in a BufferedReader and that should work I'm pretty sure.

> chars is an array, offset is the array index you need to start at for inserting the chars into, and length is the max number of chars you can insert for a call to read does that mean i need to store the entire total string in memory as I pull from the chan (async/<! ch) (i assume so because we need to support the various offset values)?

No I don't believe so. I think what happens is: The reader provides an array, and ask for say 10 char to be read at offset 0, so it calls read with that. The reader then read the array from 0 to 10, if the reader feels they don't have enough... say the JSON is not complete like you only got: {"hey" : " and this can't be parsed yet. So the reader will call read again, with the same array, but will ask for another 10 char to be read from offset 10. Now maybe the reader gets: {"hey" : "bob"} and this is enough to parse, so the reader can parse that and be done, now it will call close.

But, the reader could also choose to continue reading... and the next time it calls read, it can choose to pass a new char array and set the offset back to 0. Allowing the prior char array to be garbage collected.

I think this is what say a LineReader will do. The LineReader will read from another Reader say 10 char at a time into a first array for the first line. When it sees a line ending, it will call read with a new array for the second line, Or it can even choose the same array but overwrite it, by just having the offset be 0 again.

So its up to the user of the Reader to decide like if it cares to remember everything read till now or not, by choosing how to call read

okay I'll play around with it and report back later

Keep in mind that read should block until some input is availaible.

If read is called and the channel closes in the read, you can return -1 to indicate to the reader that the stream ended.

I couldn't resist:

(defn chan->reader
  [c]
  (proxy [java.io.Reader] []
    (read [chars offset length]
      (let [first-char (async/<!! c)]
        (if (nil? first-char)
          -1
          (do
            (aset chars offset first-char)
            (reduce
             (fn[acc e]
               (if-let [char (async/poll! c)]
                 (do (aset chars (+ 1 offset e) char)
                     (inc acc))
                 (reduced acc)))
             1
             (range (dec length)))))))
    (close [] (async/close! c))))

(def char-chan (doto (async/chan)
                 (async/onto-chan! [\a \b \c \d \e \f \g \h \i \j])))

(def char-reader (chan->reader char-chan))

(slurp char-reader)
"abcdefghij"
(slurp char-reader)
""

I think that should work. Can try it with cheshire, and maybe need to wrap it in a BufferedReader as well, since I saw cheshire parse-seq has a BufferedReader type hint

(def char-reader-buff (java.io.BufferedReader. (chan->reader char-chan)))

(slurp char-reader-buff)
"abcdefghij"
(slurp char-reader-buff)
java.io.IOException: Stream closed

Unless you mean some specific server, I don't think browsers cache CORS-related headers.

I mean server side.

I'm wanting to initially be open to requests but then lock down those requests after a period of time once I know the origins

You're in full control of the server side. Maybe some particular sever would not have an easy way of implementing what you want, but in general it should be possible.

Write some custom ring middleware that conditionally applies the logic of https://cljdoc.org/d/ring-cors/ring-cors/0.1.13/api/ring.middleware.cors#wrap-cors

Yea I've tried that. I think Reitit might be doing something special. I even tried doing a namespace reload but it doesn't work when I package it up.

Can you share a bit of that code? My guess is a #' can be slapped somewhere and your problem goes poof