Async

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

Introduced a way to lift async into Process Monad.

We can try to push these patches upstream and include into d-p itself, but for now it's possible to use this package.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

Thanks for the comments. This PR is no longer relevant as as @mietek noticed it has incorrect semantics.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

I'd say easiness of support, if you don't think so then we can use our master as an feature branch.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

Ok for using a feature branch as the source for the PR when it gets submitted to official d-p. But who said our master has to match exactly official d-p's master? What's the point in that?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

I've created branch for out patchet, this branch will be used as a target in d-p, in order to keep master exactly in the same state as upstream master. Once patch is accepted, then we can make a PR to the upstream.

I've used this procedure for both my patch, and @facundominguez`s one.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

@qnikst why don't you just submit a PR against tweag/d-p? We can then submit that as a PR against official d-p.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

I have introduced a patch for d-p, so merge of this commit implies reviewing of the, https://github.com/tweag/distributed-process/commit/2c9105a9893d4d2e38a96178a32d96427c262c80 branch, before it may be submitted upstream.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

will do it now

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

The main reason why I did a package is that it may be easier to maintain, until instance will be merged. But I completely agree that it may worth adding.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

yes! Again, don't trust blindly what the Asana task says... Use your judgement, after thinking hard about it. If all we need is an instance, then we don't need a package. Even if we did need a package, the instance itself would probably still need to be folded in distributed-process, because orphan instances are bad.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

Should I make a PR and add it to our fork?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

I think if all this package is doing is defining an (orphan!) instance, then it has no reason to be. The instance should be folded in distributed-process, to avoid it being orphan. Note that doing so does not introduce a dependency on async, just monad-control.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

Ok...

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

Ahha, yes.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

Thanks, will fix, forgot to check every auto generated fields.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

Please let it live, it allows build systems avoid using cabal. But I'm OK with removing it.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

@mietek possibly, but the d-p-trans goes about it the other round. It doesn't redefine Process in terms of ProcessT, just introduces lifting mechanisms. So no ProcessT. Not sure yet what the best approach is there.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

Perhaps "This package provides IO operations from the async package lifted to the Process monad.", following lifted-async?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

Perhaps "Run asynchronous IO operations while using Cloud Haskell.", following lifted?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

We normally only include maintainer lines, and only then, after a public release. Author lines either say Xyratex Technology Limited or don't exist.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

Perhaps I misunderstood yesterday's scrum, then. Wasn't there something to be added with regard to distributed-process-trans?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

I thought having a Setup.hs was no recommended anymore...

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mboes

There is no such thing as ProcessT yet. It's a long standing feature request for distributed-process. Should we be worrying about it ahead of it even existing?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

Then perhaps s/we are introducing/we could introduce/.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

Debug purpose, should be removed, thanks.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

I understand this is pending an addition for ProcessT?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

Why is this commented-out code here?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

This is about different approach, that will be possible in case if a simple (current one) will not work for complicated cases.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: qnikst

If we will skip a lot of typos, then it says about another direction. I wanted to say that exceptions should be bidirectional, i.e. if process on remove side receives an exception then it should be propagated on the local side and vice-versa.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

I don't see this datatype in the source. Was this to be revised away from the RFC?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: mietek

Is this point saying the opposite of line 56?