You might want to take a look at
https://github.com/alphaHeavy/timeout-control/blob/master/System/Timeout/Control.hs#L72too,
though I'd guess it is subject to the same race condition. I have a
few other fixes (for dealing with lifted bracket iirc) I still need to
merge back from a private branch.
Would the SxS loader (with associated manifests, etc) work? I've used
it to support similar scenarios in a former job without any PE32
hacking. Unless things have changed recently, the APIs aren't super
well documented but they are supported and there are a handful of
tools for tracing the loader t
On Mon, Jul 16, 2012 at 12:26 PM, Tony Hannan wrote:
> I'm still seeing this problem in 7.4.2. Is there a workaround?
> I'm also on Snow Leopard and using 64-bit version.
If you grabbed the installer from
http://www.haskell.org/ghc/download_ghc_7_4_2 you'll need to build
your own locally... the n
On Thu, Jan 26, 2012 at 3:44 PM, Evan Laforge wrote:
> I'd think apple would care about linker performance... I'm even a
> little surprised Xcode doesn't have something better than a lightly
> hacked gnu ld.
Someone mentioned that it was on their wish-list at LLVM 2010 conference...
it's hinted
We're hitting something that looks similar with a Chan on 7.2.1, though
they might be related..
On Fri, Nov 11, 2011 at 4:52 AM, Simon Marlow wrote:
> Sorry, no. That one has a workaround: define your own fixIO:
>
> fixIO :: (a -> IO a) -> IO a
> fixIO k = do
>m <- newEmptyMVar
>ans <-
Any chance #5421 (<> in withMVar (reproducible, but with large test
case) could be backported to 7.2.2?
-n
On Sun, Nov 6, 2011 at 5:18 AM, Ian Lynagh wrote:
> 7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be
> worked around. Please let us know if you find any showstoppers
On Tue, Nov 8, 2011 at 11:28 PM, wrote:
>
> I don't agree that GHC's user interface should be optimized for newcomers
> to Haskell. GHC is an industrial-strength compiler with some very advanced
> features; the majority of its target audience is professional programmers.
> Let its interface reflec
For production debugging, I find printObj and friends to be rather useful...
and I wonder if it would be a good idea to make these part of the release
builds, instead of being relegated to -debug?
Alternatively, should these debugging functions be moved to a separate
library? I have some other hea
On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow wrote:
> Ideally you'd want the heap check in the primop to be aggregated into the
> calling function's heap check, and the primop should allocate directly from
> the heap instead of calling out to the RTS allocate(). All this is a bit
> much to expec
On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy
wrote:
> Max Bolingbroke wrote:
> > On 18 February 2011 01:18, Johan Tibell wrote:>
> It seems like a sufficient solution for your needs would be for us to
> > use the LTO support in LLVM to inline across module boundaries - in
> > particular
10 matches
Mail list logo
