In an effort to build an Haskell client library for the Firebase service
[0], which rely heavily on HTTP event source/server sent events [1], I am
looking for an HTTP client lib supporting this spec.
AFAIK, both WAI and yesod handle the mechanism server-side but nor
http-client, wreq or http-streams seem to provide the client counterpart.
Am I looking in the wrong direction?
SSE are basically '\n' separated yaml messages over a kept open http
response stream. I guess a seasoned Haskell dev could build a solution
quite easily but o couldn't find a way to keep the response stream opened.
Ideally a conduit/pipe sink exposing each message could be exposed for
further parsing and usage.
I'd be very glassful of someone could help me contribute such handling or
come up with a solution.
Thanks for your time,
Alexandre
[0] https://www.firebase.com/docs/rest/api/
[1] http://www.w3.org/TR/2011/WD-eventsource-20110208/
Le 29 avr. 2015 14:02,
My real problem is that I've got a list of points in R3 and want to decide if they determine a plane, meaning they are coplanar but not
colinear. Similarly, given a list of points in R2, I want to verify that they aren't colinear. Both of these can be done by converting the list of points to a matrix and finding the rank of the matrix, but I only use the rank function in the definitions of colinear and coplanar.
To compute the rank of a matrix,
perform elementary row operations
until the matrix is left in echelon form;
the number of nonzero rows remaining in
the reduced matrix is the rank.
(
http://www.cliffsnotes.com/math/algebra/linear-algebra/real-euclidean-vector...
)
A matrix is in row echelon form when it
satisfies the following conditions:
* The first non-zero element in each row,
called the leading entry, is 1
* Each leading entry is in a column to
the right of the leading entry in the
previous row
* Rows with all zero elements, if any,
are below rows having a non-zero element.
(http://stattrek.com/matrix-algebra/echelon-transform.aspx)
Row echelon forms aren't unique, but for determining
the rank of a matrix, that doesn't matter.
Code working on a list of points left as an exercise for
the reader.
------------------------------
Message: 2
Date: Tue, 28 Apr 2015 21:36:52 -0400
From: Doug McIlroy
How about simply changing `sieve` to `trialDiv`? It's not that I don't like the given example, because it gives a very small use case for laziness that is difficult enough to reproduce in an eagerly evaluated language.
Is it really so difficult to reproduce in a strict language? Here is that Haskell example in OCaml
let primes = let rec trialDiv (Cons (p,xs)) = Cons (p, lazy (trialDiv @@ filter (fun x -> x mod p <> 0) @@ Lazy.force xs)) in trialDiv @@ iota 2
I'm afraid I don't understand why the program isn't a sieve. Is
the concern that the sequence of integers is thinned by dropping
composites rather than by merely marking them and counting across
them? Or is it that a trace of lazy evaluation will show that all
the divisibility tests on a single integer are clustered together
in time? Or something I haven't thought of?
Of course the program can be written in any Turing-complete language,
but the effort is likely to cause beads of sweat, like "lazy",
"force", or "spawn" to be shed on the algorithmic pearl. The sieve
can even be written succinctly as a bash shell script (below),
which exhibits warts (e.g. five flavors of parentheses) but no sweat.
Though both the Ocaml and the shell code are compact, neither dulls
the luster that lazy evaluation imparts to the Haskell.
sift() {
while true; do
read p
if (( $p % $1 != 0 )); then echo $p; fi
done }
sink() { read p; echo $p; sift $p | sink }
seq 2 1000000 | sink
------------------------------
Message: 3
Date: Wed, 29 Apr 2015 09:42:03 +0700
From: Kim-Ee Yeoh
I'm afraid I don't understand why the program isn't a sieve. Is the concern that the sequence of integers is thinned by dropping composites rather than by merely marking them and counting across them? Or is it that a trace of lazy evaluation will show that all the divisibility tests on a single integer are clustered together in time? Or something I haven't thought of?
When I reread Ertugrul's original email, I see that he's alerting to the danger of derision. There will be people who will mock Haskell for having an un-performant and un-Eratosthenian non-sieve on its front page. As in, Haskell people don't even know their basic math, ha ha. It used to be fibonaccis. That's too inviting of derision. Primes are more noble, so the thinking goes. That very small space on the face of Haskell must perform incredible duties. Among them, it has to showcase beautiful syntax, see: https://github.com/haskell-infra/hl/issues/46#issuecomment-72331664 HTH, -- Kim-Ee