- Glasgow-haskell-users

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

array-0.2.0.0 doesn't build with 6.12rc1
by Ganesh Sittampalam 02 Nov '09

02 Nov '09

[ 6 of 10] Compiling Data.Array.IO ( Data/Array/IO.hs, dist/build/Data/Array/IO.o ) Data/Array/IO.hs:73:13: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:22: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:36: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:74:5: Not in scope: data constructor `Buffer' Data/Array/IO.hs:74:13: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:25: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:36: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:75:4: Not in scope: `bufferEmpty' Data/Array/IO.hs:82:24: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:82:35: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:86:24: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:95:27: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:101:10: Not in scope: `readRawBuffer' Data/Array/IO.hs:125:22: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:31: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:45: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:127:18: Not in scope: data constructor `Buffer' Data/Array/IO.hs:127:26: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:42: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:53: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:135:30: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:142:7: Not in scope: data constructor `Buffer' Data/Array/IO.hs:142:15: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:27: `bufState' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:36: Not in scope: data constructor `WriteBuffer' Data/Array/IO.hs:143:8: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:19: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:34: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:151:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:151:43: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:35: Not in scope: type constructor or class `RawBuffer'

5 5

6.12.1 release
by Simon Marlow 02 Nov '09

02 Nov '09

The current dilemma we're facing with the 6.12.1 release is this: cabal-install still needs to be ported to the new version of Cabal, Duncan is snowed under and doesn't have time to work on it, but without cabal-install people can't easily test 6.12.1 RC and we can't test it with Hackage. We've come to rely on cabal-install quite a lot. So, one option is just to release 6.12.1 as is, with the caveat that cabal-install doesn't work, and large portions of Hackage probably do not work (but we don't know what exactly). The platform isn't due to release with GHC 6.12.x until February 2010, and by then we could make a 6.12.2 to fix any problems that we discover when cabal-install is working. One potential problem is that having made the 6.12.1 release we wouldn't be able to make any further API changes, only bug fixes. Or, we could just make a 6.12.1 RC2, and advertise it with the same caveats, putting out 6.12.1 when cabal-install works and we've had a chance to see the state of Hackage and alert package authors. Simon and I favour the RC2 option. What do others think? Cheers, Simon

7 9

call for organizing next AFP summerschool (2010)
by Simon Marlow 02 Nov '09

02 Nov '09

[ posting on behalf of Rinus Plasmeijer <rinus(a)cs.ru.nl> ] ** *Call for organizers: The Advanced Functional Programming School, 2010.* http://www.cs.uu.nl/~johanj/afp/ We solicit plans for organizing the next Advanced Functional Programming School. Since 1995 there have been six Schools on Advanced Functional Programming: * 2008, LNCS 5832, Nijmegen, The Netherlands * 2004, LNCS 3622, Tartu, Estonia * 2002, LNCS 2638, Oxford, UK * 1998, LNCS 1608, Braga, Portugal * 1996, LNCS 1129, Olympia, WA, USA * 1995, LNCS 925, Baastad, Sweden ------------------------------------------------------------------------ *The goals of this series of schools are* * Bring computer scientists, in particular young researchers and programmers, up to date with the latest AFP techniques. * Use AFP techniques in "programming in the real world". * Bridge the gap between results presented at programming conferences and material from introductory textbooks on functional programming. *The approach we take to achieve these goals in the schools is* * In depth lectures about AFP techniques, taught by experts in the field. * Lectures are accompanied by practical problems to be solved by the students at the school. The problems guide the students' learning to a great extent. This implies that there has to be a lab at the school site. * Group work is stimulated, especially because the practical problems will typically be too large for a single person. By functional programming we mean programming in a style that emphasizes the evaluation of expressions rather than the execution of commands. ------------------------------------------------------------------------ The lecture notes of the Advanced Functional Programming schools are published after the school. The organizers are responsible for publishing the lecture notes. Please submit a proposal for organizing the next advanced functional programming school. *Your proposal should include* * the name of the organizers (preferably more than one) * a programme: lecturers (a mix of young and bright, and old and wise lecturers is preferred) and topics (keep in mind that lectures have to be about "programming in the real world". Applications of functional programming are very important for the school) * the approximate dates (preferably somewhere in 2010) * a location * a budget, including an estimation of the registration and hotel costs per participant. The programme, dates, location and budget don't have to be completely fixed when you submit your proposal, but there should be sufficient information to review your proposal. Your proposal will be reviewed by the steering committee of the Advanced Functional Programming Schools, consisting of · Peter Achten (AFP6) * Pedro Henriques (AFP3) * Johan Jeuring (AFP4, AFP5) * Simon Peyton Jones (AFP4) * Pieter Koopman (AFP6) * Erik Meijer (AFP2) * Rinus Plasmeijer (Chairman, AFP6) * Tim Sheard (AFP2) * Doaitse Swierstra (AFP3, AFP6) * Tarmo Uustalu (AFP5) * Varmo Vene (AFP5) Submit your proposal to rinus(a)cs.ru.nl before December 15, 2009. Notification January 9, 2010.

1 0

Re: Type checker's expected and inferred types (reformatted)
by John Lato 31 Oct '09

31 Oct '09

> From: Isaac Dupree <ml(a)isaac.cedarswampstudios.org> > David Menendez wrote: >> On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree >> <ml(a)isaac.cedarswampstudios.org> wrote: >>> David Menendez wrote: >>>> The expected type is what the context wants (it's *ex*ternal). The >>>> inferred type is what the expression itself has (it's *in*ternal). >>>> >>>> So inferring the type Maybe () for bar seems wrong. >>> well, maybe GHC just gets it wrong enough of the time, that I got confused. >>> >>> Or maybe ... When there are bound variables interacting, on the inside and >>> outside, it gets confusing. >>> >>> >>> ghci: >>> Prelude> \x -> (3+x) + (length x) >>> >>> <interactive>:1:15: >>> Couldn't match expected type `[a]' against inferred type `Int' >>> In the second argument of `(+)', namely `(length x)' >>> In the expression: (3 + x) + (length x) >>> In the expression: \ x -> (3 + x) + (length x) >>> >>> Your explanation of "expected" and "inferred" could make sense to me if the >>> error message followed the "Couldn't match" line with, instead, >>> "In the first argument of `length', namely `x'" >>> because 'length' gives the context of expected list-type, but we've found >>> out from elsewhere (a vague word) that 'x' needs to have type Int. >> >> This had me confused for a while, but I think I've worked out what's >> happening. (+) is polymorphic, ... > > Oh darn, it sounds like you're right. And polymorphism is so common. I > just came up with that example randomly as the first nontrivial > type-error-with-a-lambda I could think of... I think this is a great example of why the current type errors are not as helpful as they could be. The code where the type checker determines 'x' has type [a] is several steps removed from where the error arises. This is how I understand this process (I've probably left out some details): 1. checker infers x :: [a] from 'length x' 2. checker infers (3 + x) :: [a] from (+) and step 1 3. checker infers the second (+) :: [a] -> [a] -> [a] from step 2 4. conflict - checker expects (length x) :: [a] from step 3 and infers (length x) :: Int from definition of 'length'. Even with this simple example the error message given doesn't directly point to the problem. I don't think it's uncommon for there to be more steps in practice. I frequently find myself adding explicit type signatures to let-bound functions to debug these. This is a pain because it also usually involves enabling ScopedTypeVariables. I personally would find it useful if error messages showed the sequence of how the type checker determined the given context. Especially if it would also do so for infinite type errors, which don't provide much useful information to me. Cheers, John

3 3

GHC, CPP and stringize
by Neil Brown 30 Oct '09

30 Oct '09

Hi, The GHC manual says that if you pass -cpp to GHC, it runs the C preprocessor, "cpp" on your code before compilation (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html…) But why, in that case, does stringize not seem to work when the -cpp flag is given? In my example, test.hs is using the C preprocessor with a simple macro to trace functions with their name. Running GHC with -cpp gives an error, but if I run cpp on the file directly then feed it to GHC, I get no error: ===== *$ ghc --version* The Glorious Glasgow Haskell Compilation System, version 6.10.3 *$ cat test.hs* import Debug.Trace #define TR(f) (trace #f f) main :: IO () main = TR(putStrLn) "Hello!" *$ ghc -cpp --make test.hs* [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:6:14: Not in scope: `#' *$ cpp test.hs* # 1 "test.hs" # 1 "<built-in>" # 1 "<command-line>" # 1 "test.hs" import Debug.Trace main :: IO () main = (trace "putStrLn" putStrLn) "Hello!" *$ cpp test.hs > test-cpp.hs* *$ ghc -cpp --make test-cpp.hs* [1 of 1] Compiling Main ( test-cpp.hs, test-cpp.o ) Linking test-cpp ... *$ ./test-cpp* putStrLn Hello! ===== What am I missing? Thanks, Neil.

2 1