- Glasgow-haskell-users

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

[THRILLSEEKERS] GHC head bursts into action on Windows!
by Reuben Thomas 05 Jan '01

05 Jan '01

Those Windows users of GHC who like to live on the bleeding edge may like to know that the CVS head version of GHC is now alive and kicking on Windows. Both text and Windowing "hello, world" programs work fine (and probably much other stuff, since the basic code generation for Intel is quite well tested now). I'm particularly keen to get bug reports for the Windows version of GHC (and in particular for the Win32 API if anyone's using it), since we don't do much testing of that sort of thing. -- http://sc3d.org/rrt/ | free, a. already paid for (Peyton Jones)

1 0

instance Bits Int
by George Russell 04 Jan '01

04 Jan '01

Why isn't Int an instance of Bits?

1 0

"Illegal class assertion"
by George Russell 04 Jan '01

04 Jan '01

is not a very helpful message, especially as GHC can't be bothered to pinpoint exactly where the error occurred. In this particular case, "Missing type variable in instance context" might be more helpful.

1 0

Happy InstallShield update
by Reuben Thomas 04 Jan '01

04 Jan '01

I just noticed that the Happy 1.9 InstallShield contained a dynamically linked executable for Happy. This was a Bad Idea, so I've replaced it with a statically linked executable. This should work for more people. -- http://sc3d.org/rrt/ | maxim, n. wisdom for fools

1 0