I have been exploring core.async And tried to implement : gophers daisy chain whispering from here https://www.youtube.com/watch?v=f6kdp27TYZs&t=1600

this is what I have come up with

lein run is not printing the final value from the channel and is permanently stuck

doseq returns nil

what about println?

oh wait your println is in a weird place, never mind

haha

i am very new to this language

putting gopher-talk inside go is pointless

all it does is block a go block - for zero benefit

should i use future

because i tried that too

no, use put!, that's what it's for

why is this not working?

this isn't the cause of your problem, it's just a random problem with the code

not sure yet,still reading

is the go thread pool exhausted?

because I read some where that : go thread pool = # cores + 2

you could be doing that yes, because you are doing blocking ops inside go

@diginomad can you back up for a moment and describe the problem statement? like, what's supposed to happen? I see the youtube presentation but I don't know the go language. describe what should happen

I am expecting a value of 3 to be printed

@diginomad yeah, if N is high enough that code is guaranteed to deadlock

that's what you expect to happen, but that's not describing what should happen in order to produce that result. more detail on the process?

you mean,my logic?

i think i see now -- but maybe it will help you to talk it out too, so go ahead 🙂

So,let is creating two initial channels left,right

putting 1 on right

in that loop i will do - left <- right;right = left ; left = new channel

basically the function call does left <- right;left+1

I made them as atoms as their state has to be changed every loop

i didin't know any other option than that

so, each {left <- right;right = left ; left = new channel} is supposed to be in a new "thread"

sorry

{left<-right;left = left+1} has to be in a new thread

@diginomad I added one more println, it stalls on the blocking read inside the println at the end

sorry if I am making no sense

the channel is empty so it blocks

i don't see it in the code why final channel is empty

does it have to do with reset! ?

I just checked, after thedoseq is done both right and left are empty

left is empty surely

I wouldnt' say surely anything about this code, it's weird

but why right,as i am resetting it to a channel which just had some stuff put in by gopher-talk

ya,it felt the same

but I couldn't uncomplicate it

with my limited knowledge

because it has to read another channel, and you are doing channel reads of both channels before writing to either

there's no code path that writes without reading first, so it's a deadlock

since nobody can possibly read

wait... no, right should be readable...

this issue aside

can i create go blocks in a loop?

@diginomad OK I added a println to gopher-talk - the doseq is exiting before gopher talk finishes its channel write

yes, you can

okay

but don't call functions that use >!! inside a go block

i have a solution, if you'd like to see it @diginomad

sure @joshjones

or, you can try some more

i tried to go from what you have, but the atoms and structure threw me off so i just started it from scratch

okay

without atoms then?

yes, any time atoms are created local within a function it's a strange thing to see

okay,how to deal with changing states inside a function?

it could be a lot better but it's an initial 10-minute solution 😉

(defn gopher-talk [right left]
  (go
    (>! left (inc (<! right)))))

(defn gophers-daisy-chain [n]
  (let [leftmost (chan 1)
        rightmost (chan 1)]
    (put! rightmost 0)
    (loop [right rightmost
           left (chan 1)
           i 0]
      (if (= i n)
        (gopher-talk right leftmost)
        (do
          (gopher-talk right left)
          (recur left
                 (chan 1)
                 (inc i)))))
    (<!! leftmost)))

using local let bindings i mean

@joshjones - nice translation

thx, I could not understand the go language code but i think the idea is the same

@diginomad generally we prefer to substitute mutation with recursion setting new immutable bindings

both function arguments and let bindings are immutable

got the code,nice one josh

(and loop bindings)

the thing is,I tried to do stuff exacyly like in video

but,i still can't understand why my code won't work entirely

@diginomad (recur new-x new-y) in a loop is equivalent to resetting x and y

notice that @joshjones also replaced your blocking channel ops with parking ones

its weird actually

because Clojure doesn't allow (go (>!! ) )

yes @noisesmith -- actually, if you change the parking puts and takes in gopher-talk with blocking ones, it does not work

but it allows when in a function like here

right, >!! is not meant for use in go blocks, >! is

yes

almost @diginomad -- it allows >!! in a go block, but does not allow >! outside a go block

ohh,okay

@diginomad also you can change all your calls to chan in your original with (chan 1) and that makes the original work

core.async chans are nonbuffered by default, and that code stalls without buffering

but use loop and rebinding and >! inside go blocks like in @joshjones example anyway, that's the right way to do it in clojure

@noisesmith okay

and also, is it a bad practice to use any of the refs like atoms in let bindings?

it's just weird

better to avoid if possible (though not always possible, it usually is)

@diginomad if you take your original example and make gopher-talk contain the go block, and change the >!! to >! and the <!! to <!, you get interesting results --

(gophers-daisy-chain 50)
45
=> nil
(gophers-daisy-chain 50)
47
=> nil
(gophers-daisy-chain 50)
50

atoms are for stateful things that are modified from more than one thread, usually

@diginomad I can't say I've ever seen an atom in production clojure code in a let binding -- would definitely say it's bad practice

i have been using it pretty frequently

will note that

i found it was weird when I used atoms inside map

that was a horrible debugging time

yeah, atoms and laziness are a bad mix

once you shift your thinking from variable assignment to evaluation of expressions, and buy the whole "values are values, and they don't change" approach, you have to really try to find opportunities to use atoms -- they just don't come up that often

and your race condition as shown above is a perfect example of why mutable state is just an impediment to everyday development. problems are hard enough to solve without involving state

great point that!

will practice harder then

it's a (relatively) simple matter of looking at idiomatic code and beginning to model those best practices in your own code, and writing it often enough for it to become habit

true

but i have been solving only some HackerRank problems

not sure if that will improve my Clojure idiomatic style

suggestions?

I don't actually know what hackerrank problems look like -- if only your solution matters, or ...?

yes,only solutions matter

for exercises, there's http://4clojure.com where you can see other people's solutions

thanks for the suggestion @noisesmith

thanks guys @joshjones @noisesmith

that was helpful

hope you guys found it interesting too

yes sir, best of luck and see you around

🙂

I think here’s the same thing (daisy chain) in core.async and manifold - https://github.com/dm3/manifold-cljs/blob/master/examples/src/manifold_test/daisy.cljs

@diginomad I just rewrote this, the way I initially wanted to. much shorter, and more or less clear, depending on your familiarity with functions like partition

(defn gopher-talk [right left]
  (go (>! left (inc (<! right)))))

(defn gophers-daisy-chain [n]
  (let [rightmost (chan 1)
        leftmost (chan 1)
        chans (concat [rightmost] (repeatedly n #(chan 1)) [leftmost])
        chan-pairs (partition 2 1 chans)]
    (run! (fn [[r l]] (gopher-talk r l)) chan-pairs)
    (put! rightmost 0)
    (<!! leftmost)))

why is this idiomatic than your initial solution?

*more idiomatic

I wouldn't say it's more idiomatic necessarily, but it does avoid the explicit loops, and the idea is more simple: create pairs of side-by-side channels, link them up, and you're done

there's not as much of the notion of "the previous right gopher is now the left gopher" -- just thinks of them in pairs

sweet

got to know what run! is

it's map without the return value or the alternate arities

(or the laziness)

it's relatively new (1.7) so it's not as common but it should be used in place of (doall (map ... in cases like this

the real alternative is dorun on map

but yes, run! is better 😄

right good call

for,doseq === map,run!?

pretty much yeah

have a good afternoon/evening/morning all, i'm off to enjoy the sunshine while it lasts here 🙂

using the same logic as above but with this function

it prints the value

but is not terminating the program

had to kill it

what could be the reason?

need to call shutdown-agents in your -main function. explained here: https://clojure.org/guides/faq#agent_shutdown @diginomad

@diginomad FWIW futures will fail for large n, not a good use case here. you were probably just trying things, but wanted to mention