I have tried to start my journey into Haskell web development tonight, but I seem to have hit a few snags. I'm on a Mac, using OS X 10.7.3, with ghc 7.4.1 installed via homebrew, and cabal-install-0.14.0 installed from source.
On a completely clean ghc install (i.e. after removing ~/.ghc and ~/.cabal), an attempt at: "cabal install yesod-platform" failed, due to language-javascript requiring a version of happy >= 1.18.5 but could not be found. Interestingly, installing happy by itself installs 1.18.9. Attempting an install of the yesod-platform after that seemed to work like a charm.
I then followed the instructions to create a scaffolded site via "yesod init", specifying sqlite as my database. Trying to do "yesod devel" on my site complained about persistence-sqlite missing, which was trivial to fix -- I assume that this is not installed when doing the yesod-platform because there are multiple options available. Once that was done, I tried to do the "yesod devel" again, only to be met with:
> yesod devel
Yesod devel server. Press ENTER to quit Resolving dependencies... Configuring demo-0.0.0... Rebuilding application... Building demo-0.0.0... Preprocessing library demo-0.0.0... Registering demo-0.0.0... Starting development server: runghc -package-confdist/package.conf.inplace devel.hs Starting devel application Devel application launched: http://localhost:3000 Exit code: ExitFailure 11
Did I miss something along the way? Is there any other debugging information I can provide?
This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
to make a smaller test case, or to find out more about why this
happens. If you do, please report, perhaps we can narrow it down to
open a ticket.
The only fix I've found is downgrading to GHC 7.0.4, a few weeks ago
the latest STABLE snapshots still had this problem, so unless we can
find this soon, this will probably be a problem in the next Haskell
platform release.
On Fri, May 4, 2012 at 7:37 AM, Luite Stegeman <stege...@gmail.com> wrote:
> On Fri, May 4, 2012 at 4:25 AM, Daniel Santa Cruz <dstc...@gmail.com> wrote:
> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
> to make a smaller test case, or to find out more about why this
> happens. If you do, please report, perhaps we can narrow it down to
> open a ticket.
> The only fix I've found is downgrading to GHC 7.0.4, a few weeks ago
> the latest STABLE snapshots still had this problem, so unless we can
> find this soon, this will probably be a problem in the next Haskell
> platform release.
> luite
Just to confirm: does this issue only exist on Mac? I just tested on a
Linux machine (LMDE 64-bit) with no issues.
On Fri, May 4, 2012 at 1:20 PM, Michael Snoyman <mich...@snoyman.com> wrote:
> Just to confirm: does this issue only exist on Mac? I just tested on a
> Linux machine (LMDE 64-bit) with no issues.
Yes, mac only, possibly only 64 bit. (System here: OS X 10.7.3, 64 bit
GHC, xcode 4.3 with llvm-gcc i686-apple-darwin11-llvm-gcc-4.2 (GCC)
4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) )
I recommend using a VM (not just for Haskell, but anything you would
deploy to Linux) on Mac if you have 8G of memory (and can easily spare
some for your VMs). When the new Haskell Platform comes out I want to
create a downloadable VM.
On Fri, May 4, 2012 at 5:54 AM, Luite Stegeman <stege...@gmail.com> wrote:
> On Fri, May 4, 2012 at 1:20 PM, Michael Snoyman <mich...@snoyman.com> wrote:
>> Just to confirm: does this issue only exist on Mac? I just tested on a
>> Linux machine (LMDE 64-bit) with no issues.
> Yes, mac only, possibly only 64 bit. (System here: OS X 10.7.3, 64 bit
> GHC, xcode 4.3 with llvm-gcc i686-apple-darwin11-llvm-gcc-4.2 (GCC)
> 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) )
While that might be a good short term solution to the problem, and good
general advice for making sure code runs smoothly on the production server,
it's not a good long term response to this problem. Mac users should be
able to run Yesod locally. Hopefully our GSoC project will help fix this,
but if anyone running a Mac has time to try and isolate this bug, I'd
appreciate it.
On May 4, 2012 4:07 PM, "Greg Weber" <g...@gregweber.info> wrote:
> I recommend using a VM (not just for Haskell, but anything you would
> deploy to Linux) on Mac if you have 8G of memory (and can easily spare
> some for your VMs). When the new Haskell Platform comes out I want to
> create a downloadable VM.
> Greg Weber
> On Fri, May 4, 2012 at 5:54 AM, Luite Stegeman <stege...@gmail.com> wrote:
> > On Fri, May 4, 2012 at 1:20 PM, Michael Snoyman <mich...@snoyman.com>
> wrote:
> >> Just to confirm: does this issue only exist on Mac? I just tested on a
> >> Linux machine (LMDE 64-bit) with no issues.
> > Yes, mac only, possibly only 64 bit. (System here: OS X 10.7.3, 64 bit
> > GHC, xcode 4.3 with llvm-gcc i686-apple-darwin11-llvm-gcc-4.2 (GCC)
> > 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) )
On Fri, May 4, 2012 at 3:34 PM, Michael Snoyman <mich...@snoyman.com> wrote:
> While that might be a good short term solution to the problem, and good
> general advice for making sure code runs smoothly on the production server,
> it's not a good long term response to this problem. Mac users should be able
> to run Yesod locally. Hopefully our GSoC project will help fix this, but if
> anyone running a Mac has time to try and isolate this bug, I'd appreciate
> it.
I've already spent some time on this, but so far without any success.
I've tried gdb and valgrind (the latter needs some extra syscall
wrappers to support the ghc runtime on 64 bit OS X), but haven't been
able to narrow it down in any way. Does anyone have suggestions for
strategies or tools that might help here? Valgrind reports some
invalid memory accesses, but haskell being haskell, getting
information about where and why is a whole different matter...
> On Fri, May 4, 2012 at 3:34 PM, Michael Snoyman <mich...@snoyman.com>
wrote:
> > While that might be a good short term solution to the problem, and good
> > general advice for making sure code runs smoothly on the production
server,
> > it's not a good long term response to this problem. Mac users should be
able
> > to run Yesod locally. Hopefully our GSoC project will help fix this,
but if
> > anyone running a Mac has time to try and isolate this bug, I'd
appreciate
> > it.
> I've already spent some time on this, but so far without any success.
> I've tried gdb and valgrind (the latter needs some extra syscall
> wrappers to support the ghc runtime on 64 bit OS X), but haven't been
> able to narrow it down in any way. Does anyone have suggestions for
> strategies or tools that might help here? Valgrind reports some
> invalid memory accesses, but haskell being haskell, getting
> information about where and why is a whole different matter...
> luite
I have no advice, and without a Mac, can't really help too much. It might
be worth turning to the cafe or the GHC team for some advice at this point.
At the very least, it's good if they know that there's some regression in
the 7.4 series.
On Fri, May 4, 2012 at 6:39 AM, Luite Stegeman <stege...@gmail.com> wrote:
> On Fri, May 4, 2012 at 3:34 PM, Michael Snoyman <mich...@snoyman.com> wrote:
>> While that might be a good short term solution to the problem, and good
>> general advice for making sure code runs smoothly on the production server,
>> it's not a good long term response to this problem. Mac users should be able
>> to run Yesod locally. Hopefully our GSoC project will help fix this, but if
>> anyone running a Mac has time to try and isolate this bug, I'd appreciate
>> it.
> I've already spent some time on this, but so far without any success.
> I've tried gdb and valgrind (the latter needs some extra syscall
> wrappers to support the ghc runtime on 64 bit OS X), but haven't been
> able to narrow it down in any way. Does anyone have suggestions for
> strategies or tools that might help here? Valgrind reports some
> invalid memory accesses, but haskell being haskell, getting
> information about where and why is a whole different matter...
On Fri, May 4, 2012 at 3:44 PM, Michael Snoyman <mich...@snoyman.com> wrote:
> I have no advice, and without a Mac, can't really help too much. It might be
> worth turning to the cafe or the GHC team for some advice at this point. At
> the very least, it's good if they know that there's some regression in the
> 7.4 series.
I've asked/mentioned this in the #ghc irc channel a few times but
without any results (Simon Marlow is often there). No ticket yet
because the test case (default yesod scaffold) isn't terribly useful
for tracking down the bug.
With profiling there should be some kind of information on how the
program is executing that is always present. It should be possible to
log function calls while the program is running. This is all
theoretical though, I haven't tried it. Probably I am giving really
bad advice :)
On Fri, May 4, 2012 at 7:17 AM, Luite Stegeman <stege...@gmail.com> wrote:
> On Fri, May 4, 2012 at 3:49 PM, Greg Weber <g...@gregweber.info> wrote:
>> Have you tried the new profiling-based stack trace feature? I have not yet.
> Haven't tried it yet, but i thought that would only help with stack
> traces from haskell exceptions, not with segfaults. Do you know if it
> should?
On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able > to make a smaller test case, or to find out more about why this > happens. If you do, please report, perhaps we can narrow it down to > open a ticket.
This is the exact issue I'm trying to resolve now.
I've built 4 different versions of GHC as updating GHC seemed to
resolve it in the past. The problem seems to be related to runghc on
devel.hs as I was able to launch the server fine when I used the
binary. I'll be more than happy to help resolve this as I love Yesod
when it's all working smoothly, but it is a real pain when a large
chunk of time is taken up dealing with this issue.
On Wed, Jun 20, 2012 at 4:34 PM, srhb <sbrofe...@gmail.com> wrote:
> Hi,
> On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
>> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
>> to make a smaller test case, or to find out more about why this
>> happens. If you do, please report, perhaps we can narrow it down to
>> open a ticket.
I'd like to get this resolved as well, but I have no access to a Mac
system, and even if I did, my complete lack of experience on that platform
probably wouldn't help.
Here's a simple question: are you able to compile and run devel.hs?
Michael
On Wed, Jun 20, 2012 at 11:54 AM, Lyndon Maydwell <maydw...@gmail.com>wrote:
> This is the exact issue I'm trying to resolve now.
> I've built 4 different versions of GHC as updating GHC seemed to
> resolve it in the past. The problem seems to be related to runghc on
> devel.hs as I was able to launch the server fine when I used the
> binary. I'll be more than happy to help resolve this as I love Yesod
> when it's all working smoothly, but it is a real pain when a large
> chunk of time is taken up dealing with this issue.
> On Wed, Jun 20, 2012 at 4:34 PM, srhb <sbrofe...@gmail.com> wrote:
> > Hi,
> > On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
> >> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
> >> to make a smaller test case, or to find out more about why this
> >> happens. If you do, please report, perhaps we can narrow it down to
> >> open a ticket.
On Wed, Jun 20, 2012 at 5:51 PM, Michael Snoyman <mich...@snoyman.com> wrote:
> I'd like to get this resolved as well, but I have no access to a Mac system,
> and even if I did, my complete lack of experience on that platform probably
> wouldn't help.
> Here's a simple question: are you able to compile and run devel.hs?
> Michael
> On Wed, Jun 20, 2012 at 11:54 AM, Lyndon Maydwell <maydw...@gmail.com>
> wrote:
>> This is the exact issue I'm trying to resolve now.
>> I've built 4 different versions of GHC as updating GHC seemed to
>> resolve it in the past. The problem seems to be related to runghc on
>> devel.hs as I was able to launch the server fine when I used the
>> binary. I'll be more than happy to help resolve this as I love Yesod
>> when it's all working smoothly, but it is a real pain when a large
>> chunk of time is taken up dealing with this issue.
>> On Wed, Jun 20, 2012 at 4:34 PM, srhb <sbrofe...@gmail.com> wrote:
>> > Hi,
>> > On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
>> >> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
>> >> to make a smaller test case, or to find out more about why this
>> >> happens. If you do, please report, perhaps we can narrow it down to
>> >> open a ticket.
On Wed, Jun 20, 2012 at 6:57 AM, Lyndon Maydwell <maydw...@gmail.com> wrote:
> I seem to recall being able to do this earlier today, although I can't
> confirm as I've blown away my Haskell install again.
Yeh, don't tell anyone but Haskell's package system (cabal et al.) really
sucks. I don't think the "reinventing the wheel" approach is valid here,
scale is showing that despite of "programming / sysadmin-on-spare-time",
the package system has to be reviewed in order to keep "growing" on a
"stable manner". That said (as the *ssh*le of Torvalds said), I find darcs
way better than git (it's more bazaar-esque), so it's surprising (to me)
that having a such a good vcs they didn't spoke between them. (Heading to
AR (tomorrow) - will see if I can make it for Rants Friday).
On Wed, Jun 20, 2012 at 6:10 PM, Rodrigo Gadea <rodrigo.ga...@gmail.com> wrote:
> On Wed, Jun 20, 2012 at 6:57 AM, Lyndon Maydwell <maydw...@gmail.com> wrote:
>> I seem to recall being able to do this earlier today, although I can't
>> confirm as I've blown away my Haskell install again.
> Yeh, don't tell anyone but Haskell's package system (cabal et al.) really
> sucks. I don't think the "reinventing the wheel" approach is valid here,
> scale is showing that despite of "programming / sysadmin-on-spare-time", the
> package system has to be reviewed in order to keep "growing" on a "stable
> manner". That said (as the *ssh*le of Torvalds said), I find darcs way
> better than git (it's more bazaar-esque), so it's surprising (to me) that
> having a such a good vcs they didn't spoke between them. (Heading to AR
> (tomorrow) - will see if I can make it for Rants Friday).
> On Wed, Jun 20, 2012 at 6:10 PM, Rodrigo Gadea <rodrigo.ga...@gmail.com>
> wrote:
> > On Wed, Jun 20, 2012 at 6:57 AM, Lyndon Maydwell <maydw...@gmail.com>
> wrote:
> >> I seem to recall being able to do this earlier today, although I can't
> >> confirm as I've blown away my Haskell install again.
> > Yeh, don't tell anyone but Haskell's package system (cabal et al.) really
> > sucks. I don't think the "reinventing the wheel" approach is valid here,
> > scale is showing that despite of "programming / sysadmin-on-spare-time",
> the
> > package system has to be reviewed in order to keep "growing" on a "stable
> > manner". That said (as the *ssh*le of Torvalds said), I find darcs way
> > better than git (it's more bazaar-esque), so it's surprising (to me) that
> > having a such a good vcs they didn't spoke between them. (Heading to AR
> > (tomorrow) - will see if I can make it for Rants Friday).
On Wed, Jun 20, 2012 at 10:48 PM, Michael Snoyman <mich...@snoyman.com> wrote:
> Could you try removing the forkIO call in `main` in devel.hs? Also, what
> happens if you keep the file the same, but compile with -threaded?
> On Wed, Jun 20, 2012 at 5:41 PM, Lyndon Maydwell <maydw...@gmail.com> wrote:
>> It looks like I probably recalled incorrectly :)
>> The compiled version of devel.hs has the same issue, although there is
>> no error code listed on exit.
>> Example session:
>> lyndon@endpin ~/temp/Foo yesod devel
>> Yesod devel server. Press ENTER to quit
>> Resolving dependencies...
>> Configuring Foo-0.0.0...
>> Rebuilding application...
>> Building Foo-0.0.0...
>> Preprocessing library Foo-0.0.0...
>> [1 of 8] Compiling Settings.Development ( Settings/Development.hs,
>> dist/build/Settings/Development.o )
>> [2 of 8] Compiling Model ( Model.hs, dist/build/Model.o )
>> [3 of 8] Compiling Settings ( Settings.hs, dist/build/Settings.o )
>> [4 of 8] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs,
>> dist/build/Settings/StaticFiles.o )
>> [5 of 8] Compiling Foundation ( Foundation.hs,
>> dist/build/Foundation.o )
>> [6 of 8] Compiling Import ( Import.hs, dist/build/Import.o )
>> [7 of 8] Compiling Handler.Home ( Handler/Home.hs,
>> dist/build/Handler/Home.o )
>> [8 of 8] Compiling Application ( Application.hs,
>> dist/build/Application.o )
>> Registering Foo-0.0.0...
>> Starting development server: runghc
>> -package-confdist/package.conf.inplace devel.hs
>> Starting devel application
>> Devel application launched: http://localhost:3000 >> Exit code: ExitFailure 11
>> On Wed, Jun 20, 2012 at 6:10 PM, Rodrigo Gadea <rodrigo.ga...@gmail.com>
>> wrote:
>> > On Wed, Jun 20, 2012 at 6:57 AM, Lyndon Maydwell <maydw...@gmail.com>
>> > wrote:
>> >> I seem to recall being able to do this earlier today, although I can't
>> >> confirm as I've blown away my Haskell install again.
>> > Yeh, don't tell anyone but Haskell's package system (cabal et al.)
>> > really
>> > sucks. I don't think the "reinventing the wheel" approach is valid here,
>> > scale is showing that despite of "programming / sysadmin-on-spare-time",
>> > the
>> > package system has to be reviewed in order to keep "growing" on a
>> > "stable
>> > manner". That said (as the *ssh*le of Torvalds said), I find darcs way
>> > better than git (it's more bazaar-esque), so it's surprising (to me)
>> > that
>> > having a such a good vcs they didn't spoke between them. (Heading to AR
>> > (tomorrow) - will see if I can make it for Rants Friday).
Not sure if this helps, but I only got this error with the 64bit
version of the Haskell Platfom (2012.2.0.0), when I switched to the
32bits version the problem stopped.
I am a Haskell newbie, but if there are any tests you want me to do
I'll be happy to help. I am using a MacBookPro Core2 duo, 4GB with OSX
10.7 (lion).
On Wed, Jun 20, 2012 at 11:51 AM, Lyndon Maydwell <maydw...@gmail.com> wrote:
> ForkIO and -threaded changes don't seem to have had any impact.
> On Wed, Jun 20, 2012 at 10:48 PM, Michael Snoyman <mich...@snoyman.com> wrote:
>> Could you try removing the forkIO call in `main` in devel.hs? Also, what
>> happens if you keep the file the same, but compile with -threaded?
>> On Wed, Jun 20, 2012 at 5:41 PM, Lyndon Maydwell <maydw...@gmail.com> wrote:
>>> It looks like I probably recalled incorrectly :)
>>> The compiled version of devel.hs has the same issue, although there is
>>> no error code listed on exit.
>>> Example session:
>>> lyndon@endpin ~/temp/Foo yesod devel
>>> Yesod devel server. Press ENTER to quit
>>> Resolving dependencies...
>>> Configuring Foo-0.0.0...
>>> Rebuilding application...
>>> Building Foo-0.0.0...
>>> Preprocessing library Foo-0.0.0...
>>> [1 of 8] Compiling Settings.Development ( Settings/Development.hs,
>>> dist/build/Settings/Development.o )
>>> [2 of 8] Compiling Model ( Model.hs, dist/build/Model.o )
>>> [3 of 8] Compiling Settings ( Settings.hs, dist/build/Settings.o )
>>> [4 of 8] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs,
>>> dist/build/Settings/StaticFiles.o )
>>> [5 of 8] Compiling Foundation ( Foundation.hs,
>>> dist/build/Foundation.o )
>>> [6 of 8] Compiling Import ( Import.hs, dist/build/Import.o )
>>> [7 of 8] Compiling Handler.Home ( Handler/Home.hs,
>>> dist/build/Handler/Home.o )
>>> [8 of 8] Compiling Application ( Application.hs,
>>> dist/build/Application.o )
>>> Registering Foo-0.0.0...
>>> Starting development server: runghc
>>> -package-confdist/package.conf.inplace devel.hs
>>> Starting devel application
>>> Devel application launched: http://localhost:3000 >>> Exit code: ExitFailure 11
>>> On Wed, Jun 20, 2012 at 6:10 PM, Rodrigo Gadea <rodrigo.ga...@gmail.com>
>>> wrote:
>>> > On Wed, Jun 20, 2012 at 6:57 AM, Lyndon Maydwell <maydw...@gmail.com>
>>> > wrote:
>>> >> I seem to recall being able to do this earlier today, although I can't
>>> >> confirm as I've blown away my Haskell install again.
>>> > Yeh, don't tell anyone but Haskell's package system (cabal et al.)
>>> > really
>>> > sucks. I don't think the "reinventing the wheel" approach is valid here,
>>> > scale is showing that despite of "programming / sysadmin-on-spare-time",
>>> > the
>>> > package system has to be reviewed in order to keep "growing" on a
>>> > "stable
>>> > manner". That said (as the *ssh*le of Torvalds said), I find darcs way
>>> > better than git (it's more bazaar-esque), so it's surprising (to me)
>>> > that
>>> > having a such a good vcs they didn't spoke between them. (Heading to AR
>>> > (tomorrow) - will see if I can make it for Rants Friday).
> Not sure if this helps, but I only got this error with the 64bit
> version of the Haskell Platfom (2012.2.0.0), when I switched to the
> 32bits version the problem stopped.
> I am a Haskell newbie, but if there are any tests you want me to do
> I'll be happy to help. I am using a MacBookPro Core2 duo, 4GB with OSX
> 10.7 (lion).
> []s,
> On Wed, Jun 20, 2012 at 11:51 AM, Lyndon Maydwell <maydw...@gmail.com>
> wrote:
> > ForkIO and -threaded changes don't seem to have had any impact.
> > On Wed, Jun 20, 2012 at 10:48 PM, Michael Snoyman <mich...@snoyman.com>
> wrote:
> >> Could you try removing the forkIO call in `main` in devel.hs? Also, what
> >> happens if you keep the file the same, but compile with -threaded?
> >> On Wed, Jun 20, 2012 at 5:41 PM, Lyndon Maydwell <maydw...@gmail.com>
> wrote:
> >>> It looks like I probably recalled incorrectly :)
> >>> The compiled version of devel.hs has the same issue, although there is
> >>> no error code listed on exit.
> >>> On Wed, Jun 20, 2012 at 6:10 PM, Rodrigo Gadea <
> rodrigo.ga...@gmail.com>
> >>> wrote:
> >>> > On Wed, Jun 20, 2012 at 6:57 AM, Lyndon Maydwell <maydw...@gmail.com
> >>> > wrote:
> >>> >> I seem to recall being able to do this earlier today, although I
> can't
> >>> >> confirm as I've blown away my Haskell install again.
> >>> > Yeh, don't tell anyone but Haskell's package system (cabal et al.)
> >>> > really
> >>> > sucks. I don't think the "reinventing the wheel" approach is valid
> here,
> >>> > scale is showing that despite of "programming /
> sysadmin-on-spare-time",
> >>> > the
> >>> > package system has to be reviewed in order to keep "growing" on a
> >>> > "stable
> >>> > manner". That said (as the *ssh*le of Torvalds said), I find darcs
> way
> >>> > better than git (it's more bazaar-esque), so it's surprising (to me)
> >>> > that
> >>> > having a such a good vcs they didn't spoke between them. (Heading to
> AR
> >>> > (tomorrow) - will see if I can make it for Rants Friday).
> On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able > to make a smaller test case, or to find out more about why this > happens. If you do, please report, perhaps we can narrow it down to > open a ticket.
On Fri, Jun 22, 2012 at 3:01 PM, Vincent Ambo <taz...@googlemail.com> wrote:
> This error only happens when using the 64bit version of GHC.
> Am 20.06.2012 um 10:34 schrieb srhb:
> Hi,
> On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
>> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
>> to make a smaller test case, or to find out more about why this
>> happens. If you do, please report, perhaps we can narrow it down to
>> open a ticket.
Based on everything I've heard, it *is* a GHC issue. I think Luite has
said as much in the past. The problem is that we don't have a simple
test case to reproduce. I do think that it would be worthwhile filing
a report with GHC and explain that we haven't been able to whittle the
problem down yet, and see if they have any advice.
On Fri, Jun 22, 2012 at 10:31 AM, Lyndon Maydwell <maydw...@gmail.com> wrote:
> I am also running a 64 bit GHC.
> I'm leaning more towards GHC issue than Yesod issue at this point but
> that's just a guess :)
> On Fri, Jun 22, 2012 at 3:01 PM, Vincent Ambo <taz...@googlemail.com> wrote:
>> This error only happens when using the 64bit version of GHC.
>> Am 20.06.2012 um 10:34 schrieb srhb:
>> Hi,
>> On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
>>> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
>>> to make a smaller test case, or to find out more about why this
>>> happens. If you do, please report, perhaps we can narrow it down to
>>> open a ticket.
