Fork me on GitHub

@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)]
    {: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"))
And that causes the "Could not write JavaScript nil`


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: 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:

😱 16

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


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


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.

Roman Liutikov18:05:34

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 😕

Roman Liutikov18:05:23

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:


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

Roman Liutikov18:05:50

@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.

Roman Liutikov18:05:50

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

👍 8

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] [2]

Roman Liutikov19:05:23

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++…

Roman Liutikov19:05:27

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

Roman Liutikov19:05:22

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.