RE: problem with -caf-all

I'm trying to use the -caf-all flag with ghc-6.02, in conjunction with -O (which means going via C...) But in a few modules of a large program, the .hc files contain duplicate definitions of MODsat_CAF_cc_ccs (where MOD = a particular module) I can't see an obvious pattern to the

[ ghc-Bugs-919861 ] Typo in user guide

Bugs item #919861, was opened at 2004-03-20 00:16 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=919861group_id=8032 Category: Documentation Group: 6.2 Status: Closed Resolution: Fixed

[ ghc-Bugs-913728 ] Error in installation (fixed)

Bugs item #913728, was opened at 2004-03-10 21:57 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=913728group_id=8032 Category: Build System Group: 6.2 Status: Closed Resolution: None

PATCH: add malloc function attribute to rts malloc functions

http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Function-Attributes.html The gcc manual says: malloc The malloc attribute is used to tell the compiler that a function may be treated as if it were the malloc function. The compiler assumes that calls to malloc result in

ANNOUNCE: GHC version 6.2.1

The (Interactive) Glasgow Haskell Compiler -- version 6.2.1 We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version

Re: [Haskell] reasons for non-portability

Am Sonntag, 21. März 2004 12:36 schrieben Sie: Wolfgang Jeltsch wrote: [...] My question is, if a module is considered non-portable only if it contains non-portable constructs itself, or if a module is also non-portable if it just imports a module which is non-portable. Both,

Re: [Haskell] reasons for non-portability

Am Montag, 22. März 2004 12:46 schrieben Sie: Am Sonntag, 21. März 2004 12:36 schrieben Sie: Wolfgang Jeltsch wrote: [...] My question is, if a module is considered non-portable only if it contains non-portable constructs itself, or if a module is also non-portable if it just

Re: [Haskell] reasons for non-portability

Am Montag, 22. März 2004 13:29 schrieben Sie: On Sat, Mar 20, 2004 at 08:50:10PM +0100, Wolfgang Jeltsch wrote: according to http://www.haskell.org/hierarchical-modules/libraries/ reference-libraries.html#MODULE-HEADER, each module should have a header which contains a line about

RE: [Haskell] GHC binary for Cygwin

The other day, I tried to compile the Fudgets library with GHC-MinGW. It didn't work, of course, and having GHC for Cygwin would presumably significantly reduce the amount of pain required to port it. (Support for certain Posix system calls and symbolic links would be helpful.) At

RE: [Haskell] reasons for non-portability

Thanks for the info. Well, according to that explanation, all modules would be non-portable since the Prelude is normally implemented using non-standard features. I think, this is solved by declaring all modules described in the Haskell 98 Report portable. One question: Every

[Haskell] ANNOUNCE: GHC version 6.2.1

The (Interactive) Glasgow Haskell Compiler -- version 6.2.1 We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version

Re: [Haskell] Proposal for a Standard of Abstract Collections (with Reference Implementation)

Another comment is that it looks too complicated. Your basic Collection class has 30 members, and some of them are clearly excessive: do you really need all of has, elem, (#), not_elem, and (/#) in the class (rather than defined as auxiliary functions, possibly optimised with fusion)? (Of

[Haskell] main::[String]-IO() ?

Hello everybody, each time I write an application that makes use of command line arguments I have to copypaste the code for dealing with these args to my program from a reference implementation, because it is so hard to remember. What do you think about changing the default type of main or

Re: [Haskell] main::[String]-IO() ?

I typically do: ... main = getArgs = go go [whatever] = ... On Mon, 22 Mar 2004, Steffen Mazanek wrote: Hello everybody, each time I write an application that makes use of command line arguments I have to copypaste the code for dealing with these args to my program from a reference

Re: [Haskell] main::[String]-IO() ?

Steffen Mazanek [EMAIL PROTECTED] writes: Hello everybody, each time I write an application that makes use of command line arguments I have to copypaste the code for dealing with these args to my program from a reference implementation, because it is so hard to remember. What do you think

Re: [Haskell] ANNOUNCE: GHC version 6.2.1

On Monday 22 March 2004 16:40, Simon Marlow wrote: - The threaded runtime system is included by default. To link a program with this variant of the RTS, add the -threaded option when linking. After downloaded the sources i found that ./configure --help still lists the

RE: [Haskell] COM port IO on a Windows machine?

Thanks, Steve and Axel, for your help. I have got serial port IO working, but the solution is a bit ugly. My solution (below) works on Windows 2000, Hugs Nov 2003. It does not work with Windows 2000, GHI 5.04.2. Later tonight I will try it on Windows ME with the latest versions of GHC and Hugs.

[Haskell-cafe] ????Pattern match(es) are overlapped???

I am implementing HTTP and I have something like: newtype Method = Method String getMethod = Method GET putMethod = Method PUT [...] doMeth getMethod = ... doMeth putMethod = ... GHC gives me a patter matches are overlapped warning. And when I run, I discover that pattern

Re: [Haskell-cafe] ????Pattern match(es) are overlapped???

newtype Method = Method String getMethod = Method GET putMethod = Method PUT [...] doMeth getMethod = ... doMeth putMethod = ... For Haskell the last two lines look both like pattern-matching on a variable which always matches. You might as well have written: doMeth x =

Re: [Haskell-cafe] ????Pattern match(es) are overlapped???

Arjan van IJzendoorn [EMAIL PROTECTED] writes: newtype Method = Method String getMethod = Method GET putMethod = Method PUT doMeth getMethod = ... doMeth putMethod = ... You will have to write: doMeth (Method GET) = ... doMeth (Method PUT) = ... Or (I assume, haven't

RE: [Haskell-cafe] ????Pattern match(es) are overlapped???

Hi, Or (I assume, haven't tested) if you insist on renaming the methods: doMeth m | m == getMethod = ... | m == putMethod = ... This, of course, assumes that you've derived (or declared) Method an instance of Eq. Regards, Stefan

Re: [Haskell-cafe] ????Pattern match(es) are overlapped???

I actually ended up using a lookup list e.g. handlers=[(getMethod,doGet),(putMethod,doPut)] which has the convenience of being able to put a 501 Not Implemented in an obvious place. I'll post the code shortly. My goal is to form the core of a generically useful HTTP haskell server library.