Re: base package -- goals
Hi, Am Dienstag, den 26.02.2013, 10:08 + schrieb Simon Peyton-Jones: I think it would be vv helpful to have all these goals articulated on the wiki page. http://hackage.haskell.org/trac/ghc/wiki/SplitBase well, all the goals are there (or are they not sufficiently well explained)? I also tried to compare the two approaches – the re-exporting API-specifying packages and the actual split of base – by listing their advantages (I skipped the disadvantages, these would just be the negation of the other advantages list...) at http://hackage.haskell.org/trac/ghc/wiki/SplitBase#Approaches I don’t feel in the position to actually make a call here, or even to cast a vote with confidence, but I’m happy to continue summarizing the discussion until a consensus is found. If there is more discussion, that is. 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] [Announcement] New release of hArduino: Control your Arduino board from Haskell
A new release (v0.5) of hArduno is out, now supporting servo-motors, shift-registers, seven-segment displays, and distance sensors. Comes with a bunch of examples to play around with: http://leventerkok.github.com/hArduino/ On Hackage: http://hackage.haskell.org/package/hArduino -Levent. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Newbie
Hello, I'm new to Haskell and this is my first post to this forum. A few questions right off the bat: 1) Is this the right place for newbies to post questions about Haskell? 2) Is there a FAQ for Haskell questions? 3) Are there any active Haskell user groups in the Chicago area? A more technical question: I'm messing around with basic Haskell examples on eclipse using the FP add-on running over GHC. The following code works: pred :: Int - Int pred 0 = 0 pred n = n-1 The following code doesn't: pred :: Int - Int pred 0 = 0 pred n+1 = n Does anyone know why this might be? Thanks and I apologize in advance. dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Newbie
On Thu, Mar 7, 2013 at 7:45 PM, Dan Lior sitipo...@gmail.com wrote:
1) Is this the right place for newbies to post questions about Haskell?
This is most a list for announcements; beginn...@haskell.org is better for
these kinds of questions, and haskell-c...@haskell.org for general
discussion.
pred :: Int - Int
pred 0 = 0
pred n+1 = n
n+k patterns were part of Haskell '98, but removed from Haskell 2010. You
may be able to use the pragma
{-# LANGUAGE NPlusKPatterns #-}
to turn them back on.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Newbie
On 8 March 2013 11:56, Brandon Allbery allber...@gmail.com wrote:
On Thu, Mar 7, 2013 at 7:45 PM, Dan Lior sitipo...@gmail.com wrote:
1) Is this the right place for newbies to post questions about Haskell?
This is most a list for announcements; beginn...@haskell.org is better for
these kinds of questions, and haskell-c...@haskell.org for general
discussion.
pred :: Int - Int
pred 0 = 0
pred n+1 = n
n+k patterns were part of Haskell '98, but removed from Haskell 2010. You
may be able to use the pragma
{-# LANGUAGE NPlusKPatterns #-}
to turn them back on.
Even then, you need to have pred (n+1) = n.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] GHC 7.6.2 introduces loop in UUAGC
The uuagc package [1] works fine with GHC versions 7.4.* and 7.6.1. However, with GHC 7.6.2 the binary still compiles but runs into an infinite loop at runtime. To reproduce, do: cabal install uuagc touch tmp.ag uuagc tmp.ag With GHC versions 7.6.2 this succeeds and creates a (rather boring) file tmp.hs, while with GHC 7.6.2 this displays: uuagc: loop I suspect that this is related to strictness annotations, which exist in many places in the UUAGC source code (which itself is also preprocessed by the UUAGC system). In the release notes I cannot find anything related to strictness which could introduce this, so would anyone have a clue on where to look? Has there been a longstanding bug in the UUAGC source code which only now surfaces? Or is it a bug introduced in GHC 7.6.2 where something is a bit too strict? FYI, I have been able to trace this down to a bug in the GHC type checker, resulting in an incorrect (invalid) type being inferred for a function in uulib, which UUAGC relies on. A new version of uulib has been uploaded to Hackage which solves this issue, and the bug report for GHC can be found at http://hackage.haskell.org/trac/ghc/ticket/7748 Regards, Jeroen Bransen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Announcement] New release of hArduino: Control your Arduino board from Haskell
A new release (v0.5) of hArduno is out, now supporting servo-motors, shift-registers, seven-segment displays, and distance sensors. Comes with a bunch of examples to play around with: http://leventerkok.github.com/hArduino/ On Hackage: http://hackage.haskell.org/package/hArduino -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Announcement] New release of hArduino: Control your Arduino board from Haskell
Good to see someone working on an arduino api. I'll have to try this out sometime. On 7 March 2013 17:38, Levent Erkok erk...@gmail.com wrote: A new release (v0.5) of hArduno is out, now supporting servo-motors, shift-registers, seven-segment displays, and distance sensors. Comes with a bunch of examples to play around with: http://leventerkok.github.com/hArduino/ On Hackage: http://hackage.haskell.org/package/hArduino -Levent. ___ 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] Question about updating GHC on MacOS
Hi, I have Haskell Platform with GHC[i] 7.4.2 installed on a MacOS system. There's a problem with the handling of certain Markdown constructs in literate Haskell (lines starting with '#') that I understand is fixed in 7.6.2. Therefore, I'd like to be able to update my GHC installation to 7.6.2. But I haven't yet been able to find any instructions about how to upgrade an existing GHC installation. Am I missing something? #g -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] File I/O benchmark help (conduit, io-streams and Handle)
Hi all, I'm turning to the community for some help understanding some benchmark results[1]. I was curious to see how the new io-streams would work with conduit, as it looks like a far saner low-level approach than Handles. In fact, the API is so simple that the entire wrapper is just a few lines of code[2]. I then added in some basic file copy benchmarks, comparing conduit+Handle (with ResourceT or bracket), conduit+io-streams, straight io-streams, and lazy I/O. All approaches fell into the same ballpark, with conduit+bracket and conduit+io-streams taking a slight lead. (I haven't analyzed that enough to know if it means anything, however.) Then I decided to pull up the NoHandle code I wrote a while ago for conduit. This code was written initially for Windows only, to work around the fact that System.IO.openFile does some file locking. To avoid using Handles, I wrote a simple FFI wrapper exposing open, read, and close system calls, ported it to POSIX, and hid it behind a Cabal flag. Out of curiosity, I decided to expose it and include it in the benchmark. The results are extreme. I've confirmed multiple times that the copy algorithm is in fact copying the file, so I don't think the test itself is cheating somehow. But I don't know how to explain the massive gap. I've run this on two different systems. The results you see linked are from my local machine. On an EC2 instance, the gap was a bit smaller, but the NoHandle code was still 75% faster than the others. My initial guess is that I'm not properly tying into the IO manager, but I wanted to see if the community had any thoughts. The relevant pieces of code are [3][4][5]. Michael [1] http://static.snoyman.com/streams.html [2] https://github.com/snoyberg/conduit/blob/streams/io-streams-conduit/Data/Conduit/Streams.hs [3] https://github.com/snoyberg/conduit/blob/streams/conduit/System/PosixFile.hsc [4] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binary.hs#L54 [5] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binary.hs#L167 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File I/O benchmark help (conduit, io-streams and Handle)
One clarification: it seems that sourceFile and sourceFileNoHandle have virtually no difference in speed. The gap comes exclusively from sinkFile vs sinkFileNoHandle. This makes me think that it might be a buffer copy that's causing the slowdown, in which case the benchmark may in fact be accurate. On Mar 8, 2013 8:30 AM, Michael Snoyman mich...@snoyman.com wrote: Hi all, I'm turning to the community for some help understanding some benchmark results[1]. I was curious to see how the new io-streams would work with conduit, as it looks like a far saner low-level approach than Handles. In fact, the API is so simple that the entire wrapper is just a few lines of code[2]. I then added in some basic file copy benchmarks, comparing conduit+Handle (with ResourceT or bracket), conduit+io-streams, straight io-streams, and lazy I/O. All approaches fell into the same ballpark, with conduit+bracket and conduit+io-streams taking a slight lead. (I haven't analyzed that enough to know if it means anything, however.) Then I decided to pull up the NoHandle code I wrote a while ago for conduit. This code was written initially for Windows only, to work around the fact that System.IO.openFile does some file locking. To avoid using Handles, I wrote a simple FFI wrapper exposing open, read, and close system calls, ported it to POSIX, and hid it behind a Cabal flag. Out of curiosity, I decided to expose it and include it in the benchmark. The results are extreme. I've confirmed multiple times that the copy algorithm is in fact copying the file, so I don't think the test itself is cheating somehow. But I don't know how to explain the massive gap. I've run this on two different systems. The results you see linked are from my local machine. On an EC2 instance, the gap was a bit smaller, but the NoHandle code was still 75% faster than the others. My initial guess is that I'm not properly tying into the IO manager, but I wanted to see if the community had any thoughts. The relevant pieces of code are [3][4][5]. Michael [1] http://static.snoyman.com/streams.html [2] https://github.com/snoyberg/conduit/blob/streams/io-streams-conduit/Data/Conduit/Streams.hs [3] https://github.com/snoyberg/conduit/blob/streams/conduit/System/PosixFile.hsc [4] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binary.hs#L54 [5] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binary.hs#L167 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File I/O benchmark help (conduit, io-streams and Handle)
I would have expected sourceFileNoHandle to make the most difference, since that's one location (write) where you've obviously removed a copy. Does sourceFileNoHandle allocate less? Incidentally, I've recently been making similar changes to IO code (removing buffer copies) and getting similar speedups. Although the results tend to be less pronounced in code that isn't strictly IO-bound. On Fri, Mar 8, 2013 at 2:50 PM, Michael Snoyman mich...@snoyman.com wrote: One clarification: it seems that sourceFile and sourceFileNoHandle have virtually no difference in speed. The gap comes exclusively from sinkFile vs sinkFileNoHandle. This makes me think that it might be a buffer copy that's causing the slowdown, in which case the benchmark may in fact be accurate. On Mar 8, 2013 8:30 AM, Michael Snoyman mich...@snoyman.com wrote: Hi all, I'm turning to the community for some help understanding some benchmark results[1]. I was curious to see how the new io-streams would work with conduit, as it looks like a far saner low-level approach than Handles. In fact, the API is so simple that the entire wrapper is just a few lines of code[2]. I then added in some basic file copy benchmarks, comparing conduit+Handle (with ResourceT or bracket), conduit+io-streams, straight io-streams, and lazy I/O. All approaches fell into the same ballpark, with conduit+bracket and conduit+io-streams taking a slight lead. (I haven't analyzed that enough to know if it means anything, however.) Then I decided to pull up the NoHandle code I wrote a while ago for conduit. This code was written initially for Windows only, to work around the fact that System.IO.openFile does some file locking. To avoid using Handles, I wrote a simple FFI wrapper exposing open, read, and close system calls, ported it to POSIX, and hid it behind a Cabal flag. Out of curiosity, I decided to expose it and include it in the benchmark. The results are extreme. I've confirmed multiple times that the copy algorithm is in fact copying the file, so I don't think the test itself is cheating somehow. But I don't know how to explain the massive gap. I've run this on two different systems. The results you see linked are from my local machine. On an EC2 instance, the gap was a bit smaller, but the NoHandle code was still 75% faster than the others. My initial guess is that I'm not properly tying into the IO manager, but I wanted to see if the community had any thoughts. The relevant pieces of code are [3][4][5]. Michael [1] http://static.snoyman.com/streams.html [2] https://github.com/snoyberg/conduit/blob/streams/io-streams-conduit/Data/Conduit/Streams.hs [3] https://github.com/snoyberg/conduit/blob/streams/conduit/System/PosixFile.hsc [4] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binary.hs#L54 [5] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binary.hs#L167 ___ 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
