Is there a reason not to just use interop and native JS for WS support?

No reason in particular besides being largely unfamiliar with how to deal with websockets in JS. I’ve mostly used them from Clojure with Java’s built-in websocket client

I recently had to add WS stuff into an existing app that is plain HTML on the frontend -- so I only had the option of JS and it was much simpler than I expected. The WS client stuff in Java is nastier, IMO. Our backend WS server support is via the sunng ring adapter on Jetty 11 and that's a really nice integration.

Are you wondering about Frontend (ClojureScript) or backend (Clojure) Websocket libraries? On the backend I think jetty and http-kit give you a basic ring compatible WebSocket API out of the box. On the fronend - haslett gives you a very simple API. core.async is more needed for websockets on the frontend side to avoid callback hell in ClojureScript. It's not so needed for websockets on the backend where threads/blocking/locks/semaphores etc are available.

You may need to wrap any websocket library that you use with extra features: • Serialisation/deserialisation • Request/Response • Multiplexing (so you don't use lots of websocket connections per page) • Retries • Detecting disconnections • Automatic Reconnections

I've been using Sente for years and am pretty happy with it. It doesn't require core.async and does everything of the above except for multiplexing, I think. Which should be trivial to implement on top. The only downside is that you have to use Sente on both the frontend and the backend. So unless you want to reimplement half of Sente, you have to use CLJ[S] on both the client and the server.

what do people suggest for ws on the backend then

WS server? As noted above, we're using Jetty 11 in production via the sunng Ring adapter, which has really elegant WS support.

(our frontend is JS, not cljs)

this one : https://github.com/sunng87/ring-jetty9-adapter ?

In the end I went with wscljs since it’s working for my needs and wraps around the pure JS interface to websockets. My question was intended for websockets on the frontend; I have little say in how the backend is implemented, but I do have to connect to a websocket endpoint it exposes

@U01458A7CBX Yes, that's what we're using in production now for almost all our apps.

Can you paste your full namespace declaration? :require should be a keyword there

Darn, forgot the quote. The correct from is (require '["lib" :as lib])

@U017QJZ9M7W Thanks for chiming in. It's not a namespace declaration, though. I'm trying to require a namespace in the repl. https://clojure.org/guides/repl/navigating_namespaces#_how_things_can_go_wrong.

first? https://xkcd.com/221/

I mean, there's no order in a set, so by that definition I'd say the first element is any element

I get what you mean and it may actually work in my current context. Would repeated calls of this give the same element each time?

It'd be up to the specific implementation of the set, but I would be surprised if it didn't return the same element

Here, they mention something about the order being determined by the hash of the elements: https://clojuredocs.org/clojure.core/set > The actual order will ultimately be determined by the specific hashing function underpinning the data structure. Which I think is still an implementation detail, but is probably true in praxis.

What's the use-case, though? I'd definitely go for (-> my-set vec rand-nth) unless it's a very big collection

Actually, vec on a set might even be constant-time, depending on how it's implemented

(frequencies (repeatedly 1000 #(first (random-sample 0.1 (cycle #{:a :b :c})))))
;;=> {:b 344, :c 343, :a 313}

> but this seems wasteful… Did you measure it? If it's a problem, give us more insight into the the input / output and expected use-cases. Because improving performance is all about taking advantage of specific constraints of the problem (and don't generalize well).

I did not measure it. It was more of a reaction that it seems (to my mind, without actually knowing the inner workings) a redundant operation to add ordering into something for which I don’t care about the ordering purely to allow me to use a function that I do know about but needs a sequence to operate on.

Certainly (-> my-set vec rand-nth) will achieve the desired outcome and as I’m currently working with a set of 4 elements 😂 is unlikely to cause any issues…

Thanks all for your prompt replies.

rand-nth and shuffle both seem reasonable (if I was reading the code and trying to understand the author's intention)

user=> (frequencies (repeatedly 1000 #(rand-nth (vec #{:a :b :c}))))
{:a 330, :b 351, :c 319}

user=> (frequencies (repeatedly 1000 #(first (shuffle #{:a :b :c}))))
{:c 333, :b 323, :a 344}

I'm guessing the shuffle would be more expensive, especially on CLJS.

Yeah. I may put them into a separate function called rand-from-set or such. Would at least make the intention clearer

Maybe (comp first shuffle) could work for your case? EDIT: Looks like someone already recommended shuffle , didn’t notice 🙂

Using shuffle, you’ll pay the cost of allocating an ArrayList then invoking java.util.Collections::shuffle on the AL. I don’t expect this to be much more expensive than PRNGs that run something like xoshiro256 then modulo to get the value within some interval

Hadn’t spotted that you can shuffle a set. It returns a vector, but at least doesn’t need to be made into one beforehand.

in CLJS: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L2523-L2524

so convert to array, run Fisher-Yates in-place, and return vec.

(just to take first)

I can't imagine this would be faster than calling rand-int and nth on a set->vec.

(Just to be clear, this discussion is completely theoretical: with 4 elements in a set, the best version is the one that won't make the reader think. :))

At a high level, I’d agree. I don’t see it being quicker to shuffle the whole lot just to take the first element of that shuffled collection, than to take a single element at random

Totally agreed that it’s a theoretical discussion. I would always rather think about the efficiency - it won’t make a difference here, but the next time I need to do similar it could make a difference. There is a big difference between thinking about efficiency and agonising over efficiency, though! With which in mind, I shall get back to writing some bugs code

can you provide the exact error? and more importantly how you are running this? all form by form in the REPL? this really shouldn't be using (require ...)

I'm running this form by form in the REPL

Error is coming

and don't ever use core.async for promise interop if that is your only use of core.async

(ns codex
  (:require ["openai" :refer [OpenAIApi Configuration]]))

(def api-key "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")
(def conf (Configuration. (clj->js {:api-key api-key})))
(def open-ai (OpenAIApi. conf))

(-> (.createCompletion open-ai (clj->js {:prompt "const fib ="}))
  (.then prn))

Yes, this is what I tried first. However, since had the same result, I decided to give core-async a try.

or if you want something that looks more like js await use

(ns codex
  (:require ["openai" :refer [OpenAIApi Configuration]]
            [shadow.cljs.modern :refer (js-await)]))

(def api-key "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")
(def conf (Configuration. (clj->js {:api-key api-key})))
(def open-ai (OpenAIApi. conf))

(js-await [result (.createCompletion open-ai (clj->js {:prompt "const fib ="}))]
  (prn result))

What the... I just tried to reproduce it and now it suddenly works... 😦

I'll try js-await.

I'll see if I can reproduce this again later. I need to go and do something else.

working with async stuff at the REPL is not super fun

Hm, I understand. The repl is very immediate and async requests are not. I thought, <p! would halt execution though.

it does not no

Ah, right there was a difference between CLJ and CLJS. Darn

no different in CLJ with async code

but you have the option to block and wait for the result, so that is missing indeed

That's what I meant. I feel like the added value of using this nodeJS library is getting slimmer and slimmer. I might as well write my own client. Especially since their client is only published as optimized code and I have no way to see what it does.

your client won't be able to block either?

or do you mean CLJ? there is a java API is there not?

They have a Python and a JavaScript client published afaik.

https://github.com/benjamin-asdf/codex-play/blob/main/main.cljs if it is any help to you I have here an example using the node package with nbb

Does it help when you put a :refer [my-let] in there?

(:require-macros [repro.macros :refer [my-let]])?

ah, that sorts it.

I didn't realize that's how it worked inside the same namespace.

@U017QJZ9M7W Here's the answer to your question recently ^

👍

There's #C0620C0C8 and code blocks should be formatted as blocks and not as inline code. As to the actual question, just don't call components as functions. Lots of ways to do it. E.g. you can add # in front ot (component "John").

thank you, it works!

You can easily experiment with that syntax using your browser's DevTools JS console.

But also, there's no return statement and it's not a lamda, so nothing is returned.

Ok, I will play some more with the DevTools ... right now I am just returning this (.drawArrays gl (.-TRIANGLE_STRIP gl) offset vertex-count)

I bet the result of drawScene is completely ignored. And most likely, drawArrays doesn't return anything either.

I wasn't sure what was going on with the javascript.. seems wierd that they made an object just to declare some const and call the gl.drawArrays(...) method. Thanks for the help

That {} is not an object, it's just a block.

But you're right, even as a block it's completely pointless. Perhaps some copy-paste mistake.

its not entirely pointless in theory. blocks provider their own scope, so the const declared there is only available in that block. pointless here since there is no other count

but for CLJS you can just ignore it since we have clear scoping rules anyways 😉