Re: [GHC] #29: Check for exhaustive patterns is broken
#29: Check for exhaustive patterns is broken
---+
Reporter: nobody| Owner:
Type: bug | Status: new
Priority: lowest| Milestone: _|_
Component: Compiler |Version: 5.02
Resolution: None | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Changes (by ganesh):
* failure: = None/Unknown
Comment:
This is an unsolvable issue. Consider this simplified example:
{{{
foo x | x == 0 = 0
| x /= 0 = 0
}}}
For correct Eq implementations these patterns are indeed exhaustive. But
(a) GHC has no evidence that all Eq implementations are correct, and (b)
in general it would be undecidable to check whether arbitrary guards are
exhaustive or not.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/29#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] #3645: Layout and pragmas
#3645: Layout and pragmas +--- Reporter: igloo | Owner: Type: feature request| Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Parser) |Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown| Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | +--- Changes (by guest): * failure: = None/Unknown * type: bug = feature request -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3645#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] #29: Check for exhaustive patterns is broken
#29: Check for exhaustive patterns is broken ---+ Reporter: nobody| Owner: Type: bug | Status: closed Priority: lowest| Milestone: _|_ Component: Compiler |Version: 5.02 Resolution: invalid | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by ganesh): * status: new = closed * resolution: None = invalid Comment: Closing this with the approval of the GHC team (http://www.haskell.org/pipermail/glasgow-haskell- users/2009-November/018017.html) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/29#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] #68: Warnings for unitialized fields
#68: Warnings for unitialized fields
--+-
Reporter: nobody | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: _|_
Component: Compiler |Version: None
Resolution: None | Keywords: warnings
Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by simonmar):
* failure: = None/Unknown
Old description:
{{{
Hello.
Would it be possible to add flag to disable warnings for
unitialized fields just when using constructor with
zero fields? I mean, if I use
Foo {}
to construct empty record, it is a bit unpleasant that
I get flooded by dozens of useless warnings; but I don't
want to disable them -- they are useful when I forget
to initialize some field(s).
Zdenek Dvorak
}}}
New description:
Would it be possible to add flag to disable warnings for
unitialized fields just when using constructor with
zero fields? I mean, if I use
{{{
Foo {}
}}}
to construct empty record, it is a bit unpleasant that
I get flooded by dozens of useless warnings; but I don't
want to disable them -- they are useful when I forget
to initialize some field(s).
Zdenek Dvorak
Comment:
Not clear if this is a good idea, but we'll leave it here anyway.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/68#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] #95: GHCi :edit command should jump to the the last error
#95: GHCi :edit command should jump to the the last error
--+-
Reporter: martijnislief| Owner:
Type: feature request | Status: new
Priority: normal | Milestone: _|_
Component: GHCi |Version: None
Resolution: None | Keywords:
Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by simonmar):
* failure: = None/Unknown
* summary: GHCi editor binding with :e = GHCi :edit command should
jump to the the last error
* milestone: 6.12 branch = _|_
Old description:
{{{
For me, a very useful feature of Hugs is the :e command,
allowing to jump directly to the file and line number that
contain the first error.
I'd be very happy if GHCi supported this feature.
}}}
New description:
GHCi has a `:edit` command for editing the current source file. Hugs's
command of the same name automatically jumps the editor to the location of
the last error; it would be nice if GHCi's did the same.
Comment:
You can define it yourself, but it's a bit hacky and it would clearly be
better to have it built-in. This is also a small self-contained task
(limited to the GHCi front end) that a new contributor could take on.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/95#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] #229: Integer overflow in array allocation
#229: Integer overflow in array allocation -+-- Reporter: josefs | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/base |Version: 6.4.1 Resolution: None| Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by StefanWehr): * failure: = None/Unknown Comment: With ghci 6.10.4 on Linux the problem no longer occurs. (You get an Exception: Error in array index instead of a core dump.) The bug seems to be fixed but I did not dare to change the status. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/229#comment:11 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] #3670: Allow RULES for higher-ranked terms
#3670: Allow RULES for higher-ranked terms
+---
Reporter: rl | Owner:
Type: feature request| Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 6.13
Resolution: fixed | Keywords:
Difficulty: | Os:
Unknown/Multiple
Testcase: simplCore/should_compile/rule2.hs | Architecture:
Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by simonpj):
* testcase: = simplCore/should_compile/rule2.hs
* difficulty: =
* status: new = closed
* resolution: = fixed
* failure: = None/Unknown
Comment:
Good idea. Fixed by
{{{
Tue Nov 17 12:54:17 GMT 2009 simo...@microsoft.com
* Improvement to typecheck higher-rank rules better
See Note [Typechecking rules] in TcRules.
Suggested by Roman
M ./compiler/typecheck/TcRules.lhs -5 +20
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3670#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
[GHC] #3671: Add partitioning functions to Data.List
#3671: Add partitioning functions to Data.List
-+--
Reporter: holzensp | Owner:
Type: proposal | Status: new
Priority: normal| Component: libraries/base
Version: 6.12.1 RC1|Keywords: Data.List
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
The functions `take` and `span` have recursive equivalents `takeRec` and
`spanRec` that apply the same function to the remainder, i.e.
{{{
takeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i xs
spanRec p xs = let (hs,ts) = spanp xs in hs : spanRec p xs
}}}
and the more generic version of `take`:
{{{
genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs :
genericTakeRec i xs
}}}
These functions, to me, are in the same league as `partition` and `group`,
can be added with little chance of nameclashes on functions with a
different meaning and are not named compositions.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3671
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] #3671: Add partitioning functions to Data.List
#3671: Add partitioning functions to Data.List
-+--
Reporter: holzensp | Owner:
Type: proposal | Status: new
Priority: normal| Milestone:
Component: libraries/base| Version: 6.12.1 RC1
Resolution:|Keywords: Data.List
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment (by holzensp):
Correction, obviously:
{{{
takeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i ts
spanRec p xs = let (hs,ts) = spanp xs in hs : spanRec p ts
genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs :
genericTakeRec i ts
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3671#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] #17: Separate warnings for unused local and top-level bindings
#17: Separate warnings for unused local and top-level bindings --+- Reporter: magunter | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Compiler |Version: None Resolution: None | Keywords: -fwarn-unused-binds Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by mboes): * cc: mb...@lix.polytechnique.fr (added) Comment: I doubt the usefulness of this feature since any top-level function that is mentioned in the export list of the module won't trigger a warning. It is confusing to see dead code in a module and so top-level functions that aren't used should probably just be commented out. However, this feature does come handy when using records: it often happens that a field name isn't used in a module, hence triggering a warning. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/17#comment:11 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] #3671: Add partitioning functions to Data.List
#3671: Add partitioning functions to Data.List
-+--
Reporter: holzensp | Owner:
Type: proposal | Status: new
Priority: normal| Milestone:
Component: libraries/base| Version: 6.12.1 RC1
Resolution:|Keywords: Data.List
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment (by holzensp):
Oh my, so sloppy; forgot base cases. Last try.
{{{
takeRec :: Int - [a] - [[a]]
takeRec = genericTakeRec
genericTakeRec :: (Integral a) = a - [b] - [[b]]
genericTakeRec n _ | n = 0 = []
genericTakeRec _ [] = []
genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs :
genericTakeRec i ts
spanRec :: (a - Bool) - [a] - [[a]]
spanRec _ [] = []
spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p ts
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3671#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
[GHC] #3672: Let Linker.c know about stg_arg_bitmaps
#3672: Let Linker.c know about stg_arg_bitmaps -+-- Reporter: int-e |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Runtime System| Version: 6.13 Keywords:| Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- stg_args_bitmaps is useful to make sense of AP and PAP closures on the heap, i.e. for heap inspecting code. So it would be nice if code other than the RTS that uses it worked in ghci. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3672 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] #3655: Performance regression relative to 6.10
#3655: Performance regression relative to 6.10 --+- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler |Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --+- Comment (by simonmar): We tracked it down to `sequence_` not fusing with `map` in a couple of places, due to `sequence_` not having arity 2 which was preventing a partially-applied call being inlined, which meant that the rule didn't fire. Simon PJ is going to investigate further. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3655#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] #229: Integer overflow in array allocation
#229: Integer overflow in array allocation -+-- Reporter: josefs | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: libraries/base |Version: 6.4.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by simonmar): * status: new = closed * resolution: None = fixed Comment: Thanks Stefan! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/229#comment:12 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] #3583: Default view patterns
#3583: Default view patterns -+-- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler|Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Comment (by simonmar): On the policy issue: if it's clear an idea is bad, then we should close the ticket, yes. On this particular issue it looks like there is some support for the idea, if not in the exact form suggested by the original submitter. Could someone familiar with the details update the ticket? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3583#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] #229: Integer overflow in array allocation
#229: Integer overflow in array allocation
-+--
Reporter: josefs | Owner:
Type: bug | Status: closed
Priority: low | Milestone: _|_
Component: libraries/base |Version: 6.4.1
Resolution: fixed | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Old description:
{{{
When asked to create a sufficiently large array ghci
coredumps.
\begin{code}
import Data.Array.ST
import Control.Monad.ST
import GHC.Base
example = runST (do arr - newArray (minInt,maxInt)
False
go arr)
where go :: STArray s Int Bool - ST s Bool
go arr = readArray arr 3
\end{code}
Load this into ghci and type 'example'.
}}}
New description:
When asked to create a sufficiently large array ghci
coredumps.
{{{
\begin{code}
import Data.Array.ST
import Control.Monad.ST
import GHC.Base
example = runST (do arr - newArray (minInt,maxInt)
False
go arr)
where go :: STArray s Int Bool - ST s Bool
go arr = readArray arr 3
\end{code}
}}}
Load this into ghci and type 'example'.
Comment (by josef):
Using the bounds (minInt,maxInt) was probably the wrong thing todo. My
concern when filing the bug report was not the arithmetic overflow but the
fact that ghci crashes when it tries to allocate a too large an array. It
is still possible to provoke a crash if you change the array bounds to,
say, (2,maxInt). Should I open a new ticket or reopen this one?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/229#comment:13
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] #2439: Missed optimisation with dictionaries and loops
#2439: Missed optimisation with dictionaries and loops
--+-
Reporter: rl | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Compiler |Version: 6.9
Resolution: | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Runtime performance bug |
--+-
Comment (by rl):
I'm not sure how this translates to the new inliner. This is code that is
generated now:
{{{
Foo.sum' =
\ (@ a_aj6) ($dNum_aje :: GHC.Num.Num a_aj6) -
let {
lit_skO [Dmd=Just L] :: a_aj6
[LclId, Str=DmdType]
lit_skO = GHC.Num.fromInteger @ a_aj6 $dNum_aje Foo.sum'1 } in
letrec {
loop_skM [Occ=LoopBreaker] :: a_aj6 - [a_aj6] - a_aj6
[LclId, Arity=2, Str=DmdType SS]
loop_skM =
\ (z_afp :: a_aj6) (ds_djs :: [a_aj6]) -
case z_afp of z1_XfG { __DEFAULT -
case ds_djs of _ {
[] - z1_XfG;
: x_afr xs_afs -
loop_skM (GHC.Num.+ @ a_aj6 $dNum_aje z1_XfG x_afr) xs_afs
}
}; } in
\ (xs_afu :: [a_aj6]) - loop_skM lit_skO xs_afu
}}}
Instead of scrutinising the dictionary, we are now calling the method
selector in every iteration. Is this even worse than before?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2439#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] #565: overlapping instances fundeps broken
#565: overlapping instances fundeps broken
--+-
Reporter: ashley-y | Owner:
Type: bug | Status: new
Priority: low | Milestone: _|_
Component: Compiler (Type checker) |Version: 5.00
Resolution: None | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by ganesh):
* failure: = None/Unknown
Comment:
The problem with all these examples is that someone (in another module)
add {{{instance Num Bool}}}, and now the instances really do overlap, and
the fundep is violated.
So I think this bug should be closed as invalid.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/565#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] #2439: Missed optimisation with dictionaries and loops
#2439: Missed optimisation with dictionaries and loops --+- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler |Version: 6.9 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --+- Comment (by simonpj): I think the underling issue hasn't changed. The only difference is that before we inlined the method selector and now we don't. (Deliberately -- little is gained by doing so.) So it's more or less the same with new and old inliner. I think that strict dictionaries are still the answer here. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2439#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] #110: Cygwin binaries
#110: Cygwin binaries --+- Reporter: fizzgig | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None |Version: None Resolution: None | Keywords: Difficulty: Unknown | Os: Windows Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by yairchu): * failure: = None/Unknown * os: Unknown/Multiple = Windows -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/110#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] #3303: Allow multi-line deprecation messages.
#3303: Allow multi-line deprecation messages.
---+
Reporter: duncan| Owner: igloo
Type: merge | Status: closed
Priority: high | Milestone: 6.12.1
Component: Compiler |Version: 6.10.2
Resolution: fixed | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Changes (by igloo):
* status: new = closed
* failure: = None/Unknown
* resolution: = fixed
Comment:
Merged:
{{{
Sun Nov 15 15:56:17 GMT 2009 Duncan Coutts dun...@well-typed.com
* Fix formatting of module deprecation/warning messages
Ignore-this: a41444bdda003aee4412eb56a0e7d052
It was accidentally using list syntax. Fixes #3303 again.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3303#comment:10
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] #3532: haddock should support content indexing of versioned package dirs
#3532: haddock should support content indexing of versioned package dirs
+---
Reporter: juhpetersen| Owner: igloo
Type: bug| Status: closed
Priority: high | Milestone: 6.12.1
Component: Documentation |Version: 6.10.4
Resolution: fixed | Keywords:
Difficulty: Unknown| Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by igloo):
* status: new = closed
* failure: = None/Unknown
* resolution: = fixed
Comment:
Fixed in HEAD and 6.12 by:
{{{
Sun Nov 8 21:07:01 GMT 2009 Ian Lynagh ig...@earth.li
* Put docs into versioned directory names; fixes trac #3532
You can now have multiple versions of a package installed, and
gen_contents_index will do the right thing.
Tue Nov 10 22:36:32 GMT 2009 Ian Lynagh ig...@earth.li
* Use relative paths for haddockHTMLs in the inplace package.conf
This means that the docs get built with the correct relative paths.
When installing, the absolute path will still be used.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3532#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] #565: overlapping instances fundeps broken
#565: overlapping instances fundeps broken --+- Reporter: ashley-y | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (Type checker) |Version: 5.00 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by igloo): * owner: = simonpj Comment: I agree; Simon, can you confirm and close it, please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/565#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] #2615: ghci doesn't play nice with linker scripts
#2615: ghci doesn't play nice with linker scripts ---+ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.12.1 Component: GHCi |Version: 6.10.1 Resolution:| Keywords: Difficulty: Unknown | Os: Linux Testcase:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by slyfox): * cc: slyfox (added) * failure: = None/Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2615#comment:13 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] #1185: can't do I/O in the child of forkProcess with -threaded
#1185: can't do I/O in the child of forkProcess with -threaded -+-- Reporter: simonmar| Owner: igloo Type: merge | Status: closed Priority: high| Milestone: 6.12.1 Component: Runtime System |Version: 6.6 Resolution: fixed | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by igloo): * status: new = closed * failure: = None/Unknown * resolution: = fixed Comment: The One more patch seems to already be applied, but I've merged the rest and the test now passes. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1185#comment:28 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] #1117: [2,4..10] is not a good list producer
#1117: [2,4..10] is not a good list producer --+- Reporter: b...@internet.com.uy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Compiler |Version: 6.6 Resolution: | Keywords: rewrite rules Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by daniel.is.fischer): * failure: = None/Unknown Comment: Seems fixed. Timings with 6.10.3: fastest 2.55s, fast 2.64s, slow 2.71s on average. I think that's good enough, suggest closing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1117#comment:11 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] #3671: Add partitioning functions to Data.List
#3671: Add partitioning functions to Data.List
-+--
Reporter: holzensp| Owner:
Type: proposal| Status: new
Priority: normal | Milestone:
Component: libraries/base |Version: 6.12.1 RC1
Resolution: | Keywords: Data.List
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Changes (by malcolm.wall...@cs.york.ac.uk):
* difficulty: =
Comment:
Although your recursive 'takeRec' makes some sense, the recursive
'spanRec' is more dubious.
{{{
spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p ts
}}}
By the definition of 'span', the first element of 'ts' satisfies the
predicate p. Thus, in the first recursive call, 'span' will split the
remaining list into [] and ts, the second recursive call likewise, and so
on ad infinitum.
{{{
spanRec (==0) [1,2,3,0,4,5,6] = [1,2,3]:[]:[]:[]:[]...
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3671#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] #1216: indexing 2d arrays is slow and leaky. why?
#1216: indexing 2d arrays is slow and leaky. why?
--+-
Reporter: claus| Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 6.12.1
Component: Compiler |Version: 6.6
Resolution: | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Runtime performance bug |
--+-
Changes (by daniel.is.fischer):
* cc: daniel.is.fisc...@web.de (added)
Comment:
Still slow and also overallocating in 6.10.3:
{{{
./indexL 10 +RTS -sstderr
array (1,40) [snip]
7,132,475,396 bytes allocated in the heap
935,808 bytes copied during GC
31,748 bytes maximum residency (1 sample(s))
22,992 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Generation 0: 13604 collections, 0 parallel, 0.20s, 0.16s elapsed
Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed
INIT time0.00s ( 0.00s elapsed)
MUT time 11.34s ( 11.42s elapsed)
GCtime0.20s ( 0.16s elapsed)
EXIT time0.00s ( 0.00s elapsed)
Total time 11.55s ( 11.58s elapsed)
%GC time 1.8% (1.4% elapsed)
Alloc rate628,705,232 bytes per MUT second
Productivity 98.2% of total user, 97.9% of total elapsed
da...@linux-mkk1:~/Haskell/CafeTesting ./indexH +RTS -sstderr -RTS 10
./indexH 10 +RTS -sstderr
array (1,40) [snip]
9,800,880 bytes allocated in the heap
11,908 bytes copied during GC
31,696 bytes maximum residency (1 sample(s))
22,992 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Generation 0:18 collections, 0 parallel, 0.00s, 0.00s elapsed
Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed
INIT time0.00s ( 0.00s elapsed)
MUT time3.80s ( 3.80s elapsed)
GCtime0.00s ( 0.00s elapsed)
EXIT time0.00s ( 0.00s elapsed)
Total time3.80s ( 3.80s elapsed)
%GC time 0.0% (0.0% elapsed)
Alloc rate2,581,735 bytes per MUT second
Productivity 100.0% of total user, 100.0% of total elapsed
}}}
Both compiled with -O2.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1216#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
