will you default to JDK 19?

when this lands, I think so yes

Any objections?

The first thing I'll probably do is make the threads in the core.async go macro use this, currently it defaults to 1 normal thread

I’m all for it

> when this lands, I think so yes so JDK 19 is out but graal is still in preview?

yeah

well, they don't have an official build yet

I see, did you need to build it yourself?

there is a dev build

k

I can send you my local build of bb if you want to play around with it :P

will they even do one or are they waiting on the next LTS or is 19 an LTS?

I think the next release will have it

I think 19 is even an LTS right

hmm no it isn't

https://github.com/oracle/graal/issues/4957

but they will have it, I'm fairly certain

exciting to finally have this

> # whoopps lol

Exciting! Love the demo format 😁

Great demo! Are you aware of any studies that compare the performance/scaling capabilities of Loom threads and virtual threads in other languages, e.g. goroutines?

@UEQPKG7HQ Not aware of those

good you're experimenting with this @U04V15CAJ but I'd be very careful

if you have Vars with thread-bounded global namespace are you sure this will work as intended?

If you remember few months back I wrote an optimistic article about Virtual thread and structured concurrency, but during night I have actually nightmares about this

I'm not sure what you're getting at

I'm getting towards how Vars are implemented

bb won't replace all Threads with VirtualThreads

they have thread-local semantics... and threadlocal is an enemy of cheap threads

dynamic vars, yes

I'd like to understand Vars deeply so my nightmare goes away

I'm not sure what could go wrong, but feel free to make a Clojure JVM repro

how def and defn work with thread-local? btw you're wildly overestimating my Clojure capabilities 🙂

@ales.najmann def and defn create globally mutable things. many things are mutable in Java. What is the problem? ;)

well if def and defn create entries in thread-local and just by referring to these things they got duplicated per thread, you have a problem. if that's the case solutions based around idea that you can launch millions of cheap virtual threads simply falls apart, because they're no longer cheap. You said that only dynamic vars follow thread semantics and use thread local - this is where I'm losing it because I didn't have time to follow white rabbit down this hole.

But you're probably right, there is no reason why Vars in general should use thread locals. I'm almost certainly exaggerating here.

@ales.najmann I tried this with both normal threads and virtual threads and they yielded the same result:

(def ^:dynamic *foo* 10)
(defn lots-of-tasks
  [concurrency]
  (binding [*foo* 111]
    (let [executor   #_(Executors/newFixedThreadPool concurrency)
          (Executors/newVirtualThreadPerTaskExecutor)
          tasks      (mapv (fn [_]
                             (bound-fn []
                               (Thread/sleep 1000)
                               *foo*))
                           (range concurrency))
          start-time (System/currentTimeMillis)
          sum        (->> (.invokeAll ^ExecutorService executor tasks)
                          (map #(.get ^Future %))
                          (reduce +))
          end-time   (System/currentTimeMillis)]
      {:sum     sum
       :time-ms (- end-time start-time)})))

At least, in bb ;)

You are right that one should be mindful about conveying bindings to virtual threads, that doesn't happen automatically, but it doesn't happen automatically with normal threads either

This is quite convincing. You're smart man. I've to do some exercise during the weekend using Clojure (or bb) around this topic. It seems like a great thing to do.

From the docs:

Virtual threads support thread-local variables, synchronized blocks, and thread interruption; therefore, code working with Thread and currentThread won't have to change. Indeed, this means that existing Java code will easily run in a virtual thread without any changes or even recompilation!

I suspect a virtual thread will always be tied to the thread it started to run on, else you can't have the above reliably OR you will have to do a lot of magic

There is a concept of pinning and my bet is thread-locals can be one cause for pinning virtual thread to an OS thread

But let me tell you why I'm so scared. I've seen video where Oracle engineer created a loop over collection of more than 10 million items launching thread for each individual one of them. If you do this and you hit pinning,your VM is toast

I wonder if it just blocks or explode... I'm not sure at this point.

The above example (in tweet) does something similar (but for 100k threads, which would normally also toast your running program)

it explodes with normal threads

ah, ok! then it's a good, very good sign.

Holy expletive! Loom is exciting tech. In babashka so soon!

Never reach for Erlang ever again... 😆

sick

yes pleeeeeaassse 🙂

The idea is basically to calculate all namespaces that are reachable from the main CLJS namespace(s) including macro namespaces and then content-hash those

and then upload the compiled CLJS under that hash on some store

and then next time you either download from the store or re-compile

Huh. That sounds like it could have a big impact on CLJS build times.

oh, it is public https://github.com/nextjournal/dejavu

also using it in clerk

oh cool

forgot that 😅 /cc @robert-stuttaford

oooooh

https://github.com/nextjournal/clerk/blob/ab655f87480e92c63eaa5ab5b6ad7592ce9e8d73/bb/viewer_resources_hashing.clj

i assume the 'compiled cljs' is the :none optimised file? how do you integrate this with shadow?

ok it looks like clerk's use is not for app cljs but for something else

to be clear, we have a 6 minute shadow-cljs :release build that we'd like to speed up, which builds 7 shadow builds. right now we're not doing anything in terms of conditional compilation; we simply build everything always. seems like this solution is about hashing the source tree, and then checking if that hash is on <storage>. if not found, build, otherwise, continue to reference existing assets in <storage>, and bypass building any cljs.

so if even one cljs or required cljc file changes, you're running your full build

I’m writing a tool in nbb that takes a description of questions from stdin or a file, asks the questions, and outputs the result to a file. (Sort of re-awakening a pet project).

One feature I want to add is something like:

{:type :number,
  :name :phone,
  :message "What is your phone number?",
  :validate '(fn [value]
               (or (= 10 (count (str value)))
                   (str "10 digits please, I got: " value " which is " (count (str value)) " digits.")))}

where you can embed functions in your questions description.

alright, you can already do this with eval I think

Thanks I’ll give it a try

you might want to wrap this in (js/Promise.resolve ...) - in the future this might change to a promise so then you will be prepared in case it changes

I'm not sure if it will change

Ah, this works right now:

$ nbb -e '(eval (quote (+ 1 2 3 )))'
6

It appears that eval returns a string. But I want the datastructure 🙂

user=> (type (eval "3"))
java.lang.String

huh...

evaluating a string returns a string

this is normal :)

oh true.

I think you are after:

$ nbb -e '(nbb.core/load-string "3")'
3

if you want to eval a string

this does return a promise btw

(import '[java.util.concurrent ExecutorService Executors Future])

(defn lots-of-tasks
  [concurrency]
  (let [executor   #_(Executors/newFixedThreadPool concurrency)
        ;; this uses one thread per concurrent operation...  too many when you
        ;; want to create 100.000!!!!  now let's swap the executor out with
        ;; virtual threads aka loom on JDK19!!!!
        (Executors/newVirtualThreadPerTaskExecutor)
        tasks      (mapv #(fn []
                            (Thread/sleep 1000)
                            %)
                         (range concurrency))
        start-time (System/currentTimeMillis)
        sum        (->> (.invokeAll ^ExecutorService executor tasks)
                        (map #(.get ^Future %))
                        (reduce +))
        end-time   (System/currentTimeMillis)]
    {:sum     sum
     :time-ms (- end-time start-time)}))

(lots-of-tasks 100000)

thanks @U04V15CAJ

Is there are way to read the error in bb shell without throwing an exception ? smth like

(shell {:out :string :err :string } "ls err") ; fails now

yeah, you can do :continue true

to not throw

you are a star of replying to messages with the speed of light !

this one works, cheers

(shell {:out :string :err :string :continue true} "ls err")

I gave the answer over there now

thanks