Vadim

Sadly, this library doesn't do much outside of what is provided by the java.time API. This is the limitation of the `DateTimeFormatter`: ``` boot.user=> (java.time.LocalDate/parse "2017/05" (java.time.format.DateTimeFormatter/ofPattern "yyyy/MM")) java.time.DateTimeException: Unable...

I can imagine a feature that would harmonize the `Number* -> TemporalEntity` constructors with their `parse` counterparts. It should require a dynamic context set up before parsing, or a special...

Given this is a bug in new functionality, it won't break any previous uses. We'll get the fix when it's fixed upstream. Would be great if you could release this...

Actually, I wrote the following thing as a crutch: ``` clojure (defn- unwrap [stream] (loop [s stream] (cond (instance? manifold.stream.Callback s) (recur (first (.downstream s))) (instance? manifold.stream.SourceProxy s) (recur (.source...

This seems to be a problem with `loop/let-flow` macro interaction and `alt`. If you convert the example to the explicit CPS form, the `alt` works fine. You can use this...

Here's a testcase: ```clojure (deftest alt-letflow (let [a (d/deferred), b (d/deferred), result (atom nil)] #_(d/let-flow [x (d/alt a b)] (reset! result x)) (-> (d/alt a b) (d/chain #(reset! result %)))...

So, this happens because `let-flow` transforms not only its own binding, but also picks up any locals in its lexical scope. In the macroexpansion of the test-case above, `a` and...

I'd say it's an inconsistency. This stems from https://github.com/ztellman/manifold/blob/193f5f48972c8e20dd0a9fc41a1311566a9f7bdd/src/manifold/deferred.clj#L378 - when state of deferred is realized, the listener execution happens immediately on the thread which attaches the listener.

I took a stab at implementing error propagation, you can take a look in the [commit here](https://github.com/dm3/manifold/commit/149be2b68fd01688d0a4a0722be54074dcb5c7a3). The meat of the thing is the [propagate-error](https://github.com/dm3/manifold/commit/149be2b68fd01688d0a4a0722be54074dcb5c7a3#diff-8ebfbb6648d7498531b1e91320ab226fR310) function. I'm not sure about...

> Since put! and take! can yield errors, I'd rather have the error state surfaced there, rather than as a separate side-channel which people may or may not pay attention...