Clojurians Log v2

Apparent problem commit: https://github.com/clojure/clojurescript/commit/e86a369d7f99a43e5745e7b425f199d7966be426 Missed call site: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L660

[:main] Configuring build.
[:main] Compiling ...
[:main] Build failure:
------ ERROR -------------------------------------------------------------------
 File: jar:file:/home/logan/.m2/repository/org/clojure/clojurescript/1.12.116/clojurescript-1.12.116.jar!/cljs/js.cljs:660:13
--------------------------------------------------------------------------------
 657 |       (let [{:keys [global-exports]} (get js-dependency-index (name dep))]
 658 |         (.append sb
 659 |           (with-out-str
 660 |             (comp/emit-global-export ns-name global-exports dep)))))
-------------------^------------------------------------------------------------
null
Wrong number of args (3) passed to cljs.compiler/emit-global-export
{:warning :fn-arity, :line 660, :column 13, :msg "Wrong number of args (3) passed to cljs.compiler/emit-global-export", :shadow.build.compiler/warning-as-error true}
ExceptionInfo: Wrong number of args (3) passed to cljs.compiler/emit-global-export

thanks, are you doing something with bootstrapped?

https://clojure.atlassian.net/browse/CLJS-3465

ok, cljs.js is the bootstrap namespace, something is pulling that in

Yup, being imported for no reason that I can see. Working fine now. Thank you so much ❤️

great!

I'm don't believe so, but I'm not sure. It's running through shadow-cljs on top, I can have a dig through tomorrow if needed

I wrote a series of blog posts about my own workflow. nowadays I do not use tailwind anymore, but there is an example of how you could. see https://code.thheller.com/blog/shadow-cljs/2024/10/18/fullstack-cljs-workflow-with-shadow-cljs.html and https://code.thheller.com/blog/shadow-cljs/2024/10/30/supercharging-the-repl-workflow.html

the second has the tailwind example

I'm actually using the first one as the setup for my current project, and thanks for the second one, ill have a read

I also have a reference repo using everything described in those posts https://github.com/thheller/shadow-stack-mvp

I see a lot of code bases have resources/public instead of just public, do you have any thoughts on that or is it just preference

resources/public is generally used by people that want to build uberjars and then its easier to just put everything in the resources folder in said uberjar. I do not build uberjars and never have my .js files in any jars either, so public works just fine with no need for that extra level. but its more or less personal preference

resources is also often part of the classpath, which I don't like since it often leads to cases where "development" files end up in jars (of libraries specifically) that shouldn't have them. so public to me is cleaner 🤷

Got it, thanks!

On your site, the tailwind example has a script where the css is inside the src directory, does that seem fine to you? I've already got both cljs and clj files in the src so maybe its fine

Think I'll put it in src/main/.../frontend

yeah I generally "categorize" so src/css src/dev src/main and so on. doesn't really matter that much

I also mix, see for example the shadow-cljs UI https://github.com/thheller/shadow-cljs/tree/master/src/main/shadow/cljs/ui main.css just sitting there. not tailwind but still. in the end this is pretty much personal preference.

re: performance the cost of Reflect is suprisingly low - historically even touching arguments was a 100% slow down

is arguments still disadvised or now also ok-ish?

I'm pretty sure you still get punished for arguments

that's another thing for us to fix up, we can probably make the dispatcher way faster at dev time, so there's not this big perf gap during dev vs. build artifact

is arguments not used in build artifacts, due to a GC optimization or so?

direct fn dispatch

our own optimization

how does that relate to dev vs build?

https://clojurescript.org/reference/compiler-options#static-fns

set for advanced builds

but can enable for REPLs etc. for performance testing

got it

so it will do ((.-cljs$lang$arity1 f) 1) instead of (f 1) for multi-arity for example right?

not enabled normally because problematic for redef

there's a bunch of complicated logic, see :invoke case in compiler.cljc

👍

I guess instead of arguments CLJS could indeed now do ...xs + xs.length

for dev

yes

still need to run some benchmarks though. not sure the extra Reflect.apply indirection is worth the trouble

cljs.user=> (simple-benchmark [xs (repeat 20 "a")] (mapv String/.toUpperCase xs) 10000000)
[xs (repeat 20 "a")], (mapv String/.toUpperCase xs), 10000000 runs, 5200 msecs
nil
cljs.user=> (simple-benchmark [xs (repeat 20 "a")] (mapv #(.toUpperCase %) xs) 10000000)
[xs (repeat 20 "a")], (mapv (fn* [p1__16514#] (.toUpperCase p1__16514#)) xs), 10000000 runs, 4359 msecs

what if CLJS had just generated the second example from the first, would that be incorrect sometimes (except for /new support)

#(.toUpperCase ^String %)

well you don't know the number of arguments beforehand, which is a problem I guess

in fact, I have a similar expansion in SCI for this (for Clojure) to just produce a varargs function

how does adding a second arg affect this? I mean the whole args/apply dance has to cost something

second arg with a different example you mean? (since toUpperCase doesn't take a second argument AFAIK)

well yeah not specifically toUpperCase. just something that takes more than one arg

doesn't really matter. the above already confirms that is has a cost, which makes me not want to use it

#(.toUpperCase %) vs String/.toUpperCase 🤷

true

I understand the need on the JVM side. JS not so much.

same actually ;)

I had trouble understanding what the advantage of this is. When would you use it instead of just .toString from that example?

When you know the type (not sure if that matters at all in CLJS) and don't want extra lambdas. Which is especially pertinent when you already have one #(...) on the outside since you can't nest #(...).

(fn [x] (.toUpperCase x))

By itself - yeah, sure. But if nested multiple times, that might be a harder sell for some. I'm myself still not sure what I prefer. :)

Just .toUpperCase probably would've worked well, if clj compatibility wasn't a concern

A half-joke proposition - adding #.someMethod to both Clojure and ClojureScript that would reflect in the former is a matching method cannot be found during compilation.

this doesn’t require (:refer-global :only [String])?

apparently not, just (def String js/String) worked for me

oh my:

cljs.user=> (let [s js/String]
              (map s/.toUpperCase "asdf"))
("A" "S" "D" "F")

as long as it has a prototype, it works

thanks for collecting these notes, I had looking into js-dossier on my list of todos

🙇 ok, happy to keep all apprised of my progress to avoid duplicating effort.