Is there any way to have a "moderate first comment by new submitter"
policy for trac, to avoid the kind of ticket spam we have at the moment?
They seem to have started commenting on existing tickets now (#4510),
which could turn into a real mess really quickly, if the currently known
spam account
Hi folks,
If you're a postgraduate and would like to spend 12 weeks in Cambridge
working on a GHC or Haskell-related project, then apply for an
internship: we have open slots starting in July this year and later.
We've had many successful intern projects over the years. Lots more
informatio
This is laptop so 99% no ECC RAM, however it looks like apple provides
some facility to test memory in single user mode...
http://www.command-tab.com/2008/01/11/how-to-test-ram-under-mac-os-x/
If that's not reliable, then have a look at http://www.memtest.org/ if
this support your hardware a
On Fri, Jan 28, 2011 at 2:44 PM, Johan Tibell wrote:
> My computer dies a horrible death (i.e. kernel panic) whenever I build
> GHC from HEAD (currently using the "quickest" build configuration).
> Anyone had the same problem in the past? Any workarounds?
Here are some details:
Interval Since L
I'd check RAM in your computer. Build process puts heavy load on your machine
so...
pavel
On 28.01.2011, at 16:44, Johan Tibell wrote:
> Hi,
>
> My computer dies a horrible death (i.e. kernel panic) whenever I build
> GHC from HEAD (currently using the "quickest" build configuration).
> Anyone
Hi,
My computer dies a horrible death (i.e. kernel panic) whenever I build
GHC from HEAD (currently using the "quickest" build configuration).
Anyone had the same problem in the past? Any workarounds?
Johan
___
Glasgow-haskell-users mailing list
Glasgo
On Friday 28 January 2011 11:40:33, Simon Marlow wrote:
> I think you may have had an encounter with this bug:
>
> http://hackage.haskell.org/trac/ghc/ticket/4924
>
That seems not unlikely. the offending Main contained a couple of near-
identical loops, and that bug doesn't reliably occur (I co
On 27/01/2011 20:04, Volker Wysk wrote:
I need to get the file descriptor, which is encapsulated inside a handle.
handleToFd gets it, but the fd is closed. Is it possible to extract the fd
from the handle, without modifying the handle?
I think you mean the *Handle* is closed, not the FD, right?
On 27/01/2011 11:45, Daniel Fischer wrote:
While tuning some code, the test programme suddenly started producing stack
overflows.
Reverting the code to a previous version did not revert that behaviour,
code that previously produced a well-behaved binary now produced stack
overflowing ones.
But on
Right; it's a bug all right. Happily, I committed a major patch two weeks ago,
which cures the bug (I checked). The fix will be in 7.0.2. Meanwhile, if you
can build the HEAD or get a development snapshot, you should be good to do.
Thanks for reporting this
Simon
From: glasgow-haskell-users-
10 matches
Mail list logo