dolio 2017-02-20 09:45:09
Looks like --cpp-options=... is an accepted cabal flag.
dolio 2017-02-20 09:45:22
And should add to the cpp-options from the file.
sternmull 2017-02-20 10:24:26
i have to read from two handles, wrap their data into messages and write that messages to a third handle. At the moment i use two threads to read the handles. How do i synchronize writes to the third handle? Are two reader threads a good idea at all?
merijn 2017-02-20 10:26:12
two threads seems fine
geekosaur 2017-02-20 10:26:19
multiple reader threads and a TChan to send the resulting message packets to the third?
merijn 2017-02-20 10:26:31
^^ that, except I'd probably use Chan
Tuplanolla 2017-02-20 10:26:57
You probably want a bounded channel here, merijn.
geekosaur 2017-02-20 10:27:13
depends on the data flow
merijn 2017-02-20 10:27:30
Tuplanolla: True
sternmull 2017-02-20 10:27:41
i thought about using a channel. But then i have a third thread that processes the message and has to stop when both readers are done. I hoped it could be solved less complicated.
geekosaur 2017-02-20 10:28:00
and in particular, precisely *how* it gets bounded depends on the data flow and the application requirements. for video streaming, you drop stuff; for some other uses, you block the readers...
merijn 2017-02-20 10:28:10
Which is why I was working on a closable version of Chan (well, actually, it's mostly done, I just need to write benchmarks)
merijn 2017-02-20 10:28:29
Unfortunately, that means first fixing criterion, because as-is it's not good enough :\
merijn 2017-02-20 10:28:36
Hence why I keep postponing it :p
geekosaur 2017-02-20 10:28:38
sternmull, so you define the message data as data Message = Done | Data yourData
geekosaur 2017-02-20 10:28:52
(first cut...)
sternmull 2017-02-20 10:31:59
geekosaur: yes something like that. And the writer has to count the Done messages it has seen and finish at the last one... ok.
geekosaur 2017-02-20 10:32:02
you can also have the Done message include a sender id and track until you've seen all senders
Tuplanolla 2017-02-20 10:32:05
Do the read threads quit when they're done, sternmull?
sternmull 2017-02-20 10:33:09
Tuplanolla: Yes they do.
geekosaur 2017-02-20 10:33:09
(which has the potential advantage that you can add more threads and have it autoadapt instead of having to change a hardcoded count)
Tuplanolla 2017-02-20 10:33:09
Another option presents itself: link the threads via exceptions.
Tuplanolla 2017-02-20 10:33:09
@hackage async
lambdabot 2017-02-20 10:33:09
http://hackage.haskell.org/package/async
sternmull 2017-02-20 10:33:09
geekosaur: There should be no need for more threads. I want to read stdout and stderr from a process and multiplex that to a TCP stream. Date should be stuff like log output and compiler messages. So no need for super high performance. Easy implementation is more important right now :)
merijn 2017-02-20 10:33:14
Tuplanolla: For some workflows (most I have) that doesn't work out so nicely
geekosaur 2017-02-20 10:33:16
that's why I said "potential"
Tuplanolla 2017-02-20 10:33:39
Not all options are good options!
Benzi-Junior 2017-02-20 10:33:39
does anyone here know where the implementations for vector tuples are defined ?
sternmull 2017-02-20 10:33:39
Tuplanolla: I already found async and happily use it to wait for the two readers.
Benzi-Junior 2017-02-20 10:36:32
alternatively is there a way to look up instance declarations on hackage or with hoogle ?
