Fork me on GitHub
#cljs-dev
<
2016-06-09
>
dnolen04:06:00

@darwin right this was what I was warning you about - not a simple change

darwin10:06:27

yep, you were right, at least it was a good exercise and I’ve learned a bit more while digging through it 🙂

darwin17:06:20

it would be really handy if I could properly detect functions coming from cljs land, right now I have a heuristics which looks at name, but I cannot tell anything about single-arity anonymous functions, would be nice to have all cljs functions tagged with something like cljs$lang$type

darwin17:06:31

cannot distinguish those lambda fns from cljs lambdas in user code

darwin17:06:38

or what about generating some specific name to all anonymous functions created by cljs?

darwin17:06:45

devtools displays (anonymous function) in call stack traces, it might be more helpful to generate some more descriptive name based on lexical context of those anon-fns

darwin17:06:55

and I would be able to detect them this way here

dnolen17:06:04

there’s just no way to do that

rohit18:06:48

@dnolen: as discussed yesterday, i’ve started work performing benchmarks (found in cljs repo) and plotting them over releases. Initial work here: https://ducky427.github.io/clojurescript-benchmarks

rohit18:06:57

I’ve only ported over some benchmarks right now.

rohit18:06:22

Comments welcome!

rohit18:06:18

I am using benchmark.js to run the actual benchmarks on JSC/SpiderMonkey/v8 engines.

dnolen18:06:28

@rohit that’s pretty cool

dnolen18:06:25

will talk to some people tomorrow about how feasible it would be to have that be a part of our build process

rohit18:06:15

as we are running those benchmarks on jsc as well, i guess they would need to be run on a mac

rohit18:06:41

also, i’ve kept the display format same as Andy Fingerhut’s results for clojure

dnolen18:06:51

JavaScriptCore can be compiled for Linux I believe

rohit18:06:13

@dnolen: oh cool. just found @mfikes' notes for doing that.

mfikes18:06:56

@rohit, and also the JavaScriptCore build for Linux is “apropos” in the sense that the ClojureScript unit test suite passes on it.

jr21:06:45

@dnolen: confirmed that the issue of serializing clojure.lang.Var still exists on master. Adding a handler for clojure.lang.Var does seem to resolve the issue but I’m not sure if my code is correct

jr21:06:36

ie not sure if the analysis cache is using the vars correctly

dnolen21:06:45

@jr I don’t want to consider just wiring that in until I get more information about where this shows up in the analysis cache and how

dnolen21:06:01

what key does it appear under etc

dnolen21:06:22

that is can we just elide this stuff instead of bothering

jr21:06:32

agreed - now that I’m set up with clojurescript master I can get that information for you

dnolen21:06:54

cool thanks

jr21:06:34

explain {:name explain, :arglists ([this]), :doc “omitted", :protocol #'schema.core/Schema, :meta {:name explain, :arglists ([this]), :doc “omitted", :protocol #'schema.core/Schema, :file nil}

jr21:06:54

The :protocol value is a Var reference

jr21:06:23

This is the print representation of analysis before writing

danielcompton22:06:04

Nice @rohit, I was thinking about doing the same for code size

jr23:06:41

After reviewing the analyzer source code it seems that the :protocol value in the analysis cache is expected to be a var. I put together a patch that deserializes the var in transit and works AFAICT https://gist.github.com/JacobNinja/dd488daced80960c7ed5c547f4a39854

jr23:06:39

Would like to omit :protocol if possible instead of adding handlers

danielcompton23:06:12

Is it acceptable to use a mies project to report a bug?