Clojurians
#cljs-dev
<
2018-03-10
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

mfikes02:03:03

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?

tmulvaney09:03:37

@mfikes kinda like ^seq-or-nil?

rauh09:03:57

@tmulvaney seq means basically seq-or-nil

tmulvaney09:03:07

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

tmulvaney09:03:28

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.

bhauman10:03:35

re: aot-caching

bhauman10:03:22

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

bhauman10:03:30

@dnolen @mfikes ^

bhauman10:03:27

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

jannis11:03:58

@dnolen Revised patch uploaded without a :browser target.

mfikes11:03:31

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

mfikes12:03:47

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

mfikes12:03:55

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

mfikes13:03:46

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

dnolen14:03:25

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

dnolen14:03:46

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

dnolen14:03:06

@jannis thanks

mfikes14:03:39

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

dnolen14:03:53

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

dnolen15:03:21

in the ticket I mean

dnolen15:03:40

@mfikes oh I see you understand the problem :slightly_smiling_face:

mfikes15:03:42

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)

dnolen15:03:15

no not actually

dnolen15:03:28

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

dnolen15:03:43

so not worried, this is a good thing

dnolen15:03:06

making things easy also makes bugs easier to find :slightly_smiling_face:

mfikes15:03:19

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

mfikes15:03:40

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

dnolen15:03:54

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

jannis15:03:37

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

dnolen15:03:27

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

dnolen15:03:35

thanks again!

dnolen16:03:28

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

dnolen16:03:33

only lein test

dnolen17:03:30

@jannis nvm, env issues over here

mfikes17:03:44

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.

dnolen17:03:19

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

dnolen17:03:35

I don’t see how that explains overflow

dnolen17:03:00

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

dnolen17:03:43

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

dnolen17:03:01

(thus not breaking callers who expect certain arities)

dnolen17:03:23

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

mfikes18:03:35

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

dnolen18:03:20

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

dnolen18:03:13

@mfikes hoo boy :slightly_smiling_face:

mfikes18:03:16

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

dnolen18:03:26

JS dynamic binding

mfikes18:03:02

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.

dnolen18:03:52

a lot of time for such a simple change

mfikes18:03:08

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

dnolen18:03:39

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

dnolen18:03:48

but not worth it go mucking around there at the moment

mfikes18:03:59

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

mfikes18:03:30

Glad it can be resolved

dnolen18:03:01

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

mfikes18:03:57

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

dnolen18:03:40

not using main but cool anyway

dnolen19:03:10

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

dnolen19:03:29

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

rauh19:03:48

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

dnolen19:03:02

I think you don’t understand why we need MetaFn

dnolen19:03:14

Advanced compilation

miikka22:03:25

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.

miikka22:03:27

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