Fork me on GitHub
#missionary
<
2022-03-30
>
ribelo01:03:08

using sleep inside ap sometimes results in an error not in reactor context

ribelo01:03:56

it's a bug, or something like that could be possible and acceptable?

reedho05:03:47

Hi @U0BBFDED7, could you share the snippets of it.. im so far never seen/goes to that error

ribelo07:03:03

this error pops up when you try to use signal / stream outside the reactive context

ribelo07:03:35

When I'm at the computer, I'll make a gist

leonoel09:03:54

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.

ribelo09:03:44

@leonoel I generally have this and it works, but in one particular case it crashes if I have sleep in ap

ribelo09:03:11

but I can't reproduce it on a smaller example, so I probably have a bug somewhere

ribelo10:03:00

it works, it's awesome, the problem as usual is on my side

reedho04:03:13

Hello every body, hello @dustingetz and @leonoel

👋 3
reedho05:03:35

Before hand, i would say thank you for creating missionary and co

reedho05:03:27

Its bean great for me amd help me understands more nuanced about asynchroni 🙏🙏🙏

leonoel09:03:58

Hello @reedho, welcome !

ribelo10:03:02

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 🙃

ribelo10:03:22

is this normal behaviour and something to get used to, or is there a chance of improvement here?

ribelo10:03:49

test source file is 90kb, after compilation it is 120kb

ribelo10:03:15

for comparison, using core.async increases the size to 100kb

ribelo10:03:54

and using pure js promises makes the resulting file only 60kb.

leonoel18:03:40

> 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

👍 1
Dustin Getz14:04:21

@U0BBFDED7 So we can understand, can you describe what exactly the problem you see in production with core.async js build size?

Dustin Getz14:04:33

I.e. what exactly is the harm being done

ribelo14:04:27

each use of go increases the buildsize by about 1kb

😮 2
ribelo14:04:09

we have used go 385 times in the project

ribelo14:04:24

and as for other things, missionary is much simpler to use, because of the way errors are propagated

ribelo14:04:26

clojurescript in general is not particularly buildsize friendly

ribelo14:04:57

especially lazy-seq, have to be careful to use transducers or reducers like mapv instead o map