Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler |Version: 6.8.2 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by michalt): Yes, that makes sense. Also the plugin is on github if anyone is interested: https://github.com/michalt/ghc-comparisons-plugin -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:30 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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi
--+-
Reporter: nomeata | Owner: trommler
Type: feature request | Status: closed
Priority: normal | Milestone: 7.6.2
Component: Build System |Version: 7.2.1
Resolution: fixed| Keywords:
Os: Linux| Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related: #4496
--+-
Changes (by PHO):
* cc: pho@… (added)
Comment:
Your patch mentions a variable `LIBFFI_LIBS`, which isn't defined
anywhere. I think you need something like:
{{{
diff --git a/rts/ghc.mk b/rts/ghc.mk
index e3c9fa6..d3638ac 100644
--- a/rts/ghc.mk
+++ b/rts/ghc.mk
@@ -386,12 +386,14 @@ rts/dist/build/AutoApply_HC_OPTS += -fno-PIC -static
endif
endif
-# add CFLAGS for libffi
+# add CFLAGS and LIBS for libffi
# ffi.h triggers prototype warnings, so disable them here:
ifeq $(UseSystemLibFFI) YES
LIBFFI_CFLAGS = $(addprefix -I,$(FFIIncludeDir))
+LIBFFI_LIBS = $(addprefix -L,$(FFILibDir)) -lffi
else
LIBFFI_CFLAGS =
+LIBFFI_LIBS = -Lrts/dist/build -lffi
endif
rts/Interpreter_CC_OPTS += -Wno-strict-prototypes $(LIBFFI_CFLAGS)
rts/Adjustor_CC_OPTS+= -Wno-strict-prototypes $(LIBFFI_CFLAGS)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#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
[GHC] #7464: git tag for base-4.6.0.0 missing
#7464: git tag for base-4.6.0.0 missing
-+--
Reporter: SimonHengel | Owner:
Type: bug | Status: new
Priority: normal| Component: libraries/base
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
I assume this is the same as {{{ghc-7.6.1-release}}}. But it would be
nice to have the proper tag. I need this information, so that I can refer
that commit with git submodules.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7464
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] #7459: deriving Generic does not work with TypeLits
#7459: deriving Generic does not work with TypeLits -+-- Reporter: maxtaldykin | Owner: dreixel Type: feature request | Status: new Priority: normal| Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking:|Related: -+-- Changes (by dreixel): * owner: = dreixel * failure: GHC rejects valid program = Other * type: bug = feature request Comment: Thanks for the report, although I don't think this is a bug. We have not intended `Generic` to be used with `TypeLits` (or any `DataKinds` stuff); the error message is not entirely accurate, but that's not what you are reporting. Changing `isTauTy` might have deep implications throughout the compiler; I don't think that's the right fix here. I would be more inclined to change `bad_arg_type` in `TcGenGenerics`. But first we should think exactly of what generic programming with arguments of kind `Symbol` implies. Can you tell me what kind of generic functionality you want on datatypes such as `F` and `X`? Just some example values and the functions you would want to use on them would be clarifying. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7459#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] #5928: INLINABLE fails to specialize in presence of simple wrapper
#5928: INLINABLE fails to specialize in presence of simple wrapper ---+ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler |Version: 7.4.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: patch = new Comment: It sounds like more investigation is needed on this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5928#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] #3080: Show more instances with :info
#3080: Show more instances with :info ---+ Reporter: josef | Owner: Type: feature request | Status: closed Priority: lowest| Milestone: 7.6.2 Component: GHCi |Version: 6.10.1 Resolution: duplicate | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * resolution: = duplicate Comment: closing as duplicate of #5998, which has more info and discussion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3080#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] #7256: Missing dataCast1 and dataCast2 methods in Data.Data instances
#7256: Missing dataCast1 and dataCast2 methods in Data.Data instances ---+ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler |Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * owner: dreixel = * status: patch = new Comment: Removing patch tag until libraries@ has given an opinion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7256#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] #7256: Missing dataCast1 and dataCast2 methods in Data.Data instances
#7256: Missing dataCast1 and dataCast2 methods in Data.Data instances ---+ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler |Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by dreixel): There was no opinion: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/18099 I was going to proceed and patch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7256#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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi
--+-
Reporter: nomeata | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.6.2
Component: Build System |Version: 7.2.1
Resolution: | Keywords:
Os: Linux| Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related: #4496
--+-
Changes (by trommler):
* owner: trommler =
* status: closed = new
* resolution: fixed =
Comment:
Replying to [comment:15 PHO]:
Your patch mentions a variable `LIBFFI_LIBS`, which isn't defined
anywhere. I think you need something like:
This was part of my original patch but did not make it into the above
commit:
{{{
ifneq $(UseSystemLibFFI) YES
LIBFFI_LIBS = -Lrts/dist/build -lffi
else
LIBFFI_LIBS =
endif
}}}
In the case of {{{UseSystemLibFFI==YES}}} the correct linker flags will
be set as part of {{{rts/libs.depend}}}, hence the empty definition for
{{{LIBFFI_LIBS}}}.
Tests driver dynHelloWorld, dynlibs T3807 and T5373 fail here with
unresolved symbols from ffi when built with the in-tree libffi.
I will reopen, assign to me, and prepare a patch.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi --+- Reporter: nomeata | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Build System |Version: 7.7 Resolution: | Keywords: Os: Linux| Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: #4496 --+- Changes (by trommler): * owner: = trommler * version: 7.2.1 = 7.7 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi --+- Reporter: nomeata | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Build System |Version: 7.7 Resolution: | Keywords: Os: Linux| Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: #4496 --+- Changes (by trommler): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#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] #6017: Reading ./.ghci files raises security issues
#6017: Reading ./.ghci files raises security issues -+-- Reporter: nomeata | Owner: pminten Type: task | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by pminten): There is also the question what you want to check with the blacklist/whitelist mechanism. The .ghci files can be divided into three categories: explicitely passed (-ghci-script), standard location (~/.ghci, ~/.ghc/ghci.conf) and current directory. Also .ghci files can source other .ghci files using :script (with arbitrary names, don't need to be called .ghci obviously). The patch simply says that if only files in the current directory are a threat and that if the user approves such a file the trust in that file cascades to whatever files are sourced. With the patch the /foo/bar/ghci-config in your example wouldn't need to be whitelisted because the only way for it to be loaded is through -ghci- script (in which case it would be trusted) or by another file (in which case it would inherit the trustedness). Having a way to configure the default blacklist approach is a good idea but if the blacklist is expanded as you seem to suggest a single knob probably won't suffice. There's a very good chance the user doesn't want the blacklist mechanism to ask for files (s)he explicitly requests to be loaded. So you'd get at least two settings. But you may also want to have a knob for the files loaded by .ghci files, the user may not appreciate being asked for every included file. There would be at least 4 knobs. But I suspect all but one would have a default that nobody changes. For files the user explicitly passes and files included by those the default would be allow. For files included by not automatically trusted files the default would be to allow them if the including file is allowed (if that file can be nasty you already have the security problem). So only the not automatically trusted files (the .ghci files) in the current directory would need a knob. One could imagine that files on a blacklist are rejected even if the user asks for them, this could be a knob too. With this reasoning you'd get at most 2 knobs and a lot of hardcoded behaviour. Of course if there are situations where you'd want something different than the defaults indicated above the reasoning doesn't apply. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6017#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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi
--+-
Reporter: nomeata | Owner: trommler
Type: feature request | Status: patch
Priority: normal | Milestone: 7.6.2
Component: Build System |Version: 7.7
Resolution: | Keywords:
Os: Linux| Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related: #4496
--+-
Comment(by PHO):
Replying to [comment:16 trommler]:
In the case of {{{UseSystemLibFFI==YES}}} the correct linker flags
will be set as part of {{{rts/libs.depend}}}, hence the empty definition
for {{{LIBFFI_LIBS}}}.
I get it. But then what about {{{FFILibDir}}}? If I understand this
correctly, {{{rts/libs.depend}}} contains only {{{-l}}} flags so
{{{-L$(FFILibDir)}}} won't be passed to the linker.
Apart from that, {{{$(rts_LD_OPTS)}}} seems to be ignored too. Or am I
missing some point?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#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] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically)
-+--
Reporter: andygill | Owner:
Type: feature request | Status: patch
Priority: normal| Milestone: 7.8.1
Component: Compiler | Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by afarmer@…):
commit 779f10fdedbeeb31891f3f3772cbc2dfdd32e1ee
{{{
Author: Andrew Farmer afar...@ittc.ku.edu
Date: Thu Oct 4 16:51:28 2012 -0500
Extend parser to allow specification of RULES that never fire. #7162
compiler/parser/Parser.y.pp |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi
--+-
Reporter: nomeata | Owner: trommler
Type: feature request | Status: patch
Priority: normal | Milestone: 7.6.2
Component: Build System |Version: 7.7
Resolution: | Keywords:
Os: Linux| Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related: #4496
--+-
Comment(by ptrommler@…):
commit 7ee5bedc5e5039c9bb3ba06b50a4395e579a4b0e
{{{
Author: Peter Trommler ptromm...@acm.org
Date: Fri Nov 30 13:40:10 2012 +0100
Link in-tree libffi to rts. Fixes trac #5743.
rts/ghc.mk |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#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] #7256: Missing dataCast1 and dataCast2 methods in Data.Data instances
#7256: Missing dataCast1 and dataCast2 methods in Data.Data instances ---+ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.8.1 Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Ah, great. I've applied it. Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7256#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] #7228: ghc-pkg prints an awful lot of usage information
#7228: ghc-pkg prints an awful lot of usage information
---+
Reporter: benmachine| Owner:
Type: bug | Status: closed
Priority: normal| Milestone: 7.8.1
Component: ghc-pkg |Version: 7.7
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by igloo):
* status: patch = closed
* resolution: = fixed
Comment:
Applied:
{{{
commit 2c6939a5b0b11950712be160d2712aee0e6f8b4b
Author: Ben Millwood thebenmachine+...@gmail.com
Date: Fri Sep 7 17:22:46 2012 +0100
Make ghc-pkg print less on error.
}}}
Thanks!
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7228#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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi --+- Reporter: nomeata | Owner: trommler Type: feature request | Status: closed Priority: normal | Milestone: 7.6.2 Component: Build System |Version: 7.7 Resolution: fixed| Keywords: Os: Linux| Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: #4496 --+- Changes (by igloo): * status: patch = closed * resolution: = fixed Comment: I've applied the patch, thanks. I think we only use `rts_LD_OPTS` when calling ld directly. If you have any problems building, it's probably best to open a new ticket giving details, as this one is starting to get a little large and most of the history probably won't be relevant. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#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] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) ---+ Reporter: andygill | Owner: Type: feature request | Status: closed Priority: normal| Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: patch = closed * resolution: = fixed Comment: Applied thanks - and thanks for the test too! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#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] #7333: python2
#7333: python2 ---+ Reporter: michalt | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Build System |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: patch = closed * difficulty: = Unknown * resolution: = fixed Comment: I don't have python2 here on Debian. I've applied the part of the patch that uses python2 if it exists, but I haven't removed the hash-bangs as they don't do any harm AFAICS. I've also removed the python detection from the ghc configure script. Thanks for pointing that out. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7333#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] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) ---+ Reporter: andygill | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: closed = new * resolution: fixed = Comment: Whoa! Where's the documentation? Andrew, can you send a patch to the user manual, please? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis
+---
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: low | Milestone: _|_
Component: Compiler | Version: 6.8.3
Keywords: empty case analysis | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
+---
Changes (by goldfire):
* cc: eir@… (added)
* failure: = None/Unknown
Comment:
Now that GHC is getting more dependently typed features, an empty case
seems more useful. For example, I would like to define the following:
{{{
data a :==: b where
Refl :: a :==: a
data EmptySet
type Not a = a - EmptySet
type DecidableEquality (a :: k) (b :: k) = Either (a :==: b) (Not (a :==:
b))
data SBool :: Bool - * where
SFalse :: SBool False
STrue :: SBool True
eqBoolDec :: SBool a - SBool b - DecidableEquality a b
eqBoolDec SFalse SFalse = Left Refl
eqBoolDec STrue STrue = Left Refl
eqBoolDec SFalse STrue = Right (\case {})
eqBoolDec STrue SFalse = Right (\case {})
}}}
Even if empty pattern matches were allowed, I recognize that this would
just produce an (erroneous) incomplete pattern match warning, because of
bug #3927. But, once that is fixed, empty pattern matches would have a new
lease on life.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#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] #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: igloo
Type: bug | Status: infoneeded
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: 3658|Blocking:
Related: |
---+
Changes (by igloo):
* status: new = infoneeded
Comment:
If you run
{{{
peflags --bigaddr=0 c:/ghc/ghc-7.6.1/bin/ghc.exe
}}}
then does ghci work afterwards?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7134#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
[GHC] #7465: ./configure --with--ffi-libraries: ld cannot find libffi in a non-standard location
#7465: ./configure --with--ffi-libraries: ld cannot find libffi in a non-standard location +--- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Linux| Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: |Related: #5743 +--- This ticket is to continue work on comment 19 to ticket #5743. The issue is only relevant if you wish to use a system provided libffi rather than the in-tree libffi. PHO's comment[http://hackage.haskell.org/trac/ghc/ticket/5743#comment:19]: ... If I understand this correctly, rts/libs.depend contains only -l flags so -L$(FFILibDir) won't be passed to the linker. Apart from that, $(rts_LD_OPTS) seems to be ignored too. igloo's comment [http://hackage.haskell.org/trac/ghc/ticket/5743#comment:21]: ... I think we only use rts_LD_OPTS when calling ld directly. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7465 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: igloo Type: bug | Status: infoneeded 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: 3658|Blocking: Related: | ---+ Comment(by cetinsert): I would like to test this but cannot find anything named peflags to run. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7134#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] #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: igloo Type: bug | Status: infoneeded 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: 3658|Blocking: Related: | ---+ Comment(by cetinsert): Would it be possible to put the ghc binary that results from peflags --bigaddr=0 online, then I could download and report back immediately? Or the peflags binary itself at least. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7134#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7466: [PATCH] Prefer libgmp/libgmp3 over GMP.framework on Darwin
#7466: [PATCH] Prefer libgmp/libgmp3 over GMP.framework on Darwin
+---
Reporter: PHO | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries (other)
Version: 7.6.1| Keywords:
Os: MacOS X | Architecture: Unknown/Multiple
Failure: Other| Blockedby:
Blocking: |Related:
+---
integer-gmp's {{{./configure}}} should not ignore {{{--with-gmp-includes
}}}/{{{--with-gmp-libraries}}} just because {{{GMP.framework}}} is found.
It should search for {{{GMP.framework}}} only when
{{{libgmp}}}/{{{libgmp3}}} is absent.
Here is my [https://github.com/phonohawk/packages-integer-
gmp/commit/2523eb35548e79f32506b9a7011f8ebbd355f5dc patch]:
{{{
% git fetch git://github.com/phonohawk/packages-integer-gmp.git libgmp-on-
darwin
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7466
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
