On 16 May 2011 21:31, dm-list-haskell-c...@scs.stanford.edu wrote:
At Mon, 16 May 2011 10:56:02 +0100,
Simon Marlow wrote:
Yes, it's not actually documented as far as I know, and we should fix
that. But if you think about it, sequential consistency is really the
only sensible policy:
On 13/05/2011 21:12, Bernie Pope wrote:
On 13 May 2011 19:06, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
As far as memory consistency goes, we claim to provide sequential
consistency for IORef and IOArray operations, but not for peeks and
pokes.
Hi Simon,
On 16 May 2011 19:56, Simon Marlow marlo...@gmail.com wrote:
On 13/05/2011 21:12, Bernie Pope wrote:
Could you please point me to more information about the sequential
consistency of IORefs? I was looking for something about this recently
but couldn't find it. I don't see anything in the
At Mon, 16 May 2011 10:56:02 +0100,
Simon Marlow wrote:
Yes, it's not actually documented as far as I know, and we should fix
that. But if you think about it, sequential consistency is really the
only sensible policy: suppose one processor creates a heap object and
writes a reference to
At Tue, 17 May 2011 02:18:55 +1000,
Bernie Pope wrote:
http://augustss.blogspot.com/2011/04/
ugly-memoization-heres-problem-that-i.html
He says that There's no guarantee about readIORef and writeIORef when doing
multi-threading.. But I was wondering if that was true, and if it were, what
On 16/05/11 20:31, dm-list-haskell-c...@scs.stanford.edu wrote:
At Mon, 16 May 2011 10:56:02 +0100,
Simon Marlow wrote:
Yes, it's not actually documented as far as I know, and we should fix
that. But if you think about it, sequential consistency is really the
only sensible policy: suppose one
On 12/05/2011 18:24, dm-list-haskell-c...@scs.stanford.edu wrote:
At Thu, 12 May 2011 16:45:02 +0100,
Simon Marlow wrote:
There are no locks here, thanks to the message-passing implementation we
use for throwTo between processors.
Okay, that sounds good. So then there is no guarantee about
On 13 May 2011 19:06, Simon Marlow marlo...@gmail.com wrote:
As far as memory consistency goes, we claim to provide sequential
consistency for IORef and IOArray operations, but not for peeks and pokes.
Hi Simon,
Could you please point me to more information about the sequential
consistency of
On 11/05/2011 23:57, dm-list-haskell-c...@scs.stanford.edu wrote:
At Wed, 11 May 2011 13:02:21 +0100,
Simon Marlow wrote:
However, if there's some simpler way to guarantee that= is the
point where exceptions are thrown (and might be the case for GHC in
practice), then I basically only need to
On 12/05/2011 16:04, David Mazieres expires 2011-08-10 PDT wrote:
At Thu, 12 May 2011 09:57:13 +0100,
Simon Marlow wrote:
So to answer my own question from earlier, I did a bit of
benchmarking, and it seems that on my machine (a 2.4 GHz Intel Xeon
3060, running linux 2.6.38), I get the
At Thu, 12 May 2011 16:45:02 +0100,
Simon Marlow wrote:
There are no locks here, thanks to the message-passing implementation we
use for throwTo between processors.
Okay, that sounds good. So then there is no guarantee about ordering
of throwTo exceptions? That seems like a good
At Mon, 9 May 2011 17:55:17 +0100,
John Lato wrote:
Felipe Almeida Lessa wrote:
So, in the enumerator vs. iterIO challenge, the only big differences I
see are:
a) iterIO has a different exception handling mechanism.
b) iterIO can have pure iteratees that
On 06/05/2011 16:56, dm-list-haskell-c...@scs.stanford.edu wrote:
At Fri, 6 May 2011 10:15:50 +0200,
Gregory Collins wrote:
Hi David,
Re: this comment from catchI:
It is not possible to catch asynchronous exceptions, such as
lazily evaluated divide-by-zero errors, the throw function, or
At Wed, 11 May 2011 13:02:21 +0100,
Simon Marlow wrote:
There's no guarantee of the form that you mention - asynchronous
exceptions can occur anywhere. However, there might be a way to do what
you want (disclaimer: I haven't looked at the implementation of iterIO).
Control.Exception
At Wed, 11 May 2011 13:02:21 +0100,
Simon Marlow wrote:
There's no guarantee of the form that you mention - asynchronous
exceptions can occur anywhere. However, there might be a way to do what
you want (disclaimer: I haven't looked at the implementation of iterIO).
Control.Exception
At Wed, 11 May 2011 13:02:21 +0100,
Simon Marlow wrote:
However, if there's some simpler way to guarantee that= is the
point where exceptions are thrown (and might be the case for GHC in
practice), then I basically only need to update the docs. If someone
with more GHC understanding
From: dm-list-haskell-c...@scs.stanford.edu
At Fri, 6 May 2011 10:10:26 -0300,
Felipe Almeida Lessa wrote:
So, in the enumerator vs. iterIO challenge, the only big differences I
see are:
a) iterIO has a different exception handling mechanism.
b) iterIO can have pure iteratees that
On 7/05/2011, at 2:44 PM, Mario Blažević wrote:
As I said, the most usual name for the Enumerator concept would be Generator.
That term is already used in several languages to signify this kind of
restricted coroutine. I'm not aware of any good alternative naming for
Iteratee.
This being
Sorry for third post but I wonder why the many instances are restricted
by Monad.
Both Functor and Applicative can by constructed without Monad:
instance (Functor m) = Functor (CtlArg t m) where
fmap f (CtlArg arg g c) = CtlArg arg (fmap f . g) c
instance (Functor m) = Functor (Iter t
At Sat, 07 May 2011 21:50:13 +0100,
Maciej Marcin Piechotka wrote:
Sorry for third post but I wonder why the many instances are restricted
by Monad.
It would be great if Functor were a superclass of Monad. However,
since it isn't, and since I can't think of anything particularly
useful to do
On 5/7/11 5:15 PM, dm-list-haskell-c...@scs.stanford.edu wrote:
In general, I try to place as few requirements in the contexts of
functions as possible.
One counterargument to this philosophy is that there are many cases
where fmap can be defined more efficiently than the liftM derived from
Hi David,
Re: this comment from catchI:
It is not possible to catch asynchronous exceptions, such as lazily evaluated
divide-by-zero errors, the throw function, or exceptions raised by other
threads using throwTo if those exceptions might arrive anywhere outside of a
liftIO call.
It
2011/5/6 David Mazieres dm-list-haskell-c...@scs.stanford.edu:
* Every aspect of the library is thoroughly document in haddock
including numerous examples of use.
I'm reading the documentation, it's impressively well detailed. It has
explanations, examples, all that one could dream for.
David Mazieres dm-list-haskell-c...@scs.stanford.edu wrote:
Hi, everyone. I'm pleased to announce the release of a new iteratee
implementation, iterIO:
http://hackage.haskell.org/package/iterIO
IterIO is an attempt to make iteratees easier to use through an
interface based on
2011/5/6 Ertugrul Soeylemez e...@ertes.de:
David Mazieres dm-list-haskell-c...@scs.stanford.edu wrote:
Please enjoy. I'd love to hear feedback.
Thanks a lot, David. This looks like really good work. I'm using the
'enumerator' package, and looking at the types your library seems to use
a
On Thu, 2011-05-05 at 21:15 -0700, David Mazieres wrote:
Hi, everyone. I'm pleased to announce the release of a new iteratee
implementation, iterIO:
http://hackage.haskell.org/package/iterIO
IterIO is an attempt to make iteratees easier to use through an
interface based on pipeline
On Fri, May 6, 2011 at 6:46 AM, David Virebayre
dav.vire+hask...@gmail.com wrote:
2011/5/6 Ertugrul Soeylemez e...@ertes.de:
David Mazieres dm-list-haskell-c...@scs.stanford.edu wrote:
Please enjoy. I'd love to hear feedback.
Thanks a lot, David. This looks like really good work. I'm
On Fri, 06 May 2011 15:10:26 +0200, Felipe Almeida Lessa
felipe.le...@gmail.com wrote:
So, in the enumerator vs. iterIO challenge, the only big differences I
see are:
a) iterIO has a different exception handling mechanism.
b) iterIO can have pure iteratees that don't touch the monad.
c)
On Fri, May 6, 2011 at 10:44 AM, Henk-Jan van Tuyl hjgt...@chello.nl wrote:
iterIO cannot be compiled on Windows, because it depends on the package
unix.
That's a big showstopper. I wonder if the package split I recommend
could solve this issue, or if it's something deeper.
Cheers,
--
Hi All,
I really love the look of this package, but if this is going be *the* iteratee
package, I would absolutely love to see it fix some of the biggest mistakes in
the other iteratee packages, soecifically naming. A change in naming for the
terms iteratee, enumerator and enumeratee would go
At Fri, 6 May 2011 10:15:50 +0200,
Gregory Collins wrote:
Hi David,
Re: this comment from catchI:
It is not possible to catch asynchronous exceptions, such as
lazily evaluated divide-by-zero errors, the throw function, or
exceptions raised by other threads using throwTo if those
At Fri, 6 May 2011 10:10:26 -0300,
Felipe Almeida Lessa wrote:
He also says that the enumerator package's Enumerators aren't
iteratees, only iterIO's enumerators are. Well, that's not what I'm
reading:
-- from enumerator package
newtype Iteratee a m b = Iteratee {runIteratee :: m
At Fri, 6 May 2011 10:54:16 -0300,
Felipe Almeida Lessa wrote:
On Fri, May 6, 2011 at 10:44 AM, Henk-Jan van Tuyl hjgt...@chello.nl wrote:
iterIO cannot be compiled on Windows, because it depends on the package
unix.
That's a big showstopper. I wonder if the package split I recommend
Alex Mason wrote:
I really love the look of this package, but if this is going be *the*
iteratee package, I would absolutely love to see it fix some of the
biggest mistakes in the other iteratee packages, soecifically naming.
A change in naming for the terms iteratee, enumerator and enumeratee
At Sat, 7 May 2011 01:15:25 +1000,
Alex Mason wrote:
Hi All,
I really love the look of this package, but if this is going be
*the* iteratee package, I would absolutely love to see it fix some
of the biggest mistakes in the other iteratee packages, soecifically
naming. A change in naming
At least one thing I've concluded is that it really should be
presented as two concepts, rather than three. So we should talk
about, e.g., producers, consumers, and pipeline stages that do both.
I think that's a great idea.
I'd been thinking about using the terms Source and Sink, but
Sorry for second-posting. In addition to the problems mentioned
elsewhere (too big packages) I would like to point problems with SSL:
- It uses OpenSSL from what I understand which is not compatible with
GPL-2 as it uses Apache 1.0 licence (in addition to BSD4) as it requires
mentioning OpenSSL
On Fri, 06 May 2011 18:28:07 +0200,
dm-list-haskell-c...@scs.stanford.edu wrote:
At Fri, 6 May 2011 10:54:16 -0300,
Felipe Almeida Lessa wrote:
On Fri, May 6, 2011 at 10:44 AM, Henk-Jan van Tuyl hjgt...@chello.nl
wrote:
iterIO cannot be compiled on Windows, because it depends on the
At Sat, 07 May 2011 00:09:46 +0200,
Henk-Jan van Tuyl wrote:
On Fri, May 6, 2011 at 10:44 AM, Henk-Jan van Tuyl hjgt...@chello.nl
wrote:
iterIO cannot be compiled on Windows, because it depends on the
package
unix.
[...]
I'd obviously love to make my stuff work on Windows, but
On 11-05-06 11:15 AM, Alex Mason wrote:
Hi All,
I really love the look of this package, but if this is going be *the* iteratee
package, I would absolutely love to see it fix some of the biggest mistakes in
the other iteratee packages, soecifically naming. A change in naming for the
terms
At Fri, 06 May 2011 21:27:21 -0400,
Mario Blažević wrote:
I'd been thinking about using the terms Source and Sink, but Source is
very overloaded, and SinkSource doesn't exactly roll off the tongue
or evoke a particularly helpful intuition.
The SCC package happens to use Source and
On 11-05-06 09:58 PM, dm-list-haskell-c...@scs.stanford.edu wrote:
At Fri, 06 May 2011 21:27:21 -0400,
Mario Blažević wrote:
I'd been thinking about using the terms Source and Sink, but Source is
very overloaded, and SinkSource doesn't exactly roll off the tongue
or evoke a particularly helpful
On 5/6/11 11:15 AM, Alex Mason wrote:
Hi All,
I really love the look of this package, but if this is going be *the* iteratee
package, I would absolutely love to see it fix some of the biggest mistakes in
the other iteratee packages, soecifically naming. A change in naming for the
terms
Hi, everyone. I'm pleased to announce the release of a new iteratee
implementation, iterIO:
http://hackage.haskell.org/package/iterIO
IterIO is an attempt to make iteratees easier to use through an
interface based on pipeline stages reminiscent of Unix command
pipelines. Particularly
Sounds just terrific! Thanks!
06.05.2011, в 8:15, David Mazieres dm-list-haskell-c...@scs.stanford.edu
написал(а):
Hi, everyone. I'm pleased to announce the release of a new iteratee
implementation, iterIO:
http://hackage.haskell.org/package/iterIO
IterIO is an attempt to make
45 matches
Mail list logo
