On Fri, Mar 07, 2008 at 03:04:46AM +, Duncan Coutts wrote:
> > Though, if there were a way to figure that stuff out without a c
> > compiler in a portable way, that would be cool.
>
> It is specified by the platform C ABI. So it varies from one platform to
> another, but it is specified for mo
On Thu, 2008-03-06 at 04:50 -0800, John Meacham wrote:
> On Thu, Mar 06, 2008 at 12:41:56PM +, Duncan Coutts wrote:
> > c2hs has to read the header files on your system to be able to check any
> > consistency.
> >
> > I'm not sure why hsc2hs is the minimal tool. It relies on a C compiler
> >
Hi Greg,
Thanks again for maintaining ghc in macports!
I tried installing ghc through macports. Unfortunately, the build
failed with the following error message below. I'd be happy to send
you a complete log, if you think it would help. Many thanks,
Wouter
main/ParsePkgConf.hs:296:35:
Hi,
my binary distribution
http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-linux.tar.bz2
creates binaries that fail on some i386 linux boxes with:
timer_create: Invalid argument
I've built the distribution with
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
and the file
On Thu, Mar 06, 2008 at 12:41:56PM +, Duncan Coutts wrote:
> c2hs has to read the header files on your system to be able to check any
> consistency.
>
> I'm not sure why hsc2hs is the minimal tool. It relies on a C compiler
> where c2hs does not. What happens with Haskell implementations that
On Thu, 2008-03-06 at 03:11 -0800, John Meacham wrote:
> On Thu, Mar 06, 2008 at 10:43:41AM +, Duncan Coutts wrote:
> > > something like this:
> > >
> > > foreign import ccall "get_COLOR_PAIRS" colorPairsPtr :: Ptr CInt
> > > #def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;}
> >
On Thu, Mar 06, 2008 at 11:43:08AM +, Simon Peyton-Jones wrote:
> See 4.5.5 in the Report http://haskell.org/onlinereport/decls.html.
>
> Rule 1 says that 'compress' is not generalised. So it gets the type
> [t] -> [t]
> where 'a' is an as-yet-un-determined type; in implementation ter
| On Thu, Mar 06, 2008 at 08:56:15AM +, Simon Peyton-Jones wrote:
| > No, it's fine. compress is indeed monomorphic, but since it's called
| > at exactly one type, namely Char, so it gets the monomorphic type
| > [Char] -> [Char]. That is what the Haskell Report says. (Or tries
| > to.)
|
| B
On Thu, Mar 06, 2008 at 08:56:15AM +, Simon Peyton-Jones wrote:
> No, it's fine. compress is indeed monomorphic, but since it's called
> at exactly one type, namely Char, so it gets the monomorphic type
> [Char] -> [Char]. That is what the Haskell Report says. (Or tries
> to.)
But when I mod
On Thu, 2008-03-06 at 11:12 +, Simon Peyton-Jones wrote:
> If, following this thread, you conclude that GHC should do something
> different than what it does, can you submit a Trac ticket? With a
> small example?
It's probably not worth quibbling about the issue I raised about "foo.h
&foo" i
If, following this thread, you conclude that GHC should do something different
than what it does, can you submit a Trac ticket? With a small example?
Thanks
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Duncan Coutts
| Sent: 06 March 2008 00:
On Thu, Mar 06, 2008 at 10:43:41AM +, Duncan Coutts wrote:
> > something like this:
> >
> > foreign import ccall "get_COLOR_PAIRS" colorPairsPtr :: Ptr CInt
> > #def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;}
>
> The problem with that is that it doesn't follow the rules about
On Wed, 2008-03-05 at 18:46 -0800, John Meacham wrote:
> On Thu, Mar 06, 2008 at 02:18:08AM +, Duncan Coutts wrote:
> > There are rather too many of these C libs that define their public
> > interfaces as macros. I had to adjust the zlib binding the other day to
> > allow it to compile without
No, it's fine. compress is indeed monomorphic, but since it's called at
exactly one type, namely Char, so it gets the monomorphic type [Char] ->
[Char]. That is what the Haskell Report says. (Or tries to.)
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
14 matches
Mail list logo