I’m looking the issue CLJS-1519 and I changed all the arity error messages to understand where is the exception is raised, but the message doesn’t change. I’m running the repl using the wiki example and running from script/noderepl. Maybe I’m looking on the wrong place and this exception are raised from google closure.

@ndrluis I believe the exception is raised there: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/compiler.cljc#L824 Did you rebuild the compiler as described at https://github.com/clojure/clojurescript/wiki/Building-the-compiler before testing the modifications?

@lauri yes

@ndrluis the fix is simple but it exists in an unusual place

you need to look at the cljs.core macros file around deftype etc. where we produce IFn implementations

deftype’s which implement IFn get call methods, the call implementation handles the dispatch to arity + the error report

I suspect the mistake is that deftype methods take 1 additional argument - the instance

there’s nothing wrong with any of this

just the reported argument count

thx @lauri and @dnolen, I will try to look where @dnolen said

@ndrluis to elaborate a bit more we allow more things than just JS functions to be invokeable

JS functions are all invokeable via call

so ClojureScript types that are also invokeable implement it as well

A question about boostraped-cljs: what is the trick that makes macros from cljs.core available?

when executing eval-str?

@viebel sorry can you clarify?

@anmonteiro for example: why can I call the when macro inside an expression?

where is the code of the when macro stored?

usually, macros are not available at run-time

@viebel probably this: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L25

OK

In my case (js/goog.require "cljs.core$macros”) does nothing

cljs.core$macros is already loaded

I have not set :dump-core false. Is it related

?

@viebel what’s your problem specifically?

:dump-core doesn’t have anything to do with macros AFAIK

I’m trying to optimize the load clojure.spec inside KLIPSE

Currently, I load everything from github

It’s a waste since KLIPSE uses clojure.spec

So everything is already there...

except macros

are you getting undeclared var warnings?

is that the problem?

No

The problem is that I can’t find what is the right thing to do

or rather, what macros aren’t there? clojure.spec’s?

what should do my load-fn

I tried to make it calls the callback with {:source “”}

but then :refer fails

so now, I’m returning the analysis cache

but I’m having issues with macros

https://clojurians.slack.com/archives/cljs-dev/p1476371386003806

the macros namespaces don’t really get “bundled” when you build ClojureScript on the JVM

so if that’s the problem you’re having, you need to load those files because they won’t be in your bundle

I know

This is exactly what I’m trying to do

I asked about cljs.core macros - because it seems that they are bundled during the build

right?

So I wanted to do the same trick with clojure.spec

makes sense?

right, I’m not sure I can help you then

the core macros namespace might even be treated in a special manner by the analyzer

I also tried to load the macro source files but then I am getting an infinite loop

I’m not sure

not sure why

because every other namespace depends on it

maybe your patch could help?

what files are you getting an infinite loop with?

checking...

There was an infinite loop with cljs.core$macros

So I made my load-fn return “” for cljs.core and cljs.core$macros

@viebel right there are some namespaces that you can skip loading

macros namespaces also?

yeah

except cljs.core$macos?

the list may vary, but here’s a sample: https://github.com/clojure/clojurescript/blob/master/src/test/self/self_parity/test.cljs#L166

oh nice

Trying it

who built this list?

Mike Fikes, I think

@viebel there’s some more stuff here: https://github.com/clojure/clojurescript/blob/master/src/test/self/self_parity/test.cljs#L166 and here: https://github.com/mfikes/planck/blob/master/planck-cljs/src/planck/repl.cljs#L855

but some of those are Planck-specific

@viebel I don’t know how you’re compiling KLIPSE, but your list might be even longer if you’re compiling with simple optimizations

I’m doing :optimizations :simple

as :advanced is not supported with bootstraped

so you might have a lot of stuff already “loaded” in your build

that you can simply skip loading

that should shave off a lot of time in some require calls

ok

I’m trying now

@anmonteiro it starts to work

I can require clojure.spec

But..

I’m having issues when calling s/def

WARNING: Use of undeclared Var cljs.spec$macros/def-impl at line 4

somehow def-imp is resolved to the macro ns instead of the non-macro one

any idea?

@viebel which version of ClojureScript?

(compiler)

or rather, are you using a given ClojureScript version in KLIPSE and fetching namespaces from GitHub master?

not fetching from github

using latest release: 1.9.229

1.9.229 in both the KLIPSE build and the clojure.spec namespace?

let me double check

I was with 1.9.277 for clojure.spec

moved to 1.9.229 and now it works

Thanks a lot for your help

I hope that soon my articles about clojure.spec will load much faster

Many thx

@viebel yeah, that’s what I suspected

in case you’re wondering why it didn’t work: https://github.com/clojure/clojurescript/commit/7e90ad51452ec5edd8ee7f2b7af9c7e7fb759c97

I see

just wondering if there is some other state outside cljs.env to be addressed to get reproducible builds, I have some tests checking cljs compiler output in different compilation modes: https://github.com/binaryage/cljs-oops/tree/master/test/transcripts/expected it works pretty well, the problem is when I decide to change order of the tests or filter some out, I get slightly different results, the generated code is still correct, but js-beautify will format/insert linebreaks to some other places for some reason I just ran directory diff for two builds which happen to be different, and it looks that gensym and similar do not reset when calling new compiler/build, this is probably causing flakiness of my tests, because build depends on state of the system left from previous builds

ah, nevermind, found the problem, because gensym and similar are not reset for each new build, we may end up with generated identifiers of different length, e.g. my-sym10 vs. my-sym12345, and this affects linebreaks of cljs output, solution for me was to remove all linebreaks to normalize the output before processing it further

that alone is not enough to get stable output, I also have to “reindex” all auto-gen and gensym’d symbols with stable indexing, but that I had to do anyways

Would it be ok for me to work on http://dev.clojure.org/jira/browse/CLJS-1820? Shouldn’t interfere with deraen’s work 😉