Clojurians Log v2

@dnolen I used your mies template for convenience to repro. Is that not the bar anymore?

to clarify, I changed:

(let [start (System/nanoTime)]
  (b/build "src"
    {:main 'cljs.could-not-write-js.core
     :output-to "out/cljs/could_not_write_js.js"
     :output-dir "out"
     :verbose true})
  (println "... done. Elapsed" (/ (- (System/nanoTime) start) 1e9) "seconds"))

(let [start (System/nanoTime)]
  (b/build
    {:main 'cljs.could-not-write-js.core
     :output-to "out/cljs/could_not_write_js.js"
     :output-dir "out"
     :verbose true})
  (println "... done. Elapsed" (/ (- (System/nanoTime) start) 1e9) "seconds"))

Looks like this arity was added in 1.10.238, but has never worked (for this at least).

just heads up, playing with Chrome Canary, I just realized that chrome devtools devs are probably going to remove support for custom formatters: https://bugs.chromium.org/p/chromium/issues/detail?id=1016755 this will likely affect cljs-devtools and maybe some others like shadow-cljs the setting is not sticky anymore in current chrome canary, but can be re-enabled for current devtools session: https://github.com/binaryage/dirac/commit/b0af5f27f10caccc68275e6a1d49aa0fcb4f2705#diff-3cf273a40d7f903d23ccccd12a43b157R65-R66

that’s pretty shite

I wonder what the alternative is that Dart is pursuing

don’t know, I requested access to the design doc they mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=1016755#c3

I guess they are going to introduce a safer alternative with less flexibility in styling the content

I was hoping something would be standardized tbh. I'm still using Firefox.

I've reached to FF DevTools people a while ago, they also think what Chrome has for custom formatters atm is not safe.

I guess we gotta build our own REBL after all 😕

Isn't Dirac available as Chrome extension rather than DevTools fork?

Dirac is always a devtools fork. But newly Chrome can be launched via a helper tool without needing to fiddle with chrome extension setup. I put quite some effort into making it zero-config: https://github.com/binaryage/dirac/releases/tag/v1.5.0

oh wow, I had no idea re: dirac CLI. i’ll have to try this soon

@dnolen Was great to hear about your interest in cljs on Dart. I've experimented on Dart emitter for cljs at some point but that was too overwhelming for a single person.

also agree about compiler's modularity, having js stuff decoupled from the analyzer could make it easier to develop for new targets

on a slightly different topic, I spent last month or so on this project[1], the end goal is to use it to do live-scripting of Blender with ClojureScript[2]. During the process I got somewhat familiar with V8 and its C++ interface. I believe it would be possible to use self-hosted clojurescript and run it inside customized V8 which has performance-critical pieces written in C++ (e.g persisten data structures, disabled GC for compilation pass). This could (in theory) produce faster compiler drop-in replacement (macros would be evaluated in another process in classic cljs compiler running java). Maybe it is totally bad idea, but it sounds like a fun challenge - the goal is to use classic cljs compiler sources as-is, so it is not an alt impl/fork, just custom runtime for it. [1] https://github.com/darwin/naga [2] https://github.com/darwin/blender-clojure

IIRC JSC has better perf characteristics, at least cljs benchmarks usually look better for JSC

Ok, cool. btw. The meta idea is that with your proposal. Parts of self-hosted cljs compiler could be compiled into C++ (as C++ target). Parts could be hand-written and just V8 would be instructed to replace JS versions with hand-written versions. And this could be done incrementally. Starting with no retargeted code and no hand-written C++…

They just gave me access to the doc. In short they are going to remove it without a replacement (after user feedback consideration)

yeah that would be interesting. I also heard from Mike that they had an idea to target C from cljs with copy on write data structures

every time I start looking into a new target for cljs it's just too many small details and noise because of JS stuff here and there

@dnolen How would you feel about a patch to optimize the frequency of calls to :bundle-cmd? Currently it's called on every change, but it only needs to be called when the set of npm packages that are required changes. Most of the credit goes to @bhauman for the idea, but I'm happy to champion it & try figure it out if you're interested. I'm particularly burned by this due to webpack taking ~4s to run on our project during dev for some reason.