@malcolmsparks: did you manage to replicate the problem i was having ?

no, I haven't: this test passes on -5 😞

https://www.refheap.com/108915

all I changed was (generate-string) to (str) , because I didn't have the source to (generate-string)

ah, now I've replicated it:

https://www.refheap.com/108916

@mccraigmccraig: hi there, I think I've got to the bottom of the issue

I've changed your chain-delay-deferred to the following:

clojure
(defn chain-delay-deferred
  [n t]
  (let [f (d/deferred)]
    (future (Thread/sleep t) (d/success! f 100))
    (let [sum (reduce (fn [d i] (d/chain d (fn [v] (+ v i))))
                      f
                      (range 0 n))]
      (d/chain sum
               (fn [v]
                 @(d/future (Thread/sleep 10) (str v)))))))

note the deref on the last line

yep... hmm. i'll have to have another look... presumably that last deref is just adding in a delay, so maybe you can get rid of most of chain-delay-deferred and replace it with (d/chain (d/success-deferred 10) (fn [v] (future (Thread/sleep 10) (str v))))

i'm getting deeper into this

it's a bit weird

I'm on working on tag -5

it works if I remove all but the invoke-method interceptor

it only hangs if there's at least one interceptor before the invoke-method interceptor AND (at least) one after it. I'm trying to reduce down to a hanging test using only manifold

I was going to suggest that I thought the problem is that your d/chain (itself a deferred) was returning a deferred in the last link of the chain

but after some testing, I've discovered that's perfectly ok with manifold

but just not in the context of yada, which is a rather contorted manifold structure - they'll be a reason, I just can't find it yet!

well, i guess i'm happy you've managed to replicate !

despite this issue, I am gaining further respect for manifold, it really is flexible and lets you exploit async without thinking too hard - @ztellman did a great job

yeah, i've been really happy with it - in combo with a cats monad on top of it i've been building what would otherwise be insanely complex chains, and they are very straightforward to grok and work with

have you any links to the cats monad stuff I can read up on?

there's this, which is out of date and referring to core.async rather than manifold - https://github.com/funcool/canal

but the idea is the same

there's probably not that much difference between using the d/chain and monad approach ... i was already using the monad for error-handling elsewhere though, so i went with that

in other news, if you forgive the aside, I've been playing with yada a bit - I've noticed that the result of yada/handler (which is aliased as yada/yada now), is a record, that itself can be fed into yada - if you want to expose the metadata of the handler as a REST service

so you could do this

(-> "Hello World!" yada yada)

or even

(-> "Hello World!" yada yada yada)

what fun

lol irl here

'cos i knew what you were going to type for the second example there

i've been having a pretty good time with yada and re-frame... it all feels like webapps done, if not completely right, then pretty close

yes, i've been having a lot of fun with re-frame too, it's a wonderful thing -

I'm building a yada console with material design classes and re-frame to inspect and analyse/debug yada calls

It's also nice to be able to use yada in a real system

and experiment with the possibilities

that sounds pretty cool !

it's early days, but I think if I'm asking people to trade in their Ring middleware for yada, the least I can do is to provide a decent debug experience when things go awry

it won't do any harm... but swagger, extraction and coercion of params, async, representations, auth and spec conformance are killer features too

well, I'm sure it's possible to 'lift' Ring middleware into a manifold chain, so it might not be a case of yada and Ring middleware being mutually exclusive -

I've got a todo item somewhere to investigate that

I'm thinking of things like prone, rather than the Ring middleware that tries to do http-like things like wrap-head and wrap-last-modified, which are pretty broken because they don't reduce any load on the server in their implementations

oh, i hadn't seen prone - that looks awesome

thx for the kind feedback too btw

yeah prone is very nice

it's partly what influenced me to build this yada console thing

prone has the request context, the response, any errors, etc. but a yada console gets to show available methods/representations, content-negotiation scores, interceptors invoked, and a whole lot more besides

data is king

not forgetting of course that a yada resource is itself a rich data structure, it's not just a Ring handler

ok, i'm going to have another stab at your bug

right - progress: https://www.refheap.com/108922

the problem is due to yada's construction of a manifold chain via clojure.core/apply

I'd like to invite @ztellman here to see if he has any thoughts

(I don't know what the netiquette of summoning people to slack channels is, I hope Zach doesn't mind)

going back to simplify further

ah, i see - perhaps use reduce rather than apply then : https://www.refheap.com/108923

?

you're a genius, that works!

I've raised https://github.com/ztellman/manifold/issues/50 against manifold

what’s up?

sorry, accepted the invite and then spaced out

hi zach! just been puzzled by a little issue in our use of manifold

i've raised #50 to show some examples

ok, taking a look now

we have a workaround (using reduce rather than apply)

but from something you warned me about before, I'm concerned reduce might have a performance impact - my chain is about a dozen long

hmmm

what version, btw?

[manifold "0.1.0"]

i encountered the problem on 1.1.0-alpha3, since i overrode yada's dep

we can definitely upgrade manifold if that helps

oops 0.1.1-alpha3

ah, sorry @mccraigmccraig you tried that already

so if you just call (chain a b c) that does an inline expansion

i've been trying to simplify the examples as far as possible, the bug only shows itself in certain configurations

if you do (apply chain [a b c]) that calls the non-inlined form

this suggests a bug in my non-inlined form

which I will now look into

potentially I don't know upfront the interceptor chain, I need the dynamic version...

right, and that should work perfectly fine

nothing wrong with your approach, just (apparently) with my code

though I do appear to be testing this behavior: https://github.com/ztellman/manifold/blob/master/test/manifold/deferred_test.clj#L71-L82

if you look at #50, you'll see that tinkering around with the inclusion of identity in the chain makes a difference -it's not just a problem with apply in isolation

ok, replacing chain with chain’ on the hanging example also fixes it

oh!

chain' ?

oh, the arg count might make a difference here, I didn't spot that

ok, just pushed a fix, now to cut a version

oh cool

I’m going to try to figure out why my existing tests didn’t catch this

that’s still a bit mysterious

what is being coerced here? what's the difference between chain and chain' - I'm struggling a bit

oh, ok

so chain’ is the faster cousin of chain, because instead of checking if a value is either a deferred or can be coerced to a deferred, it only checks if it’s a deferred

they have entirely disjoint implementations

chain’ didn’t have the implementation error

so clojure.core/future is not a deferred but can be coerced to one?

correct

but you were using d/future, which does return a deferred

so chain’ would have been the “optimal” thing to use

ok, i'll need the slow version I think - I think I need to let my users return clojure.core futures and promises

yeah, again, nothing wrong with anything you’re doing

this is all on me

unless I can coerce on the user boundary and internally use manifold defereds exclusively, then I'll get some boost with chain' right?

great - thanks Zach - I'll switch to the bugfix release when it's ready

yeah, you’ll get some small boost

I wouldn’t worry about it

ok, I'll bear it in mind when I start profiling

great, ok, figured out why the test didn’t catch it, either

one sec while I cut a release

oh great - glad you found that

glad we've found the issue because otherwise manifold has been working out really well - extremely easy to give to users

awesome

sorry for this, pretty silly oversight on my part

absolutely no problem - thanks so much for helping out and fixing

0.1.1-alpha4 is deployed

cool - I'll cut a new yada release now

Ran 39 tests containing 229 assertions. 0 failures, 0 errors.

yada likes the new manifold - am going to release

yada 1.0.0-20150828.201157-7 is deployed

w00t ... i'll try it out next time i'm allowed near a keyboard

try the 1.0.0-20150828.203727-8 release, I messed up

just tried the -8 release - no hangs 😄