This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-30
Channels
- # announcements (8)
- # babashka (102)
- # beginners (312)
- # calva (9)
- # clj-kondo (9)
- # cljfx (7)
- # clojure (126)
- # clojure-europe (52)
- # clojure-nl (2)
- # clojure-norway (2)
- # clojure-spec (5)
- # clojure-uk (4)
- # clojurescript (13)
- # conjure (5)
- # cursive (5)
- # datalog (18)
- # datomic (8)
- # emacs (1)
- # events (3)
- # fulcro (16)
- # graphql (2)
- # gratitude (1)
- # helix (16)
- # inf-clojure (17)
- # introduce-yourself (9)
- # java (11)
- # lambdaisland (3)
- # leiningen (3)
- # lsp (8)
- # malli (3)
- # membrane (7)
- # missionary (26)
- # nextjournal (1)
- # off-topic (19)
- # pathom (3)
- # polylith (13)
- # portal (16)
- # reagent (39)
- # reitit (2)
- # releases (23)
- # remote-jobs (1)
- # shadow-cljs (40)
- # specter (3)
- # sql (12)
- # tools-deps (8)
- # tree-sitter (1)
- # vim (3)
- # web-security (6)
- # xtdb (16)
Hi @U0BBFDED7, could you share the snippets of it.. im so far never seen/goes to that error
signals and streams must be bound to a reactor instance, therefore they must be constructed in reaction to a reactor event. To create a new signal in reaction to an arbitrary event, the event producer itself must be a signal or a stream.
@leonoel I generally have this and it works, but in one particular case it crashes if I have sleep in ap
I noticed that js buildsize swells a lot after using missionary. Probably due to the macros in cloroutine. We wanted to replace core.async in production, which we have a problem with and which also swells. The problem is that missionary swells even more 🙃
is this normal behaviour and something to get used to, or is there a chance of improvement here?
> Probably due to the macros in cloroutine. Yes. code generated by cloroutine is verbose and probably not very closure compiler friendly > is this normal behaviour and something to get used to, or is there a chance of improvement here? The size increase is inevitable due to the additional machinery required, but I think there's room for improvement. Various optimizations could be added to cloroutine that could improve both runtime performance and code size, it's been low priority so far but I'm definitely interested moving in this direction
@U0BBFDED7 So we can understand, can you describe what exactly the problem you see in production with core.async js build size?
I.e. what exactly is the harm being done