Fork me on GitHub
#shadow-cljs
<
2017-12-20
>
mhuebert10:12:14

hmm, the reagent with-let macro results in some externs inference warnings: https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.clj#L48

Cannot infer target type in expression (. c__50784__auto__ -ratomGeneration)
Cannot infer target type in expression (. with-let79468 -generation)

thheller10:12:28

hmm I think thats going to require type hints

thheller10:12:40

any idea why those are not protocols?

thheller10:12:24

I can't really make sense of that macro, seems weird

mhuebert10:12:28

alright. so that would just be adding ^js in front of v and c#

thheller10:12:44

^clj not js

thheller10:12:55

since its a clojure value we don't need externs

thheller10:12:12

but it doesn't detect it as a clojure value since it doesn't use a protocol

mhuebert10:12:19

would that also work in non-shadow builds

mhuebert10:12:47

so (let [^clj ~v (reagent.ratom/with-let-values ~k)] …

thheller10:12:04

can't tag quoted syms like that

thheller10:12:33

v (with-meta {:tag 'clj} (gensym "with-let")) in the let above

thheller10:12:40

oops switch the args

thheller10:12:57

(with-meta (gensym "with-let") {:tag 'clj})

thheller10:12:33

I think so at least .. maybe the unqoute does work too

mhuebert11:12:13

alright, so what seems to work is your way^^ for the symbol that is bound outside of the syntax quote, v (with-meta (gensym "with-let") {:tag 'clj}) and an inline ^clj for the symbol that is bound within the quote (when-some [^clj c# reagent.ratom/*ratom-context*] ...)

mhuebert11:12:01

neither seem to work the other way around

thheller11:12:41

interesting. would not have expected ^clj c# to work

thheller11:12:02

makes sense though since its not unquoted

mhuebert11:12:43

i am seeing some deftype- or protocol-related type hint errors that show up the first time I run a build, but not after (unless i rm -rf target)

41 | (deftype GZIPPacker [packer]
-------^------------------------------------------------------------------------
 Cannot infer target type in expression (. (. GZIPPacker -prototype) -taoensso$sente$interfaces$IPacker$)
--------------------------------------------------------------------------------
  42 |   taoensso.sente.interfaces/IPacker
  43 |   (pack [_ x]
  44 |     (try
  45 |       (->> x (pack packer) (gzip))

mhuebert11:12:09

actually it’s not entirely clear to me when they will appear or not

thheller11:12:32

are you using a checkout of shadow-cljs?

mhuebert11:12:13

shadow-cljs is not listed in the dependencies, and there is no checkouts dir

thheller11:12:35

I see those warnings sometimes when working on shadow-cljs itself, have not figured out where they come from either

thheller11:12:41

since they work most of the time

mhuebert11:12:44

ok, so the warnings remain during reload. but if i stop the process, and then start another watch process, the warnings are gone (until i remove the caches)

thheller11:12:42

the warnings should prohibit the cache from being use at all

thheller11:12:20

I’ll take a look at sente

thheller11:12:46

I guess I could treat any variable name that uses that naming pattern as CLJS

thheller11:12:56

eg. everything $thing$foo$

mhuebert11:12:14

seems to happen in some even very simple cases of implementing protocols. the sente thing is probably easiest to debug/reproduce as it’s all open source. another example from my repo --

(defprotocol IExplain
  (explain [this value]))

(defrecord ExplainStruct [struct-schema]
  IExplain
  (explain [this value] (first (struct/validate value struct-schema))))
results in
24 | (defrecord ExplainStruct [struct-schema]
-------^------------------------------------------------------------------------
 Cannot infer target type in expression (. (. ExplainStruct -prototype) -my-app$lib$forms$IExplain$)
--------------------------------------------------------------------------------
  25 |   IExplain
  26 |   (explain [this value] (first (struct/validate value struct-schema))))

thheller11:12:58

can you run shadow-cljs clj-repl and then (require 'shadow.build.cljs-hacks :reload) and compile again?

thheller11:12:31

sometimes it seems that the hacks aren’t loaded properly

thheller11:12:44

or rather overwritten somewhere else

mhuebert11:12:33

k let me check, i have to start the process over w/o cache

thheller11:12:34

I need to clean up those hacks so I can make proper patches for CLJS

thheller11:12:13

I’m confused how they warnings go away with cache since any warning should prevent the cache from being written in the first place

thheller11:12:54

sente does some weird elide-require stuff but besides that nothing that should interfere with the compile

thheller11:12:10

but yeah it doesn’t seem to be related to sente anyways if you see it in your lib

mhuebert11:12:11

ok so i have 1) started a shadow server, 2) started a watch process, and I see all the warnings. Then I 3) did the clj-repl command above, and 4) edited a file to trigger the watch. Now the warnings are gone.

thheller11:12:59

yeah thats behaviour I see when working on shadow-cljs itself. just never saw it when using it as a lib.

thheller11:12:11

guess I need to figure out whats happening

thheller11:12:27

or find another way to hack the compiler 😛

thheller11:12:36

the (in-ns 'cljs.analyzer) always felt like it could break any time

thheller12:12:39

@mhuebert found it, fixed in [email protected]. cljs.core was force-loaded after the hacks so it was overwriting them again.

mhuebert12:12:16

:thumbsup: works in my build

davidst13:12:12

@thheller shadow-cljs emits an undeclared var warning for letfn forms if the bindings are not in the right order

davidst13:12:53

according to the docstring the names in letfn should be available to all definitions

davidst13:12:36

So it looks like a shadow-cljs issue

thheller14:12:19

odd. didn’t know that letfn allows this behaviour. will look into it