Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonmar):
Looks ok to me, though the difference between ghc-pkg dump and ghc-pkg
describe is slightly worrisome. That means `ghc-pkg describe | ghc-pkg
update` is not the identity (I think we have a test that will break).
What goes wrong if `ghc-pkg describe` uses `--no-expand-vars` by default?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#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
[GHC] #5217: GADT declaration not (yet) handled by Template Haskell
#5217: GADT declaration not (yet) handled by Template Haskell
-+--
Reporter: Ashley Yakeley| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler (Type checker)
Version: 7.0.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
-+--
Compiling this:
{{{
{-# LANGUAGE TemplateHaskell, GADTs #-}
module GadtBug where
$([d|data T a where { T :: T Char; }|])
}}}
gives this:
{{{
GadtBug.hs:4:23:
GADT declaration not (yet) handled by Template Haskell T :: T Char
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5217
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] #5218: Add unpackCStringLen# to create Strings from string literals
#5218: Add unpackCStringLen# to create Strings from string literals -+-- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal| Component: Compiler Version: 7.0.3 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- GHC insert calls to `unpackCString#` to convert string literals to `String`s. Libraries like bytestring use rewrite rules to match on this call to optimize code like `pack (unpackCString# s)`. If GHC would instead use a version of unpackCString#, say unpackCStringLen#, that includes the (statically known) length, creating `ByteString`s from literals could be a constant time operation instead of a linear time operation. Another use case, which motivated this ticket, is appending string literals to builders (e.g. using `Data.Binary.Builder.fromByteString`). For small strings the most efficient way to append a string to the builder is to copy the statically allocated string directly into the builder's output buffer. If the string length was known statically, we could do this efficiently using `memcpy` or even using a small unrolled loop. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5218 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] #5218: Add unpackCStringLen# to create Strings from string literals
#5218: Add unpackCStringLen# to create Strings from string literals -+-- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal| Component: Compiler Version: 7.0.3 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tibbe): * cc: johan.tibell@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5218#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] #5177: Segfault in reportCCSProfiling
#5177: Segfault in reportCCSProfiling ---+ Reporter: dankna |Owner: simonmar Type: bug | Status: new Priority: high|Milestone: 7.2.1 Component: Profiling | Version: 7.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by simonmar): * owner: = simonmar Comment: I'll fix this - it's bad for hs_init to require that you keep the memory for argv around until hs_exit. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5177#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] #5086: internal error: update_fwd: unknown/strange object -1206004376
#5086: internal error: update_fwd: unknown/strange object -1206004376 ---+ Reporter: danw|Owner: simonmar Type: bug | Status: merge Priority: high|Milestone: 7.0.4 Component: Runtime System | Version: 6.12.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by simonmar): * status: new = merge * milestone: 7.2.1 = 7.0.4 Comment: I fixed the bug that caused the crash in `Space.hs`: changeset:af9e96991659185821632ff96383480c9dc9cbda (should be merged to 7.0.4) I'm optimistically assuming this fixes the original bug too. Please try the 7.0.4 release candidate (when we put it out), and let us know if you can still reproduce the problem. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5086#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] #5180: dry run option -n broken
#5180: dry run option -n broken -+-- Reporter: hammar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler|Version: 7.0.2 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86_64 (amd64) Failure: Compile-time crash | -+-- Changes (by simonmar): * status: new = closed * resolution: = fixed * milestone: = 7.2.1 Comment: I deprecated `-n`, and made it a no-op: changeset:7256b301f0fde617e04c8dc47a223b30f1f6eae2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5180#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] #5216: Haskell Platform 2011.2.0.1 Setup
#5216: Haskell Platform 2011.2.0.1 Setup -+-- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system |Version: 7.0.3 Resolution: invalid | Keywords: setup windows 7 Testcase: | Blockedby: Difficulty: | Os: Windows Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by igloo): * status: new = closed * resolution: = invalid Comment: Please file Haskell Platform bug reports in the HP trac: http://trac.haskell.org/haskell-platform/ Thanks -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5216#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] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by duncan):
Replying to [comment:8 simonmar]:
Looks ok to me, though the difference between ghc-pkg dump and ghc-pkg
describe is slightly worrisome. That means `ghc-pkg describe | ghc-pkg
update` is not the identity (I think we have a test that will break).
It doesn't break yet because nothing uses ${pkgroot}. But yes, it'd have
to be updated to use `--no-expand-pkgroot`.
What goes wrong if `ghc-pkg describe` uses `--no-expand-vars` by
default?
It's simply that it'll surprise people and perhaps existing tools. I'm
happy to give it a go and see what breaks :-)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if -+-- Reporter: batterseapower|Owner: igloo Type: feature request | Status: patch Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:45 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] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by duncan):
Ok, so we'll make both `dump` and `describe` use the unexpanded form by
default and provide `--expand-pkgroot` which should generate the previous
format exactly.
`ghc-pkg field` will by default expand the `${pkgroot}` but that can be
altered via `--no-expand-pkgroot`.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#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] #5177: Segfault in reportCCSProfiling
#5177: Segfault in reportCCSProfiling +--- Reporter: dankna | Owner: simonmar Type: bug| Status: closed Priority: high | Milestone: 7.2.1 Component: Profiling |Version: 7.1 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: MacOS X Blocking: | Architecture: x86_64 (amd64) Failure: Runtime crash | +--- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Fixed: changeset:a6e8418a71b14ef85ee7134be654689b17765f03 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5177#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] #4978: Continuation passing style loop doesn't compile into a loop
#4978: Continuation passing style loop doesn't compile into a loop ---+ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.4.1 Component: Compiler |Version: 7.0.1 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Ok, I believe this is now fixed. The relevant commits are: * accurate primop sizes: changeset:46176dfa4f329af687c92e57740c800a6cada7b1 * go_pap: changeset:f43bedeef3ecdf4d037a2484a0f0a3672ab60299 * make primops appear cheaper: changeset:4063e1d8501b38b5ed8d620dcd8e27adee0e7091 and I added a test: changeset:cec2c3f6f99c3eea35bf1d1eb952ad9477166999 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4978#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] #4978: Continuation passing style loop doesn't compile into a loop
#4978: Continuation passing style loop doesn't compile into a loop ---+ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.0.1 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by simonmar): * milestone: 7.4.1 = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4978#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] #5212: waitForProcess: does not exist (No child processes)
#5212: waitForProcess: does not exist (No child processes) ---+ Reporter: chrisdone |Owner: chrisdone Type: bug | Status: new Priority: normal |Milestone: Component: GHC API | Version: 6.12.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime ---+ Comment(by simonmar): Could it be that something/someone else is cleaning up child processes for you? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5212#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] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () ---+ Reporter: j.waldmann |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Runtime System | Version: 7.0.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Comment(by simonmar): If you can't boil it down to a smaller example, please try these steps: * compile with `-debug` and try again. This will hopefully turn the segfault into an ASSERT failure * find the smallest `-N` value that still triggers the bug * run the program with `+RTS -Ds`, capture the output, and attach it to the ticket (or send it to me if it's too big to attach). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#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] #5215: process library does not build with GHC 7.0.x
#5215: process library does not build with GHC 7.0.x -+-- Reporter: Favonia |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 7.2.1 Component: libraries/process | Version: 7.0.3 Keywords: interruptible waitForProcess | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- Changes (by simonmar): * owner: Favonia = simonmar * milestone: = 7.2.1 Comment: Thanks, your patch was not quite right (710 should be 701), but I'll fix and commit. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5215#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
[GHC] #5219: need a version of hs_init that returns an error code for command-line errors
#5219: need a version of hs_init that returns an error code for command-line errors -+-- Reporter: simonmar |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.4.1 Component: Runtime System| Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- This ticket is extracted from Roman's comment in #4464: `hs_init` simply aborts if it doesn't like the RTS arguments which is quite unhelpful for dynamic libraries. I took me a day to find out that an application crash was caused by a failing hs_init (because of the -rtsopts problem). I would like to add a check for this to our code but there doesn't seem to be a way to do this. It would be much nicer if hs_init returned a failure/success code, at least for dynamic libraries. To which I responded: If hs_init needs to return an error condition rather than aborting, then we need to define a new API for that, and fix setupRtsFlags. I don't think we need to do this for every case of stg_exit and certainly not for barf: these are all internal error conditions and we have no sensible way to recover. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5219 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] #4464: RTS options broken for dynamic libraries
#4464: RTS options broken for dynamic libraries -+-- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Runtime System |Version: 7.1 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: I've created a new ticket for the remaining part of this one: #5219, so I think this can now be closed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4464#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2236: Deep stacks make execution time go through the roof
#2236: Deep stacks make execution time go through the roof
-+--
Reporter: simonpj | Type: bug
Status: closed| Priority: low
Milestone: 7.2.1 |Component: Runtime System
Version: 6.8.2 | Resolution: fixed
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
This is fixed in 7.2.1.
{{{
N = 400k, main_fast:
MUT time0.33s ( 0.33s elapsed)
GC time0.01s ( 0.01s elapsed)
N = 400k, main_slow, GHC 7.2.1:
MUT time0.33s ( 0.44s elapsed)
GC time0.08s ( 0.08s elapsed)
N = 400k, main_slow, GHC 7.0.3:
MUT time2.25s ( 2.26s elapsed)
GCtime2.95s ( 2.95s elapsed)
}}}
yay for stack chunks.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2236#comment:11
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] #5220: GHC internal error when missing -XFlexibleContexts with generics
#5220: GHC internal error when missing -XFlexibleContexts with generics
-+--
Reporter: dreixel | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.1 |Keywords:
Testcase: GEq2 | Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
See test case GEq2 (currently on the ghc-generics branch, soon to be
merged). When missing -XFlexibleContexts, the compiler panics with
{{{
GHC internal error: `Main.$gdmgeq' is not in scope during type checking,
but it passed the renamer
}}}
When -XFlexibleContexts is added, the error disappears.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5220
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] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
--+-
Reporter: duncan | Owner:
Type: feature request | Status: closed
Priority: normal | Milestone: 7.2.1
Component: Package system |Version: 6.10.2
Resolution: fixed| Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by duncan):
* status: new = closed
* resolution: = fixed
Comment:
Done!
{{{
commit 40b6bd47cf00f025426746bbd7abdd0eda2a3afd
Author: Duncan Coutts dun...@well-typed.com
Date: Mon May 23 22:10:45 2011 +0100
Implement ${pkgroot} spec, allows relocatable registered packages
Historically ghc implemented relocatable packages by allowing
$topdir in the package registration info and having ghc expand
this with its notion of $topdir. The topdir refers to where ghc
itself is installed (specifically the libdir).
The ${pkgroot} spec takes this idea and makes it portable.
(http://www.haskell.org/pipermail/libraries/2009-May/011772.html)
Instead of paths relative to where ghc is installed, they can be
relative to the package database itself. Thus it is no longer a
ghc-specific idea and can work for package collections other than
the global package db.
commit f35a3d247e023b6c1b0abe677549b29398933b50
Author: Duncan Coutts dun...@well-typed.com
Date: Wed May 25 13:06:14 2011 +0100
Provide the pkgroot value in ghc-pkg dump describe when necessary
Tools handling installed packages need to be able to interpret the
paths which are relative to the ${pkgroot} which means they need to
know the value of ${pkgroot}. With ghc-pkg this is not always obvious
since ghc-pkg does not currently have any way machine interface for
reporting the location of its package dbs (global, user). The solution
we have arrived at is simply to emit the pkgroot as an extra field
when it is needed.
There are two cases:
* --no-expand-pkgroot: ghc-pkg dump/describe will not expand the
${pkgroot} var, so it will appear literally in the output and the
pkgroot field will be generated so that tools know what value to
use for the ${pkgroot}.
* --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot}
and ${pkgrooturl} vars and will not generate the pkgroot field.
The defaults are:
* ghc-pkg dump/describe --no-expand-pkgroot
* ghc-pkg field --expand-pkgroot
}}}
Also implemented in Cabal:
{{{
Wed May 25 12:47:42 BST 2011 Duncan Coutts dun...@community.haskell.org
* Support ${pkgroot}-relative paths in installed package info from hc-
pkg
See http://hackage.haskell.org/trac/ghc/ticket/3268
In new versions of ghc-pkg, ghc-pkg dump will emit an extra field like
pkgroot: /the/path/that/is/the/pkgroot
and other fields may contain ${pkgroot}, e.g.
library-dirs: ${pkgroot}/blah/
This allows relocatable packages, with package files installed
relative to the package database itself.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:11
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] #5179: Unexpected Failure due to change of defaultDynFlags' type
#5179: Unexpected Failure due to change of defaultDynFlags' type +--- Reporter: daniel.is.fischer | Owner: igloo Type: bug| Status: closed Priority: high | Milestone: 7.2.1 Component: Test Suite |Version: 7.1 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Other | +--- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Passing the panic is the right thing to do, for now at least. (In the future, we might want `defaultErrorHandler` to take a smaller value instead, i.e. only the information it actually needs rather than all of `DynFlags`). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5179#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] #5172: unix-compat does not build because of strangeness in GHC's header files.
#5172: unix-compat does not build because of strangeness in GHC's header files. -+-- Reporter: rtvd| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System |Version: 7.0.3 Resolution: worksforme | Keywords: unix-compat Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Other | -+-- Changes (by igloo): * status: new = closed * resolution: = worksforme Comment: To use a bindist your system needs to be similar enough to the system that built it. Ubuntu probably has a `libbsd-dev` package including `libutil.h`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5172#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] #5196: Warn about non-existent targets immediately
#5196: Warn about non-existent targets immediately --+- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System |Version: 7.1 Resolution: wontfix | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: I don't think we can tell whether a target exists earlier than we do now. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5196#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] #5172: unix-compat does not build because of strangeness in GHC's header files.
#5172: unix-compat does not build because of strangeness in GHC's header files. -+-- Reporter: rtvd| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System |Version: 7.0.3 Resolution: worksforme | Keywords: unix-compat Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Other | -+-- Comment(by simonmar): I think `unix-compat` should not need to `#include HsUnix.h`, removing that would also fix the problem. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5172#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] #4967: internal error: stg_ap_v_ret on forkProcess + executeFile
#4967: internal error: stg_ap_v_ret on forkProcess + executeFile -+-- Reporter: udoprog |Owner: Type: bug | Status: new Priority: normal|Milestone: 7.2.1 Component: Compiler | Version: 6.12.1 Keywords: forkProcess stg_ap_v_ret | Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64)| Failure: Runtime crash -+-- Changes (by simonmar): * status: infoneeded = new * failure: None/Unknown = Runtime crash Comment: No response from submitter, but he provided enough info and code for us to reproduce, so we should try. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4967#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] #4967: internal error: stg_ap_v_ret on forkProcess + executeFile
#4967: internal error: stg_ap_v_ret on forkProcess + executeFile -+-- Reporter: udoprog |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 6.12.1 Keywords: forkProcess stg_ap_v_ret | Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64)| Failure: Runtime crash -+-- Changes (by simonmar): * owner: = simonmar * priority: normal = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4967#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] #3976: '+RTS -S' reports negative allocation.
#3976: '+RTS -S' reports negative allocation. --+- Reporter: wkahl| Owner: Type: bug | Status: closed Priority: low | Milestone: 7.2.1 Component: Runtime System |Version: 6.12.1 Resolution: worksforme | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: powerpc Failure: Incorrect result at runtime | --+- Changes (by simonmar): * status: infoneeded = closed * resolution: = worksforme Comment: There have been various changes in this area in the RTS, so it's highly likely the bug has been fixed. Given non-response from the submitter and likelihood that it's already been fixed, I'm closing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3976#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] #2979: better support for FFI C wrappers for macros in system headers
#2979: better support for FFI C wrappers for macros in system headers -+-- Reporter: duncan|Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.2.1 Component: Compiler (FFI)| Version: 6.10.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * component: Compiler = Compiler (FFI) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2979#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] #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations
#3008: Strange behavior when using newtyped version of IO monad in FFI import declarations ---+ Reporter: waern |Owner: chak Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: Compiler (FFI) | Version: 6.10.1 Keywords: FFI | Testcase: Blockedby: | Difficulty: Unknown Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: None/Unknown ---+ Changes (by simonmar): * component: Compiler = Compiler (FFI) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3008#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] #3326: the recompilation checker should take CPP flags into account
#3326: the recompilation checker should take CPP flags into account ---+ Reporter: bkomuves | Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 6.10.1 Resolution: duplicate | Keywords: Testcase:| Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by simonmar): * status: new = closed * resolution: = duplicate Comment: I think this is subsumed by #437 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3326#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] #3397: :step hangs when -fbreak-on-exception is set
#3397: :step hangs when -fbreak-on-exception is set ---+ Reporter: hamish| Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.2.1 Component: GHCi |Version: 6.10.3 Resolution: worksforme| Keywords: Testcase:| Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking:| Architecture: x86 Failure: None/Unknown | ---+ Changes (by simonmar): * status: new = closed * failure: = None/Unknown * resolution: = worksforme Comment: No test case for this 2-year old bug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3397#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] #3552: Unreachable code in optimised CMM code
#3552: Unreachable code in optimised CMM code ---+ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 6.10.4 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by simonmar): * cc: ezyang (added) * failure: = None/Unknown * status: new = closed * resolution: = fixed Comment: Edward implemented dead basic block elimination that fixes this ticket I think. changeset:50f5c8491bfcb6b891f772e2915443dbb5078e97 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3552#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] #4967: internal error: stg_ap_v_ret on forkProcess + executeFile
#4967: internal error: stg_ap_v_ret on forkProcess + executeFile -+-- Reporter: udoprog |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 6.12.1 Keywords: forkProcess stg_ap_v_ret | Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64)| Failure: Runtime crash -+-- Comment(by udoprog): I was unable to reproduce the problem using only my custom fork/exec code, which can be found with a simple example here: http://toolchain.eu/open/Main.hs Tested with both ghc-6.12.1 and ghc-6.12.3 This indicates that the problem must be a combination either of that very specific case I linked above on the github branch, it seems to work fine without daemonization so there might be some issues in combination with the following package: http://hackage.haskell.org/package/hdaemonize Other than that, the branch I posted builds and runs fine with ghc-6.12.3. Since my package maintainer saw it fit to upgrade, retrying the whole build chain with ghc-6.12.1 is a bit difficult for me atm. So now it might be possible to reproduce if the following criterias are met: * use hdaemonize * wrap the 'doStuff' method call in http://toolchain.eu/open/Main.hs with 'daemonize' * kill the forked process twice Preferably stdout should be redirected somewhere sane, so it can be examined later, otherwise 'daemonize' will simply close it. Hope this either enables you to close this bug, or check if it is valid. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4967#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] #5221: unicode regression
#5221: unicode regression
-+--
Reporter: igloo |Owner: batterseapower
Type: bug | Status: new
Priority: high |Milestone: 7.2.1
Component: Compiler | Version: 7.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
This program now fails:
{{{
$ touch `printf a1\243a`
$ ls -b a*
a1\243a
$ cat q.hs
import Data.List
import System.Directory
main :: IO ()
main = do xs - getDirectoryContents .
let ys = filter (a `isPrefixOf`) xs
print ys
mapM_ removeFile ys
$ ghc --make q
$ ./q
[a1\61347a]
q: a1�a: removeLink: does not exist (No such file or directory)
$ ls -b a*
a1\243a
$
}}}
Max says:
{{{
This program should work unmodified. The fact that it doesn't
demonstrates that I need to replace some instances of the
Foreign.C.*CString functions with their escape-handling counterparts
(withFilePath and friends). Although I fixed this in some libraries I
apparently forgot to do so in others.
Alternatively, I could change the Foreign.C functions to do the Right
Thing with escape characters. This would strictly be in violation of
the FFI spec though it would make it vastly more probable that 3rd
party libraries would work correctly with strings containing
surrogates.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5221
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] #5206: Data.Map: Add a strict version of fromListWith and fromListWithKey
#5206: Data.Map: Add a strict version of fromListWith and fromListWithKey +--- Reporter: federico_s | Owner: Type: feature request| Status: closed Priority: normal | Milestone: Component: libraries (other) |Version: 7.0.3 Resolution: wontfix| Keywords: Map, strict evaluation Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | +--- Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: Please see http://www.haskell.org/haskellwiki/Library_submissions for the process for proposing changes to the core libraries. Thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5206#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
