- Glasgow-haskell-users

Help with Win64 port
by George Brewster 01 Jul '10

01 Jul '10

Hey, I'd really like to see ghc working on 64-bit Windows, so I've decided to take at least a quick stab at getting it going. Having talked to some of the people on #ghc, it sounds like the first thing to do is get an unregisterised build going, which sounded like it may be managable. So to that end, I've pulled the 6.12 branch, done a 32-bit build, changed the build config to do an unregisterised build and turn off the native code generator, found a version of mingw64 which seems to work for me, stuffed it in in place of the in-tree mingw, and got my build to fail. At this point, I'd like to get a general idea of what my strategy should be. I read the Building/Porting page on the wiki, and used the config file there as an example of how to do an unregisterised build, but have been ignoring anything related to the hc file bootstrapping process, as I have a working ghc on my platform, just of the wrong bitness. In particular, if there are any changes that you know I'll need to make to the source to get this working, please let me know. The more of those I learn about now, the less fumbling around I'll have to do as things break. In particular, is there some place where I indicate that I'm build a 64-bit compiler? I didn't find anything with a quick look. I have very little time to work on it, and no familiarity with ghc internals, so I wouldn't expect much, but I'm hoping I can get it going... -George

2 1

Re: [Haskell-cafe] Space leak with unsafePerformIO
by Yitzchak Gale 01 Jul '10

01 Jul '10

Henning Thielemann wrote on Haskell Cafe: >> Attached is a program with a space leak... >> I have coded a simple 'map' function, once using unsafePerformIO and >> once without. UnsafePerformIO has a space leak in some circumstances. >> In the main program I demonstrate cases with and without space leak. >> Without space leak the program writes a file to the disk until it >> is full. Bertram Felgenhauer wrote: > The program relies on the GC doing short-cut evaluation of record > selectors to avoid a space leak... > Use of suffix: Due to the call of Main.go1 this is *not* a record > selector. It is compiled to an actual case expression, which to the > garbage collector looks just like an ordinary thunk. A reference to > Main.ds is kept around until the suffix is about to be processed > and a memory leak ensues. > The good news is that the problem is completely unrelated to > unsafePerformIO (the presence of unsafePerformIO makes optimisations > more difficult, but any pure function of sufficient complexity would > have the same effect). Is there already a GHC Trac bug for this? Link to Bertram's original email, with detailed analysis of the GHC Core: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079479.html Thanks, Yitz

2 1

heap profiling
by Evan Laforge 01 Jul '10

01 Jul '10

I've been trying to profile my program and having some trouble. I imagine other people have stumbled across these same issues, so hopefully I can benefit from someone else's experience. In return, if I can figure out some of these things, I'll put it up at http://www.haskell.org/haskellwiki/How_to_profile_a_Haskell_program or maybe make make a heap profiling page linked from that. Firstly a few miscellaneous questions: When running '-hc -hblag,drag' it works for a little while and then stops. The app is still hung, but cpu has gone to 0%. The disk is also idle, so I don't think it's swapping. According to -S, all garbage collection has stopped too. It's apparently due to something about this particular profile, since reducing the amount of data it handles just results in a sooner hang. This same combination works with other profiles, so apparently something the code is doing is locking up. Has anyone else seen this? Any tips on how to troubleshoot where it's getting stuck, doing what? If it sounds like a ghc bug I can try to trim down the size and submit a ticket. GHC 6.12.1 on OSX. The image link from http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/profiling.html is broken, which makes it a little harder to understand the documentation. -s stats say GC time is 46%, productivity is 32%. That's pretty bad, right? And where is the remaining 22% going? The ghc manual says lag is "time between creation and first use" and drag is "time between last use and last reference is dropped". I think I understand drag: it means you haven't touched the data for a while before it goes out of scope or its retainer goes out of scope. So for instance: stuff = do st <- get x1 st x2 Does this mean that 'st' will be dragging through 'x2' as it would in an imperative language? I gather the usual haskell use is when combined with laziness: 'Map.insertWith (+) "a" 42' will keep the old value of "a" around until you look "a" up and force it, since the (+) won't be applied until then. Same with foldl. Are there some other classic examples of drag? Searching for "haskell dragging problem" doesn't yield much to do with memory use. Lag I'm not so sure about. How is something created before it's used? And... what's INHERENT_USE? And what about VOID? How can an object be created but never used? What triggered its creation? So, the main question: I have a program that runs some computation in a monad stack before extracting the final result, a list, and passing it on. When run under the heap profiler, there's a huge spike in that phase, which I think should be mostly bogus usage, since the final output is so relatively small. When I run under -hb I see big bands for LAG and DRAG. According to -hd the top 3 users are: <mtl-1.1.0.2:Control.Monad.Writer.Lazy.sat_sltc> (,) D:Monad This is kind of puzzling to me... first of all I've never seen an explanation for sat_* closure descriptors, and second of all, why does it not show up in the .prof file at all? I switched to Writer.Strict and the drag disappeared, which helped, but the lag is still there, and the top -hd is now <mtl-1.1.0.2:Control.Monad.Writer.Strict.sat_soa1> State stg_ap_2_upd_info (the top -hy is "*", which I gather means "don't know"). And what's "stg_ap_2_upd_info"? The top item accounts for 70% of the memory usage. One obvious candidate for the lag is Writer's data (DList Log.Msg) is collecting and only being forced at the end of the computation, but there is no logging in this section and in any case should never be 30M of it! -hc is not helpful since every monadic operation is charged a little bit, -hr is similarly unhelpful (top retainer is MANY... hah). So what exactly is this sat_*? Where is the memory going? I guess it doesn't have an SCC since it doesn't show up in the .prof output. Is there some place I can manually put an SCC? I was able to fix the drag just by guessing at a strict writer, but the lag is still around. Is there another spot in Writer's >>= that could be accumulating? What's *in* that giant mountain of lag?

4 11

Fwd: Segmentation fault in non-dynamically linked binaries?
by austin seipp 30 Jun '10

30 Jun '10

Forwarding this to g-h-u for archival purposes and in case anybody else has ideas (should'a done this earlier.) ---------- Forwarded message ---------- From: austin seipp <as(a)0xff.ath.cx> Date: Wed, Jun 16, 2010 at 11:21 AM Subject: Re: Segmentation fault in non-dynamically linked binaries? To: Simon Marlow <marlowsd(a)gmail.com> Follow up: Both of my machines are running debian x86_64 linux, both with libc6 version 2.11.2-1 (aka eglibc,) from debian sid. My work machine does not exhibit the same segfaulting behavior as my home machine. Debugging with the rts source available and watching setFullProgArgv go by does not help a lot - when stgCallocBytes is called with strlen as a parameter (to determine how much to allocate,) the code immediately crashes upon arrival into the first instruction of strlen, but the strange thing is *which* strlen it is jumping to. >From a simple 'hello world' executable on my work machine, when disassembling setFullProgArgv we get this: ... 0x0000000000432a26 <setFullProgArgv+54>: xor %ebp,%ebp 0x0000000000432a28 <setFullProgArgv+56>: nopl 0x0(%rax,%rax,1) 0x0000000000432a30 <setFullProgArgv+64>: mov (%r14,%rbp,1),%rdi 0x0000000000432a34 <setFullProgArgv+68>: mov %rbp,%rbx 0x0000000000432a37 <setFullProgArgv+71>: add 0x247f5a(%rip),%rbx # 0x67a998 <full_prog_argv> 0x0000000000432a3e <setFullProgArgv+78>: add $0x1,%r12d 0x0000000000432a42 <setFullProgArgv+82>: callq 0x4028b8 <strlen@plt> 0x0000000000432a47 <setFullProgArgv+87>: lea 0x1(%rax),%edi 0x0000000000432a4a <setFullProgArgv+90>: mov $0x4616fe,%esi 0x0000000000432a4f <setFullProgArgv+95>: callq 0x434790 <stgMallocBytes> 0x0000000000432a54 <setFullProgArgv+100>: mov %rax,(%rbx) 0x0000000000432a57 <setFullProgArgv+103>: mov 0x247f3a(%rip),%rax ... Note that it calls strlen@plt which jumps to libc's implementation of strlen. However, when looking at this same program compiled on my home machine, we instead get: ... 0x0000000000432db6 <+54>: xor %ebp,%ebp 0x0000000000432db8 <+56>: nopl 0x0(%rax,%rax,1) 0x0000000000432dc0 <+64>: mov (%r14,%rbp,1),%rdi 0x0000000000432dc4 <+68>: mov %rbp,%rbx 0x0000000000432dc7 <+71>: add 0x24898a(%rip),%rbx # 0x67b758 <full_prog_argv> 0x0000000000432dce <+78>: add $0x1,%r12d 0x0000000000432dd2 <+82>: callq 0x67b3c0 <strlen@@GLIBC_2.2.5> 0x0000000000432dd7 <+87>: lea 0x1(%rax),%edi 0x0000000000432dda <+90>: mov $0x46207e,%esi 0x0000000000432ddf <+95>: callq 0x434cb0 <stgMallocBytes> 0x0000000000432de4 <+100>: mov %rax,(%rbx) 0x0000000000432de7 <+103>: mov 0x24896a(%rip),%rax # 0x67b758 <full_prog_argv> ... Here we call a version of strlen which the dynamic linker enforces come from glibc v2.2.5. If we run objdump -x, we get: ... Version References: required from librt.so.1: 0x09691973 0x00 04 GLIBC_2.3.3 required from libm.so.6: 0x09691a75 0x00 03 GLIBC_2.2.5 required from libc.so.6: 0x0d696913 0x00 05 GLIBC_2.3 0x09691a75 0x00 02 GLIBC_2.2.5 ... So there are some dependencies on older GLIBC versions for certain symbols, but I'm not sure why. I'm at work agaom so I'll follow up again here in a few hours once I get back home after doing some more reading. On Tue, Jun 15, 2010 at 3:43 PM, austin seipp <as(a)0xff.ath.cx> wrote: > Simon, > > Thanks for the reply. > > One interesting thing to note is that on my work machine, also running > x86_64 debian, with with a full update from apt (many updates come > from sid, others are from lenny,) static and dynamic linking both seem > to work fine for the same versions of GHC that affect my home machine. > > On my debian machine here at work I have a libc6 which is installed > from the unstable sid repository. It is libc6 version '2.11-1', which > is actually a version of eglibc, not glibc (although eglibc is > designed for full ABI-level compatibility - debian switched to it a > while ago.) I believe my home machine with x86_64 debian has the exact > same version of libc6 installed out of sid repos but I cannot confirm > that at the moment. > > I do not currently have access to my home machine from here. When I do > I'll get a copy of the 6.12.1 source code and do a debug link and do > some more investigation. > > Thanks, > > On Tue, Jun 15, 2010 at 5:33 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> On 13/06/2010 07:26, austin seipp wrote: >>> >>> Hello, >>> >>> I am running GHC on x86_64 debian linux, and recently I have >>> discovered that the executables generated by my GHC segfault when the >>> linking step is not dynamic. >>> I discovered this while attempting to install haskell-src-exts, which >>> requires a linked version of Setup.hs when cabal builds it (and which >>> would fail inexplicably until I did >>> further investigation.) >>> >>> Example: >>> >>> link ~/t » cat hi.hs >>> main :: IO () >>> main = putStrLn "hi" >>> link ~/t » ghc -dynamic hi.hs >>> link ~/t » file ./a.out >>> ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), >>> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not >>> stripped >>> link ~/t » ldd ./a.out >>> linux-vdso.so.1 => (0x00007fffbadff000) >>> libHShaskell98-1.0.1.1-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/haskell98-1.0.1.1/libHShaskell98-1.0.1.1-ghc6.12.3.so >>> (0x00007fab3a4c4000) >>> libHSrandom-1.0.0.2-ghc6.12.3.so => >>> /usr/local/lib/ghc-6.12.3/random-1.0.0.2/libHSrandom-1.0.0.2-ghc6.12.3.so >>> (0x00007fab3a2af000) >>> libHStime-1.1.4-ghc6.12.3.so => >>> /usr/local/lib/ghc-6.12.3/time-1.1.4/libHStime-1.1.4-ghc6.12.3.so >>> (0x00007fab39fad000) >>> libHSprocess-1.0.1.3-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/process-1.0.1.3/libHSprocess-1.0.1.3-ghc6.12.3.so >>> (0x00007fab39d93000) >>> libHSdirectory-1.0.1.1-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/directory-1.0.1.1/libHSdirectory-1.0.1.1-ghc6.12.3.so >>> (0x00007fab39b77000) >>> libHSunix-2.4.0.2-ghc6.12.3.so => >>> /usr/local/lib/ghc-6.12.3/unix-2.4.0.2/libHSunix-2.4.0.2-ghc6.12.3.so >>> (0x00007fab398c6000) >>> librt.so.1 => /lib/librt.so.1 (0x00007fab396a2000) >>> libutil.so.1 => /lib/libutil.so.1 (0x00007fab3949f000) >>> libdl.so.2 => /lib/libdl.so.2 (0x00007fab3929b000) >>> libHSold-time-1.0.0.5-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/old-time-1.0.0.5/libHSold-time-1.0.0.5-ghc6.12.3.so >>> (0x00007fab3903c000) >>> libHSold-locale-1.0.0.2-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/old-locale-1.0.0.2/libHSold-locale-1.0.0.2-ghc6.12.3.so >>> (0x00007fab38e28000) >>> libHSfilepath-1.1.0.4-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/filepath-1.1.0.4/libHSfilepath-1.1.0.4-ghc6.12.3.so >>> (0x00007fab38c07000) >>> libHSarray-0.3.0.1-ghc6.12.3.so => >>> /usr/local/lib/ghc-6.12.3/array-0.3.0.1/libHSarray-0.3.0.1-ghc6.12.3.so >>> (0x00007fab38992000) >>> libHSbase-4.2.0.2-ghc6.12.3.so => >>> /usr/local/lib/ghc-6.12.3/base-4.2.0.2/libHSbase-4.2.0.2-ghc6.12.3.so >>> (0x00007fab381f2000) >>> libHSinteger-gmp-0.2.0.1-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/integer-gmp-0.2.0.1/libHSinteger-gmp-0.2.0.1-ghc6.12.3.so >>> (0x00007fab37fe1000) >>> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fab37da1000) >>> libHSghc-prim-0.2.0.0-ghc6.12.3.so => >>> >>> /usr/local/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so >>> (0x00007fab37b1c000) >>> libHSrts-ghc6.12.3.so => >>> /usr/local/lib/ghc-6.12.3/libHSrts-ghc6.12.3.so (0x00007fab378ba000) >>> libm.so.6 => /lib/libm.so.6 (0x00007fab37637000) >>> libHSffi-ghc6.12.3.so => >>> /usr/local/lib/ghc-6.12.3/libHSffi-ghc6.12.3.so (0x00007fab3742a000) >>> libc.so.6 => /lib/libc.so.6 (0x00007fab370c9000) >>> libpthread.so.0 => /lib/libpthread.so.0 (0x00007fab36eac000) >>> /lib64/ld-linux-x86-64.so.2 (0x00007fab3a6cb000) >>> link ~/t » ./a.out >>> hi >>> link ~/t » rm ./a.out *.hi *.o >>> link ~/t » ghc hi.hs >>> link ~/t » file ./a.out >>> ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), >>> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not >>> stripped >>> link ~/t » ldd ./a.out >>> linux-vdso.so.1 => (0x00007fffaafff000) >>> librt.so.1 => /lib/librt.so.1 (0x00007fdf83d77000) >>> libutil.so.1 => /lib/libutil.so.1 (0x00007fdf83b74000) >>> libdl.so.2 => /lib/libdl.so.2 (0x00007fdf8396f000) >>> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fdf83730000) >>> libm.so.6 => /lib/libm.so.6 (0x00007fdf834ae000) >>> libc.so.6 => /lib/libc.so.6 (0x00007fdf8314c000) >>> libpthread.so.0 => /lib/libpthread.so.0 (0x00007fdf82f30000) >>> /lib64/ld-linux-x86-64.so.2 (0x00007fdf83f9c000) >>> link ~/t » ./a.out >>> [1] 7850 segmentation fault ./a.out >>> link ~/t » gdb7.0 ./a.out >>> >>> >>> 139 ↵ >>> GNU gdb (GDB) 7.0 >>> Copyright (C) 2009 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or >>> later<http://gnu.org/licenses/gpl.html> >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "x86_64-unknown-linux-gnu". >>> For bug reporting instructions, please see: >>> <http://www.gnu.org/software/gdb/bugs/>... >>> Reading symbols from /home/a/t/a.out...done. >>> (gdb) r >>> Starting program: /home/a/t/a.out >>> [Thread debugging using libthread_db enabled] >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x000000000067b3c0 in strlen@@GLIBC_2.2.5 () >>> (gdb) bt >>> #0 0x000000000067b3c0 in strlen@@GLIBC_2.2.5 () >>> #1 0x0000000000432dd7 in setFullProgArgv () >>> #2 0x000000000043464d in hs_init () >>> #3 0x000000000043478d in startupHaskell () >>> #4 0x0000000000433d59 in real_main () >>> #5 0x0000000000433e87 in hs_main () >>> #6 0x00007ffff6fccc4d in __libc_start_main () from /lib/libc.so.6 >>> #7 0x0000000000402d49 in _start () >>> (gdb) >>> >>> >>> What's interesting is that this occurs with all versions of GHC on my >>> machine, which include: >>> * GHC 6.12.1 >>> * GHC 6.12.3 >>> * GHC 6.13.20100426 >>> >>> Executables that were statically linked with GHC before this strange >>> behavior started occurring appear to still work, i.e. xmonad& xmobar. >>> I recently did an update of my machine with aptitude, but I would not >>> think this would interfere with GHC. >> >> Strange - I suspect there is some ABI change in glibc that means the static >> libraries are no longer compatible with the new version. You'll get more >> information out of gdb if you compile with -debug, then try stepping through >> from setFullProgArgv to see what goes wrong. >> >> If there is an ABI change, and it's going to appear in all the major Linux >> distros at some point, this could give us some difficulties with binary >> distributions. >> >> Cheers, >> Simon >> > > > > -- > - Austin > -- - Austin -- - Austin

1 1

Alternative (per-project) package database
by Dimitry Golubovsky 30 Jun '10

30 Jun '10

Hi, Summarizing my findings (I couldn't find solution to this problem anywhere; maybe somebody else gets interested as well). Experimental setting: A simple package targeting a hello-world like application. We will keep all dependent upon packages in a subdir named .private-pkg All commands are run from within this project directory. Bootstrapping: Initialize packages database ghc-pkg init .private-pkg Clone few initial packages from the existing installation: ghc-pkg describe <package name here> | (GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg register -) These packages are (in this order): ffi, rts, ghc-prim, integer-gmp, base-4.2.0.1 (or whatever base-4 you have) If just "base" is specified, ghc-pkg will attempt to dump the description of base-3.x.x.x package which is not what we need. Check that packages are installed without problems. $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 ffi-1.0 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 rts-1.0 Try to install some package (for simplicity, choose `bytestring' as it has only base in dependencies). (export GHC_PACKAGE_PATH=`pwd`/.private-pkg/; cabal install bytestring --package-db=$GHC_PACKAGE_PATH --prefix=`pwd`) $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 bytestring-0.9.1.7 ffi-1.0 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 rts-1.0 Our test executable looks like this: --------------------------------------------------------------------------- module Main where import System.Directory main = do putStrLn "Hello Private World" getDirectoryContents "." >>= putStrLn . show --------------------------------------------------------------------------- So we have to include `directory' as dependency in the project's cabal file. Let's build the executable: (export GHC_PACKAGE_PATH=`pwd`/.private-pkg/; cabal install --package-db=$GHC_PACKAGE_PATH --prefix=`pwd`) Resolving dependencies... Configuring filepath-1.1.0.4... Preprocessing library filepath-1.1.0.4... Building filepath-1.1.0.4... [1 of 3] Compiling System.FilePath.Windows ( System/FilePath/Windows.hs, dist/build/System/FilePath/Windows.o ) [2 of 3] Compiling System.FilePath.Posix ( System/FilePath/Posix.hs, dist/build/System/FilePath/Posix.o ) [3 of 3] Compiling System.FilePath ( System/FilePath.hs, dist/build/System/FilePath.o ) Registering filepath-1.1.0.4... Installing library in /home/dima/src/hello-pvt/lib/filepath-1.1.0.4/ghc-6.12.2 ............................... Building directory-1.0.1.1... [1 of 1] Compiling System.Directory ( System/Directory.hs, dist/build/System/Directory.o ) Registering directory-1.0.1.1... Installing library in /home/dima/src/hello-pvt/lib/directory-1.0.1.1/ghc-6.12.2 Registering directory-1.0.1.1... Configuring hello-pvt-0.1... Preprocessing executables for hello-pvt-0.1... Building hello-pvt-0.1... Linking dist/build/hello-pvt/hello-pvt ... Installing executable(s) in /home/dima/src/hello-pvt/bin .................... $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 bytestring-0.9.1.7 directory-1.0.1.1 ffi-1.0 filepath-1.1.0.4 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 old-locale-1.0.0.2 old-time-1.0.0.5 rts-1.0 unix-2.4.0.2 Thus, everything needed got compiled and installed under the project's directory. So it will be easy to clean everything up just by removing bin, lib, and .private-pkg subdirs (or choose a better prefix for cabal install, so everything will install in a single location). So, cabal does work in project-private mode. Maybe developers of cabal-install would consider adding such mode to the program, so all these extra options will not be needed. Of course votes from other users will increase the chance of such addition ;) Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1

GHC.IO.Device and "ready" method?
by Dimitry Golubovsky 29 Jun '10

29 Jun '10

Hi, Should an implementation of GHC.IO.Device expect the `ready' method to be called from a thread different than one waiting for an I/O operation on a handle to complete, while that operation is in progress? As a more general question, are GHC Handles (and underlying implementations of GHC.IO.Device and GHC.IO.BufferedIO) expected to be thread-safe? I would be happy to store the id of the thread that calls mkFileHandle somewhere in the underlying `dev' and simply reject all I/O requests that come from other threads, but is this correct/permitted behavior? Thanks. -- Dimitry Golubovsky Anywhere on the Web

3 2

Alternative (per-project) GHC package database?
by Dimitry Golubovsky 29 Jun '10

29 Jun '10

Marc, Marc Weber wrote: > If you want to give hack-nix a try you can get what you're looking for > by running these two commands: > hack-nix --build-env > . ./default-env > However you have to install Nix once. I thought I could stay within Cabal without adding Nix, however Nix was on my mind. My initial thought is: for bootstrapping, I could dump package descriptions from the global database for few basic packages (rts, ghc-prim, base, etc.) and run them through ghc-pkg register with GHC_PACKAGE_PATH set to cover only per-project package conf directory. -- Dimitry Golubovsky Anywhere on the Web

1 0

Alternative (per-project) GHC package database?
by Dimitry Golubovsky 29 Jun '10

29 Jun '10

Hi, I would like to have a completely per-project configuration of GHC installed packages. Suppose I have a project (targeting one or more executables) directory: /my/project and a (initially empty) subdirectory in it: /my/project/packages and GHC and Cabal are run like cd /my/project ; GHC_PACKAGE_PATH=/my/project/packages cabal install so the default global and user package configurations are not visible when building the project. How can I bootstrap a fresh minimal working GHC package configuration at the empty location? Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1

new recursive do notation (ghc 6.12.x) spoils layout
by John Lask 23 Jun '10

23 Jun '10

Whilst I have nothing against the change in syntax for recursive do aka http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html Instead of writing mdo a <- getChar b <- f c c <- g b putChar c return b you would write do a <- getChar rec { b <- f c ; c <- g b } putChar c return b it does spoil the nice layout - it would be nice to just be able to write (which does not parse) do rec a <- getChar b <- f c c <- g b putChar c return b I don't particularly care that the only recursive statements are #2,#3 - I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised "do rec" as a recursive group it would have been a drop in replacement and taken me one tenth of the time. Why can't we have this?

3 3

Thread-backed handles: thread blocked indefinitely in an MVar operation
by Dimitry Golubovsky 22 Jun '10

22 Jun '10

Simon, On Tue, Jun 22, 2010 at 4:31 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: > So the problem is that fillReadBuffer has to return 0 to indicate EOF, but > you are killing the slave thread as soon as it has reached the end of the > stream. So you get one call to fillReadBuffer that returns the data up to > the end of the stream, and the next call that should return 0 blocks on the > Chan indefinitely because the slave thread has already been killed. Thanks for your reply. Updated paste: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=26455 I enclosed readChan in a catchException call which seems to have cured the problem: it just simulates EOF on the handle if the thread is blocked (channel vanished). Interestingly that in the failing version, handle closing was done in a separate thread (thread 3), but in the updated version it was the same thread 1. -- Dimitry Golubovsky Anywhere on the Web -- Dimitry Golubovsky Anywhere on the Web

2 1