is there any library to parse ns forms and give me back information about aliases? AFAIK clojure.tools.namespace.parse does not give me that info. I want to support aliases in Dirac and don’t want to reinvent the wheel https://github.com/binaryage/dirac/issues/21

@darwin I have some really ugly ns parsing code

https://github.com/thheller/shadow-build/blob/master/src/clj/shadow/cljs/util.clj#L183

should be portable to cljs without much trouble

thanks a lot, will consider it, but if I had to port it, I would consider simply feeding the source into cljs.analyzer and trying to get its info back

more future-proof solution, I think

now that we have working bootstrap

yes there is cljs.analyzer/parse-ns which is probably the best way to go

just doesn't do all I wanted so I wrote my own 😉

that is cool, but my concern here is maintenance cost, don’t want to replicate what cljs compiler already does and potentially diverge

yeah totally agree

I will eventually play with clojure.spec to see if I can make it work to parse the ns form

should make for way better errors

will look into cljs.analyzer/parse-ns, thanks, I’m not much familiar with analyzer apis

great!

clojure.spec looks great, I like the idea, but was never a fan of prismatic.schema

for some reason, it felt over-complicated to me

be careful when using it though, it requires some setup and has side effects

@darwin: If nothing else, you can perhaps make things easier by first calling desugar-ns-specs to make the result easier to parse.

probably safer if you go through cljs.analyzer.api/parse-ns

(defn desugar [[_ ns & specs]] 
  `(ns ~ns 
    ~@(ana/desugar-ns-specs specs)))

btw. my usage of prismatic schema validations turned to be quite slow during development, I did one trick which made it usable, I used js/WeakMap to cache all validator results, this helped a lot, I think this could be applied to clojure.spec as well (whenever WeakMap is avail)

https://github.com/darwin/plastic/blob/master/src/common/plastic/validator.cljs

assuming validators are side-effect free

https://github.com/plumatic/schema/issues/256

ah, it is plumatic, not prismatic 🙂

Exception in thread "main" java.lang.ClassCastException: sun.nio.cs.UTF_8 cannot be cast to java.lang.String, compiling:(/Users/zilence/code/oss/clojurescript/bin/../bin/cljsc.clj:22:1)
	at clojure.lang.Compiler.load(Compiler.java:7239)
	at clojure.lang.Compiler.loadFile(Compiler.java:7165)
	at clojure.main$load_script.invoke(main.clj:275)
	at clojure.main$script_opt.invoke(main.clj:337)
	at clojure.main$main.doInvoke(main.clj:421)
	at clojure.lang.RestFn.invoke(RestFn.java:436)
	at clojure.lang.Var.invoke(Var.java:388)
	at clojure.lang.AFn.applyToHelper(AFn.java:160)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)
Caused by: java.lang.ClassCastException: sun.nio.cs.UTF_8 cannot be cast to java.lang.String
	at cljs.closure$set_options.invoke(closure.clj:247)
	at cljs.closure$make_options.invoke(closure.clj:288)
	at cljs.closure$optimize.doInvoke(closure.clj:1236)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at clojure.core$apply.invoke(core.clj:632)
	at cljs.closure$build.invoke(closure.clj:1975)
	at cljs.closure$build.invoke(closure.clj:1886)
	at user$eval5502.invoke(cljsc.clj:23)
	at clojure.lang.Compiler.eval(Compiler.java:6782)
	at clojure.lang.Compiler.load(Compiler.java:7227)
	... 9 more

has anyone seen this when running script/test?

no idea what is going on

@thheller: Master doesn’t do that for me on OS X. I’ve never seen that before.

@mfikes thanks for testing ... did a fresh checkout and it works

ClojureScript 1.9.14 released

@mfikes happy to take subsequent patches that make macro checking work in bootstrapped

@dnolen: nice work on 1.9.14, spec is fun

dammmmmmnnnn! sweet!!

@dnolen: Thanks! Actually, since TCHECK-105 hasn’t yet been folded in, bootstrap works fine with the parts of Spec that people can use. CLJS-1656 only really becomes applicable when test.check itself supports bootstrap (Gary Fredericks estimated he’ll get to that within a week or so).

does CLJS 1.9 strictly require Clojure 1.8 or is that not the case? edit: I meant clojure 1.9

you can require Clojure 1.9

and in fact will get more functionality like macro checking

I meant 1.9, editing

no it doesn’t require 1.9

cool

I’m getting a compilation warning for this line in the analyzer https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L2366

@jr need more information

probably boot or some tool requiring the analyzer in cljs. That causes mchk to bind to _ after the reader conditional is applied. I’ll dig further and provide more information

@jr ah yeah that a good catch, yes will fix that now

only affects bootstrap

Yeah, I get it too. All of Planck’s unit tests are passing with it, whatever it is.

It is probably innocuous.

just a bad reader conditional

if someone has time to review http://dev.clojure.org/jira/browse/CLJS-1658

I've been bitten by this for the third time now, each time spending an hour trying to figure out what is going on 😛

you probably shouldn’t be using implements? anyway

I only added that for internal performance stuff

but the issue would be true for satisfies? as well, it’s not specific to implements?

ah didn't check that

in my case I'm using implements? exactly for performance reasons though

testing anything on js/window is probably a bad idea

still when you run into the issue the error is very very weird

only run into this every couple of months

can add the change to satisfies? if you want

AFAICT it is affected in the same way as implements?

yes, the main thing I want to see on that ticket would be an eyeball of the benchmarks across the 3 major engines

satisifes? and implements? are old highly tuned things

I don’t forsee any problems - but this is JavaScript after all

makes sense, I'll run some benchmarks

not looking good. 😞

;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 9 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 23 msecs

with change

;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 8 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 16 msecs

without

so I guess thats out 😞

v8 that is

what about the others?

we usually make decision balanced across at least SpiderMonkey and JavaScriptCore

need to figure out how to install them first

@thheller: feel free to update the patch and I can also take a look later too

will do

ok, ran benchmarks on jsc, spidermonkey, v8. all seem to be slightly slower.

http://dev.clojure.org/jira/browse/CLJS-1658 results in comments

wouldn't have expected it to have an impact at all

it is pretty small though - I will think about it - another thing to try in a separate patch

sentinel value

and the timings for that

I may try that tomorrow

cool, thanks much for the existing report, very useful