Fork me on GitHub
#cljs-dev
<
2016-06-01
>
darwin17:06:37

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

thheller17:06:56

@darwin I have some really ugly ns parsing code

thheller17:06:25

should be portable to cljs without much trouble

darwin17:06:22

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

darwin17:06:29

more future-proof solution, I think

darwin17:06:57

now that we have working bootstrap

thheller17:06:52

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

thheller17:06:03

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

darwin17:06:23

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

thheller17:06:44

yeah totally agree

thheller17:06:36

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

thheller17:06:42

should make for way better errors

darwin17:06:57

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

darwin17:06:13

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

darwin17:06:36

for some reason, it felt over-complicated to me

thheller17:06:39

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

mfikes17:06:42

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

thheller17:06:55

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

mfikes17:06:02

(defn desugar [[_ ns & specs]] 
  `(ns ~ns 
    ~@(ana/desugar-ns-specs specs)))
would put things into a “canonical” form

darwin17:06:32

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)

darwin17:06:25

assuming validators are side-effect free

darwin17:06:26

ah, it is plumatic, not prismatic 🙂

thheller17:06:38

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

thheller17:06:52

has anyone seen this when running script/test?

thheller17:06:58

no idea what is going on

mfikes17:06:10

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

thheller18:06:20

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

dnolen18:06:08

ClojureScript 1.9.14 released

dnolen18:06:27

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

thheller18:06:32

@dnolen: nice work on 1.9.14, spec is fun

bhauman18:06:10

dammmmmmnnnn! sweet!!

mfikes18:06:12

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

anmonteiro18:06:24

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

dnolen18:06:53

you can require Clojure 1.9

dnolen18:06:01

and in fact will get more functionality like macro checking

anmonteiro18:06:35

I meant 1.9, editing

dnolen18:06:41

no it doesn’t require 1.9

dnolen18:06:59

@jr need more information

jr18:06:28

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

dnolen18:06:27

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

dnolen18:06:31

only affects bootstrap

mfikes18:06:06

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

mfikes18:06:43

It is probably innocuous.

dnolen18:06:36

just a bad reader conditional

thheller18:06:25

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

dnolen18:06:51

you probably shouldn’t be using implements? anyway

dnolen18:06:01

I only added that for internal performance stuff

dnolen18:06:38

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

thheller18:06:23

ah didn't check that

thheller18:06:35

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

thheller18:06:13

testing anything on js/window is probably a bad idea

thheller18:06:36

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

thheller18:06:50

only run into this every couple of months

thheller18:06:44

can add the change to satisfies? if you want

thheller18:06:05

AFAICT it is affected in the same way as implements?

dnolen18:06:17

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

dnolen18:06:52

satisifes? and implements? are old highly tuned things

dnolen18:06:05

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

thheller18:06:43

makes sense, I'll run some benchmarks

thheller18:06:28

not looking good. 😞

thheller18:06:44

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

thheller18:06:47

with change

thheller18:06:57

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

thheller18:06:14

so I guess thats out 😞

dnolen18:06:28

what about the others?

dnolen18:06:41

we usually make decision balanced across at least SpiderMonkey and JavaScriptCore

thheller18:06:47

need to figure out how to install them first

dnolen18:06:05

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

thheller19:06:18

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

thheller19:06:41

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

dnolen19:06:37

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

dnolen19:06:39

sentinel value

dnolen19:06:55

and the timings for that

thheller19:06:43

I may try that tomorrow

dnolen20:06:52

cool, thanks much for the existing report, very useful