- Glasgow-haskell-users

runghc badly broken
by Niklas Broberg 18 Apr '05

18 Apr '05

Hi all, I'm trying to use runghc (6.4 release version, redhat linux), but it appears to be badly broken. It only processes the first argument given to it, so while --------------------------- > runghc Foo.hs hello with Foo.hs being simply main = putStrLn "hello" --------------------------- works just fine, while for instance --------------------------- > runghc -v1 Foo.hs Loading package base-1.0 ... linking ... done. <interactive>:1:78: Failed to load interface for `Main': Could not find module `Main': it is not a module in the current program, or in any known package. Leaving GHCi. --------------------------- manages to be 1-verbose but doesn't find the file, and --------------------------- > runghc Foo.hs -v1 hello --------------------------- executes the file alright, but forgets verbosity. I can't imagine this is the intended behavior? /Niklas

1 1

HOME: getEnv: does not exist
by Niklas Broberg 18 Apr '05

18 Apr '05

Hi all, when I try to use runghc to execute cgi scripts in apache (on redhat linux), they all fail with with the message "HOME: getEnv: does not exist". I assume this means that GHC is trying to find the HOME dir of the user for some reason, and fails since apache runs as nobody. Could someone shed some light on this matter for me? #!/usr/bin/runghc main = do putStrLn "Content-type: application/xhtml" putStrLn "Content-length: 5\n" putStrLn "Hello" Thanks, /Niklas

3 5

Edison Libraries in ghc 6.4
by Carlos Areces 17 Apr '05

17 Apr '05

Dear All, We are using Glasgow Haskell for the implemenation of a theorem prover. We use the Edison Libraries for efficient implementations of Sets and Heaps. We have a stable version of the prover with no problems and fairly good performance working on ghc 6.2. We have just installed ghc 6.4 and when compiling the source code we've received many warnings like the following one: ./src/hylores/ComplClauseSet.hs:51:0: Warning: Deprecated use of type constructor or class `Min' (imported from MinHeap) This module is unmaintained, and will disappear soon We are making heavy use of types from the Edison library, so we get quite a number of warnings, implying changes all over our code to correct them. Which are exactly the problems with the Edison Library? And what's its future with respect to ghc? If we should abandon Edison, which are the alternatives which will be supported by ghc in the future? In a number of cases, we can already use alternative data types provided in the Data Module (e.g., Map as replacement of FiniteMap), but we couldn't find an alternative to MinHeap. Also, Set is implemented in Data as a Balanced Tree, while the Unbalanced version provided by Edison was sufficient for our application. Any help/guidance very welcome. Best, Carlos. -- Carlos Eduardo Areces INRIA Lorraine

1 0

RE: Complexity bug in garbage collector?
by Simon Marlow 16 Apr '05

16 Apr '05

On 14 April 2005 15:35, Josef Svenningsson wrote: > I've had some fun chasing around a couple of space leaks lately. One > of the graphs that I produced looked like this: > www.cs.chalmers.se/~josefs/coresa.ps > > Notice the shape of the graph. It shows a perfect squareroot function. > But my program should be allocating at a constant rate. From previous > experience this suggests that there is a time complexity bug in the > garbage collector. This makes it take time proportional to the square > of the amount of allocated memory. Can someone confirm this? The X axis of the heap profile is mutator time: that is runtime excluding GC time, so you wouldn't see any non-linear GC effects in the shape of the heap profile anyway. You'll be able to confirm this by comparing the time on the profile to the wall-clock time, and checking the output from +RTS -sstderr is useful too. It's possible you're seeing cache effects: as the working set grows larger, the program slows down. The shape does look a bit too perfect to be cache effects, though. I wouldn't rule out any bugs (of course :-), so please send us further evidence if you find it. Cheers, Simon

2 1

RE: hi-boot and dependencies bug?
by Simon Peyton-Jones 16 Apr '05

16 Apr '05

6.4 does mutual recursion much much better. See the manual. Don't expend much effort on mutual recn in 6.2 S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Isaac Jones | Sent: 16 April 2005 01:46 | To: GHC-users list | Cc: Simon Marlow | Subject: hi-boot and dependencies bug? | | Greetings. | | I haven't tested this with ghc 6.4 yet, and I don't know if this is a | known problem. I noticed this while building support for cabal. | | I have two mutually recursive modules, prepared as described in the | GHC 6.2 user's manual: A and B | | I create A.hi-boot | in B, in import {-source-} A | | This works fine. But now I create C, which imports B (not A). When I | compile with --make, A does not get built, and I get a link-time | error. | | However, if C imports A directly, it builds everything just fine. | | I've attached a tarball with the example. Test it like this: | | % ghc --make C.hs | Chasing modules from: C.hs | Compiling B ( ./B.hs, ./B.o ) | Compiling Main ( C.hs, C.o ) | Linking ... | ./B.o(.text+0x1b): In function `__stginit_B_': | : undefined reference to `__stginit_A_' | collect2: ld returned 1 exit status | | | | peace, | isaac | | p.s. please CC me on replies; i'm not subscribed to this mailing list

1 0

runghc and .ghci
by John Meacham 16 Apr '05

16 Apr '05

I notice that my .ghci is sourced for programs run via runghc (runhaskell). This is causing trouble because I have things like :set +t +s and other options which mess up the running of many scripts. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

hi-boot and dependencies bug?
by Isaac Jones 16 Apr '05

16 Apr '05

Greetings. I haven't tested this with ghc 6.4 yet, and I don't know if this is a known problem. I noticed this while building support for cabal. I have two mutually recursive modules, prepared as described in the GHC 6.2 user's manual: A and B I create A.hi-boot in B, in import {-source-} A This works fine. But now I create C, which imports B (not A). When I compile with --make, A does not get built, and I get a link-time error. However, if C imports A directly, it builds everything just fine. I've attached a tarball with the example. Test it like this: % ghc --make C.hs Chasing modules from: C.hs Compiling B ( ./B.hs, ./B.o ) Compiling Main ( C.hs, C.o ) Linking ... ./B.o(.text+0x1b): In function `__stginit_B_': : undefined reference to `__stginit_A_' collect2: ld returned 1 exit status peace, isaac p.s. please CC me on replies; i'm not subscribed to this mailing list

1 0

Re: Bus Error with ghc 6.4 on Solaris
by Volker Stolz 15 Apr '05

15 Apr '05

In gmane.comp.lang.haskell.glasgow.bugs, you wrote: > Simon M is away today and Monday, but I do recall him saying something > about the Solaris port being broken. I'm sure he would welcome help > getting it fixed. Are there any of you who build GHC from source, and > know Solaris? I'm currently running a build on $slowhost, so I probably won't get to actual debugging until Monday. We're talking about the release, not -HEAD, right? Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME It's a million to one chance, but it just might work.

1 0

Do you use GHC?
by Simon Peyton-Jones 15 Apr '05

15 Apr '05

Dear Haskell folk, PLEASE READ THIS IF YOU USE THE Glasgow Haskell Compiler (GHC). I virtually never send messages to overlapping sets of lists, but I'm doing so this time, because I'd really like to get to everyone who uses GHC. Here at GHC HQ, we are often asked how many people use GHC, and what kind of folk they are. Since GHC is free software, we have no clue. Download stats tell us a bit, but not much, because GHC gets out through a variety of other routes too (e.g. Debian). We also have little idea about which aspects of GHC are most valued, nor of what enhancements would be most sought after, or which platforms are most important to you. We hear quite a bit from the bleeding-edge folk who push the limits, but much less from people who just want to get the job done. Thus motivated, Tomasz Zielonka kindly put together a (WASH-powered) survey for us, which asks you to tell us a bit yourself and how you use GHC. We've had about 230 responses so far; thank you to those 230 folk. But I'm pretty certain there are more than 230 people in the world who use GHC! THIS MESSAGE IS TO ASK YOU TO TAKE 5 MINS TO COMPLETE THE SURVEY http://www.haskell.org/ghc/survey/start.cgi We'd like to hear from *absolutely everyone* who uses GHC: whether you are a first-year undergraduate or a famous professor; whether you use GHC for industrial applications or recreation; whether you use higher-rank polymorphism or have only just learned what functional programming is. Everyone! We'll use the information to guide our future priorities, and we'll publish some kind of summary of what we learn in due course. It's all anonymous, of course, unless you choose to say who you are. If you think it's appropriate, please circulate this announcement locally, e.g. to your students who may not be on the Haskell mailing list Many thanks Simon PJ and Simon Marlow

1 0

RE: Re[2]: GHC 6.4/mingw32: files larger than 4 GBandhFileSize/hSetFileSize/c_stat
by Simon Peyton-Jones 15 Apr '05

15 Apr '05

I have no clue what the right thing here is. Simon M is away today and Monday, but he'll doubtless tell you on Tuesday. He is supreme being for this kind of stuff. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Bulat Ziganshin | Sent: 12 April 2005 15:22 | To: glasgow-haskell-users(a)haskell.org | Subject: Re[2]: GHC 6.4/mingw32: files larger than 4 GBandhFileSize/hSetFileSize/c_stat | | Hello Simon, | | mingw32 have 32-bit off_t type; access to large files are supported | with special functions and structures defined in msvcrrt.dll: | | _CRTIMP __int64 __cdecl _lseeki64(int, __int64, int); | _CRTIMP __int64 __cdecl _telli64(int); | _CRTIMP int __cdecl _fstati64(int, struct _stati64 *); | _CRTIMP int __cdecl _stati64(const char *, struct _stati64 *); | struct _stati64 { | .... | __int64 st_size; | .... | }; | | so, we need either | 1) define COff to __int64 instead of off_t and rewrite existing | functions to work with 64 bit filesizes | or | 2) define new set of low-level functions to work with 64 bit | filesizes. define high-level functions in terms of these 64-bit | functions on Win32 | | what solution will be better? in the first case COff no longer will be | equal to off_t, what some applications can imply. in the second case | we will add a lot of duplicating code | | is there any other (GHC-supported) environments supporting 64 bit | filesizes, but having only 32-bit off_t? | | (sorry for my bad English, i'm too far from native speaker) | | | | Friday, April 08, 2005, 3:33:36 PM, you wrote: | | SPJ> By all means. If someone cares to send us a patch, we'll incorporate | SPJ> it. | | SPJ> | While GHC I/O library on mingw32 platform perfectly reads and writes | SPJ> | files larger than 4 GB, functions hFileSize/c_fstat, | SPJ> | hSetFileSize/c_ftruncate and c_stat are still tied to C functions | SPJ> | returning 32 bit values and as a result truncate larger sizes to their | SPJ> | low 32 bits. Can this behaviour be fixed in the next bug-fix version? | | | -- | Best regards, | Bulat mailto:bulatz@HotPOP.com | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0