testsuite for GHC version 6.6.1?

2007-05-04 Thread Christian Maeder
How or where can I pick up the testsuite for this new version? I want to test my own builds. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why do we have stack overflows?

2007-05-04 Thread Adrian Hey
John Meacham wrote: I believe it is because a stack cannot be garbage collected, and must be traversed as roots for every garbage collection. I don't think there are any issues with a huge stack per se, but it does not play nice with garbage collection so may hurt your performance and memory

Re: testsuite for GHC version 6.6.1?

2007-05-04 Thread Matthias Kilian
On Fri, May 04, 2007 at 02:48:13PM +0200, Christian Maeder wrote: How or where can I pick up the testsuite for this new version? I want to test my own builds. http://www.haskell.org/ghc/dist/6.6.1/ghc-testsuite-6.6.1.tar.gz ___ Glasgow-haskell-users

Re: Why do we have stack overflows?

2007-05-04 Thread Malcolm Wallace
Adrian Hey [EMAIL PROTECTED] wrote: Failing because the stack has grown beyond some arbitrary (and typically small) size seems bad to me. Just FYI, nhc98 has a single memory area in which the stack and heap grow towards each other. Memory exhaustion only happens when the stack and heap meet

Re: Why do we have stack overflows?

2007-05-04 Thread Adrian Hey
Malcolm Wallace wrote: Just FYI, nhc98 has a single memory area in which the stack and heap grow towards each other. Memory exhaustion only happens when the stack and heap meet in the middle and GC fails to reclaim any space. However, it can only do this because it is single-threaded. As soon

GHC as a library - getting output from GHCI

2007-05-04 Thread Mads Lindstrøm
Hi I am trying to use GHC as a library (see http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get all the output from an interactive session and put in a GUI. This http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a nice starting point. However, the result of:

Re: GHC as a library - getting output from GHCI

2007-05-04 Thread Pepe Iborra
I believe that the trick is to wrap your stmt in a IO handler that captures stdout and returns it together with the value of your stmt. That is, something with a type: wrapStmt :: IO a - IO (a,String) It should be easy to implement wrapStmt using System.Posix.Process. Then you just define

Re: GHC as a library - getting output from GHCI

2007-05-04 Thread Pepe Iborra
Mads On 04/05/2007, at 19:19, Mads Lindstrøm wrote: Hi Pepe I would have liked something cross-platform. Take a look at the unix-compat[1] package by Bjorn Bringert, although it looks like it won't help you. Maybe it can be extended. Also, if stmt contains an error, wrapStmt will not

Cost of Overloading vs. HOFs

2007-05-04 Thread Adrian Hey
Hello, The GHC users guide says overloading is death to performance if left to linger in an inner loop and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an explicit argument at the start seemed to give noticable a

Re: recent Windows installer for ghc head?

2007-05-04 Thread Conal Elliott
I untar'd the 20070404 head and added its bin/i386-unknown-cygwin32 to my PATH. When I run ghci, I get : Can't find package.conf as c:\ghc\GHC-67~2.200\bin\I386\driver\package.conf.inplace Suggestions? Thanks, - Conal On 5/2/07, Claus Reinke [EMAIL PROTECTED] wrote: Thanks for the

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Neil Mitchell
Hi Adrian The GHC users guide says overloading is death to performance if left to linger in an inner loop and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an explicit argument at the start seemed to give noticable

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Duncan Coutts
On Fri, 2007-05-04 at 19:28 +0100, Adrian Hey wrote: Hello, The GHC users guide says overloading is death to performance if left to linger in an inner loop and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Adrian Hey
Neil Mitchell wrote: Hi Adrian The GHC users guide says overloading is death to performance if left to linger in an inner loop and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an explicit argument at the start

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Adrian Hey
Duncan Coutts wrote: One might hope that in this case we could hoist the extraction of the dictionary members outside the inner loop. This possibility had crossed my mind too. If HOFs really are faster (for whatever reason) then it should be possible for a compiler to do this automatically.

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread kahl
Adrian Hey wrote: Duncan Coutts wrote: One might hope that in this case we could hoist the extraction of the dictionary members outside the inner loop. This possibility had crossed my mind too. If HOFs really are faster (for whatever reason) then it should be possible for a

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Conal Elliott
Does anyone know what became of Dictionary-free Overloading by Partial Evaluation http://web.cecs.pdx.edu/%7Empj/pubs/pepm94.html? Is it impractical for some reason? On 5/4/07, Adrian Hey [EMAIL PROTECTED] wrote: Hello, The GHC users guide says overloading is death to performance if left to

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Stefan O'Rear
On Fri, May 04, 2007 at 09:02:03PM +0100, Neil Mitchell wrote: Hi Adrian The GHC users guide says overloading is death to performance if left to linger in an inner loop and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread John Meacham
On Fri, May 04, 2007 at 03:07:41PM -0700, Conal Elliott wrote: Does anyone know what became of Dictionary-free Overloading by Partial Evaluation http://web.cecs.pdx.edu/%7Empj/pubs/pepm94.html? Is it impractical for some reason? jhc also uses a dictionary free approach, doing a case directly

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Conal Elliott
Cool. You know which types to consider because jhc is a whole-program compiler? Given the whole program, why not monomorphize, and inline away all of the dictionaries? - Conal On 5/4/07, John Meacham [EMAIL PROTECTED] wrote: On Fri, May 04, 2007 at 03:07:41PM -0700, Conal Elliott wrote:

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread John Meacham
On Fri, May 04, 2007 at 05:06:10PM -0700, Conal Elliott wrote: Cool. You know which types to consider because jhc is a whole-program compiler? Yes. though, i have since redone the back end so there is no technical reason for it to be whole program any more, you can just benefit from more

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Matthew Brecknell
Stefan O'Rear: Data.Sequence doesn't use overloading Data.Sequence uses overloading for subtree size annotations. The structural recursion seems to make it quite awkward to express size annotations without overloading. ___ Glasgow-haskell-users

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread Stefan O'Rear
On Sat, May 05, 2007 at 10:29:54AM +1000, Matthew Brecknell wrote: Stefan O'Rear: Data.Sequence doesn't use overloading Data.Sequence uses overloading for subtree size annotations. The structural recursion seems to make it quite awkward to express size annotations without overloading. Ah

Re: Cost of Overloading vs. HOFs

2007-05-04 Thread skaller
On Fri, 2007-05-04 at 17:06 -0700, Conal Elliott wrote: Cool. You know which types to consider because jhc is a whole-program compiler? Given the whole program, why not monomorphize, and inline away all of the dictionaries? That's what Felix does: typeclasses, no dictionaries: whole