June 2002 - Glasgow-haskell-users

RE: problems with FFI including h files
by Simon Marlow 05 Jun '02

05 Jun '02

> > 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. Yes - but read the text I quoted before my message. I'm not talking about calling the function, I'm talking about generating C prototypes. You suggested that the Haskell compiler could generate prototypes and the C compiler could be used to check for mismatches, which would be great if it were possible, but sadly it's not. The Haskell compiler can't generate a C prototype that can be used to check for compatibility with any other C prototypes in scope, because the Haskell FFI declaration doesn't contain all the necessary information. It has just enough information to be able to call the function, nothing more. The FFI *is* restricted to invoking functions, not macros (consider GHC's native code generator, for example). However, when compiling via C, we have to rely on prototypes being in scope from external header files, because of the above problem. (look in the FFI mailing list archives, BTW - these issues were discussed at length a while back). Cheers, Simon

2 1

RE: problems with FFI including h files
by Simon Marlow 05 Jun '02

05 Jun '02

> 2) Restrict ffi to invoking functions not macros. > > In this case, GHC generates function prototypes itself > based on the > Haskell type and ignores the header files. > > If you want to detect mismatches between function > prototypes in the C > header file and the GHC-generated prototypes, you could > generate a C > file like this: > > #include <ffi_specified_headers.h> > #include <ghc_generated_prototypes.h> > > GHC_type_for_f *f_pointer = &f; > > and you'll get told of many mismatches. 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?). > This is roughly how the Hugs FFI header file will look once my current > hacking on it is finished. The current header file contains little > more than the final struct and a few typedefs. Looks good. Simon

2 1

SuSE 8.0 packages
by Ralf Hinze 04 Jun '02

04 Jun '02

You can find GHC packages (version 5.03.20020410) for SuSE's latest distribution here: http://www.informatik.uni-bonn.de/~ralf/ghc-5.03.20020410-1.i386.rpm http://www.informatik.uni-bonn.de/~ralf/ghc-prof-5.03.20020410-1.i386.rpm http://www.informatik.uni-bonn.de/~ralf/ghc-5.03.20020410-1.src.rpm Have fun, Ralf

1 0

RE: Replacing the Prelude
by Ashley Yakeley 04 Jun '02

04 Jun '02

Ping! At 2002-05-14 07:17, Simon Peyton-Jones wrote: >Ashley writes > >| > I was hoping to do something similar for 'do' notation by redefining >| > (>>), (>>=) etc., but unfortunately GHC is quite insistent >| that 'do' notation quite specifically refers to GHC.Base.Monad > >Dylan replies > >| I'm surprised that ghc uses the fromInteger and fromRational >| that are in scope; I thought there was general agreement that >| it should use the Prelude.from{Integer,Rational} in scope. > >Ashley is referring to a GHC extension. Normally, GHC uses >Prelude.fromInteger etc, regardless of what is in scope. But if you >say -fno-implicit-prelude, GHC will instead use whatver fromInteger >is in scope. (This is documented in the manual.) > >Ashley's question, as I understand is whether something similar >could be done for monads. > >Answer: I think so, without much bother. I'm beavering away on >a Haskell workshop paper at the moment, but ping me in a fortnight >to do it. > >Simon >_______________________________________________ >Glasgow-haskell-users mailing list >Glasgow-haskell-users(a)haskell.org >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

RE: problems with FFI including h files
by Simon Marlow 03 Jun '02

03 Jun '02

> Sad, but very true! And GHC's headers are not very nice in > this respect: > > panne@jeanluc:~> grep '#define [^ \t][^ \t] ' > /usr/lib/ghc-5.03/include/* > /usr/lib/ghc-5.03/include/PrimOps.h:#define C 0 > /usr/lib/ghc-5.03/include/PrimOps.h:#define R 1 > /usr/lib/ghc-5.03/include/PrimOps.h:#define C 1 > /usr/lib/ghc-5.03/include/PrimOps.h:#define R 0 Yikes! Fixed, thanks. > panne@jeanluc:~> grep '#define [^ \t][^ \t] ' > /usr/lib/ghc-5.03/include/* > /usr/lib/ghc-5.03/include/Regs.h:#define R1 (BaseReg->rR1) > /usr/lib/ghc-5.03/include/Regs.h:#define R2 (BaseReg->rR2) > /usr/lib/ghc-5.03/include/Regs.h:#define F1 (BaseReg->rF1) > /usr/lib/ghc-5.03/include/Regs.h:#define F2 (BaseReg->rF2) > /usr/lib/ghc-5.03/include/Regs.h:#define F3 (BaseReg->rF3) > /usr/lib/ghc-5.03/include/Regs.h:#define F4 (BaseReg->rF4) > /usr/lib/ghc-5.03/include/Regs.h:#define D1 (BaseReg->rD1) > /usr/lib/ghc-5.03/include/Regs.h:#define D2 (BaseReg->rD2) > /usr/lib/ghc-5.03/include/Regs.h:#define L1 (BaseReg->rL1) > /usr/lib/ghc-5.03/include/Regs.h:#define Sp (BaseReg->rSp) > /usr/lib/ghc-5.03/include/Regs.h:#define Su (BaseReg->rSu) > /usr/lib/ghc-5.03/include/Regs.h:#define Hp (BaseReg->rHp) > > And so on... > > SimonM: What about a "poor man's" namespace, i.e. prefixing > every macro, > type, etc. with "GHC"/"ghc"? OpenGL, GLUT, GTK, etc. do a > similar thing, > and although it's a primitive measure, it's very effective. We really *should* do this, I know. The problem is that it isn't free by a long shot: it'll make .hc files significantly larger, and obfuscate a lot of code. Anyone have any ideas that don't have such a big impact? Cheers, Simon

3 2

RE: monomorphism/hugs98/ghc-5.02.3
by Simon Marlow 03 Jun '02

03 Jun '02

> However, in ghc-5.02.3 for Haskell 98 (without glasgow extensions) it > seems that is not the case. I _guessed_ that I need to use the flag > -fno-monomorphism-restriction > but I don't know whether I've failed to turn it on or if the > problem is to be found somewhere else. A related problem I've found > is that if I try to specify that flag in a pragma, I get an error > message stating that static flags may not be specified in pragmas, > and yet the flag is supposed to be dynamic. -fno-monomorphism-restriction was a static flag by mistake. The bugfix will be in 5.04. Cheers, Simon

1 0

Efficient UArray dot-product?
by Mike Gunter 03 Jun '02

03 Jun '02

Is it possible to write an dot-product function that GHC will compile to efficient code without using unsafeAt? I've tried and can't. I'm looking at generic IArray functions pragma-specialized to UArray Int Double. With unsafeAt the -ddump-simpl output looks optimal to me (aside from not unrolling or pipelining**): loop i s | i > ubSI = s | otherwise = let s' = s + (small `unsafeAt` i) * (big `unsafeAt` (off + i)) in seq s' $ loop (i + 1) s' compiles to $wloop = \ ww12 L :: PrelGHC.Int# ww13 L :: PrelGHC.Double# -> case PrelGHC.># ww12 ww9 of wild3 L { PrelBase.True -> PrelFloat.$wD# ww13; PrelBase.False -> $wloop (PrelGHC.+# ww12 1) (PrelGHC.+## ww13 (PrelGHC.*## (PrelGHC.indexDoubleArray# ww2 ww12) (PrelGHC.indexDoubleArray# ww6 (PrelGHC.+# a2 ww12)))) }; } in Without it (i.e. with (!)) the compiler will only use primitive arithmetic for addressing one of the arrays. Why? Is there a way to write dot-product that produces good code without resorting to unsafeAt? thanks, mike ** Pipelining probably isn't going to be worth your time in so far as you're targeting processors with dynamic scheduling. They'll pipeline things for you.

2 1

Dynamic types: GHCI works, GHC doesn't?
by Andre Pang 02 Jun '02

02 Jun '02

Hi all, I'm trying to get a grip on the Dynamic types stuff supplied with GHC, and I'm not sure if I'm doing something wrong, or whether I've found a bug. It seems that the fromDynamic and fromDyn functions seem to work if you load your module into GHCI, but they don't work when you compile it into a stand-alone executable with GHC. Here's an example of what the output is meant to be like: 22:51(0) .../project/dynamic_types-bug% ghci -package lang DynamicTypesBug.hs [ GHCI header deleted ] Loading package std ... linking ... done. Loading package lang ... linking ... done. Compiling Main ( DynamicTypesBug.hs, interpreted ) Ok, modules loaded: Main. Main> main Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? True Attempting to run fromDynamic on the dynamic type ... 5. This be the footnote Main> So, that all works fine. Compile it through GHC, however, and this happens: 22:57(0) .../project/dynamic_types-bug% ghc --make -package lang DynamicTypesBug.hs ghc-5.02.2: chasing modules from: DynamicTypesBug.hs Compiling Main ( DynamicTypesBug.hs, ./DynamicTypesBug.o ) ghc: linking ... 22:57(0) .../project/dynamic_types-bug% ./a.out Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? False Attempting to run fromDynamic on the dynamic type ... Fail: Maybe.fromJust: Nothing Furthermore, if you compile it with GHC, then run GHCI afterward, GHCI will use the Main.o object file rather than try to compile it again, and will fail: 22:58(1) .../project/dynamic_types-bug% ghci -package lang DynamicTypesBug.hs [ GHCI header deleted ] Loading package std ... linking ... done. Loading package lang ... linking ... done. Skipping Main ( DynamicTypesBug.hs, ./DynamicTypesBug.o ) Ok, modules loaded: Main. Main> main Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? False Attempting to run fromDynamic on the dynamic type ... *** Exception: Maybe.fromJust: Nothing Main> I've seen this behaviour with: * ghc-5.02.2 from the Debian ghc5 package * ghc-5.02.1 on another Linux machine (compiled from source) * ghc-5.03.20020204 snapshot on Windows (Sigbjorne's MSI package) It's possible that I'm not using the Dynamic module functions properly, since I don't think I understand them that well. In particular, I'm a bit confused as to how to construct a TypeRep with the mkAppTy function. See my code to see how I'm (mis)using it :). The code which exhibits this behaviour is attached to this message (DynamicTypesBug.hs). Hopefully I'm just doing something silly ... -- #ozone/algorithm <ozone(a)algorithm.com.au> - trust.in.love.to.save

4 4

Re: Dynamic types: GHCI works, GHC doesn't?
by Andre Pang 01 Jun '02

01 Jun '02

On Sat, Jun 01, 2002 at 11:01:57PM +1000, Andre Pang wrote: > It seems that the fromDynamic and fromDyn functions seem to work > if you load your module into GHCI, but they don't work when you > compile it into a stand-alone executable with GHC. .. unless you compile it with -O2: 23:18(0) .../project/dynamic_types-bug% ghc --make -package lang -O2 DynamicTypesBug.hs ghc-5.02.2: chasing modules from: DynamicTypesBug.hs Compiling Main ( DynamicTypesBug.hs, ./DynamicTypesBug.o ) ghc: linking ... 23:18(0) .../project/dynamic_types-bug% ./a.out Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? True Attempting to run fromDynamic on the dynamic type ... 5. This be the footnote Weird. It also seems to work with -O1. I should note that I observed the buggy GHC behaviour with -fvia-c as well, regardless of whether gcc-2.95 or gcc-3.1 was used. Putting -O0 on the GHC commandline, or omitting the -O option altogether, appears to trigger the bug. This doesn't happen with GHCI (i.e. 'ghci -O0' seems to work). -- #ozone/algorithm <andrep(a)cse.unsw.EDU.AU> - b.sc (comp. sci+psych)

1 0

problems with FFI including h files
by Hal Daume III 01 Jun '02

01 Jun '02

Hi all! I'm hoping someone with more FFI experience than me (pretty much anyone who's done anything with FFI) can help me out. Basically, I'm trying to include an h file and gcc is telling me that there are parse errors in it. However, when I write a c program that includes that h file, it don't get such errors. Here is an example C program: 12:52pm moussor:ATLAS/ cat TestAtlas.c #include "cblas.h" int main() { double x = cblas_ddot(0,0,0,0,0); } And, I can compile it: 1:39pm moussor:ATLAS/ /nfs/isd/hdaume/bin/gcc TestAtlas.c -B/nfs/isd/hdaume/download/ATLAS -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -llapack -lcblas -lf77blas -latlas 1:39pm moussor:ATLAS/ ./a.out 1:39pm moussor:ATLAS/ The h file I'm including, "cblas.h" is located in /nfs/isd/hdaume/download/ATLAS/include and all the libraries are the the specified lib directory (though those aren't really relevant at this point). Moving on to the haskell side of things, I have a module: 1:37pm moussor:~/projects/ cat HBlas/Level1GC2.hs {-# OPTIONS -#include "cblas.h" #-} -- run with: module HBlas.Level1GC2 where 1:41pm moussor:~/projects/ that contains no definitions (obviously my real one has definitions, but it makes no difference at this point). so, i try to compile with ghc using: ghco HBlas/Level1GC2.hs -cpp -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -llapack -lcblas -lf77blas -latlas -iHBlas -pgmc/nfs/isd/hdaume/bin/gcc -optc-B/nfs/isd/hdaume/download/ATLAS so, basically, i'm including the same -L and -B directives to gcc, using the same version of gcc (3.1), same libraries and everything but now it complains and says: Compiling HBlas.Level1GC2 ( HBlas/Level1GC2.hs, HBlas/Level1GC2.sun4.o ) In file included from /tmp/ghc3741.hc:7: /nfs/isd/hdaume/download/ATLAS/include/cblas.h:444: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:449: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:453: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:458: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:474: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:479: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:483: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:488: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:504: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:509: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:513: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:518: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:534: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:539: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:543: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:548: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:568: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:572: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:577: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:582: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:586: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:591: parse error before numeric constant if I look at cblas.h, line 444 is the last line of this definition: void cblas_sgemm(const enum CBLAS_ORDER Order, const enum CBLAS_TRANSPOSE TransA, const enum CBLAS_TRANSPOSE TransB, const int M, const int N, const int K, const float alpha, const float *A, const int lda, const float *B, const int ldb, const float beta, float *C, const int ldc); i really have *no* idea what's going on. if i compile the c and the haskell with -v, the lines leading up to the errors on the haskell side read: *** C Compiler /nfs/isd/hdaume/bin/gcc -x c /tmp/ghc3749.hc -o /tmp/ghc3749.raw_s -w -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=502 -B/nfs/isd/hdaume/download/ATLAS -ffloat-store -I . -I /nfs/isd/hdaume/lib/ghc-5.02.3/include Reading specs from /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs Configured with: /nfs/isd/hdaume/download/gcc-3.1/configure --prefix=/nfs/isd/hdaume --with-cpu=ultrasparc --enable-languages=c,c++,f77,java Thread model: posix gcc version 3.1 /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/cc1 -lang-c -v -I . -I /nfs/isd/hdaume/lib/ghc-5.02.3/include -isystem /nfs/isd/hdaume/download/ATLAS/include -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -D__GLASGOW_HASKELL__=502 /tmp/ghc3749.hc -quiet -dumpbase ghc3749.hc -O -Wimplicit -w -version -ffloat-store -o /tmp/ghc3749.raw_s GNU CPP version 3.1 (cpplib) (sparc ELF) GNU C version 3.1 (sparc-sun-solaris2.8) compiled by GNU C version 2.95.2 19991024 (release). ignoring nonexistent directory "/nfs/isd/hdaume/sparc-sun-solaris2.8/include" #include "..." search starts here: #include <...> search starts here: . /nfs/isd/hdaume/lib/ghc-5.02.3/include /nfs/isd/hdaume/download/ATLAS/include /usr/local/include /nfs/isd/hdaume/include /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/include /usr/include End of search list. In file included from /tmp/ghc3749.hc:7: /nfs/isd/hdaume/download/ATLAS/include/cblas.h:444: parse error before numeric constant and the entire transcript of just compiling the c program with gcc is: 1:41pm moussor:ATLAS/ /nfs/isd/hdaume/bin/gcc TestAtlas.c -B/nfs/isd/hdaume/download/ATLAS -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -llapack -lcblas -lf77blas -latlas -v Reading specs from /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs Configured with: /nfs/isd/hdaume/download/gcc-3.1/configure --prefix=/nfs/isd/hdaume --with-cpu=ultrasparc --enable-languages=c,c++,f77,java Thread model: posix gcc version 3.1 /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/cc1 -lang-c -v -isystem /nfs/isd/hdaume/download/ATLAS/include -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc TestAtlas.c -quiet -dumpbase TestAtlas.c -version -o /var/tmp//cc1I7kU6.s GNU CPP version 3.1 (cpplib) (sparc ELF) GNU C version 3.1 (sparc-sun-solaris2.8) compiled by GNU C version 2.95.2 19991024 (release). ignoring nonexistent directory "/nfs/isd/hdaume/sparc-sun-solaris2.8/include" #include "..." search starts here: #include <...> search starts here: /nfs/isd/hdaume/download/ATLAS/include /usr/local/include /nfs/isd/hdaume/include /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/include /usr/include End of search list. /usr/ccs/bin/as -V -Qy -s -xarch=v8plusa -o /var/tmp//cc1wEdD7.o /var/tmp//cc1I7kU6.s /usr/ccs/bin/as: Sun WorkShop 6 99/08/18 /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crt1.o /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crti.o /usr/ccs/lib/values-Xa.o /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crtbegin.o -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -L/nfs/isd/hdaume/download/ATLAS -L/nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -L/usr/ccs/bin -L/usr/ccs/lib -L/nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../.. /var/tmp//cc1wEdD7.o -llapack -lcblas -lf77blas -latlas -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crtend.o /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crtn.o ld: Software Generation Utilities - Solaris-ELF (4.0) so yeah, i'm completely at a loss here. i really don't know very much about gcc and why it would be doing this; i notice there are a few command line options passed to cc1 in the haskell version that don't exist on the c side. to make sure it wasn't a problem with the .hc extension, i renamed TestAtlas.c to TestAtlas.hc and compiled with "gcc -x c TestAtlas.hc ..." and the rest the same and it still works fine. please please please help :) thanks! - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

4 6