RE: make all: [MatchPS.o] Segmentation Fault (core dumped)
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 information is required. can't reproduce this one: is it still causing you hassle? Simon
RE: Interface file problem
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 to fix this? You need to rebuild your libraries too (ghc/lib and hslibs). Cheers, Simon
Re: litlits in interface files
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 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 for accessing every value will definitely make my binding about 1-2 orders slower. Currently the usage of litlits compiles into a single load instruction in machine code. *sigh* Normally I'm not an advocate of O(1) optimizations, but in this special case, which will happen in lots of inner loops, the situation is different... Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
RE: HaskellDirect and Regular Expressions (PCRE)
| 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: /usr/include/bits/types.h:38: Parse error on input: | unsigned long long | int __u_quad_t; | | make: *** [Pcre.hs] Error 1 This looks like an HDirect problem, so I'm ccing Sigbjorn. I reported this one to Sigbjorn a while ago; I believe he's fixed it now and it'll be in the next release of H/Direct. It was to do with strange gcc-isms in the system header files that H/Direct couldn't grok. Cheers, Simon
RE: litlits in interface files
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 for accessing every value will definitely make my binding about 1-2 orders slower. Currently the usage of litlits compiles into a single load instruction in machine code. *sigh* Normally I'm not an advocate of O(1) optimizations, but in this special case, which will happen in lots of inner loops, the situation is different... If you can #include the header file into the Haskell source, then you can get away without litlits. If your header file contains extra gumph like prototypes and stuff, you can use this little trick: $ cat wibble.c #include myheader.h ^D $ gcc -E -dM wibble.c wibble.h and #include "wibble.h" in your Haskell source. Bear in mind that litlits will only work if you're compiling via C anyway, which is a compilation route we're doing everything we can to deprecate :) Cheers, Simon
Re: litlits in interface files
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: [...] Col trick, really! Didn't know the -dM flag. But again in my case it doesn't help: 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. Aaaargl... Has anybody better ideas (coding tricks, extensions for the FFI, etc.) for a general solution to this problem? Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: litlits in interface files
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. Aaaargl...
Has anybody better ideas (coding tricks, extensions for the FFI, etc.)
for a general solution to this problem?
I don't know about a general solution, but I did write a little program
to auto-generate a bunch of Haskell constants from a C header file,
which you are welcome to steal and modify. In my case, it was
converting the #defines from sys/errno.h to a workable Haskell
enumeration.
For instance, EDEADLK is 35 under Linux, 78 under SunOS4, and 45 under
Solaris2. In addition, EDEADLOCK==EDEADLK==35 under Linux, doesn't
exist at all under SunOS4, but exists as 56 (which differs from
EDEADLK) under Solaris2. This little Haskell program writes a little C
program which includes the appropriate header, does lots of CPP magic,
and generates a Haskell datatype. The final type is in Eq, Enum, and
Show. If the C decls turn out to be non-contiguous, or to overlap, the
C prog writes a specific instance Enum and/or a function to override Eq,
otherwise, it simply asks for the normal derived instances.
So to use the errno.h constants via the FFI, I simply pass them as ints
by wrapping them with toEnum and fromEnum.
Hope this helps.
Regards,
Malcolm
horrible code starts here
main = do
putStr cprogHeader
mapM_ (putStr . cppify) possibleErrNos
putStr cprogFooter
cprogHeader =
"#include errno.h\n\
\main() {\n\
\ int i, j=0, max=0, noncontig=0, dup=0;\n\
\ char *errs[2000];\n\
\ char *dups[20];\n\
\ int dupi[20];\n\
\ for (i=0; i2000; i++) {\n\
\errs[i]=(char*)0;\n\
\ }\n\
\ for (i=0; i20; i++) {\n\
\dups[i]=(char*)0;\n\
\dupi[i]=0;\n\
\ }\n"
cppify symbol =
"#ifdef "++symbol++"\n\
\ if (errs["++symbol++"]) {\n\
\dups[dup]=\""++symbol++"\"; dupi[dup]="++symbol++"; dup++;\n\
\ } else\n\
\errs["++symbol++"] = \""++symbol++"\";\n\
\ if ("++symbol++"max) max="++symbol++";\n\
\#endif\n"
cprogFooter =
" printf(\"module DErrNo where\\n\\n\");\n\
\ printf(\"{- Automatically generated from /usr/include/errno.h -}\\n\\n\");\n\
\ printf(\"data ErrNo =\\n\");\n\
\ printf(\"Edummy\\n\");\n\
\ for (i=1; i=max; i++) {\n\
\if (errs[i]) {\n\
\ printf(\" | %s\\n\",errs[i]);\n\
\} else if (jdup) {\n\
\ errs[i] = dups[j++];\n\
\ printf(\" | %s\\n\",errs[i]);\n\
\} else { noncontig=1; }\n\
\ }\n\
\ for (;jdup;j++) {\n\
\ errs[++max] = dups[j];\n\
\ printf(\" | %s\\n\",errs[max]);\n\
\ }\n\
\ if (noncontig) {\n\
\printf(\" deriving (Eq,Show)\\n\\n\");\n\
\printf(\"instance Enum ErrNo where\\n\");\n\
\for (i=1; i=max; i++) {\n\
\ if (errs[i])\n\
\printf(\" toEnum %d = %s\\n\",i,errs[i]);\n\
\}\n\
\printf(\" toEnum _ = Edummy\\n\");\n\
\for (i=1; i=max; i++) {\n\
\ if (errs[i])\n\
\printf(\" fromEnum %s = %d\\n\",errs[i],i);\n\
\}\n\
\printf(\"\\n\");\n\
\ } else printf(\" deriving (Eq,Enum,Show)\\n\\n\");\n\
\ printf(\"eqErrNo :: ErrNo - ErrNo - Bool\\n\");\n\
\ for (j=0;jdup;j++) {\n\
\printf(\"eqErrNo %s %s = True\\n\",dups[j],errs[dupi[j]]);\n\
\printf(\"eqErrNo %s %s = True\\n\",errs[dupi[j]],dups[j]);\n\
\ }\n\
\ printf(\"eqErrNo a b = a==b\\n\\n\");\n\
\ exit(0);\n\
\}\n"
possibleErrNos =
-- beginning of linux symbols
[ "EPERM"
, "ENOENT"
, "ESRCH"
, "EINTR"
, "EIO"
, "ENXIO"
, "E2BIG"
, "ENOEXEC"
, "EBADF"
, "ECHILD"
, "EAGAIN"
, "ENOMEM"
, "EACCES"
, "EFAULT"
, "ENOTBLK"
, "EBUSY"
, "EEXIST"
, "EXDEV"
, "ENODEV"
, "ENOTDIR"
, "EISDIR"
, "EINVAL"
, "ENFILE"
, "EMFILE"
, "ENOTTY"
, "ETXTBSY"
, "EFBIG"
, "ENOSPC"
, "ESPIPE"
, "EROFS"
, "EMLINK"
, "EPIPE"
, "EDOM"
, "ERANGE"
, "EDEADLK"
, "ENAMETOOLONG"
, "ENOLCK"
, "ENOSYS"
, "ENOTEMPTY"
, "ELOOP"
, "EWOULDBLOCK"
, "ENOMSG"
, "EIDRM"
, "ECHRNG"
, "EL2NSYNC"
, "EL3HLT"
, "EL3RST"
, "ELNRNG"
, "EUNATCH"
, "ENOCSI"
, "EL2HLT"
, "EBADE"
, "EBADR"
, "EXFULL"
, "ENOANO"
, "EBADRQC"
, "EBADSLT"
, "EDEADLOCK"
, "EBFONT"
, "ENOSTR"
, "ENODATA"
, "ETIME"
, "ENOSR"
, "ENONET"
, "ENOPKG"
, "EREMOTE"
, "ENOLINK"
, "EADV"
, "ESRMNT"
, "ECOMM"
, "EPROTO"
, "EMULTIHOP"
, "EDOTDOT"
, "EBADMSG"
, "EOVERFLOW"
, "ENOTUNIQ"
, "EBADFD"
, "EREMCHG"
, "ELIBACC"
, "ELIBBAD"
, "ELIBSCN"
, "ELIBMAX"
, "ELIBEXEC"
, "EILSEQ"
, "ERESTART"
, "ESTRPIPE"
, "EUSERS"
, "ENOTSOCK"
, "EDESTADDRREQ"
, "EMSGSIZE"
, "EPROTOTYPE"
, "ENOPROTOOPT"
, "EPROTONOSUPPORT"
, "ESOCKTNOSUPPORT"
, "EOPNOTSUPP"
, "EPFNOSUPPORT"
, "EAFNOSUPPORT"
RE: Documentation of MVars
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
bug reports
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, which needs some fiddling around in the parser to get working. - Alastair Reid's "strange selectee". Alastair: could you send us the code and some instructions on how to reproduce it? (or anyone else for that matter). - Eelco Dolstra's Time bug. I don't think any of us has the expertise or inclination to examine it in any detail, so it'll probably get committed by default :) - Sigbjorn's foreign export report. I haven't looked at this yet. Have I forgotten anyone? Cheers, Simon
Re: litlits in interface files
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 A_CONSTANT;
}
Granted, but this still doesn't bring you back that single nice
machine instruction it would be in the case of litlits. OK, OK,
this is an O(1) optimization and going via C is bad, but sometimes
it's more efficient to be a bad boy... ;-)
A tool could be helpful in massive generating such functions...
And if you need a tool (which I desperately would), it can produce
the constants right away, without any foreign import. Hmmm, how
does this fit with Green Card? And the tool would seem conspicuously
like a cut-down version of Manuel's C-HS.
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
