Fork me on GitHub

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: Did you rebuild the compiler as described at before testing the modifications?


@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

Yehonathan Sharvit14:10:02

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

Yehonathan Sharvit14:10:13

when executing eval-str?


@viebel sorry can you clarify?

Yehonathan Sharvit14:10:32

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

Yehonathan Sharvit14:10:43

where is the code of the when macro stored?

Yehonathan Sharvit14:10:20

usually, macros are not available at run-time

Yehonathan Sharvit15:10:04

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

Yehonathan Sharvit15:10:22

cljs.core$macros is already loaded

Yehonathan Sharvit15:10:43

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

Yehonathan Sharvit15:10:31

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

Yehonathan Sharvit15:10:44

Currently, I load everything from github

Yehonathan Sharvit15:10:57

It’s a waste since KLIPSE uses clojure.spec

Yehonathan Sharvit15:10:04

So everything is already there...


are you getting undeclared var warnings?


is that the problem?

Yehonathan Sharvit15:10:44

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?

Yehonathan Sharvit15:10:51

what should do my load-fn

Yehonathan Sharvit15:10:17

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

Yehonathan Sharvit15:10:28

but then :refer fails

Yehonathan Sharvit15:10:41

so now, I’m returning the analysis cache

Yehonathan Sharvit15:10:49

but I’m having issues with macros


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

Yehonathan Sharvit15:10:39

This is exactly what I’m trying to do

Yehonathan Sharvit15:10:12

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

Yehonathan Sharvit15:10:26

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


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

Yehonathan Sharvit15:10:04

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


I’m not sure


because every other namespace depends on it

Yehonathan Sharvit15:10:31

maybe your patch could help?


what files are you getting an infinite loop with?

Yehonathan Sharvit15:10:31

There was an infinite loop with cljs.core$macros

Yehonathan Sharvit15:10:59

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

Yehonathan Sharvit15:10:53

macros namespaces also?

Yehonathan Sharvit15:10:00

except cljs.core$macos?

Yehonathan Sharvit15:10:25

who built this list?


Mike Fikes, I think


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

Yehonathan Sharvit15:10:28

I’m doing :optimizations :simple

Yehonathan Sharvit15:10:37

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

Yehonathan Sharvit16:10:14

I can require clojure.spec

Yehonathan Sharvit16:10:26

I’m having issues when calling s/def

Yehonathan Sharvit16:10:03

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

Yehonathan Sharvit16:10:35

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


@viebel which version of ClojureScript?


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

Yehonathan Sharvit16:10:55

not fetching from github

Yehonathan Sharvit16:10:16

using latest release: 1.9.229


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

Yehonathan Sharvit16:10:04

let me double check

Yehonathan Sharvit16:10:12

I was with 1.9.277 for clojure.spec

Yehonathan Sharvit16:10:24

moved to 1.9.229 and now it works

Yehonathan Sharvit16:10:31

Thanks a lot for your help

Yehonathan Sharvit16:10:51

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


@viebel yeah, that’s what I suspected


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: 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 Shouldn’t interfere with deraen’s work 😉