not really, you can deep def or you can use the test electric entrypoint in an RCF test

the problem is that electric anything can only be resolved from an electric program (not valid in clojure as clojure is not aware of electric) so to use the REPL you have to bring your own electric entrypoint (see our unit tests)

I suspect it's because of incorrect require, or something along those lines? I have faced it being really confused why the symbol isn't being resolved, only to realized that there is some error regarding compilation somewhere else.

post an example stacktrace please

a common gotcha (that i’ve been meaning to improve) is when a stale browser tab reconnects to a fresh server, especially a stale tab from an entirely different electric app, which will (because the DAG is initialized by the client) start resolving stuff on the server classpath that isn’t there

This is totally not helpful, but I posted this after I resolved the problem a couple hours ago. I don't think I can reproduce it. Sorry about that. I will return to this if I face something like it again.

i also don’t yet trust shadow-cljs setups that are not explicitly booted by the app/repl via the clojure shadow API, see the documented shadow setup in the starter app user.clj

Hm, so the one via cider is not trustworthy?

in theory the editor plugins can work but i’ve seem unstable compilation happen with them in ways i don’t understand, what i know for certain is that when i explicitly control compilation i have zero issues

im working on understanding calva better , hope to have a validated calva setup soon that is more tightly integrated than “run shadow from user.clj” but i haven’t had time yet to go deep

yeah I have seen things happen where I'd restart emacs and compilation errors would go away.

@U09K620SG Came across this much more quickly than I would have liked...

Oh, maybe I am looking at the wrong stacktrace! A trace above it was the answer.

Is there any way to make these traces more sane? They are quite long.

maybe you can prettify and collapse the non-interesting parts with https://github.com/clj-commons/pretty

yes , we do need to review the common sources of compiler and runtime errors to elide stack frames that aren’t from userland. this is actually really easy - “good first issue” easy if you are interested in taking a whack?

many of the common errors can be reduced to 1 line probably

the other thing that might help is to develop or find a mechanism for using spec to validate syntax at certain places (before macroexpansion adds distance between what the user typed and the actual code that crashed), this would be a later pass after the first

> “good first issue” easy if you are interested in taking a whack Where roughly would one start looking?

Next time you see a stack trace with electric compiler or electric runtime internals, first observe that internals traces have no value to the end user who only cares about userland. so a starting point is to sever the useless info. If you look at how clojure.core's ex-info is implemented, they have code to sever the top few frames, which is basically what you want here

Really the hard part (from my perspective) is running like that for a while to be confident that this is the right thing to do, and to start mapping out all the places where this might be desirable, there are only a few places in electric where user land code is evaluated and they all should be pretty obvious and already have a try/catch around them

u guys are legends