Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2018-05-31

Channels

#core-async
<
2018-05-31
>
Logan Powell11:05:18

@clark Thank you for your offer to help. I think I'm figuring it out, but slowly 🙂

Logan Powell11:05:48

let me know if there's a better way to present this that doesn't create a neverending loop

Logan Powell14:05:20

are go blocks not lazy?

Logan Powell14:05:19

should I use put!s instead?

Logan Powell14:05:49

put! doesn't seem to cut it

Logan Powell14:05:01

glitch_crab Sorry, I used def not defn 😛

Logan Powell14:05:55

woah, my mind is exploding over here :shocked_face_with_exploding_head: If anyone can help me wrap my head around why put!'ing to a chan when it's in motion seems to restart the process, I plan on publishing this stuff to the intertubes for posterity: https://github.com/loganpowell/cljs-guides/blob/master/src/core-async/guide-core-async.md#control-flow-with-alts

bjr14:05:32

the single-! variants of <! and >! are generally called parking takes and puts

bjr14:05:42

I think this refers to them as synchronous takes/puts

Logan Powell14:05:41

will correct, thanks!

bjr14:05:30

i think it’s important to think about these operations in terms of parking vs blocking. go being a macro for wrapping parking operations. threads, which all code is executed in, are the context for blocking operations, so nothing special is needed to use blocking operations.

Logan Powell14:05:54

so, I can clarify that "parking" enables ClojureScript users to use "blocking" syntax?

bjr14:05:09

not really…

Logan Powell14:05:19

that's what I thought

bjr14:05:24

clojurescript (javascript) does not have threads

bjr14:05:32

so there is no true asynchrony (for the most part)

Logan Powell14:05:01

can you elaborate on "no true asynchrony"?

bjr14:05:15

2 computations cannot happen at the exact same time

bjr14:05:43

it’s the concurrency != parallelism thing

Logan Powell15:05:05

right, is that why my put!s are restarting the process?

bjr15:05:18

i’m not sure what you mean by restarting the process

Logan Powell15:05:04

thank you for that, yes, I'm - slightly - in tune with the difference there...

bjr15:05:13

can you post an example of how you are using put!?

Logan Powell15:05:31

the two different logs

Logan Powell15:05:03

I'm trying to put! to a running chan

Logan Powell15:05:22

and it like quadruples its output size

bjr15:05:26

what do you mean by running chan? what is a not-running chan?

bjr15:05:14

apologize if i’m being pedantic, but i want to avoid us talking past each other

bjr15:05:41

so calling timeout-chan starts a process which is supposed to run for 5000ms

bjr15:05:21

but it also starts 3 other processes which infinitely put messages on port

bjr15:05:44

so port will accumulate those puts long after the go-loop process completes

Logan Powell15:05:22

so, they're not "waking up" again, but they're just loaded in the port?

bjr15:05:02

the 2 examples are not the same

bjr15:05:32

what are you trying to show by calling (put! test-chan "OUTSIDE")?

Logan Powell15:05:00

no, but if if just eval the (timeout-chan test-chan) it logs the same as the (let.. (go..

Logan Powell15:05:15

I'm trying to show how to interact with the channel from the "outside"

bjr15:05:29

which channel are you trying to interact with?

Logan Powell15:05:36

say from an api

bjr15:05:48

the one returned by timeout-chan, which is created by the go-loop?

Logan Powell15:05:58

the test-chan in the example

Logan Powell15:05:13

I'm using the timeout inside of the timeout-chan as an alts! control trigger

Logan Powell15:05:51

to stop the go-loop

bjr15:05:57

I think there are simpler ways to show this

bjr15:05:10

staying with this code

Logan Powell15:05:14

please 🙏 😄

bjr15:05:35

i bet you’re dealing with a race condition

Logan Powell15:05:44

I think it might also help others to see these idiosyncrasies

bjr15:05:53

sometimes the go-loop is parked on the call to (<! port)

bjr15:05:07

sometimes it’s parked on (alts! [port tmt])

bjr15:05:20

you don’t actually want that (<! port) call

bjr15:05:23

I don’t quite understand it

bjr15:05:35

you’ve already taken a value from port using alts!

Logan Powell15:05:21

can you explain what you mean by sometimes it's parked on the call to (<! port)?

bjr15:05:34

what does that call do when port has no pending puts?

Logan Powell15:05:55

let me think about what your asking...

bjr15:05:10

in general when demonstrating anything async you probably want to avoid timeouts — and anything time-dependent. you want things as controlled as possible. so separate trigger channels acting like “gates” are usually a fine choice.

bjr15:05:22

but i know that’s sometimes less realistic

bjr15:05:24

👍

Logan Powell15:05:50

k, let me marinate on this convo 😉

👍 4