This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-08
Channels
- # announcements (8)
- # babashka (11)
- # beginners (63)
- # calva (1)
- # chlorine-clover (1)
- # cider (18)
- # cljfx (4)
- # cljs-dev (18)
- # clojure (17)
- # clojure-europe (20)
- # clojure-spec (2)
- # conjure (2)
- # data-science (6)
- # datomic (7)
- # depstar (17)
- # etaoin (2)
- # events (2)
- # fulcro (28)
- # graalvm (2)
- # graphql (3)
- # jobs-discuss (5)
- # off-topic (18)
- # pedestal (5)
- # reagent (6)
- # reveal (2)
- # shadow-cljs (39)
- # spacemacs (7)
- # xtdb (13)
I’ve updated these tests with 4 cases - https://github.com/clojure/clojurescript/compare/master...mhuebert:cljc-macros-require-test
observed behaviour:
• failure (expected): a cljc macro namespace :require
’s another namespace containing macros, which does not “self-require”. when the macro is used, there is no resolve warning & the macro function is called without arguments being correctly passed to it (see wrap-1
). Seems reasonable that this does not work - the compiler has no way to know that the ns has macros, unless :require-macros
is called somewhere, so a $macros
ns is never created. though perhaps should warn?
• failure (bug?): a cljc macro namespace :require-macro
’s another namespace containing macros. consuming the macro always fails, does not matter if the other ns self-requires. (see wrap-2
). error occurs when trying to resolve the alias.. does namespace resolution in syntax-quote follow :require-macros
aliases? this may be a bug?
• success: a cljc macro namespace :require
’s another namespace, which self-requires. (see wrap-3
, and wrap-4
for a variant with both cljs + cljc files)
additionally it looks like alias resolution fails in more cases in shadow’s bootstrap build (cc @U05224H0W) - I added a couple failing examples here, including the issue with reagent macros: https://github.com/mhuebert/shadow-bootstrap-example/blob/1d5cadbb013660b4e0bea80a8ee9ea4a544ec2ab/src/shadow_eval/core.cljs#L32
@mhuebert the tests you are doing all start at the same time so they are all racing against each other. you need to ensure that one eval completes before the next one runs. at least that would eliminate some of the randomness?
so depending on when they go async or even if they go async the order they complete in is more or less random
at least thats what looks suspicious to me about the tests. whether or not that actually affects anything I do not know but the async behaviour is "bad"
Right, but the order shouldn’t matter if operating on different namespaces, or otherwise not interacting? I just based it on how the cljs self host tests are set up
well at least from a theory perspective I can see how one eval
sees that a namespace is not yet loaded and kicks off the async load. the next eval
does the same ending up in loading the namespace twice and so on
I’ve updated them all to be in their own deftest w/ async - https://github.com/clojure/clojurescript/compare/master...mhuebert:cljc-macros-require-test#diff-7144cb9420ccfd2b33c6c96777c668bba2046694d2431c231d67357fc15008efR861