RE: My mistake is harder to diagnose than it could be

2000-11-02 Thread Simon Peyton-Jones
In the new GHCi system we plan to make it *required* that the module name and the file name match, EXCEPT for module Main. This seems to remove a whole class of errors. Yell if that'll be problematic for you Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

Re: fatal error: heapCensus

2000-11-02 Thread Oliver Braun
Hi again, unfortunately I forgot to ask my questions ;o) What does heapCensus mean ? What can I do to avoid this error ? > I have compiled all files with the -prof and the -auto-all flag. > > When starting the program > > * without any RTS options -> everything is OK > * with +RTS -p

RE: Fun with GHC's optimiser

2000-11-02 Thread Manuel M. T. Chakravarty
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote, > I can never resist messages like these, even when I'm meant > to be doing other things. That's good to know ;-) > It's very helpful when people offer > fairly precise performance-bug reports. Thanks! Thanks for the prompt reply! To SimonM, to

fatal error: heapCensus

2000-11-02 Thread Oliver Braun
Dear GHC-Users, I am currently developing part of the EdComb library (http://ist.unibw-muenchen.de/EdComb/). I have compiled all files with the -prof and the -auto-all flag. When starting the program * without any RTS options -> everything is OK * with +RTS -p-> everything is OK *

RE: Quick question re RULES

2000-11-02 Thread Manuel M. T. Chakravarty
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote, > Is this a propos of your new transformations for parallelism? Precisely! Trying to figure out how to generate the fastest possible array code with GHC. Manuel ___ Glasgow-haskell-users mailing list [EM

RE: Fun with GHC's optimiser

2000-11-02 Thread Simon Peyton-Jones
I can never resist messages like these, even when I'm meant to be doing other things. It's very helpful when people offer fairly precise performance-bug reports. Thanks! | I am wondering whether there is a particular reason why the | optimiser doesn't pull the | | (1) a = NO_CCS PArray! [wi

RE: Fun with GHC's optimiser

2000-11-02 Thread Simon Marlow
> I am wondering whether there is a particular reason why the > optimiser doesn't pull the > > (1) a = NO_CCS PArray! [wild1 mba#]; > > and the > > (2) case w of wild3 { > I# e# -> I checked with the before-ghci-branch compiler, and it pulls out (1) but not (2). Simon did a fai

Fun with GHC's optimiser

2000-11-02 Thread Manuel M. T. Chakravarty
Questions over questions arise in my quest to understand GHC's code generator. In this nice little piece of STG $w$snewPArray = NO_CCS[] \r[ww w] case newIntArray# [ww realWorld#] of wild { (#,#) s2# mba# -> case -# [ww 1] of y { DEFAULT ->

RE: Quick question re RULES

2000-11-02 Thread Simon Peyton-Jones
| PrelBase contains the appended code. Am I correct in | assuming that the stuff is structured as it is, because the | "map" rule first `breaks' the map `open', which exposes it | to the various foldr/build rules, and if no foldr/build rule | matches, the "mapList" rule `closes' it again in a lat

Quick question re RULES

2000-11-02 Thread Manuel M. T. Chakravarty
PrelBase contains the appended code. Am I correct in assuming that the stuff is structured as it is, because the "map" rule first `breaks' the map `open', which exposes it to the various foldr/build rules, and if no foldr/build rule matches, the "mapList" rule `closes' it again in a later phase o