- Glasgow-haskell-users

Compiling GHC disabling the type checker
by Neil Mitchell 16 Oct '06

16 Oct '06

Hi, I would like to write a translator which takes a Haskell-like language to GHC compilable Haskell. This Haskell-like language is not explicitly typed, and cannot have types inferred for it (rank 2 types may exist etc), however it is known that the program will not crash with a type error. All case statements are well typed, i.e. case x of {1 -> ..; True -> ...} will not happen, although types cannot be given to the whole program. How does GHC react to a really large number of unsafeCoerce's? Is this likely to destroy performance? Has anything like this been done before? I know that LML was able to "turn off" the type checker, but I guess GHC doesn't have such an option, because of its typed Core language. Thanks Neil

5 4

6.4.3 and threaded RTS problems
by Simon Marlow 16 Oct '06

16 Oct '06

Hi Folks, Roman Leshchinskiy and I looked into the 6.4.3 crashes on Sparc/Solaris yesterday. I think we may have found the problem, and it seems likely that this is the same problem affecting 6.4.3 on MacOS X. The threaded RTS is assuming in a couple of places that pthread_cond_wait() doesn't spuriously wake up, which is apparently the case on Linux but not true in general. I don't think this bug affects 6.6. I could be wrong, however. Does anyone on MacOS X have a recent testsuite run with the HEAD? I'll try to put together a fix for 6.4.3 when the 6.6 release cycle has died down. Cheers, Simon

6 13

Parallel GC
by Chad Scherrer 16 Oct '06

16 Oct '06

IIRC, there was some work being done this past summer on parallelizing GC for SMP GHC (I think that's my current record for most acronyms in one sentence). GHC 6.6 is reported as having single-threaded GC, and I'm wondering if an unforeseen technical problem might have come up with parallelization, or whether something is still in the works. Excitedly awaiting GHC's SMP GC, Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

2 2

load stdm problem
by TOPE KAREM 16 Oct '06

16 Oct '06

Hi, After downloading Haskell 98 (current version), I tried to load stdm by typing *:load stdm *I kept gettin <command line> could not find module 'stdm' I added path under system variables under environment variables like this: control panel/system/Aadvanced/(under system variable)Environment variables/path *c:ghc/stdm.hs* After which I tried to load stdm as before but there is no changes. Could you please help. Thanks Tope, South Africa

1 0

Bad control characters in GHCi 6.6 (Mac OS X PPC)
by Björn Buckwalter 16 Oct '06

16 Oct '06

Dear all, I downloaded the GHC 6.6 tarballs, built and installed them on my mac (Tiger, PPC) using the documented procedure: ./configure make make install The build and install was fairly smooth. However, ghci will not recognize "control characters", e.g. delete/backspace, arrow keys, ctrl-a, ctrl-d et c. It seems to recognize ctrl-c for cancelling a line but will print the ^C first. A typical session may look like: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> 1 + 2 3 Prelude> Arrow keys ^[[D^[[A^[[B^[[C <interactive>:1:11: lexical error at character '\ESC' Prelude> Delete ^? <interactive>:1:7: lexical error at character '\DEL' Prelude> Control C ^CPrelude> Ok, command was terminated but no newline... now backa^?space ^?^?^? <interactive>:1:2: parse error on input `,' Prelude> ^D <interactive>:1:0: lexical error at character '\EOT' Prelude> :q Leaving GHCi. My previous installation of GHC (6.4.2 from darwinports) didn't have these problems. I realize that this may be due to my lack of unix skills rather than pertinent to GHC. Any help would be appreciated. Thanks, Bjorn Buckwalter

2 1

OSX Haskell
by Wilson MacGyver 16 Oct '06

16 Oct '06

Hi, Is the instructions/notes for the OSX pkgs that were prepared Wolfgang Thaller available anywhere? I would like to make the OSX binaries more install friendly, like the pkg for 6.4.1 Thanks, Mac -- Omnem crede diem tibi diluxisse supremum.

1 0

foldl laziness support
by Serge D. Mechveliani 15 Oct '06

15 Oct '06

Dear Haskell implementors, I keep on facing a frightening problem of the laziness support. Consider the example of ----------------------------------- import List (union) main = let n = 10^4 :: Int in putStr (shows (take 2 $ unionMany [[1 .. i] | i <- [1 .. n]]) "\n") unionMany = foldl union [] ----------------------------------- Compiling it in ghc-6.6, -O, we have the running cost O(n), instead of O(1). Now, changing to unionMany [] = [] unionMany (xs: xss) = union xs (unionMany xss) , we reach O(1). For example, for n = 10^9, the time remains less than 0.01 sec. My program has many fragments of such kind, when a function produces a long list, some client functions need all the list, and others need only its small initial part. When we rely on the standard library, foldl creeps in everywhere. Also may things are easy to program via foldl. I wonder how to avoid these numerous cost pitfalls. Maybe, the complier could do more optimization? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

4 3

Re: darcs patch: initial, very incomplete tags generator (and 16 more)
by Bulat Ziganshin 15 Oct '06

15 Oct '06

Hello nr, Saturday, October 14, 2006, 12:30:54 AM, you wrote: > The ultimate goal is to replace hasktags with > a tags generator based on GHC-as-a-library. is this working at this time? how i can download/use it? hasktags is over-simplified utility, having a really parsing alternative to it will be great -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 6

ghc 6.6 for Windows crashes my program on exit
by Brian Hulley 15 Oct '06

15 Oct '06

Hi, Has anyone else come across this crash with ghc 6.6 on Windows? The thread 'Win32 Thread' (0x5c8) has exited with code 0 (0x0). First-chance exception at 0x7c90eb74 in main.exe: 0xC0000008: An invalid HANDLE was specified. Unhandled exception at 0x7c90eb74 in main.exe: 0xC0000008: An invalid HANDLE was specified. The program has this form: main = do display_graphics_window_and_run_message_loop -- window has now been closed putStrLn "Finished\n" getChar and has been working perfectly with ghc 6.4.2. The only changes I had to make to compile it with ghc 6.6 were minor tweaks to deal with the changes to the ByteString api. When I run the ghc 6.6 compiled version, the window is displayed and works as usual, then when I dismiss the window, "Finished" is written to the console. It is only when I press return in the console that the program crashes on exit with that error message. I'm running the program from within MS Visual Studio (the graphics window is written as a C DLL that's called from Haskell). If I just run the program directly from the desktop the program exits silently . If I run the program from a command shell nothing unusual happens either: no error is printed out but the crash-on-exit is presumably still happening. >From just looking at the error message, it looks to me like it might be that the rts exit code has somehow held onto the handle of the window's thread after this thread no longer exists, but of course this is only a wild guess. Alternatively, which file(s) in the ghc source distro would be the place to start looking to see what happens between the time the thread for the window has exited and the thread for main.exe exits? Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

1 1

Visual Haskell 2005?
by Michael Sparks 15 Oct '06

15 Oct '06

Are there any plans to make a version of Visual Haskell that works with Visual Studio 2005?

2 1