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 me
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 pos
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, bu
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 als
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 efficient
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 S
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
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
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 tra
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 i
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 immediatel
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 PROTEC
12 matches
Mail list logo
