Re: [GHC] #2790: Use -fregs-graph by default
#2790: Use -fregs-graph by default -+-- Reporter: igloo |Owner: benl Type: task | Status: new Priority: high |Milestone: 6.14.1 Component: Compiler | Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by benl): Yes, but I've only tested it on OSX with the testsuite. You might want to do a full hackage build on Linux first if you're setup for it. Apart from with the vector library, it doesn't make much difference to the runtimes. Perhaps we want to enable -fregs-graph for -O and -fregs- iterative for -O2. At least that would stop all the allocators (including the linear one) from rotting in the future. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2790#comment:24 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] #4248: Poor error message when openFile fails to open named pipe
#4248: Poor error message when openFile fails to open named pipe
-+--
Reporter: Khudyakov | Owner:
Type: bug | Status: new
Priority: normal| Component: libraries/base
Version: 6.12.3|Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
openFile cannot open named pipe if no one reads on the other end and fails
with particularly unhelpful error message. Quick googling shows that it
opens file in non-blocking mode so failure to open is not bug per se, but
this fact is not mentioned in documentation.
Example:
1. Create named pipe
{{{
$ mkfifo /tmp/fifo
}}}
2. Now in GHCi:
{{{
Prelude openFile /tmp/fifo WriteMode
*** Exception: /tmp/fifo: openFile: does not exist (No such device or
address)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4248
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] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc.
#635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -+-- Reporter: simonmar| Owner: bos Type: task| Status: closed Priority: normal | Milestone: _|_ Component: libraries/base |Version: 6.13 Resolution: fixed | Keywords: Testcase: N/A | Blockedby: Difficulty: Project (more than a week) | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | -+-- Comment(by simonmar): Thanks for closing the bug, and well done to both you and Bryan! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/635#comment:43 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] #4221: Calling freeHaskellFunctionPtr from C finalizer leads to crashes
#4221: Calling freeHaskellFunctionPtr from C finalizer leads to crashes
-+--
Reporter: ravi_n|Owner:
Type: bug | Status: new
Priority: normal|Milestone: 6.14.1
Component: Runtime System| Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime crash
-+--
Comment(by simonmar):
I found and fixed the bug, but I was confused for a while that the program
was still crashing after I'd fixed the bug. Then I noticed the program
has a pretty serious bug in it:
{{{
callFnBlob :: ForeignPtr FnBlob - CDouble - IO (CDouble)
callFnBlob fnblob d = withForeignPtr fnblob $
\ptrblob - return(call_fn_blob ptrblob d)
}}}
this is an invalid use of `withForeignPtr`, because the pointer escapes
from the context (in the closure `call_fn_blob ptrblob d`). Hence the
finalizer runs before the call, and you get a crash.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4221#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] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS -+-- Reporter: guest |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.14.1 Component: Runtime System| Version: 6.12.1 Keywords:| Testcase: N/A Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * priority: normal = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/698#comment:34 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] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information -+-- Reporter: guest |Owner: simonmar Type: task | Status: new Priority: high |Milestone: 6.14.1 Component: Runtime System| Version: 6.6.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: = simonmar * failure: = None/Unknown * priority: low = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#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] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS -+-- Reporter: guest |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.14.1 Component: Runtime System| Version: 6.12.1 Keywords:| Testcase: N/A Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by zooko): Unfortunately I'm still receiving notifications in my email about this ticket. I've already removed my email address from the Cc: line. If anyone who understands the trac config better could take me off this ticket I would appreciate it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/698#comment:35 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] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS -+-- Reporter: guest |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.14.1 Component: Runtime System| Version: 6.12.1 Keywords:| Testcase: N/A Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by zooko): * cc: zo...@… (added) Comment: Adding myself to Cc: with the intent to then un-add myself again and see if that makes me receive no more mail about this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/698#comment:36 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] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS -+-- Reporter: guest |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.14.1 Component: Runtime System| Version: 6.12.1 Keywords:| Testcase: N/A Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by zooko): * cc: zo...@… (removed) Comment: Removing myself from Cc:. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/698#comment:37 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] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14.1 Component: libraries/unix| Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by duncan): Perhaps we can just use SIGCHLD as a notification. When we get a SIGCHLD we can assume that there may be multiple children in a waitable state. We can then call waitpid/waitid multiple times, using the WNOHANG flag so it does not block, then we call it repeatedly until there are no more children to wait for. If we want to avoid waiting for children that do not belong to System.Process then we can use WNOWAIT first time and then call it again if we find the PID was one our ours. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:21 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] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14.1 Component: libraries/unix| Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by duncan): See also the docs for [http://www.opengroup.org/onlinepubs/009695399/functions/wait.html wait()], particular the rationale near the bottom for a discussion of reliably counting child processes. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:22 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] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14.1 Component: libraries/unix| Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by duncan): And similarly: http://www.linuxselfhelp.com/gnu/glibc/html_chapter/libc_24.html#SEC491 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#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] #3811: Parse errors should display text being parsed
#3811: Parse errors should display text being parsed +--- Reporter: asuffield | Owner: igloo Type: bug| Status: closed Priority: normal | Milestone: 6.14.1 Component: Compiler (Parser) |Version: 6.12.1 Resolution: fixed | Keywords: Testcase: T3811* | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | +--- Changes (by igloo): * status: new = closed * testcase: = T3811* * resolution: = fixed Comment: I've added more info to the parse errors in `RdrHsSyn`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3811#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
