- Glasgow-haskell-users

ANN: TextRegexLazy 0.70 (stable)
by Chris Kuklewicz 11 Aug '06

11 Aug '06

What: "TextRegexLazy" version 0.70 Where: darcs get --partial http://evenmere.org/~chrisk/trl/stable/ (and darcs get --partial http://evenmere.org/~chrisk/trl/head/ ) The conversion to separate regex-* packages seems stable now. More changes will be done as part of interfacing with GHC. What should I do to advance the plan of changing GHC's regex support? Note that the new Posix library backend is much higher performance than the old one when searching for all the (non-overlapping) matches. The regex-compat package provides Text.Regex.New that uses this better wrapping. The low level API from the Wrap modules always handles errors with Either types. The (Byte)String modules provide a medium level API that handles errors with Either types (compile/execute/regexec). By comparison, the "match" or "=~" high level API still calls error or fail. The build environment will have to be slightly edited when installing. Details are in the README file (and you can and should email me questions). I would appreciate someone with ghc on windows to build as many of the packages as possible and tell me how to do it or how to fix it. GHC includes a copy of the Posix regex library to compile on windows, but regex-posix does not do this (yet). regex-parsec may undergo some small changes to give it a more posix-compatible mode. Right now QuickCheck has found some sub-expression captures that are different for pcre and posix, and parsec agrees with pcre in its left-most strategy but does not always agree with posix in its longest strategy. -- Chris

1 0

dependingOn in 6.6
by John Meacham 11 Aug '06

11 Aug '06

I was wondering if we could be sure to get dependingOn :: a -> b -> a dependingOn = .... in ghc 6.6? this has been discussed before, it is implemented in jhc and I have found all sorts of use for it as it can be used to control let floating and inlining in a nice general way and is trivial to implement. (one for ghc was posted before based on primitives it already implements) we just need to decide on a module to export it. the meaning is that x = ... `dependingOn` y returns x with an artificial dependency on y. so things using x cannot be floated out above where y is defined. John -- John Meacham - ⑆repetae.net⑆john⑈

4 4

getMBlocks
by Rich Fought 11 Aug '06

11 Aug '06

Hello, I'm still chasing down a memory leak in my server application written in Haskell using GHC 6.4.x under MinGW/MSYS. In the scenario described below, I am repeating the same server request once per second continuously. After utilizing some memory monitoring tools I've discovered that memory usage fluctuates within in a range of approximately 850 KB (I assume as garbage is collected), but at regular intervals the range gets bumped up by ~ 1 MB. So in effect I get a stair-stepping of memory usage that keeps repeating until memory runs out. WinDbg has revealed that this stepping coincides with the GHC runtime function getMBlocks(). My question is: what conditions affect when the runtime determines that it needs more memory? Is it a pure "no more room" trigger or is there some sort of algorithm behind it? I assume that this behavior means I still have a space leak somewhere in my Haskell code, though none of leak check tools I utilize indicate such. Thanks, Rich

2 4

GHC 6.4.3 on FreeBSD
by Simon Marlow 11 Aug '06

11 Aug '06

An update on the GHC/FreeBSD front: I didn't manage to reproduce the reported threading bugs on a UP, will be trying on a MP shortly. However, I did discover one odd case that libpthread doesn't appear to handle properly, but libthr does. This arose from a test in GHC's test suite, but I've transliterated the code from Haskell to C: $ cat thr1.c #include <unistd.h> #include <signal.h> #include <pthread.h> int main(int argc, char *argv[]) { sigset_t s; sigemptyset (&s); sigaddset(&s, SIGUSR1); sigprocmask(SIG_BLOCK, &s, NULL); pthread_kill(pthread_self(), SIGUSR1); sigpending(&s); printf("%x\n", s); exit(0); } $ gcc -pthread thr1.c $ ./a.out 0 $ gcc -lthr thr1.c $ ./a.out 20000000 $ This might (or might not) be related to the other threading issues with GHC on FreeBSD. Do you think we should link with -lthr by default on FreeBSD? This would be a trivial change to make, and given that GHC has its own lightweight threading runtime, we probably aren't getting much from having the KSE-based threading implementation anyway. Cheers, Simon

2 2

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

11 Aug '06

Reilly, > ... this shouldn't prohibit linking > GMP in dynamically, should it? It's just a C library and GCC should > happily generate relocatable code. As a dynamically linked library, > there should be no tainting issues to worry about even if the > dynamically linked code is shipped with the executable. > > Am I missing something? Not at all. GHC builds the GMP library only if it is not already available on the system. On my Mac OS X computer it uses a dynamic library. I have not tried using gmp.dll on Windows since I have not built GHC on my Windows computer (it is a bit slow--a 600MHz P3). But the dynamic library form of GMP only solves the licensing problem (admittedly, for my purposes the worst of the bunch). It should be easy to change GMP's build settings so GHC is distributed with a dynamic GMP library. The other problem is that GMP has a mechanism to let the user determine its memory allocator, with the caveat that only one allocator can be used by a single program. GHC configures GMP to use GHC's RTS-GC for allocation so GHC-compiled programs can't interface with GHC separately. (This would not be such a big problem for general programs but C-Haskell cryptographic or scientific programs that might benefit from GMP's additional functionality would suffer.) On a side note, if you have been reading this user-list recently it seems that programmers (including myself, I guess) do not want to have to package a dynamic library (GMP) with programs compiled with GHC--a particularly irksome task if your Haskell program doesn't even *use* Integer. Not only do users have to package the separate dll, they also have to package a notice of the GMP copyright along with the binary. Just today Einar Karttunen mentioned that: >> * "This product includes software developed by the OpenSSL Project >> * for use in the OpenSSL Toolkit (http://www.openssl.org/)". >> >> All developers would have to do is include the acknowledgment stated >> above. > ... > ps. personally I don't think the advertising clause is bad, but > I think it is bad to force it on other users. Einar does have a good point, here. Personally speaking, such packaging and licensing stuff is o.k. for free software but for a clean commercial distribution it would be a bad thing; a reason to choose not to use GHC (or nhc98, for that matter). Best regards, Peter

1 0

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