3957cee · streamly · git.iko.soy

git.iko.soy/streamly

on master help sign in

fix output explanation of wAsyncly

3957ceeShruti_Umat6 years ago

CONTRIBUTING.md+2−2

@@ -193,7 +193,7 @@ mapM f (Stream step1 state1) = Stream step state

193```

194

195* For the input streams use numbering for `step` and `state` e.g.

196− step1/state1. For the ouput stream use `step` and `state`.

196+ step1/state1. For the output stream use `step` and `state`.

197* For state argument of `step`, use `st`.

198* For result of executing a `step` use `r` or `res`

199* For the yielded element use `x`

@@ -221,7 +221,7 @@ type inference minimal and type errors can be discovered incrementally by

221increasing the scope a little bit at a time. If you use type signatures on all

222top level declarations then you do not even need to comment out the code. This

223organization results in a better order of type errors which makes it easier to

224−fix them and when necessary use elimination method by commenting out some code.

224+fix them and when necessary, use elimination method by commenting out some code.

225

226Similarly when you put modules in the cabal file in dependency order you can

227do the same there, just comment out a tail of the module list and your library

src/Streamly/Internal/Data/Stream/Async.hs+1−1

@@ -870,7 +870,7 @@ wAsync = joinStreamVarAsync WAsyncVar

870-- every pass because one more @<>@ is broken down into two components. At this

871-- point there are no more @<>@ operations to be broken down further and the

872-- queue has reached its maximum size. Now these streams are scheduled in

873−-- round-robin fashion yielding @[2,7,5,3,8,8,9]@.

873+-- round-robin fashion yielding @[2,7,5,3,8,6,9]@.

874--

875-- As we see above, in a right associated expression composed with @<>@, only

876-- one @<>@ operation is broken down into two components in one execution,