Clojurians Log v2
hyperfiddle 2025-07-11
When I run clj -A:dev -X dev/-main on the starter app I can see INFO dev: :point_right: on the screen, but I get a time out when I point my browser at it? Any ideas?
Are you running on Windows?
Yes, with WSL2 installed
This is on us. I’m attempting a fix. Will keep you posted soon
I pushed a fix. git pull and clj -A:dev -X dev/-main should do the trick.
going to try that now....
Still fails for me, and what I noticed is that when I put http://0.0.0.0:8080 in my browser it changes to http://127.0.0.1:8080/ Not sure if that is relevant though. I use FF.
And I also get this:
* Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080
> GET / HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 11 Jul 2025 10:49:13 GMT
< Last-Modified: Thu, 10 Jul 2025 14:02:45 GMT
< Content-Type: text/html
< Content-Length: 399
< Server: Jetty(11.0.18)
<
<html>
<head>
<meta charset="utf-8"/>
<title>Hyperfiddle</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="/electric_starter_app/index.css" type="text/css" />
<script defer type="text/javascript" src="/electric_starter_app/js/main.js"></script>
</head>
<body></body>
</html>so it works... but FF is not playing ball for some reason. Let me try another browser
hmm Edge and Brave don't like it either... but curl does
I don't get it
Glad to hear it works with localhost. Sorry you had to debug it. I’m capturing this and we will improve.
no worries, just a bit confused
ok, there is a difference with the latest Ring version ("1.14.2") and the one used in the starter app. Not sure what it is though.
Hi Thomas thanks for pointing that out we will upgrade our deps asap
In the meantime please just clone the starter app and don't change the deps
We haven’t upgraded cljs in quite some time. Is there a feature or fix you need from a more recent cljs version?
No, I just tend to use the latest of everything.
Published a new Electric snapshot:
• breaking: stricter unserializable value guards.
◦ we are not expecting any actual breakage, but there could be some in principle.
◦ we discovered transit serializes java Object to nil and js/Object to {}. While these two should be harmless, we do not know if other types could be implicitly serialized today, or in the future. As a matter of precaution and to prevent any accidental or unexpected object transfers, Electric will now only accept to serialize objects with an explicit transit write handler.
• compiler improvements:
◦ fix clojure.core/delay usage in cljs blocks
◦ fix foo.bar.Baz syntax support in cljs
◦ improved macro support in cljs (e.g. encore and telemere)
◦ improved zprint and SCI compat (calling zprint or SCI from Electric)
https://docs.google.com/document/d/17BE7xpV9bFoPq9scLJHCF8hD5gBm00K0Up45N3XeG5c/edit?tab=t.0
improved zprint and sci compat? 👀
improved zprint and sci compat?https://github.com/hyperfiddle/electric/commit/257ef44b5f9feaaf81aeef551f2af527eacdb180
does this mean electric can run in SCI?
I don’t know (I don’t think so). This fix is about calling SCI from Electric, not the other way around. Sorry for the confusion.
ah no worries, it just got me curious :)
Someday 🤞
thanks for the release! confirmed telemere logging is working in both clj and cljs
Hi. I have a macro that is misbehaving with the new Electric snapshot. It was fine before. See in thread for details.
> unless you call this macro from an e/defn I only call my macro from the top level.
From the error message, it seems that this is about whether subforms of do are processed separately as top-level forms, or whether the do form as a whole gets processed all together.
FWIW, I know Common Lisp clearly states that subforms of progn are processed as top-level forms, but I’m struggling to find a similar statement for Clojure’s do. Although a little experimenting shows that it does seem to be the case.
Anyway, as I said, no urgency. Have a good weekend!
I asked about top-level do in #clojure.
You might want to look at the discussion at https://clojurians.slack.com/archives/C03S1KBA2/p1752422724214819
Some interesting stuff!
(No urgency. I have a workaround.)
(FWIW, it defines a CLJS atom that tracks the latest value of an Electric signal. Maybe this is a bad idea and there are better ways of achieving what I want, but I think that’s by the by.)
I call it like this:
When I first connect to a REPL, I get the following error:
Exception in thread "main" Syntax error macroexpanding hyperfiddle.electric3/defn [...]
my-ns/Maintain-my-cljs-name::
I cannot resolve [!my-atom-name]If I change the when cljs? in the macro definition to when true, I can start a REPL with no problem.
I can then revert the change, and running (dev/-main) works fine.
Maybe the macro changes in the new snapshot have broken something.
Thank you for this detailed report.
> Maybe the macro changes in the new snapshot have broken something.
>
I share your intuition. Though I'm not yet clear if the release broke something or if something was working by accident before.
Eyeballing your macro impl I noticed you detect cljs vs clj with (:ns &env) . Try with (:js-globals &env) instead. We've found it to be a more reliable check overall.
And not just in Electric. After years of dealing with tools.analyzer and clj/cljs compilers, we now default to (:js-globals &env). TBH I don't remember why.
Thanks — it’s good to know about :js-globals.
I gave it a go but (:js-globals &env) is behaving in the same way as (:ns &env).
We used to fill in :ns in electric and we don't for this exact reason, people check for cljs env that way. Although I don't see how that breaks here, unless you call this macro from an e/defn