Re: [GHC] #2185: Memory leak with parMap
#2185: Memory leak with parMap --+- Reporter: igloo | Owner: simonmar Type: run-time performance bug | Status: reopened Priority: normal| Milestone: 6.10 branch Component: Runtime System|Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonmar): * status: closed = reopened * component: Compiler = Runtime System * resolution: fixed = Comment: unfixed. Sparks really should be treated as GC roots, because many uses of par rely on this behaviour (including most of the strategies library). I don't have any ideas for how to fix this yet. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2185#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] #2470: read for StdGen fails for arbitrary string
#2470: read for StdGen fails for arbitrary string +--- Reporter: guest| Owner: Type: bug | Status: new Priority: normal | Component: libraries/random Version: 6.8.3|Severity: normal Keywords: StdGen read |Testcase: Architecture: x86 | Os: Windows +--- According to the docs for StdGen: In addition, read may be used to map an arbitrary string (not necessarily one produced by show) onto a value of type StdGen. In general, the read instance of StdGen has the following properties: * It guarantees to succeed on any string. * It guarantees to consume only a finite portion of the string. * Different argument strings are likely to result in different results. Here's what happens on my system: C:\odm\ghc\libghci GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :mod +System.Random Prelude System.Random (read tasty tofu) :: StdGen Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. *** Exception: Prelude.read: no parse Prelude System.Random You can contact me at [EMAIL PROTECTED] if you need more information. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2470 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] #1364: Finalizers not guaranteed to run before the program exits
#1364: Finalizers not guaranteed to run before the program exits --+- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: feature request | Status: new Priority: normal| Milestone: 6.10.1 Component: Runtime System|Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by Svarog): Replying to [comment:6 Svarog]: Added patches that add C finalizers that can be run directly from the garbage collector. Just in case it's not clear, fix1364-ghc.patch should be applied to ghc and fix1364-base.patch should be applied to the base library. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1364#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] #1364: Finalizers not guaranteed to run before the program exits
#1364: Finalizers not guaranteed to run before the program exits --+- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: feature request | Status: new Priority: normal| Milestone: 6.10.1 Component: Runtime System|Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by tibbe): * cc: [EMAIL PROTECTED] (added) Comment: Replying to [comment:6 Svarog]: Added patches that add C finalizers that can be run directly from the garbage collector. Will this add a performance penalty (i.e. extra GC overhead) to code that does not make use of finalizers? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1364#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] #2470: read for StdGen fails for arbitrary string
#2470: read for StdGen fails for arbitrary string -+-- Reporter: guest |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: libraries/random | Version: 6.8.3 Severity: normal| Resolution: Keywords: StdGen read | Testcase: Architecture: x86 | Os: Windows -+-- Comment (by guest): With further thought, I wonder if I misunderstand the specification. From reading the code, it looks like the read instance is using the first 6 characters to construct the StdGen result. However, because the rest of the string is left over and unprocessed, the read call fails whenever there are more than 6 characters in the passed string. Two notes: (1) The number 6 is undocumented, making the behavior of read incompehensible without examining the code; (2) it's unclear how this specification interacts with compound structures, like the derived instance of read :: String - (StdGen,StdGen). What would we expect read (longword,longerword,longestword) :: (StdGen,StdGen) to do? How do we know which commas mean what? If whoever looks at this decides this is an enhancement rather than a bug, I won't be too terribly hurt. Again, you can contact me at [EMAIL PROTECTED] Exposing stdFromString (perhaps with a different name) might make everything cleaner. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2470#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] #1364: Finalizers not guaranteed to run before the program exits
#1364: Finalizers not guaranteed to run before the program exits --+- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: feature request | Status: new Priority: normal| Milestone: 6.10.1 Component: Runtime System|Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by Svarog): Replying to [comment:8 tibbe]: Will this add a performance penalty (i.e. extra GC overhead) to code that does not make use of finalizers? I'm pretty sure that it won't. The only overhead is that the weak pointer struct now has an extra field for a C finalizer and the code that goes through dead weak pointers and schedules existing Haskell finalizers has an extra if statement to check for C finalizers and run them immediately. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1364#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] #1997: Stricter enumFrom instance for Integer, to match Int
#1997: Stricter enumFrom instance for Integer, to match Int ---+ Reporter: dons | Owner: igloo Type: bug| Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base |Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: lib/should_run/enum04 | Architecture: Multiple Os: Multiple | ---+ Changes (by igloo): * owner: = igloo * milestone: 6.10 branch = 6.10.1 Comment: Thanks for the patch! We'll take a look -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1997#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] #2470: read for StdGen fails for arbitrary string
#2470: read for StdGen fails for arbitrary string
--+-
Reporter: guest | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: libraries/random |Version: 6.8.3
Severity: normal| Resolution: invalid
Keywords: StdGen read | Difficulty: Unknown
Testcase:| Architecture: x86
Os: Windows |
--+-
Changes (by igloo):
* status: new = closed
* difficulty: = Unknown
* resolution: = invalid
Comment:
Strings that are the result of showing a StdGen work fine as part of
structures:
{{{
Prelude System.Random let x = (mkStdGen 100, mkStdGen 200)
Prelude System.Random x
(101 1,201 1)
Prelude System.Random let y = show x
Prelude System.Random y
(101 1,201 1)
Prelude System.Random let z = read y :: (StdGen,StdGen)
Prelude System.Random z
(101 1,201 1)
Prelude System.Random
}}}
For reading a random string you can use `reads` to avoid the exception.
We've discussed this before, although I can't find the ticket now (it
might have been on a mailing list or something), and concluded that given
the finite portion requirement the current behaviour is the best.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2470#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] #2470: read for StdGen fails for arbitrary string
#2470: read for StdGen fails for arbitrary string --+- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: libraries/random |Version: 6.8.3 Severity: normal| Resolution: invalid Keywords: StdGen read | Difficulty: Unknown Testcase:| Architecture: x86 Os: Windows | --+- Comment (by guest): igloo: would it be appropriate to document the read 6 characters? Just a final thought. At a minimum, my interpretation of the phrase using different strings is likely to result in different generators is strongly violated by a dependency on the first six characters, unless that's documented. No worries either way. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2470#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] #1930: infix type constructors are printed incorrectly by GHC
#1930: infix type constructors are printed incorrectly by GHC
--+-
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal| Milestone: _|_
Component: Compiler |Version: 6.8.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: Unknown
Os: Unknown |
--+-
Comment (by nfrisby):
Moreover, infix constructors - even those that are not operators - are
also incorrectly printed.
{{{
data Report = AsExpected Outcome | Outcome `InsteadOf` Outcome
}}}
Note how GHC 6.8.2 prints the !InsteadOf operator without the backticks:
{{{
*Correctness :i Report
data Report = AsExpected Outcome | Outcome InsteadOf Outcome
-- Defined at Correctness.hs:23:5-10
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1930#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
