Marc van Dongen writes:
Just to let you know.
When trying to make all from CVS I got the following:
make[2]: *** [MatchPS.o] Segmentation Fault (core dumped)
make[1]: *** [all] Error 1
make: *** [all] Error 1
I had this before. Re-making will solve the problem.
Let me know if more
I just mad ghc-4.07 from cvs and tried to use it.
After a few seconds I got:
Result.hs:29:
Prelude.hi:1 Interface file version error; Expected 407
found version 406
Result.hs:29: Could not find valid interface file `Prelude'
Compilation had errors
Any suggestions as to how
Simon Marlow wrote:
I think the only answer to this is "litlits are deprecated". We'll
have to make do with foreign imports to get these kind of constants.
It's not clear to me how exactly this should be accomplished via
foreign import. The (well, *my* :-) basic problem is: How do you
map
| 3. [dom@lhrtbax pcre]$ make Pcre
| ../../src/ihc -fhs-to-c -fno-qualified-names
| -fexclude-system-includes -cpp -I/h
| ome/dom/pcre-2.08/ --asf=Pcre.asf -fvoid-typedef-is-abstract
| -finline-synonyms -
| fout-pointers-are-not-refs-c Pcre.idl -o Pcre.hs
| failed
| Reason:
It's not clear to me how exactly this should be accomplished via
foreign import. The (well, *my* :-) basic problem is: How do you
map about 1000 numerical #defines from C header files (OpenGL/GLUT)
efficiently to Haskell? Saving some STG state, calling out to C land,
and restoring some state
Simon Marlow wrote:
If you can #include the header file into the Haskell source, then
you can get away without litlits.
Of course, in the general (and in the OpenGL/GLUT) case you can't.
If your header file contains extra gumph like prototypes and stuff,
you can use this little trick: [...]
Depending on the OpenGL version there are #defines
or a big enum. So the only portable way without litlits would be a
small automatically generated C program that is run as part of
HOpenGL's configuration process and outputs Haskell definitions or
#defines for all needed constants.
George Russell writes:
I find the documentation of takeMVar and readMVar in section
1.4.1 confusing
if not non-existent.
Thanks, I've updated the documentation on MVars to be a little closer to
reality.
Cheers,
Simon
That pretty much completes my sweep over the outstanding bug reports today.
Thanks everyone for bearing with us.
I've got the following left to deal with:
- Ralf Hinze's "Misleading error message" (Simon - looks
like your domain this one)
- Marcin Kowalczyk's result type signatures,
Marcin 'Qrczak' Kowalczyk wrote:
IMHO the following should be efficient, calling the function only
once, near the time of the first use (if not, should be fixed):
foreign import aConstant :: Int
#include header.h
int aConstant (void)
{
return
10 matches
Mail list logo