On 15/05/2014 11:12, Herbert Valerio Riedel wrote:
Hello GHC devs,
While I refactored the ghc code base to declare LANGUAGE pragmas
locally, rather than via -X-flags on the GHC commandline, I've noticed
there were a couple of places where NondecreasingIndentation grammar was used.
What's the
On 28/05/2014 12:16, Edward Kmett wrote:
How hard /would/ it be to replace the global weak pointer lock with
something that scales better?
I'm looking at switching some of my older BDD code into Haskell.
To do so I'd love to be able to use an intuitive weak-pointer based
cache management
Please record the repro steps exactly, including the git hashes of any
repositories that you use. If it is a GC bug, the last thing we want is
for it to disappear, because then we lose the opportunity to find it.
If you could put the build steps into a script that we can run to
reproduce the
On 2014-05-29 at 09:17:58 +0200, Simon Marlow wrote:
While I refactored the ghc code base to declare LANGUAGE pragmas
locally, rather than via -X-flags on the GHC commandline, I've noticed
there were a couple of places where NondecreasingIndentation grammar was
used.
What's the current
I actually don't know that it would be the bottleneck if I ported it to
Haskell at this time, as lots of other things will change speed, and I may
lose for other reasons: The memory layout is less efficient, the cache
management overhead is higher, etc.
I do know that if I were to reintroduced a
Oops last time I checked I hadn't cherry-picked the #9078 fix. Retested
with that and it still segfaults.
Unfortunately we haven't found a smaller test case yet. We've been using
Vagrant for repeatable test runs for GHCJS in the past. Would a Vagrant
script for reproducing the crash be ok?
luite
On Thu, May 29, 2014 at 5:41 PM, Simon Marlow marlo...@gmail.com wrote:
Yeah, vagrant would be fine.
Do you have any FFI or other strange things in GHCJS that might
conceivably cause this?
Not in GHCJS itself as far as I know, but its dependency list is rather
long, unfortunately.
luite
Currently, most GHC API tests are not run on 'make fast',
ostensibly because linking against the GHC API can take a while.
I propose that change this, and run GHC API tests by default.
Reasons:
1. The GHC API is closely tied a lot of internal structure of GHC, so
it's very easy to make a change,
