Re: problems with FFI including h files
Alastair Reid [EMAIL PROTECTED] writes: I thought we established that generating valid C prototypes from the Haskell FFI type signature wasn't possible due to the incompleteness of the Haskell type (lack of 'const' modifiers for one thing - is there anything else?). Compilers use the same calling sequence whether you tell them about const or not. I believe that we can call all C functions correctly knowing only the calling convention (ccall, stdcall, etc) and the Haskell type. I certainly hope this is true since Hugs' implementation of wrappers depends on it. (Hmmm, some calling conventions do funny things when passing and returning small structs. I don't know much about this though...) I think some ABI's specify a different calling convention for varargs functions than non-varargs functions. (I remember reading this on some Haskell mailing list some time back, one of the previous times this same discussion occurred.) Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Poll: scope in GHCi
Simon Marlow [EMAIL PROTECTED] writes: Ok, so in general a 'scope' can be constructed by combining: 1. the full top-level scope from zero or more *interpreted* modules 2. the exports of zero or more modules (interpreted or compiled) 3. any temporary bindings made on the command line I'd like to suggest one more thing that it would be nice to have in scope. I would like every loaded module to be imported qualified into the scope. (In fact, I would prefer if this were the default, although I suppose it might be useful to have a way to turn it off.) Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc --make feature request
Simon Marlow [EMAIL PROTECTED] writes: GHC actually has rather sophisticated recompilation checking which goes beyond just checking whether the interface changed - it keeps version information for each entity exported by a module and only recompiles if any of the entities actually used by the module have changed (this is described in the user's guide under the section on recompilation checking). I've seen unexpected compiles using ghc --make. I've got a system with modules A, B, and C; A depends on B and B depends on C. I've seen the following sequence of events: I change C ghc --make A compiles C, B, and A I change A ghc --make A skips C and compiles B and A I don't know of any reason why it would have compiled B in the second case. If this is not a known bug, I can try to reproduce it and submit a formal bug report. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HOpengl on Ghc 5.02
Nicolas [EMAIL PROTECTED] writes: Hi there, Sorry for this stupid question: Is there a distrib of a HOpenGl package working with ghc 5.02. I tried the CVS but don't manage to make it work (ghc 5.03 panic). Can someone help me? I got HOpenGL to work without trouble. On September 29, I checked out the ghc-5-02 branch from CVS, configured it with --enable-hopengl, and built and installed it. (I actually built a Debian package, using the Debian packager's build scripts.) I doubt if it matters, but I'm using HOpenGL with gtk+hs and gtkglarea instead of Glut. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePtrCompare, anybody?
Leon Smith [EMAIL PROTECTED] writes: However, in this situation, pointer comparison is simply an arbitrary total order on the set of all atoms, which is all we need to implement finite maps based on search trees. And of course, pointer comparisons are a much cheaper operation that actual string comparison. You could just add an extra Int sequence number to your Atoms, and compare using that. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC FFI Return Type Bug
Sigbjorn Finne [EMAIL PROTECTED] writes:
Julian Seward (Intl Vendor) [EMAIL PROTECTED] writes:
Hmm, we're looking at this. However, I don't really know what
C is or is not supposed to do here. Given
char fooble ( ... )
{
return 'z';
}
on an x86, 'z' will be returned at the lowest 8 bits in %eax.
What I don't know is, is the C compiler obliged to clear the
upper 24 bits of %eax, or does that onus fall on the callee?
Yes, the callee is required to narrow expr in 'return expr;' to
fit that of the specified return type -- see 9.8 of Harbison and
Steele. So, a C compiler that cause f() to return 0x7fff for
the following,
unsigned char g()
{
return 0x7fff;
}
unsigned int f()
{
return g();
}
is in the wrong. [Notice that narrowing for signed integral types
is undefined in ISO C, but most current-day compilers implement
such narrowing ops the same way, i.e., by masking off excess bits.]
It's certainly true that an ISO C compiler on a typical machine must
return 255 from f() (on an atypical machine, it's possible to have
unsigned char be a 32-bit type). However, this is essentially
unrelated to the question of whether the x86 ABI allows g() to return
a value in %eax that has the upper 3 bytes non-zero.
When I compile the following file:
abitest.c
unsigned int g_val;
unsigned char g()
{
return g_val;
}
unsigned int f()
{
return g();
}
---
with the command
gcc -Wall -O2 -fomit-frame-pointer -S abitest.c
I get the output:
abitest.S
.file abitest.c
.version01.01
gcc2_compiled.:
.text
.align 16
.globl g
.typeg,@function
g:
movzbl g_val,%eax
ret
.Lfe1:
.sizeg,.Lfe1-g
.align 16
.globl f
.typef,@function
f:
call g
andl $255,%eax
ret
.Lfe2:
.sizef,.Lfe2-f
.comm g_val,4,4
.ident GCC: (GNU) 2.7.2.3
---
You can see that the code for f is:
call g
andl $255,%eax
ret
So gcc believes that a function which returns a value of type unsigned
char is not responsible for clearing the high 3 bytes of %eax.
Carl Witty
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Endangered I/O operations
Simon Marlow [EMAIL PROTECTED] writes: You obtain the ordering properties by setting the handle to NoBuffering, otherwise you get buffered input/output. Wouldn't it be deviating from the report to do extra flushing in the buffered case? (this is something of a technicality, actually we already do non-report flushing in several cases and our line-buffered input isn't line-buffered at all). If the report does not allow the implementation to flush buffers at any time, I would call that a bug in the report. I would much rather use an implementation where stdout and stderr came out in the right order, and reading from stdin flushed stdout. (As another example, an implementation might want to flush all buffers before doing a fork(), to avoid duplicated output.) The only caveat is that if such flushing is allowed but not required, it might encourage writing sloppy, nonportable code. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
Manuel M. T. Chakravarty [EMAIL PROTECTED] writes: I didn't say that this works for any kind of parser combinator, I merely said that it works Doitse's and mine. Both implement SLL(1) parsers for which - as I am sure, you know - there exists a decision procedure for testing ambiguity. More precisely, whenever the library can build the parse table, the grammar must be non-ambigious. As the parse table construction is lazy, this covers only the productions exercised in that particular run, which is why I said that you need a file involving all grammar constructs of the language. Nothing magic here. Wow. Clearly I haven't spent enough time looking at your parser systems. I apologize for my incorrect assumptions and statements. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
Manuel M. T. Chakravarty [EMAIL PROTECTED] writes: I don't think, the point is the test for non-ambiguity. At least, Doitse's and my self-optimising parser combinator library will detect that a grammar is ambigious when you parse a sentence involving the ambiguous productions. So, you can check that by parsing a file involving all grammar constructs of the language. Sorry, doesn't work. Where do you get this file involving all grammar constructs of the language? If such an approach worked, you could use it to determine whether an arbitrary context-free grammar was ambiguous; but this problem is undecidable. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
