I’m working on an Emacs minor mode to highlight which code runs on the client, which on the server, and which on either. See thread for details.
Just a taster for now, but I plan to get it into a state where I can share it.
Here’s some v3 code:
And the same code in v2:
Site resolution in v3 follows the rules of dynamic scope, i.e. it is inherited from the caller. So this can't be done with simple lexical analysis
I just checked, the hf-electric.el provided by @xifi (who is an electric committer) is for electric v2
Ah, OK. But doesn’t that just mean that I can’t colour things at the beginning of a function, but I can as soon as I see e/client or e/server? (As I am doing already for v3 e/fn?)
you won't be able to color lambdas either, lambdas are initially sited by the caller, which means you can't know by looking at the source code unless it explicitly has a top level site
it turns out that dynamic siting like this is really important, we spent quite some time thinking about it last year
(Yeah — I’m very excited by v3)
However, I'd be happy for you and @xifi to do a zoom call to discuss, he can help you discern with higher resolution how far an approach like this might go and explore various strategies for implementing. Because this is really cool!
And a frequently requested feature
> you won’t be able to color lambdas either
See the uses of e/fn in the v3 example above. Is that what you mean?
I’d be happy for you and @xifi to do a zoom call to discussThat would be great
yeah L19 cannot be colored without analysing bar, and this appears not to be a valid program because bar is not an electric fn
it's probably important to start with a real program taken from the tutorial
even,
Just checking — are you looking at the v3 example? (Not the v2 example.)
yes the first one
oh i see, you're coloring the div because the div auto-sties
L9 (+ 1 2 3) ; initially we are on the client is dynamic as well, it depends on the caller of Foo1
Yeah — you mentioned that earlier. I will fix it.
As a hypothesis, we might state that the tool is still useful even if lambdas cannot fully be sited lexically (i.e. at comptime). That is interesting to test, maybe so!
In v2, is there a default site?
L12 (div 1 2 3) - 1 2 3 are literals, so i think we already optimize these, but in principle those expressions are caller-sited
you can look at the macroexpansion of div to understand
I guess you knew that already as L19 correctly discolors the div children
> L12 (div 1 2 3) - 1 2 3 are literals, so i think we already optimize these, but in principle those expressions are caller-sited
Oh, OK.
and L34 is good
L40 good (only str server sited)
> In v2, is there a default site?
we do start on the client but it is good practice to site your Main, e.g. https://gitlab.com/hyperfiddle/electric3-starter-app/-/blob/ba07faf428f414717509c86eb1a0e66b3005049e/src/electric_starter_app/main.cljc#L7
i dont understand the page load websocket connection dance well enough to state that it has to be that way (client bias). The http->websocket upgrade involves a handshake, so it's not clear that it has to be client biased. The compiler may have a hardcoded assumption and it may be arbitrary
OK, for v2 I’ll just leave it un-sited at the start of an e/defn (for now at least).
I am surprised that you are able to lexically color so much, im interested in seeing how this goes in real apps. It also may be that we build more abstract apps than most users do
I’ll get this into a state where I can share it, and maybe you can try it out.
i am not an emacs user anymore but @xifi may be interested
My code-coloring Emacs minor mode is ready to share. See https://github.com/simon-katz/nomis-electric-clojure-mode
If you’re an Emacs user, please try it out and let me know how it goes.
@nomiskatz Sterling work! I ran it over (most of) the v3 tutorial code, and it seems to work well so far. I'd dropped Peter Nagy's gist from my config, shall see how I get on with this 🙂
One thing — I noticed let is unsited, and inherits site only for its init-expression and body. I suspect e/for[-by] should follow the same rule.
nice job! I don't use any coloring currently but if I did I would definitely look at this
@jollyboatbros Thanks for trying it out! I’ve fixed e/for and e/for-by. Please try the updated version.
Also I’ve made the mode turn on automatically for Electric source files, but that can be turned off. See https://github.com/simon-katz/nomis-electric-clojure-mode?tab=readme-ov-file#turning-on-nomis-electric-clojure-mode
Just for posterity… I wrote: > In v2, is there a default site? and > OK, for v2 I’ll just leave it un-sited at the start of an e/defn (for now at least). I was confusing dynamic and lexical things — what site the program starts on and what color to use at the top-level of a function.
new Electric snapshot pushed. No known breaking changes. • major Missionary upgrade -- we see no regressions after two weeks of testing, however, the surface area of risk is all of electric. We expect no problems, this is just FYI. • minor changes to electric-forms4 which should not be breaking
Welp, I have no idea what I'm doing. Deleted my current copy of the snapshot and forgotten how to get it again. You have a pointer to the instructions handy?
just clone the starter app, there are no further steps
Cloned it again in another directory and it pulled the snapshot after login as you'd expect. Then when I started my current app, it also asked for login and everythings working. Is there a better way to upgrade than cloning the starter app every time?
um, you're the one who deleted it?
yep. The AI told me to!!! 😀
After rereading this about 5 times, I think you are asking "How do I update my electric dependency to the latest snapshot"? The answer is to restart your REPL, maven revalidates -SNAPSHOT releases daily.
Sorry for the confusion. Yes that's the ultimate goal. Now for the really noob question. Does the REPL get restarted with "clj -A:dev -X dev/-main" because it didn't seem to.
All my Clojure experience is on the server side and years ago. Not so familiar with the new ways of doing things.
> because it didn’t seem to Did you quit your previous REPL?
clj -A:dev -X dev/-main will start a new one
I thought so. Probably screwed something up. Will make sure next time. Thanks
Is there any example in the tutorial of setting a custom property on a DOM node and getting it back. In particular a hash-map?
Where can I find the source for treelister1 and treelister3 used in the explorer tutorial? https://electric.hyperfiddle.net/tutorial/explorer/''
i see they aren't even published to github anywhere due to repository refactoring we've been doing, i'll post here for now. I see treelister1 is not actually used in the published tutorial, so i will just post treelister3
I think we are going to remove this tutorial entirely and turn it into a demo, this is too deep in the weeds
If you're trying to replicate locally, it is in com.hyperfiddle/hyperfiddle {:mvn/version "v0-alpha-SNAPSHOT"} which is published