[akka-user] Re: Why does FlexiMerge mandate same type on all inlets?
Hi Joe
I followed your instructions and got it to compile (hoping it will run as
well). Thank you very much!
For others reading this, I have updated the gist with a new file
https://gist.github.com/magnusart/0802295c0fafdf9b5028.
But I did not quite follow along on statement:
(A simpler alternative is to put a separate map in front of each input
from a = Left(a) and b = Right(b), then a simple MergePreferred will
suffice)
Could you please expand a bit more on what you would do and where you would
map?
/Magnus
Den onsdag 15 juli 2015 kl. 00:27:32 UTC+2 skrev Joe Edwards:
Inlets are naturally Contravariant (an inlet that reads A can be viewed as
an inlet that reads B : A), but that breaks down slightly when you're
viewing it 'from the other side' - as the Outlet of something else. Perhaps
there should be a view of the Inlet which can be used in a merge which is
actually covariant, IDK.
You can, however, work around it by ignoring that little detail:
State[Any](ReadPreferred[Nothing](p.right,
p.left).asInstanceOf[ReadPreferred[Any]]) { ...
Since Nothing is a common subclass of everything, the contravariance
allows you to construct the ReadPreferred[Nothing]. Then you can just cast
it to a ReadPreferred[Any] - Type Erasure means it will cast successfully
(at runtime)!
The main danger here is that something in the implementation changes and
this sort of thing might give you a runtime exception somewhere inside the
FlexiMergeImpl. Luckily the current implementation will not.
The other thing you should note is that L R are also erased by Type
Erasure, so if you want to match on them you'll need to have a ClassTag in
scope (e.g. [L : ClassTag, R : ClassTag])
(A simpler alternative is to put a separate map in front of each input
from a = Left(a) and b = Right(b), then a simple MergePreferred will
suffice)
On Tuesday, 14 July 2015 16:58:12 UTC+1, Magnus Andersson wrote:
Sorry, post button pressed by mistake.
Continued:
FlexiMerge only seems to be able to handle inlets of the same type. I
wish to have a preferred merge that accepts two inputs, L and R and then
produce Either[L,R]. I would use the read preferred.
Why this limitation and how can I work around it? I have created a gist
that illustrates my problem
https://gist.github.com/magnusart/0802295c0fafdf9b5028.
Any suggestions appreciated!
/Magnus
Den tisdag 14 juli 2015 kl. 17:54:23 UTC+2 skrev Magnus Andersson:
Hi
I'm trying to build an EitherRoute and EitherMerge flows.
I've completed the EitherRoute which has one inlet that accepts
Either[L,R] and two outlets that produces either L or R.
When I'm constructing the EitherMerge I run into problems.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Why does FlexiMerge mandate same type on all inlets?
Aha, I see. Thank you, I need to give this a try as well.
I have been following the documentation on the homepage which had it split
up by shape and inheriting FlexiRoute/Merge. I see I still have a lot of
stuff left to learn :)
/Magnus
Den torsdag 16 juli 2015 kl. 00:09:43 UTC+2 skrev Joe Edwards:
You could build it out of 3 more standard pieces by doing:
def eitherMerge[L, R]: Graph[FanInShape2[L, R, Either[L, R]], Unit] =
FlowGraph.partial() { implicit builder =
import FlowGraph.Implicits._
val left = builder.add(Flow[L].map(Left.apply))
val right = builder.add(Flow[R].map(Right.apply))
val merge = builder.add(MergePreferred[Either[L, R]](1))
left ~ merge.in(0)
right ~ merge.preferred
new FanInShape2(left.inlet, right.inlet, merge.out)
}
If you still wanted to use your custom shape you can also do so (to give
the inlets custom names)
On Wednesday, 15 July 2015 18:40:08 UTC+1, Magnus Andersson wrote:
Hi Joe
I followed your instructions and got it to compile (hoping it will run as
well). Thank you very much!
For others reading this, I have updated the gist with a new file
https://gist.github.com/magnusart/0802295c0fafdf9b5028.
But I did not quite follow along on statement:
(A simpler alternative is to put a separate map in front of each input
from a = Left(a) and b = Right(b), then a simple MergePreferred will
suffice)
Could you please expand a bit more on what you would do and where you
would map?
/Magnus
Den onsdag 15 juli 2015 kl. 00:27:32 UTC+2 skrev Joe Edwards:
Inlets are naturally Contravariant (an inlet that reads A can be viewed
as an inlet that reads B : A), but that breaks down slightly when you're
viewing it 'from the other side' - as the Outlet of something else. Perhaps
there should be a view of the Inlet which can be used in a merge which is
actually covariant, IDK.
You can, however, work around it by ignoring that little detail:
State[Any](ReadPreferred[Nothing](p.right,
p.left).asInstanceOf[ReadPreferred[Any]]) { ...
Since Nothing is a common subclass of everything, the contravariance
allows you to construct the ReadPreferred[Nothing]. Then you can just cast
it to a ReadPreferred[Any] - Type Erasure means it will cast successfully
(at runtime)!
The main danger here is that something in the implementation changes and
this sort of thing might give you a runtime exception somewhere inside the
FlexiMergeImpl. Luckily the current implementation will not.
The other thing you should note is that L R are also erased by Type
Erasure, so if you want to match on them you'll need to have a ClassTag in
scope (e.g. [L : ClassTag, R : ClassTag])
(A simpler alternative is to put a separate map in front of each input
from a = Left(a) and b = Right(b), then a simple MergePreferred will
suffice)
On Tuesday, 14 July 2015 16:58:12 UTC+1, Magnus Andersson wrote:
Sorry, post button pressed by mistake.
Continued:
FlexiMerge only seems to be able to handle inlets of the same type. I
wish to have a preferred merge that accepts two inputs, L and R and then
produce Either[L,R]. I would use the read preferred.
Why this limitation and how can I work around it? I have created a gist
that illustrates my problem
https://gist.github.com/magnusart/0802295c0fafdf9b5028.
Any suggestions appreciated!
/Magnus
Den tisdag 14 juli 2015 kl. 17:54:23 UTC+2 skrev Magnus Andersson:
Hi
I'm trying to build an EitherRoute and EitherMerge flows.
I've completed the EitherRoute which has one inlet that accepts
Either[L,R] and two outlets that produces either L or R.
When I'm constructing the EitherMerge I run into problems.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Why does FlexiMerge mandate same type on all inlets?
You could build it out of 3 more standard pieces by doing:
def eitherMerge[L, R]: Graph[FanInShape2[L, R, Either[L, R]], Unit] =
FlowGraph.partial() { implicit builder =
import FlowGraph.Implicits._
val left = builder.add(Flow[L].map(Left.apply))
val right = builder.add(Flow[R].map(Right.apply))
val merge = builder.add(MergePreferred[Either[L, R]](1))
left ~ merge.in(0)
right ~ merge.preferred
new FanInShape2(left.inlet, right.inlet, merge.out)
}
If you still wanted to use your custom shape you can also do so (to give
the inlets custom names)
On Wednesday, 15 July 2015 18:40:08 UTC+1, Magnus Andersson wrote:
Hi Joe
I followed your instructions and got it to compile (hoping it will run as
well). Thank you very much!
For others reading this, I have updated the gist with a new file
https://gist.github.com/magnusart/0802295c0fafdf9b5028.
But I did not quite follow along on statement:
(A simpler alternative is to put a separate map in front of each input
from a = Left(a) and b = Right(b), then a simple MergePreferred will
suffice)
Could you please expand a bit more on what you would do and where you
would map?
/Magnus
Den onsdag 15 juli 2015 kl. 00:27:32 UTC+2 skrev Joe Edwards:
Inlets are naturally Contravariant (an inlet that reads A can be viewed
as an inlet that reads B : A), but that breaks down slightly when you're
viewing it 'from the other side' - as the Outlet of something else. Perhaps
there should be a view of the Inlet which can be used in a merge which is
actually covariant, IDK.
You can, however, work around it by ignoring that little detail:
State[Any](ReadPreferred[Nothing](p.right,
p.left).asInstanceOf[ReadPreferred[Any]]) { ...
Since Nothing is a common subclass of everything, the contravariance
allows you to construct the ReadPreferred[Nothing]. Then you can just cast
it to a ReadPreferred[Any] - Type Erasure means it will cast successfully
(at runtime)!
The main danger here is that something in the implementation changes and
this sort of thing might give you a runtime exception somewhere inside the
FlexiMergeImpl. Luckily the current implementation will not.
The other thing you should note is that L R are also erased by Type
Erasure, so if you want to match on them you'll need to have a ClassTag in
scope (e.g. [L : ClassTag, R : ClassTag])
(A simpler alternative is to put a separate map in front of each input
from a = Left(a) and b = Right(b), then a simple MergePreferred will
suffice)
On Tuesday, 14 July 2015 16:58:12 UTC+1, Magnus Andersson wrote:
Sorry, post button pressed by mistake.
Continued:
FlexiMerge only seems to be able to handle inlets of the same type. I
wish to have a preferred merge that accepts two inputs, L and R and then
produce Either[L,R]. I would use the read preferred.
Why this limitation and how can I work around it? I have created a gist
that illustrates my problem
https://gist.github.com/magnusart/0802295c0fafdf9b5028.
Any suggestions appreciated!
/Magnus
Den tisdag 14 juli 2015 kl. 17:54:23 UTC+2 skrev Magnus Andersson:
Hi
I'm trying to build an EitherRoute and EitherMerge flows.
I've completed the EitherRoute which has one inlet that accepts
Either[L,R] and two outlets that produces either L or R.
When I'm constructing the EitherMerge I run into problems.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Why does FlexiMerge mandate same type on all inlets?
Sorry, post button pressed by mistake. Continued: FlexiMerge only seems to be able to handle inlets of the same type. I wish to have a preferred merge that accepts two inputs, L and R and then produce Either[L,R]. I would use the read preferred. Why this limitation and how can I work around it? I have created a gist that illustrates my problem https://gist.github.com/magnusart/0802295c0fafdf9b5028. Any suggestions appreciated! /Magnus Den tisdag 14 juli 2015 kl. 17:54:23 UTC+2 skrev Magnus Andersson: Hi I'm trying to build an EitherRoute and EitherMerge flows. I've completed the EitherRoute which has one inlet that accepts Either[L,R] and two outlets that produces either L or R. When I'm constructing the EitherMerge I run into problems. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Why does FlexiMerge mandate same type on all inlets?
Inlets are naturally Contravariant (an inlet that reads A can be viewed as
an inlet that reads B : A), but that breaks down slightly when you're
viewing it 'from the other side' - as the Outlet of something else. Perhaps
there should be a view of the Inlet which can be used in a merge which is
actually covariant, IDK.
You can, however, work around it by ignoring that little detail:
State[Any](ReadPreferred[Nothing](p.right,
p.left).asInstanceOf[ReadPreferred[Any]]) { ...
Since Nothing is a common subclass of everything, the contravariance allows
you to construct the ReadPreferred[Nothing]. Then you can just cast it to a
ReadPreferred[Any] - Type Erasure means it will cast successfully (at
runtime)!
The main danger here is that something in the implementation changes and
this sort of thing might give you a runtime exception somewhere inside the
FlexiMergeImpl. Luckily the current implementation will not.
The other thing you should note is that L R are also erased by Type
Erasure, so if you want to match on them you'll need to have a ClassTag in
scope (e.g. [L : ClassTag, R : ClassTag])
(A simpler alternative is to put a separate map in front of each input from
a = Left(a) and b = Right(b), then a simple MergePreferred will suffice)
On Tuesday, 14 July 2015 16:58:12 UTC+1, Magnus Andersson wrote:
Sorry, post button pressed by mistake.
Continued:
FlexiMerge only seems to be able to handle inlets of the same type. I wish
to have a preferred merge that accepts two inputs, L and R and then produce
Either[L,R]. I would use the read preferred.
Why this limitation and how can I work around it? I have created a gist
that illustrates my problem
https://gist.github.com/magnusart/0802295c0fafdf9b5028.
Any suggestions appreciated!
/Magnus
Den tisdag 14 juli 2015 kl. 17:54:23 UTC+2 skrev Magnus Andersson:
Hi
I'm trying to build an EitherRoute and EitherMerge flows.
I've completed the EitherRoute which has one inlet that accepts
Either[L,R] and two outlets that produces either L or R.
When I'm constructing the EitherMerge I run into problems.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
