- Glasgow-haskell-users

09 Nov '09

I am (in fact we are) working to make Haskell code to run on an ARM Linux machine called GP2X Wiz, the open-source based handheld game console. I wish to finally make a Haskell cross-compiler for ARM Linux, and for now I am trying to make main = putStrLn "Hello, World!" to run on the machine. At first I did $ ghc hello.hs -o hello -fvia-C -keep-hc-files and tried to use the generated hc file, but figured that the code is (or at least some code in the included headers is) x86-dependent. I heard that the GHC can compile to ANSI C, and I want to use it as an intermediate code to ARM Linux before we can actually port the GHC to it. Is there any specific option I have to give in order to generate an ANSI C code from a Haskell source code?

7 6

Re: Compiling to ANSI C
by scooter.phd＠gmail.com 07 Nov '09

07 Nov '09

Believe it when it shows up in GHC pristine. ------Original Message------ From: Thomas DuBuisson To: scooter.phd(a)gmail.com Cc: han Cc: glasgow-haskell-users(a)haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 11:28 On Sat, Nov 7, 2009 at 11:16 AM, <scooter.phd(a)gmail.com> wrote: > Do we have a native LLVM bitcode writer or is it still FFI? I was referring to a paper [1] I just ran into on reddit. I only skimmed it, but it seems they (or just he?) integrated LLVM as a new backend for GHC. Thomas [1] http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf Sent from my Verizon Wireless BlackBerry

1 0

Re: Compiling to ANSI C
by scooter.phd＠gmail.com 07 Nov '09

07 Nov '09

Do we have a native LLVM bitcode writer or is it still FFI? ------Original Message------ From: Thomas DuBuisson Sender: glasgow-haskell-users-bounces(a)haskell.org To: han Cc: glasgow-haskell-users(a)haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 09:56 If I were you, I'd look at using the recent LLVM backend work as a means to translate Haskell -> ARM. Thomas On Sat, Nov 7, 2009 at 9:08 AM, han <e(a)xtendo.org> wrote: > I am (in fact we are) working to make Haskell code to run on an ARM > Linux machine called GP2X Wiz, the open-source based handheld game > console. > > I wish to finally make a Haskell cross-compiler for ARM Linux, and for > now I am trying to make > > main = putStrLn "Hello, World!" > > to run on the machine. At first I did > > $ ghc hello.hs -o hello -fvia-C -keep-hc-files > > and tried to use the generated hc file, but figured that the code is > (or at least some code in the included headers is) x86-dependent. > > I heard that the GHC can compile to ANSI C, and I want to use it as an > intermediate code to ARM Linux before we can actually port the GHC to > it. > > Is there any specific option I have to give in order to generate an > ANSI C code from a Haskell source code? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry

2 1

ANNOUNCE: GHC 6.12.1 Release Candidate 1
by Ian Lynagh 07 Nov '09

07 Nov '09

Hi all, We are pleased to (finally!) announce the first release candidate for GHC 6.12.1: http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ As well as the source tarball: ghc-6.12.0.20091010-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

17 36

6.12.1 Release Candidate: profiling and libHSffi_p.a
by Neil Brown 07 Nov '09

07 Nov '09

Hi, I tried profiling a program with the GHC 6.12 release candidate. I got this: $ ghc -O1 -prof -auto-all --make CommsTime.hs [1 of 1] Compiling Main ( CommsTime.hs, CommsTime.o ) Linking CommsTime ... /usr/bin/ld: cannot find -lHSffi_p collect2: ld returned 1 exit status Googling turned up this link, which suggests this problem was fixed earlier this year: http://www.mail-archive.com/cvs-ghc@haskell.org/msg13546.html However: $ find ~ -iname "libHSffi*" /home/nccb2/lib/ghc-6.12.0.20091010/libHSffi.a /home/nccb2/lib/ghc-6.12.0.20091010/libHSffi-ghc6.12.0.20091010.so /home/nccb2/ghc-6.11.20090915/libffi/libHSffi.a /home/nccb2/ghc-6.11.20090915/libffi/libHSffi-ghc6.11.20090915.so /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi-ghc6.12.0.20091010.so /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi.a /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi_p.a This seems to indicate that the library is built (/home/nccb2/ghc-6.12.0.20091010 is where I built GHC) but not installed on my system. This is a Debian 32-bit system, and I don't remember passing any options to the GHC configure command besides --prefix. Neil.

2 1

Reliably preventing let-floating and thunk overwriting?
by Bryan O'Sullivan 06 Nov '09

06 Nov '09

The criterion benchmarking package is pretty nice to use in general, but it has a property that sticks in my craw: ensuring that pure code actually gets evaluated on every iteration through the benchmarking loop is awkward and fragile. My current scheme is to increment an Int on every iteration and pass that to the function being benchmarked. I document the need for the function to somehow use this Int, lest it be let-floated out to the top level, where it will be evaluated just once and our measurements will become nonsensical. I wonder if anyone else has any clever ideas about approaches that might be less intrusive in the API.

2 2

NDP
by Luca Ciciriello 06 Nov '09

06 Nov '09

Hi All. Has someone heard something about "Nested Data Parallelism" in Haskell? Does exists some paper that I can read about this technology? Thanks in advance. Luca. _________________________________________________________________ New Windows 7: Find the right PC for you. Learn more. http://www.microsoft.com/uk/windows/buy/

2 2

inferred type doesn't type-check (using type families)
by Roland Zumkeller 04 Nov '09

04 Nov '09

Hi, Compiling > class WithT a where > type T a > f :: T a -> a -> T a > f = undefined > g x = f x 42 with -XTypeFamilies -fwarn-missing-signatures gives: Inferred type: g :: forall a. (Num a) => T a -> T a Adding > g :: Num a => T a -> T a results in: Couldn't match expected type `T a' against inferred type `T a1' In the first argument of `f', namely `x' Is the inferred type not the right one? Is g typeable? Best, Roland -- http://alacave.net/~roland/

5 4

How to know data size in UDP?
by Kazu Yamamoto 04 Nov '09

04 Nov '09

Hello, I'm trying to implement DNS resolver without any external C libraries for my daemon program which uses DNS lookup. I know the "hsdns" library exists. But since it calls GNU asynchronous DNS resolver library by FFI, all threads of Haskell are blocked on non-threaded RTS. If the threaded RTS is used, forkProcess kills the IO thread. With the threaded RTS of at least GHC 6.10.4, we cannot make our program as a daemon nor use pre-fork mechanism. Thus, I decided to implement DNS resolver only with non-blocking Haskell functions. I use a *connected* UDP socket like this: proto <- getProtocolNumber "udp" let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_NUMERICHOST, AI_PASSIVE] , addrSocketType = Datagram , addrProtocol = proto } a:_ <- getAddrInfo (Just hints) (Just "An IP address of DNS server") (Just "domain") sock <- socket (addrFamily a) (addrSocketType a) (addrProtocol a) connect sock (addrAddress a) h <- socketToHandle sock ReadWriteMode hSetBuffering h NoBuffering hSetBinaryMode h True If my understating is correct, I cannot use recvFrom since it calls recvfrom() with FFI. So, I use socketToHandle to translate a socket to a handle. Since the handle is associated with UDP, the entire data size should be known when a UDP packet arrived. But I cannot find a way to know data size. (I want a function like hFileSize.) Note that hGetContents blocks. Without data size in advance, a program to handle network protocols on UDP becomes quite dirty or sometime cannot be implemented. So, please tell me how to know data size associated with a handler of UDP? --Kazu

2 2

Assembler errors when compiling nofib benchmarks with -optc-g
by Henry DeYoung 03 Nov '09

03 Nov '09

Hi, I am working with another grad student on a course project on cache behavior of GHC programs. The first part of this project is to reproduce some of the measurements from Nethercote and Mycroft's "The Cache Behavior of Large Lazy Functional Programs on Stock Hardware". We've decided to use oprofile to sample cache misses recorded by the performance counters. To get reasonable information out of oprofile, I'd like to compile the nofib benchmarks via C with export of debugging symbols. As a first step toward this, I've changed the NoFibHcOpts variable in nofib/mk/boilerplate.mk to be: NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g However, when I do make in the nofib/real/compress directory, for example, I get the following error message: ==nofib== compress: time to compile BinConv follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinCon v.hs -o BinConv.o <<ghc: 83082120 bytes, 8 GCs, 5163477/9786528 avg/max bytes residency (3 samples), 33M in use, 0.00 INIT (0.00 elapsed), 0.14 MUT (1.25 elapsed), 0.10 GC (0.12 elapsed) :ghc>> 1.27user 0.12system 0:01.39elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+21251minor)pagefaults 0swaps ==nofib== compress: size of BinConv.o follows... text data bss dec hex filename 6677 192 8 6877 1add BinConv.o ==nofib== compress: time to compile BinTest follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinTes t.hs -o BinTest.o /tmp/ghc14909_0/ghc14909_0.s: Assembler messages: /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: junk at end of line, first unrecognized character is `0' etc... Curiously, if I remove the -optc-g flag, but still use -fvia-C and -pgmc gcc, everything works fine. Do you have any ideas what might be causing these errors? Is there a fix or workaround to get the C compiler to export debugging symbols? Second, it appears that a make with -fvia-C -pgmc gcc removes the C source after it has been compiled. Is there a way to preserve this source so that it can be annotated line by line using oprofile? I apologize if these questions are rudimentary; this is my first experience with GHC and nofib. Also, if these questions should be directed toward a different mailing list, please let me know. Thanks for any help you can give with this! Henry

3 4