Re: [GHC] #5845: Change description of old-locale to NOT say its deprecated
#5845: Change description of old-locale to NOT say its deprecated +--- Reporter: dterei | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: libraries (other) |Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by dterei): * status: new = closed * resolution: = fixed Comment: Don't worry, it's fixed. 1) It's fixed in old-locale 1.0.0.5. If you read what I wrote, I said I pulled in a version bump form the ghc-7.4 branch. So the patch was submitted after 1.0.0.4 was released. GHC 7.6 will be out very shortly with old-locale 1.0.0.5. 2) Trac (this old version anyway) can't track more than one git repo. So we obviously have it tracking the GHC repo, not the old-locale repo. Hence you have to look at github to see the commit: https://github.com/ghc /packages-old-locale/commit/9f4b00d4ef5b37adffa01742a09b6f9ad2df1a09, which is a much nicer experience anyway. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5845#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7172: GHCi :issafe command doesn't work
#7172: GHCi :issafe command doesn't work -+-- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.1-rc1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Testcase: Blockedby: | Blocking: Related: | -+-- In HEAD and GHC 7.6 RC the ghci :issafe command simply doesn't report the correct result. I will fix very soon (e.g. 48 hours) but wanted to have this bug be tracked and made a high priority so 7.6 isn't released before I fix it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7172 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] #7172: GHCi :issafe command doesn't work
#7172: GHCi :issafe command doesn't work -+-- Reporter: dterei| Owner: dterei Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 7.6.1-rc1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * priority: normal = highest * difficulty: = Unknown Comment: Upping to 'highest' if you want it to be in 7.6. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7172#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] #7171: erroneous overlapping instances reported with FunDeps
#7171: erroneous overlapping instances reported with FunDeps +--- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.1-rc1 Keywords: type classes, fundeps| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by simonpj): * difficulty: = Unknown Comment: Thanks. Happily I believe this is already fixed -- at least your test case works for me; I think the fix was the one for #7128. And the symptoms look very much like #7150, which also works now. If you can try with HEAD that'd be great. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7171#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] #7171: erroneous overlapping instances reported with FunDeps
#7171: erroneous overlapping instances reported with FunDeps -+-- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.6.1-rc1 Resolution: fixed | Keywords: type classes, fundeps Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7171 | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * testcase: = typecheck/should_compile/T7171 * resolution: = fixed Comment: Re-open if you think this is still broken. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7171#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7173: Unnecessary constraints in inferred type
#7173: Unnecessary constraints in inferred type -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Carter Schonwald reports: when playing with the current hackage versions of Epic and Idris to make them play nice with ghc7.6rc1 * http://hackage.haskell.org/package/idris-0.9.2.1 *http://hackage.haskell.org/package/epic-0.9.3 (current version on github now builds on ghc 7.6, https://github.com/edwinb/EpiVM) I ran into some funny type inference problems. Namely, using the idris-0.9.2.1 source and iteratively seeing how ghc complains, I repeated found that ghc would infer extraneous class constraints with variables that don't appear in the function type! eg `(Num a, Ord a) = PArg - Doc`, when the correct type to infer would be `PArg - Doc`. Here are some gists with links to more info https://gist.github.com/3365312 https://gist.github.com/3365073 https://gist.github.com/3364775 Anyways, I'm not sure what to make of this, is this a reasonable artifact of type inference getting confused on functions with a large number of case analyses when various typeclass extensions are enabled? Or Is this a bug in terms of what inference should be able to handle? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7173 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] #7173: Unnecessary constraints in inferred type
#7173: Unnecessary constraints in inferred type -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Old description: Carter Schonwald reports: when playing with the current hackage versions of Epic and Idris to make them play nice with ghc7.6rc1 * http://hackage.haskell.org/package/idris-0.9.2.1 *http://hackage.haskell.org/package/epic-0.9.3 (current version on github now builds on ghc 7.6, https://github.com/edwinb/EpiVM) I ran into some funny type inference problems. Namely, using the idris-0.9.2.1 source and iteratively seeing how ghc complains, I repeated found that ghc would infer extraneous class constraints with variables that don't appear in the function type! eg `(Num a, Ord a) = PArg - Doc`, when the correct type to infer would be `PArg - Doc`. Here are some gists with links to more info https://gist.github.com/3365312 https://gist.github.com/3365073 https://gist.github.com/3364775 Anyways, I'm not sure what to make of this, is this a reasonable artifact of type inference getting confused on functions with a large number of case analyses when various typeclass extensions are enabled? Or Is this a bug in terms of what inference should be able to handle? New description: Carter Schonwald reports: when playing with the current hackage versions of Epic and Idris to make them play nice with ghc7.6rc1 * http://hackage.haskell.org/package/idris-0.9.2.1 * http://hackage.haskell.org/package/epic-0.9.3 (current version on github now builds on ghc 7.6, https://github.com/edwinb/EpiVM) I ran into some funny type inference problems. Namely, using the idris-0.9.2.1 source and iteratively seeing how ghc complains, I repeated found that ghc would infer extraneous class constraints with variables that don't appear in the function type! eg `(Num a, Ord a) = PArg - Doc`, when the correct type to infer would be `PArg - Doc`. Here are some gists with links to more info https://gist.github.com/3365312 https://gist.github.com/3365073 https://gist.github.com/3364775 Anyways, I'm not sure what to make of this, is this a reasonable artifact of type inference getting confused on functions with a large number of case analyses when various typeclass extensions are enabled? Or Is this a bug in terms of what inference should be able to handle? -- Comment(by simonpj): Instructions to reproduce, assuming ghc 7.6 rc, plus having cabal installed 1. `cabal unpack` the most recent `haskeline`, and fix it so it can build. This involves updating the `Setup.hs` file for haskeline, as there's no longer a `Control.Exception.Extensible` (instead its just `Control.Exception.Base`), so that just needs to be swapped. `cabal install` that. 2. `git clone https://github.com/cartazio/EpiVM` 3. `cd EpiVM ; git checkout patch-1 ; cabal build ; cabal configure ; cabal build ; cabal install` 4. Now you can try doing `cabal install idris` and you should get the following type error message: https://gist.github.com/3405712 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7173#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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc
--+-
Reporter: erikd| Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler |Version: 7.4.1
Resolution: | Keywords:
Os: Linux| Architecture: powerpc
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by erikd):
Digging deeper:
{{{
{-# LANGUAGE MagicHash #-}
import GHC.Int
import GHC.Word
import GHC.IntWord64
import Numeric (showHex)
main :: IO ()
main = putStrLn (showHex (wordToInt64 input) )
input :: Word64
input = 0x1a2a3a4a5a6a7a8a
wordToInt64 :: Word64 - Int64
wordToInt64 (W64# x) = I64# (word64ToInt64# x)
}}}
also gives an incorrect result when optimisation is on. The
`word64ToInt64#` is foreign imported as:
{{{
foreign import ccall unsafe hs_word64ToInt64 word64ToInt64# :: Word64#
- Int64#
}}}
and `hs_word64ToInt64` is defined in C as :
{{{
HsInt64 hs_word64ToInt64 (HsWord64 w) {return (HsInt64) w;}
}}}
and testing that function in isolation in a small C program shows no
problem.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc --+- Reporter: erikd| Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler |Version: 7.4.1 Resolution: | Keywords: Os: Linux| Architecture: powerpc Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by erikd): The CMM code generated on powerpc is identical to the CMM code generated on i386. That suggests that the problem is the powerpc specific CMM - ASM stage. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#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] #7122: Slightly extend performance range for T1969 and T3294
#7122: Slightly extend performance range for T1969 and T3294 ---+ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Test Suite|Version: 7.5 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = fixed Comment: This was done recently. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7122#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] #5831: space_leak_001(ghci) segfaults on OS X x86_64
#5831: space_leak_001(ghci) segfaults on OS X x86_64 ---+ Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high| Milestone: 7.6.1 Component: Compiler| Version: 7.5 Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * owner: = simonmar Comment: I'm testing the #7040 patch, so I'll look at this too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5831#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] #7132: Internal error: stg_ap_v_ret when running indexed_types tests
#7132: Internal error: stg_ap_v_ret when running indexed_types tests ---+ Reporter: goldfire| Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler| Version: 7.5 Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * owner: = simonmar * difficulty: = Unknown * priority: normal = highest * milestone: = 7.8.1 Comment: I think I may have broken the LLVM backend somehow. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7132#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] #7134: ghc-7.6.0.20120810-x86_64-windows.exe - internal error R_X86_64_PC32
#7134: ghc-7.6.0.20120810-x86_64-windows.exe - internal error R_X86_64_PC32 ---+ Reporter: cetinsert | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.6.2 Component: GHCi| Version: 7.6.1-rc1 Keywords: R_X86_64_PC32 | Os: Windows Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * milestone: 7.8.1 = 7.6.2 Comment: Given that it appears to kill GHCi completely on this platform, I think 7.6.2 would be a better milestone. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7134#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] #7160: C finalizers are reversed during GC
#7160: C finalizers are reversed during GC
-+--
Reporter: int-e | Owner: simonmar
Type: bug | Status: new
Priority: high | Milestone: 7.6.1
Component: Runtime System| Version: 7.6.1-rc1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit cec899d9fb668d4adccf731a63902e5be49f0660
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Aug 20 13:52:07 2012 +0100
Retain ordering of finalizers during GC (#7160)
This came up since the addition of C finalizers, since Haskell
finalizers are already stored in an explicit list. C finalizers on
the other hand get a WEAK object each, so in order to run them in the
right order we have to make sure that list stays in the correct
order. I hate adding new invariants, but this is the quickest way to
fix the bug for now. A better way to fix it would be to have a single
WEAK object with a list of finaliers attached to it, and a primop
for adding finalizers to the list.
rts/sm/MarkWeak.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7160#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] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically)
-+--
Reporter: andygill | Owner:
Type: feature request | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonpj):
* difficulty: = Unknown
Old description:
We want a way of having GHC RULES known by GHC, but not used by the
optimizer.
HERMIT, a interactive plugin for GHC that applies rules - and as well as
built in rules (like alpha conversion, beta-reduction, etc) - also
provide access to the named GHC RULES. Here is the rub: We want to use
GHC RULES that are parsed and typed checked like normal rules, are
visible to the HERMIT system, but never run by the simplifier. Currently
we can say
- attempt this *before* this (opt) pass, or
- attempt *after* this pass, there is no way of saying
- *never* attempt.
We were thinking
{-# RULES [~] map/map forall f g . map f (map g xs) = map (f.g) xs
#-}
Where the [~] says *never* execute this without be explicitly asked,
following on from the [~0] which does not run in first pass.
We happy making the required changes.
New description:
We want a way of having GHC RULES known by GHC, but not used by the
optimizer.
HERMIT, a interactive plugin for GHC that applies rules - and as well as
built in rules (like alpha conversion, beta-reduction, etc) - also provide
access to the named GHC RULES. Here is the rub: We want to use GHC RULES
that are parsed and typed checked like normal rules, are visible to the
HERMIT system, but never run by the simplifier. Currently we can say
- attempt this '''before''' this (opt) pass, or
- attempt '''after''' this pass,
but there is no way of saying
- '''never''' attempt.
We were thinking
{{{
{-# RULES [~] map/map forall f g . map f (map g xs) = map (f.g) xs
#-}
}}}
Where the `[~]` says *never* execute this without be explicitly asked,
following on from the `[~0]` which does not run in first pass.
We are happy making the required changes.
--
Comment:
I think I'm ok with this. All the machinery is there already except for
the concrete syntax to say never execute.
The only question in my mind is whether to be a bit more explicit by
saying
{{{
{-# RULES [NEVER] map/map ... #-}
}}}
but that means more work in the lexer, so it probably isn't worth it. I
don't feel strongly.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#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] #7160: C finalizers are reversed during GC
#7160: C finalizers are reversed during GC -+-- Reporter: int-e | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.6.1 Component: Runtime System| Version: 7.6.1-rc1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * status: new = merge -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7160#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest| Milestone: 7.6.1
Component: Compiler |Version: 7.6.1-rc1
Resolution: worksforme | Keywords:
Os: Solaris| Architecture: x86
Failure: GHC rejects valid program | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
+---
Comment(by maeder):
I've tried now the same with ghc-7.6.0.20120815 under x86_64 linux and I
got the same failure.
Unfortunately I could not use a binary snapshot
{{{
maeder@pollux:/local/home/maeder/ghc-7.6.0.20120815 ./configure
checking for path to top of build tree... utils/ghc-pwd/dist-
install/build/tmp/ghc-pwd: /lib64/libc.so.6: version `GLIBC_2.14' not
found (required by utils/ghc-pwd/dist-install/build/tmp/ghc-pwd)
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: /lib64/libc.so.6: version
`GLIBC_2.15' not found (required by utils/ghc-pwd/dist-install/build/tmp
/ghc-pwd)
configure: error: cannot determine current directory
}}}
I'll try out
http://www.haskell.org/ghc/dist/current/dist/ghc-7.7.20120820-src.tar.bz2
(Also the network package is now updated on hackage, so no patches are
needed anymore)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#comment:18
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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error +--- Reporter: maeder | Owner: Type: bug| Status: closed Priority: highest| Milestone: 7.6.1 Component: Compiler |Version: 7.6.1-rc1 Resolution: worksforme | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by maeder): * os: Solaris = Unknown/Multiple * architecture: x86 = Unknown/Multiple -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#comment:19 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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error +--- Reporter: maeder | Owner: Type: bug| Status: closed Priority: highest| Milestone: 7.6.1 Component: Compiler |Version: 7.6.1-rc1 Resolution: worksforme | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Comment(by simonpj): 15 August sounds a bit early. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#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
Re: [GHC] #7173: Unnecessary constraints in inferred type
#7173: Unnecessary constraints in inferred type
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1-rc1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by Deewiant):
* failure: None/Unknown = GHC rejects valid program
* version: 7.4.2 = 7.6.1-rc1
Comment:
Reduced test case:
{{{
module Bug7173 where
data Binder b = Guess b
data TT n = Bind (Binder (TT n))
se p (Bind b) = sb b
sb (Guess t) = se 0 t
}}}
It works fine with 7.4.2 but fails with 7.6.1-rc1, inferring a spurious
`Num a` constraint for `sb` without referring to `a` at all:
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.2
$ ghc -S Bug7173.hs
$ ghc-7.6.0.20120810 --version
The Glorious Glasgow Haskell Compilation System, version 7.6.0.20120810
$ ghc-7.6.0.20120810 -S Bug7173.hs
Bug7173.hs:7:1:
Could not deduce (Num a0) arising from the ambiguity check for `sb'
from the context (Num a)
bound by the inferred type for `sb': Num a = Binder (TT t1) - t
at Bug7173.hs:(7,1)-(8,21)
The type variable `a0' is ambiguous
Possible fix: add a type signature that fixes these type variable(s)
Note: there are several potential instances:
instance Num Double -- Defined in `GHC.Float'
instance Num Float -- Defined in `GHC.Float'
instance Integral a = Num (GHC.Real.Ratio a)
-- Defined in `GHC.Real'
...plus three others
When checking that `sb'
has the inferred type `forall t t1 a. Num a = Binder (TT t1) - t'
Probable cause: the inferred type is ambiguous
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7173#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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error +--- Reporter: maeder | Owner: Type: bug| Status: closed Priority: highest| Milestone: 7.6.1 Component: Compiler |Version: 7.6.1-rc1 Resolution: worksforme | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Comment(by maeder): Ok, I see http://www.haskell.org/ghc/dist/stable/dist/ghc-7.6.0.20120820-src.tar.bz2 today. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#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] #7152: Add flag to configure that skips overwriting of symlinks on install
#7152: Add flag to configure that skips overwriting of symlinks on install -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * priority: normal = high * difficulty: = Unknown * milestone: = 7.8.1 Comment: I like this idea too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7152#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] #7155: Fails to build on powerpc with -Werror : The import of `CmmCallConv' is redundant
#7155: Fails to build on powerpc with -Werror : The import of `CmmCallConv' is redundant --+- Reporter: erikd| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.7 Resolution: duplicate| Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = duplicate Comment: I'll commit the patch from #7083 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7155#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] #7163: nofib/real/gg is miscompiled at -O1
#7163: nofib/real/gg is miscompiled at -O1 -+-- Reporter: michalt | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * owner: = igloo * difficulty: = Unknown * priority: normal = highest * milestone: = 7.8.1 Comment: I traced this to the callerSaves changes made by igloo recently, he's currently on the case. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7163#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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error +--- Reporter: maeder | Owner: Type: bug| Status: closed Priority: highest| Milestone: 7.6.1 Component: Compiler |Version: 7.6.1-rc1 Resolution: worksforme | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Comment(by igloo): If you are testing 7.6.1 RC 1, please use the source tarball from http://www.haskell.org/ghc/dist/7.6.1-rc1/ -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#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] #7083: Reduce the likelihood of x64/x86-64 changes breaking the build on other arches
#7083: Reduce the likelihood of x64/x86-64 changes breaking the build on other
arches
---+
Reporter: erikd | Owner:
Type: task | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 7.5
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by erikd@…):
commit 2f7c578574a9d5e9b4d95847abc3d1cb1b35336d
{{{
Author: Erik de Castro Lopo er...@mega-nerd.com
Date: Wed Aug 8 06:44:00 2012 +1000
Reduce the likelihood of x64/x86-64 changes breaking the build on
other arches (#7083).
Code that needs to differentiate between i386 and x86-64 should now
be written as if x86-64 is the default and i386 is the special case.
Eg:
# if i386_TARGET_ARCH
someFuncion = .
# else
someFuncion = .
# endif
compiler/nativeGen/X86/Regs.hs | 56
++-
1 files changed, 20 insertions(+), 36 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7083#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7083: Reduce the likelihood of x64/x86-64 changes breaking the build on other arches
#7083: Reduce the likelihood of x64/x86-64 changes breaking the build on other arches ---+ Reporter: erikd | Owner: Type: task | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.5 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7083#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7132: Internal error: stg_ap_v_ret when running indexed_types tests
#7132: Internal error: stg_ap_v_ret when running indexed_types tests
---+
Reporter: goldfire | Owner: simonmar
Type: bug | Status: closed
Priority: highest | Milestone: 7.8.1
Component: Compiler |Version: 7.5
Resolution: fixed | Keywords:
Os: MacOS X | Architecture: x86_64 (amd64)
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
Fixed:
commit d4ac7d8160b3533c7d0a2377b5442038f69486a8
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Tue Aug 21 12:48:34 2012 +0100
Fix inverted test for platformUnregisterised (should fix the optllvm
breakage)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7132#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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error +--- Reporter: maeder | Owner: Type: bug| Status: closed Priority: highest| Milestone: 7.6.1 Component: Compiler |Version: 7.6.1-rc1 Resolution: worksforme | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Comment(by maeder): No, I just want to test if this (definite) bug of 7.6.1 RC 1 is gone in a newer version (or head) as Simon reported. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error +--- Reporter: maeder | Owner: Type: bug| Status: merge Priority: highest| Milestone: 7.6.1 Component: Compiler |Version: 7.6.1-rc1 Resolution: worksforme | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by maeder): * status: closed = merge Comment: It works for me now with ghc-7.7.20120820 but fails for ghc-7.6.0.20120820. So still some merging is needed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#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
Re: [GHC] #7166: Time running backwards in retainer profile
#7166: Time running backwards in retainer profile ---+ Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.2.2 Resolution: worksforme| Keywords: Os: Windows | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = worksforme Comment: I believe you, but lacking repro code we don't have a way to fix this. (we do have several tests that run the retainer profiler and then run hp2ps on the output, and they don't fail). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7166#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] #7040: linker failures with foreign global data
#7040: linker failures with foreign global data
---+
Reporter: luite | Owner: simonmar
Type: bug | Status: patch
Priority: high| Milestone: 7.6.1
Component: Runtime System | Version:
Keywords: | Os: MacOS X
Architecture: x86_64 (amd64) | Failure: Other
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by marlowsd@…):
commit e590ad77f9596a8389409ae56ea902c97e5dbfb0
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Aug 20 13:14:47 2012 +0100
OS X: use mmap() instead of malloc for allocating the bss (#7040)
rts/Linker.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7040#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] #7170: Foreign.Concurrent finalizer called twice in some cases
#7170: Foreign.Concurrent finalizer called twice in some cases -+-- Reporter: joeyadams | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Runtime System| Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * owner: = simonmar * difficulty: = Unknown * priority: normal = high * milestone: = 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7170#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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc --+- Reporter: erikd| Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler |Version: 7.4.1 Resolution: | Keywords: Os: Linux| Architecture: powerpc Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonmar): You could make the program even simpler by passing the result to a foreign-imported C function to print it out, instead of using `showHex`. Then you would be using no library code at all, and you should be able to trace through the assembly to figure out where something has gone wrong (unfortunatey I don't read PPC assembler so I'm no use here). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#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] #7040: linker failures with foreign global data
#7040: linker failures with foreign global data ---+ Reporter: luite | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.6.1 Component: Runtime System | Version: Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Other Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * priority: high = highest * status: patch = merge Comment: let's get this merged into 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7040#comment:17 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] #7170: Foreign.Concurrent finalizer called twice in some cases
#7170: Foreign.Concurrent finalizer called twice in some cases
-+--
Reporter: joeyadams | Owner: simonmar
Type: bug | Status: merge
Priority: high | Milestone: 7.6.1
Component: libraries/base| Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime crash
Difficulty: Unknown |Testcase: ffi/should_run/7170
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonmar):
* status: new = merge
* testcase: = ffi/should_run/7170
* component: Runtime System = libraries/base
Comment:
Fixed:
commit 895dd47937c6c9340bf4f289f9f43d5f9be9ffcc
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Tue Aug 21 15:42:50 2012 +0100
Remove finalizers from a ForeignPtr atomically (#7170)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7170#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] #7129: LINE pragma disables automatic tickish annotations
#7129: LINE pragma disables automatic tickish annotations
---+
Reporter: scpmw | Owner:
Type: bug | Status: closed
Priority: normal| Milestone: 7.8.1
Component: Compiler |Version: 7.5
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Other | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonmar):
* status: patch = closed
* resolution: = fixed
Comment:
commit 68a1393b806f5cd26086eb5853cc5427df99f320
{{{
Author: Peter Wortmann sc...@leeds.ac.uk
Date: Wed Aug 8 16:52:15 2012 +0100
Annotate code in {-# LINE #-} pragmas as well
I suppose this was a good idea for HPC, as it assumed that source code
annotations coming from a source file could only talk about the same
source file (by how Mix files are saved).
I don't see a reason why cost-centres or source annotations would want
that kind of behaviour. I introduced a flag for toggling the behaviour
per tickish.
(plus some minor refactoring, as well as making sure that the same
check
applies to binary tick boxes, where they had apparently been
forgotten.)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7129#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] #7174: panic when using function in 'deriving' data declaration
#7174: panic when using function in 'deriving' data declaration -+-- Reporter: shapeshifter |Owner: Type: bug | Status: closed Priority: normal|Component: Compiler Version: 7.4.2 | Resolution: duplicate Keywords:| Os: Linux Architecture: Unknown/Multiple | Failure: Compile-time crash Testcase:|Blockedby: Blocking:| Related: -+-- Changes (by guest): * status: new = closed * resolution: = duplicate Comment: It is already fixed in HEAD, bug #5961. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7174#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] #7109: Inlining depends on datatype size, even with INLINE pragmas
#7109: Inlining depends on datatype size, even with INLINE pragmas --+- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.5 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7109#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] #7112: No inlining in the presence of non-instantiated phantom type
#7112: No inlining in the presence of non-instantiated phantom type -+-- Reporter: dreixel | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7112#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] #7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1
#7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1 --+- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.4.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7114#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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: merge
Priority: highest| Milestone: 7.6.1
Component: Compiler |Version: 7.6.1-rc1
Resolution: worksforme | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC rejects valid program | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
+---
Comment(by maeder):
to reproduce do
{{{
cabal install aterm fgl xml network utf8-string
svn co https://svn-agbkb.informatik.uni-bremen.de/Hets/trunk Hets
cd Hets
make
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#comment:25
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] #7163: nofib/real/gg is miscompiled at -O1
#7163: nofib/real/gg is miscompiled at -O1
-+--
Reporter: michalt | Owner: igloo
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by ian@…):
commit 6d3fb1b1efee263f07da47693147990e8443ab1d
{{{
Author: Ian Lynagh i...@well-typed.com
Date: Tue Aug 21 16:41:30 2012 +0100
Fix the generation of CallerSaves; fixes #7163
Simon Marlow spotted that we were #include'ing MachRegs.h several
times,
but that doesn't work as (a) it uses ifdeffery to avoid being included
multiple times, and (b) even if we work around that, then the
#define's
from previous inclusions are still defined when we #include it again.
So we now put the platform code for each platform in a separate .hs
file.
compiler/codeGen/CallerSaves.hs | 51
-
compiler/codeGen/CgUtils.hs |2 +-
compiler/codeGen/CodeGen/CallerSaves.hs | 32 +
compiler/codeGen/CodeGen/Platform/ARM.hs|9
compiler/codeGen/CodeGen/Platform/NoRegs.hs |8 +++
compiler/codeGen/CodeGen/Platform/PPC.hs|9
compiler/codeGen/CodeGen/Platform/PPC_Darwin.hs | 10
compiler/codeGen/CodeGen/Platform/SPARC.hs |9
compiler/codeGen/CodeGen/Platform/X86.hs|9
compiler/codeGen/CodeGen/Platform/X86_64.hs |9
compiler/codeGen/StgCmmUtils.hs |2 +-
compiler/ghc.cabal.in |9 +++-
includes/CallerSaves.part.hs| 54
+++---
13 files changed, 132 insertions(+), 81 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7163#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] #7163: nofib/real/gg is miscompiled at -O1
#7163: nofib/real/gg is miscompiled at -O1 --+- Reporter: michalt | Owner: igloo Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: T7163| Blockedby: Blocking: |Related: --+- Changes (by igloo): * status: new = closed * testcase: = T7163 * resolution: = fixed Comment: Fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7163#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] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons
--+-
Reporter: simonpj | Owner:
Type: bug | Status: patch
Priority: lowest | Milestone: 7.6.1
Component: Compiler |Version: 6.8.2
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by michalt):
* status: new = patch
Comment:
I think I've fixed the problem with shadowing (I've basically followed the
approach used in CSE). Everything validates.
However, the nofib results are not very encouraging (I've attached the
whole
output of ```nofib-analyse```):
{{{
Program SizeAllocs Runtime Elapsed TotalMem
...
Min -0.1% -0.0% -3.5% -3.8% -4.8%
Max +0.4% +0.0% +2.0% +2.0% +0.0%
Geometric Mean -0.0% -0.0% -1.0% -1.0% -0.1%
}}}
(the results are: clean GHC and ordinary nofib run vs GHC with the patch
and
nofib run with EXTRA_HC_OPTS=-fcomparisons).
I've used the debugging output to see how often the optimization is
actually
removing some comparison: in case of GHC compile it managed to remove
around
1800 comparisons, in nofib only around 40. So I'm not sure this is worth
the
whole additional optimization. It seems that either the patch is not going
far
enough or there simply isn't that many opportunities for optimization...?
If it's
the former, then the main idea would probably be to extend the pass to be
able
to deal with arithmetic [1]. If it's the latter then maybe we should just
close
it as wontfix? What do you think?
[1] Handling, for example things like:
{{{
case x # y + 5 of
case x # y + 4 of
...
}}}
but this will be quite a bit more complex as we need to take into account
integer overflows, etc.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:25
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] #7175: Panic when wrongly using a type family as return types for GADTs
#7175: Panic when wrongly using a type family as return types for GADTs
+---
Reporter: goldfire| Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1-rc1 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
The following code causes the following panic:
{{{
{-# LANGUAGE TypeFamilies, GADTs #-}
type family F a
data G1 a where
G1C :: F Int
data G2 a where
G2C :: F Int
}}}
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.0.20120810 for x86_64-apple-darwin):
compiler/typecheck/TcTyClsDecls.lhs:1081:5-62: Irrefutable pattern
failed for pattern Data.Maybe.Just subst
}}}
Admittedly, the code causing the panic is silly, but it happened to me as
I was refactoring. Having two separate GADTs with the wrong return types
seems necessary to cause the panic.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7175
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] #7167: Make it a warning (not error) to hide an import that isn't exported
#7167: Make it a warning (not error) to hide an import that isn't exported -+-- Reporter: simonpj | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by jwlato): * cc: jwlato@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7167#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7177: Flag -rtsopts not obeyed in hs_init()
#7177: Flag -rtsopts not obeyed in hs_init() --+- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal| Component: Runtime System Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- When calling hs_init() the defaultRtsConfig is always used, which means that flag decoding is off even if the code was linked with -rtsopts. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7177 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] #7171: erroneous overlapping instances reported with FunDeps
#7171: erroneous overlapping instances reported with FunDeps -+-- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.6.1-rc1 Resolution: fixed | Keywords: type classes, fundeps Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7171 | Blockedby: Blocking: |Related: -+-- Comment(by jwlato): I can confirm my problem is fixed in HEAD, but not ghc-7.6.0.20120820. Hopefully it'll be merged soon. Thanks for looking at this so quickly! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7171#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] #6057: hGetBufNonBlocking blocks the underlying handle on Windows
#6057: hGetBufNonBlocking blocks the underlying handle on Windows --+- Reporter: cetinsert| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 7.0.4 Resolution: invalid | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by cetinsert): @simonmar I closed it because I found out I was calling hSetBuffering NoBuffering twice on the same handle from different Haskell threads. Now I came to learn that one should not have any assumptions on how handles should behave as they seem to very platform specific in funny ways. I updated the library I wrote to explicitly mention the handle buffering states it can work with (http://hackage.haskell.org/packages/archive/splice/0.6.1/doc/html /Network-Socket-Splice.html#v:hSplice) and the problems are gone. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6057#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Request for comments on proposal for literate programming using markdown
Ultimately your best bet to actually get something integrated will be to find something that minimizes the amount of work on the part of GHC HQ. I don't think *anybody* there is interested in picking up a lot of fiddly formatting logic and carving it into stone. They might be slightly less inclined to shut the door in your face if the proposal only involved adding a few hooks in the AST for exposing alternative documentation formats, which would enable you to hook in via a custom unlit or do something like how haddock hooks in, but overall, if it involves folks at GHC HQ maintaining a full markdown parser I think they will (and should) just shrug and move on. The resulting system would be slightly less work for you, but would only see any improvements delayed a year between GHC releases, and then the community can't adopt the improvements in earnest for another year after that. This is *not* an encouraging development cycle, and doesn't strike me as a recipe for a successful project. As proposed, this would distract some pretty core resources from working on core functionality and I for one am heavily against it as I understand what has been proposed so far. Haddock works with some fairly simple extensions to GHC's syntax tree. If your proposal was modified so that it just requires a few hooks or worked with the existing haddock hooks in the syntax tree, then while I would hardly be a huge proponent due the fragmentation issues about how to deal with documentation, I would at least cease to be actively opposed. -Edward On Tue, Aug 21, 2012 at 7:45 AM, Philip Holzenspies p...@st-andrews.ac.ukwrote: On 14 Aug 2012, at 07:48, Simon Hengel wrote: Personally, still do not see the big benefit for all that work, and I'm still somewhat worried that a mechanism that is not used by default (I'm talking about unliting with an external command) may start to bit rot. But as long as you are commit to keep `-pgmL` intact, I'm ok ;). A biggy that I had left out has just reoccurred to me. The very first reason for me to look at how unlitting and preprocessing is done in GHC was, because I was looking into what would be required for a refactoring engine (like haRe) to be based on the GHC API. Of course, at the moment, the API doesn't do anything with unlitting and preprocessing. I think in the end it's best to go with the solution that works best for GHC-HQ. Still hoping to hear from them ;) Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Holes in GHC
Can you give me read/write access to your github repo? I'm simonpj on github.
That way I can add comments/questions in code, and generally clean up.
It would make things easier if you could merge with HEAD so that I don't have
to mess around moving libraries back in time.
--
You've put LANGUAGE Holes in TcErrors which means I can't bootstrap.
--
You have this in your patch file, which can't be right
+ | CHoleCan {
+ cc_ev :: CtEvidence,
+ cc_hole_ty :: TcTauType, -- Not a Xi! See same not as above
+ cc_depth:: SubGoalDepth-- See Note [WorkList]
+}
+
\end{code}
\begin{code}
@@ -933,6 +940,9 @@ ctPred (CTyEqCan { cc_tyvar = tv, cc_rhs = xi })
ctPred (CFunEqCan { cc_fun = fn, cc_tyargs = xis1, cc_rhs = xi2 })
= mkTcEqPred (mkTyConApp fn xis1) xi2
ctPred (CIrredEvCan { cc_ty = xi }) = xi
+ctPred (CHoleCan { cc_flavor = fl, cc_hole_ty = xi })
+ = xi
+
since c_flavor isn't a field of CHoleCan.
---
| The 3 currently remaining issues:
|
| - Free type variables are not tidied consistently. For every one of
| these hole warnings, the same TidyEnv is reused, without taking the
| updates from the other holes into account. I'm pretty sure I know where
| this happens and how I could fix it.
This should be easy.
* TcErrors.reportUnsolved uses tyVarsOfWC to find the free type variables
of unsolved constraints
* It then uses tidyFreeTyVars to assign them names
* And that gives an env used in tidying.
So it should just work. I hope you are letting the various 'tidy' calls in
TcErrors do the work.
| - What I thought would be the local environment doesn't actually seem
| to be it. The holes store in their origin the result of `getLclTypeEnv'
| at their location, but as the Note [Bindings with closed types] says,
| the TopLevelFlag of these don't actually differentiate the top level
| from the non-top level bindings. I think it would be more helpful to
| only show the non-top level bindings at the hole's location, any hints
| about how to obtain just these would be appreciated.
In this context local means this module rather than not top level. Use
isExternalName to distinguish top-level things from nested things.
| - The holes do not have very accurate source location information, like
| some other errors have. The hole has its origin, (test2.hs:3:16), but
| somehow not something like: In the expression: folder _ x _, In an
| equation for `test': test x = foldr _ x _. Help with how that is
| supposed to work would also be appreciated.
That's odd. Every Wanted constraint has a WantedLoc (TcRnTypes), which
includes a [ErrCtxt], which is that stack of In ..; In... stuff you see.
Code looks plausible.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.1 Release Candidate 1
Hi there, On Sun, Aug 12, 2012 at 8:57 PM, Ian Lynagh i...@well-typed.com wrote: We are pleased to announce the first release candidate for GHC 7.6.1: http://www.haskell.org/ghc/dist/7.6.1-rc1/ This includes the source tarball, installers for 32bit and 64bit Windows, and bindists for amd64/Linux, i386/Linux, amd64/OSX and i386/OSX. Could somebody please apply my patch (see attached) so the FreeBSD builder clients could produce working binaries again? Thanks, Gabor 0001-Fix-build-with-FreeBSD-versions-earlier-than-9.0-as-.patch Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
7.6.1 RC1 panic coVarsOfTcCo:Bind
Hi,
I'm getting the panic below when building darcs 2.8 with GHC 7.6. It'll
take some effort to cut it down or give repro instructions for an
uncut-down version (I needed to hack a lot of underlying packages to be
able to even get as far as doing this build), so could someone confirm
that it's worth it before I do so? I can't spot anything already
reporting this in trac.
Cheers,
Ganesh
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.6.0.20120810 for i386-unknown-mingw32):
coVarsOfTcCo:Bind
cobox{v a6Czs} [lid]
= cobox{v a6CTr} [lid] `cast`
(main:Darcs.Test.Patch.WithState.WithState{tc r1LL8}
model{tv tC} [tv]
(main:Darcs.Witnesses.Ordered.FL{tc r1Dy1} prim{tv ty} [tv]
main:Darcs.Witnesses.Ordered.:{tc r1Dyc}
main:Darcs.Witnesses.Ordered.FL{tc r1Dy1}
prim{tv ty} [tv])
ghc-prim:GHC.Types.~{(w) tc 31Q}
main:Darcs.Test.Patch.WithState.WithState{tc r1LL8}
(Sym cobox{v a6CSH} [lid])
main:Darcs.Witnesses.Ordered.FL{tc r1Dy1}
prim{tv ty} [tv]
main:Darcs.Witnesses.Ordered.:{tc r1Dyc} main:Darcs.Witnesses.Order
ed.FL{tc r1Dy1}
prim{tv ty} [tv])
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Compositional Compiler Construction, Oberon0 examples available
Doaitse Swierstra wrote: Heinrich Apfelmus wrote: I have a small question: Last I remember, you've mainly been using your UUAGC preprocessor to write attribute grammars in Haskell, especially for UHC. Now that you have first-class attribute grammars in Haskell (achievement unlocked), what do you intend to do with the preprocessor? How do these two approaches compare at the moment and where would you like to take them? On the page http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo there is a link (http://www.fing.edu.uy/~mviera/papers/VSM12.pdf) to a paper we presented at LDTA (one of the ETAPS events) this spring. It explains how UUAGC can be used to generate first class compiler modules. We have also a facility for grouping attributes, so one can trade flexibility for speed. The first class approach stores list of attributes as nested cartesian products, access to which a clever compiler might be able to optimize. This however would correspond a form of specialisation, so you can hardly say that we have really independent modules; as always global optimisation is never compositional). From the point of view of the first class approach such grouped non-termionals are seen as a single composite non-terminal. Ah, I see. So the custom syntax offered by UUAGC is still appreciated, but you now intend to compile it to first-class attribute grammars instead of bare metal Haskell. Makes sense. Thanks! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Compositional Compiler Construction, Oberon0 examples available
On Aug 21, 2012, at 13:46 , Heinrich Apfelmus apfel...@quantentunnel.de wrote: Doaitse Swierstra wrote: Heinrich Apfelmus wrote: I have a small question: Last I remember, you've mainly been using your UUAGC preprocessor to write attribute grammars in Haskell, especially for UHC. Now that you have first-class attribute grammars in Haskell (achievement unlocked), what do you intend to do with the preprocessor? How do these two approaches compare at the moment and where would you like to take them? On the page http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo there is a link (http://www.fing.edu.uy/~mviera/papers/VSM12.pdf) to a paper we presented at LDTA (one of the ETAPS events) this spring. It explains how UUAGC can be used to generate first class compiler modules. We have also a facility for grouping attributes, so one can trade flexibility for speed. The first class approach stores list of attributes as nested cartesian products, access to which a clever compiler might be able to optimize. This however would correspond a form of specialisation, so you can hardly say that we have really independent modules; as always global optimisation is never compositional). From the point of view of the first class approach such grouped non-termionals are seen as a single composite non-terminal. Ah, I see. So the custom syntax offered by UUAGC is still appreciated, but you now intend to compile it to first-class attribute grammars instead of bare metal Haskell. Makes sense. Thanks! It is not much that it is our intention, but it is an easy way to make an existing compiler extensible. The main (fixed) part of the compiler is constructed in the old way from an UUAGC description, and those attributes are grouped (and quite a bit more efficient). On top of this you can define extra attributes and computations, which plug in to the old system. Notice that there is a main difference between the two approaches is that the uuagc route gives you fast compilers, because we can analyse the grammar, and generate efficient tree walking evaluators, whereas the first-class approach gives you great flexibility and the possibility to abstract from common patterns for which others prefer to get lost in stacks of monads, or find out that monads do not work at all since they cannot feed back information into a computation easily. Doaitse Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Wanted: Haskell binding for libbdd (buddy)
Peter Gammie peteg42 at gmail.com writes: My hBDD bindings are on Hackage. Great! Perhaps add category: logic in the cabal file? J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lazy decoding of a list with Data.Binary
I just encountered the following problem: http://stackoverflow.com/questions/11695373/lazy-decoding-of-a-list-with-data-binary If I get that correctly, there once was a discussion about adding a Data.Binary.Lazy to binary: http://www.haskell.org/pipermail/haskell-cafe/2007-November/034758.html What happened to this? And if binary is strict by default now, shouldn't the binary-strict package be deprecated? Is there an alternative these days how to lazily write/read binary? Thanks Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pure and monadic functions using the Repa arrays
Hi Haskellers, I have been playing with the Repa functions and trying the Repa-examples. In order to gain experience with the Repa functions I have written some small linear algebra utilities and import this module to a bigger project. In the beginning of my project I used the mmultP function from the repa-examples to calculate a big matrix, therefore I have and array of type: arr :: Monad m = m (Array U DIM2 Double) Then I carried this array in a lot of functions which become Monadic function and then it is necessary to introduce the monadic machinery for manipulating this functions . The Question is then if there is the possibility to work with a pure function in place of the monadic version? There is something like a runRepa function? runRepa :: Monad m = m (Array U DIM2 Double) - Array U DIM2 Double or could I used the unsafePerformIO function ? or the evaluation of the parallel arrays must be postponed until the Repa.Array is called in the main function? Thanks in Advance, Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Compositional Compiler Construction, Oberon0 examples available
On Aug 21, 2012, at 13:46 , Heinrich Apfelmus apfel...@quantentunnel.de wrote: Doaitse Swierstra wrote: Heinrich Apfelmus wrote: I have a small question: Last I remember, you've mainly been using your UUAGC preprocessor to write attribute grammars in Haskell, especially for UHC. Now that you have first-class attribute grammars in Haskell (achievement unlocked), what do you intend to do with the preprocessor? How do these two approaches compare at the moment and where would you like to take them? On the page http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo there is a link (http://www.fing.edu.uy/~mviera/papers/VSM12.pdf) to a paper we presented at LDTA (one of the ETAPS events) this spring. It explains how UUAGC can be used to generate first class compiler modules. We have also a facility for grouping attributes, so one can trade flexibility for speed. The first class approach stores list of attributes as nested cartesian products, access to which a clever compiler might be able to optimize. This however would correspond a form of specialisation, so you can hardly say that we have really independent modules; as always global optimisation is never compositional). From the point of view of the first class approach such grouped non-termionals are seen as a single composite non-terminal. Ah, I see. So the custom syntax offered by UUAGC is still appreciated, but you now intend to compile it to first-class attribute grammars instead of bare metal Haskell. Makes sense. Thanks! It is not much that it is our intention, but it is an easy way to make an existing compiler extensible. The main (fixed) part of the compiler is constructed in the old way from an UUAGC description, and those attributes are grouped (and quite a bit more efficient). On top of this you can define extra attributes and computations, which plug in to the old system. Notice that there is a main difference between the two approaches is that the uuagc route gives you fast compilers, because we can analyse the grammar, and generate efficient tree walking evaluators, whereas the first-class approach gives you great flexibility and the possibility to abstract from common patterns for which others prefer to get lost in stacks of monads, or find out that monads do not work at all since they cannot feed back information into a computation easily. Doaitse Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] phantom types
On Aug 19, 2012, at 5:29 , wren ng thornton w...@freegeek.org wrote:
On 8/17/12 5:35 AM, TP wrote:
Hi,
I am currently reading documentation on Generalized Algebraic Data Types:
http://en.wikibooks.org/wiki/Haskell/GADT
I have a question concerning this page. Let us consider the following code
proposed in the page:
--
-- Phantom type variable a (does not appear in any Expr: it is just a
-- dummy variable).
data Expr a = I Int
| B Bool
| Add (Expr a) (Expr a)
| Mul (Expr a) (Expr a)
| Eq (Expr a) (Expr a)
deriving (Show)
[...]
I don't understand. When we write eval (I n) = n, as I is a constructor
which takes an Int as argument, we are able to deduce that the type of n is
Int; so the type of eval should be in this case Expr Int - Int.
What do I miss?
Perhaps it'd help to rewrite the above ADT using GADT syntax (but note that
its the exact same data type):
data Expr :: * - * where
I :: Int - Expr a
B :: Bool - Expr a
Add :: Expr a - Expr a - Expr a
Mul :: Expr a - Expr a - Expr a
Eq :: Expr a - Expr a - Expr a
But if you use the real power of GADT's you would write:
{-# LANGUAGE KindSignatures, GADTs #-}
data Expr :: * - * where
I :: Int - Expr Int
B :: Bool - Expr Bool
Val :: a- Expr a
Add :: Expr Int - Expr Int - Expr Int
Mul :: Expr Int - Expr Int - Expr Int
Eq :: Eq a = Expr a - Expr a - Expr Bool
eval :: Expr a - a
eval (I i) = i
eval (B b) = b
eval (Val v) = v
eval (Add e1 e2) = eval e1 + eval e2
eval (Mul e1 e2) = eval e1 * eval e2
eval (Eq e1 e2) = eval e1 == eval e2
Note that the I and B cases are actually superfluous, and are covered by the
val case. This has all nothing to do with phnatom types, but with a proper
understanding of the GADT concept.
Doaitse
So, when looking at the pattern (I n), since I :: Int - Expr a we know that
n :: Int and that (I n) :: Expr a.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure and monadic functions using the Repa arrays
On 08/21/12 09:19, felipe zapata wrote: Hi Haskellers, I have been playing with the Repa functions and trying the Repa-examples. In order to gain experience with the Repa functions I have written some small linear algebra utilities and import this module to a bigger project. In the beginning of my project I used the mmultP function from the repa-examples to calculate a big matrix, therefore I have and array of type: arr :: Monad m = m (Array U DIM2 Double) Then I carried this array in a lot of functions which become Monadic function and then it is necessary to introduce the monadic machinery for manipulating this functions . The Question is then if there is the possibility to work with a pure function in place of the monadic version? There is something like a runRepa function? runRepa :: Monad m = m (Array U DIM2 Double) - Array U DIM2 Double or could I used the unsafePerformIO function ? or the evaluation of the parallel arrays must be postponed until the Repa.Array is called in the main function? When this change was introduced (there wasn't always the arbitrary monad m around everything), I remember I just wrapped my one big repa function in the identity monad and it worked fine. For example, -- Grid.hs import Control.Monad.Identity (Identity) ... zoom :: Values3D - ScaleFactor - Identity Values3D -- Main.hs import Control.Monad.Identity (runIdentity) ... let output = runIdentity $ zoom dbl_data zoom_factor This gives you the warm/fuzzy of knowing that the function is pure, but I think I eventually just let it run in IO to avoid introducing mtl as a dependency. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] salvia
Hi. Does anybody know anything about Sebastiaan Visser, the maintainer of Salvia-* packages (web server) ? Looks like his email is dead. Sergey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fclabels 0.5
just what I was looking for, thanks! 2012/8/20 Erik Hesselink hessel...@gmail.com: Untested, but this should be about right: osi (Bij f b) = iso (Bij b f) Erik On Mon, Aug 20, 2012 at 2:35 PM, Sergey Mironov ier...@gmail.com wrote: Hi. I'm porting old code, which uses fclabels 0.5. Old fclabels define Iso typeclass as follows: class Iso f where iso :: a :-: b - f a - f b iso (Lens a b) = osi (b - a) osi :: a :-: b - f b - f a osi (Lens a b) = iso (b - a) Newer one defines iso: class Iso (~) f where iso :: Bijection (~) a b - f a ~ f b instance Arrow (~) = Iso (~) (Lens (~) f) where iso bi = arr ((\a - lens (fw bi . _get a) (_set a . first (bw bi))) . unLens) instance Arrow (~) = Iso (~) (Bijection (~) a) where iso = arr . (.) but no osi. I'm not a guru in categories, can you help me define osi? Thanks Sergey. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Combining databases from packages installed with cabal install
Hi. I'm configuring haddock via cabal install (see [0]) to build the hoogle database. The database is being installed in ~/.cabal/share/doc/$package-$version/html/$package.txt, but is not being combined with the default database. That is, if right after the installation I try to search with the hoogle command for some a function, it will not work. I wrote the following script, which I called cabal-install: #!/bin/sh set -e set -x cabal \ install \ --enable-documentation \ --enable-library-profiling \ --haddock-hyperlink-source \ --haddock-hoogle \ --haddock-html \ $@ cd ~/.cabal/share/hoogle-4.2.13/databases/ for file in ~/.cabal/share/doc/*/html/*.txt do hoo=`echo $file | sed 's/.txt$/.hoo/;s#.*/##'` if [ ! -f $hoo ] then hoogle convert $file $hoo || true hoogle combine default.hoo $hoo -o /tmp/cabal-install-$$.hoo mv /tmp/cabal-install-$$.hoo default.hoo fi done Basically, it searches for .txt hoogle databases installed that were not combined yet with the default database, and combines them. I think it would be good if this was the default behaviour of cabal install when called with --haddock-hoogle. Is this a bug? Greetings. 0: http://hackage.haskell.org/trac/hackage/ticket/517 -- marcot http://marcot.eti.br/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Galois internships available
* ANNOUNCING: * INTERNSHIP AT GALOIS, Inc. Galois, Inc. www.galois.com has an internship available in Portland, Oregon, USA. PROJECT OVERVIEW: The project is a 4+ year research project on build high-assurance autonomous vehicles. Galois will be working on three aspects of this problem: * Synthesizing software components from Haskell-based embedded DSLs. * Building/porting a hardware platform for testing our prototypes. * Performing static/dynamic analysis on C/C++ code to detect vulnerabilities. We intend to release open-source most (if not all) source code developed on the project and we will be publishing on our research results. Being an intern for repeated terms is a possibility. LOGISTICS: The length and start date of the internship are all negotiable: anytime from this fall through next fall is acceptable. Ideally, you can be at Galois for at least 3 continuous months. The internship is paid competitively, and the intern will be responsible for her own living arrangements (although we can certainly help you find arrangements). Galois is located in the heart of downtown, with multiple public transportation options available and world-class bicycle infrastructure, so living here without an automobile is a viable option. QUALIFICATIONS: * MUST-HAVES: * The ability to be geographically located in Portland during the internship. * Good knowledge of C/C++. * Some experience with low-level/embedded design. * Excellent software engineering ability and aptitude. * NICE-TO-HAVES (not necessary, but let me know if you have these qualifications!): * Experience with Haskell and particularly embedded DSLs. * Experience with microcontrollers (particularly ARM Cortex M). * Experience with control systems. * Interest in/experience with real-time systems and RTOSes. * Interest in/experience with software security. * Interest in/experience with static analysis. * Experience with ArduPilot http://code.google.com/p/ardupilot-mega/ or other autopilot systems. * Good writing skills/experience in writing technical papers. * DO NOT NEED: * A specific degree (we're interested in hearing from anyone from post-docs to undergrads). ABOUT GALOIS: Galois, Inc. is located in Portland, Oregon with a mission to create trustworthiness in critical systems. We're in the business of taking blue-sky ideas and turning them into real-world technology solutions. We've been developing real-world systems for over 10 years using Haskell. To get a sense of life at Galois, one of our previous interns documented his internship here: http://blog.ezyang.com/2010/08/day-in-the-life-of-a-galois-intern/. TO APPLY: In one email, * Please attach a C.V. (PDF, plain text, or markdown only). * In the body of the email, include a brief non-HTML note stating your interest and experience and any other relevant details. Send this to Lee Pike (leepike at galois.com) with the subject line Internship 2012. If you follow these directions, you'll get a confirmation from me. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] regex-pcre is not working with UTF-8
On 08/18/2012 06:16 PM, José Romildo Malaquias wrote: Hello. It seems that the regex-pcre has a bug dealing with utf-8: I hope this bug can be fixed soon. Is there a bug tracker to report the bug? If so, what is it? You need something like that let pat = makeRegexOpts (compUTF8 .|. defaultCompOpt) defaultExecOpt (@'(.+?)'@ :: B.ByteString) and than pat will match correctly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] salvia
On Tue, Aug 21, 2012 at 5:02 PM, Sergey Mironov wrote: Hi. Does anybody know anything about Sebastiaan Visser, the maintainer of Salvia-* packages (web server) ? Looks like his email is dead. I responded to Sergey off-list, so others don't have to. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] regex-pcre is not working with UTF-8
On Tue, Aug 21, 2012 at 10:25:53PM +0300, Konstantin Litvinenko wrote: On 08/18/2012 06:16 PM, José Romildo Malaquias wrote: Hello. It seems that the regex-pcre has a bug dealing with utf-8: I hope this bug can be fixed soon. Is there a bug tracker to report the bug? If so, what is it? You need something like that let pat = makeRegexOpts (compUTF8 .|. defaultCompOpt) defaultExecOpt (@'(.+?)'@ :: B.ByteString) and than pat will match correctly. The bug is related to String (not ByteString) in a UTF-8 locale. Until it is fixed, I am using the workaround of converting the regular expression and the text to ByteString, doing the matching, and then converting the results back to String. Romildo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] explicit annotations on kind polymorphism for data types
Hello All: I'm working through Giving Haskell a Promotion. Section 2.4 presents an explicitly annotated data type declaration similar to the following: data EqRefl (a::X)(b::X) where Refl :: forall X. forall (a::X). EqRefl a a Has this been implemented in GHC 7.4.2? 7.8.3 in the GHC User Guide leads me to believe it has not. -- dude ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cloud Haskell real usage example
Hello everyone. I'm taking my first steps in Cloud Haskell and got some unexpected behaviors. I used the code from Raspberry Pi in a Haskell Cloud [1] as a first example. Did try to switch the code to use Template Haskell with no luck, stick with the verbose style. I changed some of the code, from ProcessId-based messaging to typed channel to receive the Pong; using startSlave to start the worker nodes; and changed the master node to loop forever sending pings to the worker nodes. The unexpected behaviors: - Dropping a worker node while the master is running makes the master node to crash. - Master node do not see worker nodes started after the master process. In order to fix this, I tried to findSlaves at the start of the master process and send ping to only these ones, ignoring the list of NodeId enforced by the type signature of startMaster. Now the master finds new slaves. The bad thing is that when I close one of the workers, the master process freezes. It simply stop doing anything. No more messages and no more Pings to other slaves. :( My view of Cloud Haskell usage would be something similar to this: a master node sending work to slaves; slave instances getting up or down based on demand. So, the master node should be slave-failure-proof and also find new slaves somehow. Am I misunderstanding the big picture of Cloud Haskell or doing anything wrong in the following code? Code (skipped imports and wiring stuff): -- newtype Ping = Ping (SendPort Pong) deriving (Typeable, Binary, Show) newtype Pong = Pong ProcessId deriving (Typeable, Binary, Show) worker :: Ping - Process () worker (Ping sPong) = do wId - getSelfPid say Got a Ping! sendChan sPong (Pong wId) master :: Backend - [NodeId] - Process () master backend _ = forever $ do workers - findSlaves backend say $ Slaves: ++ show workers (sPong, rPong) - newChan forM_ workers $ \w - do say $ Sending a Ping to ++ (show w) ++ ... spawn w (workerClosure (Ping sPong)) say $ Waiting for reply from ++ (show (length workers)) ++ worker(s) replicateM_ (length workers) $ do (Pong wId) - receiveChan rPong say $ Got back a Pong from ++ (show $ processNodeId wId) ++ ! (liftIO . threadDelay) 200 -- Wait a bit before return main = do prog - getProgName args - getArgs case args of [master, host, port] - do backend - initializeBackend host port remoteTable startMaster backend (master backend) [worker, host, port] - do backend - initializeBackend host port remoteTable startSlave backend _ - putStrLn $ usage: ++ prog ++ (master | worker) host port -- [1] http://alenribic.com/writings/post/raspberry-pi-in-a-haskell-cloud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cloud Haskell real usage example
On Tue, Aug 21, 2012 at 9:01 PM, Thiago Negri evoh...@gmail.com wrote: My view of Cloud Haskell usage would be something similar to this: a master node sending work to slaves; slave instances getting up or down based on demand. So, the master node should be slave-failure-proof and also find new slaves somehow. Am I misunderstanding the big picture of Cloud Haskell or doing anything wrong in the following code? (Disclaimer: I can't speak for Cloud Haskell's developers.) AFAIK this is CH's goal. However, they're not quite there yet. Their network implementation is still a lot naive as you're seeing =). Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cloud Haskell real usage example
On Wed, Aug 22, 2012 at 8:30 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Tue, Aug 21, 2012 at 9:01 PM, Thiago Negri evoh...@gmail.com wrote: My view of Cloud Haskell usage would be something similar to this: a master node sending work to slaves; slave instances getting up or down based on demand. So, the master node should be slave-failure-proof and also find new slaves somehow. Am I misunderstanding the big picture of Cloud Haskell or doing anything wrong in the following code? (Disclaimer: I can't speak for Cloud Haskell's developers.) AFAIK this is CH's goal. However, they're not quite there yet. Their network implementation is still a lot naive as you're seeing =). I believe this behavior is due to the usage of channel, you just need to implement some kind of timeout function. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://yi-programmer.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
