- Glasgow-haskell-users

RE: 4.08.2
by Simon Peyton-Jones 29 Jan '01

29 Jan '01

George I'm sorry we've been silent. MS has some kind of huge email backlog. But the real reason is that POPL and a workshop have intervened so we've been out of action for a fortnight. The plan is to release 4.08.2 in a matter of days, not weeks. If you build the head of the ghc-4-07-branch you'll get the current 4.08.2, and we expect only tiny changes before the release (e.g. making sure it all works on Sparc). 4.08 remains our "stable branch". Simon | -----Original Message----- | From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de] | Sent: 23 January 2001 22:23 | To: George Russell | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: 4.08.2 | | | George Russell wrote: | > Since the absence of any reply presumably means "not for a | while yet", | | I'm not so sure about this, there has been quite some | bug-fixing and it's | not clear to me what's missing for a release. Simon^2? | | > could someone let me have a compiled hsc for the ghc-4.08 head | > on something reasonably close to SunOS/sparc Ultra-1? | | The current branch-o-mania is a little confusing, but the CVS branch | called "ghc-4-07-branch" (yes, "7", not "8") should contain what you | are looking for. At least I think so... :-} Any | bootstrapping problems? | | Cheers, | Sven | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

Floating point performance
by Jan Kort 26 Jan '01

26 Jan '01

Hi, I noticed ghc (version 4.08.1) floating point performance is really slow on my computer: a 270Mhz sun ultra5. The program below does 1 milion floating point multiplications and takes 2 seconds to run. I made a profile and it says most of the time (93%) is spent in the function bar. Any idea what is going on ? Regards, Jan module Main where foo :: Double -> [Double] foo 0 = [1] foo n = bar n:foo (n-1) bar :: Double -> Double bar n = n*1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 foldl' :: (a -> b -> a) -> a -> [b] -> a foldl' _ a [] = a foldl' f a (x:xs) = (foldl' f $! f a x) xs main :: IO() main = putStrLn (show (foldl' (+) 0 (foo 10000))) --------------------------- Profile: total time = 2.60 secs (130 ticks @ 20 ms) total alloc = 24,845,828 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc bar Main 93.1 96.1 foo Main 3.1 2.4 foldl' Main 3.1 1.4 individual inherited COST CENTRE MODULE entries %time %alloc %time %alloc MAIN MAIN 0 0.0 0.0 100.0 100.0 main Main 0 0.0 0.0 0.0 0.0 CAF PrelShow 1 0.0 0.0 0.0 0.0 CAF PrelFloat 3 0.0 0.0 0.0 0.0 CAF PrelHandle 3 0.0 0.0 0.0 0.0 CAF Main 9 0.0 0.0 100.0 100.0 main Main 1 0.8 0.0 100.0 100.0 foo Main 10001 3.1 2.4 96.2 98.5 bar Main 10000 93.1 96.1 93.1 96.1 foldl' Main 10002 3.1 1.4 3.1 1.4

2 1

RE: limited suspending on readChan possible?
by Simon Marlow 26 Jan '01

26 Jan '01

> Hello everyone, I thought I?d return to more earthly issue > than discovering > bugs in signal handlers etc. :) > > I?ve been looking for a way to suspend on an empty channel for only a > limited time. So I came up with a solution which involves > dupChan (which > is currently broken as stated in Meurig?s bug-report) and unGetChan: How about timeout N . readChan where timeout is defined according to our Asynchronous Exceptions paper (see http://www.haskell.org/~simonmar/papers/async.ps.gz) Cheers, Simon

1 0

RE: _scc_
by Simon Marlow 26 Jan '01

26 Jan '01

> Why > _scc_ "foo" > and not > {-# SCC "foo" #-} > ? > > IMHO a pragma would be better: does not make the scc-annotated program > non-standard. > > (Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary > places.) Good suggestion. I'm not sure why it was done the current way; perhaps it was before the advent of pragmas. Anyway, on my ToDo list it goes... Cheers, Simon

1 0

_scc_
by qrczak＠knm.org.pl 25 Jan '01

25 Jan '01

Why _scc_ "foo" and not {-# SCC "foo" #-} ? IMHO a pragma would be better: does not make the scc-annotated program non-standard. (Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary places.) -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: using the GHC parser and renamer
by Simon Peyton-Jones 25 Jan '01

25 Jan '01

Kate I'm sorry not to have replied to your earlier message; I've been away at POPL etc. Incidentally, for implementation-related things, better to use glasgow-haskell-bugs (albeit it's not actually a bug) rather than glasgow-haskell-users. GHC 4.08 (which is the place from which you got your code, I think) uses a "driver" written in perl to coordinate its operations. The driver runs cpp, then GHC itself (a binary called 'hsc'), then gcc, then as, then ld. Run ghc-4.08 with "-v" to see what it does. My bet is that you are running your bits-of-ghc-plus-bits-of-your-own binary directly. So it's not getting all the command-line flags it expects. (nor are they documented, because it's an internal interface). | Main.hs:1: | Could not find interface file for 'Prelude' | in the directories ./*.hi It's not looking in the right directories because it hasn't been told to do so by the command-line flags. If you run ghc-4.08 -v you'll see how the driver communicates which directctories to look in. | Main.hs:3: | Bad interface file:: ./ParseAndRenameFile.hi | ./ParseAndRenameFile.hi:1 Interface file | version error; Expected 0 | found version 408 The version number it expects to find is again communicated by a command line flag. For your purposes you may not care, so one option is to just remove the test. Or ghc-4.08 -v will show you what the driver is saying to hsc. Incidentally, Tim Sheard at OGI is building a modular front end for Haskell, in the spirit of Mark Jones's Typing Haskell in Haskell paper. It might be worth asking him whether it's in a borrow-able state, becuase it's probably less of a monster than GHC. Simon

1 0

limited suspending on readChan possible?
by Volker Stolz 25 Jan '01

25 Jan '01

Hello everyone, I thought I´d return to more earthly issue than discovering bugs in signal handlers etc. :) I´ve been looking for a way to suspend on an empty channel for only a limited time. So I came up with a solution which involves dupChan (which is currently broken as stated in Meurig´s bug-report) and unGetChan: > timedReadChan ch t = do > dup <- dupChan ch > mv <- newEmptyMVar > forkIO (do > msg <- readChan dup > putMVar mv True > ) > forkIO (do > threadDelay t > putMVar mv False > ) > res <- takeMVar mv > if res > then do > -- we discard dup and re-read from ch: > msg <- readChan ch > return (Just msg) > else (return Nothing) However, shouldn´t the dupChan be a space-leak par excellence? We end up having no readers and keep adding new meesages to dup... -- \usepackage[latin1]{inputenc}! Volker Stolz * stolz(a)i2.informatik.rwth-aachen.de * PGP + S/MIME

1 0

using the GHC parser and renamer
by Kate S. Golder 24 Jan '01

24 Jan '01

Hi - We are trying to use the GHC parser and renamer within a program that we are writing (a program to take a Haskell program written in multiple modules, and return a program that is a single module) and. We were wondering if you can think of something that we might be missing. It compiles fine (when we execute "make all" at the command line), but when we run the executable it gets through the parser fine, and creates the uniqueSupply for the renamer, but it doesn't get through the renamer, we get an errors that say (Main.hs is the file that is being parsed and renamed): Main.hs:1: Could not find interface file for 'Prelude' in the directories ./*.hi Main.hs:3: Bad interface file:: ./ParseAndRenameFile.hi ./ParseAndRenameFile.hi:1 Interface file version error; Expected 0 found version 408 Fail: Compilation had errors We assume that these are because the renamer needs to look at .hi files, and that it either can't find them (Prelude.hi) or it has the wrong version number (ParseAndRenameFile.hi). How do we tell the renamer where to look for the interface files, and fix the version error? I've included the three files (Makefile, Main.hs, and ParseAndRenameFile.hs) at the bottom of this email. Thanks in advance for you any thoughts you might have, Kate =========================================================== Makefile: HC = ghc-4.08 INTERFACE_FILES = .:compiler/absCSyn:compiler/basicTypes:compiler/codeGen:compiler/coreSyn:compiler/cprAnalysis:compiler/deSugar:compiler/hsSyn:compiler/javaGen:compiler/main:compiler/nativeGen:compiler/parser:compiler/prelude:compiler/profiling:compiler/rename:compil er/simplCore:compiler/simplStg:compiler/specialise:compiler/stgSyn:compiler/stranal:compiler/typecheck:compiler/types:compiler/usageSP:compiler/utils:/home/lumberjacks/deforest/ghc-4.08/fptools-binaries/lib/i386-unknown-linux/imports/lang/ HC_OPTS = -cpp -i$(INTERFACE_FILES) $(EXTRA_HC_OPTS) -fglasgow-exts SRCS = Main.hs ParseAndRenameFile.hs OBJS = Main.o ParseAndRenameFile.o .SUFFIXES : .o .hs .hi .lhs .hc .s all: $(OBJS) $(HC) -lHSlang -lNewGHC -L/usr/users/deforest/ghc-4.08/fptools-newgcc-build/lib -o PARF $(HC_OPTS) $(OBJS) # Standard suffix rules .o.hi: @: .lhs.o: $(HC) -c $< $(HC_OPTS) .hs.o: $(HC) -c $< $(HC_OPTS) depend : $(HC) -M $(HC_OPTS) $(SRCS) # DO NOT DELETE: Beginning of Haskell dependencies Main.o : Main.hs Main.o : ./ParseAndRenameFile.hi ParseAndRenameFile.o : ParseAndRenameFile.hs ParseAndRenameFile.o : compiler/basicTypes/UniqSupply.hi ParseAndRenameFile.o : compiler/rename/Rename.hi ParseAndRenameFile.o : compiler/utils/FastString.hi ParseAndRenameFile.o : compiler/hsSyn/HsSyn.hi ParseAndRenameFile.o : compiler/basicTypes/BasicTypes.hi ParseAndRenameFile.o : compiler/parser/RdrHsSyn.hi ParseAndRenameFile.o : compiler/utils/FastString.hi ParseAndRenameFile.o : compiler/utils/StringBuffer.hi ParseAndRenameFile.o : compiler/parser/Parser.hi ParseAndRenameFile.o : compiler/parser/Lex.hi ParseAndRenameFile.o : compiler/basicTypes/SrcLoc.hi ParseAndRenameFile.o : compiler/rename/RnMonad.hi ParseAndRenameFile.o : compiler/main/MkIface.hi ParseAndRenameFile.o : compiler/typecheck/TcModule.hi ParseAndRenameFile.o : compiler/basicTypes/Module.hi ParseAndRenameFile.o : compiler/main/CmdLineOpts.hi ParseAndRenameFile.o : compiler/main/ErrUtils.hi ParseAndRenameFile.o : compiler/utils/Outputable.hi # DO NOT DELETE: End of Haskell dependencies =========================================================== Main.hs: module Main where import ParseAndRenameFile main :: IO () main = parseAndRename "Main.hs" =========================================================== ParseAndRenameFile.hs: module ParseAndRenameFile where import UniqSupply ( mkSplitUniqSupply ) import Rename ( renameModule ) import FastString -- import IO ( hPutStr, stderr ) import HsSyn import BasicTypes ( NewOrData(..) ) import RdrHsSyn ( RdrNameHsModule ) import FastString ( mkFastCharString, unpackFS ) import StringBuffer ( hGetStringBuffer ) import Parser ( parse ) import Lex ( PState(..), P, ParseResult(..) ) import SrcLoc ( mkSrcLoc ) import RnMonad ( InterfaceDetails(..) ) import MkIface ( startIface, ifaceDecls, endIface ) import TcModule ( TcResults(..), typecheckModule ) import Module ( ModuleName, moduleNameUserString ) import CmdLineOpts import ErrUtils ( ghcExit ) import Outputable parseAndRename filename = do {(name, parsed) <- parseFile filename; rn_uniqs <- mkSplitUniqSupply 'r'; maybe <- renameModule rn_uniqs parsed; putStr "done \n" } --parseFile is adapted from parseModule in compiler/main/Main.lhs parseFile :: String -> IO (ModuleName, RdrNameHsModule) parseFile filename = do {buf <- hGetStringBuffer True{-expand tabs-} filename; case parse buf PState{ bol = 0#, atbol = 1#, context = [], glasgow_exts = glaexts, loc = mkSrcLoc (mkFastString filename) 1 } of PFailed err -> do printErrs err ghcExit 1 return (error "parseModule") -- just to get the types right POk _ m@(HsModule mod _ _ _ _ _ _) -> return (mod, m) } where glaexts | opt_GlasgowExts = 1# | otherwise = 0# =========================================================== Thanks again!

1 0

4.08.2
by George Russell 23 Jan '01

23 Jan '01

Any idea yet when 4.08.2 is going to be released? The bugs I reported some time ago are now getting to be a serious nuisance. I've tried compiling the 4.08 branch from source, but thanks to some as-yet-unclarified infelicity in gcc or ghc, I get a segmentation fault from the resulting hsc.

3 4

Do *you* understand GHC?
by Manuel M. T. Chakravarty 22 Jan '01

22 Jan '01

Neither do I, but I am pretending to: http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ This is a - so far, very small - set of notes on GHC internals to assist my weak memory. Maybe it is also useful for others. Cheers, Manuel

2 1