Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
On 03/08/2010 10:45 PM, Wolfgang Jeltsch wrote: > The point is, of course, that such conversions are not only possible for > binary operations but for arbitrary values and that these conversions are > done > by a single generic function conv. I don’t think it would be possible to > implement conv without generalized newtype deriving. > > Any thoughts? > Hi Wolfgang, it's not exactly the same, but... > import Control.Applicative > > newtype Wrapped a = Wrap a deriving Show > > instance Functor Wrapped where > fmap f (Wrap x) = Wrap $ f x > > instance Applicative Wrapped where > pure = Wrap > (Wrap f) <*> (Wrap x) = Wrap $ f x > > convBinOp :: (a -> a -> a) -> (Wrapped a -> Wrapped a -> Wrapped a) > convBinOp op x y = pure op <*> x <*> y Best regards, Steffen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Real-time garbage collection for Haskell
On 2010-03-05 10:50 +0100 (Fri), Henning Thielemann wrote: > Curt Sampson schrieb: >> Understanding the general techniques for this sort of thing and seeing >> where you're likely to need to apply them isn't all that difficult, once >> you understand the problem. (It's probably much easier if you don't have >> to work it out all for yourself, as I did. Someone needs to write the >> "how to manage lazyness in Haskell" guide.) > > My attempt in this direction: > http://www.haskell.org/haskellwiki/Laziness_is_not_always_good > http://www.haskell.org/haskellwiki/Maintaining_laziness Unfortunately, neither of these address the problem of the day-to-day programmer: "what are the typical ways I introduce space leaks, and how do I stop doing that?" cjs -- Curt Sampson +81 90 7737 2974 http://www.starling-software.com The power of accurate observation is commonly called cynicism by those who have not got it.--George Bernard Shaw ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Real-time garbage collection for Haskell
On 2010-03-06 12:42 + (Sat), Simon Marlow wrote: > Usually I find keeping the nursery size (-A) close to the L2 cache size > works best, although sometimes making it really big can be even better. Interesting to know. I got the impression that I was being encouraged to keep -A closer to the L1 cache size, myself. > -qg disables parallel GC completely. This is usually terrible for > locality, because every GC will move all the recently allocated data > from each CPU's L2 cache into the cache of the CPU doing GC, where it > will have to be fetched out again after GC. I've since explained to Cranshaw (we are getting to have *way* too many 'Simon's around here) about the issues with our different machines; some of this depends on the host on which we're doing the testing. * Our Core i7 hosts share 8 MB of L3 cache amongst four cores with two threads each. Thus, no locality penalties here. * Our Xeon E5420 host has two 4-core CPUs, and each pair of cores shares a 6 MB L2 cache. Thus there's a pretty good chance that something you need is in someone else's cache. I don't know if there's any difference between moving stuff between two caches on the same CPU and two caches on different CPUs. * Our Xeon E5520 host has two 4-core CPUs, each core of which has two threads. Each CPU (4 cores) shares an 8 MB L3 cache. Thus, presumably, less locality penalty than the E5420 but more than an i7. As a side note, I also see slightly less memory bandwidth on this system (for both caches and main memory) than I do on an i7. This gets complex pretty fast. And don't ask me about Intel's new style of having L1 and L3 or L2 and L3 caches rather than L1 and L2 caches. > -qb disables load-balancing in the parallel GC, which improves locality > at the expense of parallelism, usually I find it is an improvement in > parallel programs. I'd think so too. Figuring out what went on here is going to have to wait until I get more detailed GC information in the eventlog. Followups to glasgow-haskell-us...@haskell.org. cjs -- Curt Sampson +81 90 7737 2974 http://www.starling-software.com The power of accurate observation is commonly called cynicism by those who have not got it.--George Bernard Shaw ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more thoughts on "Finally tagless"
Dear Jacques, you are right, I should have done so and will do my best not to repeat this error. Please accept my sincere apologies to Ken and yourself for my negligence, no offense was meant. Best regards Günther Am 09.03.10 03:37, schrieb Jacques Carette: Günther Schmidt wrote: In Olegs haskell implementation he is using classes mainly to model the syntax and instances to use for evaluators / compilers to allow multiple interpretations. When there are 3 authors on a paper (and in the implementation file), it is customary to acknowledge all 3, unless you have personal knowledge that one particular person did the work. In this case, the work was very much joint between Oleg, Ken and I. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more thoughts on "Finally tagless"
Günther Schmidt wrote: > In Olegs haskell implementation he is using classes mainly to model > the syntax and instances to use for evaluators / compilers to allow > multiple interpretations. When there are 3 authors on a paper (and in the implementation file), it is customary to acknowledge all 3, unless you have personal knowledge that one particular person did the work. In this case, the work was very much joint between Oleg, Ken and I. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more thoughts on "Finally tagless"
Stephen Tetley wrote: > The finally tagless style is an implementation of the TypeCase pattern > (Bruno C. d. S. Oliveira and Jeremy Gibbons): > One part of our work does that, yes. > The authors of the "Finally Tagless" note in the long version of their > paper that the GADT TypeCase had some problems with non-exhaustive > pattern matching (last paragraph, page 14) - if I'm understanding it > correctly, in order to be total, the interpretation function stills > needs to introduce pattern matching clauses in some circumstances for > values that the GADT actually prevents occurring. > You understand correctly. By using plain HM, augmented with either type classes or functors (to pass a higher-order dictionary around), all the redundant cases can be eliminated in a way that is transparent to the type system. To me, the parametricity in the 'interpreter' buys you more than what GADTs do. This was most definitely unexpected. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] file descriptors and handles
On Mar 8, 2010, at 14:26 , Mathijs Kwik wrote: it writes to the stdIn handle and closes it afterwards. - doesn't it need to close the fd as well? Once you've made a Handle from it, the Handle "owns" it; in particular, when the Handle is finalized it will close the fd. Also, attempting to use the fd for anything directly is likely to cause severe confusion to the process or file on the other end. the stdOut handle gets used when reading the command output (using hGetContents) - doesn't the handle need to get closed? or will this happen automatically if hGetContents finds EOF ? hGetContents automatically closes the Handle lazily. Will reading further output throw an exception or just think it's EOF? And what happens when closing the underlying FD? will the handle "break"? or will it close automatically? If you manually close the fd, the Handle will become unhappy and throw an exception. Don't touch an fd after performing an fdToHandle, or a Handle after performing a handleToFd (unless you are very certain about what you're doing, which is likely to require knowledge of how the GHC runtime's Handles work). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig 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] ptys and hGetContent problem
And to reply to myself again... ta <- getTerminalAttributes fd setTerminalAttributes fd (withoutMode ta EnableEcho) Immediately -- and to find the right EOF character: let Just eofChar = controlChar ta EndOfFile On Tue, Mar 9, 2010 at 12:23 AM, Mathijs Kwik wrote: > Ok, cool > > I got a bit further now. > I'm not using handles anymore (they seem to break indeed for ptys). > Just using executePseudoTerminalFd now (from the original blogpost) > and fdRead/fdWrite. > Now I can communicate with the process and all goes well. > If I really want lazy-like behaviour, I can just forkIo and talk > through a Chan, but for now this is enough. > > Also sending "\^C" and "\^D" work as expected, although I just saw the > reply mentioning I should ask stty for the current EOF character. > > The only thing I'm still looking for is a way to stop echoing input. > Right now, fdRead gives me back the output of the process, mixed with > the input I supplied. > I'm pretty sure this can be turned off. > > Any suggestions? > > > On Mon, Mar 8, 2010 at 11:11 PM, Nick Bowler wrote: >> On 20:38 Mon 08 Mar , Mathijs Kwik wrote: >>> Hi all, >>> >>> I found this blogpost from Bryan O'Sullivan >>> http://www.serpentine.com/blog/2008/09/30/unix-hacking-in-haskell-better-pseudoterminal-support/ >>> and I wanted to try it out. >>> >>> Before moving to an interactive command (which needs pty), I just did >>> a small test for "ls -l /" to see if it worked. >>> I got it to compile, but when running, it throws an exception when >>> reaching the end of the output (in this case because I evaluate the >>> length to force reading all). >>> Main: /dev/ptmx: hGetContents: hardware fault (Input/output error) >> >> You have just stumbled into the wonderful world of pseudo-terminals, >> where their behaviour is subtly different on every bloody platform. It >> appears that on your platform, after the last user closes the slave port >> (i.e. after your child process terminates), subsequent reads from the >> master port return EIO. >> >> One would normally detect this condition with the poll system call, by >> looking for POLLHUP on the master port. >> >> On some platforms (but evidently not yours), the last close of the slave >> port causes the behaviour you seem to have expected, where a subsequent >> read returns 0. >> >>> What's wrong? :) >> >> Presumably the problem is that handle-based I/O is not suitable for >> pseudo-terminal masters. Definitely not lazy I/O. >> >>> And further... >>> If I do want to use an interactive program which needs input, how do I >>> send ctrl-d or ctrl-c? >>> tail -f needs ctrl-c (or I need to kill the process) >> >> These so-called "control characters" are normally configured by termios. >> If suitably configured, the appropriate action will be performed when >> the control characters are written to the master port. >> >> -- >> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ptys and hGetContent problem
Ok, cool I got a bit further now. I'm not using handles anymore (they seem to break indeed for ptys). Just using executePseudoTerminalFd now (from the original blogpost) and fdRead/fdWrite. Now I can communicate with the process and all goes well. If I really want lazy-like behaviour, I can just forkIo and talk through a Chan, but for now this is enough. Also sending "\^C" and "\^D" work as expected, although I just saw the reply mentioning I should ask stty for the current EOF character. The only thing I'm still looking for is a way to stop echoing input. Right now, fdRead gives me back the output of the process, mixed with the input I supplied. I'm pretty sure this can be turned off. Any suggestions? On Mon, Mar 8, 2010 at 11:11 PM, Nick Bowler wrote: > On 20:38 Mon 08 Mar , Mathijs Kwik wrote: >> Hi all, >> >> I found this blogpost from Bryan O'Sullivan >> http://www.serpentine.com/blog/2008/09/30/unix-hacking-in-haskell-better-pseudoterminal-support/ >> and I wanted to try it out. >> >> Before moving to an interactive command (which needs pty), I just did >> a small test for "ls -l /" to see if it worked. >> I got it to compile, but when running, it throws an exception when >> reaching the end of the output (in this case because I evaluate the >> length to force reading all). >> Main: /dev/ptmx: hGetContents: hardware fault (Input/output error) > > You have just stumbled into the wonderful world of pseudo-terminals, > where their behaviour is subtly different on every bloody platform. It > appears that on your platform, after the last user closes the slave port > (i.e. after your child process terminates), subsequent reads from the > master port return EIO. > > One would normally detect this condition with the poll system call, by > looking for POLLHUP on the master port. > > On some platforms (but evidently not yours), the last close of the slave > port causes the behaviour you seem to have expected, where a subsequent > read returns 0. > >> What's wrong? :) > > Presumably the problem is that handle-based I/O is not suitable for > pseudo-terminal masters. Definitely not lazy I/O. > >> And further... >> If I do want to use an interactive program which needs input, how do I >> send ctrl-d or ctrl-c? >> tail -f needs ctrl-c (or I need to kill the process) > > These so-called "control characters" are normally configured by termios. > If suitably configured, the appropriate action will be performed when > the control characters are written to the master port. > > -- > Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Num instance for Lazy ByteStrings (was: NumLazyByteString Package License)
> Is NumLazyByteString a newtype around Bytestring.Lazy that interprets the > bit stream represented by the ByteString as integer? Not exactly. There is not newtype wrapper. NumLazyByteString is: instance Num L.ByteString where ... instance Enum L.ByteString where ... instance Integral L.ByteString where ... instance Bits L.ByteString where ... > If so, could this also > be done using a newtype around [Integer], where appropriately large Integers > are used? If yes, you may find > http://code.haskell.org/numeric-prelude/src/Number/Positional.hs > useful. Thanks for the pointer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Books for "advanced" Haskell
On 04/03/2010, at 8:28 PM, Curt Sampson wrote: > ... I recommend reading "The Typeclassopedia,"[1], which will > introduce you to all of the monad's friends and family. > > [1]: http://byorgey.wordpress.com/2009/03/16/monadreader-13-is-out/ I'd love to read a book-length version of the Typeclassopedia, with more examples of applications of the various type classes, and pitched at a more ignorant reader (like myself). Tom___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ptys and hGetContent problem
On Mar 9, 2010, at 9:35 AM, Ivan Lazar Miljenovic wrote: And further... If I do want to use an interactive program which needs input, how do I send ctrl-d or ctrl-c? tail -f needs ctrl-c (or I need to kill the process) You want Ctrl-d in Unix-based OSs and Ctrl-z in Windows: http://en.wikipedia.org/wiki/End_of_File . Ctrl-c kills a program. The statement about UNIX is not quite right. UNIX has *NO FIXED END-OF-FILE CHARACTER*. Strictly speaking, it doesn't have an end-of-file character at all. What the UNIX terminal driver (and interfaces that emulate it) has is a "send this line now with no terminator" character. abcd sends "abcd" to the program sans \n ab sends "ab" to the program sans \n sends "" to the program Program does n = read(0, buffer, sizeof buffer); User types ab buffer gets "ab", n gets 2. Program does if (n == 0) handle_eof(); which does nothing. Program calls read again, User types buffer gets no data, n gets 0, program tests n against 0 and goes off to do the EOF thing. So the character *only* means when nothing precedes it on the current line. Why do I write rather than ^D? Because nothing in UNIX anywhere says that *has* to be ^D, it's just a default. Back in the old V6 days, I saw no more reason to stick with that default than I saw to stick with the default of '#' for character erase and '@' for line kill. I've been using ^Z for in UNIX longer than Windows (or DOS before it) has _existed_. If you want to know what character to send for end-of-file when communicating with a UNIX system, use stty(1) to find out what the character actually is. Insisting on ^D is not just wrong, it's rude. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Am Montag, 8. März 2010 22:45:19 schrieb Wolfgang Jeltsch:
> Hello,
>
> some time ago, it was pointed out that generalized newtype deriving could
> be used to circumvent module borders. Now, I found out that generalized
> newtype deriving can even be used to define functions that would be
> impossible to define otherwise. To me, this is surprising since I thought
> that generalized newtype deriving was only intended to save the programmer
> from writing boilerplate code, not to extend expressiveness.
>
> Have a look at the following code:
> > {-# LANGUAGE
> > GeneralizedNewtypeDeriving,
> > MultiParamTypeClasses,
> > FlexibleInstances
> > #-}
> >
> > class Iso a b where
> >
> > conv :: item a -> item b
> >
> > instance Iso a a where
> >
> > conv = id
> >
> > newtype Wrapped a = Wrap a deriving (Iso a, Show)
>
> Now any value whose type contains some type t can be converted into a value
> of the type that you get if you replace t by Wrap t. Here is some code to
> demonstrate this for binary operations:
>
> > newtype BinOp a = BinOp (a -> a -> a)
> >
> > convBinOp :: (a -> a -> a) -> (Wrapped a -> Wrapped a -> Wrapped a)
> > convBinOp op = let BinOp op' = conv (BinOp op) in op'
>
> Now, you can enter
>
> convBinOp (*) (Wrap 5) (Wrap 3)
>
> into GHCi, and you will get
>
> Wrap 15
>
> as the result.
>
> The point is, of course, that such conversions are not only possible for
> binary operations but for arbitrary values and that these conversions are
> done by a single generic function conv. I don’t think it would be possible
> to implement conv without generalized newtype deriving.
Generalized newtype deriving doesn’t just allow otherwise undefinable functions
to be defined. It probably also allows for faster function implementations. For
example, with the above conv method, you could probably convert a list of some
type [t] into a list of type [Wrapped t] in O(1) time. If you would code this
conversion by hand, it would take O(n) time, of course.
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cabal dependency hell
On Mon, 2010-03-08 at 15:37 +0100, Marc Weber wrote: > Hi Maciej, > > that's why I started hack-nix. > > You can patch dependencies easily. > > However you have to install the Nix package manager. > > It also works with lates versions only because the dependency solves is > written in Nix itself. > > Which package is causing trouble to you? > For example happstack. > We can't expect package maintainers to test everything. > So it must be people like you and me who fixes those changes. > Well. Except that it require bumping versions. Which according to hackage policy requires to fork a project (which makes it pointless in the first place) > The way to go is make hackage allow changing constraints on the fly > notifying the author that he can update his repository. > > This will work in most cases. > > Bumping versions because a dependency has changed is bad as well. > > This will cause to much overhead (and it dosen't solve the problem > because the old package is still wrong). > > Specifying dependencies must be decoupled from bumping versions. > > It's because dep specs do depend on the "world" which can change.. > > At least that's what I think. > Hmm. When I was returning home I thought about some wiki-like system that would allow to say 'Package X is compatible/not compatible with Y'. Possibly something like: - Only the 'sure' deps are installed in default mode - When in 'expert' mode I can install any package which has not been marked as incompatible Then I can say that I tested built and: - It failed to built - It failed the automatic tests (if they exists)/does not work - It success So if there is versions: 0.7 0.8 0.9 1.0 1.0.1 1.1 1.2 1.3 1.4 And: - 0.8 failed to built - >=1.0 <1.1 was marked by author - 1.1 was marked as success - 1.3 failed to build Then - In default/normal mode it can be used with 1.0, 1.0.1 and 1.1 - In expert mode 0.9 and 1.2 can be installed in addition to above - Any version can be installed in 'I'm feeling lucky' mode when I explicitly say package to ignore some restriction Possibly it is needed to collect user karma (or possibly already account verification is sufficient). > If you're interested in Nix and hack-nix I can show you how everything > works using an SSH session. > Ekhm... SSH? > Marc Weber 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] Num instance for Lazy ByteStrings (was: NumLazyByteString Package License)
On Mon, 8 Mar 2010, Thomas DuBuisson wrote: Tristan and other interested parties on the Cafe, Answering your question first, Tristan: I was going to use BSD3 (if it isn't already) for the NumLazyByteString. Is NumLazyByteString a newtype around Bytestring.Lazy that interprets the bit stream represented by the ByteString as integer? If so, could this also be done using a newtype around [Integer], where appropriately large Integers are used? If yes, you may find http://code.haskell.org/numeric-prelude/src/Number/Positional.hs useful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell course, training
On Sun, 7 Mar 2010, G?nther Schmidt wrote: I think I've reached the point where I need some tutoring, so provided I've got money for travel and course fees, and time, where do I get it? I'm not a student so some courses aren't available to me. How about visiting our Haskell meeting in Leipzig, June 4th? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ptys and hGetContent problem
On 20:38 Mon 08 Mar , Mathijs Kwik wrote: > Hi all, > > I found this blogpost from Bryan O'Sullivan > http://www.serpentine.com/blog/2008/09/30/unix-hacking-in-haskell-better-pseudoterminal-support/ > and I wanted to try it out. > > Before moving to an interactive command (which needs pty), I just did > a small test for "ls -l /" to see if it worked. > I got it to compile, but when running, it throws an exception when > reaching the end of the output (in this case because I evaluate the > length to force reading all). > Main: /dev/ptmx: hGetContents: hardware fault (Input/output error) You have just stumbled into the wonderful world of pseudo-terminals, where their behaviour is subtly different on every bloody platform. It appears that on your platform, after the last user closes the slave port (i.e. after your child process terminates), subsequent reads from the master port return EIO. One would normally detect this condition with the poll system call, by looking for POLLHUP on the master port. On some platforms (but evidently not yours), the last close of the slave port causes the behaviour you seem to have expected, where a subsequent read returns 0. > What's wrong? :) Presumably the problem is that handle-based I/O is not suitable for pseudo-terminal masters. Definitely not lazy I/O. > And further... > If I do want to use an interactive program which needs input, how do I > send ctrl-d or ctrl-c? > tail -f needs ctrl-c (or I need to kill the process) These so-called "control characters" are normally configured by termios. If suitably configured, the appropriate action will be performed when the control characters are written to the master port. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Hello,
some time ago, it was pointed out that generalized newtype deriving could be
used to circumvent module borders. Now, I found out that generalized newtype
deriving can even be used to define functions that would be impossible to
define
otherwise. To me, this is surprising since I thought that generalized newtype
deriving was only intended to save the programmer from writing boilerplate
code, not to extend expressiveness.
Have a look at the following code:
> {-# LANGUAGE
> GeneralizedNewtypeDeriving,
> MultiParamTypeClasses,
> FlexibleInstances
> #-}
>
> class Iso a b where
>
> conv :: item a -> item b
>
> instance Iso a a where
>
> conv = id
>
> newtype Wrapped a = Wrap a deriving (Iso a, Show)
Now any value whose type contains some type t can be converted into a value of
the type that you get if you replace t by Wrap t. Here is some code to
demonstrate this for binary operations:
> newtype BinOp a = BinOp (a -> a -> a)
>
> convBinOp :: (a -> a -> a) -> (Wrapped a -> Wrapped a -> Wrapped a)
> convBinOp op = let BinOp op' = conv (BinOp op) in op'
Now, you can enter
convBinOp (*) (Wrap 5) (Wrap 3)
into GHCi, and you will get
Wrap 15
as the result.
The point is, of course, that such conversions are not only possible for
binary operations but for arbitrary values and that these conversions are done
by a single generic function conv. I don’t think it would be possible to
implement conv without generalized newtype deriving.
Any thoughts?
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 152 - March 08, 2010
--- Haskell Weekly News http://sequence.complete.org/hwn/20100308 Issue 152 - March 08, 2010 --- Welcome to issue 152 of HWN, a newsletter covering developments in the [1]Haskell community. Hello Haskellers, this week brings updates to some standards (like Parsec), as well as some new tunes to the Haskell songbook. WAI and Yesod were released, giving some new options for Haskell-based web applications, Don Stewart made some improvements to his Genetic Optimizer system to include options from GHC's new LLVM backend, and I made some serious progress on the new HWN software. Speaking of the new software, there have been numerous reports of warts and other unfortunate things with the current editions of the HWN. Fear not, these warts are well known and being worked on intently. Unfortunately, it's somewhat difficult to fix them given the current publication software, however, in the new-and-improved version that (hopefully) should be entering use soon, these warts will be removed. So, without further interuption about the stylistic content, Haskellers, your Haskell Weekly News! Announcements Bluetile 0.3.1. Jan Vornberger [2]announced Bluetile, an adaptation of xmonad for the masses. Bluetile aims to make tiling window managers accessible by drawing on standard window manager conventions and idioms. ED: This is not technically an announcement, but it's very cool and everyone should check it out! yesod 0.0.0 (web framework). Michael Snoyman [3]announced the release of yesod, a web framework based on WAI. wai-0.0.0 (Web Application Interface). Michael Snoyman [4]announced the first release of wai, a library implementing the WAI protocol. iteratee-parsec 0.0.2. Maciej Piechotka [5]announced iteratee-parsec, a library which allows for parsec parsers in the IterateeG monad. Parsec 3.1.0. Derek Elkins [6]announced a new release of Parsec, containing many improvments due (primarily) to Antoine Latter. Progression-0.3 (supporting benchmarking in Haskell). Neil Brown [7]announced a new release of Progression. Progression is a utility built on top of Criterion for recording benchmarks for several version of your code. Ghent Functional Programming Group: First Meeting on April 1, 2010. Jeroen Janssen [8]announced the first meeting of the Ghent Functional Programming group, see the post for location and time details. PhD position in Functional Programming at Chalmers (deadline 2010-04-07). Patrik Jansson [9]announced an opening for a PhD student at Chalmers, working in Functional Programming and DSELs. VSTTE 2010: Verified Software -- Third Call for Papers. Gudmund Grov [10]announced a third CFP for VSTTE 2010, the Third International Conference on Verified Software: Theories, Tools, and Experiments. barchart-0.1.1. Sebastian Fischer [11]announced barchart, a command line program with an associated library for generating bar charts. Call for Participation: CHR Summer School. Jon Sneyers [12]announced a call for participation in the CHR Summer School on Programming and Reasoning with Rules and Constraints. Discussion Free theorem - what do we need it for. Maciej Piechotka [13]asked about Free Theorems and what they were good for. Has anybody translated Douglas Hofstadter's Scientific American articles introducting Scheme to a general audience into Haskell? Benjamin L. Russell [14]asked if anyone had considered translating Douglas Hofstadter's SciAm articles introducting Scheme to Haskell. Evolving Faster Haskell Programs (now with LLVM!). Don Stewart [15]our resident speed demon is at it again, harnessing the new LLVM backend of GHC and the power of Natural Selection to make his programs go even faster. Blog noise [16]Haskell news from the [17]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Neil Brown: [18]Synchronous Channels using MVars. * "FP Lunch": [19]Causal Semantics of (A)FRP. * Darcs: [20]darcs weekly news #56. * Dan Piponi (sigfpe): [21]Products, Limits and Parametric Polymorphism. * Bryn Keller: [22]Real World Haskell. * Isaac Dupree: [23]Next Project, Move doc-parsing to from GHC to Haddock. * Isaac Dupree: [24]Summer of Code Wrap-Up.. * Isaac Dupree: [25]Status update. * Isaac Dupree: [26]platform progress. * Isaac Dupree: [27]another boring update, & question :-). * Isaac Dupree: [28]How To Navigate Your Code:. * Michael Snoyman: [29]Persistence. * Neil Brown: [30]Choice over Events using STM. * Michael Snoyman: [31]Tweedle Beetle Battle. * Galois, Inc: [32]The Semantics of
[Haskell-cafe] Mini-announce: AC-Color 1.1.3
I just uploaded a new version of the ever-unpopular AC-Colour package. (Yes, there's a country where it's spelled that way.) What it already did: Provides a simple strict unboxed RGB colour type, with arithmetic. The three channels can be either Double or Word8. (And there's some low-level hackery to convert between the two. For some reason just using "floor" is awesomely slow, but talking to GHC.Prim directly is much, much faster... which unfortunately makes this package far less portable than it should be!) What it does now: Colour maps. Give it some control points, and it'll (linearly) interpolate between them to give you a function Double -> Colour. (I haven't seen anything else on Hackage that will do this out-of-the-box. I've seen linear blends between two colours, but not fully automatic piece-wise linear maps like this.) Now obviously none of this is terribly earth-shattering. But I find myself needing this often enough that it's annoying to have to spend 10 minutes coding and debugging it every single time I want it. Maybe somebody else will find a use for it too. I paid special attention to trying to make the colour maps as general as possible. (E.g., the parameter range isn't limited to [0..1], it's arbitrary. Going off the end of the range produces sensible results. You can make the map loop. And so on.) Maybe if I'm feeling ambitious I'll try 2D colour maps. (Of course, the problem there is that your control points need not be coplanar - or even form a regular grid!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more thoughts on "Finally tagless"
Hi Günther The finally tagless style is an implementation of the TypeCase pattern (Bruno C. d. S. Oliveira and Jeremy Gibbons): http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/typecase.pdf TypeCase can be implemented via GADTs or type classes - typed printf in section 4.2 of the paper is shown in both versions. The authors of the "Finally Tagless" note in the long version of their paper that the GADT TypeCase had some problems with non-exhaustive pattern matching (last paragraph, page 14) - if I'm understanding it correctly, in order to be total, the interpretation function stills needs to introduce pattern matching clauses in some circumstances for values that the GADT actually prevents occurring. Plain old data types can easily be interpreted by multiple evaluators - the benefit of TypeCase is probably when you want some degree of extensibility, see this message for instance: http://www.haskell.org/pipermail/haskell-cafe/2008-July/045028.html Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ptys and hGetContent problem
> And further... > If I do want to use an interactive program which needs input, how do I > send ctrl-d or ctrl-c? > tail -f needs ctrl-c (or I need to kill the process) You want Ctrl-d in Unix-based OSs and Ctrl-z in Windows: http://en.wikipedia.org/wiki/End_of_File . Ctrl-c kills a program. -- 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] more thoughts on "Finally tagless"
> Yeah, subject "Finally Tagless" again, sorry, I'm just not done with it yet.
>
> In Olegs haskell implementation he is using classes mainly to model the
> syntax and instances to use for evaluators / compilers to allow multiple
> interpretations.
>
> I wonder if it'd be possible to do the same without classes using data types
> instead?
>
> Something similar to what Luke Palmer has done here:
>
> http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/
Günther,
You can just use the dictionary translation of type classes to replace
them with data types:
E.g.
class Eval sem where
val :: Int -> sem Int
add :: sem Int -> sem Int -> sem Int
>-->
data EvalDict sem = EvalDict { val :: Int -> sem Int, add :: sem Int
-> sem Int -> sem Int }
Cheers,
Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: search Data.Tree.Zipper
I somehow cannot figure this out. Tree is Foldable so I can use "find" on it. But how can I use find on TreeLoc? Am I missing something obvious? Dan Weston wrote: > I think you want > > find :: Foldable t => (a -> Bool) -> t a -> Maybe a > > > Jian Fan wrote: >> Hi, >> >> There doesn't seem to be a function to search the tree so >> I come up with following function: >> >> searchTree :: (a -> Bool) -> TreeLoc a -> Maybe (TreeLoc a) >> searchTree pred rootLoc = >> if pred (getLabel rootLoc) then >> Just rootLoc >> else case firstChild rootLoc of >> Just loc -> case searchTree pred loc of >> Just loc -> Just loc >> Nothing -> case right loc of >> Just rLoc -> searchTree pred rLoc >> Nothing -> Nothing >> Nothing -> Nothing >> >> Which feels quite ugly. Any suggestions? Thanks. >> >> Jian >> >> ___ >> 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] Re: [Haskell] Recursive definition of fibonacci with Data.Vector
On Sun, 7 Mar 2010, Edgar Z. Alvarenga wrote: Hello, why I can't define a recursive vector using Data.Vector, like in the example: import qualified Data.Vector as V let fib = 0 `V.cons` (1 `V.cons` V.zipWith (+) fib (V.tail v)) Since I liked to have both element-wise lazy construction and packed data, I created a data-structure for that purpose: http://code.haskell.org/storablevector/Data/StorableVector/Cursor.hs However, those vectors/arrays are finite, but could be extended to a chunky infinite structure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ptys and hGetContent problem
Hi all, I found this blogpost from Bryan O'Sullivan http://www.serpentine.com/blog/2008/09/30/unix-hacking-in-haskell-better-pseudoterminal-support/ and I wanted to try it out. Before moving to an interactive command (which needs pty), I just did a small test for "ls -l /" to see if it worked. I got it to compile, but when running, it throws an exception when reaching the end of the output (in this case because I evaluate the length to force reading all). Main: /dev/ptmx: hGetContents: hardware fault (Input/output error) Please have a look at the hpaste to see what I did: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=23343 What's wrong? :) My guess is that hGetContents doesn't receive a nice EOF when the process exits (ls doesn't stay around waiting for input), but I have no idea on how to fix this. And further... If I do want to use an interactive program which needs input, how do I send ctrl-d or ctrl-c? tail -f needs ctrl-c (or I need to kill the process) Thanks for any help Mathijs PS: I know about libexpect, it's not useful for what I wanna do (multiple processes, having 'answers' from 1 be used to decide what to input the other, without ending the 'answer' process) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] more thoughts on "Finally tagless"
Hi all, and Oleg et al in particular. Yeah, subject "Finally Tagless" again, sorry, I'm just not done with it yet. In Olegs haskell implementation he is using classes mainly to model the syntax and instances to use for evaluators / compilers to allow multiple interpretations. I wonder if it'd be possible to do the same without classes using data types instead? Something similar to what Luke Palmer has done here: http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] search Data.Tree.Zipper
I think you want find :: Foldable t => (a -> Bool) -> t a -> Maybe a Jian Fan wrote: Hi, There doesn't seem to be a function to search the tree so I come up with following function: searchTree :: (a -> Bool) -> TreeLoc a -> Maybe (TreeLoc a) searchTree pred rootLoc = if pred (getLabel rootLoc) then Just rootLoc else case firstChild rootLoc of Just loc -> case searchTree pred loc of Just loc -> Just loc Nothing -> case right loc of Just rLoc -> searchTree pred rLoc Nothing -> Nothing Nothing -> Nothing Which feels quite ugly. Any suggestions? Thanks. Jian ___ 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] file descriptors and handles
Hi all, Today I had a look at chapter 20 of RWH. The extended example (stripped down HSH) in the end is great. I think I understand it, but I have some questions left: the master process closes the client-sided FD's. it uses fdToHandle for the other sides of the pipe to get a handle to stdIn and stdOut on the client process. it writes to the stdIn handle and closes it afterwards. - doesn't it need to close the fd as well? the stdOut handle gets used when reading the command output (using hGetContents) - doesn't the handle need to get closed? or will this happen automatically if hGetContents finds EOF ? - and also here, shouldn't the fd get closed? More general: what happens when closing a handle when there's still output left? Will reading further output throw an exception or just think it's EOF? And what happens when closing the underlying FD? will the handle "break"? or will it close automatically? Thanks for any help Mathijs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] search Data.Tree.Zipper
I haven't tested it, but I think you're looking for something like this: searchTree2 :: (a -> Bool) -> TreeLoc a -> Maybe (TreeLoc a) searchTree2 pred rootLoc = if pred (getLabel rootLoc) then Just rootLoc else firstChild rootLoc >>= siblings where siblings loc = searchTree2 pred loc `mplus` (searchTree2 pred =<< right loc) On Mon, Mar 8, 2010 at 1:11 PM, Jian Fan wrote: > Hi, > > There doesn't seem to be a function to search the tree so > I come up with following function: > > searchTree :: (a -> Bool) -> TreeLoc a -> Maybe (TreeLoc a) > searchTree pred rootLoc = > if pred (getLabel rootLoc) then > Just rootLoc > else case firstChild rootLoc of > Just loc -> case searchTree pred loc of > Just loc -> Just loc > Nothing -> case right loc of > Just rLoc -> searchTree pred rLoc > Nothing -> Nothing > Nothing -> Nothing > > Which feels quite ugly. Any suggestions? Thanks. > > Jian > > ___ > 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] search Data.Tree.Zipper
Hi, There doesn't seem to be a function to search the tree so I come up with following function: searchTree :: (a -> Bool) -> TreeLoc a -> Maybe (TreeLoc a) searchTree pred rootLoc = if pred (getLabel rootLoc) then Just rootLoc else case firstChild rootLoc of Just loc -> case searchTree pred loc of Just loc -> Just loc Nothing -> case right loc of Just rLoc -> searchTree pred rLoc Nothing -> Nothing Nothing -> Nothing Which feels quite ugly. Any suggestions? Thanks. Jian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal-install
Peter Robinson wrote: On 8 March 2010 17:51, Andrew Coppin wrote: Anyway, can anybody tell me how I can change the default settings so that I get profiling libraries built by default, and Haddock documentation built by default? (I'm on Windows, in case that makes a difference...) # cabal install --help shows you options like: --enable-library-profiling Enable Library profiling --enable-documentation Enable building of documentation If you want these settings permanently you need to locate your config file (I don't know where it is on Windows...) Perhaps it's My Documents\.cabal or something? Oh no, wait a sec: E:\> cabal --help ... D:\Documents and Settings\User\Application Data\cabal\config ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal-install
Miguel Mitrofanov wrote: See http://www.haskell.org/cabal/ for more information. ^ | + Oh, sure, like I haven't already tried *that*. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal-install
MigMit:~ MigMit$ cabal --help This program is the command line interface to the Haskell Cabal infrastructure. See http://www.haskell.org/cabal/ for more information. ^ | + On 8 Mar 2010, at 19:51, Andrew Coppin wrote: OK, so apparently my Google skills are lacking. I can't find anything but the most terse documentation of the cabal-install tool online. Somewhere there surely must be something which explains how to control this thing. Anyway, can anybody tell me how I can change the default settings so that I get profiling libraries built by default, and Haddock documentation built by default? (I'm on Windows, in case that makes a difference...) ___ 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] Num instance for Lazy ByteStrings (was: NumLazyByteString Package License)
Tristan and other interested parties on the Cafe, Answering your question first, Tristan: I was going to use BSD3 (if it isn't already) for the NumLazyByteString. For the cafe too: A while ago I made a Num instance for LPS; it is currently on my code.haskell.org account. Notice this isn't on Hackage yet and the semantics will be different soon. Most notably I want to ensure divide and anything else implemented through 'asInteger' and 'asInteger2' results in a bytestring of length equal to the largest of the operands. If that isn't clear then let me be very explicit. NumLazyByteString intentionally allows overflow! If you want operations (mod 2^40) then you need only work with bytestrings of length 5 bytes and the operations will result in 5 byte ByteString. This is already true for basic operations (bit operations, +, -, *) but is not yet done for quot, rem, quotRem, divMod, mod, /, and other you can see leverage Integer instead of using custom code. Any desire for non-overflowing operations (basically, re-expressing Integer as LazyByteString) would have to be done as an newtype with a Num instance that grows the bytestring to the necessary level, preventing overflow prior to calling NumLazyByteString. Finally, I intend for numerous operations to be lazy. If you add two infinite bytestrings you should be able to get the result of that operation (modulo some finite value) using NumLazyByteString. This is obviously not true for those operations leveraging Integer. Any comments or requests on the future of this Library are welcome - I'll probably get around to finishing it and putting it on Hackage in a couple weeks. Cheers, Thomas On Sun, Mar 7, 2010 at 9:24 PM, Tristan Ravitch wrote: > I found myself adding Bits and Num instances for ByteStrings when I > found your implementation (which is much better than mine was shaping > up to be). Do you have any particular license in mind for it? > > I used it in an implementation of the Delta Debugging algorithm > (http://www.st.cs.uni-saarland.de/dd/), which I was thinking I would > like to release, and wanted to make sure the licensing could work out > properly. > > Thanks, > -- > Tristan Ravitch > travi...@cs.wisc.edu > http://pages.cs.wisc.edu/~travitch > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkuUiiUACgkQJklRJNuIcWSxmACfVblD+gR/Fv57teNTArSfXhHg > NtsAnRqBvinNesMk3mxMxDERw5MBn9jZ > =Jm4O > -END PGP SIGNATURE- > > signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal-install
On 8 March 2010 17:51, Andrew Coppin wrote: > Anyway, can anybody tell me how I can change the default settings so that I > get profiling libraries built by default, and Haddock documentation built by > default? > > (I'm on Windows, in case that makes a difference...) # cabal install --help shows you options like: --enable-library-profiling Enable Library profiling --enable-documentation Enable building of documentation If you want these settings permanently you need to locate your config file (I don't know where it is on Windows...) Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal-install
OK, so apparently my Google skills are lacking. I can't find anything but the most terse documentation of the cabal-install tool online. Somewhere there surely must be something which explains how to control this thing. Anyway, can anybody tell me how I can change the default settings so that I get profiling libraries built by default, and Haddock documentation built by default? (I'm on Windows, in case that makes a difference...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Books for "advanced" Haskell
On Sun, Mar 7, 2010 at 10:53 PM, Stephen Tetley wrote: > Hi All > > What is the state-of-the-practice in type-level programming? > > I know Günther started this thread about monads, but I seem to > remember him having a long running problem with "typeful" database > programming, and I wonder if some of his problems are really in the > later area. Compared to monads, type-level programming seems much more > a wild frontier - scattered docs, fewer definitive examples, no > de-facto standard library. So I want the book describes how to make type-level programming up to the practice. I think this would cover how to provide simple interface for types and contexts with full benefits, how to produce friendly error message in type-errors, when to use UndecidableInstances, and how to get rid of such itchy things. -nwn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
Hi Maciej, that's why I started hack-nix. You can patch dependencies easily. However you have to install the Nix package manager. It also works with lates versions only because the dependency solves is written in Nix itself. Which package is causing trouble to you? We can't expect package maintainers to test everything. So it must be people like you and me who fixes those changes. The way to go is make hackage allow changing constraints on the fly notifying the author that he can update his repository. This will work in most cases. Bumping versions because a dependency has changed is bad as well. This will cause to much overhead (and it dosen't solve the problem because the old package is still wrong). Specifying dependencies must be decoupled from bumping versions. It's because dep specs do depend on the "world" which can change.. At least that's what I think. If you're interested in Nix and hack-nix I can show you how everything works using an SSH session. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
Hello Maciej, Monday, March 8, 2010, 4:33:08 PM, you wrote: > PS. I understand that content may be flame-gen. I am sorry in advance if > such circumstances happen. However I believe that possible improvements > in process are worth the risk. i was the author of this idea and i thought that 1) package author should allow to use only versions of dependence that he know will work 2) if new version of dependence arrives, package author should upload minor update of his package that allows to use it -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc leaking memory?
On 08/03/2010 13:30, Joachim Breitner wrote: Hi Simon, Am Montag, den 08.03.2010, 11:07 + schrieb Simon Marlow: On Sat, Mar 6, 2010 at 11:57 AM, Joachim Breitner wrote: Hi, in Debian, we are having some problems building large libraries (such as agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, armel, s390) which compile with -fvia-C, especially when building the profiling libraries. In the case of highlighting-kate, there were really issues with the code: A huge list of words which ghc seemed to try to inline caused it consuming a lot of memory. But in the case of agda, it even fails with relatively small modules: https://buildd.debian.org/fetch.cgi?pkg=agda&arch=sparc&ver=2.2.6-3&stamp=1267334936&file=log&as=raw Now, looking at the memory gauge on my computer while compiling such a program with Cabal (which compiles all modules in one ghc call), it looks like it is steadily increasing. I’d expect ghc to free a lot of memory when it is done with a module, but this does not seem to be the case. Is this a bug (i.e. memory leak) in ghc or expected behavior? Can you verify that it is GHC leaking memory, and not gcc? I recommend turning off -fvia-C in particular unless you're sure that you need it. Sorry if I was not clear: The issues arise on “strange” architectures (armel, s390, sparc, mips) where, as far as I know, -fvia-C is the only option and thus the default. I was not setting this flag myself. Ah, I see. Isn’t GHC calling gcc once for each module? In that case, that can not leak across modules, can it? Right, gcc is only being invoked once per module, but the files being sent to gcc can get quite large, particularly when profiling is enabled, and even a single run of gcc can grow very large. This has been more of a problem with the newer gcc versions since they changed their memory manager and started doing whole-module optimisations (though we do try to disable this with -fno-toplevel-reorder, I'm not sure if that disbales module-at-a-time compilation completely). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal dependency hell
While I love Haskell it's packaging system have some problems - especially with parsec. Currently I'm not able to install an practically anything using cabal due to version mismatches (or at least packages linking to both version of parsec). I found the following problems in various cabal packages (the examples are only examples - please do not be offended): - The constraints are too loose. It is written that package works with '>0.6 && <1' but in 0.8 the API has been changed (example of tagsoup & hxt. Fixed hxt versions depends on ghc 6.12... and ghc 6.10 if you change 2 lines in cabal file) - The constraints are too tight. It is written that package works with 'parsec <3' but it can run with 3.0 and 3.1 (a lot of packages) Additionally: - Monomorphism restriction & autodetection of types may cause that extending interface (such as changing signature from a -> IO a to MonadIO m => a -> m a) may break some programs - You cannot change the restrictions on already submitted programs. If I figure out that due to minor change my package does not work with parsec 3.1 I can push the new version with fix but there is no way to mark package on hackage as 'this version is not compatible with parsec >=3.1' I understand that it is not problem only with haskell/cabal but also with many other packaging systems - especially those language-specific. I understand the need of ability of changing API (and haskell-specific problem what constitutes as API change). However I hope that some improvements are possible. Best regards PS. I understand that content may be flame-gen. I am sorry in advance if such circumstances happen. However I believe that possible improvements in process are worth the risk. 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] ghc leaking memory?
Hi Simon, Am Montag, den 08.03.2010, 11:07 + schrieb Simon Marlow: > > On Sat, Mar 6, 2010 at 11:57 AM, Joachim Breitner > > wrote: > >> Hi, > >> > >> in Debian, we are having some problems building large libraries (such as > >> agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, > >> armel, s390) which compile with -fvia-C, especially when building the > >> profiling libraries. > >> > >> In the case of highlighting-kate, there were really issues with the > >> code: A huge list of words which ghc seemed to try to inline caused it > >> consuming a lot of memory. > >> > >> But in the case of agda, it even fails with relatively small modules: > >> https://buildd.debian.org/fetch.cgi?pkg=agda&arch=sparc&ver=2.2.6-3&stamp=1267334936&file=log&as=raw > >> > >> Now, looking at the memory gauge on my computer while compiling such a > >> program with Cabal (which compiles all modules in one ghc call), it > >> looks like it is steadily increasing. I’d expect ghc to free a lot of > >> memory when it is done with a module, but this does not seem to be the > >> case. > >> > >> Is this a bug (i.e. memory leak) in ghc or expected behavior? > > Can you verify that it is GHC leaking memory, and not gcc? I recommend > turning off -fvia-C in particular unless you're sure that you need it. Sorry if I was not clear: The issues arise on “strange” architectures (armel, s390, sparc, mips) where, as far as I know, -fvia-C is the only option and thus the default. I was not setting this flag myself. Isn’t GHC calling gcc once for each module? In that case, that can not leak across modules, can it? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata 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] how to write a function to send a string to a tuple
2010/3/8 Pradeep Wickramanayake : > Hi, > > > > Im having problems with sending a string to a tuple. > > > > My string contains integers and strings > > > > The whole string stay as (“test,dfdf”,3,”dfsf”) > > > > sortList2 :: String -> String > > sortList2 (x:xs) > > | x == ',' = "" > > | otherwise = [x] ++ sortList2 xs > > > > The above function separating each words from the string > > > > Now I need to put them to a tuple > > > > putList :: String -> (Int, String, String, Int, Int) > > putList (x:xs) > > |xs /="" = sortList2 ++ > putList xs > > I'm not sure what you're doing with the "sorting", but you could sort of hack it using `read' as such: Prelude> read "(3, \"hello\")" :: (Int, String) (3, "hello") Of course, this will crash if the input string is not parsable. Prelude> read "(3, 'a')" :: (Int, String) *** Exception: Prelude.read: no parse -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how to write a function to send a string to a tuple
Hi,
Im having problems with sending a string to a tuple.
My string contains integers and strings
The whole string stay as ("test,dfdf",3,"dfsf")
sortList2 :: String -> String
sortList2 (x:xs)
| x == ',' = ""
| otherwise = [x] ++ sortList2 xs
The above function separating each words from the string
Now I need to put them to a tuple
putList :: String -> (Int, String, String, Int, Int)
putList (x:xs)
|xs /="" = sortList2 ++
putList xs
I wrote something like above. But I really have no clue how to continue. Can
someone help me. It's a big help
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc leaking memory?
On 06/03/2010 18:43, Antoine Latter wrote: Including ghc-users. On Sat, Mar 6, 2010 at 11:57 AM, Joachim Breitner wrote: Hi, in Debian, we are having some problems building large libraries (such as agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, armel, s390) which compile with -fvia-C, especially when building the profiling libraries. In the case of highlighting-kate, there were really issues with the code: A huge list of words which ghc seemed to try to inline caused it consuming a lot of memory. But in the case of agda, it even fails with relatively small modules: https://buildd.debian.org/fetch.cgi?pkg=agda&arch=sparc&ver=2.2.6-3&stamp=1267334936&file=log&as=raw Now, looking at the memory gauge on my computer while compiling such a program with Cabal (which compiles all modules in one ghc call), it looks like it is steadily increasing. I’d expect ghc to free a lot of memory when it is done with a module, but this does not seem to be the case. Is this a bug (i.e. memory leak) in ghc or expected behavior? Can you verify that it is GHC leaking memory, and not gcc? I recommend turning off -fvia-C in particular unless you're sure that you need it. It is expected that a --make compilation grows in memory over time, since the compiler accumulates information about modules that it has loaded. Having said that, it should not be retaining the entire compiled code of each module, only its interface. It might be hard to tell - in any case if you have an example where --make appears to be retaining too much memory then you should submit it as a bug. Is there a way to make Cabal build each module on its own? not at the moment, sorry. >> Are there any fixes or work-arounds? You can try using GC settings, e.g. +RTS -M. It might be a good idea to set this using an environment variable, e.g. GHCRTS=-M where is roughly equal to the amount of real memory on your machine. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell course, training
I was going to suggest the summer course in Utrecht, but I was concerned about whether it was exclusively for students or not. I've been to the first summer school last year, and it is particularly helpful if you didn't have the chance to take a proper functional programming (and Haskell) course before. Best, On 8 March 2010 07:19, Andres Loeh wrote: > Hi Günther, > > > all going well this year I'll be able to invest some money on becoming a > > better Haskeller. > > > > I think I've reached the point where I need some tutoring, so provided > I've > > got money for travel and course fees, and time, where do I get it? I'm > not > > a student so some courses aren't available to me. > > please consider the summer school in "Applied Functional Programming" > that we at Utrecht University are going to offer this year for the > second time: > > http://www.utrechtsummerschool.nl/index.php?type=courses&code=H9 > > While the school is mainly aimed at students (bachelor- and > master-level), we have no formal requirement that participants must be > students, and we will certainly consider other applications. > > Cheers, > Andres > > -- > > Andres Loeh, Universiteit Utrecht > > mailto:and...@cs.uu.nl mailto:m...@andres-loeh.de > http://www.andres-loeh.de > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
