Re: [GHC] #5804: Registration capture issue
#5804: Registration capture issue -+-- Reporter: st.kurilin| Owner: igloo Type: bug | Status: new Priority: normal| Milestone: _|_ Component: Compiler | Version: Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * owner: = igloo * difficulty: = Unknown * milestone: = _|_ Comment: Thanks for the report. I should let upstream know. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5804#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5840: Extend the supported environment sizes of vectorised closures
#5840: Extend the supported environment sizes of vectorised closures
--+-
Reporter: mukesh.tiwari | Owner: chak
Type: bug| Status: new
Priority: normal | Milestone:
Component: Data Parallel Haskell | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown|Testcase:
Blockedby: |Blocking:
Related: |
--+-
Changes (by igloo):
* difficulty: = Unknown
Old description:
ghc: panic! (the 'impossible' happened)
(GHC version 7.2.1 for i386-apple-darwin):
VectMonad.lookupFamInst: not found:
dph-par:Data.Array.Parallel.PArray.PData.PData{tc r4u}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Int{(w) tc 3J},
dph-par:Data.Array.Parallel.PArray.Base.PArray{tc r1}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Double{(w) tc 3u}),
ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Int{(w) tc 3J}
dph-par:Data.Array.Parallel.Lifted.Closure.:-{tc r2} (ghc-
prim:GHC.Types.Int{(w) tc 3J}
dph-
par:Data.Array.Parallel.Lifted.Closure.:-{tc r2} ghc-
prim:GHC.Types.Int{(w) tc 3J}),
ghc-prim:GHC.Types.Int{(w) tc 3J})
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
New description:
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 7.2.1 for i386-apple-darwin):
VectMonad.lookupFamInst: not found:
dph-par:Data.Array.Parallel.PArray.PData.PData{tc r4u}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Int{(w) tc 3J},
dph-par:Data.Array.Parallel.PArray.Base.PArray{tc r1}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Double{(w) tc 3u}),
ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Int{(w) tc 3J}
dph-par:Data.Array.Parallel.Lifted.Closure.:-{tc r2} (ghc-
prim:GHC.Types.Int{(w) tc 3J}
dph-
par:Data.Array.Parallel.Lifted.Closure.:-{tc r2} ghc-
prim:GHC.Types.Int{(w) tc 3J}),
ghc-prim:GHC.Types.Int{(w) tc 3J})
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5840#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5840: Extend the supported environment sizes of vectorised closures
#5840: Extend the supported environment sizes of vectorised closures --+- Reporter: mukesh.tiwari | Owner: chak Type: bug| Status: new Priority: normal | Milestone: 7.6.1 Component: Data Parallel Haskell | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * milestone: = 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5840#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5816: static linking silently fails in ghc
#5816: static linking silently fails in ghc
---+
Reporter: carter | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler| Version: 7.2.2
Keywords: linking osx | Os: MacOS X
Architecture: x86_64 (amd64) | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by igloo):
* status: infoneeded = new
Comment:
That gist says:
{{{
NOTE: on lion (and snow leopard i suppose), make sure you are using a 64
bit
install of ghc. Also, unless you are suggesting an edit to these
directions,
please go ask people on the relevant mailing list or wiki for help :)
note that these directions probably can use some cleanup, but i'm choosing
these steps so that rebuilding any haskell library doesn't require
remembering ANYTHING :-)
(tested on ghc 7.2.2, assumes you have standard developer things installed
on mac, like x11 and stuff)
1) cabal install gtk2hs-buildtools #(this should work with any haskell
platform install)
2) brew install cairo gtk gettext fontconfig
3) brew link cairo gettext fontconfig and all the other dependencies
listed for
brew's gtk formula
this is best done with by hand running brew link for each of the items
in
`brew deps gtk` along with fontconfig and gettext.
some of these will already linked, and some won't be, so this command
makes
it simpler
# brew will complain, who cares, this makes your life easier (at least if
you're
living in a haskell world :p )
NOTE: you will need to make sure that all these Brew libs are built, and
linked in
4) download libfreetype, heres a URL you can use
http://sourceforge.net/projects/freetype/files/freetype2/2.4.8/freetype-2.4.8.tar.bz2/download?use_mirror=iweb
5) unpack libfreetype, and then run
./configure ; make ; make install
this will install the static and dynamic library files for lib freetype
in
/usr/local/ (../include and ../lib) , which is what you'll want, though
this will
contribute to brew doctor complaining, but again, this is the easiest
way
6) cabal install gtk
this should work sans complaints!
now you can eg
cabal install chart-gtk
and run
this https://gist.github.com/1655252 example chart code either by building
with
ghc and running the executable
or by running main in ghc, and
or
try out some other cool libraries like diagrams!
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5816#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5816: static linking silently fails in ghc
#5816: static linking silently fails in ghc ---+ Reporter: carter | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler| Version: 7.2.2 Keywords: linking osx | Os: MacOS X Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * owner: = igloo * milestone: = 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5816#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5813: Offer a compiler warning for failable pattern matches
#5813: Offer a compiler warning for failable pattern matches
-+--
Reporter: snoyberg | Owner:
Type: feature request | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler | Version: 7.2.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by igloo):
* difficulty: = Unknown
* milestone: = 7.6.1
Comment:
I'd be inclined to close this as wontfix, as John explains in http://www
.mail-archive.com/haskell-cafe@haskell.org/msg96527.html :
{{{
This is actually the right useful behavior. using things like
do
Just x - xs
Just y - ys
return (x,y)
will do the right thing, failing if xs or ysresults in Nothing. for
instance, in the list monad, it will create the cross product of the
non Nothing members of the two lists. a parse monad may backtrack and
try another route, the IO monad will create a useful (and
deterministic/catchable) exception pointing to the exact file and line
number of the pattern match. The do notation is the only place in
haskell that allows us to hook into the pattern matching mechanism of
the language in a general way.
}}}
What do other people think?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5813#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5832: PolyKinds03 and PolyKinds13 fail an ASSERT
#5832: PolyKinds03 and PolyKinds13 fail an ASSERT -+-- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.4.1-rc2 Keywords: PolyKinds | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: PolyKinds03 PolyKinds13 Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj Comment: I'm on this -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5832#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5813: Offer a compiler warning for failable pattern matches
#5813: Offer a compiler warning for failable pattern matches -+-- Reporter: snoyberg | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by snoyberg): Dynamic typing is also a right useful behavior for some people. It can remove the need for some typing (both meanings intended) and make code shorter. Critics of dynamic typing generally counter that static typing can move a whole class of errors from runtime bugs to things which can be caught at compile time. I believe the same logic applies here. I'm not arguing to have this behavior removed from GHC; I'm asking for an option to be added for those of us wanting a little more safety in our code. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5813#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5813: Offer a compiler warning for failable pattern matches
#5813: Offer a compiler warning for failable pattern matches -+-- Reporter: snoyberg | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by maeder): * cc: Christian.Maeder@… (added) Comment: I think, it is definitely worth a flag, since you get a warning if you desugar do manually to `... = \ (Just y) - ...`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5813#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5841: seg fault in ghci but not ghc when using chart-gtk code
#5841: seg fault in ghci but not ghc when using chart-gtk code --+- Reporter: carter| Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.4.1 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related: 5816 | --+- I don't know if this is os x lion specific, but when running (attached .hs file) after compiling with (attached .txt) directions, the program compiled with ghc to a binary will work when set to generate either a pdf or a x11 window. In contrast, the same program when run via ghci and set to render to an x11 window, it segfaults. The ghci run when set to output to pdf works fine though. So I think the problem (perhaps, but perhaps not) might be with how the gtk package uses the ffi when run via ghci vs ghc? (so perhaps is a static vs dynamic linking issue). it does seem like this might in some way related to another linking bug on mac http://hackage.haskell.org/trac/ghc/ticket/5816#comment:4 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5841 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4900: DEPENDS pragma
#4900: DEPENDS pragma ---+ Reporter: cdsmith | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Build System |Version: Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * owner: igloo = * priority: highest = normal * milestone: 7.4.1 = 7.6.1 Comment: Yep, makes sense. Done in 7.4.1 (73e2749647f8ac21dbb0eea3d6df7c6834494a04) and HEAD (a711f138302b6d7ca043b67e8f0a907a560fcefb). Remilestoning again for the `DEPENDS` pragma part. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5810: OSX Lion building 7.4 head causes Haddock Divide By Zero
#5810: OSX Lion building 7.4 head causes Haddock Divide By Zero
--+-
Reporter: codeweaver | Owner: igloo
Type: bug | Status: closed
Priority: highest | Milestone: 7.4.1
Component: Compiler |Version: 7.4.1-rc1
Resolution: fixed| Keywords: haddock divide by zero
internal error
Os: MacOS X | Architecture: Other
Failure: Building GHC failed | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by igloo):
* status: new = closed
* resolution: = fixed
Comment:
I think this is fixed by:
commit 552504663774d4ad2528d466f08841b5b78c7518
{{{
Author: Ian Lynagh ig...@earth.li
Date: Fri Feb 3 17:03:21 2012 +
Updated to a newer version of gmp; fixes #5810
I didn't diagnose the problem, but with the newer GMP the problem
seems
fixed. There are a couple of things that look like candidates for the
bug:
* A few minor bugs related to portability fixed.
* A bug in division code possibly causing incorrect computation was
fixed.
}}}
Please let us know if you still have problems.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5810#comment:14
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5816: static linking silently fails in ghc
#5816: static linking silently fails in ghc
---+
Reporter: carter | Owner: igloo
Type: bug | Status: infoneeded
Priority: normal | Milestone: 7.6.1
Component: Compiler| Version: 7.2.2
Keywords: linking osx | Os: MacOS X
Architecture: x86_64 (amd64) | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by igloo):
* status: new = infoneeded
Comment:
{{{
brew install cairo gtk gettext fontconfig
}}}
is failing for me.
If the problem is in in linking, are you able to make a testcase that
demonstrates the problem using only a trivial C library, that just has a
function like
{{{
int f(int x) {
return x + 3;
}
}}}
or similar please?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5816#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5816: static linking silently fails in ghc
#5816: static linking silently fails in ghc ---+ Reporter: carter | Owner: igloo Type: bug | Status: infoneeded Priority: normal | Milestone: 7.6.1 Component: Compiler| Version: 7.2.2 Keywords: linking osx | Os: MacOS X Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by carter): whats the error message for the brew installs step? I dont' have a ready made ffi mini c lib example, though I can try to replicate it this weekend. did you do brew update before the brew install step? It is worth remarking that on ghc 7.4, a related bug happens where a seg fault happens in ghci, but ghc runs fine (and gives the desired output) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5816#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5757: zero unexpected failures on all tier 1 platforms
#5757: zero unexpected failures on all tier 1 platforms -+-- Reporter: simonmar | Owner: Type: task | Status: new Priority: highest | Milestone: 7.4.2 Component: Test Suite| Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related: #5785, #5757 | -+-- Changes (by igloo): * milestone: 7.4.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5757#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5790: Missing document about .eventlog's u flag
#5790: Missing document about .eventlog's u flag -+-- Reporter: shelarcy | Owner: duncan Type: bug | Status: new Priority: highest | Milestone: 7.4.2 Component: Documentation | Version: 7.4.1-rc1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: 7.4.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5790#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4138: Performance regression in overloading
#4138: Performance regression in overloading -+-- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Compiler | Version: 6.13 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: 7.4.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4138#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull | Owner: tibbe Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: GHCi| Version: 6.12.3 Keywords: MVar| Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * difficulty: = Unknown * milestone: 7.4.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4245#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4421: Compilation performance regression
#4421: Compilation performance regression -+-- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Compiler | Version: 6.12.3 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: 7.4.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4421#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4968: openTempFile fails on Windows if a directory exists with the file name it tries
#4968: openTempFile fails on Windows if a directory exists with the file name it tries ---+ Reporter: ganesh | Owner: bos Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: libraries/base | Version: 7.0.1 Keywords: | Os: Windows Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * difficulty: = Unknown * milestone: 7.4.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4968#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted
#5539: GHC panic - Simplifier ticks exhausted -+-- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high| Milestone: 7.6.1 Component: Compiler|Version: 7.3 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by igloo): * milestone: 7.4.1 = 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5539#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5842: pretty tests from GHC's testsuite
#5842: pretty tests from GHC's testsuite -+-- Reporter: igloo | Owner: dterei Type: task | Status: new Priority: normal| Milestone: 7.6.1 Component: libraries/pretty | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- We've been moving tests into the library that they test (#1161). I'm attaching some tests that used to be in the GHC testsuite `tests/lib/PrettyPrint`. Could you take a look, and perhaps make a `pretty` testsuite from them please? If you just put the files in a `tests/` directory in the `pretty` repo, then they would still be run as part of the GHC testsuite, which would have the advantage that they'd still get run during GHC validates etc. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5842 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5843: hGetBufSome blocks when all available input is buffered (on Windows only)
#5843: hGetBufSome blocks when all available input is buffered (on Windows only) -+-- Reporter: joeyadams| Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.2.2| Keywords: Os: Windows | Architecture: x86 Failure: Incorrect result at runtime | Testcase: Blockedby: | Blocking: Related: | -+-- See the attached program. On Windows, it blocks on hGetSome. If I take out the hGetLine and hWaitForInput, hGetSome does not block. If I add codehSetBuffering h NoBuffering/code, hGetBufSome still blocks after hWaitForInput because it does some buffering when it calls hLookAhead_. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5843 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5843: hGetBufSome blocks when all available input is buffered (on Windows only)
#5843: hGetBufSome blocks when all available input is buffered (on Windows only)
-+--
Reporter: joeyadams| Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.2.2| Keywords:
Os: Windows | Architecture: x86
Failure: Incorrect result at runtime | Testcase:
Blockedby: | Blocking:
Related: |
-+--
Comment(by joeyadams):
Sorry, I pressed Create Ticket when I meant to press Preview.
I did some debug traces, and found that the flow of calls is as follows:
hGetSome
hGetBufSome
bufReadNBNonEmpty (second occurrence)
bufReadNBEmpty
Buffered.fillReadBuffer0
The Buffered.fillReadBuffer0 call blocks on Windows, even though it
shouldn't:
{{{
-- | reads bytes into the buffer without blocking. Returns the
-- number of bytes read (Nothing indicates end-of-file), and the new
-- buffer.
fillReadBuffer0 :: dev - Buffer Word8 - IO (Maybe Int, Buffer Word8)
}}}
Digging deeper, I think fillReadBuffer0 ultimately boils down to a call to
fdReady. But I'm not 100% sure.
hWaitForInput, which also calls fdReady, does in fact work on Windows.
Perhaps readRawBufferPtrNoBlock isn't calling fdReady correctly. Here is
how GHC.IO.FD.ready calls it (for FD):
{{{
#if defined(mingw32_HOST_OS)
(fromIntegral $ fromEnum $ fdIsSocket fd)
#else
0
#endif
}}}
And here is how readRawBufferPtrNoBlock calls it:
{{{
| otherwise= do r - unsafe_fdReady (fdFD fd) 0 0 0
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5843#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
