@bhauman have you ever encountered this error while reloading files by any chance?
ioc_helpers.cljs:42 Uncaught Error: No protocol method ISwap.-swap! defined for type cljs.core/Atom: [object Object]
at Object.cljs$core$missing_protocol [as missing_protocol] (core.cljs:272)
at Function.cljs.core._swap_BANG_.cljs$core$IFn$_invoke$arity$3 (core.cljs:756)
at Function.cljs.core.swap_BANG_.cljs$core$IFn$_invoke$arity$3 (core.cljs:4303)
at cljs$core$swap_BANG_ (core.cljs:4291)
at file_reloading.cljs:303
at file_reloading.cljs:289
at file_reloading.cljs:289
at figwheel$client$file_reloading$state_machine__12780__auto____1 (file_reloading.cljs:289)
at figwheel$client$file_reloading$state_machine__12780__auto__ (file_reloading.cljs:289)
at cljs$core$async$impl$ioc_helpers$run_state_machine (ioc_helpers.cljs:35)
Looks like an undefined atom
@richiardiandrea yeah some how your state of your runtime got way out of wack. That error should never happen.
Are you live reloading figwheel itself?
@bhauman well yeah 😄
I guess this atom here is not defined https://github.com/bhauman/lein-figwheel/blob/b187d9a4535e96d49f24c01579c30d11715b0fe8/support/src/figwheel/client/file_reloading.cljs#L275
on-load-callbacks
no I think the atom is defined
ah
yep I can deref it in the console
its a problem where the prtocols are blown away
the swap protocol got blown away off of the Atom
woah that's weird
you can't reload cljs.core
oh
ok that might be the problem then
because I am reloading stuff after an exception and it looks like I am reloading everything
figwheel prevents you from reloading cljs.core
cljs.core
included
good, I am happy I have asked!
no scratch that
anyways thanks a lot! I think I am very close to a first stable alpha
well so one of the things figwheel does is it ensures that you only reload files that are in the source directories and that actually change
yeah I was wondering that, because I am running lein-figwheel
in parallel on the same project to see what happens
you must be sending a signal to figwheel that cljs.core changed
and that can't be true
because cljs.core doesn't change
yeah, no I am going to filter that for sure
but filtering isn't going to help I don't think
sorry, I mean filtering the change set
yes I understand but the change set should only be the file that changed from edit and its dependents
it should never be cljs.core etc
and the first compile needs to be ignored
unfortunately for what I can see, in boot
when an exception happens, no file is written
so the next time I compile it rewrites all of them
which means everything changed
well thats a PITA
maybe I am missing something (will ask in #boot)
for now I can just filter the messages I send to the client
so what you can to is md5 the files
and see what happens
boot does it by default
but keep track
but if the previous fileset is empty
and only send the changed ones
save the state
in an atom
yep that is also already done in boot-reload
, probably the case of an ex was handled differently
hmmmm weird
there is no (reset! prev fileset)
when an exception happens at the moment
I have another random question, it reloads fine now, but the on-reload
function does not get updated properly (aka, if I have a print in it, and I updated it, I never see the new string printed)...can this be due to pragma stuff and figwheel-load
?