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
> int aConstant (void)
> {
> return A_C
Fri, 25 Feb 2000 13:10:24 +0100, Sven Panne <[EMAIL PROTECTED]>
pisze:
> 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 Hask
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, wh
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
> 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. Aaaar
> But testing this showed another strange phenomenon: The heap grows
> infinitely. :-( A cut-down version, which has the same effect:
>
>
> import Addr
> import Foreign
>
> main:: IO ()
> main = do
>fo <- mkForeignObj nullAd
> The following program causes SIGSEGV after a few thousands of
> iterations.
>
> I compile with 'ghc test2.hs -o test2 -fglasgow-exts' by ghc-4.06 on
> Linux, gcc-2.95.1, glibc-2.1.2. With ghc-4.04 it crashes too.
>
> --
> --
>
> The Long Version(TM):
> re DocBook:
> Firstly, I have to admit, I did not completely discover how
> and why DocBook
> handles things like it does, but hardcoded paths are always evil.
>
> I have a file /etc/sgml.catalog on my system which handles the mapping
> DTD<->filename, so I replaced the
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: [.
> 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 s
> What is the matter with
>
> main =
> let xs =
>[((1,[0,0,0,0,2,0,0,0,0,2]),(-5,[0,0,0,0,1,0,3,3,0,1])),
> ((1,[0,1,0,0,0,1,0,0,0,1]),(-5,[0,1,0,0,0,1,0,0,0,1])),
> ((1,[0,1,0,0,1,0,0,0,0,2]),(-3,[0,1,0,0,1,0,0,-2,4,0])),
> ((1,[0,1,0,0,1,0,1,0,
> | 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:
> Hello lovely GHC people. I may have found a bug.
>
> If I leave a hanging right brace where one might have been for a 'let'
> expression, eg:
>
> let env' = extendVarEnvList rho env }
>
> I then receive the message:
>
> panic! (the `impossible' happened):
> Lex.popContext: empty co
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 ab
> 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
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
Sven writes:
> GHC-4.06 includes litlits (i.e. those thingies between ``...''') in
> interface files when the corresponding module is compiled with -O
> and sometimes inlines them in other modules. Efficient as it is,
> this can break modules which don't use the same #includes.
I think the only
> ==fptools== gmake all --no-print-directory -r;
> in /usr/local/pub-bkb/ghc/fptools/hslibs/lang
> --
> --
> rm -f Weak.o ; if [ ! -d Weak ]; then mkdir Weak; else find
> Weak -name '*.o' -print | xargs rm -f __rm_food ; fi ;
> The following hack forces the warnings to be silent.
>
> --- /ghc/bin/ghc-4.04~ Mon Jan 17 14:49:50 2000
> +++ /ghc/bin/ghc-4.04 Mon Feb 7 11:12:13 2000
> @@ -1144,7 +1144,9 @@
> # unshift(@Ld_flags, ('-Xlinker -bbigtoc -Xlinker -bnoquiet'));
> unshift(@Ld_flags, ('-Xlinker -
Hi George,
> Can whoever managed to build ghc-4.06 for a Sparc please tell
> me exactly what
> versions of gcc, ar and ld they are using please?
>
> I am using gcc 2.95.2 with -m32 option.
> as: WorkShop Compilers 5.0 Alpha 03/27/98 Build
> ld: Software Generation Utilities - Solaris/ELF (3.0
20 matches
Mail list logo
