Fork me on GitHub
#shadow-cljs
<
2019-10-09
>
wonko708:10:51

Hi! is there a way of checking what clojure dependencies could be updated?

beetleman16:10:30

if you using deps.edn you can use: https://github.com/Olical/depot

thheller08:10:51

not built-in no

tony.kay15:10:35

@thheller I’ve got an additional “hint” on that weird tagged literal leaking to transit write while compiling: It seems to happen when I’m using deps :local/root. I switch between that and normal version when working on Fulcro bugs. It does it under the following conditions (so far, these seem the only way I get it): Build target is :react-native, and I’m using a dependency that has heavy use of CLJC through :local/root in deps.

tony.kay16:10:53

Confirmed. If I put Fulcro out as a SNAPSHOT and use :mvn/version, then I don’t get the shadow-cljs exception about the tagged literal

thheller16:10:59

@tony.kay can you try with the latest version? I added an additional try/catch that should assist with debugging

tony.kay16:10:07

I’m using .61

thheller16:10:34

then it should be printing the full EDN data (in the server log, so don't start in the background)

tony.kay16:10:53

I’m using shadow-cljs server

tony.kay16:10:59

what should I do instead?

thheller16:10:05

no thats it

tony.kay16:10:21

stand by…it looked the same to me. I’ll repro

thheller16:10:44

:transit-str
   {:depends-on []
    :start
    (fn []
      (fn [data]
        (let [out (ByteArrayOutputStream. 4096)
              w (transit/writer out :json)]
          (try
            (transit/write w data)
            (.toString out)
            (catch Exception e
              (log/warn-ex e ::transit-str-failed {:data data})
              (throw e))))))

    :stop (fn [x])}

thheller16:10:03

I added that try/catch and it should trigger the log/warn-ex stuff

tony.kay16:10:09

ah, there is more

tony.kay16:10:17

kind of a boat load

thheller16:10:19

so we can at least tell which data triggered the problem

tony.kay16:10:20

where do you want it?

tony.kay16:10:11

ok, I’ll get it to you

tony.kay16:10:11

Seems like this function from Fulcro is confusing it:

(let [update-fn (fn [component f args]
                  #?(:cljs (.setState component
                             (fn [prev-state props]
                               #js {"fulcro$state" (apply f (gobj/get prev-state "fulcro$state") args)}))))]
  (defn update-state!
    "Update a component's local state. Similar to Clojure(Script)'s swap!

    This function affects a managed cljs map maintained in React state.  If you want to affect the low-level
    js state itself use React's own `.setState` directly on the component."
    ([component f]
     (update-fn component f []))
    ([component f & args]
     (update-fn component f args))))
and I do get a warning about .setState…it’s the warning thta is being passed through

tony.kay16:10:39

:resources 269, :compiled 4, :warnings [{:source-excerpt {:start-idx 452, :before ["     (get-in cst (if (sequential? k-or-ks) k-or-ks [k-or-ks])))))" "" "(let [update-fn (fn [component f args]"], :line "                  #?(:cljs (.setState component", :after ["                             (fn [prev-state props]" "                               #js {\"fulcro$state\" (apply f (gobj/get prev-state \"fulcro$state\") args)}))))]" "  (defn update-state!" "    \"Update a component's local state. Similar

thheller16:10:21

found it I think

tony.kay16:10:23

well, other than those are strings?

thheller16:10:56

:extra {:warn-type :target, :form (. component setState (fn [prev-state props] #object[cljs.tagged_literals.JSValue 0x7713c25e "[email protected]"]))}

thheller16:10:46

:extra is warning data and the :form it warns about is probably something like (fn [prev-state props] #js{:foo ...})

thheller16:10:56

with :local/root the :infer-externs :auto logic kicks in and starts warnings about stuff

thheller16:10:06

with the files in .jar those warnings are not triggered

thheller16:10:04

I'll clean up the warning since :form isn't used for anything anyways

tony.kay16:10:37

cool, that explains it.

thheller16:10:52

will release a fix later, be back later

thheller16:10:10

thanks for the log!

tony.kay16:10:26

I’m also seeing warning that make no sense to me when using react native target. When I use (:import [ ErrorCode]) and then use something like (.-EXCEPTION ErrorCode) without a ^js meta marker I get a warning about Cannot infer target type in expression (. ErrorCode -EXCEPTION)…I expected imports to “just work”

tony.kay16:10:10

oh, maybe that isn’t a class 😕

tony.kay16:10:36

no, it’s an enum, so it should be imported

thheller21:10:59

@tony.kay both issues should be fixed in [email protected]

pmooser21:10:20

When I use instaparse and require instaparse.core from a cljs project using shadow-cljs, I see a bunch of warnings. However, they all seem to come from :clj portions of feature expressions (or whatever we call them these days in clojure). Is anyone else familiar with this, or understand why it might be happening?

pmooser21:10:23

(the warnings all originate from java stuff that is meaningless in cljs, which is why presumably they're in :clj blocks instead of the :cljs part)

pmooser21:10:50

------ WARNING #3 - :protocol-invalid-method -----------------------------------
 Resource: instaparse/gll$macros.cljc:51:4
 Bad method signature in protocol implementation, CharSequence does not declare method called charAt

pmooser21:10:08

And now I see when I do a require like this:

pmooser21:10:09

[instaparse.core :as insta :refer-macros [defparser]]

thheller21:10:14

are you compiling for self-hosted?

pmooser21:10:15

I get the following error from shadow-cljs:

pmooser21:10:23

The required namespace "instaparse.macros" is not available, it was required by "instaparse/core$macros.cljc".
"instaparse/macros.clj" was found on the classpath. Should this be a .cljs file?

pmooser21:10:37

Yes, I have 2 builds, one for self-hosted bootstrap.

thheller21:10:48

looks like self-hosted? the library may just not be compatible with self-hosted?

pmooser21:10:59

Can I still use it, if I just don't use it dynamically?

pmooser21:10:18

(what I mean is, I use self-hosted for a REPL I've implemented, but I don't need to use instaparse in the REPL)

pmooser21:10:49

I don't really understand how the two builds interact.

thheller21:10:42

the :bootstrap build is controlling what is available to use in self-hosted code eval'd in the browser

thheller21:10:11

you are probably just a bit generous with your :entries?

pmooser21:10:32

Ok, that makes sense. I'm sure you're right - entries includes my core namespace, and I included instaparse there.

pmooser21:10:40

Thanks @thheller, that all makes sense now.

thheller21:10:03

yeah, only include namespace there that you want your users to be able to actually use

thheller21:10:19

including all the "base" code usually isn't required

pmooser21:10:26

Sure. I mean honestly in my ideal world they could use any namespace. But I understand that cljs has limitations in this regard.

pmooser21:10:35

(that is why :entries is as broad as I could make it previously)

thheller21:10:03

it isn't easy to write macros that run in all hosts equally

thheller21:10:47

not sure if some adjustments could fix it for instaparse, might be possible to get that working but not sure. could also just exclude the macros.

pmooser21:10:00

Sure. And I'm sure there are many subtleties I don't understand. I still hope someday we end up in a completely self-hosted cljs world. But I'm not sure we're ever really going to get to "clojure in clojure" like Rich used to talk about a decade ago.

pmooser21:10:21

I think excluding that ns in the bootstrap build for now works perfectly fine.

pmooser21:10:35

And thank you for your patience in helping me!

thheller21:10:16

self-hosted will always mean that the build is gigantic which makes it a no-go for most apps

thheller21:10:37

can't ship 5mb of JS normally

pmooser22:10:59

I understand. I expect that to be less and less of a problem in the future, especially for certain classes of apps.

thheller22:10:59

I doubt that. If anything we need to get filesize down not up.

pmooser22:10:33

I think historical trends seem to go the opposite direction of your predictions.

thheller22:10:13

https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 explains pretty well why it likely won't change until some major breakthrough in the "mobile" world

pmooser22:10:32

This looks interesting, and I will read it, but talking about performance budgets loading CNN on mobile phones doesn't speak to what I'm talking about. That's why I said "for certain classes of apps". I don't think a news site on a random phone is exactly in the domain of having a self-hosted REPL which you can use to write code at runtime. Anyway, this is almost certain outside the core of shadow-cljs discussion. Thank you for the article - I will finish reading it.

thheller22:10:58

sure certain apps don't care much about size. just saying that a "completely self-hosted cljs world" is not even a goal at this point, at least shadow-cljs will never go there.

pmooser22:10:17

I'm sure there is a lot I don't understand about the cljs compilation world, but since shadow-cljs isn't the compiler or the runtime, I didn't expect that being a goal or not was contingent on shadow-cljs's perspective on the relative importance of being completely self-hosted.

thheller22:10:16

not sure how to answer that. all I can tell you that if you want something completely self-hosted without a JVM required then you'll never find that in shadow-cljs

pmooser22:10:31

Sure, I'm sure you're right, and I don't think it seems to currently be a goal for the clojure folks either at this point.

thheller22:10:41

maybe once a full JVM can run in WASM 😉 but then we'll be north of 100MB which makes it even less of an option 😛

pmooser22:10:10

Yes, and at that point I will agree with you that's undesirable and also won't ever happen. 🙂

pmooser22:10:20

Anyway, thanks again for your help.