getMBlocks
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 plans and status
On Mon, 2006-08-07 at 20:38 +0100, Chris Kuklewicz wrote: > skaller wrote: > > Wouldn't it be nice to use Ville Laurikari's TRE > > package instead of PCRE? > > > > [It is also Posix compliant and drop in replacement for > > gnu regex .. as well as supporting nice extensions] > > > > It is possible to add support for more backends. > The more the merrier, no need to replace anything. > I have never heard of TRE before. TRE is actually based on mathematics. > I could use darcs or darwinports to install libtre. > Looking at the API, I see that it is very easy to add as a backend. > TRE is LGPL, which PCRE is BSD. Appeal to Ville to change the licence :) > TRE is not a replacement for PCRE. Who want's a replacement? PCRE is junk. Check the papers, cached here: http://felix.sf.net/papers/regex-submatch.ps http://felix.sf.net/papers/spire2000-tnfa.ps http://felix.sf.net/papers/greedy.pdf -- John Skaller Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 plans and status
skaller wrote: On Mon, 2006-08-07 at 17:07 +0100, Chris Kuklewicz wrote: Would a new and expanded Regex package (Test.Regex.Lazy) be something that could be included in the 6.6.0 libraries? What is the best practice for getting it included? It still supports a wrapped Posix regex backend, but also include a PCRE wrapper and pure haskell backends and work efficiently on both String and ByteString. It runs, has an increasing amount of Haddock documentation, some HUnit tests, and some new QuickCheck tests are almost done. Wouldn't it be nice to use Ville Laurikari's TRE package instead of PCRE? [It is also Posix compliant and drop in replacement for gnu regex .. as well as supporting nice extensions] It is possible to add support for more backends. The more the merrier, no need to replace anything. I have never heard of TRE before. I could use darcs or darwinports to install libtre. Looking at the API, I see that it is very easy to add as a backend. TRE is LGPL, which PCRE is BSD. TRE is not a replacement for PCRE. TRE claims to be a replacement for Posix regex except for collating elements. But Posix regex is already in GHC's Text.Regex(.Posix) modules. So I would say: I welcome contribution of Text.Regex.Lib.WrapTRE,StringTRE,ByteStringTRE but getting the current library into GHC-6.6 would be more important. Note that Text.Regex.Lazy has two darcs repositories: http://evenmere.org/~chrisk/trl/stable/ http://evenmere.org/~chrisk/trl/head/ -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 plans and status
On Mon, 2006-08-07 at 17:07 +0100, Chris Kuklewicz wrote: > Would a new and expanded Regex package (Test.Regex.Lazy) be something that > could > be included in the 6.6.0 libraries? What is the best practice for getting it > included? > > It still supports a wrapped Posix regex backend, but also include a PCRE > wrapper > and pure haskell backends and work efficiently on both String and ByteString. > > It runs, has an increasing amount of Haddock documentation, some HUnit tests, > and some new QuickCheck tests are almost done. Wouldn't it be nice to use Ville Laurikari's TRE package instead of PCRE? [It is also Posix compliant and drop in replacement for gnu regex .. as well as supporting nice extensions] -- John Skaller Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 plans and status
Would a new and expanded Regex package (Test.Regex.Lazy) be something that could be included in the 6.6.0 libraries? What is the best practice for getting it included? It still supports a wrapped Posix regex backend, but also include a PCRE wrapper and pure haskell backends and work efficiently on both String and ByteString. It runs, has an increasing amount of Haddock documentation, some HUnit tests, and some new QuickCheck tests are almost done. -- Chris Simon Marlow wrote: 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=reopened&milestone=6.6&order=priority 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Graphics library very slow
On Mon, 2006-08-07 at 16:12 +0100, Simon Peyton-Jones wrote: > By "this code is currently broken", I'm sure you are right, but which > code you mean exactly? The Win32 binding for GHC? Or the Hugs Graphics > Library (HGL) implementation for GHC? The HGL for GHC and therefore also the current SOE impl which is based upon HGL. > It'd be good to have a Trac bug report, specifying as precisely as > possible what is broken. I am afraid that I do not know what is wrong with it, I've just heard tell from many users and other developers that it is broken in some way. Paul Hudak told me that he had discussed the state of it with Simon Marlow and that neither of them were keen on fixing the Win32 impl of HGL because debugging it has proved to be a nightmare in the past. Hence Paul is currently evaluating an alternative implementation of SOE based on Gtk2Hs (this also provides some other benefits like anti-aliased rendering). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Graphics library very slow
By "this code is currently broken", I'm sure you are right, but which code you mean exactly? The Win32 binding for GHC? Or the Hugs Graphics Library (HGL) implementation for GHC? It'd be good to have a Trac bug report, specifying as precisely as possible what is broken. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Duncan Coutts | Sent: 07 August 2006 14:56 | To: Vyacheslav Akhmechet | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Graphics library very slow | | On Mon, 2006-08-07 at 09:04 -0400, Vyacheslav Akhmechet wrote: | > The latest stable release seems to have some sort of a problem with | > the graphics library (the general one as well as the wrapper used in | > SOE). Opening a window takes more than a couple of minutes (on Windows | > XP). When I run an identical version of the code through Hugs, the | > window opens immediately. Am I doing something wrong? | | Unfortunately this code is currently broken with GHC on windows. No one | has fixed it because the code is low level, ugly and few people | understand it. | | There is an alternative implementation of the SOE api based on Gtk2Hs. | This is currently being reviewed by the original SOE author. The aim is | to make it match the original semantics as closely as possible. The code | is currently available in the development version of Gtk2Hs. | | Duncan | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.6 plans and status
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=reopened&milestone=6.6&order=priority 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4.3 on FreeBSD
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
#include
#include
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
2000
$
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Graphics library very slow
On Mon, 2006-08-07 at 09:04 -0400, Vyacheslav Akhmechet wrote: > The latest stable release seems to have some sort of a problem with > the graphics library (the general one as well as the wrapper used in > SOE). Opening a window takes more than a couple of minutes (on Windows > XP). When I run an identical version of the code through Hugs, the > window opens immediately. Am I doing something wrong? Unfortunately this code is currently broken with GHC on windows. No one has fixed it because the code is low level, ugly and few people understand it. There is an alternative implementation of the SOE api based on Gtk2Hs. This is currently being reviewed by the original SOE author. The aim is to make it match the original semantics as closely as possible. The code is currently available in the development version of Gtk2Hs. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Graphics library very slow
The latest stable release seems to have some sort of a problem with the graphics library (the general one as well as the wrapper used in SOE). Opening a window takes more than a couple of minutes (on Windows XP). When I run an identical version of the code through Hugs, the window opens immediately. Am I doing something wrong? Thanks, - Slava. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: default declarations
It's arguably a bug in ghci -- but it's not quite clear what the "right" answer is. Suppose you are in the top level scope of two modules with differing default declarations. So GHCi uses the "default default" for the top level, always. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Daniel Fischer | Sent: 06 August 2006 01:11 | To: GHC Users | Subject: default declarations | | Hi, | | apparently ghci doesn't take default declarations into account. | Inspired by a question on the hugs-users list I wrote | | module BoolNum where | | default (Bool, Rational) | | instance Num Bool where | (+) = (/=) | (-) = (/=) | (*) = (&&) | negate x = x | abs x = x | signum x = x | fromInteger = odd | | | and in hugs, as expected I get | BoolNum> 1 | True | | but in ghci, it's | *BoolNum> 1 | 1, | | no defaulting apparently takes pkace. | | Why? | | Bug or feature ? | | Cheers, Daniel | -- | | "In My Egotistical Opinion, most people's C programs should be | indented six feet downward and covered with dirt." | -- Blair P. Houghton | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
