Perhaps you could pair clj-reload with a file watcher such as https://github.com/nextjournal/beholder?

I’ve used beholder with clj-reload and it works well. But my current setup is custom calva’s custom repl command to do the reload. Mostly because of my obsessive cmd+s habit on every new line of code,

Thanks, @U3X7174KS and @U06G9HMLGPM! I wanted to make sure I wasn’t reinventing the wheel here 🙂

I knew about hawk, but not beholder. interesting.

what’s wrong with reinventing the wheel? 😄

Any time! Happy to aid in both wheel-finding and wheel-inventing, whatever floats your boat.

uhm, boats dont have wheels ☝️🤓

Good point! I'll have to invent some better metaphors. "whatever gets your engine humming"?

I think your metaphor was perfect. I am a fan of mixing them up, gives some spice to life. I was just doing the "annoying person" role-play.

I don't have anything specific but this sounds like the Racket community's kind of jam

Yeah. On https://beautifulracket.com/appendix/why-lop-why-racket.html

love his writing!

Domain Driven Design has also ideas about this of course. You have to translate it a bit into the functional world but in my opinion, ubiquitous language and model driven also applies to clojure apps, at least at medium scale.

How different is creating these DSLs with Racket vs say using instaparse with Clojure?

big picture, both can do the thing but Racket, being permeated with this as their raison d'etre, has things like #lang declarations to streamline the process. other than that the thing that jumps out to me is that instaparse is quite slow.

one thing to think about is, do you need a DSL with custom parsing or does a bit of EDN data do the job. This is what I went for with https://github.com/soulspace-org/overarch and I've written a bit about the decision in the rationale and the design document..

I think, instead of alts! you can use poll!: https://clojuredocs.org/clojure.core.async/poll!

But AFAIK, neither poll! , nor alts! can retroactively consume the values from the channel if the control flow already went forwarrd.

thank you!!!

and you're right! poll is a better fit for me

Note that your modified code will spin endlessly and without blocking, so this is probably not what you have in mind.

Sorry, I see now that it will throttle on c'

ehh... true, needs some more thought

but the while loop will keep going

but maybe it's ok

I think you will still need alts! to differentiate between no value and closed channel.

> How would you go about debugging this? Without being familiar with Undertow at all - by reading through its sources, finding the place(s) where the data is actually being sent, and putting a conditional breakpoint there that triggers only if the data doesn't start with {.

Noob question: How do your workflow look for > putting a conditional breakpoint there Undertow is written in Java, and I don't have the most experience with this. What are the steps you take to do this? If there' any pointed you have would love it. Thanks @U2FRKM4TW!

I have very little experience with other IDEs, but in IntelliJ IDEA it's trivial: right click on the line number -> add conditional breakpoint.

Heck, okay -- I am going to get idea + cursive and give this a try! Thank you @U2FRKM4TW!

how are you printing out the data you are getting from the websockets?

because it looks sort of like synchronized printing out from multiple threads

thread 1 prints starts printing a map and thread 2 starts printing, and the output ends up intermingled

(and 2 tabs => 2 websockets => 2 threads servicing the websockets)

I have two chrome tabs with try catch over the message handler:

this._ws.onmessage = this._wsOnMessage;
    // ...

  _wsOnMessage = (e) => {
    try {
      this._handleReceive(JSON.parse(e.data.toString()));
    } catch (error) {
      debugger;
    }
  };

(Added more examples in a https://stackoverflow.com/questions/78444592/undertow-seems-to-send-corrupt-messages-when-enabled-with-permessage-deflate version of this question)

Could you have multiple threads doing json encoding to the same output stream, and then data from that steam is going out over the websocket?

Could there be a big in the server side code where everything is writing to the same websocket

Does it look more and more corrupt the more tabs you open?

The way you are doing the per message deflate thing is done, you are create a new instance per request, which seems like it would be the correct way to use such a thing, but maybe it needs to be created once and re-used

And true should be false

https://undertow.io/javadoc/1.3.x/io/undertow/websockets/extensions/PerMessageDeflateHandshake.html the boolean argument is if the code is running as a client or server, server is false

https://issues.redhat.com/browse/UNDERTOW-684?focusedCommentId=13203543&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel looks similar but is marked resolved

I do think you're onto something about multiple threads writing to the same shared resource. I don't think it's the json encoding. This is where I do it:

(defn send-json!
  "Serializes `obj` to json, and sends over a websocket."
  [obj ws-conn]
  (let [obj-json (cheshire/generate-string obj)
        p (promise)
        _ (WebSockets/sendText
           ^String obj-json
           ^WebSocketChannel ws-conn
           (proxy [WebSocketCallback] []
             (complete [ws-conn context]
               (deliver p nil))
             (onError [ws-conn context throwable]
               (deliver p throwable))))
        ret @p]
    (when (instance? Throwable ret)
      (throw ret))))

(defn send-json!
  "Serializes `obj` to json, and sends over a websocket."
  [obj ws-conn]
  (let [obj-json (if (#{:refresh-presence :set-presence-ok} (:op obj))
                   (cheshire/generate-string {"op" "ping" "id1" (java.util.UUID/randomUUID)
                                              "id2" (java.util.UUID/randomUUID)
                                              "id3" (java.util.UUID/randomUUID)
                                              "id4" (java.util.UUID/randomUUID)
                                              "id5" (java.util.UUID/randomUUID)
                                              "id6" (java.util.UUID/randomUUID)
                                              "id7" (java.util.UUID/randomUUID)})
                   (cheshire/generate-string obj))
        p (promise)
        _ (WebSockets/sendText
           ^String obj-json
           ^WebSocketChannel ws-conn
           (proxy [WebSocketCallback] []
             (complete [ws-conn context]
               (deliver p nil))
             (onError [ws-conn context throwable]
               (deliver p throwable))))
        ret @p]
    (when (instance? Throwable ret)
      (throw ret))))

(I tried changing client? between true and false and got no benefit there either)

https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/websockets_extension/WebSocketServer.java#L61 shows creating a single PerMessageDeflateHandshake object and not a new one per request, and shows passing false instead of true

Maybe just try throwing a (locking #'send-json! ...) around the body of send-json! and see if that eliminates the corruption

sendText is going to write to a buffer, then call a callback when the buffer has been flushed out, so it seems plausible that writing to the buffer from multiple threads could be unsafe

I guess mapv should have checked that though

FWIW I'm also using this in shadow-undertow (and therefore shadow-cljs). although only ever creating on instance of the handler per server, so maybe try that? https://github.com/thheller/shadow-undertow/blob/bf84dab4989f21601c52449a36fda4dabe2e067a/src/main/shadow/undertow.clj#L518-L520

Update: I tried a hack, where I cached the handler , but the issue persisted. However : I can't repro anymore whenever I add locking!

(def lock (Object.))
(defn send-json!
  "Serializes `obj` to json, and sends over a websocket."
  [obj ws-conn]
  (locking lock
    (let [obj-json (->json obj)
          _ (clojure.tools.logging/infof "Sending JSON locked: %s" obj-json)
          p (promise)
          _ (WebSockets/sendText
             ^String obj-json
             ^WebSocketChannel ws-conn
             (proxy [WebSocketCallback] []
               (complete [ws-conn context]
                 (deliver p nil))
               (onError [ws-conn context throwable]
                 (deliver p throwable))))
          ret @p]
      (when (instance? Throwable ret)
        (throw ret)))))

it maybe that websockets are no longer thread safe once you add the deflate extension thing

Ah! That could be it. Thank you @U0NCTKEV8