- Glasgow-haskell-users

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

RE: An Haskell compilation server
by Simon Marlow 17 Jan '01

17 Jan '01

[ moved to glasgow-haskell-users(a)haskell.org... ] > Wed, 17 Jan 2001 01:49:25 -0800, Simon Marlow > <simonmar(a)microsoft.com> pisze: > > > Funny you should say that. The next version of GHC (5.00 - to be > > released soon) will have hmake-like functionality enabling it to > > compile multiple modules without exiting, > > How to specify .c files to be linked in? > > Or to not bother with linking so I will link manually. No way to do either at the moment. These would be nice things to have though. Cheers, Simon

1 0

RE: bootstrapping GHC
by Simon Marlow 16 Jan '01

16 Jan '01

[ Moved to glasgow-haskell-users(a)haskell.org... ] > I found the mailing list discussion on generating the hc boot > files and > unregisterized code after a tip from Michael Weber and will eventually > get around to trying to bootstrap on Linux/PPC. > > On the other hand, I'm running into a bit of trouble on the > SPARC. It's > actually an UltraSPARC (sparc64). My assumption was that > ordinary SPARC > code should just run on it. What's actually happen is illegal > instructions > everywhere. The one that seems to stop me dead cold every > time is here: > > 00000000009c4cfc <PrelMain_mainIO_info>: > 9c4cfc: 00 9c 4c f8 bn 10d80dc <_end+0x69bff4> > 9c4d00: 00 00 00 00 unimp 0 > 9c4d04: 00 11 00 01 unimp 0x110001 > > and this is in hsc, which is as far into the bootstrap as I got. > > This disassembly looks wrong to me. Perhaps asm mangling is needed; I > had -fno-asm-mangling set because the assembler was barfing > on prologue > nonsense. I'll be looking into that, as I'm not very familiar with the > real guts of the compiler, or, for that matter, modern SPARC's. If you're doing an unregisterised bootstrap, there shouldn't be any problem with assembly mangling since you're just using the OS's native C compiler (preferably gcc). Although we do have one or two bits of inline assembly which might be upsetting things: ASSIGN_DBL and PK_DBL in ghc/includes/StgMacros.h spring to mind. The PPC folks, particularly Atze Dijkstra <atze(a)cs.uu.nl> who did the recent MacOS X port, have gone through the whole unregisterised bootstrap process recently so they should be able to help. Guys? Cheers, Simon

1 0

Re: Too Strict?
by C.Reinke 15 Jan '01

15 Jan '01

> Can someone help? The program below works fine with small files but when I > try to use it on the one I need to (about 3 million lines of data) it > produces no output. The hard disk is hammered - I assume this is the run time > system paging. My suspicion is that the program is trying to read in the > whole file before processing it. Is this correct? If so, how do I make the > program lazy so that it processes a line at time? I was about to apply GHood to your program to see whether such a tool could help to find the problem, so I started to cut down your code. However, in the simplified version of the program, one can see what is going on without any graphical tool.. (nevertheless, observation of the simplified code with GHood confirms your suspicion immediately, and it points out the spine of the list as the problem, too, so the tool is useful!-) (*) In effect, your anonymize comes down to a "mapM" over a list of actions applied to input lines, and all of the resulting IO-actions are placed before the single "hPutStr". So, even if the results of the individual actions in the list may not be needed until later, the whole spine of the list of lines has to be traversed before "hPutStr" can be executed, meaning that all input is read before any output is produced (and thus before any computation results are requested, blowing up memory usage). For the problem at hand, you could simply output each line as it is processed instead of just returning it into a list for later use (see variant _1 below). If you would want to keep both the modular program structure and the explicit line-by-line IO-style, you would need to interleave the input and output commands somehow (perhaps similar to variant _2 below?). Hth, Claus (*) Please note that our web-server is being upgraded today.. (web-pages and GHood download will not be available until tomorrow, hence no URL here :-( PS The simplified code (+ variations) with observations: module Main(main) where import Observe import IO(openFile, hPutStr, IOMode(ReadMode,WriteMode,AppendMode)) filename = "ldif1.txt" fileout = "ldif.out" readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename let action l = return (':':l) a <- mapM action (observe "input" (lines s)) hPutStr h (unlines (observe "output" a)) main = runO readAndWriteAttrVals readAndWriteAttrVals_1 = do h <- openFile fileout WriteMode s <- readFile filename let action_and_output l = hPutStr h (':':l) mapM_ (observe "output" action_and_output) (observe "input" (lines s)) main_1 = runO readAndWriteAttrVals_1 readAndWriteAttrVals_2 = do h <- openFile fileout WriteMode s <- readFile filename let { action l = return (':':l) ; as = map action (observe "input" (lines s)) ; os = repeat (hPutStr h) } mapM id (observe "output" (zipWith (>>=) as os)) main_2 = runO readAndWriteAttrVals_2

1 0

Too Strict?
by Steinitz, Dominic J 15 Jan '01

15 Jan '01

Can someone help? The program below works fine with small files but when I try to use it on the one I need to (about 3 million lines of data) it produces no output. The hard disk is hammered - I assume this is the run time system paging. My suspicion is that the program is trying to read in the whole file before processing it. Is this correct? If so, how do I make the program lazy so that it processes a line at time? By the way, the MD5 function which I use and is included as part of HSLIBS has the type String -> IO String. The MD5 algorithm really is a function and should have type String -> String. Do people agree and if so how do I get it changed? Dominic. -- Compile with ghc -o test test.hs -static -package util -- under Windows. module Main(main) where import IO(openFile, hPutStr, IOMode(ReadMode,WriteMode,AppendMode)) import MD5 import Char -- showHex and showHex' convert the hashed values to -- human-readable hexadecimal strings. showHex :: Integer -> String showHex = map hexDigit . map (fromInteger . (\x -> mod x 16)) . takeWhile (/=0) . iterate (\x -> div x 16) . toInteger hexDigit x | (0 <= x) && (x <= 9) = chr(ord '0' + x) | (10 <= x) && (x <=16) = chr(ord 'a' + (x-10)) | otherwise = error "Outside hexadecimal range" powersOf256 = 1 : map (*256) powersOf256 showHex' x = showHex $ sum (zipWith (*) (map ((\x -> (mod x 16)*16 + (div x 16)) . toInteger . ord) x) powersOf256) -- The type Anon and function anonymize hide the anonymisation -- process. In this case, it's a hash function -- digest :: String -> IO String which implements MD5. type Anon a = IO a class Anonymizable a where anonymize :: a -> Anon a -- MyString avoids overlapping instances of Strings -- with the [Char] data MyString = MyString String deriving Show instance Anonymizable MyString where anonymize (MyString x) = do s <- digest x return ((MyString . showHex') s) instance Anonymizable a => Anonymizable [a] where anonymize xs = mapM anonymize xs filename = "ldif1.txt" fileout = "ldif.out" readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename a <- anonymize((map MyString) (lines s)) hPutStr h (unlines (map (\(MyString x) -> x) a)) main = readAndWriteAttrVals ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

message
by www＠dcs.gla.ac.uk 10 Jan '01

10 Jan '01

[This message is sent through a WWW-Email gateway.] [The authenticity of the sender can not be validated.] [Message sent from the following machine - 64.208.99.35 ] [after accessing this URL http://www.dcs.gla.ac.uk/scripts/global/send_message?glasgow-haskell-users@…] -- Hi, I am facing problems with dynamic linking under Linux. For example I have two programs , test.cxx and client.cxx. I compile test.cxx to get a shared library. Now test.cxx has a function called callme() which is not declared but not defined. I could compile this to get the .so. However , on trying to compile , client.cxx with this .so, I get undefined reference to callme(). Note that client.cxx DOES NOT call the function callme(). Is there a way to go around this problem and get the linker to search for only those functions which are called ? I would be greatly indebted 2 U if U could suggest a way out. Thanking you in anticipation, Pradipto Kolay Design Engineer (Wipro GE Medical Systems) Pradipto.kolay(a)geind.ge.com Code : Test.cxx - #include <iostream.h> char *printhello() { cout << "Hello world " << endl << flush; } void func() { callme(); } gcc -shared -embedded-relocs -o libTest.so test.o (Works fine) client.cxx - #include <iostream.h> extern char *printhello(void ); main() { printhello(); } g++ -v client.cxx -L. -Bdynamic -lTest O/P : ./libTest.so: undefined reference to `callme' collect2: ld returned 1 exit status g++: file path prefix `dynamic' never used --

1 0