Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 might be worth investigating providing a version which can catch asynchronous exceptions if the underlying monad supports it (via MonadCatchIO or something similar). One of the most interesting advantages I can see for IterIO over the other iteratee implementations is that you actually have some control over resource usage -- not being able to catch asynchronous exceptions nullifies much of that advantage. A clear use case for this is timeouts on server threads, where you typically throw a TimeoutException exception to the handling thread using throwTo if the timeout is exceeded. Another question re: resource cleanup: in the docs I see: Now suppose inumHttpBody fails (most likely because it receives an EOF before reading the number of bytes specified in the Content-Length header). Because inumHttpBody is fused to handler, the failure will cause handler to receive an EOF, which will cause foldForm to fail, which will cause handleI to receive an EOF and return, which will ensure hClose runs and the file handle h is not leaked. Once the EOFs have been processed, the exception will propagate upwards making inumHttpServer fail, which in turn will send an EOF to iter. Then the exception will cause enum to fail, after which sock will be closed. In summary, despite the complex structure of the web server, because all the components are fused together with pipe operators, corner cases like this just work with no need to worry about leaked file descriptors. Could you go into a little bit of detail about the mechanism behind this? Thanks! G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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. Thanks ! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 pipeline stages reminiscent of Unix command pipelines. Particularly if you've looked at iteratees before and been intimidated, please have a look at iterIO to see if it makes them more accessible. [...] 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 similar, but more complicated representation. Is there any particular reason, why you didn't base your library on an existing iteratee package like 'enumerator'? Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 similar, but more complicated representation. Is there any particular reason, why you didn't base your library on an existing iteratee package like 'enumerator'? David has documented some design decisions in http://hackage.haskell.org/packages/archive/iterIO/0.1/doc/html/Data-IterIO.html#g:3 Perhaps you may find some answers there. David (another one :) ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 stages reminiscent of Unix command pipelines. Particularly if you've looked at iteratees before and been intimidated, please have a look at iterIO to see if it makes them more accessible. Some aspects of iterIO that should simplify learning and using iteratees are: * Every aspect of the library is thoroughly document in haddock including numerous examples of use. * Enumerators are easy to build out of iteratees. * There is no difference between enumerators and enumeratees (i.e., inner pipeline stages). The former is just a type-restricted version of the latter. * Parsing combinators provide detailed error reporting and support LL(*) rather than LL(1) parsing, leading to fewer non-intuitive parsing failures. A couple of tricks avoid consuming excessive memory for backtracking. * Super-fast LL(1) parsing is also available through seamless integration with attoparsec. * A universal exception mechanism works across invocations of mtl monad transformers, thereby unifying error handling. * All pipe operators have uniform semantics, eliminating corner cases. In particular, if the writing end of a pipe fails, the reading end always gets EOF, allowing it to clean up resources. * One can catch exceptions thrown by any contiguous subset of stages in a pipeline. Moreover, enumerator exception handlers can resume downstream stages that haven't failed. * The package is full of useful iteratees and enumerators, including basic file and socket processing, parsec-like combinators, string search, zlib/gzip compression, SSL, HTTP, and loopback enumerator/iteratee pairs for testing a protocol implementation against itself. Please enjoy. I'd love to hear feedback. David 1. It looks nice - however it causes problem as we have 3 iteratees packages, all of which have some advantages. 4 if we count coroutine. (I don't count original implementations). 2. What is the reason of using Inum/Onum instead of Iteratee/Enumerator/Enumeratee. The latter seems to be a standard naming in the community? Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CFP: APLAS 2011, Kenting, Taiwan
==
APLAS 2011 Call For Papers
Ninth Asian Symposium on Programming Languages and Systems
Kenting, Taiwan, December 5--7, 2011
(co-located with CPP 2011)
http://flolac.iis.sinica.edu.tw/aplas11/
==
BACKGROUND:
APLAS aims at stimulating programming language research by
providing a forum for the presentation of latest results and
the exchange of ideas in topics concerned with programming
languages and systems. APLAS is based in Asia, but is an
international forum that serves the worldwide programming
language community.
APLAS is sponsored by the Asian Association for Foundation of
Software (AAFS) founded by Asian researchers in cooperation with
many researchers from Europe and the USA. The past APLAS symposiums
were successfully held in Shanghai ('10), Seoul ('09),
Bangalore ('08), Singapore ('07), Sydney ('06), Tsukuba ('05),
Taipei ('04) and Beijing ('03) after three informal workshops.
Proceedings of the past symposiums were published in
Springer-Verlag's LNCS 6461, 5904, 5356, 4807, 4279, 3780, 3302,
and 2895.
The 2011 edition will be held at Kenting, a seaside resort in
Southern Taiwan.
TOPICS:
The symposium is devoted to both foundational and practical
issues in programming languages and systems. Papers are solicited
on, but not limited to, the following topics:
+ semantics, logics, foundational theory;
+ design of languages and foundational calculi;
+ type systems;
+ compilers, interpreters, abstract machines;
+ program derivation and transformation;
+ program analysis, verification, model-checking, software security;
+ concurrency, constraints, domain-specific languages;
+ tools for programming, verification, implementation.
APLAS 2011 is not limited to topics discussed in previous
symposiums. Papers identifying future directions of
programming and those addressing the rapid changes of the
underlying computing platforms are especially welcome.
Demonstration of systems and tools in the scope of APLAS are
welcome to the System and Tool presentations category.
Authors concerned about the appropriateness of a topic are
welcome to consult with Program Chair prior to submission.
IMPORTANT DATES:
Abstract Deadline: June 13, 2011
Submission Deadline: June 17, 2011 (GMT)
Notification: August 29, 2011
Camera-Ready: September 19, 2011
INVITED SPEAKERS:
Nikolaj Bjorner, Microsoft Research Redmond
Ranjit Jhala, UC San Diego
Peter O'Hearn, Queen Mary U. London
Sriram Rajamani, Microsoft Research India
SUBMISSION INFORMATION:
We solicit submissions in two categories:
Regular research papers, describing original research results,
including tool development and case studies, from a perspective of
scientific research. Regular research papers should not exceed 16
pages in the Springer LNCS format, including bibliography and
figures. They should clearly identify what has been accomplished and
why it is significant. Submissions will be judged on the basis of
significance, relevance, correctness, originality, and clarity. In
case of lack of space, proofs, experimental results, or any
information supporting the technical results of the paper could be
provided as Appendix or a link to a web page.
System and Tool presentations, describing systems or tools that
support theory, program construction, reasoning, and/or program
execution in the scope of APLAS. Unlike presentations of regular
research papers, presentation of accepted papers in this category is
expected to be centered around a demonstration. The paper and the
demonstration should identify the novelties of the tools and use
motivating examples. System and Tool papers should not
exceed 8 pages in the Springer LNCS format, including bibliography and
figures. Submissions will be judged based on both the papers and the
systems or tools as described in the papers. It is highly desirable
that the tools are available on the web.
Papers should be submitted electronically via the submission web page
at http://www.easychair.org/conferences/?conf=aplas2011. Acceptable
formats are PostScript or PDF, viewable by Ghostview or Acrobat
Reader. Submitted papers must be unpublished and not submitted for
publication elsewhere. Papers must be written in English. The
proceedings are planned to be published as a volume in
Springer-Verlag's Lecture Notes in Computer Science series. Accepted
papers must be presented at the conference.
GENERAL CHAIR:
Tyng-Ruey Chuang, Academia Sinica, Taiwan
PROGRAM CHAIR:
Hongseok Yang, Queen Mary U. London
aplas2...@easychair.org
PROGRAM COMMITTEE:
Lars Birkedal (ITU, Denmark)
James Brotherston (Imperial College, UK)
Kung Chen (National Chengchi U., Taiwan)
Wenguang Chen (Tsinghua U., China)
Wei-Ngan Chin (NUS, Singapore)
Javier Esparza (TUM, Germany)
Xinyu Feng (USTC, China)
Jerome Feret (INRIA, France)
Matthew Fluet (RIT, USA)
Rajiv Gupta (UC Riverside, USA)
Masahito Hasegawa (Kyoto U., Japan)
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 using the
'enumerator' package, and looking at the types your library seems to use
a similar, but more complicated representation. Is there any particular
reason, why you didn't base your library on an existing iteratee package
like 'enumerator'?
David has documented some design decisions in
http://hackage.haskell.org/packages/archive/iterIO/0.1/doc/html/Data-IterIO.html#g:3
Perhaps you may find some answers there.
He says that enumerator's Iteratee doesn't have special support for
pure Iteratees. When he says that the iteratee package doesn't have
special support for control messages, the same applies for enumerator
as well. He also says that enumerator can't distinguish failures from
iteratees and enumeratees.
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 (Step a m b)}
type Enumerator a m b = Step a m b - Iteratee a m b
type Enumeratee ao ai m b = Step ai m b - Iteratee ao m (Step ai m b)
-- from iterIO package
newtype Iter t m a = Iter {runIter :: Chunk t - IterR t m a}
type Inum tIn tOut m a = Iter tOut m a - Iter tIn m (IterR tOut m a)
type Onum t m a = Inum () t m a
The enumerator package's Enumerator *is* an iteratee, an so is its
Enumeratee. The only real difference is that iterIO represents
enumerators as enumeratees from () to something. In enumerator
package terms, that would be
-- enumerator packages's enumerator if it was iterIO's :)
-- note that Inum's tIn and tOut are reversed w.r.t Enumeratee
ao and ai
type Enumerator a m b = Enumeratee () a m b
Whether this representation is better or worse isn't clear for me.
Now, one big problem that iterIO has that enumerator hasn't, is that
iterIO is a *big* library with many dependencies, including OpenSSL.
IMHO, that package should be split into many others.
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) iterIO's iteratees can send control messages to ther enumerators.
d) iterIO's enumerators are enumeratees, but enumerator's enumerators
are simpler.
e) enumerator has fewer dependencies.
f) enumerator uses conventional nomenclature.
g) enumerator is Haskell 98, while iterIO needs many extensions (e.g.
MPTC and functional dependencies).
Anything that I missed?
The bottomline: the biggest advantage I see right now in favor of
iterIO is c), although it still has the problem that you may get
runtime errors if you send the wrong control message. However, right
now e) and g) may stop many users of enumerator from porting to
iterIO, even if they like its approach.
Cheers! =)
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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) iterIO's iteratees can send control messages to ther enumerators. d) iterIO's enumerators are enumeratees, but enumerator's enumerators are simpler. e) enumerator has fewer dependencies. f) enumerator uses conventional nomenclature. g) enumerator is Haskell 98, while iterIO needs many extensions (e.g. MPTC and functional dependencies). Anything that I missed? iterIO cannot be compiled on Windows, because it depends on the package unix. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: syntactic-0.1
I'm happy to announce the first release of syntactic: http://hackage.haskell.org/package/syntactic providing generic abstract syntax and utilities for embedded languages. To get an idea of what it's about, check out the tiny(!) implementation of (simplified) Feldspar in the Examples directory: http://projects.haskell.org/syntactic/Examples/MuFeldspar The library is intended to provide a growing set of utilities for embedded languages. In particular, I hope to be able to provide safe interfaces to various unsafe techniques for speeding things up. Comments, patches and clients are welcome! / Emil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: [GeekUp] Functional Programming Night at GeekUp Liverpool May
If anyone's in Northwest UK on Tuesday 31st May, why not come to Geekup's first ever Functional Programming Night? http://lanyrd.com/2011/geekup-liverpool-may/ It'll mostly consist of 3 short talks on Haskell, Lisp, and Clojure: * Haskell in the Real World (Hakim @osfameron) * Implenting a Lisp interpreter in .Net (Simon Johnson) * Clojure: why you should be interested in a 50 year old language (Tom Mortimer-Jones @morty_uk) There will also be beer! The talks are likely to be more general interest than assuming deep knowledge of FP, but it would be great to meet anyone around UK NW to gauge interest in more in-depth sessions sometime in the future! Hakim -- Forwarded message -- From: John McKerrell mck...@gmail.com Date: 6 May 2011 15:10 Subject: [GeekUp] Functional Programming Night at GeekUp Liverpool May To: gee...@googlegroups.com Just wanted to announce May's GeekUp properly. We'll be having a Functional Programming Extravaganza with three (count em', 3!) talks from Hakim Cassimally, Simon Johnson and Tom Mortimer-Jones. Meeting in 3345 on Parr Street as ever, talks starting at 7pm but turn up from 6:30 and we'll be chatting over beer in the bar. Turn-out has been great for the recent events but we're always happy to welcome more people, there's more information on lanyrd: http://lanyrd.com/2011/geekup-liverpool-may/ Let us know you're coming by signing up on that link but feel free to turn up anyway, attendance is free and open to all comers of course. John -- http://geekup.org/ | http://geekup.org/wiki/ | http://jobboard.geekup.org/ To post e-mail: gee...@googlegroups.com Or go online: http://groups.google.com/group/geekup/ To unsubscribe e-mail: geekup+unsubscr...@googlegroups.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 a hell of a long way here; Peaker on #haskell suggested Consumer/Producer/Transformer, and there is a lot of agreement in the channel that these are vastly better names. They’re also far less intimidating to users. I personally feel that maybe Transformer isn't such a great name (being closely associated with monad transformers), and that maybe something like Mapper would be better, but I'm by no means in love with that name either. More people in #haskell seem to like Transformer, and I don't think my argument against it is very strong, so the hivemind seems to have settled on the Producer/Transformer/Consumer trilogy. I'd love to hear thoughts on the issue, especially from David. Cheers, Alex Mason On 06/05/2011, at 20:17, Maciej Marcin Piechotka wrote: 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 stages reminiscent of Unix command pipelines. Particularly if you've looked at iteratees before and been intimidated, please have a look at iterIO to see if it makes them more accessible. Some aspects of iterIO that should simplify learning and using iteratees are: * Every aspect of the library is thoroughly document in haddock including numerous examples of use. * Enumerators are easy to build out of iteratees. * There is no difference between enumerators and enumeratees (i.e., inner pipeline stages). The former is just a type-restricted version of the latter. * Parsing combinators provide detailed error reporting and support LL(*) rather than LL(1) parsing, leading to fewer non-intuitive parsing failures. A couple of tricks avoid consuming excessive memory for backtracking. * Super-fast LL(1) parsing is also available through seamless integration with attoparsec. * A universal exception mechanism works across invocations of mtl monad transformers, thereby unifying error handling. * All pipe operators have uniform semantics, eliminating corner cases. In particular, if the writing end of a pipe fails, the reading end always gets EOF, allowing it to clean up resources. * One can catch exceptions thrown by any contiguous subset of stages in a pipeline. Moreover, enumerator exception handlers can resume downstream stages that haven't failed. * The package is full of useful iteratees and enumerators, including basic file and socket processing, parsec-like combinators, string search, zlib/gzip compression, SSL, HTTP, and loopback enumerator/iteratee pairs for testing a protocol implementation against itself. Please enjoy. I'd love to hear feedback. David 1. It looks nice - however it causes problem as we have 3 iteratees packages, all of which have some advantages. 4 if we count coroutine. (I don't count original implementations). 2. What is the reason of using Inum/Onum instead of Iteratee/Enumerator/Enumeratee. The latter seems to be a standard naming in the community? Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 exceptions might arrive anywhere outside of a liftIO call. It might be worth investigating providing a version which can catch asynchronous exceptions if the underlying monad supports it (via MonadCatchIO or something similar). One of the most interesting advantages I can see for IterIO over the other iteratee implementations is that you actually have some control over resource usage -- not being able to catch asynchronous exceptions nullifies much of that advantage. A clear use case for this is timeouts on server threads, where you typically throw a TimeoutException exception to the handling thread using throwTo if the timeout is exceeded. Excellent point. There's actually a chance that iterIO already catches those kinds of exceptions, but I wasn't sure enough about how the Haskell runtime works to make that claim. I've noticed in practice that asynchronous exceptions tend to come exactly when I execute the IO = operation. If that's true, then since each IO = is wrapped in a try block, the exceptions will all be caught (well, not divide by zero, but things like throwTo, which I think are more important). One way I was thinking of implementing this was wrapping the whole execution in block, and then calling unblock (unless iterIO's own hypothetical block function is called) for every invocation of liftIO. Unfortunately, the block and unblock functions now seem to be deprecated, and the replacement mask/unmask ones would not be as amenable to this technique. 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 could explain how asynchronous exceptions work, I'd love to hear it... Another question re: resource cleanup: in the docs I see: Now suppose inumHttpBody fails (most likely because it receives an EOF before reading the number of bytes specified in the Content-Length header). Because inumHttpBody is fused to handler, the failure will cause handler to receive an EOF, which will cause foldForm to fail, which will cause handleI to receive an EOF and return, which will ensure hClose runs and the file handle h is not leaked. Once the EOFs have been processed, the exception will propagate upwards making inumHttpServer fail, which in turn will send an EOF to iter. Then the exception will cause enum to fail, after which sock will be closed. In summary, despite the complex structure of the web server, because all the components are fused together with pipe operators, corner cases like this just work with no need to worry about leaked file descriptors. Could you go into a little bit of detail about the mechanism behind this? Yes, absolutely. This relies on the fact that an Inum must always return its target Iter, even when the Inum fails. This invariant is ensured by the two Inum construction functions, mkInumC and mkInumM, which catch exceptions thrown by the codec iteratee and add in the state of the target iteratee. Now when you execute code like inum .| iter, the immediate result of running inum is IterR tIn m (IterR tOut m a)--i.e., the result of an iteratee returning the result an iteratee (because Inums are iteratees, too). If the Inum failed, then the outer IterR will use the Fail constructor: Fail !IterFail !(Maybe a) !(Maybe (Chunk t)) Where the Maybe a will be a Maybe (IterR tOut m b), and, because of the Inum invariant, will be Just an actual result. .| then must translate the inner iteratee result to the appropriate return type for the Inum (since the Inum's type (IterR tIn m ...) is different from the Iter's (Iter tOut m ...)). This happens through the internal function joinR, which says: joinR (Fail e (Just i) c) = flip onDoneR (runR i) $ \r - case r of Done a _- Fail e (Just a) c Fail e' a _ - Fail e' a c _ - error joinR Where the 'runR' function basically keeps feeding EOF to an Iter (and executing it's monadic actions and rejecting its control requests) until it returns a result, at which point the result's residual input can be discarded and replaced with the residual input of the Inum. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 (Step a m b)}
type Enumerator a m b = Step a m b - Iteratee a m b
type Enumeratee ao ai m b = Step ai m b - Iteratee ao m (Step ai m b)
-- from iterIO package
newtype Iter t m a = Iter {runIter :: Chunk t - IterR t m a}
type Inum tIn tOut m a = Iter tOut m a - Iter tIn m (IterR tOut m a)
type Onum t m a = Inum () t m a
The enumerator package's Enumerator *is* an iteratee, an so is its
Enumeratee.
Strictly speaking, I guess that's precise if you look at the type of
Enumerator. However, it's not really an iteratee in the spirit of
iteratees, since it isn't really a data sink and has no input type.
The only real difference is that iterIO represents
enumerators as enumeratees from () to something. In enumerator
package terms, that would be
-- enumerator packages's enumerator if it was iterIO's :)
-- note that Inum's tIn and tOut are reversed w.r.t Enumeratee
ao and ai
type Enumerator a m b = Enumeratee () a m b
Whether this representation is better or worse isn't clear for me.
Exactly. The reason it's better (and for a long time my library was
more like the enumerator one) is that the mechanics of uniform error
handling are complex enough as it is. When enumerators and
enumeratees are two different types, you need two different mechanisms
for constructing them, and then have to worry about handing errors in
the two different cases. I found that unifying enumerators and
enumeratees (or Inums and Onums as I call them) significantly
simplified a lot of code.
Now, one big problem that iterIO has that enumerator hasn't, is that
iterIO is a *big* library with many dependencies, including OpenSSL.
IMHO, that package should be split into many others.
Yes, this is definitely true.
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) iterIO's iteratees can send control messages to ther enumerators.
d) iterIO's enumerators are enumeratees, but enumerator's enumerators
are simpler.
e) enumerator has fewer dependencies.
f) enumerator uses conventional nomenclature.
g) enumerator is Haskell 98, while iterIO needs many extensions (e.g.
MPTC and functional dependencies).
Anything that I missed?
The bottomline: the biggest advantage I see right now in favor of
iterIO is c),
I basically agree with this list, but think you are underestimating
the value of a. I would rank a as the most important difference
between the packages. (a also is the reason for d.)
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 could solve this issue, or if it's something deeper. It's actually worse than this, unfortunately. The unix package dependency is mostly there for efficiency. For the HTTP package, in order to handle things like directories, If-Modified-Since, and Content-Length, I need to look at file attributes. The platform-independent code lets me do this, but I would have to make many more system calls. Also, I would have a slight race condition, because it's hard to get the attributes of the file you actually opened (to make sure the length hasn't changed, etc), while the unix package gets me access to both stat and fstat. This has all been abstracted away by the FileSystemCalls class, so if there's a way to implement those five functions on Windows, we could move defaultFileSystemCalls to its own module (or even its own package), and solve the problem without sacrificing performance or correctness on unix. Unfortunately, there are two worse unix dependencies: 1) I'm using the network IO package to do IO on ByteStrings, and the network library claims this doesn't work on windows. 2) Proper implementation of many network protocols requires the ability to send a TCP FIN segment without closing the underlying file descriptor (so you can still read from it). Thus, I'm using FFI to call the shutdown() system call on the file descriptors of Handles. I have no idea how to make this work on Windows. I'm hoping that time eventually solves problem #1. As for problem #2, the ideal solution would be to get something like hShutdown into the system libraries. I'd obviously love to make my stuff work on Windows, but probably lack the experience to do it on my own. Suggestions and help are of course welcome... David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 would go a hell of a long way here; Peaker on #haskell suggested Consumer/Producer/Transformer, and there is a lot of agreement in the channel that these are vastly better names. They’re also far less intimidating to users. I personally feel that maybe Transformer isn't such a great name (being closely associated with monad transformers), and that maybe something like Mapper would be better, but I'm by no means in love with that name either. More people in #haskell seem to like Transformer, and I don't think my argument against it is very strong, so the hivemind seems to have settled on the Producer/Transformer/Consumer trilogy. I'd love to hear thoughts on the issue, especially from David. I vastly prefer the names Producer/Transformer/Consumer over the others. Then again, I never quite understood what Iteratees were all about in the first place. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 for the terms iteratee, enumerator and enumeratee would go a hell of a long way here; Peaker on #haskell suggested Consumer/Producer/Transformer, and there is a lot of agreement in the channel that these are vastly better names. They’re also far less intimidating to users. I personally feel that maybe Transformer isn't such a great name (being closely associated with monad transformers), and that maybe something like Mapper would be better, but I'm by no means in love with that name either. More people in #haskell seem to like Transformer, and I don't think my argument against it is very strong, so the hivemind seems to have settled on the Producer/Transformer/Consumer trilogy. I'd love to hear thoughts on the issue, especially from David. This is a question I struggled a lot with. I definitely agree that the terms are pretty intimidating to new users. 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'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. In the end, I decided just to come up with new terms that wouldn't carry any pre-conceptions (e.g., what's an Inum?), and then build the intuition through copious documentation... I'm open to suggestion here. I've already overhauled the naming conventions in the library once. Initially I used the names EnumI and EnumO for Inum and Onum. I think the old names were much worse, especially since Enum is a fundamental typeclass that has absolutely nothing to do with enumerators. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Division: Is there a way to simultaneously find the quotient and remainder?
:) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Division: Is there a way to simultaneously find the quotient and remainder?
Sure... see quotRem in the prelude. On May 6, 2011 10:49 AM, cas...@istar.ca wrote: :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Division: Is there a way to simultaneously find the quotient and remainder?
Hoogle is very useful for the kinds of questions where you can estimate a likely type: http://www.haskell.org/hoogle/?hoogle=Integral+a+%3D%3E+a+-%3E+a+-%3E+%28a%2Ca%29 On Sat, May 7, 2011 at 12:50 AM, Chris Smith cdsm...@gmail.com wrote: Sure... see quotRem in the prelude. On May 6, 2011 10:49 AM, cas...@istar.ca wrote: :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Gtk2hs on Windows
On 05/05/2011 09:50 PM, Andrew Coppin wrote: On 05/05/2011 01:32 AM, Albert Y. C. Lai wrote: Just 5 weeks ago, http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456 Did anyone see it? Right. So the problem might be GTK+ v3? Wrong. Apparently the bundle I downloaded contains GTK+ 2.20, which is fine. But the page above clarifies what the real problem is: HP 2011.2.0.1 doesn't work, apparently. (Doesn't say why.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Server hosting
OK, so strictly this is unrelated to Haskell as such. However, there's enough people doing webby stuff with Haskell that some of you must have wanted to run your code on a real, Internet-accessible web server. So does anybody have any suggestions on which companies offer the most favourable tools / pricing? I currently have a website, but it supports only CGI *scripts* (i.e., Perl or PHP). It does not support arbitrary CGI *binaries*, which is what I'd want for Haskell. In fact, I don't have control over the web server at all; I just put content on there. The same provider can offer me a virtual server, but at 3x the price I'm currently paying. I simply cannot afford that kind of money just for silly toy projects. What does everybody else use? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 Source is very overloaded, and SinkSource doesn't exactly roll off the tongue or evoke a particularly helpful intuition. One good thing I can say for the Enumerator/Iteratee nomenclature is that it nicely connotes the inversion of control (i.e., the push data flow) that enumerator is all about. Enumera*tor** *feeds Itera*tee* -- subject, verb, object. Producer/Consumer connotes the same by allusion to the producer-consumer pattern of thread synchronization. Tom On Fri, May 6, 2011 at 9:47 AM, dm-list-haskell-c...@scs.stanford.eduwrote: This is a question I struggled a lot with. I definitely agree that the terms are pretty intimidating to new users. 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'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. In the end, I decided just to come up with new terms that wouldn't carry any pre-conceptions (e.g., what's an Inum?), and then build the intuition through copious documentation... I'm open to suggestion here. I've already overhauled the naming conventions in the library once. Initially I used the names EnumI and EnumO for Inum and Onum. I think the old names were much worse, especially since Enum is a fundamental typeclass that has absolutely nothing to do with enumerators. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
On 6 May 2011 20:07, Andrew Coppin andrewcop...@btinternet.com wrote: OK, so strictly this is unrelated to Haskell as such. However, there's enough people doing webby stuff with Haskell that some of you must have wanted to run your code on a real, Internet-accessible web server. So does anybody have any suggestions on which companies offer the most favourable tools / pricing? I currently have a website, but it supports only CGI *scripts* (i.e., Perl or PHP). It does not support arbitrary CGI *binaries*, which is what I'd want for Haskell. In fact, I don't have control over the web server at all; I just put content on there. The same provider can offer me a virtual server, but at 3x the price I'm currently paying. I simply cannot afford that kind of money just for silly toy projects. What does everybody else use? Some suggestions: * Amazon C2. FREE hosting for a year, you can get SSH access and various Linux distributions. * Linode I use this with a Linux distribution Costs about $19USD, I guess, for 200GB bandwidth, 512MB memory, 16GB HD. * Other VPS-y things; RapidVPS hosts hpaste.org and tryhaskell.org which are FastCGI, about the same as Linode but half the price, and half as fast/responsive (for me) but reliable. I'd recommend Amazon in this case, you don't get much cheaper than free. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
I use Amazon EC2 Free Tier. You can install Yesod/Warp easily enough and it's fine for small traffic. JP On Fri, May 6, 2011 at 8:07 PM, Andrew Coppin andrewcop...@btinternet.com wrote: OK, so strictly this is unrelated to Haskell as such. However, there's enough people doing webby stuff with Haskell that some of you must have wanted to run your code on a real, Internet-accessible web server. So does anybody have any suggestions on which companies offer the most favourable tools / pricing? I currently have a website, but it supports only CGI *scripts* (i.e., Perl or PHP). It does not support arbitrary CGI *binaries*, which is what I'd want for Haskell. In fact, I don't have control over the web server at all; I just put content on there. The same provider can offer me a virtual server, but at 3x the price I'm currently paying. I simply cannot afford that kind of money just for silly toy projects. What does everybody else use? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
On 05/06/2011 08:07 PM, Andrew Coppin wrote: [...] I currently have a website, but it supports only CGI *scripts* (i.e., Perl or PHP). It does not support arbitrary CGI *binaries*, which is what I'd want for Haskell. In fact, I don't have control over the web server at all; I just put content on there. I don't really expect this to work, but... ?php $argsstr = ... $ok = 0 passthru( './my_real_cgi '.$argsstr, $ok ); exit( $ok ); ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
On 6 May 2011 20:18, Steffen Schuldenzucker sschuldenzuc...@uni-bonn.dewrote: I don't really expect this to work, but... ?php $argsstr = ... $ok = 0 passthru( './my_real_cgi '.$argsstr, $ok ); exit( $ok ); ? I actually got something like that to work on a shared host before, I used PHP as the starter and then served a CGI app. You need to make sure the shared libraries for Haskell are on there too (gmp, for example, IIRC). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
Has anyone tried webfaction.com with Haskell? I use them for custom Python web apps and they're great (competitive shared hosting price, ssh access, easy to setup proxy apps listening on custom ports or cgi apps with the ability to edit .htaccess). Loosely speaking it's a cross between traditional shared hosting and VPS hosting, but I'm not quite ready for web development with Haskell yet so I've only used it with Python. On Fri, May 6, 2011 at 12:21 PM, Christopher Done chrisd...@googlemail.comwrote: On 6 May 2011 20:18, Steffen Schuldenzucker sschuldenzuc...@uni-bonn.dewrote: I don't really expect this to work, but... ?php $argsstr = ... $ok = 0 passthru( './my_real_cgi '.$argsstr, $ok ); exit( $ok ); ? I actually got something like that to work on a shared host before, I used PHP as the starter and then served a CGI app. You need to make sure the shared libraries for Haskell are on there too (gmp, for example, IIRC). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: timeplot-0.3.0 - the analyst's swiss army knife for visualizing ad-hoc log files
Hi Eugene, This is a great tool. I often have to analyze data from multiple sources, so I usually create a SQLite database to store it all and start running queries. I just tested it in the form: $ echo 'SELECT...' | sqlite3 database.db | tplot options And for more complicated queries outputting the results to file then reading it in with tplot. Both worked great. Thanks, Eric On Sun, May 1, 2011 at 12:14 PM, Eugene Kirpichov ekirpic...@gmail.comwrote: Hello, Sorry for the broken link: the correct link to the presentation is: http://jkff.info/presentations/two-visualization-tools.pdf 2011/4/30 Eugene Kirpichov ekirpic...@gmail.com: Hello fellow haskellers, I announce the release of timeplot-0.3.0, the analyst's swiss army knife for visualizing ad-hoc log files. Links: * http://jkff.info/presentation/two-visualization-tools - a presentation saying what the tools are all about and giving plenty of graphical examples on cluster computing use cases. At the end of the presentation there's also a couple of slides about installation. It is a little bit outdated, it corresponds to versions just before 0.3.0. * http://hackage.haskell.org/package/timeplot * http://github.com/jkff/timeplot * The sibling tool, splot - for visualizing the activity of many concurrent processes - http://hackage.haskell.org/package/splot and http://github.com/jkff/splot . It has also gotten a couple of new features since my last announcement. The major new feature of tplot is the introduction of subplots, the 'within' plots. It allows one to plot data from several sub-tracks on one track of the graph: - several line- or dot-plots - several plots of sums or cumulative sums, perhaps stacked (to see how the sub-tracks contribute to the total sum - e.g. if your log speaks about different types of overhead and you wish to see how they contribute to the total) - stacked activity count plot - a generalization of the previous activity count plot, which allows you to, given a log saying like Machine started servicing job JOB1 ... Machine finished servicing job JOB1 etc, plot how many machines are servicing each job at any moment, in a stacked fashion - so, how loads by different jobs contribute to the whole cluster's load. The activity frequency plot plots the same on a relative scale. The syntax is, for example: within[.] dots or within[.] acount or even within[.] duration cumsum stacked etc. Note that these are of course just example use cases and the tool is universal, it is not in any sense specialized to clusters, jobs, overheads or actually even to logs. I'd like to encourage you to give it a try and look around for a use case :) If you do give the tool a try, please tell me if something goes wrong, be it an installation problem or a bug (the version is fresh released, so this is quite possible). -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
Have you considered Dynamic DNS [1]? I haven't personally tried it but a friend of mine told me it works pretty well. -deech [1] http://www.dyndns.com/services/dns/dyndns/ On Fri, May 6, 2011 at 1:07 PM, Andrew Coppin andrewcop...@btinternet.com wrote: OK, so strictly this is unrelated to Haskell as such. However, there's enough people doing webby stuff with Haskell that some of you must have wanted to run your code on a real, Internet-accessible web server. So does anybody have any suggestions on which companies offer the most favourable tools / pricing? I currently have a website, but it supports only CGI *scripts* (i.e., Perl or PHP). It does not support arbitrary CGI *binaries*, which is what I'd want for Haskell. In fact, I don't have control over the web server at all; I just put content on there. The same provider can offer me a virtual server, but at 3x the price I'm currently paying. I simply cannot afford that kind of money just for silly toy projects. What does everybody else use? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 (This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit). - It doesn't allow to use it after STARTTLS command Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
I've used webfaction with haskell. http://wrwills.webfactional.com/30/10/2009/Haskell-on-a-Webfaction-Host -Rob On Fri, May 6, 2011 at 8:48 PM, Eric Rasmussen ericrasmus...@gmail.comwrote: Has anyone tried webfaction.com with Haskell? I use them for custom Python web apps and they're great (competitive shared hosting price, ssh access, easy to setup proxy apps listening on custom ports or cgi apps with the ability to edit .htaccess). Loosely speaking it's a cross between traditional shared hosting and VPS hosting, but I'm not quite ready for web development with Haskell yet so I've only used it with Python. On Fri, May 6, 2011 at 12:21 PM, Christopher Done chrisd...@googlemail.com wrote: On 6 May 2011 20:18, Steffen Schuldenzucker sschuldenzuc...@uni-bonn.dewrote: I don't really expect this to work, but... ?php $argsstr = ... $ok = 0 passthru( './my_real_cgi '.$argsstr, $ok ); exit( $ok ); ? I actually got something like that to work on a shared host before, I used PHP as the starter and then served a CGI app. You need to make sure the shared libraries for Haskell are on there too (gmp, for example, IIRC). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] no time profiling on my MacBookPro8,1
For this vanilla program module Main where main = print $ fib 40 fib 0 = 1 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) with these commands $ ghc -prof -auto-all -rtsopts -O --make Main.hs -o Main $ ./Main +RTS -p all of the %time cells in the generated Main.prof file are 0.0, as is the total time count (0.00 secs and 0 ticks). The %alloc cells seem normal. Andy Gill noticed that if you compile with -threaded, the %time cells seem normal. I scanned the GHC Trac tickets specific to Mac OS X, but saw no titles that looked similar. Is this a known issue? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 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. [...] I'd obviously love to make my stuff work on Windows, but probably lack the experience to do it on my own. Suggestions and help are of course welcome... Is the unix-compat package any good? Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A long day with HXT
Dear Group,
I have just spent many hours staring at code and losing some hair. My
hope is to save you the same experience someday. Here was my goal:
Take some XML, like photo url=somewhere align=left alt=/ and
replace the align attribute with a class attribute, but only if the
value of the align attribute was not null. This led to to followed
(hugely condensed) attempts:
{-# LANGUAGE Arrows #-}
import Text.XML.HXT.Core
-- photo url=somewhere align=left alt=/
testString = photo url=\somewhere\ align=\left\ alt=\\/
toClass :: b - QName
toClass = const (mkName class)
try f = runLA (xread processTopDown f) testString
test1 = try $
hasAttrValue align (not.null)
processAttrl (changeAttrName toClass `when` hasName align )
test2 = try $ processAttrl
(changeAttrName toClass `when` hasAttrValue align (not.null))
test3 = try $ processAttrl
(changeAttrName toClass `when` hasName align)
`when` hasAttrValue align (not.null)
run = do
print test1
print test2
print test3
result of run:
[NTree (XTag photo [NTree (XAttr url) [NTree (XText somewhere) []],NTree
(XAttr class) [NTree (XText left) []],NTree (XAttr alt) []]) []]
[NTree (XTag photo [NTree (XAttr url) [NTree (XText somewhere) []],NTree
(XAttr align) [NTree (XText left) []],NTree (XAttr alt) []]) []]
[NTree (XTag photo [NTree (XAttr url) [NTree (XText somewhere) []],NTree
(XAttr class) [NTree (XText left) []],NTree (XAttr alt) []]) []]
test1 and test3 performed as desired, needless to say I started out
with something similar to test2 and was almost crying because the
align attribute didn't change. Why?
In test1, I run through the tree and select the elements which have a
non-null align attribute. (hasAttrValue align (not.null)) Then for
each of these elements I process their attributes. (processAttrl)
where I change the attribute name to class (changeAttrName toClass)
WHEN the attribute name is align (`when` hasName align) Result: Joy
In test2, I run through the tree and process every attribute list
(processAttrl) I change the name of the attribute to class
(changeAttrName toClass) WHEN the align attribute is not null (`when`
hasAttrValue align (not.null))) Result: Nothing changes, - No Joy
In test3, I run through the tree process every attribute list
(processAttrl) WHEN the align attribute is not null (`when` hasAttrValue
align (not.null)) and in that case I change the attribute name to
class (changeAttrName toClass) WHEN the attribute is named align
(`when` hasName align) Result: Joy
After staring at test2 for more time that I would like to acknowledge,
I (think) I realized the following. In test2 I thought the
(hasAttrValue align (not.null)) was referring to the tree that was
coming into the test, but actually it is referring to the list of
attributes that is generated by processAttrl. This list of attributes
does not itself have any attributes, thus the (hasAttrValue align
(not.null)) code never succeeds, and thus the (changeAttrName toClass)
is never executed.
Lessons learned: I'm not really sure, but it is these kind of subtleties
that make me sometimes long for my old friend Perl.
Best wishes,
Henry Laxen
--
Nadine Henry LaxenBelle, Venus, Aphrodite
10580 N. McCarran Blvd. Adonis, Miss Parker Jarod
Suite 115-396 Via Alta # 6
Reno, NevadaChapala, Jalisco, Mexico
89503-1896 CP 45900
The rest is silence. (Hamlet)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] no time profiling on my MacBookPro8,1
Whoops: I'm running Haskell Platform 2011.2.0.1. OS X 10.6.7 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) (if that matters?) Out of my depth here. On Fri, May 6, 2011 at 5:07 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: For this vanilla program module Main where main = print $ fib 40 fib 0 = 1 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) with these commands $ ghc -prof -auto-all -rtsopts -O --make Main.hs -o Main $ ./Main +RTS -p all of the %time cells in the generated Main.prof file are 0.0, as is the total time count (0.00 secs and 0 ticks). The %alloc cells seem normal. Andy Gill noticed that if you compile with -threaded, the %time cells seem normal. I scanned the GHC Trac tickets specific to Mac OS X, but saw no titles that looked similar. Is this a known issue? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] For Project Euler #1 isn't it more efficient to generate just the numbers you need? Spoiler
-- Instead of this -- sumMultiples3or5 s = sum [x | x - [3..s-1], x `mod` 3 == 0 || x `mod` 5 == 0] -- Isn't this faster sumMultiples3or5 s = sum ([x | x - [3,6..s-1]] `merge` [x | x - [5,10..s-1]]) merge xs [] = xs merge [] ys = ys merge txs@(x:xs) tys@(y:ys) | x y = x : xs `merge` tys | x y = y : txs `merge` ys | otherwise = x : xs `merge` ys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 probably lack the experience to do it on my own. Suggestions and help are of course welcome... Is the unix-compat package any good? Thanks for the suggestion. I'm not sure I totally understand how to use unix-compat, though. It gives me calls like getFdStatus :: Fd - IO FileStatus which is one of the things I need. But how do I get an Fd in the first place? (unix-compat seems to have no equivalent of openFd.) David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 iteratee, enumerator and enumeratee would go a hell of a long way here; Peaker on #haskell suggested Consumer/Producer/Transformer, and there is a lot of agreement in the channel that these are vastly better names. They’re also far less intimidating to users. I personally feel that maybe Transformer isn't such a great name (being closely associated with monad transformers), and that maybe something like Mapper would be better, but I'm by no means in love with that name either. More people in #haskell seem to like Transformer, and I don't think my argument against it is very strong, so the hivemind seems to have settled on the Producer/Transformer/Consumer trilogy. I'd love to hear thoughts on the issue, especially from David. The Producer/Consumer terminology, if I'm not mistaken, is usually applied to coroutine pairs. I use these terms myself in the SCC package, together with terms Transducer and Splitter. The former term is also well established, the latter was my own. Though I like and use this terminology, I'm not sure it's a good fit for the existing Enumerator/Iteratee pairs, which are not real symmetric coroutines. Enumerators are more like the Python (2.5) Generators. I don't know what the Python terminology would be for the Iteratee. On 11-05-06 12:47 PM, dm-list-haskell-c...@scs.stanford.edu wrote: This is a question I struggled a lot with. I definitely agree that the terms are pretty intimidating to new users. 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'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 Sink names as well. They are used not for coroutines directly, but instead for references to coroutines of the appropriate type. Every consumer thus owns a Source from which it fetches its input, and that Source is always bound to another coroutine that yields those values through a Sink. Source and Sink are a passive handle to a Producer and Consumer. I may be subjective, but I find this use of the terms very fitting. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot install error
epsilonhalbe wrote: hey haskellers, i'm fresh into haskell and love it. so to do faster easier haskell i wanted to install lambdabot but had to face some errors - i don't understand them at all here is some error output from zsh: http://hpaste.org/46401/bot_install_error can anyone help me - i'm working on a debian (crunchbang) y.t epsilonhalbe (ε/2) I ran into very similar problems on ubuntu 11.4. The culprit seems to be binutils version 2.21.something. (I think the assembler is suddenly more strict in some situations and aborts assembling with these error messages.) There is a related bug report in ghc's trac: [1]. According to that, you could try to remove the -fvia-C flag to prevent ghc from using the C backend. (I had no luck with that, so I guess there is still another bug lurking.) HTH, Sönke [1] http://hackage.haskell.org/trac/ghc/ticket/5050 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 Sink names as well. They are used not for coroutines directly, but instead for references to coroutines of the appropriate type. Every consumer thus owns a Source from which it fetches its input, and that Source is always bound to another coroutine that yields those values through a Sink. Source and Sink are a passive handle to a Producer and Consumer. I may be subjective, but I find this use of the terms very fitting. You mean fitting for references to coroutines, or fitting for the replacement names for Enumerator/Iteratee? If there's overwhelming consensus, I would certainly consider changing the names in the iterIO library, but it's a pretty big change... David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 intuition. The SCC package happens to use Source and Sink names as well. They are used not for coroutines directly, but instead for references to coroutines of the appropriate type. Every consumer thus owns a Source from which it fetches its input, and that Source is always bound to another coroutine that yields those values through a Sink. Source and Sink are a passive handle to a Producer and Consumer. I may be subjective, but I find this use of the terms very fitting. You mean fitting for references to coroutines, or fitting for the replacement names for Enumerator/Iteratee? The former, unfortunately. 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do exist globally available hosting project services?
Dear haskellers, I was reading the terms of service of the Haskell Community Server and found this statement: Users residing in countries on the United States Office of Foreign Assets Control sanction list, including Cuba, Iran, Libya, North Korea, Sudan and Syria, may not post or access CONTENT available through OUR services. I wonder whether there is a solution for hosting projects which does not discriminate people by their place of residence. http://code.haskell.org http://www.patch-tag.com https://github.com all seem to be ruled under USA laws. Would anybody recommend an alternative? Best, Facundo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do exist globally available hosting project services?
2011/5/7 Facundo Domínguez facundoming...@gmail.com: Dear haskellers, I was reading the terms of service of the Haskell Community Server and found this statement: Users residing in countries on the United States Office of Foreign Assets Control sanction list, including Cuba, Iran, Libya, North Korea, Sudan and Syria, may not post or access CONTENT available through OUR services. I wonder whether there is a solution for hosting projects which does not discriminate people by their place of residence. http://code.haskell.org http://www.patch-tag.com https://github.com all seem to be ruled under USA laws. Would anybody recommend an alternative? See the Countries Blocked column here: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
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 iteratee, enumerator and enumeratee would go a hell of a long way here; Peaker on #haskell suggested Consumer/Producer/Transformer, and there is a lot of agreement in the channel that these are vastly better names. They’re also far less intimidating to users. I personally feel that maybe Transformer isn't such a great name (being closely associated with monad transformers), and that maybe something like Mapper would be better, but I'm by no means in love with that name either. More people in #haskell seem to like Transformer, and I don't think my argument against it is very strong, so the hivemind seems to have settled on the Producer/Transformer/Consumer trilogy. I believe transducer is the proper term. (Of course, producers and consumers are both special cases of transducers, trivializing the input or output stream, respectively.) Though, IMO, I don't find the names producer and consumer enlightening as to why this particular pattern of iteration/enumeration is different from the conventional pattern found in OOP's iterators. Any time you have a bunch of things being created and passed around you have producers and consumers; the terminology is insufficient to define the pattern. The shift from iterator to enumerator helps to capture that difference. Given as there's no common name for the code calling an iterator, it's not immediately apparent what the push-based enumerative version should be called; iteratee seems as good as any other name, because it expresses the duality involved in the switch from the iterative style. control : pull, push producer : iterator, enumerator consumer : ???, iteratee Of course, this pattern of names suggests that enumeratee should properly be a backformation for naming the consumer of the pull-based iterative pattern. But then we're still left with the problem of what the transducers should be called in both cases. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For Project Euler #1 isn't it more efficient to generate just the numbers you need? Spoiler
If you're looking for efficiency, I believe you can actually do #1 in constant time: On Sat, May 7, 2011 at 7:31 AM, cas...@istar.ca wrote: -- Instead of this -- sumMultiples3or5 s = sum [x | x - [3..s-1], x `mod` 3 == 0 || x `mod` 5 == 0] -- Isn't this faster sumMultiples3or5 s = sum ([x | x - [3,6..s-1]] `merge` [x | x - [5,10..s-1]]) merge xs [] = xs merge [] ys = ys merge txs@(x:xs) tys@(y:ys) | x y = x : xs `merge` tys | x y = y : txs `merge` ys | otherwise = x : xs `merge` ys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
