nbb 2023-09-05 | Slack Archive

Fit Opene05:09:31

New to Clojure. I wrote a little countdown alarm script based on the ink-demo, but when I tested it with 1000 hours, I encountered a JavaScript heap out of memory error. I found out that the code below was causing significant memory and runtime overhead.

(doseq [n (range 1 @left-time)]
        (js/setTimeout #(swap! left-time dec) (* n 1000)))

Therefore, I modified it to use setInterval instead.

(def count
      (js/setInterval
       #(if (> @left-time 0)
          (swap! left-time dec)
          (js/clearInterval count))
       1000))

Should I submit a pull request in README for this?

borkdude07:09:04

@U03FJ0E8S8L please do!

Fit Opene10:09:28

Submitted, thanks for merging. By the way, nbb is really awesome!

borkdude10:09:19

Thank you :)

👍 2

jaide20:09:50

Working on a web framework for personal projects big and small. One big enhancement would be to auto-refresh the browser after sending data to the nrepl server. Are there any systems in place that would at least let me observe the eval request? Thinking if I could at least react to eval, I could broadcast a SSE to the browser to refresh in development mode.

borkdude20:09:08

You mean some kind of middleware thingie?

jaide20:09:42

Oh yeah! I forgot nrepl supports that 😅 That would probably work!

borkdude20:09:56

well, nbb nrepl doesn't support it (yet)

borkdude20:09:14

also bb nrepl doesn't support it (yet)

jaide20:09:28

I see. I'll start by reading through https://github.com/babashka/nbb/blob/main/src/nbb/impl/nrepl_server.cljs and see where that leads

borkdude20:09:02

I guess you could re-define your eval keybindings to something which evaluates + also adds a (broadcast ..) call to the mix in your editor

jaide20:09:12

Oh right, something like that crossed my mind too. It's a viable alternative for personal use, but that would be a strong choice with the goal of publishing a framework

jaide20:09:54

A quick solution I suppose would be to use something like browser-sync to watch cljs files, and refresh browser on save

jaide20:09:56

Would it be possible to start a nrepl server via the api, then proxy it to intercept?

borkdude20:09:12

there is an nrepl api yes

jaide20:09:04

On second thought, maybe auto-refreshing on eval is not a great DX. It's not uncommon to check state like:

(comment
  @routes)

Which might create problems if it refreshes on every eval. Analyzing the eval to guess when it's a good idea to reload sounds messy so perhaps browser-sync or something more minimal inspired by it is a better solution

jaide20:09:52

Yeah that might work better: • Watch cljs files for changes • On save, connect to repl and eval the file, if successful send SSE to refresh • Server adds a script on dev mode to listen for those SSEs and triggers a refresh

jaide20:09:35

Argh maybe not, (sorry thinking out loud), not every file save should be eval'd. So maybe proxy request, but try and distinguish between a form eval (don't refresh), and a buffer or file eval (refresh). I am pretty sure every time I eval'd a buffer or file, I immediately refreshed the page to look for changes.

jaide20:09:39

For the middleware approach, is it critical it matches the existing nrepl middleware interface\implementation? In theory, it wouldn't be much work to create a promise-based ring-like middleware system for the nbb implementation

jaide20:09:12

I already have the promise-based ring-like middleware for my request layer so copying that over would be fairly trivial.

borkdude20:09:48

I don't think nbb nrepl should be compatible with existing middleware since that's usually all based on JVM anyway, right

borkdude20:09:55

feel free to draft something

jaide20:09:43

Awesome! This is what middleware usage looks like https://github.com/jaidetree/gracieanimator/blob/c2dbacaffd21cd4fb9a2323a2e70c3a0d1b50f7b/src/gracie/server.cljs#L14-L26 and most are implemented here https://github.com/jaidetree/gracieanimator/blob/c2dbacaffd21cd4fb9a2323a2e70c3a0d1b50f7b/src/framework/middleware.cljs

jaide21:09:46

To get started thinking... 1. Clone latest nbb (or update my fork) 2. Add in middleware args and support it in the server API 3. Use npm link 4. Link this client project to it, start with some logging middleware to see what happens Does that make sense? One more question that comes to mind: Should we support middleware out of nbb.edn or is it ok to start without that for now?

borkdude21:09:13

probably makes sense

Chris McCormick04:09:36

@U8WFYMFRU you might find this a useful reference too: https://github.com/chr15m/sitefox/blob/32d33aa723de9afa578efc4f35bcc8e2ddfbb7ae/src/sitefox/reloader.cljs#L10

Chris McCormick04:09:01

It is not tested very well but last time I checked it was working.

jaide07:09:36

Thanks! That’s exactly the kind of alternative I had in mind

2023-09-05

Channels