I’m curious: There is no appropriate type hint that could be placed on not-empty to cause an unchecked if in expressions like (or (not-empty xs) ys), right?

@mfikes kinda like ^seq-or-nil?

@tmulvaney seq means basically seq-or-nil

@rauh ah i thought there was a special type hint for things like next which can return a seq or nil.

Actually the method for next is tagged as clj-or-nil in its defprotocol but i don't know if the compiler uses that flag to uncheck if expressions.

re: aot-caching

a metadata compiler directive on the clojurescript namespace of ^:no-aot that has no affect on cache read, and only prevents the compiler from writing to the cache would work

@dnolen @mfikes ^

@darwin ^

i.e.

(ns ^:no-aot example.cljs.core ...

@dnolen Revised patch uploaded without a :browser target.

@tmulvaney @rauh Right, was thinking about (not-empty "abc") not producing a seq.

I was trying to use :closure-defines and cannot figure out how to get them to work. I’ve successfully used them only in :advanced in a project before, but here is my attempt using :none and a JAR, using no downstream tooling whatsoever: https://gist.github.com/mfikes/f200cce7cf169d07e2cdffe2080910ac

I added a note to ^ showing that advanced works; my problem is with none

Ahh, the problem happens in any non-`nashorn` REPL environment. Writing a JIRA.

^ https://dev.clojure.org/jira/browse/CLJS-2645

@bhauman useful and easy to do, but I’d rather we start educating the popular libs to be cache friendly first

we can add that later once people understand the things that prevent caching

@jannis thanks

I see the root cause for CLJS-2465; working on a patch. (`js/CLOSURE_UNCOMPILED_DEFINES` is not being initialized in REPL environments)

@mfikes we’re going to have be a bit careful moving forward to clarify compiler stuff (i.e. build) from cljs.main

in the ticket I mean

@mfikes oh I see you understand the problem 🙂

carry on

OK, thought you might be worried about over-use of cljs.main to repro issues that might not occur with using the cljs.build.api directly.... (that could occur if you are not careful about how opts are cobbled together)

no not actually

cljs.main is quickly uncovering discrepancies it was hard to see before

so not worried, this is a good thing

making things easy also makes bugs easier to find 🙂

Ahh, if I had said being initialized by all REPL implementations

Anyway.... I'll see what is going on. I got Node to work

@jannis applied, book keeping thing - you haven’t submitted a Clojure CA, please do that when you have time, thanks!

@dnolen Awesome, thanks! I believe I did but I can check later.

@jannis https://clojure.org/community/contributing, sometimes it takes a bit for your name to appear

thanks again!

@jannis hrm did you not run ./script/test?

only lein test

@jannis nvm, env issues over here

Yeah, I'm feeling like a Monday release is no longer viable / wise. Perhaps another half-week at least, or a week, depending on how thing go.

yep

@mfikes re: 2641, thanks for the notes but I don’t understand the explanation

I don’t see how that explains overflow

you seem to be implying the two different cases invoke each other, but I don’t see yet how that is possible

it was implemented this way so that the instrumented thing would get all the arities from MetaFn

(thus not breaking callers who expect certain arities)

that is we only invoke f I don’t see how we can invoke the wrappers in an infinite loop

@dnolen Right. The reason f ends up calling itself is an open question for me as well. All I can say is this is the what, without being able to explain the why. It is truly mysterious to me.

k at least we’re on the same page about that 🙂

digging

@mfikes hoo boy 🙂

@dnolen The only hunch I have is the "base" f is still there but all of the direct dispatch variants have been replaced. But

JS dynamic binding

OK, no wonder I can't understand it. 🙂 It is a corner case of a lang I still don't know all that well 😞 Arg.

yep

fixing

a lot of time for such a simple change

Whew. I was getting lost in bizzaro JS world with that one.

I think there’s a couple places in the compiler where we unsafely use this

but not worth it go mucking around there at the moment

The problem is really with me, not the JavaScript language. I arguably only understand ClojureScript semantics.

Glad it can be resolved

well I couldn’t see it either so not just you 🙂

Cool. Maybe the first post involving cljs.main: https://oli.me.uk/2018-03-09-clojure-and-clojurescript-testing-with-the-clojure-cli/

Oh, sorry, I might be wrong; that project may not use cljs.main

not using main but cool anyway

hrm can’t seem find a way to fix 2641, but I’m pretty sure that’s the problem, gotta run for now

(goog/bind f nil) was strangely not addressing the issue

Why not just return a (fn [] (... (copy-arguments ...)) ...) instead of trying to recreate the fn with extend & MetaFn (which was never designed to handle variadic fns and might brake in the future if MetaFn changes design...

I think you don’t understand why we need MetaFn

Advanced compilation

To me it seems that when instrumenting, the code generated for original f calls something.cljs$core$IFn$_invoke$arity$variadic but that something gets replaced by instrumented function. So you'll get a loop call to f -> MetaFn's invoke -> apply f -> the instrumented invoke$arity$variadic -> apply f -> ... Doesn't really seem like a dynamic binding problem to me.

Uh, sorry, I mixed up dynamic binding and scoping, I guess that's actually a perfect example of dynamic binding problem! 😅