Clojurians Log v2

is this with the 2.28.22 upgrade I made earlier today or before?

I was using 2.28.21

is there a change to 22 that might matter? I looked at the commit log and it didn’t ring bells

oh, possibly this: https://github.com/thheller/shadow-cljs/commit/cc90dd19067cde5092b59581aec8bfc151b0f4e0

I’ll try the latest, sorry for not trying that aleady…the commit log didn’t look immediately obvious for changes that would matter

yeah I changed quite a bit of REPL code, so that could totally blow things up 😛

nah just wanted to check if I screwed something up with that upgrade

but if you don't use that I can rule that out as a cause for your problem

I think I tried bouncing back to 2.20.20, FYI…I think it didn’t help. I was trying to rule out shadow breaking

the connect logic for react-native in theory hasn't changed in many years, at least not intentionally

(problem is I tried so many things, and I didn’t keep great notes)

should at least get some kind of log if the connect fails or times out

yeah, that was what was weird…and I couldn’t figure out if maybe they had borked the logging…my log messages are coming out though

but my project is complex….which is why I asked if anyone else has it working. there is a non-zero chance it is something in what I have…but for the life of me I don’t see how shadow can compile, and I get a loaded app, but no shadow messages in logs

:native          {:target           :react-native
                              :init-fn          mobile.client-native/init
                              :output-dir       "mobile/native-apps/app"
                              :compiler-options {:output-feature-set :es5

you can try setting a fixed :devtools-url https://shadow-cljs.github.io/docs/UsersGuide.html#proxy-support

I did

also tried top-level local-ip

otherwise it'll try npx shadow-cljs clj-repl (shadow/get-server-addrs) to connect

if the correct ip is in there the connect logic should find it

which is why I then dumped into the js console and tried a fetch from within the app to see that localhost:9630 was reachable

cause I was trying to eliminate the latest line of macos security nightmares

unless you explicitely set :devtools {:enabled false} there should be at least some kind of log telling you what failed

did you check http://localhost:9630/runtimes if any runtime shows up if you load the app? maybe it connects just fine but fails elsewhere

I only see the CLJ runtime of shadow

I’ll try again later. I wasted most of a Sunday on it already and had given up…I was hoping I would at least hear from someone here “Yes, I’m using the latest expo go and it works perfectly”

any kind of exception during load maybe?

nothing…it was strangely silent. maddening actually

just log messages from my app saying it was starting, etc.

it was as if the shadow repl connection code just wasn’t even being tried

so I thought some exception might be swallowed…but if so it is silent. I looking in the macos console for the low-level messages and I see some TCP fails, but they were rather vague and could have been associated with my app trying othger things

did you try wiping the cache and old output files? maybe the expo build parts are some on something old?

yeah, when I downgraded to 2.20.20

wiped .shadow-cljs and everything. Like I said, what I’ll do is try again with some kind of blank slate project and see what I see.

maybe just try your demo app

hmm yeah I haven't been anywhere near a react-native project in many years, so no clue whats going on in that area

don't even know what expo go is 😛

they did some kind of internal refactor to use a “bridgeless” internals, which I find suspect. Expo Go is a pre-build native app that can run react native and has built-in features

it’s the “standard” way to sstart react native these days

you can try copying this file into your classpath and just adding some logging https://github.com/thheller/shadow-cljs/blob/d12811cfb7884d86dcecb3a16cf61c9e89bb8b05/src/main/shadow/cljs/devtools/client/react_native.cljs#L98

if needs to get past this when to start the connect process

maybe that can provide a clue somewhere if its even loaded/trying to connect

great, thanks

I get these warnings, and the first one at least is true…sounds bad

second one as well

looks like protocols changed?

yeah thats the part I changed in 2.28.22

you can upgrade or just use the older version https://github.com/thheller/shadow-cljs/blob/a676aadb9741916e0d5663e25b6622fbb9cc2eba/src/main/shadow/cljs/devtools/client/react_native.cljs

oh, did I get the wrong version?

I linked you the latest version, use the one from 2.28.21 instead. not much changed in the implementation aspect. nothing that should affect this issue at least

sorry, I set the deps wrong

I thought I was on latest

I can confirm it loads the shadow react-native ns. It looks like it all runs, and the when gets true, and it calls the setTmeout, but the function in the setTimeout never runs…

confirmed…if I change the setTimeout to a do everything starts working 🧩

why the heck would setTimeout not work?

WTF…I can do setTimeout from the debug window and it’s fine

this is bizzarre

ok, did I do something stupid somewhere and break setTimeout somehow…

(thanks for this tip, BTW, makes it trivial to debug my issue)

hehe

I didn’t realize it was this easy to muck with your injected code

you can mess around with pretty much everything in shadow-cljs this way. any ns will do 😛 CLJ included

yeah, I knew that about clojure in general, I just meant I didn’t realize your injected code wasn’t generated in some complex way

hehe yeah its all very basic

basically just adds an entry to :preloads

so

(js/console.log js/setTimeout)

so it MUST be someething about the Expo system startup

you can in theory remove that setTimeout, it is just there for error cases anyway

or maybe increase the timeout?

if you have a big app maybe it is just busy and something in expo decides to not fire it because too old?

I tried increasing the time…no help. Turning it into a do seems fine, though

there is another setTimeout use in the connect loop

but yeah seems like an expo issue if setTimeout doesn't work

I’m using core async…I wonder if something in core async is messing with it

I know they have to hook into that to do async/timeout

but it doesn't modify setTimeout

nope…removed async stuff still no timeout

hm…actually, now that I removed some of my code it DID start doing setTmeout…I think this HAS to be my fault in here somewhere…at least I know how it is broken. Thanks so much for the help!

yeah, if I start my core async loop on load, then it breaks the setTimeout from your preload. If I delay my core async loop (which immediately has a async/timeout) to happen later, then your setTimeout is ok

strange. maybe expo has a limit on how many setTimeout can be pending?

yeah, gotta be an expo-ism

What version of expo are you running?

I have get hot code and js repl working just fine. I am running "expo": "^52.0.41" with latest shadow-cljs 2.28.22 and fulcro 3.8.3

It's the latest. Works fine unless I start State charts too early

Oh yea I noticed that as well working with statecharts. I didn’t factor in that variable. When did you end up starting the statecharts?

I put it in a deferred call like 500ms later

no idea why it is borked…I vaguely remember having to do some kind of patch for sente where at one point I was trying to fix setTimeout, I’ll have to look through the libs and make sure I didn’t so something stupid

searching for setTimeout and react-native has quite a few hits, so seems like a rather longstanding unfixed issue. guess its hard to reproduce and figure out what exactly the problem is 😛