August 2006 - Glasgow-haskell-users

wxHaskell
by H. 10 Aug '06

10 Aug '06

hello @ all, I tried to install wxhaskell for my ghc6.4.2, but not everything went properly... I used the newest version of cygwin, wxWidgets 2.6.3, wxHaskell 0.9.4 and gcc 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) I didn't have any problems by installing and compiling wxWidgets, everything seemed to be fine. The "configure" as well as "make" worked for wxHaskell, but "make install" just produces "out/wxc/ewxw_main.d:1 *** multiple target patterns. Stop." The file starts as following: out/wxc/ewxw_main.o: wxc/src/ewxw_main.cpp wxc/include/wrapper.h \ wxc/include/ewxw_def.h C:/cygwin/usr/local/include/wx-2.6/wx/wx.h \ [...] Does cygming special instead of mingw causes the error or do you know any tricks to avoid this failure or know that other versions of wxWidgets work fine thanks in advance

2 1

Re: Replacement for GMP: Update
by Peter Tanski 10 Aug '06

10 Aug '06

Einar, In my previous email I wrote something potentially confusing (really a typo): > For developers (commercial or open source), the OpenSSL license > only mentions redistribution of the OpenSSL code in binary form > (paragraph 2). In this context "binary form" means the complete > program binary, not partial binary as with statically linking to a > library, so developers of GHC programs would *not* have to include > the whole OpenSSL&SSLeay license in their source code. I meant in their code, not "source code", source or binary. I hope that helps. Best regards, Peter

1 0

RE: GHC 6.4.3 on FreeBSD (fwd)
by Simon Marlow 10 Aug '06

10 Aug '06

Dear threads(a)freebsd.org (and others), This is relating to the problems we're experiencing with GHC's threaded runtime on FreeBSD (see context below). GHC itself, which is a Haskell program, when compiled with itself and linked against GHC's threaded runtime, sometimes hangs eating 100% CPU. This happens when it is linked with -pthreads, I haven't seen it when linking with -lthr. If I attach using gdb to a hung process, I see this: (gdb) where #0 0x2897146b in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x28972499 in __error () from /usr/lib/libpthread.so.2 #2 0x2895e6ba in sigaction () from /usr/lib/libpthread.so.2 #3 0x087ea6b4 in runProcess (args=0x29091758, workingDirectory=0x0, environment=0x0, fdStdInput=0, fdStdOutput=1, fdStdError=2, set_inthandler=1, inthandler=0, set_quithandler=1, quithandler=0) at runProcess.c:61 #4 0x0879b3d0 in s3ja_info () Now, runProcess() is part of our libraries. It is basically doing a fork/exec combo, with some sigaction()s and other stuff in between. As I understand the POSIX spec, it should be safe to do sigaction() in the child of a fork() in a multithreaded process. So I'm surprised to see pthread_testcancel on the stack there. This is about all I've managed to extract. gdb is having difficulty looking at the other threads: (gdb) info thr * 5 LWP 100331 0x2897146b in pthread_testcancel () from /usr/lib/libpthread.so.2 4 Thread 0x8920000 (LWP 100278) Cannot get lwp 100278 registers: Operation not permitted for unknown reasons. Any help would be appreciated... Cheers, Simon On 07 August 2006 18:31, Robert Watson wrote: > Dear many, > > I pinged the FreeBSD threads list about the previously mentioned > problem, and was sent this patch by Dan Eischen. The FreeBSD threads > mailing list is extremely responsive to bug reports; my > recommendation is that we direct future specific bug reports, as well > as any feedback on this patch, to that list. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Mon, 7 Aug 2006 13:15:21 -0400 (EDT) > From: Daniel Eischen <deischen(a)freebsd.org> > To: Robert Watson <rwatson(a)freebsd.org> > Cc: threads(a)freebsd.org > Subject: Re: GHC 6.4.3 on FreeBSD (fwd) > > On Mon, 7 Aug 2006, Robert Watson wrote: > >> >> I've been talking to the Haskell folk about problems they've had >> getting their threaded runtime running on FreeBSD. Here's one of >> their problem reports. Since I'm not up on how threads and signals >> are supposed to act, I can't confirm the below is a bug, of course, >> but figured you (experts) would be able to respond better. > > Try this patch.

1 0

6.6 plans and status
by Simon Marlow 10 Aug '06

10 Aug '06

Hi folks, The Hackathon, ICFP and Haskell Workshop are fast approaching, and we promised to have 6.6 out before then. This means we're on a pretty tight schedule, and some corners will have to be cut in order to get there. But that may not be a bad thing - without hard deadlines the release can easily drag on. So we propose the following schedule for the release: Release candidate: 25 August Release: 8 September giving me a couple of days before I have to fly out to Portland in case of serious mishaps in the release. 6.6 will be an alpha-quality release, mainly because we won't have time to fix all the bugs in the database currently scheduled for 6.6. However, we do expect it to pass the vast majority of the testsuite, and for most uses it'll work fine. We do expect to see more than the usual amount of churn between 6.6 and 6.6.1 while we shake things down, though. Before the release we will be focussing on things that can't be deferred until 6.6.1, and that means API changes (because patchlevels don't modify APIs). But we'll also be redefining the core set of packages that come with GHC, so the API stability will be restricted to just these: base, haskell98, template-haskell, readline, Cabal, unix, Win32 We will probably still ship binary distributions with more packages (at the option of the distribution builder), but in general other packages should be considered independent of GHC. You'll be able to upgrade them separately from GHC. I'm aware we still possibly have threading-related problems on MacOS X, Solaris and FreeBSD. We'll do our best to sort these out before the release, but we can't hold up the release for them. We could really use some help. In particular, I'd like to see test reports for platforms that we don't have run nightly builds on. If you have the time to take one of the 6.6 bugs, please go ahead: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… If you plan to look into a bug, either assign it to yourself (if you have a developer account on the Trac), or else drop us a note saying so. I'll be going through the bug list and prioritising in the next day or two. Many of these bugs will be pushed back to 6.6.1. Cheers, Simon

5 15

Map.lookup in 6.4.1
by Serge D. Mechveliani 10 Aug '06

10 Aug '06

Please, what is the matter with Map.lookup ? In ghc-6.4.1, I try ------------------------------- > ghci -package base ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude> Data.Map.singleton 'a' 'b' {'a':='b'} Prelude> Data.Map.lookup 'a' $ Data.Map.singleton 'a' 'b' Prelude> ------------------------------- Must not it print Just 'b' instead of printing emptyness? Further: ---------- Prelude> Data.Map.lookup 'b' $ Data.Map.singleton 'a' 'b' *** Exception: user error (Data.Map.lookup: Key not found) ---------- Instead, must not it print Nothing ? Thank you in advance for explanation, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Foreign.Marshal.Alloc questions
by Chris Kuklewicz 10 Aug '06

10 Aug '06

For the allocation functions in Foreign.Marshall.Alloc, are the function contracts that return new pointers such that the pointers are never nullPtr, or is it prudent to always check the new ptr? I can see on GHC than allocaBytes uses newPinnedByteArray# but I have not tracked down the source file for that to read it. -- Chris Kuklewicz

2 1

fork and ghc
by John Meacham 09 Aug '06

09 Aug '06

I want to modify jhc to take advantage of mutiple CPUs to help mitigate its prodigious computational requirements and was curious how well ghc compiled programs deal with forking? my initial plan is that once jhc determines which modules need to be recompiled, it will fork(2) off processes down each pass that can be done in parallel. however, I have no idea what the effect of just calling fork on the ghc runtime will be. both parent and child will continue on compiling code, so it won't be immediatly followed by an exec. John -- John Meacham - ⑆repetae.net⑆john⑈

3 3

RE: GHC 6.4.3 on FreeBSD (fwd)
by Simon Marlow 09 Aug '06

09 Aug '06

Thanks Robert. I don't believe that particular bug is on our critical path, but I'm glad they have a fix. I haven't tried the patch myself, not having a FreeBSD build handy. The current status w.r.t. GHC is: - I merged a fix to the timeout program in our testsuite that fixes occasional hangs on FreeBSD (issue was calling fork() from the child of fork(), not allowed according to POSIX). - I did a complete build and testsuite run with -lthr instead of -pthread, this completes without problems. - When GHC itself is linked with the threaded RTS and -pthread, it occasionally hangs (I saw about 5 hangs during a testsuite run of 2000 tests). When it hangs, it is consuming 100% CPU. I tried attached to the hung GHC process using gdb, and got this: ~ > gdb --pid=53978 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Attaching to process 53978 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c :1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c :1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Abort trap: 6 (core dumped) At this stage I'm tempted to default to using -lthr, since this appears to work. I can't make any further progress on the -pthread hangs without gdb working, unfortunately. If you think I should report the gdb crash, where is the best place? Cheers, Simon On 07 August 2006 18:31, Robert Watson wrote: > Dear many, > > I pinged the FreeBSD threads list about the previously mentioned > problem, and was sent this patch by Dan Eischen. The FreeBSD threads > mailing list is extremely responsive to bug reports; my > recommendation is that we direct future specific bug reports, as well > as any feedback on this patch, to that list. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Mon, 7 Aug 2006 13:15:21 -0400 (EDT) > From: Daniel Eischen <deischen(a)freebsd.org> > To: Robert Watson <rwatson(a)freebsd.org> > Cc: threads(a)freebsd.org > Subject: Re: GHC 6.4.3 on FreeBSD (fwd) > > On Mon, 7 Aug 2006, Robert Watson wrote: > >> >> I've been talking to the Haskell folk about problems they've had >> getting their threaded runtime running on FreeBSD. Here's one of >> their problem reports. Since I'm not up on how threads and signals >> are supposed to act, I can't confirm the below is a bug, of course, >> but figured you (experts) would be able to respond better. > > Try this patch.

1 0

Building GHC on OS X
by David Kirkman 09 Aug '06

09 Aug '06

Hi, I've been using ghc on Mac OS X for a while now, so when I noticed Simon Marlow's call (made last month, but I just noticed it) for people to help with OS X, I thought, why not? Well, it turns out that I can't even build ghc, so I'm not likely to end up being much help. But it would be nice to at least be able to build the thing, so if anybody can help me... I'm trying to build GHC (6.5.?? ... version from darcs.haskell.org as of yesterday) on Mac OS X (10.4.7 ppc) bootstrapping from ghc 6.4.2 and gcc 4.0.1. "./configure; make" does not work. On my initial try, I ran into the UNDO_DELETE, etc problems associated with Darwin's partial readline support described in ticket #766. The fix suggested in that ticket seems to work fine, but not until I installed the GNU readline library. (If the change to detect the broken Darwin readline is in the repository, it did not work for me). After fixing the readline problem, it looks like I can build at least part of the stage1 compiler -- but the build fails just after starting to build stage2. The final error is: > ../compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches - fwarn-unused-imports -istage2/utils -istage2/basicTypes -istage2/ types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/ typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise - istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/ simplStg -istage2/codeGen -istage2/main -istage2/profiling - istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/ iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 - DGHCI -DBREAKPOINT -package template-haskell -threaded -cpp -fglasgow- exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser - package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -DDEBUG -H16M '-#include "hschooks.h"' -package-name ghc-6.5 - fgenerics -O -c utils/FastString.lhs -o stage2/utils/FastString.o - ohi stage2/utils/FastString.hi > > utils/FastString.lhs:73:0: > Failed to load interface for `GHC.Exts': > Could not find module `GHC.Exts': > use -v to see a list of the files searched for > <<ghc: 52487092 bytes, 5 GCs, 19236/19236 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.29 MUT (0.38 elapsed), 0.03 GC (0.04 elapsed) :ghc>> > make[2]: *** [stage2/utils/FastString.o] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 The first error that I can find comes when building ghc/libraries/ base (in stage1) > ../../compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches - fwarn-unused-imports -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name base-1.0 -O -dcore-lint -W -fno-warn-unused-matches -fwarn-unused-imports -keep-hc-files - fgenerics -c Data/Generics/Schemes.hs -o Data/Generics/Schemes.o - ohi Data/Generics/Schemes.hi > Data/Generics/Schemes.hs:108:15: > Couldn't match expected type `r' (a rigid variable) > against inferred type `[a]' > `r' is bound by the type signature for `listify' > at Data/Generics/Schemes.hs:106:20 > Expected type: r -> r -> r > Inferred type: [a] -> [a] -> [a] > In the first argument of `everything', namely `(++)' > In the call (everything (++) > ([] `mkQ` (\ x -> if p x then [x] else []))) > make[2]: *** [Data/Generics/Schemes.o] Error 1 After that, there are a handful of errors complaining about things that can't be found (e.g.) > CPUTime.hs:5:0: > Failed to load interface for `System.CPUTime': > Could not find module `System.CPUTime': > use -v to see a list of the files searched for > make[2]: *** [CPUTime.o] Error 1 and > Language/Haskell/TH/Syntax.hs:46:0: > Failed to load interface for `Data.PackedString': > Could not find module `Data.PackedString': > use -v to see a list of the files searched for > make[2]: *** [Language/Haskell/TH/Syntax.o] Error 1 There are six or seven more messages like those, but nothing severe enough to stop make until the problem where it can not find 'GHC.Exts'. I tried to brute force it with 'make -k', which went a lot further, but in the end build nothing useful. Anybody have any ideas? Or build instructions for OS X? Thanks, -david k.

2 1

ANN: TextRegexLazy-0.66 devel release
by Chris Kuklewicz 08 Aug '06

08 Aug '06

(when (compilesOk) (announce newVersion)) This is a development release announcement of "TextRegexLazy" The "TextRegexLazy" package is dead. Long Live [regex-base -- interfaces ,regex-compat -- replace Text.Regex ,regex-posix -- PosixRE backend ,regex-pcre -- PCRE backend ,regex-parsec -- My lazy Haskell backend ,regex-dfa -- DFA based on modified CTKLight (LGPL) ] Note: Everything is BSD licensed except the regex-dfa engine which is LGPL. The darcs repository at http://evenmere.org/~chrisk/trl/head/ has the new version. The regex-compat package is a single Text.Regex.New module that uses regex-posix to replace Text.Regex (I cut and pasted from the Text.Regex module and re-implemented some of the functions). The old Text.Regex.Posix module is bypassed (so it could be removed in the future). Changing the dependency to a different backend is as simply as changing the import statement. Changing from String to ByteString would be a simple search-and-replace (and import Data.ByteString). The regex-posix package does not have a personal copy of the posix regex library like the copy GHC brings to Windows: http://darcs.haskell.org/packages/base/cbits/regex/ If someone can get regex-posix working on Windows, then [regex-base,regex-posix,regex-compat] will be functionally ready to be included along with GHC. TODO: * Much Haddock fixing for the new module hierarchy * Point the test cases at the new packages * Benchmark -- Chris Kuklewicz

1 0