April 2005 - Glasgow-haskell-users

RE: Porting the GHC to GNU/Hurd
by Simon Marlow 19 Apr '05

19 Apr '05

On 14 April 2005 10:48, Ross Paterson wrote: > On Sun, Apr 10, 2005 at 10:39:08PM +0100, Simon Marlow wrote: >> On 10 April 2005 14:20, Thomas Schwinge wrote: >>> [ Grrr. Why do I have to subscribe just to post this message? ] >> >> Sorry for the inconvenience, it's because I don't have time to wade >> through all the spam. > > Is it possible to allow subscribers of any haskell.org lists (or just > haskell) to post to all other lists? Making it easier for people to > post to the appropriate list is another kind of spam control. It doesn't look lke Mailman provides a way to do this, though I agree it would be a good idea. Cheers, Simon

1 0

RE: Re[2]: GHC 6.4/mingw32: files larger than 4 GBandhFileSize/hSetFileSize/c_stat
by Simon Marlow 19 Apr '05

19 Apr '05

On 12 April 2005 15:22, Bulat Ziganshin wrote: > 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 COff should be the same as off_t, because it is expose to the via Foreign.C.Types. For the I/O library, however, you could use the 64-bit interfaces explicitly (probably confininng the changes to System.Posix.Internals). Unix systems ususally require you to #define something to get access to the 64-bit off_t, we rely on autoconf to tell us what this is. Cheers, Simon > 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: > >> By all means. If someone cares to send us a patch, we'll incorporate >> it. > >>> While GHC I/O library on mingw32 platform perfectly reads and writes >>> files larger than 4 GB, functions hFileSize/c_fstat, >>> hSetFileSize/c_ftruncate and c_stat are still tied to C functions >>> returning 32 bit values and as a result truncate larger sizes to >>> their low 32 bits. Can this behaviour be fixed in the next bug-fix >>> version?

1 0

RE: hi-boot and dependencies bug?
by Simon Marlow 19 Apr '05

19 Apr '05

I expect this is the same bug we fixed in 6.4 recently. One workaround is to mention the missing module explicitly on the ghc command line, to force it to be included in the program. Cheers, Simon On 16 April 2005 17:30, Simon Peyton-Jones wrote: > 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

Partial application of type constructors?
by Conal Elliott 19 Apr '05

19 Apr '05

GHC 6.4 objects to the following simple program, pointing to the partial application of the type constructor AddL. Is there a work-around? {-# OPTIONS -fglasgow-exts #-} data LMap a b type AddL arr a b = a `arr` LMap a b data DFunA arr a b = DFunA (a `arr` b) (DFunA (AddL arr) a b) The complete error message: Type synonym `AddL' should have 3 arguments, but has been given 1 When checking the data constructor: forall arr a b. DFunA (arr a b) (DFunA (AddL arr) a b) In the data type declaration for `DFunA' Is there a serious difficulty with handling partial type applications? - Conal

2 1

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 15 Apr '05

15 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