I'm very happy that we’ve reached this point. With @dnolen's latest stuff landing in master we now have “portable” macros in bootstrapped ClojureScript!!! WOOT! See this for details https://twitter.com/mfikes/status/624384557748502529

@mfikes: :)

@timothypratley: Your nested issue with Google Closure reminds me a lot of this one with JavaScriptCore. Similar O(2^n) but probably very different root causes: http://dev.clojure.org/jira/browse/CLJS-910

@mfikes: Thank you for the link. Sounds like the identical root cause to me?? I’ll drop a link to the google closure issue there for reference.

@timothypratley: They are eerily similar. CLJS-910 can be reproduced by itself in JavaScriptCore with plain JavaScript (no ClojureScript or Google Closure).

@mfikes: so have you had a chance to try anything more complicated with the bootstrapped REPL? I had a lot of fun showing it off at Austin Clojure people were pretty excited about it

@dnolen: Not yet. But I think it is in a place where the Planck code itself is roughly close to complete and it feels like a matter of trying more and more complicated use cases.

@mfikes: so relatively clear how it’s supposed to work? etc.? Did you see how the error handling stuff works?

@dnolen: One additional issue I haven’t yet put into JIRA is that I seem to have to create namespaces first. I have to do these first two lines: https://gist.github.com/mfikes/49b46756a9a892471f4e

@dnolen: Error handling is something I haven’t ensured is cool yet either.

@dnolen: I’ll hit Planck again hard tonight and/or this weekend.

@mfikes: ok, no rush was just curious!

@mfikes: that first issue seems weird gotta work on my talk right now but would like to hear more about that later.

If anyone is interested in Planck and its conversion to cljs.js all of its updated code is on the master branch at https://github.com/mfikes/planck

@mfikes: goodness gracious! If I understand you correctly that means there are lots of upstreams to this one hahahaha. Fortunately I have a hack workaround

@timothypratley: Wow. Really? Do you think the same code is in use somehow? (I had assumed they can’t be the same and it is just strangely similar that two codebases seem to have difficulty with nesting.)

ah you are right

they are probably executing different code when they blow up

Cool… it is perhaps a challenging pattern to deal with. Maybe a naive approach is fast for small amounts of nesting but is O(2^n).

yeah I agree.

The JavaScriptCore issue is down in C or C++.

right, closure would be in java

But… it has this common theme that transpiled and generated code often results in nesting that no human would write, and thus stresses thing that consume that generated code.

For the JSC issue, :static-fns is a workaround IIRC. Haven’t looked at it in a while.

hahaha yeah I can just imagine someone reading these bug reports and spending a day muttering to themselves “why would anyone do that???"

@timothypratley: Right. I delicately stepped around why I was writing such code. Especially in this SO, which got lots of attention http://stackoverflow.com/questions/27568249/javascriptcore-nested-call-performance-issue

@mfikes: When I see inc(inc(inc(inc(inc(inc(inc(inc(inc(inc(inc(inc(inc(inc(inc())))))))) I have a pretty good suspicion as so why

@pixel: Hah )

Evidently Nolen be on live pretty soon at TXJS: http://2015.texasjavascript.com/live/

yep, he's being introduced now

I recorded David’s TXJS talk in case anyone missed it. (Trying to determine what the right are for such a thing and whether I can share it.)

@mfikes: I suspect TXJS will get the video up pretty soon so I wouldn’t worry about it too much

@mfikes: glad you liked it!