Re: [GHC] #4900: DEPENDS pragma
#4900: DEPENDS pragma -+-- Reporter: cdsmith |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.4.1 Component: Build System | Version: Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by GregWeber): So I am fiddling with the Quasi Monad now. I would like to call getGblEnv/setGblEnv from withing a new addDependentFile function, although I know that isn't right. How do I actually go about this? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:20 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] #5564: Panic in ghci name suggestion
#5564: Panic in ghci name suggestion
-+--
Reporter: judahj| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.2.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
From a plain invocation of ghci:
{{{
$ ghci
GHCi, version 7.2.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude 2
2
Prelude fit
interactive:0:1:ghc: panic! (the 'impossible' happened)
(GHC version 7.2.1 for x86_64-apple-darwin):
unknownNameSuggestErr UnhelpfulSpan
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Prelude
}}}
Presumably, ghci wants to suggest the `it` variable but is getting
confused because that variable wasn't defined in a source file.
Note that this doesn't actually crash ghci; the prompt resumes as normal
after the error message is printed out.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5564
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] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments
#5529: Newtypes with hidden constructors cannot be passed as FFI arguments ---+ Reporter: mikhail.vorozhtsov |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple| Blocking: Architecture: Unknown/Multiple| Failure: None/Unknown ---+ Comment(by simonmar): I think GHC is correct now. This was discussed a long time ago on the FFI list (no link handy, sorry), and I think the principle is that in order to use a newtype in an FFI declaration you have to know its representation, because you're linking against some known C code that depends on the representation. So if we allowed that to happen with an abstract newtype, it would constitute leakage of the abstraction. We ought to change `Foreign.C.Types` to export the types non-abstractly. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5529#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] #5540: Non-deterministic pure code in Data.Typeable
#5540: Non-deterministic pure code in Data.Typeable -+-- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 7.0.3 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: MacOS X Blocking: | Architecture: x86_64 (amd64) Failure: None/Unknown| -+-- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Sorry about the bug. It is fixed in 7.2.1 and later, but we aren't planning to patch older releases. I wish we had noticed this bug earlier! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5540#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] #5546: Documentation errors in Control.Exception.Base
#5546: Documentation errors in Control.Exception.Base -+-- Reporter: bit |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.4.1 Component: libraries/base| Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: = simonmar * priority: normal = high * milestone: = 7.4.1 Comment: Thanks for the report; fix coming. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5546#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] #5547: Control.Concurrent documentation
#5547: Control.Concurrent documentation -+-- Reporter: guest |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.4.1 Component: Documentation | Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: = simonmar * priority: normal = high * milestone: = 7.4.1 Comment: Thanks for the report; fix coming. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5547#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] #5545: ($!) not in scope
#5545: ($!) not in scope --+- Reporter: daniel.is.fischer |Owner: simonmar Type: bug| Status: new Priority: high |Milestone: 7.4.1 Component: GHCi | Version: 7.2.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by simonmar): * owner: simonpj = simonmar * priority: normal = high * milestone: = 7.4.1 Comment: I have a fix for this, validating now. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5545#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] #5552: SIGSEGV in yieldCapability () when using Control.Parallel
#5552: SIGSEGV in yieldCapability () when using Control.Parallel ---+ Reporter: tomt21 |Owner: simonmar Type: bug | Status: new Priority: highest |Milestone: 7.4.1 Component: Runtime System | Version: 7.0.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by simonmar): * owner: = simonmar * priority: normal = highest * milestone: = 7.4.1 Old description: When running with -N12 and using parMap from Control.Parallel my code gives random segfaults. The function being mapped in parallel is pure but uses hmatrix which makes FFI calls to liblapack. Using gdb on my code compiled with -debug, and using +RTS -N12 I get: Main: internal error: ASSERTION FAILED: file rts/Capability.c, line 637 (GHC version 7.0.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x7560f405 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) where #0 0x7560f405 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x75612680 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00c1c322 in rtsFatalInternalErrorFn () #3 0x00c1bf4b in barf () #4 0x00c1bfae in _assertFail () #5 0x00c18f18 in yieldCapability () #6 0x00c1e516 in scheduleYield () #7 0x00c1dbf7 in schedule () #8 0x00c1ff95 in scheduleWaitThread () #9 0x00c5f3c0 in rts_evalLazyIO () #10 0x00c1bdaf in real_main () #11 0x00c1be9e in hs_main () #12 0x755fbead in __libc_start_main () from /lib/x86_64-linux- gnu/libc.so.6 #13 0x004097ed in _start () (gdb) I also get the same thing even if using only -N2. The end of the output from -Ds looks like: 7f9e73393700: returning; I want capability 3 7f9e73393700: resuming capability 3 7f9e73393700: cap 3: running thread 20547 (ThreadRunGHC) 7f9e73393700: cap 3: thread 20547 stopped (suspended while making a foreign call) 7f9e73393700: freeing capability 3 7f9e73393700: returning; I want capability 3 7f9e73393700: resuming capability 3 7f9e73393700: cap 3: running thread 20547 (ThreadRunGHC) 7f9e73393700: cap 3: thread 20547 stopped (suspended while making a foreign call) 7f9e73393700: freeing capability 3 7f9e73393700: returning; I want capability 3 7f9e73393700: resuming capability 3 7f9e73393700: cap 3: running thread 20547 (ThreadRunGHC) 7f9e73393700: cap 3: thread 20547 stopped (suspended while making a foreign call) 7f9e73393700: freeing capability 3 7f9e73393700: returning; I want capability 3 7f9e73393700: resuming capability 3 7f9e73393700: cap 3: running thread 20547 (ThreadRunGHC) 7f9e73393700: cap 3: thread 20547 stopped (suspended while making a foreign call) 7f9e73393700: freeing capability 3 7f9e73393700: returning; I want capability 3 7f9e73393700: resuming capability 3 7f9e73393700: cap 3: running thread 20547 (ThreadRunGHC) 7f9e73393700: cap 3: thread 20547 stopped (suspended while making a foreign call) 7f9e73393700: freeing capability 3 7f9e73393700: returning; I want capability 3 7f9e73393700: resuming capability 3 7f9e73393700: cap 3: running thread 20547 (ThreadRunGHC) 7f9e73393700: cap 3: thread 20547 stopped (suspended while making a foreign call) 7f9e73393700: freeing capability 3 7f9e73393700: returning; I want capability 3 7f9e73393700: resuming capability 3 7f9e73393700: cap 3: running thread 20547 (ThreadRunGHC) 7f9e73393700: cap 3: Trying to steal work from other capabilities 7f9e73393700: No sparks stolen 7f9e73393700: cap 3: thread 20547 stopped (finished) 7f9e73393700: giving up capability 3 7f9e73393700: freeing capability 3 7f9e77502700: woken up on capability 3 7f9e77502700: resuming capability 3 7f9e71b90700: woken up on capability 6 Main: internal error: ASSERTION FAILED: file rts/Capability.c, line 637 7f9e71b90700: resuming capability 6 7f9e71b90700: giving up capability 6 (GHC version 7.0.4 for x86_64_unknown_linux) 7f9e71b90700: freeing capability 6 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug 7f9e73b94700: cap 2: thread 20546 stopped (suspended while making a foreign call) 7f9e73b94700: % I wasn't sure whether or not to report this until I investigated further and found what appears to be the same bug reported previously: http://hackage.haskell.org/trac/ghc/ticket/5214 I tried to create a test case but it doesn't cause segfaults. I can't share the program publicly but would be happy to send it to
Re: [GHC] #5552: SIGSEGV in yieldCapability () when using Control.Parallel
#5552: SIGSEGV in yieldCapability () when using Control.Parallel ---+ Reporter: tomt21 |Owner: simonmar Type: bug | Status: new Priority: highest |Milestone: 7.4.1 Component: Runtime System | Version: 7.0.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Comment(by simonmar): Please send me the code: [mailto:marlo...@gmail.com] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5552#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] #5552: SIGSEGV in yieldCapability () when using Control.Parallel
#5552: SIGSEGV in yieldCapability () when using Control.Parallel ---+ Reporter: tomt21 |Owner: simonmar Type: bug | Status: infoneeded Priority: highest |Milestone: 7.4.1 Component: Runtime System | Version: 7.0.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by simonmar): * status: new = infoneeded -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5552#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
[GHC] #5565: ghc reports a bug after interrupt
#5565: ghc reports a bug after interrupt +--- Reporter: kop | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.0.3|Keywords: Interrupt Testcase: | Blockedby: Os: Windows |Blocking: Architecture: x86 | Failure: GHCi crash +--- Two or three times clicking Ctrl+C causes GHCI to type this: ghc.exe: panic! (the 'impossible' happened) (GHC version 7.0.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5565 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] #5552: SIGSEGV in yieldCapability () when using Control.Parallel
#5552: SIGSEGV in yieldCapability () when using Control.Parallel ---+ Reporter: tomt21 |Owner: simonmar Type: bug | Status: new Priority: highest |Milestone: 7.4.1 Component: Runtime System | Version: 7.0.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by simonmar): * status: infoneeded = new Comment: Got the code, thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5552#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] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by simonmar): Wow, there's quite a lot of code here. Simon: we need to review and decide what to do. Somehow this optimisation feels similar to what the simplifier already does with case expressions (eliminating redundant cases, and branches that can't match), and perhaps it ought to be incorporated into the simplifier. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#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] #2947: infix precedence of backtick functions defined in ghci is not reported by :info
#2947: infix precedence of backtick functions defined in ghci is not reported by :info -+-- Reporter: EyalLotem |Owner: Type: bug | Status: new Priority: low |Milestone: 7.4.1 Component: GHCi | Version: 6.10.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by anacrolix): * cc: anacrolix@… (added) * failure: = None/Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2947#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] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by tibbe): It's also similar to what a forward substitution pass at a lower level might do. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:15 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] #5561: assertion overriden by other exceptions
#5561: assertion overriden by other exceptions --+- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler |Version: 7.3 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | --+- Comment(by igloo): We've been debating this on IRC. I think we're all agreed that the current behaviour is correct, in the sense that that's how imprecise exceptions work. But we could fix ''this case'', as above, to behave as expected. The fixed version would still be correct in the sense of imprecise exceptions. It would behave differently to user-defined functions that aren't similarly fixed, although you can already get differences depending on whether GHC decides to inline assertError or not. Note that performance of optimised code won't generally suffer, as normally optimisations mean assert is disabled anyway. Mikolaj and I think it is worth fixing this case. Duncan thinks it will just add to the confusion. Any other opinions? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5561#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] #5563: ANNOUNCE file is from GHC 6.10
#5563: ANNOUNCE file is from GHC 6.10 -+-- Reporter: GregWeber |Owner: Type: bug | Status: infoneeded Priority: normal|Milestone: Component: Compiler | Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * status: new = infoneeded Comment: Which ANNOUNCE file are you looking at? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5563#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] #5545: ($!) not in scope
#5545: ($!) not in scope
--+-
Reporter: daniel.is.fischer |Owner: simonmar
Type: bug| Status: new
Priority: high |Milestone: 7.4.1
Component: GHCi | Version: 7.2.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
--+-
Comment(by marlowsd@…):
commit 6a342059c19c85a929884453806b1727b526df68
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Tue Oct 18 11:31:53 2011 +0100
fix value of this_mod passed to tcRnImports (#5545)
compiler/main/HscMain.lhs|7 +++
compiler/main/InteractiveEval.hs |7 +--
2 files changed, 4 insertions(+), 10 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5545#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] #5554: Strange interaction between -osuf, profiling and TemplateHaskell
#5554: Strange interaction between -osuf, profiling and TemplateHaskell
-+--
Reporter: iustin| Owner:
Type: bug | Status: new
Priority: normal| Component: Template Haskell
Version: 7.2.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by marlowsd@…):
commit c489af738b4a4999ca110fe5dcf7944d119f
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Tue Oct 18 13:23:29 2011 +0100
fix the object suffix when using TH with profiling (#5554)
compiler/ghci/Linker.lhs | 49
+
1 files changed, 27 insertions(+), 22 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5554#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] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: simonpj Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Changes (by igloo): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:16 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] #5545: ($!) not in scope
#5545: ($!) not in scope +--- Reporter: daniel.is.fischer | Owner: simonmar Type: bug| Status: closed Priority: high | Milestone: 7.4.1 Component: GHCi |Version: 7.2.1 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | +--- Changes (by simonmar): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5545#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] #5554: Strange interaction between -osuf, profiling and TemplateHaskell
#5554: Strange interaction between -osuf, profiling and TemplateHaskell ---+ Reporter: iustin| Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.4.1 Component: Template Haskell |Version: 7.2.1 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by simonmar): * status: new = closed * resolution: = fixed * milestone: = 7.4.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5554#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] #5546: Documentation errors in Control.Exception.Base
#5546: Documentation errors in Control.Exception.Base
-+--
Reporter: bit | Owner: simonmar
Type: bug | Status: closed
Priority: high| Milestone: 7.4.1
Component: libraries/base |Version: 7.2.1
Resolution: fixed | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
{{{
commit 530fa0b23ed414ef3442803baf107d7a646b35f2
Author: Simon Marlow marlo...@gmail.com
Date: Tue Oct 18 10:42:04 2011 +0100
fix cross-ref to Catching all exceptions section (#5546)
}}}
{{{
commit 1dd55b30cdbcd13d581ee533e527b9098b770e96
Author: Simon Marlow marlo...@gmail.com
Date: Tue Oct 18 10:42:31 2011 +0100
update ref to deprecated function forkIOUnmasked - forkIOWithUnmask
(#5546)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5546#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] #5547: Control.Concurrent documentation
#5547: Control.Concurrent documentation
+---
Reporter: guest | Owner: simonmar
Type: bug| Status: closed
Priority: high | Milestone: 7.4.1
Component: Documentation |Version: 7.2.1
Resolution: fixed | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
{{{
commit 4b5dc77567db7458b0ea2de48d2f68e33bb0cb9d
Author: Simon Marlow marlo...@gmail.com
Date: Tue Oct 18 10:48:48 2011 +0100
update IO manager documentation (#5547)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5547#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] #5558: Deadlock using unsafePerformIO to create a global MVar
#5558: Deadlock using unsafePerformIO to create a global MVar --+- Reporter: int-e| Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Runtime System |Version: 7.2.1 Resolution: fixed| Keywords: Testcase: concurrent/should_run/5558 | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | --+- Changes (by simonmar): * status: new = closed * testcase: = concurrent/should_run/5558 * resolution: = fixed Comment: test added -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5558#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] #5565: ghc reports a bug after interrupt
#5565: ghc reports a bug after interrupt
--+-
Reporter: kop|Owner:
Type: bug| Status: new
Priority: normal |Milestone:
Component: GHCi | Version: 7.0.3
Keywords: Interrupt | Testcase:
Blockedby: | Difficulty:
Os: Windows| Blocking:
Architecture: x86| Failure: GHCi crash
--+-
Description changed by igloo:
Old description:
Two or three times clicking Ctrl+C causes GHCI to type this:
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
New description:
Two or three times clicking Ctrl+C causes GHCI to type this:
{{{
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5565#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] #5565: ghc reports a bug after interrupt
#5565: ghc reports a bug after interrupt --+- Reporter: kop|Owner: Type: bug| Status: new Priority: normal |Milestone: Component: GHCi | Version: 7.0.3 Keywords: Interrupt | Testcase: Blockedby: | Difficulty: Os: Windows| Blocking: Architecture: x86| Failure: GHCi crash --+- Comment(by igloo): Thanks for the report. So just to check: You didn't background ghci (e.g. press `^Z`) at any point, right? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5565#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] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments
#5529: Newtypes with hidden constructors cannot be passed as FFI arguments ---+ Reporter: mikhail.vorozhtsov |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple| Blocking: Architecture: Unknown/Multiple| Failure: None/Unknown ---+ Comment(by simonmar): Replying to [comment:4 mikhail.vorozhtsov]: That's not exactly correct. The C code depends on the ''particular'' way the argument is represented (e.g. passing Int64 instead of Int32 is a bad idea), but what GHC checks is a general representability (Int64/Int32/Float/..., it doesn't matter as long as it fits the calling convention) of the type. Constructor exporting is just an overkill for that task. What we need is a way to mark (with corresponding C types) appropriate newtypes as being representable (e.g. automatically by the compiler in module interfaces, or by requesting derivation of a special type class) without forcing users to spill the guts and when invent conventions for not hurting themselves (yes, we export the internals, but never use them in your code, they are here only to pass FFI checks). I don't understand. Using a newtype in a foreign call exposes its representation, because it only works if you match the representation type with the type expected by the C function. So marking newtypes as representable doesn't help - you really have to know the representation. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5529#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
[GHC] #5566: instance decls via TH: dropped methods and stack overflows
#5566: instance decls via TH: dropped methods and stack overflows
-+--
Reporter: FSalad| Owner:
Type: bug | Status: new
Priority: normal| Component: Template Haskell
Version: 7.2.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
{{{
{-# LANGUAGE TemplateHaskell #-}
class C a where
c :: a
$([d| instance C Int where c = 0 |] )
data D = D
$([d| instance C D where c = D |] )
$([d| instance Show D where show _ = D |] )
}}}
Loading this into GHCI:
{{{
/tmp/Foo.hs:6:3:
Warning: No explicit method nor default method for `c'
In the instance declaration for `C Int'
/tmp/Foo.hs:10:3:
Warning: No explicit method nor default method for `c'
In the instance declaration for `C D'
Ok, modules loaded: Main.
ghci c :: Int
*** Exception: /tmp/Foo.hs:6:3-35: No instance nor default method for
class operation Main.c
ghci c :: D
*** Exception: stack overflow
ghci show D
*** Exception: stack overflow
ghci
}}}
I also tried putting C and/or D into separate modules, to no effect.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5566
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] #5566: instance decls via TH: dropped methods and stack overflows
#5566: instance decls via TH: dropped methods and stack overflows -+-- Reporter: FSalad| Owner: Type: bug | Status: new Priority: normal| Component: Template Haskell Version: 7.2.1 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime -+-- Changes (by FSalad): * failure: None/Unknown = Incorrect result at runtime -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5566#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] #5563: ANNOUNCE file is from GHC 6.10
#5563: ANNOUNCE file is from GHC 6.10 -+-- Reporter: GregWeber |Owner: Type: bug | Status: infoneeded Priority: normal|Milestone: Component: Compiler | Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by GregWeber): in the ghc repo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5563#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] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments
#5529: Newtypes with hidden constructors cannot be passed as FFI arguments ---+ Reporter: mikhail.vorozhtsov |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple| Blocking: Architecture: Unknown/Multiple| Failure: None/Unknown ---+ Comment(by mikhail.vorozhtsov): Yes, that's why I said that types should be marked with corresponding C types (maybe tagged would be a better word). When a programmer matches newtypes from other Haskell libraries with the types of arguments of the C function he wants to import, he does it by '''name'''. '''I''' don't need to know how exactly, say, CTime is represented to match it with time_t, '''compiler''' does. My point is that while exporting constructors does expose representation to GHC's FFI checking code, it also exposes it to programmers that use the module. And I don't think that the former should require/force the latter. I want to have control over the export list, compiler can use other means of making representation accessible to it's own code. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5529#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
[GHC] #5567: LLVM: Improve alias analysis / performance
#5567: LLVM: Improve alias analysis / performance -+-- Reporter: dterei| Owner: dterei Type: task | Status: new Priority: normal| Component: Compiler (LLVM) Version:|Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- * LLVM doesn't generate as good as code as we feel it should in many situations * Why? * We've often felt its a alias anlysis issue. * I'm a little more doubtful of that than others (I feel its part of the bigger problem, not the whole thing). * I think there may be some register allocation / instruction selection / live range splitting issue going on. * We could also do with looking at what optimisation passes we should run and in what order... Here is some work Max did on the alias issue, his results for nofib weren't good: http://blog.omega-prime.co.uk/?p=135 So this ticket is just a high level ticket about figuring out and improving the performance of LLVM backend. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5567 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] #5567: LLVM: Improve alias analysis / performance
#5567: LLVM: Improve alias analysis / performance -+-- Reporter: dterei| Owner: dterei Type: task | Status: new Priority: normal| Component: Compiler (LLVM) Version:|Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by dterei): http://dterei.blogspot.com/2011/09/ghc-project-for-all.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5567#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] #5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions
#5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions --+- Reporter: erikd | Owner: dterei Type: task | Status: closed Priority: normal| Component: Compiler (LLVM) Version: 7.3 | Resolution: wontfix Keywords:| Testcase: Blockedby:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by dterei): * status: patch = closed * resolution: = wontfix -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5506#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] #5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions
#5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions --+- Reporter: erikd | Owner: dterei Type: task | Status: closed Priority: normal| Component: Compiler (LLVM) Version: 7.3 | Resolution: wontfix Keywords:| Testcase: Blockedby:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | --+- Comment(by dterei): Apparently there are some other people working on this Erik (as in vector support in Haskell through LLVM), Manuel knows the details if you want to get involved. So closing this patch / ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5506#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] #5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions
#5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions --+- Reporter: erikd | Owner: dterei Type: task | Status: closed Priority: normal| Component: Compiler (LLVM) Version: 7.3 | Resolution: wontfix Keywords:| Testcase: Blockedby:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | --+- Comment(by dterei): http://hackage.haskell.org/trac/ghc/wiki/SimdLlvm -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5506#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] #5567: LLVM: Improve alias analysis / performance
#5567: LLVM: Improve alias analysis / performance -+-- Reporter: dterei| Owner: dterei Type: task | Status: new Priority: normal| Component: Compiler (LLVM) Version:|Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by dterei): http://llvm.org/bugs/show_bug.cgi?id=1512 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5567#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] #3753: Make ghci's -l option consistent with GNU ld's -l option
#3753: Make ghci's -l option consistent with GNU ld's -l option -+-- Reporter: hgolden |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.4.1 Component: GHCi | Version: 6.12.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by dtrebbien): * cc: dtrebbien@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3753#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: Discussion about the ConstraintKinds extension
On 18 October 2011 02:25, bob zhang bobzhang1...@gmail.com wrote:
take a contrived example,
class C B = B a where
here B :: * - Constraint, I think this definition is reasonable,
since B does not appears in the
first position of the context.
I think you are getting an error where GHC complains about a
superclass cycle. I think this warning is necessary: after all, I
could write the following definition for C:
class c Int = C c where
Now I really do have a cycle!
You are right to say that *some* Cs are OK though. In particular, in a
class C c if you don't mention c in the superclasses there can't be
a cycle. In fact, the same observation might make sense for detecting
type synonym cycles. Perhaps we could allow:
type Foo a = Int
type Bar = Foo Bar
I could change the superclass-cycle check to only reject cycles that
actually cause cycles after expansion. So with my proposed C:
1. Input: C B = B a. DontExpand = {B}
2. Substitute: B Int = B a. DontExpand = {B,C}
We can't expand further. This is a real cycle and would be rejected.
With a different C:
class Eq Int = C c where
1. Input: C B = B a. DontExpand = {B}
2. Substitute: Eq Int = B a. DontExpand = {B,C}
3. Substitute: () = B a. DontExpand = {B, C, Eq}
Again we can't expand further, but this time it is because we have
reached (). B would not be rejected.
I think relaxing the check in this manner would be safe. Would this
change be enough for you to do what you need?
Max
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implementing a new Primop, stage1 panic
On 17/10/2011 20:11, Paul Monday wrote:
Fascinating! I added the switch, figured I needed to clean everything to
see the whole stack and whammo, everything worked.
I wonder if the build is missing a dependency check along the way, I'll
have to keep a close eye as I modify files now.
Thanks for the tip!
I think adding a primop is something that does need a 'make clean', at
least in the libraries and stage2. The reason is that you changed the
interface to GHC.Prim, which is a magic internal module in GHC, and GHC
doesn't track changes to that module. In principle GHC itself should
generate a hash of the contents of GHC.Prim so that it could recompile
correctly when the contents of GHC.Prim changes, but currently I think
it just uses zero for the hash.
I've just added this to the end of
http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations
Cheers,
Simon
Paul Monday
Parallel Scientific, LLC.
paul.mon...@parsci.com mailto:paul.mon...@parsci.com
On Oct 17, 2011, at 8:00 AM, Simon Peyton-Jones wrote:
Paul
Always switch on -dcore-lint; it’s a self-checker for types, and
usually nails an error much closer to the source.
Simon
*From:*glasgow-haskell-users-boun...@haskell.org
mailto:glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org]*On Behalf Of*Paul
Monday
*Sent:*16 October 2011 16:54
*To:*glasgow-haskell-users@haskell.org
mailto:glasgow-haskell-users@haskell.org
*Subject:*Implementing a new Primop, stage1 panic
(Reposting since this got cross-posted sort of oddly and I wasn't
subscribed yet)
I'm having an odd problem as I try to define my own primop, it seems
that some docs may be out of date with respect to all of the touch
points for a simple primop addition. I've followed what the various
wiki pages have to offer (primarily
http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations
and
http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps)without
success. I even unraveled my PrimOp to be, basically, an exact copy of
another PrimOp without luck.
The primop I'm attempting to add is now very, very simple and copies
FloatAddOp exactly so there must be an additional file I have to
modify before the primop is completely added.
Here are my simple modifications:
./compiler/prelude/primops.txt.pp
primop FloatVAddOp plusFloatVec# Dyadic
Float# - Float# - Float#
with commutable = True
./compiler/codeGen/CgPrimOp.hs
translateOp FloatVAddOp= Just (MO_F_Add W32)
The compiler error is below. I have the feeling that an interface is
not being built somewhere … this must be a simple one but I can't find
any references to this error anywhere … has anyone seen this one
before?
inplace/bin/ghc-stage1 -H64m -O0 -fasm -package-name
ghc-7.3.20111007 -hide-all-packages -i -icompiler/basicTypes
-icompiler/cmm -icompiler/codeGen -icompiler/coreSyn
-icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface
-icompiler/llvmGen -icompiler/main -icompiler/nativeGen
-icompiler/parser -icompiler/prelude -icompiler/profiling
-icompiler/rename -icompiler/simplCore -icompiler/simplStg
-icompiler/specialise -icompiler/stgSyn -icompiler/stranal
-icompiler/typecheck -icompiler/types -icompiler/utils
-icompiler/vectorise -icompiler/stage2/build
-icompiler/stage2/build/autogen -Icompiler/stage2/build
-Icompiler/stage2/build/autogen -Icompiler/../libffi/build/include
-Icompiler/stage2 -Icompiler/../libraries/base/cbits
-Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser
-Icompiler/utils -optP-DGHCI -optP-include
-optPcompiler/stage2/build/autogen/cabal_macros.h -package
Cabal-1.11.2 -package array-0.3.0.3 -package base-4.4.0.0 -package
bin-package-db-0.0.0.0 -package bytestring-0.9.2.0 -package
containers-0.4.2.0 -package directory-1.1.0.1 -package
filepath-1.2.0.1 -package hoopl-3.8.7.2 -package hpc-0.5.1.0 -package
old-time-1.0.0.7 -package process-1.1.0.0 -package
template-haskell-2.6.0.0 -package unix-2.5.0.0 -Wall
-fno-warn-name-shadowing -fno-warn-orphans -XHaskell98
-XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples
-XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls
-XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances
-XRank2Types -XScopedTypeVariables
-XDeriveDataTypeable-DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm
-no-user-package-conf -rtsopts -odir compiler/stage2/build -hidir
compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf o
-hcsuf hc -c compiler/iface/BinIface.hs -o
compiler/stage2/build/BinIface.o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.3.20111007 for x86_64-unknown-linux):
applyTypeToArgs
ghc-prim:GHC.Prim.sizeofMutableArray#{(w) v 91V} [gid[PrimOp]]
@ e{tv i4L2} [tv] ds{v i4Lc} [lid] i#{v i4Lg} [lid]
forall a{tv 12} [tv].
ghc-prim:GHC.Prim.MutableArray#{(w) tc 31m}
e{tv i4L2} [tv] a{tv 12} [tv]
- ghc-prim:GHC.Prim.Int#{(w) tc 3G}
Paul Monday
Parallel Scientific, LLC.
paul.mon...@parsci.com mailto:paul.mon...@parsci.com
Re: Discussion about the ConstraintKinds extension
Hi, Max
Thanks for your reply.
I don't understand your proposal, or can you elaborate on it?
Let's double check,
In my contrived example the definition of class C is like this
class C c where { foo :: c Int = }
class C B = B a where { ...}
will this pass under your proposal?
It will bring much more power if this could pass.
plz let me know if it is committed into the source tree.
Many thanks
On Tue, Oct 18, 2011 at 2:42 AM, Max Bolingbroke batterseapo...@hotmail.com
wrote:
On 18 October 2011 02:25, bob zhang bobzhang1...@gmail.com wrote:
take a contrived example,
class C B = B a where
here B :: * - Constraint, I think this definition is reasonable,
since B does not appears in the
first position of the context.
I think you are getting an error where GHC complains about a
superclass cycle. I think this warning is necessary: after all, I
could write the following definition for C:
class c Int = C c where
Now I really do have a cycle!
You are right to say that *some* Cs are OK though. In particular, in a
class C c if you don't mention c in the superclasses there can't be
a cycle. In fact, the same observation might make sense for detecting
type synonym cycles. Perhaps we could allow:
type Foo a = Int
type Bar = Foo Bar
I could change the superclass-cycle check to only reject cycles that
actually cause cycles after expansion. So with my proposed C:
1. Input: C B = B a. DontExpand = {B}
2. Substitute: B Int = B a. DontExpand = {B,C}
We can't expand further. This is a real cycle and would be rejected.
With a different C:
class Eq Int = C c where
1. Input: C B = B a. DontExpand = {B}
2. Substitute: Eq Int = B a. DontExpand = {B,C}
3. Substitute: () = B a. DontExpand = {B, C, Eq}
Again we can't expand further, but this time it is because we have
reached (). B would not be rejected.
I think relaxing the check in this manner would be safe. Would this
change be enough for you to do what you need?
Max
--
Best, bob
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Two Proposals
For example the following code fragments read well: then group inits then group permutations then group subsequences then group tails Yes... not quite so well with the by variants. What would we say? then group initsBy by x But following the aforementioned naming convention the groupWith function could as well be named as equals. Now this reads well: then group equals by e Good idea. But equals is a terribly over-used word; I think using it would cause confusion. How about equalities, or equivalents :: [a] - [[a]] I don't think we can steal group as a keyword -- it's a function exported by Data.List, and I don't think the benefit justifies the cost. Simon From: George Giorgidze [mailto:giorgi...@gmail.com] Sent: 10 October 2011 23:22 To: Simon Peyton-Jones; GHC Users List; Philip Wadler Subject: Re: Two Proposals A quick thought that came to me after hoogling [a] - [[a]]. The first four functions in the search result are named after what they return (noun in plural) rather than what they do (verb). I am talking about inits, permutations, subsequence and tails. So I thought the following syntax might work as well if (as it is already common) grouping functions are named after what they return. then f then f by e then group f then group f by e For example the following code fragments read well: then group inits then group permutations then group subsequences then group tails Here we use the special identifier group as a verb. I have not told you about the fifth result of the hoogling, the groupWith function. The following really looks ugly: then group groupWith by e But following the aforementioned naming convention the groupWith function could as well be named as equals. Now this reads well: then group equals by e Cheers, George On 2011-Oct-5, at 09:14 , Simon Peyton-Jones wrote: [adding ghc-users] It's not easy, Phil. Do you have any ideas? For the 'then' case the name of the function serves as the verb. One might say then take 4 or then takeWhile by salary 40 For grouping one might like to say the same thing, such as then groupBy by salary but the typing rule is quite different, so we really need a different keyword. We chose the compound keyword then group to avoid needing a whole new keyword (group is treated specially only in tthis context). So you write then group by salary using groupBy Using this order of the pieces for the sorting case is harder. What would one say? then process? Like this? then process by salary 40 using takeWhile Not very nice. One could use a new keyword for grouping theng say, thus: theng groupBy by salary But that is hardly beautiful either. So the current story is not great, but it's the best I could think of. Improvements welcome. Simon | -Original Message- | From: Philip Wadler [mailto:wad...@inf.ed.ac.uk] | Sent: 04 October 2011 18:15 | To: Simon Peyton-Jones; George Giorgidze | Subject: Re: FW: Two Proposals | | George, | | Nice proposal. I like the idea of symmetry, but don't at all like the | idea that f comes before e for 'then' but f comes after e for 'then | group'. Can you rethink it and come up with something even more | symmetric? | | Yours, -- P | | | On Tue, Oct 4, 2011 at 9:23 AM, Simon Peyton-Jones | simo...@microsoft.commailto:simo...@microsoft.com wrote: | FYI | | -Original Message- | From: glasgow-haskell-users-boun...@haskell.orgmailto:glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of George Giorgidze | Sent: 30 September 2011 18:28 | To: glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org | Subject: Two Proposals | | GHC Users, | | I would like to make to the following two proposals: |* Eliminate the default grouping close from SQL-like comprehensions |* Introduce a GHC extension for list literal overloading | | OK, let me start with the first proposal. | | Currently, the SQL-like comprehension notation (both in its list comprehension | and monad comprehension variants) features the following five clauses: | | then f | then f by e | then group by e | then group using f | then group by e using f | | The first two clauses are used for specifying transformations of type [a] - [a] | (or Monad m = m a- m a for monad comprehensions). The following three | clauses are used for specifying transformations of type [a] - [[a]] (or Monad m, | Functor f = m a - m (f a) for monad comprehensions). See [1] for further | details. | | Note that the third clause does not mention which function is used for grouping. | In this case GHC.Exts.groupWith function is used as a default for list | comprehensions and the mgroupWith function from the MonadGroup class is used | as a default for monad comprehensions. | | I would like to suggest to remove the
[Haskell] haskell.org committee: Call for nominations
Dear Haskellers, The first year of the haskell.org committee is drawing to a close and it is therefore time to seek replacements for those members whose term is expiring. This year two members are retiring, Ian Lynagh and Malcolm Wallace. The rest of the committee would like to thank them for their excellent service, both from the time before the committee was formed when they amongst the people who handled similar responsibilities on a more informal basis, and over the last year. To nominate yourself, please send an e-mail to committee at haskell.org by 29 October 2011. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. More details about the committee's roles and responsibilities are on http://www.haskell.org/haskellwiki/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org or to contact one of us individually. We will shortly also be producing a report and accounts covering the first year of operation of the committee. Regards, Ganesh On behalf of the haskell.org committee ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Fwd: GHC as a library error.
The release notes say: The type of defaultErrorHandler has changed. In particular, this means that you will normally want to pass it defaultLogAction instead of defaultDynFlags. (http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/release-7-2-1.html). defaultLogAction is in the DynFlags module, reexported by GHC. I haven't tried it yet, though. Unfortunately the documentation about using GHC as an API is often not up to date. Even the API documentation is wrong: for example, the documentation for the load function talks about a reportModuleCompilationResult callback that doesn't exist any more, and the release notes do not explain the changes to the load function (loadWithLogger gone, etc). You can look at the projects using the GHC API for inspiration, for example the Scion library. JP On Tue, Oct 18, 2011 at 12:34 AM, Paulo Pocinho poci...@gmail.com wrote: Forwarding to Haskell-Cafe: I'm trying GHC as a library, as documented in: http://www.haskell.org/haskellwiki/GHC/As_a_library http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/ghc-as-a-library.html However, this code: import GHC import GHC.Paths ( libdir ) import DynFlags ( defaultDynFlags ) main = defaultErrorHandler defaultDynFlags $ do runGhc (Just libdir) $ do dflags - getSessionDynFlags setSessionDynFlags dflags target - guessTarget test_main.hs Nothing setTargets [target] load LoadAllTargets Produces: Couldn't match expected type `Severity' with actual type `DynFlags.Settings' Expected type: DynFlags.LogAction Actual type: DynFlags.Settings - DynFlags In the first argument of `defaultErrorHandler', namely `defaultDynFlags' In the expression: defaultErrorHandler defaultDynFlags How can I fix it? Note: this was on a fresh install with latest stable GHC installer 7.2.1. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
On 10/18/2011 01:30 AM, Conrad Parker wrote: And I often work with mixed text/binary data (eg. text annotations in video streams). I'd want the Show/Read instances to be in the form of a hexdump with char representation alongside (like xxd or od -xc output). It roundtrips well, so why not? :-) (slightly out of topic ...) I often do mixed text/binary too, and i now use the following package: http://hackage.haskell.org/package/bytedump The problem with a Show instance is that there's no way to configure some aspects of it :-) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] About the ConstraintKinds extension
On 18 October 2011 02:17, bob zhang bobzhang1...@gmail.com wrote: But I found a problem which I thought would be made better, plz correct me if I am wrong For those who only subscribe to Haskell-Cafe, Bob posted a very similar thread to ghc-users, which I replied to here with a suggestion for how we could relax the superclass-cycle check: http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/20828/focus=20829 Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Waiting on input with `hWaitForInput' or `threadWaitRead'
On Tue, Oct 18, 2011 at 3:18 AM, Jason Dusek jason.du...@gmail.com wrote: The lazy bridging code, `lazyBridge', blocks (unsurprisingly) and does not allow packets to go back and forth. I think I need explicit selects/waits here to get the back and forth traffic. Maybe there is a some way to leverage GHC's internal async I/O but I'm not sure how to do it. Maybe: forkIO two threads, one for the read end, one for the write end? I would use a loop over lazy I/O, also. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: GHC as a library error.
Thank you for the heads up; didn't know about the Scion library. Cheers! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Waiting on input with `hWaitForInput' or `threadWaitRead'
Jason Dusek jason.du...@gmail.com wrote: I don't think you want either of the functions you mentioned. What you probably want instead is to do concurrent programming by creating Haskell threads. A hundred Haskell threads reading from Handles are translated to one or more OS threads using whatever polling mechanism (select(), poll(), epoll) your operating system supports. I have uploaded a simple concurrent echo server implementation to hpaste [1]. It uses one thread for the stdout logger, one thread for the server, one thread for each client and finally a main thread waiting for you to hit enter to quit the application. [1] http://hpaste.org/52742 - Concurrent echo server with logger I am not sure how to apply the principle you mention to a proxy, which must read from and write to both handles in turn (or, ideally, as needed). A proxy server acts a lot like an echo server. The difference is that usually before the actual proxying starts you have a negotiation phase, and instead of echoing back to the same socket, you just write it to a different one. Here is an (untested) example: (clientH, clientHost, clientPort) - accept serverSock destH - negotiate clientH doneVar - newEmptyMVar forkIO (hGetContents clientH = hPutStr destH = putMVar doneVar) forkIO (hGetContents destH = hPutStr clientH = putMVar doneVar) replicateM_ 2 (takeMVar doneVar) mapM_ hClose [clientH, destH] Of course this code is going to bite you in production for two reasons: First of all it has no error handling. If the 'negotiate' function throws an exception, then nobody will close the client handle. So view this is a highly simplified example! The second reason is that in this lazy I/O framework it is extraordinarily difficult to write the 'negotiate' function in the first place, unless you allow yourself to put stuff back into the handle or process only one byte at a time. Both options are bad. A better option is to use a proper I/O abstraction suitable for protocol processing. Iteratees [1] come to mind. They solve this problem elegantly and let you really just use the parser style destH - negotiate. My usage of the MVar is actually kind of an abuse. I just use it to allow the two forwarder threads to signal their completion. The main thread just waits for the two to complete and then closes both handles. The word abuse is perhaps too strong, because there is essentially nothing wrong with the approach. The standard concurrency library doesn't provide an event primitive, so the more general MVar is often used for this. [1] http://www.yesodweb.com/book/enumerator Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Waiting on input with `hWaitForInput' or `threadWaitRead'
Michael Orlitzky mich...@orlitzky.com wrote: I have uploaded a simple concurrent echo server implementation to hpaste [1]. It uses one thread for the stdout logger, one thread for the server, one thread for each client and finally a main thread waiting for you to hit enter to quit the application. [1] http://hpaste.org/52742 - Concurrent echo server with logger This is a good example; you should stick it on the wiki somewhere so it isn't lost. It is a good example for concurrent programming, but not a good example for server programming. By putting it into the wiki I would discourage some programmers from using more suitable I/O abstractions/mechanisms. Better let's keep it away from the wiki. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 12.10.2011 16:02, schrieb Bas van Dijk:
API DOCS
http://hackage.haskell.org/package/vector-bytestring-0.0.0.0
you could re-export VS.empty, VS.singleton, etc. directly.
Cheers Christian
-- | /O(1)/ The empty 'ByteString'
empty :: ByteString
empty = VS.empty
{-# INLINE empty #-}
-- | /O(1)/ Convert a 'Word8' into a 'ByteString'
singleton :: Word8 - ByteString
singleton = VS.singleton
{-# INLINE [1] singleton #-} -- Inline [1] for intercalate rule
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
2011/10/18 Christian Maeder christian.mae...@dfki.de: you could re-export VS.empty, VS.singleton, etc. directly. The vector singleton and the vector-bytestring singleton don't have the same type. vector: singleton :: a - Vector a vector-bytestring: singleton :: Word8 - Vector Word8 By choosing the more general type you risk that a previously correct program becomes ambiguous. (When migrating from bytestring to vector-bytestring). I'm not sure if this will actually occur in practive or that it holds for all the little functions that you could theoretically re-export directly. Maybe we create an example program which would fail with the more general type. Proving the opposite (that the more general type is always safe) will be more difficult. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hello Haskell
hey Haskell check it out http://www.fastnews10i.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
2011/10/18 Roel van Dijk vandijk.r...@gmail.com: Maybe we [can] create an example program which would fail with the more general type. Migrating the function foo from bytestring to vector-bytestring would fail with more general types: import Data.ByteString foo = print empty Ok, modules loaded: Test. With vector: import Data.Vector.Storable foo = print empty Ambiguous type variable `a0' in the constraints: (Show a0) arising from a use of `print' at /home/roelvandijk/development/test.hs:5:7-11 (Storable a0) arising from a use of `empty' at /home/roelvandijk/development/test.hs:5:13-17 Probable fix: add a type signature that fixes these type variable(s) In the expression: print empty In an equation for `foo': foo = print empty Failed, modules loaded: none. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Working with the code For Typing Haskell In Haskell
Hi all, I'm working with the code that accompanies this paper (http://web.cecs.pdx.edu/~mpj/thih/) and I'm trying to use it but I can't figure out how to get started. I have the following code but it is not giving me the expected result: import TypingHaskellInHaskell mapt = map :: Forall [Star, Star] ([] := ((TGen 0 `fn` TGen 1) `fn` TAp tList (TGen 0) `fn` TAp tList (TGen 1))) idt = id :: Forall [Star] ([] := (TGen 0 `fn` TGen 0)) exprt = Ap (Const mapt) (Const idt) test = runTI $ tiExpr initialEnv [] exprt When I execute the test function above in ghci I get: ([],TVar (Tyvar v3 Star)). I was expecting someting like below for the type part: TAp tList (TGen 0) `fn` TAp tList (TGen 0) What I want is the library to compute for me the type of map id. What is the proper way to achieve this? Has anybody on the list worked with this code before? Thanks as lot, Patrick -- = Patrick LeBoutillier Rosemère, Québec, Canada ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Comparison Haskell, Java, C and LISP
Hi, Maybe you remember my case. I was trying to compare some aspects of these languages. Well... I found that I can compare reflection, support for generics, simplicity and safe code. I just want to ask if you have more information for reflection in Haskell. I read that there is no enough for dynamics to support complete reflection. I hope someone can help me this time :) Julita ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hello Haskell
On Tue, Oct 18, 2011 at 9:23 AM, R J rj248...@hotmail.com wrote: hey Haskell check it out http://www.fastnews10i.com OK, who has the ban hammer? G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comparison Haskell, Java, C and LISP
Haskell has no support for reflection whatsoever. It can support compile time meta-programming with Template Haskell. Reflection itself might be antagonistic to functional programming, I suspect it is at odds with referential transparency. Most of the work on reflection seemed based around Lisp / Scheme - Christian Queinnec's reflective interpreter in Lisp in Small Pieces uses an awful lot of set! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Waiting on input with `hWaitForInput' or `threadWaitRead'
2011/10/18 Ertugrul Soeylemez e...@ertes.de: A proxy server acts a lot like an echo server. The difference is that usually before the actual proxying starts you have a negotiation phase, and instead of echoing back to the same socket, you just write it to a different one. Here is an (untested) example: (clientH, clientHost, clientPort) - accept serverSock destH - negotiate clientH doneVar - newEmptyMVar forkIO (hGetContents clientH = hPutStr destH = putMVar doneVar) forkIO (hGetContents destH = hPutStr clientH = putMVar doneVar) replicateM_ 2 (takeMVar doneVar) mapM_ hClose [clientH, destH] This code seems like it says: Allow the client to write to the server one time. Allow the server to write to the client one time. Teardown both sides of the connection. Am I reading this correctly? This is, indeed, a proxy; but I'm not sure it could support a wide range of protocols. -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Waiting on input with `hWaitForInput' or `threadWaitRead'
2011/10/18 Gregory Collins g...@gregorycollins.net: On Tue, Oct 18, 2011 at 3:18 AM, Jason Dusek jason.du...@gmail.com wrote: The lazy bridging code, `lazyBridge', blocks (unsurprisingly) and does not allow packets to go back and forth. I think I need explicit selects/waits here to get the back and forth traffic. Maybe there is a some way to leverage GHC's internal async I/O but I'm not sure how to do it. Maybe: forkIO two threads, one for the read end, one for the write end? I would use a loop over lazy I/O, also. This does work, thanks; the new version of lazyBridge is: lazyBridge :: Handle - Handle - IO () lazyBridge a b = do forkIO (flush a b) forkIO (flush b a) return () where flush a b = LazyB.hGetContents a = LazyB.hPut b -- http://hpaste.org/52814 I am kind of surprised that this works at all, actually. The strict version has this problem where it lets each socket takes turns sending and receiving, if you try to send and it's not your turn, it waits for the other one to send before sending your data. The lazy version just sends bytes as they become available, the desired behaviour. I guess if I wanted to instrument the proxying, to keep a tally of how much traffic there was (to GC little used connections, for example), I would need to move up to enumerators? -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Waiting on input with `hWaitForInput' or `threadWaitRead'
2011/10/18 Jason Dusek jason.du...@gmail.com: 2011/10/18 Ertugrul Soeylemez e...@ertes.de: A proxy server acts a lot like an echo server. The difference is that usually before the actual proxying starts you have a negotiation phase, and instead of echoing back to the same socket, you just write it to a different one. Here is an (untested) example: (clientH, clientHost, clientPort) - accept serverSock destH - negotiate clientH doneVar - newEmptyMVar forkIO (hGetContents clientH = hPutStr destH = putMVar doneVar) forkIO (hGetContents destH = hPutStr clientH = putMVar doneVar) replicateM_ 2 (takeMVar doneVar) mapM_ hClose [clientH, destH] This code seems like it says: [...] After working through Gregory Collins suggestion, above, I see that I was not reading your code correctly. -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comparison Haskell, Java, C and LISP
Am 18.10.2011 18:53, schrieb Stephen Tetley: Haskell has no support for reflection whatsoever. It can support compile time meta-programming with Template Haskell. Reflection itself might be antagonistic to functional programming, I suspect it is at odds with referential transparency. Most of the work on reflection seemed based around Lisp / Scheme - Christian Queinnec's reflective interpreter in Lisp in Small Pieces uses an awful lot of set! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe But is (delimited) continuation not a kind of reflection? Nicu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] subclasses and classes with same type in instance
On 11-10-16 01:56 PM, Patrick Browne wrote: I get the same results from Listing 1 and Listing 2 below. I carefully diff'ed the two listings and found no difference except for comments. -- Listing 1- Subclass data Shed = Shed class Building building where addressB :: building - Integer addressB b = 1 -- subclass, but none in Listing 2 class Building house = House house where addressH :: house - Integer addressH b = 0 instance Building Shed where instance House Shed where -- Listing 2 -- No subclass data Shed = Shed class Building building where addressB :: building - Integer addressB b = 1 -- No subclass class Building house = House house where addressH :: house - Integer addressH b = 0 instance Building Shed where instance House Shed where ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
Hi John,
Thanks for this reply:
Date: Tue, 18 Oct 2011 14:05:22 +1030
From: John Lask jvl...@hotmail.com
Subject: Re: [Haskell-cafe] How to implement a digital filter, using
Arrows?
To: haskell-cafe@haskell.org
Message-ID: BLU0-
smtp384394452fd2750fbe3bcfcc6...@phx.gbl
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
your function corresponds with Control.Arrow.Transformer.Automaton. If
you frame your function is such most of your plumbing is taken care of.
Following your advice, I arrived at:
1 {-# LANGUAGE Arrows, GeneralizedNewtypeDeriving, FlexibleContexts #-}
2
3 module Filter (
4 FilterState
5 , Filter
6 , applyFilter
7 , convT
8 ) where
9
10 import EitherT
11 import Control.Monad
12 import Control.Monad.State
13 import Control.Arrow
14 import Control.Arrow.Operations
15 import Control.Arrow.Transformer
16 import Control.Arrow.Transformer.All
17 import Data.Stream as DS (fromList, toList)
18
19 -- tap weights, `as' and `bs', are being made part of the filter state,
in
20 -- order to accomodate adaptive filters (i.e. - DFEs).
21 data FilterState a = FilterState {
22 as :: [a] -- transfer function denominator coefficients
23 , bs :: [a] -- transfer function numerator coefficients
24 , taps :: [a] -- current delay tap stored values
25 }
26
27 -- Future proofing the implementation, using the `newtype' trick.
28 newtype Filter b c = F {
29 runFilter :: (b, FilterState b) - (c, FilterState b)
31 }
32
33 -- Time domain convolution filter (FIR or IIR),
34 -- expressed in direct form 2
35 convT :: (Num b) = Filter b b
36 convT = F $ \(x, s) -
37 let wk = (x - sum [a * t | (a, t) - zip (tail $ as s) (taps s)])
38 newTaps = wk : ((reverse . tail . reverse) $ taps s)
39 s' = s {taps = newTaps}
40 y = sum [b * w | (b, w) - zip (bs s) (wk : (taps s))]
41 in (y, s')
42
43 -- Turn a filter into an Automaton, in order to use the built in
plubming
44 -- of Arrows to run the filter on an input.
45 filterAuto :: (ArrowApply a) = Filter b c - FilterState b - Automaton
a (e, b) c
46 filterAuto f s = Automaton a where
47 a = proc (e, x) - do
48 (y, s') - arr (runFilter f) - (x, s)
49 returnA - (y, filterAuto f s')
50
53 applyFilter :: Filter b c - FilterState b - [b] - ([c], FilterState
b)
54 applyFilter f s =
55 let a = filterAuto f s
56 in proc xs - do
57 ys - runAutomaton a - ((), DS.fromList xs)
58 s' - (|fetch|)
59 returnA - (DS.toList ys, s')
60
which gave me this compile error:
Filter.hs:58:16:
Could not deduce (ArrowState (FilterState b) (-))
from the context ()
arising from a use of `fetch' at Filter.hs:58:16-20
Possible fix:
add (ArrowState (FilterState b) (-)) to the context of
the type signature for `applyFilter'
or add an instance declaration for
(ArrowState (FilterState b) (-))
In the expression: fetch
In the expression:
proc xs - do { ys - runAutomaton a - ((), fromList xs);
s' - (|fetch |);
returnA - (toList ys, s') }
In the expression:
let a = filterAuto f s
in
proc xs - do { ys - runAutomaton a - ((), fromList xs);
s' - (|fetch |);
}
So, I made this change:
51 applyFilter :: *(ArrowState (FilterState b) (-)) =* Filter b c -
FilterState b - [b] -
52 ([c], FilterState b)
And that compiled. However, when I tried to test my new filter with:
let s = FilterState [1,0,0] [0.7, 0.2, 0.1] [0, 0, 0]
applyFilter convT s [1,0,0,0,0]
I got:
interactive:1:0:
No instance for (ArrowState (FilterState Double) (-))
arising from a use of `applyFilter' at interactive:1:0-30
Possible fix:
add an instance declaration for
(ArrowState (FilterState Double) (-))
In the expression: applyFilter convT s [1, 0, 0, 0, ]
In the definition of `it': it = applyFilter convT s [1, 0, 0, ]
I thought, maybe, I need to derive from *ArrowState* in my *Filter* type
definition.
So, I tried making this change to the code:
28 newtype Filter b c = F {
29 runFilter :: (b, FilterState b) - (c, FilterState b)
30 } deriving (ArrowState (FilterState x))
but then I was back to no compile:
Filter.hs:30:14:
Can't make a derived instance of
`ArrowState (FilterState x) Filter'
(even with cunning newtype deriving):
cannot eta-reduce the representation type enough
In the newtype declaration for `Filter'
Do you have any advice?
Thanks,
-db
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
Your type stopped being an arrow when the state type started to depend on
the input type:
Filter a b ~= (a, FS a) - (b, FS a)
Filter b c ~= (b, FS b) - (c, FS b)
It's impossible to compose these two functions into a single function of
type Filter a c, because the state type doesn't match.
You need to make the filter state not dependent on the input type:
newtype Filter s a b = F { runFilter :: (a, FilterState s) - (b,
FilterState s) }
You can still create objects with the type
Filter a a b
which correspond to your old filter type. But these functions will always
'start' a pipeline. Which I think is what you want anyways!
-- ryan
On Tue, Oct 18, 2011 at 2:35 PM, Captain Freako capn.fre...@gmail.comwrote:
Hi John,
Thanks for this reply:
Date: Tue, 18 Oct 2011 14:05:22 +1030
From: John Lask jvl...@hotmail.com
Subject: Re: [Haskell-cafe] How to implement a digital filter, using
Arrows?
To: haskell-cafe@haskell.org
Message-ID: BLU0-
smtp384394452fd2750fbe3bcfcc6...@phx.gbl
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
your function corresponds with Control.Arrow.Transformer.Automaton. If
you frame your function is such most of your plumbing is taken care of.
Following your advice, I arrived at:
1 {-# LANGUAGE Arrows, GeneralizedNewtypeDeriving, FlexibleContexts #-}
2
3 module Filter (
4 FilterState
5 , Filter
6 , applyFilter
7 , convT
8 ) where
9
10 import EitherT
11 import Control.Monad
12 import Control.Monad.State
13 import Control.Arrow
14 import Control.Arrow.Operations
15 import Control.Arrow.Transformer
16 import Control.Arrow.Transformer.All
17 import Data.Stream as DS (fromList, toList)
18
19 -- tap weights, `as' and `bs', are being made part of the filter state,
in
20 -- order to accomodate adaptive filters (i.e. - DFEs).
21 data FilterState a = FilterState {
22 as :: [a] -- transfer function denominator coefficients
23 , bs :: [a] -- transfer function numerator coefficients
24 , taps :: [a] -- current delay tap stored values
25 }
26
27 -- Future proofing the implementation, using the `newtype' trick.
28 newtype Filter b c = F {
29 runFilter :: (b, FilterState b) - (c, FilterState b)
31 }
32
33 -- Time domain convolution filter (FIR or IIR),
34 -- expressed in direct form 2
35 convT :: (Num b) = Filter b b
36 convT = F $ \(x, s) -
37 let wk = (x - sum [a * t | (a, t) - zip (tail $ as s) (taps s)])
38 newTaps = wk : ((reverse . tail . reverse) $ taps s)
39 s' = s {taps = newTaps}
40 y = sum [b * w | (b, w) - zip (bs s) (wk : (taps s))]
41 in (y, s')
42
43 -- Turn a filter into an Automaton, in order to use the built in
plubming
44 -- of Arrows to run the filter on an input.
45 filterAuto :: (ArrowApply a) = Filter b c - FilterState b -
Automaton a (e, b) c
46 filterAuto f s = Automaton a where
47 a = proc (e, x) - do
48 (y, s') - arr (runFilter f) - (x, s)
49 returnA - (y, filterAuto f s')
50
53 applyFilter :: Filter b c - FilterState b - [b] - ([c], FilterState
b)
54 applyFilter f s =
55 let a = filterAuto f s
56 in proc xs - do
57 ys - runAutomaton a - ((), DS.fromList xs)
58 s' - (|fetch|)
59 returnA - (DS.toList ys, s')
60
which gave me this compile error:
Filter.hs:58:16:
Could not deduce (ArrowState (FilterState b) (-))
from the context ()
arising from a use of `fetch' at Filter.hs:58:16-20
Possible fix:
add (ArrowState (FilterState b) (-)) to the context of
the type signature for `applyFilter'
or add an instance declaration for
(ArrowState (FilterState b) (-))
In the expression: fetch
In the expression:
proc xs - do { ys - runAutomaton a - ((), fromList xs);
s' - (|fetch |);
returnA - (toList ys, s') }
In the expression:
let a = filterAuto f s
in
proc xs - do { ys - runAutomaton a - ((), fromList xs);
s' - (|fetch |);
}
So, I made this change:
51 applyFilter :: *(ArrowState (FilterState b) (-)) =* Filter b c -
FilterState b - [b] -
52 ([c], FilterState
b)
And that compiled. However, when I tried to test my new filter with:
let s = FilterState [1,0,0] [0.7, 0.2, 0.1] [0, 0, 0]
applyFilter convT s [1,0,0,0,0]
I got:
interactive:1:0:
No instance for (ArrowState (FilterState Double) (-))
arising from a use of `applyFilter' at interactive:1:0-30
Possible fix:
add an instance declaration for
(ArrowState (FilterState Double) (-))
In the expression: applyFilter convT s [1, 0, 0, 0, ]
In the definition of `it': it = applyFilter convT s [1, 0, 0, ]
I thought, maybe, I
Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
{-# LANGUAGE Arrows #-}
This is literate code. It expounds on your initial question and provides
two solutions based either on the StateArrow or Automaton
module Test where
import Data.List ( mapAccumL )
import Control.Arrow
import Control.Arrow.Operations
import Control.Arrow.Transformer
import Control.Arrow.Transformer.State
import Control.Arrow.Transformer.Automaton
this later formulation corresponds to Control.Arrow.Transformer.State
data FilterState a = FilterState {
as :: [a] -- transfer function denominator coefficients
, bs :: [a] -- transfer function numerator coefficients
, taps :: [a] -- current delay tap stored values
}
-- Time domain convolution filter (FIR or IIR),
-- expressed in direct form 2
convT = \(x, s) -
let wk = (x - sum [a * t | (a, t)- zip (tail $ as s) (taps s)])
newTaps = wk : ((reverse . tail . reverse) $ taps s)
s' = s {taps = newTaps}
y = sum [b * w | (b, w)- zip (bs s) (wk : (taps s))]
in (y, s')
we can construct the type of a Filter as a state arrow with state
(FilterState s) and base arrow type of (-)
type FilterSt s b c = StateArrow (FilterState s) (-) b c
to lift the function convT to a state arrow it would be very
easy if the constructor were exported (ie. ST convT), however it is not. So
we define a custom lift to lift functions of the above type into the arrow
liftSt :: ((x,FilterState s)-(y,FilterState s)) - FilterSt s x y
liftSt f = proc x - do
s - fetch - ()
(y,s') - arr f - (x,s)
store - s'
returnA - y
then to fold the arrow over a list of inputs
runFilterSt :: FilterSt s b c - (FilterState s) - [b] -
(FilterState s , [c])
runFilterSt f = mapAccumL (curry (swap . runState f . swap))
where
swap (a,b) = (b,a)
t1 = let
s = FilterState [1,0,0] [0.7, 0.2, 0.1] [0, 0, 0]
in snd $ runFilterSt (liftSt convT) s [1,0,0,0,0]
*Test t1
[0.7,0.2,0.1,0.0,0.0]
except I am not sure you want a state arrow as that propogates the state
through all arrows. eg in a b, the state modified by a passes to b
and so on.
This would only be any good if all your filters shared/modified the same
state.
the initial suggestion was to use an automaton arrow which isolates the
state
in each arrow.
type FilterAu b c = Automaton (-) b c
liftAu :: ((x,FilterState s)-(y,FilterState s)) - FilterState s -
FilterAu x y
liftAu f s0 = proc x - do
rec (y,s') - arr f - (x,s)
s - delay s0 - s'
returnA - y
runAutomaton is a bit cumbersome, so define a custom run function that
takes a list
runAuto a [] = []
runAuto (Automaton f) (x:xs) = let
(y,a) = f x
in y:runAuto a xs
t2 = let
s = FilterState [1,0,0] [0.7, 0.2, 0.1] [0, 0, 0]
in runAuto (liftAu convT s) [1,0,0,0,0]
*Test t2
[0.7,0.2,0.1,0.0,0.0]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comparison Haskell, Java, C and LISP
If i understand correctly, what we called generics is what so called reflection. It allow you to introspect type structure. http://haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html#g:4 On Wed, Oct 19, 2011 at 12:03 AM, yrazes yra...@gmail.com wrote: Hi, Maybe you remember my case. I was trying to compare some aspects of these languages. Well... I found that I can compare reflection, support for generics, simplicity and safe code. I just want to ask if you have more information for reflection in Haskell. I read that there is no enough for dynamics to support complete reflection. I hope someone can help me this time :) Julita ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://www.yi-programmer.com/blog/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
