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
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 imp
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 ea
(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
Simon Marlow wrote:
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.
Using -lthr instead of -pthread, I completed a test run on the dual proc box:
OVERALL SUMMARY for test run started at Tue Aug 8 09:21:49
Simon Marlow wrote:
What tool(s) did you use to obtain this figure?
This particular figure was gathered using perfmon logs collecting once
per second from my application, while running in WinDbg to break on
getMBlocks(). The particular memory variables tracked are "Private
Bytes" and "Wor
> $ghc-pkg --where-from ParseError
> package parsec: defining modules: Text.ParserCombinators.Parsec.Error,
> Text.ParserCombinators.Parsec
>
> ?
This is what I've done by now... It took me some days to notice that the
./ghc-pkg symlinks to ghc-pkg-6.5 which calls the ghc-pkg from /usr/lib/.
So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.
In the code for ByteString's 'writeStrUp/Dn' functions we're doing
Simon Marlow wrote:
Chris Kuklewicz wrote:
That could work well. It would not involved too much pulling apart.
Once small quirk is there is the old Text.Regex API and a new
JRegex-style API.
Is it possible to provide both? Perhaps deprecating the current API?
It is possible to provide t
Chris Kuklewicz wrote:
That could work well. It would not involved too much pulling apart.
Once small quirk is there is the old Text.Regex API and a new
JRegex-style API.
Is it possible to provide both? Perhaps deprecating the current API?
A "default" backend has to be dependably present.
Simon Marlow wrote:
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?
Since we're aiming to include fewer libraries under the GHC umbrella,
not more,
Vyacheslav Akhmechet wrote:
I apologize if this question has been asked before, but I couldn't
find an FAQ or the answer online.
Does Visual Haskell have support for evaluating expressions? I tried a
few things (like highlighting an expression, rightclicking, and
looking for "evaluate" option)
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?
It'd be good to have a Trac bug report, specifying as precisely as
possible what is br
Rich Fought wrote:
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 discov
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?
Since we're aiming to include fewer libraries under the GHC umbrella, not more,
this wouldn't be the
15 matches
Mail list logo
