Re: [GHC] #6128: ghc 7.4.1 does not work with LDAP-0.6.6
#6128: ghc 7.4.1 does not work with LDAP-0.6.6 ---+ Reporter: magicloud | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler| Version: 7.4.2 Keywords: c binding | Os: Linux Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by magicloud): Exception has been caught in openldap-2.4.31/libraries/libldap/os-ip.c line 1123: rc = poll( sip-si_fds, sip-si_maxfd, to ); This poll call returns -1 and set errno to 4. I have not got the reason. And following is the full debug: ldap_open(company.com, 389) ldap_pvt_gethostbyname_a: host=test.company.com, r=0 ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /usr/local/etc/openldap/ldap.conf ldap_init: using /usr/local/etc/openldap/ldap.conf ldap_init: HOME env is /home/magicloud ldap_init: trying /home/magicloud/ldaprc ldap_init: trying /home/magicloud/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL ldap_create ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP company.com:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.254.1.101:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open: succeeded ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ldap_result ld 0x755fb0 msgid 1 wait4msg ld 0x755fb0 msgid 1 (infinite timeout) wait4msg continue ld 0x755fb0 msgid 1 all 1 ** ld 0x755fb0 Connections: * host: company.com port: 389 (default) refcnt: 2 status: Connected last used: Mon Jul 16 15:13:19 2012 ** ld 0x755fb0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x755fb0 request count 1 (abandoned 0) ** ld 0x755fb0 Response Queue: Empty ld 0x755fb0 response count 0 ldap_chkResponseList ld 0x755fb0 msgid 1 all 1 ldap_chkResponseList returns ld 0x755fb0 NULL ldap_int_select ldap_int_select returned -1: errno 4 ldap_err2string -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6128#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] #6128: ghc 7.4.2 does not work with LDAP-0.6.6 (was: ghc 7.4.1 does not work with LDAP-0.6.6)
#6128: ghc 7.4.2 does not work with LDAP-0.6.6
---+
Reporter: magicloud | Owner:
Type: bug | Status: infoneeded
Priority: normal | Milestone:
Component: Compiler| Version: 7.4.2
Keywords: c binding poll | Os: Linux
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by magicloud):
* keywords: c binding = c binding poll
Comment:
Sorry I did not block the code:
{{{
ldap_open(vancloa.cn, 389)
ldap_pvt_gethostbyname_a: host=ctu1-tes-02.vancloa.cn, r=0
ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /usr/local/etc/openldap/ldap.conf
ldap_init: using /usr/local/etc/openldap/ldap.conf
ldap_init: HOME env is /home/magicloud
ldap_init: trying /home/magicloud/ldaprc
ldap_init: trying /home/magicloud/.ldaprc
ldap_init: trying ldaprc
ldap_init: LDAPCONF env is NULL
ldap_init: LDAPRC env is NULL
ldap_create
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP vancloa.cn:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.253.3.51:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open: succeeded
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ldap_result ld 0x755fb0 msgid 1
wait4msg ld 0x755fb0 msgid 1 (infinite timeout)
wait4msg continue ld 0x755fb0 msgid 1 all 1
** ld 0x755fb0 Connections:
* host: vancloa.cn port: 389 (default)
refcnt: 2 status: Connected
last used: Mon Jul 16 15:13:19 2012
** ld 0x755fb0 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x755fb0 request count 1 (abandoned 0)
** ld 0x755fb0 Response Queue:
Empty
ld 0x755fb0 response count 0
ldap_chkResponseList ld 0x755fb0 msgid 1 all 1
ldap_chkResponseList returns ld 0x755fb0 NULL
ldap_int_select
ldap_int_select4
ldap_int_select5
ldap_int_select6
ldap_int_select7
ldap_int_select8
ldap_int_select9
ldap_int_select returned -1: errno 4
ldap_err2string
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6128#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] #7078: Requested to report bug as below.
#7078: Requested to report bug as below. ---+ Reporter: NeilJ | Owner: Type: bug| Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: Os: Unknown/Multiple | Architecture: x86 Failure: GHC rejects valid program | Testcase: Blockedby: | Blocking: Related: | ---+ ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-linux): DsMonad: uninitialised ds_parr_bi Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7078 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] #7069: precision/rounding bug with floating point numbers on 32-bit-platforms
#7069: precision/rounding bug with floating point numbers on 32-bit-platforms --+- Reporter: shahn| Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler |Version: 7.4.2 Resolution: wontfix | Keywords: Float Double 32 precision rounding Os: Unknown/Multiple | Architecture: x86 Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by maeder): Is it possible to set the FLDCW floating-point load control-word as described in http://www.network- theory.co.uk/docs/gccintro/gccintro_70.html? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7069#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] #6128: ghc 7.4.2 does not work with LDAP-0.6.6
#6128: ghc 7.4.2 does not work with LDAP-0.6.6 ---+ Reporter: magicloud | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler| Version: 7.4.2 Keywords: c binding poll | Os: Linux Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by cdornan): I am not sure whether this is related to the problem discussed on the mailing list in May (see the thread containing http://www.haskell.org/pipermail/haskell-cafe/2012-May/101491.html)where I failed to reproduce the problem on a variety GHC compilers including GHC-7.4.1 running on CentOS 6. This should have been an exact match for one of the configurations for which the problematic behaviour was being observed. I don't remember seeing any explanation for these differences in behaviour. (I use the LDAP quite heavily on CentOS 5 and CentOS 6 and have never seen any of these described problems.) This is the test program I was using. It gets all the details of the LDAP server from the user so the exact same code can be used to test different installations. import LDAP main :: IO () main = do putStrLn domain domain - getLine putStrLn bindDN bindDN - getLine putStrLn bindPW bindPW - getLine putStrLn conecting... ldap - ldapInit domain ldapPort ldapSimpleBind ldap bindDN bindPW putStrLn done Of course it uses the LDAP package. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6128#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] #7069: precision/rounding bug with floating point numbers on 32-bit-platforms
#7069: precision/rounding bug with floating point numbers on 32-bit-platforms --+- Reporter: shahn| Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler |Version: 7.4.2 Resolution: wontfix | Keywords: Float Double 32 precision rounding Os: Unknown/Multiple | Architecture: x86 Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonmar): Replying to [comment:5 maeder]: Is it possible to set the FLDCW floating-point load control-word as described in http://www.network- theory.co.uk/docs/gccintro/gccintro_70.html? As it happens I considered that back in 2003(!) and wrote a comment about it: [https://github.com/ghc/ghc/blob/f857f0741515b9ebf186beb38fe64448de355817/compiler/nativeGen/X86/Instr.hs#L106 this comment] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7069#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] #6128: ghc 7.4.2 does not work with LDAP-0.6.6
#6128: ghc 7.4.2 does not work with LDAP-0.6.6 ---+ Reporter: magicloud | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler| Version: 7.4.2 Keywords: c binding poll | Os: Linux Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by magicloud): Found the interrupt, virtualTimerExpired. And in the aborted poll call, the timeout (var to in millisec) is 4294967295. Hoping someone be familiar with ghc runtime could help here. Hi Cdornan, I think this might be a problem related to the environment, by which I mean the network, ldap server, whatsoever. Here at my place, same code, I failed on some certain ldap servers, not the others. But fine on all when using ghci or runhaskell. And see the above, I do find a certain place that leads to the problem. And the same library used by ldap-utils or other language bindings is just working fine. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6128#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #6128: ghc 7.4.2 does not work with LDAP-0.6.6
#6128: ghc 7.4.2 does not work with LDAP-0.6.6 --+- Reporter: magicloud| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.4.2 Resolution: invalid | Keywords: c binding poll Os: Linux| Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonmar): * status: infoneeded = closed * resolution: = invalid Comment: The RTS uses `SIGVTALRM` for its own purposes (scheduling and profiling). This can cause certain system calls to return `EINTR`, but C library code is supposed to handle `EINTR` properly and restart the system call. I suspect that LDAP is not doing this, which would be a bug in LDAP. You can work around the problem by passing `+RTS -V0` to GHC, although note that this may have a negative impact on performance, because the scheduler will context switch too often. I'm closing the bug as `invalid` on the assumption that it is an LDAP bug. If you think this is wrong, please re-open the ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6128#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7077: Add an order-reversing newtype to Data.Ord
#7077: Add an order-reversing newtype to Data.Ord -+-- Reporter: Azel | Owner: pcapriotti Type: feature request | Status: new Priority: normal| Milestone: Component: libraries/base| Version: Keywords: ord | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = pcapriotti * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7077#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] #5240: help GNU ld to use less memory when linking libraries compiled with -split-objs.
#5240: help GNU ld to use less memory when linking libraries compiled with -split- objs. ---+ Reporter: int-e | Owner: igloo Type: feature request | Status: patch Priority: high | Milestone: 7.4.1 Component: Compiler |Version: 7.0.3 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5240#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] #7079: Irrefutable pattern failed for pattern Data.Maybe.Just
#7079: Irrefutable pattern failed for pattern Data.Maybe.Just
--+-
Reporter: lbolla| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.4.2 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Compiling the following piece of code fails badly.
{{{
{-# LANGUAGE Rank2Types #-}
class Set s where
insert :: Ord a = a - s a - s a
data UnbalancedSet a = E | T (UnbalancedSet a) a (UnbalancedSet a)
instance Ord a = forall a ∘ Set (UnbalancedSet a) where
insert = undefined
}}}
Error message is:
{{{
$ ghc -v -dcore-lint ghc-bug.hs
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version
7.4.1
Using binary package database:
/home/lbolla/src/junk/haskell/Okasaki/.hsenv_Okasaki/ghc_pkg_db/package.cache
hiding package QuickCheck-2.4.2 to avoid conflict with later version
QuickCheck-2.5
wired-in package ghc-prim mapped to ghc-
prim-0.2.0.0-23f345e1ec26a64d5ebc768bd0b2a5d9
wired-in package integer-gmp mapped to integer-
gmp-0.4.0.0-c15e185526893c3119f809251aac8c5b
wired-in package base mapped to
base-4.5.1.0-6909ea031307e047b8ba5b23968c534b
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-
haskell-2.7.0.0-718c7a8346a48b195831957f3dba0eac
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *ghc-bug.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Mon Jul 16 09:11:15 BST 2012
ms_mod = main:Main,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file ghc-bug.hs
Created temporary directory: /tmp/ghc6514_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( ghc-bug.hs, ghc-bug.o )
*** Parser:
*** Renamer/typechecker:
*** Deleting temp files:
Deleting: /tmp/ghc6514_0/ghc6514_0.s
Warning: deleting non-existent /tmp/ghc6514_0/ghc6514_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc6514_0
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-unknown-linux):
compiler/rename/RnSource.lhs:430:14-81: Irrefutable pattern failed
for pattern Data.Maybe.Just (inst_tyvars,
_,
SrcLoc.L _ cls,
_)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
System used:
{{{
$ uname -a
Linux arch 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 15:35:13 UTC 2012 i686
GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/src/gcc-4.7.1/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-
id --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-
ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-
style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.1 (GCC)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7079
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] #5996: fix for CSE
#5996: fix for CSE -+-- Reporter: michalt | Owner: simonpj Type: bug | Status: patch Priority: normal| Milestone: Component: Compiler | Version: 7.5 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5996#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] #5942: implement POSIX confstr() in System/Posix/Unistd.hsc
#5942: implement POSIX confstr() in System/Posix/Unistd.hsc +--- Reporter: clint| Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.1 Component: libraries/unix | Version: 7.4.1 Keywords: confstr | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Easy (less than 1 hour) |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by simonpj): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5942#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] #7069: precision/rounding bug with floating point numbers on 32-bit-platforms
#7069: precision/rounding bug with floating point numbers on 32-bit-platforms
--+-
Reporter: shahn| Owner: simonmar
Type: bug | Status: closed
Priority: normal | Milestone: 7.6.1
Component: Compiler |Version: 7.4.2
Resolution: wontfix | Keywords: Float Double 32
precision rounding
Os: Unknown/Multiple | Architecture: x86
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by maeder):
Maybe it is enough that (true) floating point arithmetic yields non-
deterministic results.
The problem here regards equality, which need not be the same as a - b ==
0. So if we implement
{{{
a == b = show a == show b
}}}
(or more efficiently using rounding)
then this better reflects the data model, i.e. for set instances (and the
expected behavior for this ticket).
Yet, almost all number laws are broken, i.e.
{{{
a == b == a - b == 0
}}}
But maybe this is more acceptable (with a broken FPU).
The difference between the equal values 0.65999289 and 0.65999289 (of
the given example) happens to be 5.551115123125783e-17 (so is clearly
visible as Double).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7069#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] #5714: Add 'state' to the MonadState class
#5714: Add 'state' to the MonadState class --+- Reporter: twanvl | Owner: pcapriotti Type: task | Status: patch Priority: normal | Milestone: 7.6.1 Component: libraries (other) | Version: 7.2.1 Keywords: mtl, monads-tf | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by simonpj): * owner: ekmett@… = pcapriotti -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5714#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] #5489: Win7: Bootstrapping 7.3 from 7.2.1 using msys git 1.7.6 causes integer-gmp ./configure to fail
#5489: Win7: Bootstrapping 7.3 from 7.2.1 using msys git 1.7.6 causes integer-gmp ./configure to fail --+- Reporter: btutt | Owner: igloo Type: bug| Status: patch Priority: normal | Milestone: 7.6.1 Component: Documentation | Version: 7.3 Keywords: | Os: Windows Architecture: x86| Failure: Building GHC failed Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by simonpj): * owner: = igloo * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5489#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] #6128: ghc 7.4.2 does not work with LDAP-0.6.6
#6128: ghc 7.4.2 does not work with LDAP-0.6.6 --+- Reporter: magicloud| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.4.2 Resolution: invalid | Keywords: c binding poll Os: Linux| Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by magicloud): OK. I can confirm that this works. Thanks. I assigned this to ghc was because that the same library worked with ghc 7.2.2 or earlier. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6128#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5469: Reorganisation of exports in template-haskell library
#5469: Reorganisation of exports in template-haskell library -+-- Reporter: reinerp | Owner: simonpj Type: task | Status: patch Priority: normal| Milestone: 7.6.1 Component: Template Haskell | Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5469#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] #5239: Em-dash for -- with UnicodeSyntax.
#5239: Em-dash for -- with UnicodeSyntax. +--- Reporter: Eelis- | Owner: Type: feature request| Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler (Parser) |Version: 7.0.3 Resolution: | Keywords: unicode syntax extension Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by simonpj): * status: patch = new * difficulty: = Unknown Comment: Dear porges Sorry that we've been playing dead on this. We don't have an opinion either way, but it's not entirely clear to us that everyone would welcome such a change; eg they might want to use em- dash in an operator. Could you initiate a thread on glasgow-haskell-users to see if other Unicode-aware folk actively want the change? If so, we'll apply it. A final patch would be useful; and it should include documentation in 7.3.1 of the user manual. Thanks Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5239#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] #5108: Allow unicode sub/superscript symbols in both identifiers and operators
#5108: Allow unicode sub/superscript symbols in both identifiers and operators -+-- Reporter: mikhail.vorozhtsov | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler (Parser) |Version: 7.1 Resolution: | Keywords: lexer unicode Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: None/Unknown| Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: patch = new Comment: Mikhail, The first issue here is whether we ''want'' sub/superscripts (or indeed primes) on operators, and that's a language design question. We tend towards no but if there was a clear consensus from the Unicode-aware Haskell community, we'd accept it. The implementation questions are probably resolvable. Could you start a thread on glasgow-haskell-users to ask them? (A possible outcome might be that operators should not allow primes! ie the current behaviour is inconsistent, as you point out. And it's wierd that you can use Unicode primes but not Ascii ones!) Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5108#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] #5006: Write locale character encoding to hpc html report
#5006: Write locale character encoding to hpc html report -+-- Reporter: basvandijk| Owner: simonmar Type: bug | Status: patch Priority: normal| Milestone: 7.6.1 Component: Code Coverage | Version: 7.0.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: andy@… = simonmar * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5006#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] #4900: DEPENDS pragma
#4900: DEPENDS pragma ---+ Reporter: cdsmith | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * owner: simonmar = * status: patch = new Comment: Simon H: Simon M is deeply snowed under at the moment. Might you look into the question he raises above? We're a bit stalled. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:49 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] #4415: ghci crash on Windows 7 64bits when press Ctrl-L
#4415: ghci crash on Windows 7 64bits when press Ctrl-L ---+ Reporter: isomorphic | Owner: judahj Type: bug | Status: patch Priority: normal | Milestone: 7.6.1 Component: GHCi| Version: 6.12.3 Keywords: windows 7 | Os: Windows Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonpj): * cc: judah.jacobson@… (added) * difficulty: = Unknown Comment: Judah, any progress? Thanks. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4415#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] #947: ghc -O space leak: CSE between different CAFs
#947: ghc -O space leak: CSE between different CAFs ---+ Reporter: int-e@… | Owner: Type: bug | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: 6.5 Resolution:| Keywords: Os: Linux | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: patch = new -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/947#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] #7041: GHC.Real.gcdInt is no longer optimized.
#7041: GHC.Real.gcdInt is no longer optimized. ---+ Reporter: int-e | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: libraries/base|Version: 7.5 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7041#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] #4163: Make cross-compilation work
#4163: Make cross-compilation work ---+ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Build System |Version: 6.12.3 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Difficult (2-5 days) Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * milestone: 7.6.1 = 7.8.1 Comment: Punting -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4163#comment:29 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] #7061: Allow 'default' declarations within GHCi
#7061: Allow 'default' declarations within GHCi -+-- Reporter: parcs | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 7.6.1 Component: GHCi | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7061#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] #7061: Allow 'default' declarations within GHCi
#7061: Allow 'default' declarations within GHCi -+-- Reporter: parcs | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.6.1 Component: GHCi | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7061#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] #7068: Extensive Memory usage (regression)
#7068: Extensive Memory usage (regression) -+-- Reporter: waldheinz | Owner: pcapriotti Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = pcapriotti -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7068#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] #7014: RULES for bitwise logic and shift primops
#7014: RULES for bitwise logic and shift primops -+-- Reporter: akio | Owner: simonpj Type: feature request | Status: patch Priority: normal| 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 simonpj): * owner: pcapriotti = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7014#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] #6160: support sub-second resolutions for file timestamps
#6160: support sub-second resolutions for file timestamps -+-- Reporter: redneb| Owner: pcapriotti Type: feature request | Status: patch Priority: normal| Milestone: Component: libraries/unix| Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = pcapriotti -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6160#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] #7071: Refactoring arrows
#7071: Refactoring arrows -+-- 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:| -+-- Description changed by simonpj: Old description: At the moment arrow commands re-use `HsExpr` for Proc expressions. But with Dan Winograd-Cort I concluded that the best thing by far would be to separate the data type of HsExpr from that of arrow commands. I think that would lead to a substantial tidy up. There is also a nasty lurking bug in the type checking of commands; see line 290 of TcArrows. Here we call the unifier, but do not do anything with the coercion it returns. This is plainly wrong and will bite eventually. But I don't understand this code well enough to fix it. In short, I am not confident of the arrows implementation at the moment. Several tickets are blocked on this * #5022 (which is marked as fixed but is a pretty tricky case) * #5267 * #5777 * #5609 * #344 * #4359 proposal for `proc case` and multi-branch if New description: At the moment arrow commands re-use `HsExpr` for Proc expressions. But with Dan Winograd-Cort I concluded that the best thing by far would be to separate the data type of `HsExpr` from that of arrow commands. I think that would lead to a substantial tidy up. There is also a nasty lurking bug in the type checking of commands; see line 290 of `TcArrows`. Here we call the unifier, but do not do anything with the coercion it returns. This is plainly wrong and will bite eventually. But I don't understand this code well enough to fix it. In short, I am not confident of the arrows implementation at the moment. Several tickets are blocked on this * #5022 (which is marked as fixed but is a pretty tricky case) * #5267 * #5777 * #5609 * #344 * #4359 proposal for `proc case` and multi-branch if -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7071#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] #7061: Allow 'default' declarations within GHCi
#7061: Allow 'default' declarations within GHCi
---+
Reporter: parcs | Owner: simonmar
Type: feature request | Status: closed
Priority: high | Milestone: 7.6.1
Component: GHCi |Version: 7.4.2
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonmar):
* status: patch = closed
* resolution: = fixed
Comment:
Applied, thanks!
commit 520d82b6ea81b39fcea6b4c06e40b38b85745599
{{{
Author: Patrick Palka patr...@parcs.ath.cx
Date: Sun Jul 8 12:49:22 2012 -0400
Allow 'default' declarations in GHCi
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7061#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] #5942: implement POSIX confstr() in System/Posix/Unistd.hsc
#5942: implement POSIX confstr() in System/Posix/Unistd.hsc ---+ Reporter: clint | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: libraries/unix|Version: 7.4.1 Resolution:| Keywords: confstr Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Easy (less than 1 hour) Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * owner: simonmar = * status: patch = new Comment: `confstr` is fine, but most of those values (e.g. `_CS_LFS_CFLAGS`) are non-portable as far as I can tell. The only portable one is `_CS_PATH`. See e.g. the POSIX pages that list the standard defines: [http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html] and [http://pubs.opengroup.org/onlinepubs/009695399/functions/confstr.html] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5942#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] #7060: Option -ddump-rule-rewrites doesn't dump to a file
#7060: Option -ddump-rule-rewrites doesn't dump to a file ---+ Reporter: erikd | Owner: pcapriotti Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler |Version: 7.5 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * owner: = pcapriotti -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7060#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] #7060: Option -ddump-rule-rewrites doesn't dump to a file
#7060: Option -ddump-rule-rewrites doesn't dump to a file ---+ Reporter: erikd | Owner: pcapriotti Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler |Version: 7.5 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonpj): We definitely want the old output! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7060#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7080: Make RULES and SPECIALISE more consistent
#7080: Make RULES and SPECIALISE more consistent
-+--
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:|
-+--
This [http://www.haskell.org/pipermail/glasgow-haskell-
users/2012-July/022580.html glasgow-haskell-users email thread] describes
the inconsistency between RULES and SPECIALISE pragmas. Consider
{{{
module Test where
import Data.Monoid
import Control.Monad.Writer.Strict
f :: Monad m = a - m a
f = return
g :: Monoid w = a - Writer w a
g = return
{-# RULES f-g f = g #-}
{-# SPECIALISE f :: Monoid w = a - Writer w a #-}
}}}
Here, the SPECIALISE pragma is accepted, but the RULE is rejected thus:
{{{
Could not deduce (Monoid w) arising from a use of `g'
from the context (Monad (WriterT w Identity))
bound by the RULE f-g at Foo.hs:14:3-14
Possible fix: add (Monoid w) to the context of the RULE f-g
In the expression: g
When checking the transformation rule f-g
}}}
Rejecting the RULE is quite right. On the LHS you have an application
{{{
f (WriterT w Identity) d
where d :: Monad (WriterT w Identity)
}}}
Recall that `Writer w = WriterT w Identity`. For the rewrite to work you
have to rewrite this to
{{{
g w d'
where
d' :: Monoid w
}}}
Well, how can you get a `Monoid w` dictionary from a `Monad (WriterT w
Identity)`?
I was surprised that the SPECIALISE pragma worked, but here's what it does
(you can see with -ddump-rules):
{{{
Tidy Core rules SPEC Foo.f
[ALWAYS]
forall (@ a) (@ w) ($dMonoid :: Data.Monoid.Monoid w).
Foo.f @ a
@ (Control.Monad.Trans.Writer.Strict.WriterT
w Data.Functor.Identity.Identity)
(Control.Monad.Trans.Writer.Strict.$fMonadWriterT
@ w
@ Data.Functor.Identity.Identity
$dMonoid
Data.Functor.Identity.$fMonadIdentity)
= Foo.f_f @ a @ w $dMonoid
}}}
Ah! This rule will only match if the LHS is exactly
{{{
f (WriterT w Identity) ($fMonadWriterT w Identity dm $fMonadIdentity)
}}}
So it's a nested pattern match. That makes the LHS match less often;
namely only when the dictionary argument to `f` is an application of
`$fMonadWriterT`, the function that arises from the instance decl
{{{
instance (Monoid w, Monad m) = Monad (WriterT w m) where
}}}
In exchange for matching less often, we now do get access to the `(Monoid
w)` argument.
It is odd that this is inconsistent. Here is why. For a RULE, we must
have a way to rewrite the LHS to an arbitrarily complicated RHS. For a
SPECIALISE pragma
{{{
SPECIALISE f :: spec_ty
where f's type is
f :: poly_ty
}}}
we simply ask whether `poly_ty` is more polymorphic than `spec_ty`; that
is, whether `f` can appear in a context requiring a value of type
`spec_ty`. If so, we see what arguments `f` would need to do that, and
that's the LHS pattern.
But
* It's odd that the behaviour is inconsistent
* The SPECIALISE rule is pretty fragile, beause it'll only match if the
argument dictionary is constructed exactly as shown.
It's not clear to me what, if anything, to do about this, but this ticket
records the issue.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7080
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] #5006: Write locale character encoding to hpc html report
#5006: Write locale character encoding to hpc html report
-+--
Reporter: basvandijk| Owner: simonmar
Type: bug | Status: patch
Priority: normal| Milestone: 7.6.1
Component: Code Coverage | Version: 7.0.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by v.dijk.bas@…):
commit c84481238ceb7ed49bcfd044c5bf1d9d7136d1e1
{{{
Author: Bas van Dijk v.dijk@gmail.com
Date: Mon Jul 16 11:20:23 2012 +0100
Write locale character encoding to hpc html report (#5006)
This allows the correct interpretation of Unicode characters by the
browser.
utils/hpc/HpcMarkup.hs | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5006#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] #849: Offer control over branch prediction
#849: Offer control over branch prediction -+-- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 6.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: N/A Blockedby:|Blocking: Related:| -+-- Changes (by nicolast): * cc: ikke+ghc@… (added) Comment: When using the LLVM backend, this might be feasible using the branch_weights [1] metadata annotations. This way there's no need to do any reordering in the intermediate IR: the optimization steps do this based on these annotations (I checked using Clang with `__builtin_expect`, comparing the generated IR and the final assembly). This allows more granular weights than just LIKELY or UNLIKELY. Would there be any interest if I'd look into adding such BRANCH_WEIGHT (uint) pragma? (Not sure I can pull it off though, not familiar with GHC internals (yet)). [1] http://llvm.org/docs/BranchWeightMetadata.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/849#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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if ---+ Reporter: batterseapower| Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.6.1 Component: Compiler |Version: 7.1 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 Comment: All committed, these will be in 7.6.1. Thanks everyone! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:87 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] #7079: Irrefutable pattern failed for pattern Data.Maybe.Just
#7079: Irrefutable pattern failed for pattern Data.Maybe.Just
---+
Reporter: lbolla| Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 7.4.2
Resolution: duplicate | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonpj):
* status: new = closed
* difficulty: = Unknown
* resolution: = duplicate
Comment:
Thanks! I got this
{{{
T7079.hs:10:28: parse error on input `∘'
}}}
even when I added `LANGUAGE UnicodeSyntax`.
When I used an ordinary period, happily in HEAD it now fails gracefully
{{{
T7079.hs:11:10:
Malformed instance: Ord a = forall a. Set (UnbalancedSet a)
}}}
So it's another instance of #5951, which is fixed.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7079#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] #7078: Requested to report bug as below.
#7078: Requested to report bug as below. -+-- Reporter: NeilJ | Owner: chak Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: x86 | Failure: GHC rejects valid program Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = chak * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7078#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] #7066: isInstance does not work for compound types
#7066: isInstance does not work for compound types -+-- Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: Component: Template Haskell | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj * difficulty: = Unknown Comment: That's true, and currently so by design. What if you did want to ask is there an instance for pairs? You could try making up fresh type variables 'x' and 'y', say, but then with the behaviour you were expecting it would try to find an instance for `(Show x)`, fail, and hence return an empty list. It should be better documented, I agree, but I'm not sure what alternative behaviour would make sense. I need review and commit Reiner's patches from #5469, but then I'll add the docs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7066#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] #7066: isInstance does not work for compound types
#7066: isInstance does not work for compound types -+-- Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: Component: Template Haskell | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by edsko): I see. Fair enough, but then it would be very useful if a separate function was provided that ''does'' have the expected behaviour for things like (Int, A) (for some definition of expected :). It's not obvious to me that such a function is easily user-definable. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7066#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] #5254: usb library fails on Windows
#5254: usb library fails on Windows -+-- Reporter: basvandijk| Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.1 Component: Compiler (FFI)| Version: 7.0.3 Keywords:| Os: Windows Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty:|Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by basvandijk): Before I forget, I did some more investigating in [http://www.haskell.org/pipermail/glasgow-haskell- users/2012-June/022454.html this thread]. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5254#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] #7066: isInstance does not work for compound types
#7066: isInstance does not work for compound types -+-- Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: Component: Template Haskell | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): Would you care to define the expected behaviour that you expect? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7066#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] #5714: Add 'state' to the MonadState class
#5714: Add 'state' to the MonadState class +--- Reporter: twanvl | Owner: pcapriotti Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries (other) |Version: 7.2.1 Resolution: fixed | Keywords: mtl, monads-tf Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by ekmett): * status: patch = closed * resolution: = fixed Comment: This is in. transformers 0.3 generalizes the signature of the individual 'state' functions, and mtl 2.1.* has this method in the class. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5714#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] #7066: isInstance does not work for compound types
#7066: isInstance does not work for compound types
-+--
Reporter: edsko | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone:
Component: Template Haskell | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by edsko):
Oh, I'm sorry. I would expect
{{{
isInstance clss typs
}}}
to return True if and only if I can safely generate code (in my Template
Haskell code) that relies on 'typs' being an instance of 'clss'. In the
example above, I can ''not'' safely generate code that relies on a Show
instance for (Int, A) because there is no Show instance for A. However, I
''can'' safely generate code that relies on a Show instance for (Int,
Bool), say.
Context: In Cloud Haskell when you call 'remotable' on a monomorphic
function f :: T1 - T2, I automatically generate a top-level definition
{{{
f__sdict :: Static (SerializableDict T1)
}}}
but if T1 is not in fact serializable then this will subsequently cause a
type error. So I would like to check (using isInstance) if T1 is an
instance of Serializable before generating this code.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7066#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] #7066: isInstance does not work for compound types
#7066: isInstance does not work for compound types -+-- Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: Component: Template Haskell | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): What if the type contains type variables? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7066#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] #6104: Regression: space leak in HEAD vs. 7.4
#6104: Regression: space leak in HEAD vs. 7.4
-+--
Reporter: simonmar | Owner: simonpj
Type: bug | Status: new
Priority: highest | Milestone: 7.6.1
Component: Compiler | Version: 7.5
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Compile-time performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj):
There doesn't seem to be much of a difference on `CopyFile`, at least not
now. Here's the size of the .o file:
{{{
text data bss dec hex filename
With 7.4.1 6480760 072401c48 T6104.o
With HEAD 4769704 054731561 T6104.o
}}}
So HEAD generates less code, not more. The compiler does allocate a bit
more, but not much:
{{{
7.4.1 with -O on CopyFile.hs
[1 of 1] Compiling CopyFile ( T6104.hs, T6104.o )
146,131,584 bytes allocated in the heap
67,295,032 bytes copied during GC
16,663,568 bytes maximum residency (6 sample(s))
1,330,480 bytes maximum slop
33 MB total memory in use (0 MB lost due to fragmentation)
HEAD with -O on CopyFile.hs
[1 of 1] Compiling CopyFile ( T6104.hs, T6104.o )
156,295,232 bytes allocated in the heap
71,474,496 bytes copied during GC
16,357,872 bytes maximum residency (7 sample(s))
1,451,648 bytes maximum slop
32 MB total memory in use (0 MB lost due to fragmentation)
}}}
I suppose the next thing is to try compiling Cabal.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6104#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] #7066: isInstance does not work for compound types
#7066: isInstance does not work for compound types
-+--
Reporter: edsko | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone:
Component: Template Haskell | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by edsko):
Yes, I guess that's the tricky case -- but this problem already exists.
isInstance just checks if reifyInstances doesn't return the empty list; so
reifyInstances for Show (a, Int) could return
{{{
Instance (Show a) = Instance (a, Int)
}}}
just like it returns
{{{
Instance (Show a, Show b) = Instance (a, b)
}}}
now for that exact same argument. If 'isInstance' is not modified, then an
answer of True would mean: ''this could be satisfied'' (if there are
instances for the type variables), and for monomorphic types it would mean
''yes, this is satisfied''.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7066#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] #6104: Regression: space leak in HEAD vs. 7.4
#6104: Regression: space leak in HEAD vs. 7.4
-+--
Reporter: simonmar | Owner: simonpj
Type: bug | Status: new
Priority: highest | Milestone: 7.6.1
Component: Compiler | Version: 7.5
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Compile-time performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj):
Interface file size:
{{{
GHC 7.4.1 -O -rw-rw-r-- 1 simonpj GHC 5983 Jul 16 15:21 T6104.hi
HEAD -rw-rw-r-- 1 simonpj GHC 10487 Jul 16 14:08 T6104.hi
}}}
So, yes, the interface file is a lot bigger. Looking more closely, this
seems largely accidental. The code in HEAD is broken into more functions,
each of which is individually small enough to be below the inlining-
creation threshold.
I compiled Cabal with -O, and compared the total size (with `ls -l`) of
the `.o` files and `.hi` files with both compilers:
{{{
HEAD change over 7.4.1
.o file size-6%
.hi file size +8%
}}}
So yes, interface file size is up, but not massively, and .o file size is
down.
This does not seem to account for the originally-reported doubling of
residency! And (I've checked) that doubling is still happening.
Conclusion: I don't think it's just bigger interface files. I there is
some other space leak too.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6104#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] #6104: Regression: space leak in HEAD vs. 7.4
#6104: Regression: space leak in HEAD vs. 7.4 -+-- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.5 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): Paulo, might you produce a space profile of 7.4.1 and HEAD compiling Cabal? Thanks Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6104#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] #7074: Way too long, and unhelpful, error message
#7074: Way too long, and unhelpful, error message
---+
Reporter: ksf | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 7.4.2
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonpj):
* status: new = closed
* difficulty: = Unknown
* resolution: = fixed
Comment:
Good point. An easy fix the pretty printer yields this
{{{
T7074.hs:65:5:
No instance for (Control.Monad.Fix.MonadFix m0)
arising from a do statement
The type variable `m0' is ambiguous
Possible fix: add a type signature that fixes these type variable(s)
Note: there are several potential instances:
instance Control.Monad.Fix.MonadFix ((-) r)
-- Defined in `Control.Monad.Fix'
instance Control.Monad.Fix.MonadFix (Either e)
-- Defined in `Control.Monad.Fix'
instance Control.Monad.Fix.MonadFix IO
-- Defined in `Control.Monad.Fix'
...plus three others
In a stmt of an 'mdo' block:
rec { words - newRule
$ optional pause - cmany (word - optional pause);
word - newRule $ lojbanWord // nonLojbanWord;
lojbanWord - newRule $ cmene // cmavo // brivla;
brivla - newRule $ gismu // fuhivla // lujvo;
cmene - newRule $ jbocme // zifcme;
}
In the expression:
mdo { rec { words - newRule
$ optional pause - cmany (word - optional
pause);
word - newRule $ lojbanWord // nonLojbanWord;
lojbanWord - newRule $ cmene // cmavo // brivla;
};
return words }
In an equation for `parser':
parser
= mdo { rec { words - newRule
$ optional pause - cmany (word -
optional pause);
word - newRule $ lojbanWord // nonLojbanWord;
};
return words }
}}}
in place of the monster error. Since I didn't have `Text.Parsers.Frisby`
I had to add a lot of error-bindings with bogus types, which is why the
message is different. But I can confirm that the massive output is gone.
I can't comment on the line number reported without a reproducible test
case. If you think it's important, maybe you can make another ticket for
it? Thanks for pointing out the pretty-printing problem.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7074#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] #7014: RULES for bitwise logic and shift primops
#7014: RULES for bitwise logic and shift primops
-+--
Reporter: akio | Owner: simonpj
Type: feature request | Status: patch
Priority: normal| 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:|
-+--
Comment(by simonpj):
Paolo, I'm more or less happy with the patch, with the following
suggestions:
* The local function `primop_rule` now always returns a singleton list;
any multi-rule stuff is done within that single rule. So I suggest making
the top-level `primOpRule` function do the pattern matching, and return
one rule:
{{{
primOpRule :: PrimOp - Name - CoreRule
primOpRule IntAddOp nm = mkPrimOpRule nm 2 [ binaryLit (intOp2 (+))
, identity zeroi ]
..etc...
}}}
* That turns `relop` and `rules` into top-level functions, which can have
type signatures and helpful names.
* I'd prefer to eta-expand `rules`. Otherwise the `msum` is a bit
cryptic.
* You may be able to use `convFloating` less often, by having a variant
of `getLiteral` or whatever for floating, et `getFloatingLiteral`, used
for floating primops.
* Can you comment the `Int` argument of `getLiteral`?
Then go ahead and commit. Thanks!
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7014#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] #7078: Panic using mixing list with parallel arrays incorrectly (was: Requested to report bug as below.)
#7078: Panic using mixing list with parallel arrays incorrectly -+-- Reporter: NeilJ | Owner: chak Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: x86 | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by chak): * failure: GHC rejects valid program = Compile-time crash Comment: GHC shouldn't panic, but instead give a proper error message, but the definition of transpose in Handy.hs is incorrect. It uses list pattern matching with `(:)` for parallel arrays. That is impossible as they are not inductively defined. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7078#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] #7081: add arrow analogs of lambda case and multi-way if
#7081: add arrow analogs of lambda case and multi-way if
--+-
Reporter: jeltsch | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.5 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
GHC has now support for lambda case and multi-way if (see ticket #4359).
It would be good if arrow variants of these features would be implemented.
There are three things that should be considered:
Lambda case expressions should have analog {{{proc}}} expressions where
{{{
proc case pat_1 - cmd_1
...
pat_n - cmd_n
}}}
desugars to
{{{
proc fresh - case fresh of
pat_1 - cmd_1
...
pat_n - cmd_n
}}}
Lambda case expressions should also have analog arrow commands where
{{{
\ case pat_1 - cmd_1
...
pat_n - cmd_n
}}}
desugars to
{{{
\ fresh - case fresh of
pat_1 - cmd_1
...
pat_n - cmd_n
}}}
Multi-way if expressions should have analog arrow commands where
{{{
if | cond_1 - cmd_1
...
cond_n - cmd_n
}}}
desugars to
{{{
case () of
_ | cond_1 - cmd_1
...
| cond_n - cmd_n
}}}
Identifiers {{{pat_i}}}, {{{cond_i}}}, and {{{cmd_i}}} denote patterns,
boolean expressions, and arrow commands, respectively.
Bug #7071 has to be fixed before starting with this ticket.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7081
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] #7081: arrow analogs of lambda case and multi-way if (was: add arrow analogs of lambda case and multi-way if)
#7081: arrow analogs of lambda case and multi-way if --+- Reporter: jeltsch | Owner: Type: feature request | Status: new Priority: normal| Component: Compiler Version: 7.5 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7081#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] #7071: Refactoring arrows
#7071: Refactoring arrows -+-- 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:| -+-- Comment(by jeltsch): Replying to [ticket:7071 simonpj]: #4359 proposal for `proc case` and multi-branch if There is now a separate feature request #7081 for arrow analogs of lambda case and multi-way if, since ticket #4359 (which actually was about the non-arrow variants) has been closed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7071#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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if
---+
Reporter: batterseapower| Owner: simonmar
Type: feature request | Status: closed
Priority: high | Milestone: 7.6.1
Component: Compiler |Version: 7.1
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by jeltsch):
There is now a new feature request #7081 for arrow analogs of lambda case
and multi-way if. This also covers an arrow command analog of lambda case
in addition to the {{{proc}}} expression analog.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:88
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] #4900: DEPENDS pragma
#4900: DEPENDS pragma ---+ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends| Blockedby: Blocking:|Related: ---+ Changes (by parcs): * status: new = patch Comment: Replying to [comment:47 simonmar]: While looking at the patch I noticed something odd: in order to look up the modification times of the usage files while constructing the `ModSummary`, we have to look for the `ModIface` in the HPT. The first time around, it won't be there, so we'll have `Nothing` for the `ms_uf_date`, but the second time it will, which will force us to re- summarise all the modules. This is very fishy. I'm worried about (a) correctness when the module is not in the HPT, and (b) performance. I'm leaving the patch for now until I figure out the right thing to do. It turns out that, very conveniently, the mtimes of a module's usage files are already calculated during compilation. With that in mind, I have created a new patch addresses this issue and also makes it a little simpler to reason about. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:50 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] #4900: DEPENDS pragma
#4900: DEPENDS pragma ---+ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends| Blockedby: Blocking:|Related: ---+ Comment(by parcs): Oops, I meant to rewrite the previous patch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:51 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] #4900: DEPENDS pragma
#4900: DEPENDS pragma ---+ Reporter: cdsmith | Owner: simonmar Type: feature request | Status: patch Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:52 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] #4415: ghci crash on Windows 7 64bits when press Ctrl-L
#4415: ghci crash on Windows 7 64bits when press Ctrl-L ---+ Reporter: isomorphic | Owner: judahj Type: bug | Status: patch Priority: normal | Milestone: 7.6.1 Component: GHCi| Version: 6.12.3 Keywords: windows 7 | Os: Windows Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by judahj): I did some more investigation on this issue today; I should be able to push a fix within the next couple of days. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4415#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
