oh this seems to work:

(exists? (aget js/window "jQuery"))

on what electric version are you?

com.hyperfiddle/electric {:mvn/version "v2-alpha-428-g22937f75"}

we've encountered cljs build failures due to exceeding the default stack size, e.g. in the examples app. You can https://github.com/hyperfiddle/electric-examples-app/commit/dab45788afc5f1c8128800f3c7e9ba2b869120f7

Even in dev mode?

I don't think I've seen it in dev mode, although I guess it's bound to happen at some point. Unless you have a real stack overflow? You can try increasing the stack size and see

It’s weird the app is very light.

please post the error

Here the stack trace on dev compile time start. I try to create a gist with the code.

--------------------------------------------------------------------------------
   5 |    [quizy.web-ui.core :as core]))
   6 | 
   7 | (def electric-main
   8 |   (e/boot
---------^----------------------------------------------------------------------
null
StackOverflowError: 
	java.lang.ClassLoader.defineClass1 (ClassLoader.java:-2)
	java.lang.ClassLoader.defineClass (ClassLoader.java:1017)
	java.security.SecureClassLoader.defineClass (SecureClassLoader.java:174)
	jdk.internal.loader.BuiltinClassLoader.defineClass (BuiltinClassLoader.java:800)
	jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull (BuiltinClassLoader.java:698)
	jdk.internal.loader.BuiltinClassLoader.loadClassOrNull (BuiltinClassLoader.java:621)
	jdk.internal.loader.BuiltinClassLoader.loadClass (BuiltinClassLoader.java:579)
	jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass (ClassLoaders.java:178)
	java.lang.ClassLoader.loadClass (ClassLoader.java:522)
	clojure.core/elide-top-frames (core.clj:4803)
	clojure.core/ex-info (core.clj:4807)
	clojure.core/ex-info (core.clj:4807)
	cljs.analyzer/error (analyzer.cljc:780)
	cljs.analyzer/error (analyzer.cljc:776)
	cljs.analyzer/analyze (analyzer.cljc:4366)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	cljs.analyzer/analyze (analyzer.cljc:4362)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	cljs.analyzer/analyze (analyzer.cljc:4360)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	cljs.analyzer/analyze-const (analyzer.cljc:2539)
	cljs.analyzer/analyze-const (analyzer.cljc:2536)
	cljs.analyzer/fn--3047 (analyzer.cljc:2551)
	cljs.analyzer/fn--3047 (analyzer.cljc:2547)
	clojure.lang.MultiFn.invoke (MultiFn.java:252)
	cljs.analyzer/analyze-seq* (analyzer.cljc:4080)
	cljs.analyzer/analyze-seq* (analyzer.cljc:4078)
	cljs.analyzer/analyze-seq*-wrap (analyzer.cljc:4085)
	cljs.analyzer/analyze-seq*-wrap (analyzer.cljc:4083)
	cljs.analyzer/analyze-seq (analyzer.cljc:4109)
	cljs.analyzer/analyze-seq (analyzer.cljc:4087)
	cljs.analyzer/analyze-form (analyzer.cljc:4296)
	cljs.analyzer/analyze-form (analyzer.cljc:4293)
	cljs.analyzer/analyze* (analyzer.cljc:4349)
	cljs.analyzer/analyze* (analyzer.cljc:4341)
	cljs.analyzer/analyze (analyzer.cljc:4369)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	cljs.analyzer/analyze (analyzer.cljc:4362)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	cljs.analyzer/analyze (analyzer.cljc:4360)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	shadow.build.cljs-hacks/shadow-parse-invoke*/fn--5892/fn--5893 (cljs_hacks.cljc:828)
	clojure.core/mapv/fn--8535 (core.clj:6979)
	clojure.core.protocols/fn--8249 (protocols.clj:168)
	clojure.core.protocols/fn--8249 (protocols.clj:124)
	clojure.core.protocols/fn--8204/G--8199--8213 (protocols.clj:19)
	clojure.core.protocols/seq-reduce (protocols.clj:31)
	clojure.core.protocols/fn--8234 (protocols.clj:75)
	clojure.core.protocols/fn--8234 (protocols.clj:75)
	clojure.core.protocols/fn--8178/G--8173--8191 (protocols.clj:13)
	clojure.core/reduce (core.clj:6886)
	clojure.core/mapv (core.clj:6970)
	clojure.core/mapv (core.clj:6970)
	shadow.build.cljs-hacks/shadow-parse-invoke*/fn--5892 (cljs_hacks.cljc:828)
	clojure.lang.Delay.deref (Delay.java:42)
	clojure.core/deref (core.clj:2337)
	clojure.core/deref (core.clj:2323)
	shadow.build.cljs-hacks/shadow-parse-invoke* (cljs_hacks.cljc:960)
	shadow.build.cljs-hacks/shadow-parse-invoke* (cljs_hacks.cljc:817)
	cljs.analyzer/parse-invoke (analyzer.cljc:3836)
	cljs.analyzer/parse-invoke (analyzer.cljc:3834)
	cljs.analyzer/analyze-seq* (analyzer.cljc:4081)
	cljs.analyzer/analyze-seq* (analyzer.cljc:4078)
	cljs.analyzer/analyze-seq*-wrap (analyzer.cljc:4085)
	cljs.analyzer/analyze-seq*-wrap (analyzer.cljc:4083)
	cljs.analyzer/analyze-seq (analyzer.cljc:4109)
	cljs.analyzer/analyze-seq (analyzer.cljc:4087)
	cljs.analyzer/analyze-form (analyzer.cljc:4296)
	cljs.analyzer/analyze-form (analyzer.cljc:4293)
	cljs.analyzer/analyze* (analyzer.cljc:4349)
	cljs.analyzer/analyze* (analyzer.cljc:4341)
	cljs.analyzer/analyze (analyzer.cljc:4369)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	cljs.analyzer/analyze (analyzer.cljc:4362)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	cljs.analyzer/analyze (analyzer.cljc:4360)
	cljs.analyzer/analyze (analyzer.cljc:4352)
	shadow.build.cljs-hacks/shadow-parse-invoke*/fn--5892/fn--5893 (cljs_hacks.cljc:828)
	clojure.core/mapv/fn--8535 (core.clj:6979)
	clojure.lang.PersistentList.reduce (PersistentList.java:141)

The code of the electric app: https://gist.github.com/jeans11/3f5df7d2b134e611167705322bdadd13

please add deps.edn as well

I suspect some typo masquerading as this. You should comment bisect* to find the form causing it. *comment out half of your code, see if error persists, recurse

If you can send us a repo to clone where we can reproduce it, we can improve the error (if this is a syntax error) or otherwise make this more pleasant

I send you an invite to the repo

When I remove the .shadow-cljs cache, start a repl and the app, everything works! Made some change on the app, etc... no errors. When I close / start my repl and start the app, I got the StackOverFlow error.

no, your backend should scale just fine

what electric version? please make sure you upgrade to 428

Yep I’m on the 428

v2-alpha-428-g22937f75

if you remove the shadow cache do the warnings persist? (`rm -rf .shadow-cljs`). You'll need to start the app twice to be sure the warnings are gone, first run fills the cache, second uses it

I.e., just WordCount with UI.

code?

I’m putting together a gist with the salient parts. I’ve got to remove some Multiplyisms.

https://gist.github.com/eneroth/bb22966fa76f32caae04200ca21f6332

That should be pretty much it. @U09K620SG Interesting interaction between Electric and Rama: In subscribe, I had to use proxyAsync over proxy, or pretty much everything locked up. Weirdly, the first mounted sub would be OK, but the second would block indefinitely. Luckily, this issue didn’t arise with proxyAsync.

A general note: A global partition wouldn’t be a good idea if you want 100 million bots counting words. A Rama-maintained toplist would be the way to go.

thanks @U06B8J0AJ! trying out your example, I'm getting an error, "The required namespace "com.rpl.rama.Depot" is not available". are you using these versions of rama?

com.rpl/rama {:mvn/version "0.9.4"}
com.rpl/rama-helpers {:mvn/version "0.9.0"}

@U066TMAKS Yep, those are the ones. It’s only Depot that’s the problem, nothing else?

ah nevermind, i was messing up clj/cljs. i realize now your example is split into several files

what goes into #_get_cluster_here? guess i need to read up on rama more

trying this:

(e/def cluster (e/server (.create InProcessCluster)))

Ah yeah, sorry, I didn’t include that because it’s delivered by our boot system. I’ll update the gist with some general Rama init stuff.

(InProcessCluster/create)

But you shouldn’t put it in the e/def, you should have it globally somewhere.

right

regarding the lockup, .proxy and .proxyAsync are rama methods, are they documented? i have no idea what they do (I know superficially they are emitting diffs but i dont know if they are doing e.g. thread stuff)

@U066TMAKS Try this:

;; Change require to:
[app.modules.wordCount :refer [->SimpleWordCountModule]]

;; Replace the `e/def` with
#?(:clj (defonce cluster
          (let [c (InProcessCluster/create)]
            (.launchModule c (->SimpleWordCountModule) (LaunchConfig. 1 1))
            c)))

Sorry, a few edits above, it was hastily written.

@U09K620SG https://redplanetlabs.com/javadoc/com/rpl/rama/PState.html#proxy-java.lang.Object-com.rpl.rama.Path- and below

And https://redplanetlabs.com/docs/~/pstates.html#_reactive_queries

> Blocks until initial query finishes

i don't fully understand what that means, i'll have to look more closely when i have more time

I think it means “blocks until it has an initial value to return”, since you can run .get and stuff on the proxy object. Anyway, it’s not urgent, merely interesting. proxyAsync is fine, since the return value isn’t needed until Electric does cleanup.

im kinda shocked that registering a callback on something is a blocking operation ever

It does two things: runs a query and registers a callback. Maybe those should have been two separate operations, but here we are.

I read the semantics like, imagine you could run (atom), and deref would block until the atom receives the first value.

@U066TMAKS I updated the gist with what I think would work for as a start. Let me know if it doesn’t.

thanks, had to step out for a sec but i will review shortly

https://github.com/yayitswei/rama-electric-example currently seeing errors in startup, and then java.net.BindException: Address already in use if i try to eval the defonce cluster line. i suspect it's a sequencing issue, unless there's some port conflict that i'm not aware of

Yeah, it’ll need to be managed. You can .close the cluster if you need to reevaluate it, or otherwise use some system state lib like Integrant.

@U066TMAKS Sent you a pull request

happy to say we got this running. needed to match rama's internal version of clojure, 1.11.1 (see updated example). thanks @U06B8J0AJ for your patience troubleshooting!

a few comments

• i think cljs reader conditional doesn’t do what you want it to in e/defn, not sure if that is impacting this • with-reagent may need adjustments, it was provided as an example not as a robust component • what is Footer? the gist you provided is incomplete

i currently suspect the reader conditional (without seeing the full context). The Footer form is being elided entirely, causing an arity error which JS interprets as passing undefined. Fix of this would be to not use a reader conditional. Presumably you inserted a reader conditional here because the linter told you to. Unfortunately linters give broken results with Electric, you have to ignore them or turn them off until we figure out how to fix them

Apologies, I added the Header and Footer to the gist. I indeed added the reader conditionals because the linter was complaining, unfortunately getting rid of them didn't help either.

Here's the full error message I see in the console:

Cannot read properties of undefined (reading 'insertBefore')

 in reactive (fn [] ...)
 in reactive (fn Hello [] ...)
 in (case :hello ...) in com/sagar/casa/ui/router.cljc line 38
 in reactive (defn Router [] ...) in com/sagar/casa/ui/router.cljc line 34
 in reactive (fn [] ...)
 in reactive (defn Root [] ...) in com/sagar/casa/ui.cljc line 11
 in (try ...) 

 TypeError: Cannot read properties of undefined (reading 'insertBefore')
    at $sagar$casa$ui$reagent$react_root_hook__2 [as cljs$core$IFn$_invoke$arity$2] (reagent.cljc:24:44)
    at eval (runtime.cljc:641:16)
    at eval (runtime.cljc:601:13)
    at eval (Continuous.cljs:144:8)
    at missionary$impl$Continuous$suspend (Continuous.cljs:144:7)
    at Object.eval [as missionary$impl$Fiber$Fiber$swich$arity$2] (Continuous.cljs:16:23)
    at Object.missionary$core$switch [as switch$] (core.cljc:176:17)
    at hyperfiddle$electric$impl$runtime$variable_$_cr62862_block_3 (runtime.cljc:619:9)
    at eval (impl.cljc:60:19)
    at Function.G__61998__0 [as cljs$core$IFn$_invoke$arity$0] (impl.cljc:60:35)

can I see with-reagent and Hello?

I was able to fix this. I had an older copy of with-reagent, this change fixed it https://github.com/hyperfiddle/electric/commit/dbbd147a0dc6748d5bf420c697d9d2221409cbfa Thank you for prompting me to look at with-reagent again @U09FL65DK 😅