@dnolen: just noting, that I swapped the args and updated the ticket

@mfikes: just wanted to let you know that it looks like you are assuming a 0 based column parameter in your error pointers

it's not 0 based

@bhauman: Yes, I know… I fudged it to make the pointer point at the symbol. Skating on thin ice.

oh gotcha 🙂

I'm working on warnings now.

you can get a lot farther with them

A lot more info is available

@mfikes: I was just pointing it out because I was afraid that I was doing it wrong! 🙂

Yep. I feel like I’ve committed a sin by adding one. 🙂

yeah it's tough to work around

@mfikes: I’ve added a patch to http://dev.clojure.org/jira/browse/CLJS-1593 but I’m having trouble testing it, in terms of making sure I run a nashornrepl on my code.

@slipset: Let me give it a spin…

My hypothesis is that the munged symbols are exported somehow

since (_PLUS_ 4 5) gives 9

at least in Planck

@slipset: That patch doesn’t seem to fix CLJS-1593 for me. (The repro is still reproable.)

(I tried it in script/noderepljs and script/nashornrepljs.)

ok, but for future reference, if I change something in core.cljs, how do I run a bootstrap repl on my newly changed code?

as in which scripts in scripts do I need to run to get a fresh build?

@slipset: There is no bootstrap REPL that is part of the core ClojureScript tree. But, after making changes, generally they affect script/noderepljs and you can see them.

@slipset: There is script/test-self-parity which will run the test suite in a bootstrapped environment (in Node.js)

but, I’m a bit slow, so just by starting eg script/noderepljs it will use my freshly edited core.cljs?

or do I need to do some incantations to make that happen?

@slipset: Yes. That’s been my experience. Makes it real easy to change something in the ClojureScript codebase and check its effect.

Thanks.

so, if you’ll pardon my ignorance, (_ 7 3) does not work in script/noderepljs, but that’s because noderepljs is not a bootstrapped repl?

@slipset: All I know about it is the what. I have no clue as to the why. But, right CLJS-1593 is a self-host issue (limited to that case).

yes, since you can see in noderepljs

cljs.user=> (cljs.js/eval-str (cljs.js/empty-state) "(_PLUS_ 7 3)" nil {:eval cljs.js/js-eval :context :expr} identity)
{:ns cljs.user, :value 10}

Darn there is no way for me to insert a warning handler in the piggieback REPL (piggieback calls cljs/repl for you, so you can re-bind cljs.analyzer/*cljs-warning-handlers*). Makes me think we should also have a :warning-handlers option on the cljs repl, another option. Maybe the ReplEnv can optionally implement another Protocol that perhaps has (-caught [_e]) and (-warn [warning-type env extra])

Or I can just modify piggieback.

@bhauman: But, if you pull it off, you are finding that your own warning handler is called with a treasure trove of diagnostic info?

@mfikes: yeah with the warning handler has a warning type key and often provides extra source info

so in some cases you can precisely underline the offending code

and also explain in more detail what the hell is going on.

To put things in perspective, when Piggieback and nREPL rose to prominence, ClojureScript didn’t even have *e nor (pst). Things were harsh back then. (I’m arguing that, since we are now onto a whole new slew of issues, in terms of refining the experience, Piggieback should continue to evolve.)

When *e was being added, we were adding fundamentals like mapped stack traces, having a def return a var, other things that make things feel civilized.

Absolutely, but we can now customize exception behavior with an option but we cannot customize, warning behavior with an option. Not a big deal at all, but ...., it still feels like its evolving.

as well

And piggieback should move on as well.

And the pattern for piggieback, and figwheel is that it starts the REPL for you, and the options are what allow you to customize the behavior.

I suppose, with a lot of those previous “usability” / “dev experience” enhancements, it took changing things all through the tooling stack, even changing stuff down in the compiler. Perhaps there is nothing wrong with refinements like those continuing. (It is hard for tools at the edge of the stack to do it by themselves.)

and out of band behavior modifications that use bindings are difficult to forward through a call chain, and launch on a different thread.

right now, it feels like a :warning-handlers option kinda makes sense, and will be helpful for tooling

There’s a pattern employed here where the bound value for a dynamic var can be overridden via an explicitly passed option: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L826-L827

We could take some lessons from js.cljs and refactor repl.cljc a bit and provide a lower level api for repl building.

cljs.spec implemented in ClojureScript master

@dnolen: also planning on porting the tests? correct if I’m wrong, but I can’t seem to find them

yeah we need the tests as well as the REPL support

gotcha. anyways, awesome work, thanks for porting this goodness so hastily!

fortunately ClojureScript is so close to Clojure now it was a mostly boring affair

especially having simple support for reified vars already thanks to cljs.test

just added the REPL support

I’d second the sentiment for self-hosted ClojureScript. At least with what I’ve seen so far… it is just working. 🙂

@mfikes: nice, I changed the .clj extensions to .cljc

but yeah I didn’t see anything that would make it not work in bootstrap

Thanks for that. That’s a good bit of … insurance.

The only thing I’m currently aware of is that alias. But will dig into it further.