October 2008 - Glasgow-haskell-users

could ghci debugger search for free variables better?
by Peter Hercek 23 Oct '08

23 Oct '08

May be my approach to debugging with ghci is wrong but in about half of the time I find ghci (as a debugger) almost useless. The reason is the limited way it can resolve identifiers. I can examine the free variables in the selected expression and nothing else. Well, I *think* just sometimes I can examine few more variables. But if it happens at all it is rare. Is there a way to make ghci recognize all the variables which could be visible in the selected expression? By "could be visible" I mean they are in scope and can be used in the expression if I would edit the source code. ... well I would like to see the stack too but this does not annoy me that much. Peter.

3 7

thread/socket behvior
by Jeff Polakow 22 Oct '08

22 Oct '08

We have a server that accepts messages over a socket, spawning threads to process them. Processing these messages may cause other, outgoing connections, to be spawned. Under sufficient load, the main server loop (i.e. the call to accept, followed by a forkIO), becomes nonresponsive. A smaller distilled testcase reveals that when sufficient socket activity is occurring, an incoming connection may not be responded to until other connections have been cleared out of the way, despite the fact that these other connections are being handled by separate threads. One issue that we?ve been trying to figure out is where this behavior arises from-- the GHC rts, the Network library, the underlying C libraries. Have other GHC users doing applications with large amounts of socket usage observed similar behavior and managed to trace back where it originates from? Are there any particular architectural solutions that people have found to work well for these situations? thanks, Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

3 6

Building ghc-6.10 with ghc-6.6.1
by Bertram Felgenhauer 20 Oct '08

20 Oct '08

Hi, I've successfully built ghc-6.10 with ghc-6.6.1; there was one minor problem: Building extensible-exceptions-0.1.0.0... Control/Exception/Extensible.hs:2:13: cannot parse LANGUAGE pragma ghc 6.6.1 does not know about DeriveDataTypeable - I just removed that line. Software used: ghc-6.6.1 alex 2.2 happy 1.17 Cabal 1.4.0.1 (not relevant, I believe) gcc 4.1.2 (may be relevant because of cpp) linux 2.6.24.4 I'm not sure what Magicloud's problem is, but it's related to alex; the contents of .../alex-2.3/AlexTemplate-ghc (whereever alex was installed) would be interesting -- does it contain any lines starting with # ? This template is generated from templates/GenericTemplate.hs while building alex. Another idea is that {-# OPTIONS -fglasgow-exts -cpp #-} is somehow missing from the generated utils/genprimopcode/Lexer.hs file in the ghc tree - but I can't really see how that would happen. Bertram

1 0

cabal
by Christian Maeder 20 Oct '08

20 Oct '08

Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian

1 0

GHC 6.10 confusion
by J. Garrett Morris 20 Oct '08

20 Oct '08

Hello everyone, I've been attempting to build darcs under ghc-6.10.0.20080920. Currently, I'm getting the following error: ghc failed with: D:\Programs32\GHC\ghc-6.10.0.20080920\bin/windres: CreateProcess (null): No error Does anyone recognize this? Any pointers for where I should be looking? This is on Vista 64-bit SP1. /g -- I am in here

3 3

What a mess....
by Magicloud 20 Oct '08

20 Oct '08

Hi, I want to install ghc 6.10. Well.... I installed ghc 6.6.1 (binary distribution), and cabal, happy, alex (all from darcs, the latest version). Then darcsed 6.10's source. And made. I got: "templates/GenericTemplate.hs:47:21: parse error on input `#'", when "make -C genprimopcode" Any idea what should I do? Thanks.

2 2

Strictness in data declaration not matched in assembler?
by Tyson Whitehead 19 Oct '08

19 Oct '08

Consider the following code data Data = Data { unData :: !Int } func :: Data -> Int func x = case unData x of 1 -> 2 _ -> 0 Compiling with GHC 6.8.2 gives the following stg code Main.func = \r [x_slg] case x_slg of tpl_slx { Main.Data ipv_slj -> case ipv_slj of wild_sly { GHC.Base.I# ds_slm -> case ds_slm of ds1_slz { __DEFAULT -> Main.lvl1; 1 -> Main.lvl; }; }; }; The native code generator turns it into the following x86_64 assembler Main_func_info: leaq -8(%rbp),%rax cmpq %r14,%rax jb .LcnU movq %rsi,%rbx movq $sni_info,-8(%rbp) addq $-8,%rbp testq $7,%rbx jne sni_info jmp *(%rbx) .LcnU: movl $Main_func_closure,%ebx jmp *-8(%r13) sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx) snj_info: cmpq $1,7(%rbx) jne .LcnE movl $Main_lvl_closure+1,%ebx addq $8,%rbp jmp *(%rbp) .LcnE: movl $Main_lvl1_closure+1,%ebx addq $8,%rbp jmp *(%rbp) It seems to me that the !Int member of the Data constructor is being treated like it might be a thunk in sni_info (i.e., the whole "testq $7,%rbx" thing). Isn't this unnecessary as the "!" strictness flag means the Int argument must be forced by the Data constructor before being captured? Thanks! -Tyson

8 14

base-3 vs base-4 (Was: Breakage with 6.10)
by Niklas Broberg 19 Oct '08

19 Oct '08

> > Btw, I also have problems with the haskell-src-exts that imports > > Data.Generics.Instances (to generate Data and Typeable instances). > > Where would these have moved to in the new base? And how would I make > > the code work with both 6.8.3 and 6.10? > > By having it use base-3 rather than 4. Right, and that's how I quickly fixed it up for now. But this doesn't sound like a long-term solution to me, I would prefer to use the new base-4 when possible. The cabal file already includes a conditional "if flag(splitBase)" to handle really old versions, I guess what I'm asking for is something similar for this case. Is there a splitSyb flag or some such? Though obviously this would only work if the module Data.Generics.Instances was preserved under that name somewhere else. If it was renamed or changed (which I suspect), then the hassle of keeping up to date with older versions will probably be too much, and I will want to update to the new agenda as soon as 6.10 is released for real. So what happened to this module? (Is there a migration quicksheet somewhere?) Cheers, /Niklas

6 10

ANNOUNCE: GHC 6.10.1 beta
by Ian Lynagh 17 Oct '08

17 Oct '08

We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a beta release of GHC 6.10.1. You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extrali… Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows, and a binary distribution for x86_64/Linux. More may appear later. There are a couple of known problems with the x86_64/Linux bindist: * It uses libedit.so.0 whereas some distributions (e.g. Debian) only provide libedit.so.2. * It installs utilities like unlit in the wrong place, so compiling literate code won't work. If you install from source then you won't hit either of those problems. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope to have release candidates followed by a release in around 3 weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team

10 31

breakage with Cabal-1.6
by Duncan Coutts 16 Oct '08

16 Oct '08

All, I'm trying to do a Cabal-1.6 release, in time for ghc-6.10. Here's an interim update. There are 7 packages on hackage where the latest version has a Setup.hs script that works with Cabal-1.4 but does not compile with Cabal-1.6. That's actually not too bad. It's been a lot worse in the past, and we have many more packages now. Here's the list and explanations: * ForSyDe-3.0 Uses the copyDest field from CopyFlags. These record types now use an equivalent of Maybe so they can be empty rather than always containing a default value. It's useful, but also kind of annoying in places. It's an easy fix. * MissingPy-0.10.0 * Takusen-0.8.3 * HDBC-postgresql-1.1.4.0 Imports writeHookedBuildInfo from Distribution.PackageDescription This one is a bit annoying. I tried to split up the Distribution.PackageDescription module a bit, because it was something like 1,700 lines long. I moved the parsing out into Distribution.PackageDescription.Parse. Some packages of course sill expect to get writeHookedBuildInfo from the previous location. I could make it still work by using recursive modules, but I worry what that would do to the process of bootstrapping Cabal (especially with hugs or nhc). Or I could re-merge the modules into one massive module again. Or I could say, it's only three packages broken, it's all ok. While the fix for these three packages' Setup scripts is trivial, there is not fix that will make them compile with old and new versions of the lib. Suggestions welcome. * alex-2.2 * happy-1.17 Imports buildVerbose from Distribution.Simple.Setup ( BuildFlags(..) ) however the flag has been renamed to buildVerbosity and with a different type. I would export a compat function but it would not help here since the Setup script expects it to be a record selector from BuildFlags. Cabal-1.4 contained a dodgy hack to make this continue to work, but I'm not doing that again. If I added a compat function then we could at least make it work with both ghc/cabal versions with a single implementation. So I might do that and do point releases of these packages, if Simon thinks that's ok. Really of course both packages should stop calling an external perl and other similar madness. * hsql-odbc-1.7 Imports Distribution.Setup which has been deprecated since at least Cabal-1.2. This package is unmaintained so it's not so surprising. Duncan

6 10