hyperfiddle 2025-03-18

Have not touched my electric repository for a while. No changes from my code but I am getting this when I try and start it. Start of stack trace is: Exception in thread "main" Syntax error macroexpanding at (hyperfiddle/electric/impl/lang3.clj:1:1). Also later says it's related to contrib. Caused by: java.io.FileNotFoundException: Could not locate contrib/assert__init.class, contrib/assert.clj or contrib/assert.cljc on classpath. Did something change. I think I saw something about contrib changing.

Going to just try with a fresh starter.

Did get it working. Will leave messages here for search history.

mostly yes, the analyzer passes are a bit out of date. Is this just out of curiosity? This documents compiler internals for our own needs and is subject to change

Yes, just curiosity

👍 1

Now that you’re here, what is an Electric function in terms of Missionary?

internally it is a missionary flow. (e/pure electric-expr) returns the underlying missionary flow (incseq)

⚡ 2
Dustin Getz (Hyperfiddle) 2025-03-19T02:02:15.519199Z

• calling an e/fn with zero args is like joining a missionary flow • any args are basically passed by dynamic scope

👀 2

I think the docstring of e/input should be updated. It says “Returns the current state of current continuous flow cf“. In https://electric.hyperfiddle.net/tutorial/temperature2 it is being used with a discrete flow random-writer.

Or maybe I’m misunderstanding what it means for a flow to be continuous. I think a continuous flow is a flow which is always ready to transfer, so random-writer is not a continuous flow because after transferring 0 it is not ready to transfer again for one second.

the terms are defined loosely. Often we mean it is initialized, i.e. defined at all times. (m/ap (m/? (m/sleep 1000 :foo)) is not initialized, upon boot it has no value. (m/ap (m/amb :foo (m/? (m/sleep 1000 :foo)))) is well defined and you can call e/input on it because it has a value defined at all times

i.e. it is OK to join discrete flows iff they are initialized

There’s a new version of my code-coloring-for-Emacs thing. Highlights from the CHANGELOG: • Don’t color Electric calls. • Don’t color bound symbols when used in certain contexts: ◦ as an arg in an Electric call ◦ as the RHS of a binding pair. • Provide an extension mechanism so that you can teach the mode about user-land binding macros. • Support destructuring in let-bindings forms and fn-bindings forms. See thread for details.

🌳 2

Looks nice! I wonder how hard it would be to do something similar with Calva

> Looks nice! Thanks! > I wonder how hard it would be to do something similar with Calva I don’t know — I’m not familiar with Calva.