glasgow-user

How to use #ifdef WIN32

Fri, 12/21/2007 - 12:37am
I want to switch code on the OS but this always goes through to the #else (on windows or elsewhere): {-# OPTIONS -cpp #-} #ifdef WIN32 main = putStrLn "hello windows" #else main = putStrLn "hello something else" #endif Does this depend on a Makefile setting WIN32, or should there be something predefined? Thanks,
Categories: Offsite Discussion

How do you get the process id out of the ProcessHandle in Win XP?

Thu, 12/20/2007 - 2:59am
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

Building GHC 6.6.1 on Leopard/PPC

Wed, 12/19/2007 - 10:25pm
I've been trying to get a working GHC 6.6.1 build on my Leopard box with little success. I am trying to follow the "Booting/porting from C (.hc) files" instructions here: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting When I build the HC file bundle, I get errors about rts/AutoApply_* stuff, but I've read that they are not necessary fatal. When I try to build on the target system after unpacking the HC files ('distrib/hc-build --prefix='), I get the following error: ------------------------------------------------------------------------ == make boot -f Makefile; in /Users/jjc/Downloads/ghc-6.6.1/libraries/readline ------------------------------------------------------------------------ make[1]: *** No rule to make target `System/Console/Readline_hsc.c', needed by `depend'. Stop. Failed making boot in readline: 1 make: *** [boot] Error 1 Any help is much appreciated. Not only would I like to get this building for myself, but I would also like to contribute a bootstrap build for oth
Categories: Offsite Discussion

binary-dists for ghc-6.8.2

Tue, 12/18/2007 - 7:44pm
Dear all, I've built binary distributions for Mac OS 10.4 (Tiger) based on (better supported) GMP and GNUreadline frameworks and for Solaris 10. http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2 http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 The frameworks under http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm should do. The Mac binaries have been built using gcc version 4.0.1 (Apple Computer, Inc. build 5367) and a patched Linker.lhs from http://hackage.haskell.org/trac/ghc/ticket/1798 (also the files compiler/main/DriverPipeline.hs and utils/hsc2hs/Main.hs are patched according to http://hackage.haskell.org/trac/ghc/ticket/1395) The PPC binary still features: http://hackage.haskell.org/trac/ghc/ticket/1845 The PPC ghc can be used on Intel Macs with the additional options: -optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc (but that's slower than an i386 binary). The Intel-Mac binary has also a patched file rts/Excep
Categories: Offsite Discussion

Foreign C with pointers

Tue, 12/18/2007 - 6:54pm
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

Haddock won't build on 6.8.1

Mon, 12/17/2007 - 10:27pm
I see this: $ runhaskell ./Setup.lhs build Preprocessing executables for haddock-0.8... shift/reduce conflicts: 5 Building haddock-0.8... src/Main.hs:49:7: Could not find module `System.Directory': it is a member of package directory-1.0.0.0, which is hidden Any ideas? Thanks, Deborah
Categories: Offsite Discussion

Performance bug maybe

Mon, 12/17/2007 - 8:54pm
Hi, I think I found a performance bug. Either that, or something is going on that I don't understand. I've attached an example program. Here's my session with it: =============== ghc --make -O2 MaybeBug.hs; time ./MaybeBug +RTS -tstderr [1 of 1] Compiling Main ( MaybeBug.hs, MaybeBug.o ) Linking MaybeBug ... ./MaybeBug +RTS -tstderr -1452071552 191905792 < real0m4.408s user0m3.960s sys0m0.448s ghc --make -O2 MaybeBug.hs -DSLOW -no-recomp; time ./MaybeBug +RTS -tstderr [1 of 1] Compiling Main ( MaybeBug.hs, MaybeBug.o ) Linking MaybeBug ... ./MaybeBug +RTS -tstderr -1452071552 191905792 < real0m10.717s user0m9.761s sys0m0
Categories: Offsite Discussion

Type Relations

Mon, 12/17/2007 - 7:32pm
Hello all, I've came across a problem which would be best implemented if I could define what I think to be a Type Relation. Let's consider classes as being type properties. When you say: class Num a where (+) :: a -> a -> a ... it defines a property of the type a. Basically all types a of class Num are addable, etc.. However, how can I (if I can) represent the fact that you can coerce a type a to a type b? A particular example of that is the fromInteger function from Num class where you say that if your type a is of class Num, you must be able to coerce an Int to a. I would like to define a relation between types and then say that two types are in the relation if they define the coerce function. Something I imagine would be: typerelation Coercible a b where coerce :: a -> b And then you would define instances of Coercible if you could define the function coerce between the types. You could then define function only over types which can be coerced from one to the other. Any suggestions on how t
Categories: Offsite Discussion

GADT pattern match in non-rigid context

Mon, 12/17/2007 - 4:23pm
Hi, Upgrading from GHC 6.6 to 6.8 has caused some code to stop working: ---------------------------------------------------------------------- {-# OPTIONS_GHC -fglasgow-exts #-} module Data2 where data CCompany data Paradise :: * -> * where CC :: Paradise CCompany rewrapCC CC = [] ---------------------------------------------------------------------- [1 of 1] Compiling Data2 ( Data2.hs, interpreted ) Data2.hs:12:9: GADT pattern match in non-rigid context for `CC' Tell GHC HQ if you'd like this to unify the context In the pattern: CC In the definition of `rewrapCC': rewrapCC CC = [] This code is from the Uniplate benchmarking code, which runs the Paradise benchmark from SYB on Uniplate, Compos and SYB. The Compos code uses GADT's, so the program first needs to convert from standard data structures to GADT's before it can work, then back at the end. It's the problem of converting from a GADT to a normal data structure that is failing. So is there an easy workaround? O
Categories: Offsite Discussion

ForeignPtr performance

Sun, 12/16/2007 - 8:57pm
Hi, I do a lot of programming with small compound objects, things like 3d vectors or RGBA tuples for images. For performance reasons, I keep them in StorableArrays, since there is no way to use these things with UArrays. (But that's a topic for another thread.) Some how the notion got into my head that StorableArrays were slow, I think from old versions of GHC. So I've gotten into the habit of using withStorableArray and peek/poke to work on my arrays. This, as you can imagine, is cumbersome. Not only because of the extra typing, but also because I have to do everything in the IO monad, even if the array is read-only. So I'm thinking about writing my own IArray instance using ForeignPtr for storage and unsafePerformIO for access. I did a little experiment, comparing to And there seemed to be no difference in running time, which is great. So I'm thinking of making unsafeAt something like My question is: what exactly does GHC.Prim.touch# do? This appears to be the critical function of withForeignPtr,
Categories: Offsite Discussion

mingw64

Fri, 12/14/2007 - 4:09pm
Hello Glasgow-haskell-users, are you know about http://sourceforge.net/projects/mingw-w64 ? this project was started just a few months ago, but it already provides downloads to test. the win64 support is very important for my project so please look at it
Categories: Offsite Discussion

Hugs faster than GHC

Fri, 12/14/2007 - 12:59pm
The following program reveals a performance bug in ghc 6.6 module HCBenchmark where type M1 a = () type M2 a = M1 a type M3 a = M2 a type M4 a = M3 a type M5 a = M4 a type M a = M4 a -- use M5 for 10 times the compile time and M3 for 1/10 f :: M (M (M (M (M (M (M (M (M (M x))))))))) f = () Each element you add in the chain of type synonyms adds a factor of ten to the compile time. Hugs is "a bit" faster :o) Trouble is, the module I wanted to compile originally, takes an estimated 6 thousand and 600 hours to compile and I am not sure that this bug is the only obstacle for the compiler ... Could anyone cope if that is still a problem with the newest instance of ghc? Thanks a lot Bernd
Categories: Offsite Discussion

where's the best place to post those really irratating noddyquestions that people who are learning Haskell ask.....

Fri, 12/14/2007 - 10:37am
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

upgrading visual studio integration to use 6.8.2....

Thu, 12/13/2007 - 3:28pm
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

Portage slots for GHC?

Thu, 12/13/2007 - 9:25am
Hi, I'm using GHC on Gentoo, and so far I've had to stay clear of GHC 6.6, because I've also installed stuff depending on 6.4.2, like wxHaskell, for instance. Now I see a new version of mtl, which I also have installed, depends on 6.6.1, while all of the rest of the stuff is "lagging behind" with a dependency on 6.4.2. Of course, I can easily solve the problem partially by masking out the new version for mtl, but this is going to become a major inconvenience with new versions of GHC and its dependents. What I'm getting at is, can we please have separate slots for GHC 6.4.2 and 6.6 on portage? Cheers, Dinko
Categories: Offsite Discussion

Readline for Windows in the FAQ

Wed, 12/12/2007 - 8:27pm
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

ANNOUNCE: GHC version 6.8.2

Wed, 12/12/2007 - 6:44pm
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agr
Categories: Offsite Discussion

newtypes and optimization

Wed, 12/12/2007 - 6:02pm
Hi, I have a statically-sized-list library that I use for linear algebra stuff. It's got a vector type something like this: so that a 3D vector is and I have type classes for operations on these things, like so: so that vector addition is I put strictness annotations and INLINE pragmas all over the place, and GHC does wonders with it. Using Storable instances something like the following, GHC can turn a loop like this, into something as fast as C, using no heap. You look at the core and its nothing but readDoubleOffAddr#, +## and the like. I went so far as to generalize this to matrices with things like vector-matrix and matrix-matrix multiplication, determinants and all that and, when used in loops like above, it's consistently as fast or even faster than C. However when I do this: Everything is ruined. Functions like peek and vadd are no longer inlined, intermediate linked lists are created all over the place. The Quaternion Storable instance looks like this with strictness annotations a
Categories: Offsite Discussion

Installing on Leopard

Tue, 12/11/2007 - 12:22pm
I have some problems installing 6.8.1 on Mac OS X Leopard. First I installed readline using ports: $ sudo port install readline Then GHC $ ./configure --prefix=$HOME && make install make -C rts install DOING_BIN_DIST=YES cc -E -undef -traditional -P -DINSTALLING \ -DIMPORT_DIR='"/Users/tibell/lib/ghc-6.8.1/imports"' \ -DLIB_DIR='"/Users/tibell/lib/ghc-6.8.1"' \ -DINCLUDE_DIR='"/Users/tibell/lib/ghc-6.8.1/include"' \ -DDATA_DIR='"/Users/tibell/share/ghc-6.8.1"' \ -DHTML_DIR='"/Users/tibell/share/ghc-6.8.1/html/libraries/rts"' \ -DHADDOCK_IFACE='"/Users/tibell/share/ghc-6.8.1/html/libraries/rts/rts.haddock"' \ -I../includes \ -x c -DGMP_INCLUDE_DIRS='' -DGMP_LIB_DIRS='' -I -Iinclude -DPACKAGE=rts -DVERSION= -DPKG_LIBDIR='"/Users/tibell/lib/ghc-6.8.1"' -DPKG_DATADIR='"/Users/tibell/share/ghc-6.8.1"' package.conf.in \ | grep -v '^#pragma GCC' \ | sed
Categories: Offsite Discussion

New woes regarding ghc-6.8.1 on FreeBSD-amd64

Tue, 12/11/2007 - 11:56am
Some days ago I announced having success in porting ghc-6.8.1 to FreeBSD-7.0-amd64. As the compiler seemed to be able to compile itself, I was confident to make the binary package available to the public. Now I have found out that the port is rooten in a very weird way. 669 unexpected failures. Among the most unexpected of these is the failure of arith003 (conversions between Int and Integer near 64bit boundary). It seems there is still some 32/64-bit confusion left from the building process. Still worse is, that any attempt to use the partially usable compiler as bootstrap tool fails for some reasons. On a freshly configure 6.8.1 tree (with ./configure --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib ) the build process fails at libraries/base/Control/Concurrent.hs because gmp.h is not found by ghc-inplace I fixed this by copying /usr/local/include/gmp.h to ghc-6.8.1/includes. This is, of course, a risk of confusing the 32/64bit version of this library. Anyway, the resulting c
Categories: Offsite Discussion