This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (355)
- # boot (4)
- # cider (44)
- # cljs-dev (73)
- # cljsrn (15)
- # clojars (5)
- # clojure (54)
- # clojure-brasil (2)
- # clojure-italy (1)
- # clojure-russia (4)
- # clojure-spec (9)
- # clojured (3)
- # clojurescript (15)
- # cursive (19)
- # datomic (5)
- # duct (3)
- # emacs (4)
- # events (1)
- # fulcro (5)
- # immutant (12)
- # keechma (3)
- # lein-figwheel (4)
- # lumo (2)
- # off-topic (1)
- # parinfer (11)
- # planck (4)
- # re-frame (3)
- # reagent (3)
- # reitit (1)
- # shadow-cljs (5)
- # spacemacs (7)
- # unrepl (4)
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?
@rauh ah i thought there was a special type hint for things like
next which can return a
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.
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
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
@bhauman useful and easy to do, but I’d rather we start educating the popular libs to be cache friendly first
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
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)
@jannis applied, book keeping thing - you haven’t submitted a Clojure CA, please do that when you have time, thanks!
@jannis https://clojure.org/community/contributing, sometimes it takes a bit for your name to appear
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.
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
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.
@dnolen The only hunch I have is the "base"
f is still there but all of the direct dispatch variants have been replaced. But
OK, no wonder I can't understand it. :slightly_smiling_face: It is a corner case of a lang I still don't know all that well :disappointed: Arg.
Cool. Maybe the first post involving
hrm can’t seem find a way to fix 2641, but I’m pretty sure that’s the problem, gotta run for now
Why not just return a
(fn  (... (copy-arguments ...)) ...) instead of trying to recreate the fn with
MetaFn (which was never designed to handle variadic fns and might brake in the future if MetaFn changes design...
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.