Re: [GHC] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): The `ByteArray#` code seems to come from `vector`, because the `ByteArray#` is inside an `MVector` constructor (from `Data.Vector.Primitive.Mutable`). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7534: allocateRegsAndSpill: Cannot read from uninitialized register
#7534: allocateRegsAndSpill: Cannot read from uninitialized register --+- Reporter: erikd | Owner: simonmar Type: bug| Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Linux Architecture: powerpc64 | Failure: Building GHC failed Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by simonmar): * status: new = infoneeded Comment: More info needed to make progress on this one, the repro case only happens on PPC/Linux. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7534#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] #7501: Some GHCi options are undocummented
#7501: Some GHCi options are undocummented -+-- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * difficulty: = Unknown Comment: `:check` has been around for a long time (I traced it back to 2005), I think it is only for debugging, and we don't want to document it. I'll add docs for `:showi`, I think that was an oversight. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7501#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] #7561: Unnecessary Heap Allocations - Slow Performance
#7561: Unnecessary Heap Allocations - Slow Performance
---+
Reporter: wurmli | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Build System| Version: 7.6.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by simonpj):
* difficulty: = Unknown
Old description:
Using the vector library operations that should in principle take place
locally and fast, are slow and build a large heap. While trying to
analyse what is going on a strange effect showed. Compiling the attached
small program with heap profiling support produced an executable that
runs fast and uses the heap as expected, whereas built without profiling
support it is slow. The effect shows on linux architectures amd64 and
i386, using ghc 7.6.1 and 7.4.1, respectively.
1) With profiling support
ghc --make -rtsopts -threaded -O2 -prof -fprof-auto heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
produces
fromList [3628800]
667,829,536 bytes allocated in the heap
125,768 bytes copied during GC
65,560 bytes maximum residency (2 sample(s))
20,096 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time0.34s ( 0.35s elapsed)
2) Without profiling support
ghc --make -rtsopts -threaded -O2 heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
fromList [3628800]
26,098,406,816 bytes allocated in the heap
22,674,848 bytes copied during GC
47,184 bytes maximum residency (2 sample(s))
22,448 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time 10.99s ( 11.06s elapsed)
New description:
Using the vector library operations that should in principle take place
locally and fast, are slow and build a large heap. While trying to analyse
what is going on a strange effect showed. Compiling the attached small
program with heap profiling support produced an executable that runs fast
and uses the heap as expected, whereas built without profiling support it
is slow. The effect shows on linux architectures amd64 and i386, using ghc
7.6.1 and 7.4.1, respectively.
1) With profiling support
{{{
ghc --make -rtsopts -threaded -O2 -prof -fprof-auto heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
produces
fromList [3628800]
667,829,536 bytes allocated in the heap
125,768 bytes copied during GC
65,560 bytes maximum residency (2 sample(s))
20,096 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time0.34s ( 0.35s elapsed)
}}}
2) Without profiling support
{{{
ghc --make -rtsopts -threaded -O2 heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
fromList [3628800]
26,098,406,816 bytes allocated in the heap
22,674,848 bytes copied during GC
47,184 bytes maximum residency (2 sample(s))
22,448 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time 10.99s ( 11.06s elapsed)
}}}
--
Comment:
I think your point is: profiling interferes with optimisation. And so it
does. I don't know how to fix that I'm afraid.
Or are you sayig that a non-profiled program is unexpectedly slow?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7561#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] #7562: Parse error with {-# UNPACK #-} Int
#7562: Parse error with {-# UNPACK #-} Int
-+--
Reporter: nomeata | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
This code (note the missing !) causes a parser error:
{{{
module UnpackedFields where
data Pair2 = Pair2 {-# UNPACK #-} Int
}}}
I think a proper error message is more helpful. Also, the docs should
mention that -# UNPACK #- can only be used on strict fields.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7562
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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant -+-- Reporter: nomeata | Owner: simonmar Type: task | Status: infoneeded Priority: normal| Milestone: Component: Runtime System| Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * status: new = infoneeded Comment: Could you point me to the bit of the code you're talking about? I can't find it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7505: Commentary shipped with GHC sources is outdated
#7505: Commentary shipped with GHC sources is outdated -+-- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * difficulty: = Unknown Comment: This is the old commentary before we moved it to the wiki. I think there might still be bits that never got copied over, which is why it's still in the tree. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7505#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] #7522: segfault when ignoring invalid byte sequence when decoding UTF8//IGNORE
#7522: segfault when ignoring invalid byte sequence when decoding UTF8//IGNORE -+-- Reporter: ganesh| Owner: batterseapower Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * owner: = batterseapower * difficulty: = Unknown * priority: normal = high * milestone: = 7.6.2 Comment: I suggest Max might be the best person to look at this, he implemented the support for `//IGNORE`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7522#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant
-+--
Reporter: nomeata | Owner: simonmar
Type: task | Status: new
Priority: normal| Milestone:
Component: Runtime System| Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by nomeata):
* status: infoneeded = new
Comment:
Certainly:
Here, the first element of the instruction list is used to find
{{{nbcd}}}:
http://hackage.haskell.org/trac/ghc/browser/rts/Disassembler.c#L276
The interpreter ignores the value (unless debugging is on):
http://hackage.haskell.org/trac/ghc/browser/rts/Interpreter.c#L789
And here, in assembleBCO, the number of instruction is prepended to the
list of instructions:
http://hackage.haskell.org/trac/ghc/browser/compiler/ghci/ByteCodeAsm.lhs#L156
The assertion in line 161 supports the observation that the information is
duplicated and the size of the ByteArray is correct.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7563: Passing -C flag causes the 'impossible' to happen
#7563: Passing -C flag causes the 'impossible' to happen
--+-
Reporter: jstolarek | Owner:
Type: bug| Status: new
Priority: normal | Component: Driver
Version: 7.7| Keywords:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
Failure: Incorrect warning at compile-time | Blockedby:
Blocking: |Related:
--+-
Passing -C flag to GHC causes compiler panic:
{{{
addFlag by -C on the commandline: Warning:
The -fvia-C flag does nothing; it will be removed in a future GHC
release
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.7.20130108 for x86_64-unknown-linux):
pipeLoop: at phase As but I wanted to stop at phase HCc
}}}
Comment in main/DriverPipeline.hs, lines 665-668 suggests that this
behaviour might happen with native code generator. If C codegen is being
removed, then -C flag should perhaps be removed as well (also from the
documentation)?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7563
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] #7507: loop fusion not working for Int32, Int64 as it does for Int ?
#7507: loop fusion not working for Int32, Int64 as it does for Int ? +--- Reporter: j.waldmann | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase: perf/should_run/T7507 | Blockedby: Blocking: |Related: +--- Comment(by simonmar): How does it affect code size? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7507#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] #7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
#7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
--+-
Reporter: PHO | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/base |Version: 7.7
Resolution: | Keywords:
Os: MacOS X | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by simonmar):
* status: patch = new
* difficulty: = Unknown
Comment:
I'm suspicious of this fix. If configure is finding the wrong type for
`st_ino`, then that looks like a bug in autoconf. The configure script
for base already has this:
{{{
# Enable large file support. Do this before testing the types ino_t,
off_t, and
# rlim_t, because it will affect the result of that test.
AC_SYS_LARGEFILE
}}}
If this isn't working properly, we need to find out why and inform the
autoconf folks if necessary.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7537#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] #7539: Hard ghc api crash when calling runStmt on code which has not been compiled
#7539: Hard ghc api crash when calling runStmt on code which has not been compiled -+-- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): I wouldn't be surprised if the GHC API assumes `LinkInMemory` when using interactive evaluation (`runStmt` and friends). So the easy workaround is don't do that, and we should add a test and an error message somewhere. I don't think `NoLink` or `LinkBinary` make much sense here anyway - or do you have a use case in mind? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7539#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] #7500: GHC: internal error: getMBlock: mmap: Operation not permitted
#7500: GHC: internal error: getMBlock: mmap: Operation not permitted +--- Reporter: guest | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Compiler |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by simonmar): * status: closed = new * resolution: invalid = Comment: If this is a simple case of running out of memory, then we ought to emit the correct error message rather than a panic. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7500#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] #7539: Hard ghc api crash when calling runStmt on code which has not been compiled
#7539: Hard ghc api crash when calling runStmt on code which has not been
compiled
-+--
Reporter: edsko | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by edsko):
In the layer around GHC we allow enabling or disabling code generation
(i.e., type check only). When disabled, we set `{ hscTarget = HscNothing,
ghcLink = NoLink }`. If then later the code is tried to run anyway, the
above crash can arise. (We guard against this at our layer now, but it
would still be nice if ghc would give us an error message rather than
segfault when we make a mistake).
So, yes, I agree, a check and an error message will suffice.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7539#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant -+-- Reporter: nomeata | Owner: simonmar Type: task | Status: new Priority: normal| Milestone: 7.8.1 Component: Runtime System| Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * milestone: = 7.8.1 Comment: Ah, I see. Yes, I think you're right, this field isn't necessary. It is probably there because the size of an `StgArrWords` used to be stored in units of words, but it was changed to be bytes. I'll remove it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7539: Hard ghc api crash when calling runStmt on code which has not been compiled
#7539: Hard ghc api crash when calling runStmt on code which has not been compiled -+-- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * milestone: = 7.8.1 Comment: Actually, looking at the code, it's a slight mystery to me why this doesn't work now. `LinkInMemory` doesn't cause any linking to happen, since the linking is all done on-demand in `runStmt`, so in fact it ought to work with `NoLink` and even `LinkBinary`. I'll leave the ticket open to look into it, but it's not urgent. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7539#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant
-+--
Reporter: nomeata | Owner: simonmar
Type: task | Status: new
Priority: normal| Milestone: 7.8.1
Component: Runtime System| Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit 0c42e301337bdefa94d0c288bb6d689ac33baa4d
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 11:51:58 2013 +
remove unnecessary size field in BCO (#7518)
compiler/ghci/ByteCodeAsm.lhs |8 ++--
rts/Interpreter.c |4 +---
2 files changed, 3 insertions(+), 9 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7501: Some GHCi options are undocummented
#7501: Some GHCi options are undocummented
-+--
Reporter: monoidal | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Documentation | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit f838d2f3d4ee8876647f190da3b2c858c6a669d4
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 09:29:42 2013 +
add docs for :showi language (#7501)
docs/users_guide/ghci.xml | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7501#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant -+-- Reporter: nomeata | Owner: simonmar Type: task | Status: merge Priority: normal| Milestone: 7.8.1 Component: Runtime System| Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * status: new = merge -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant ---+ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal| Milestone: 7.8.1 Component: Runtime System|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * owner: simonmar = * status: merge = new -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant ---+ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal| Milestone: 7.8.1 Component: Runtime System|Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7563: Passing -C flag causes the 'impossible' to happen
#7563: Passing -C flag causes the 'impossible' to happen
-+--
Reporter: jstolarek | Owner: igloo
Type: bug | Status: new
Priority: normal| Milestone: 7.8.1
Component: Driver| Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Incorrect warning at
compile-time
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonmar):
* owner: = igloo
* difficulty: = Unknown
* milestone: = 7.8.1
Comment:
This was broken in the past, fixed by
9c685f44e873f01403fd83209487faa64aeb47fb, and then broken again by this
commit which left a TODO to fix it:
commit f917eeb824cfb7143dde9b12e501d4ddb0049b65
{{{
Author: Ian Lynagh i...@well-typed.com
Date: Tue Aug 7 01:27:44 2012 +0100
Add Unregisterised as a field in the settings file
To explicitly choose whether you want an unregisterised build you now
need to use the --enable-unregisterised/--disable-unregisterised
configure flags.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7563#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] #7561: Unnecessary Heap Allocations - Slow Performance
#7561: Unnecessary Heap Allocations - Slow Performance ---+ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler| Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * cc: benl, rl@… (added) * component: Build System = Compiler * milestone: = 7.8.1 Comment: I just reproduced it with 7.4.1: the program does appear to run many times faster with profiling ''enabled'', which is indeed very suspicious. I suggest that someone familiar with `vector` has a look to see which optimisation or RULE is not happening. Roman or Ben perhaps? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7561#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant ---+ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal| Milestone: 7.8.1 Component: Runtime System|Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by nomeata): It seems you missed the code in Disassembler.c -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7561: Unnecessary Heap Allocations - Slow Performance
#7561: Unnecessary Heap Allocations - Slow Performance ---+ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler| Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonpj): * cc: rl@… (removed) * cc: rleshchinskiy@… (added) Comment: Crumbs, I got that totally back to front. The PROFILED program runs faster! (I though it was the un-profiled one.) As Simon says that is deeply mysterious. I've changed Roman's email on the cc list to his gmail address. `vector` is his package. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7561#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant
---+
Reporter: nomeata | Owner:
Type: task | Status: closed
Priority: normal| Milestone: 7.8.1
Component: Runtime System|Version: 7.6.1
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by marlowsd@…):
commit 343548da7274cd15aaeabe72c6b37bce78e9af9c
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 14:46:03 2013 +
fix disassembler after removal of size field in bco-instrs (#7518)
rts/Disassembler.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): Yes, this lends further support to the hypothesis that the it is mwc- random, not random-source, which is at fault. mwc-random uses an MVector to hold the RNG state. Sadly, I've still been unsuccessful at producing a testcase using only mwc-random. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:26 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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): Indeed, using bound-checked reads and writes in place of the unsafe varieties currently used in System.Random.MWC reveals that uniform1 is the culprit. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:27 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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): In particular, it appears to be the `M.read q i` in `uniformWord32` -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:28 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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
-+--
Reporter: bgamari | Owner: simonmar
Type: bug | Status: infoneeded
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by bgamari):
Well, it seems that `nextIndex` isn't wrapping correctly when used in
`uniformWord32`. Currently it is implemented as,
{{{
nextIndex :: Integral a = a - Int
nextIndex i = fromIntegral j
where j = fromIntegral (i+1) :: Word8
}}}
If I trace the index values over iterations of `uniformWord32`, I find
that they grow beyond 256, resulting in the crash.
If I implement `nextIndex` with a simple `mod`, on the other hand, things
work fine,
{{{
nextIndex :: Integral a = a - Int
nextIndex i = fromIntegral $ (i + 1) `mod` 256
}}}
Simon, is it possible that the optimizer could be now optimizing out the
cast?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Great analysis, thanks. We do indeed seem to have lost the narrowing in `nextIndex`, and it happens in Core, so nothing to do with the code generator. I'll dig a bit deeper and see if I can find out where we went wrong. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Got it - bogus rules for `narrow8Int#` and friends in `PrelRules`. Fix coming. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:31 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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
-+--
Reporter: bgamari | Owner: simonmar
Type: bug | Status: infoneeded
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit 3af022f3ae6ff3adceb2318cf50549d954e8bbe7
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 16:52:16 2013 +
Fix some incorrect narrowing rules (#7361)
e.g. narrow8Int# subsumes narrow16Int#, not the other way around.
compiler/prelude/PrelRules.lhs | 24
1 files changed, 12 insertions(+), 12 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:32
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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf ---+ Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: infoneeded = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:33 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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf ---+ Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by bgamari): Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:34 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] #7564: GHC fails without an error when building text-0.11.2.3
#7564: GHC fails without an error when building text-0.11.2.3 ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: |Related: ---+ I wanted to install GHC-7.6.1 on my server system. It is a CentOS 6. I have downloaded the ghc binary for linux x86_64, installed via make install Then I wanted to install cabal-install from the hackage. I executed bootstrap.sh, and all went ok until it arrived at the text package. GHC stopped there without any error or message. So I downloaded text manually and executed ./Setup compile -v3. I have attached the resulting logs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7564 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] #7565: GHC fails without an error when building text-0.11.2.3
#7565: GHC fails without an error when building text-0.11.2.3 -+-- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking:|Related: -+-- Coming from [here](https://github.com/haskell/cabal/issues/1173). I installed GHC-7.6.1 from the binary package, on my CentOS 6 webspace. Then I wanted to install `cabal-install`, but the compilation failed at the `text` package without a message. They told me it is an error with GHC, so I try to submit here. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7565 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] #7505: Commentary shipped with GHC sources is outdated
#7505: Commentary shipped with GHC sources is outdated -+-- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by jstolarek): If I verified that everything in the commentary is in the wiki would you agree to remove it from the source distribution? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7505#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] #5777: core lint error with arrow notation and GADTs
#5777: core lint error with arrow notation and GADTs
-+--
Reporter: benmos| Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.6.2
Component: Compiler | Version: 7.4.2
Keywords: arrows, GADTs | Os: MacOS X
Architecture: Unknown/Multiple | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by altaic):
* version: 7.4.1-rc1 = 7.4.2
* architecture: x86 = Unknown/Multiple
Comment:
This also happens on GHC 7.4.2 x86_64.
{{{
$ ghc --make Test3.hs
[1 of 1] Compiling Main ( Test3.hs, Test3.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for x86_64-apple-darwin):
cgLookupPanic (probably invalid Core; try -dcore-lint)
( $dArrow{v amL} [lid] :: base:Control.Arrow.Arrow{tc r4n}
ghc-prim:GHC.Prim.(-){(w) tc 3D} )
static binds for:
local binds for:
( main:Main.arrif{v rci} [gid[ClassOp]] :: forall (( f{tv acm} [tv] ::
ghc-prim:GHC.Prim.*{(w) tc 34d}
- ghc-prim:GHC.Prim.*{(w) tc 34d} ) :: ghc-prim:GHC.Prim.*{(w) tc 34d}
- ghc-prim:GHC.Prim.*{(w) tc 34d}).
main:Main.ArrowInit{tc rch}
( f{tv acm} [tv] :: ghc-
prim:GHC.Prim.*{(w) tc 34d}
-
ghc-prim:GHC.Prim.*{(w) tc 34d} ) =
forall ( b{tv acn} [tv] ::
ghc-prim:GHC.Prim.*{(w) tc 34d} ).
( f{tv acm} [tv] :: ghc-
prim:GHC.Prim.*{(w) tc 34d}
- ghc-
prim:GHC.Prim.*{(w) tc 34d} ) ( b{tv acn} [tv] :: ghc-prim:GHC.Prim.*{(w)
tc 34d} )
- ghc-
prim:GHC.Tuple.(){(w) tc 40} )
( main:Main.$WBoolVal{v rcH} [gid[DataConWrapper]] ::
main:Main.Value{tc rcj}
ghc-
prim:GHC.Types.Bool{(w) tc 3c} )
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5777#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] #7475: Mysterious Data.Word Segmentation Fault in GHCi
#7475: Mysterious Data.Word Segmentation Fault in GHCi --+- Reporter: VKS| Owner: Type: bug| Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: ghci, data.word, segfault | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown|Testcase: Blockedby: 3658 |Blocking: Related: | --+- Comment(by altaic): This doesn't appear to happen with 7.4.2 or in HEAD (7.7.20130109), both x86_64. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7475#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] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion --+- Reporter: shachaf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: perf/should_runt/T7436 | Blockedby: Blocking: |Related: --+- Changes (by liyang): * cc: hackage.haskell.org@… (added) Comment: Since this issue affects a large number of users and doesn't seem too contentious, could this fix be included in 7.6.2? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Error building ghc on raspberry pi.
Thanks for the advice; However, it had little effect. I now have the errors: ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1 Anyone else building GHC on a pi? On Tue, 8 Jan 2013, Thijs Alkemade wrote: Op 8 jan. 2013, om 05:16 heeft rocon...@theorem.ca het volgende geschreven: On Thu, 3 Jan 2013, Thijs Alkemade wrote: I believe I had the same problem, which disappeared after upgrading llvm from 3.0 to 3.1, and using that instead for ./configure. Hope this helps, Thijs Thanks, using LLVM 3.1 seems to have improved the siutation, but I'm running into a new error. Here is the error I get when trying to build GHC 7.6.1 from 7.4.1 ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cjjbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1 I get similar errors when building GHC 7.4.1 (patched with http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support-for-ARM-hard-float-ABI-fixes-5914.patch). Any of you encountered this problem before? Yeah, I had a lot of these. The problem was that GHC has a lot of different CFLAGS, so finding the right way to pass -float-abi=hard to every one of them took some time, but eventually I ended up with the following change to mk/build.mk: ifeq $(BuildFlavour) quick SRC_HC_OPTS= -H64m -O0 -fasm GhcStage1HcOpts= -O -fasm GhcStage2HcOpts= -O0 -fasm GhcLibHcOpts = -O -fasm -optlc-float-abi=hard SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif (Change the build flavor you are using, of course) And I ran configure as: LDFLAGS=-marm -mfloat-abi=hard -mfpu=vfp CFLAGS=-marm -mfloat-abi=hard -mfpu=vfp ./configure --with-opt=/usr/bin/opt-3.1 --with-llc=/usr/bin/llc-3.1 --with-ld=`which ld.gold` (I switched to the gold linker, because ld was running out of RAM often.) I did eventually finish building stage2, but the final executable segfaulted on start. I haven't investigated much why that happened, the days it takes to rebuild it just made me give up. Hope this helps, Thijs -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
Hi, find ghc's generated settings file. What FPU is used there? Thanks, Karel On 01/ 9/13 09:47 PM, rocon...@theorem.ca wrote: Thanks for the advice; However, it had little effect. I now have the errors: ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1 Anyone else building GHC on a pi? On Tue, 8 Jan 2013, Thijs Alkemade wrote: Op 8 jan. 2013, om 05:16 heeft rocon...@theorem.ca het volgende geschreven: On Thu, 3 Jan 2013, Thijs Alkemade wrote: I believe I had the same problem, which disappeared after upgrading llvm from 3.0 to 3.1, and using that instead for ./configure. Hope this helps, Thijs Thanks, using LLVM 3.1 seems to have improved the siutation, but I'm running into a new error. Here is the error I get when trying to build GHC 7.6.1 from 7.4.1 ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cjjbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1 I get similar errors when building GHC 7.4.1 (patched with http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support-for-ARM-hard-float-ABI-fixes-5914.patch). Any of you encountered this problem before? Yeah, I had a lot of these. The problem was that GHC has a lot of different CFLAGS, so finding the right way to pass -float-abi=hard to every one of them took some time, but eventually I ended up with the following change to mk/build.mk: ifeq $(BuildFlavour) quick SRC_HC_OPTS = -H64m -O0 -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -fasm GhcLibHcOpts = -O -fasm -optlc-float-abi=hard SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif (Change the build flavor you are using, of course) And I ran configure as: LDFLAGS=-marm -mfloat-abi=hard -mfpu=vfp CFLAGS=-marm -mfloat-abi=hard -mfpu=vfp ./configure --with-opt=/usr/bin/opt-3.1 --with-llc=/usr/bin/llc-3.1 --with-ld=`which ld.gold` (I switched to the gold linker, because ld was running out of RAM often.) I did eventually finish building stage2, but the final executable segfaulted on start. I haven't investigated much why that happened, the days it takes to rebuild it just made me give up. Hope this helps, Thijs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
(mips64el) Cross-building GHC
Hello. I would like to port GHC to mips64el. I have never tried cross-building before. So I will probably post more questions later. Actually, I am not sure that I am using the right term. I am going to use my i686 machine to build GHC for mips64el. In terms of this page(0): B = i686-unknown-linux H = mips64el-unknown-linux T = mips64el-unknown-linux Is the above correct? What I did: 1. Downloaded this(1) tarball (on i686) and unpacked it. 2. Executed the following commands(2): ghc-7.6.1$ cp /bin/pwd utils/ghc-pwd/ghc-pwd ghc-7.6.1$ perl boot ghc-7.6.1$ ./configure --enable-hc-boot --build=i686-unknown-linux --host=mips64el-unknown-linux --target=mips64el-unknown-linux Output: checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for ghc... /usr/bin/ghc checking version of ghc... 6.12.1 checking build system type... i686-unknown-linux-gnu checking host system type... mips64el-unknown-linux-gnu checking target system type... mips64el-unknown-linux-gnu HOST: mips64el-unknown-linux-gnu GHC build : i386-unknown-linux GHC host : mips-unknown-linux GHC target : mips-unknown-linux configure: Building in-tree ghc-pwd ghc: unrecognised flags: -no-user- Usage: For basic information, try the `--help' option. configure: error: Building ghc-pwd failed /ghc-7.6.1$ grep no-user ./* ./aclocal.m4:if ! $WithGhc -v0 -no-user-$GHC_PACKAGE_DB_FLAG -hidir utils/ghc-pwd/dist-boot -odir utils/ghc-pwd/dist-boot -stubdir utils/ghc-pwd/dist-boot --make utils/ghc-pwd/Main.hs -o utils/ghc-pwd/dist-boot/ghc-pwd ./configure:if ! $WithGhc -v0 -no-user-$GHC_PACKAGE_DB_FLAG -hidir utils/ghc-pwd/dist-boot -odir utils/ghc-pwd/dist-boot -stubdir utils/ghc-pwd/dist-boot --make utils/ghc-pwd/Main.hs -o utils/ghc-pwd/dist-boot/ghc-pwd How can I fix this? I can't find any information about this option. Thank you. PS: I only use free software (as defined by the FSF). Can I be sure that I won't install any non-free programs during the process? (0) http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation (1) http://www.haskell.org/ghc/dist/7.6.1/ghc-7.6.1-src.tar.bz2 (2) http://hackage.haskell.org/trac/ghc/wiki/Building/Porting ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (mips64el) Cross-building GHC
Somebody claiming to be jug...@lavabit.com wrote: I would like to port GHC to mips64el. I have never tried cross-building before. So I will probably post more questions later. Awesome. I have a MIPS-based netbook (lemote yeelong thing) and got the GHC port from Debian on it, but of course it's a just-barely-works build :) -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
This is the settingings file:
$ cat settings
[(GCC extra via C opts, -fwrapv),
(C compiler command, /usr/bin/gcc),
(C compiler flags, -fno-stack-protector -Wl,--hash-size=31
-Wl,--reduce-memory-overheads),
(ar command, /usr/bin/ar),
(ar flags, q),
(ar supports at file, YES),
(touch command, touch),
(dllwrap command, /bin/false),
(windres command, /bin/false),
(perl command, /usr/bin/perl),
(target os, OSLinux),
(target arch, ArchARM {armISA = ARMv6, armISAExt = [], armABI = HARD}),
(target word size, 4),
(target has GNU nonexec stack, False),
(target has .ident directive, True),
(target has subsections via symbols, False),
(LLVM llc command, /home/pi/.nix-profile/bin/llc),
(LLVM opt command, /home/pi/.nix-profile/bin/opt)
]
On Wed, 9 Jan 2013, Karel Gardas wrote:
Hi,
find ghc's generated settings file. What FPU is used there?
Thanks,
Karel
On 01/ 9/13 09:47 PM, rocon...@theorem.ca wrote:
Thanks for the advice; However, it had little effect.
I now have the errors:
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o
/usr/bin/ld: error:
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o uses VFP
register arguments,
libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not
/usr/bin/ld: failed to merge target specific data of file
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o
/usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o
uses VFP register arguments,
libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not
/usr/bin/ld: failed to merge target specific data of file
libraries/ghc-prim/dist-install/build/cbits/debug.o
/usr/bin/ld: error:
libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register
arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o
does not
/usr/bin/ld: failed to merge target specific data of file
libraries/ghc-prim/dist-install/build/cbits/longlong.o
/usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o
uses VFP register arguments,
libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not
/usr/bin/ld: failed to merge target specific data of file
libraries/ghc-prim/dist-install/build/cbits/popcnt.o
make[1]: ***
[libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1
Anyone else building GHC on a pi?
On Tue, 8 Jan 2013, Thijs Alkemade wrote:
Op 8 jan. 2013, om 05:16 heeft rocon...@theorem.ca het volgende
geschreven:
On Thu, 3 Jan 2013, Thijs Alkemade wrote:
I believe I had the same problem, which disappeared after upgrading
llvm from 3.0 to 3.1, and using that instead for ./configure.
Hope this helps,
Thijs
Thanks, using LLVM 3.1 seems to have improved the siutation, but I'm
running into a new error.
Here is the error I get when trying to build GHC 7.6.1 from 7.4.1
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o
/usr/bin/ld: error:
libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register
arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o
does not
/usr/bin/ld: failed to merge target specific data of file
libraries/ghc-prim/dist-install/build/cjjbits/debug.o
/usr/bin/ld: error:
libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP
register arguments,
libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not
/usr/bin/ld: failed to merge target specific data of file
libraries/ghc-prim/dist-install/build/cbits/longlong.o
/usr/bin/ld: error:
libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP
register arguments,
libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not
/usr/bin/ld: failed to merge target specific data of file
libraries/ghc-prim/dist-install/build/cbits/popcnt.o
make[1]: ***
[libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1
I get similar errors when building GHC 7.4.1 (patched with
http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support-for-ARM-hard-float-ABI-fixes-5914.patch).
Any of you encountered this problem before?
Yeah, I had a lot of these. The problem was that GHC has a lot of
different CFLAGS,
so finding the right way to pass -float-abi=hard to every one of
them took some time, but
eventually I ended up with the following change to mk/build.mk:
ifeq $(BuildFlavour) quick
SRC_HC_OPTS = -H64m -O0 -fasm
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -O0 -fasm
GhcLibHcOpts = -O -fasm -optlc-float-abi=hard
SplitObjs = NO
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
BUILD_DOCBOOK_PDF = NO
endif
(Change the build flavor you are using, of course)
And I ran configure as:
LDFLAGS=-marm -mfloat-abi=hard -mfpu=vfp CFLAGS=-marm
-mfloat-abi=hard -mfpu=vfp ./configure --with-opt=/usr/bin/opt-3.1
--with-llc=/usr/bin/llc-3.1 --with-ld=`which ld.gold`
(I switched to the gold linker,
Re: [Haskell] Haskell and Pandoc Let's Code-Style Video
Hi Chris, Thanks for that video, I'm looking forward to any more that you might do. Seeing your workflow is a very important aspect to your video, especially for newcomers trying to learn Haskell on their own. A brief overview of your tooling would be nice. Unfortunately, I shaved a yak very well, possibly more than once, while improving my PS1 prompt. Starting with duplicating your $? display but not stopping there… oh no, couldn't stop at just that :-) Cheers, Bob On 2013-01-07, at 6:50 PM, Chris Forno je...@jekor.com wrote: I've just uploaded a video walking through some of the source code for Pandoc. I plan to create more videos like it (on Pandoc and other open source/free software projects), and I'd appreciate your feedback. https://www.youtube.com/watch? v=FEFETKhhq8wfeature=youtube_gdata_play er I think Haskell is particularly well-suited for this type of study: - The code tends to be concise, and parts can usually be analyzed in isolation thanks to explicit state. - Even after 10 years of exposure to Haskell I feel like I still have much to learn about idiomatic style from the writings of others. - I've run across the same misconceptions about Haskell in the professional world (and had some myself in the beginning), and would like more people to see what Haskell really is like outside of papers and blog posts. Please let me know if there are other projects you'd like to see me cover. Thanks. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Weekly News: Issue 254
Welcome to issue 254 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers the
week of December 02, 2012 to January 05, 2013.
As some of you might have noticed, there has been an interruption in
the scheduled transmission of the newsletter. I have, over the past few
weeks, completed a move to NYC! It has been wonderful to meet many in
the community at the Haskell NYC meetups. Here is to a great year for
our cherised community.
Let's get things started out the right way, with a litte Lambda
Style :-)
[1] http://goo.gl/nQYdp
Quotes of the Week
* GuySteele: Some people prefer not to commingle the functional,
lambda-calculus part of a language with the parts that do side
effects. It seems they believe in the separation of Church and
state.
* edwardk: type level ieee floats are a crime against nature. i had
to implement them in c++ for template meta programming once. never
ever again
* acowley: (regarding Proxy) Haven't you ever wanted to put something
in a box and never think about it?
elliott: children
* merijn: xenocons: I spend the entire week grading FP homework, I
think it's impossible for you to surprise me :p
merijn: That's confusing :
* andr00: Today's software engineering word is farpotshket. This is
a Yiddish word meaning, broken, because someone tried to fix it.
* dmwit: I know, I know. 0, 1, many. But then I also write most of
my programs in a language whose type system has 4 levels. Four! Is
that even a number??
* aristid: a dubious motivation IMHO
edwardk: i've had worse =P
* ziarkaen: I'm thinking I can kill two birds with one stone by
learning Haskell while producing a website, but all the birds are
still alive at the moment.
* ion:
monad.bind = function (func, args) {
return func.apply(undefined,
[value].concat(Array.prototype.slice.apply(args || [])));
};
is idiomatic JavaScript?
* beaky: if stacks are recursion, what are queues?
Hafydd: Procrastination.
* elliott: I think lens is the first library I've seen that promises
letting you write abstract totally-inefficient-looking
compositional code and getting reliably good compilation which has
actually delivered on that promise.
* elliott: I didn't say half the things I said.
* shachaf: The two-letter and three-letter identifiers are for
edwardk's libraries. The one-letter identifiers are for his actual
code.
elliott: edwardk has non-library code?
* neutrino: in many ways, Haskell is like this primodial soup out of
which other languages end up springing
* mm_freak: bruce schneier is an endofunctor that turns all
automorphisms into identities
* roconnor: where are all the category theoriest? why don't they
already have all the answers for us?
edwardk: roconnor: this is the point in your career where you look
around for the cavalry and realize that you're it ;)
* cmccann: multi-letter type variables is an experimental new
extension
* elliott: I can't remember the last time I wrote any Haskell without
an evil grin.
* neutrino: when you're told you have to use javascript, the viable
alternative always remains in seppuku. and it's much more
honorable.
* shachaf: chrisdone: Please make Author not mandatory. [on hpaste]
donri: shachaf: just write not shachaf and no one will ever know
it's you
* tac: If you're not part of the solution, you're part of the
precipitate
* cmccann: some people blame themselves, some people blame the
language, but the people who really know what they're doing blame
shachaf.
Top Reddit Stories
* The end of an era, and the dawn of a new one
Domain: haskell.org, Score: 148, Comments: 32
On Reddit: [2] http://goo.gl/fiyVt
Original: [3] http://goo.gl/dlxsF
* Simon Peyton-Jones invests in FP Complete
Domain: fpcomplete.com, Score: 92, Comments: 15
On Reddit: [4] http://goo.gl/nPTk1
Original: [5] http://goo.gl/wzfpP
* 24 Days of Hackage - Thank YOU!
Domain: ocharles.org.uk, Score: 88, Comments: 12
On Reddit: [6] http://goo.gl/2yodj
Original: [7] http://goo.gl/hSsH6
* Heist 0.10...now with a 3000x performance improvement
Domain: snapframework.com, Score: 81, Comments: 38
On Reddit: [8] http://goo.gl/p7R7u
Original: [9] http://goo.gl/znugn
* 24 Days of Hackage: EKG
Domain: ocharles.org.uk, Score: 68, Comments: 15
On Reddit: [10] http://goo.gl/ltPb1
Original: [11] http://goo.gl/UeYOA
* pipes-3.0: Simpler, unified API
Domain: haskellforall.com, Score: 64, Comments: 71
On Reddit: [12] http://goo.gl/ZSVtT
Original: [13] http://goo.gl/6Yt01
* Hoodle : Pen note-taking program written in haskell
Domain: youtube.com, Score: 64, Comments: 21
On
Re: [Haskell-cafe] Announce: Leksah 0.13.1 (a bit experimental)
Hi Hamish, Features in process-leksah have been merged into process. For newer versions of GHC leksah-server just depends on process. I trust this applies to the unreleased beta version that you just announced, right? (The latest release versions still seem to depend on process-leksah.) In that case, I'll try again building Leksah once the new version is available from Hackage. Thank you for the quick response! Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
On Tue, Jan 8, 2013 at 10:54 PM, Joachim Breitner m...@joachim-breitner.de wrote: Am Dienstag, den 08.01.2013, 13:01 -0800 schrieb Evan Laforge: surprisingly, deepseq is not used as much as I thought. http://packdeps.haskellers.com/reverse/deepseq lists a lot of packages, but (after grepping through some of the code) most just define NFData instances and/or use it in tests, but rarely in the „real“ code. For some reason I expected it to be in more widespread use. I've been using deepseq quite a bit lately, but for the purpose of debugging space leaks. If, when I deepseq a big structure, the space leak goes away, I can then apply it to some subset. After much trial-and-error I can find something which is insufficiently strict. Ideally I can then strictify that one thing and stop using the deepseq. I wish there was a more efficient way to do this. this is also a possible application of my approach, by providing a „I want this data structure to be fully evaluated now, please tell me how it currently looks, i.e. where in the data structure still thunks lie hidden.“ Do you have a nice, striking example where using your approach (using deepseq and comparing efficiency) you could make a difference, and where a tool as described above would make the analysis much easier? We've also used this approach to debug space-leaks, and would have loved such a tool. We used deepseq, and compared the heap profiles. We finally found the leaks this way, and fixed them using strictness annotations. Finally, we verified by running deepseq again at top level and observing that it didn't change anything anymore. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
Hi Erik, Am Mittwoch, den 09.01.2013, 14:23 +0100 schrieb Erik Hesselink: We've also used this approach to debug space-leaks, and would have loved such a tool. We used deepseq, and compared the heap profiles. We finally found the leaks this way, and fixed them using strictness annotations. Finally, we verified by running deepseq again at top level and observing that it didn't change anything anymore. same question to you: Would you have a suitable test case that can be used to test and demonstrate the usefulness of such tools? Greetings, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HaskellDB-HDBC-PostgreSQL installation problem
Hello Community, I have a problem installing the HaskellDB-HDBC-PostgreSQL package with cabal. I'm using Haskell Platform in Windows and I tried to install this package, but there was the error could not find pq library. So I tried to install libpq wich includes pq but there was another error: this package needs a unix installation. Is there any way to install pq on Windows or get the HaskellDB-HDBC-PostgreSQL in another way? Thanks for your advice Johannes Reiher ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaskellDB-HDBC-PostgreSQL installation problem
Tricky. For what it's worth, if you can't figure this out in the end, you could perhaps use my pgsql-simple which is implemented in pure haskell: https://github.com/chrisdone/pgsql-simple It's been in use on hpaste.org for about 2 years. On 9 January 2013 14:44, Johannes.Reiher johannes.rei...@fh-zwickau.de wrote: Hello Community, I have a problem installing the HaskellDB-HDBC-PostgreSQL package with cabal. I'm using Haskell Platform in Windows and I tried to install this package, but there was the error could not find pq library. So I tried to install libpq wich includes pq but there was another error: this package needs a unix installation. Is there any way to install pq on Windows or get the HaskellDB-HDBC-PostgreSQL in another way? Thanks for your advice Johannes Reiher ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
On Wed, Jan 9, 2013 at 2:40 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi Erik, Am Mittwoch, den 09.01.2013, 14:23 +0100 schrieb Erik Hesselink: We've also used this approach to debug space-leaks, and would have loved such a tool. We used deepseq, and compared the heap profiles. We finally found the leaks this way, and fixed them using strictness annotations. Finally, we verified by running deepseq again at top level and observing that it didn't change anything anymore. same question to you: Would you have a suitable test case that can be used to test and demonstrate the usefulness of such tools? Sadly, no. This is a private, core part of our application that I cannot share. I can describe what we did, and also the structure of the data in broad terms: we have several Maps, where the keys are usually Text, and the values are custom data types. These contain keys into these maps again. The whole thing defines a graph with several indexes into it. We finally solved the problems by completely moving to strict map operations, strict MVar/TVar operations, and strict data types. If you have more questions, or tools you want to test, I'd be happy to help, though. Regards, Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaskellDB-HDBC-PostgreSQL installation problem
Try Persistent package. It doesn't depends on libpq and has many useful features (see http://www.yesodweb.com/book/persistent for details) On 01/09/2013 05:50 PM, Christopher Done wrote: Tricky. For what it's worth, if you can't figure this out in the end, you could perhaps use my pgsql-simple which is implemented in pure haskell: https://github.com/chrisdone/pgsql-simple It's been in use on hpaste.org for about 2 years. On 9 January 2013 14:44, Johannes.Reiher johannes.rei...@fh-zwickau.de wrote: Hello Community, I have a problem installing the HaskellDB-HDBC-PostgreSQL package with cabal. I'm using Haskell Platform in Windows and I tried to install this package, but there was the error could not find pq library. So I tried to install libpq wich includes pq but there was another error: this package needs a unix installation. Is there any way to install pq on Windows or get the HaskellDB-HDBC-PostgreSQL in another way? Thanks for your advice Johannes Reiher ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Alexander Alexeev http://eax.me/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking feedback for a tutorial paper draft about GADTs
On Tue, Jan 08, 2013 at 11:22:39PM +0400, Anton Dergunov wrote: I have written a draft of an introductory-level tutorial paper about GADTs in Haskell (for submittion to proceedings of the recent LASER summer school) and I would like to seek initial feedback about its content: what information is probably missing? are there any subtle mistakes? Not exactly the feedback you asked for, but I hope it still can be of some use. As a person with no prior knowledge about GADTs, I found your paper a good introduction. Following proof of correctness of red-black tree insertions turned out to be a little bit of a challenge as type annotations quickly become tangled (made me wondering how one should prove correctness of the proof). I particularly liked how you handle things that are not central to tutorial, like phantom and existential types: you give single-sentence explanation that provides good enough intuition to follow you further. Talking of quick explanations, I would love to see kinds and singleton types explained in the same manner. You tried to explain singleton types at page 13, but I find explanation provided by GHC documentation[1] to be much more clear. As for kinds, it just puzzles me why you use the term but don't explain it. 1. http://hackage.haskell.org/trac/ghc/wiki/TypeNats/Basics The same goes for type families - while I was able to quickly look up definition of singleton types, I failed to comprehend basics of type families by reading Haskell Wiki. I ended up pretending that type families are just type-level functions. I would love to see Yampa optimizations section expanded with more interesting examples. Are there any? Last but not least, a few minor typos and errors I spotted: * at page 8, Than we need to declare type instances... should be Then we need...; * probably due to excessive editing, parameters to repeatElem at page 13 are in the different order than before; * at page 14, you state: As in all binary search trees, for a particular node N c l x r values greater than x are stored in left sub-tree (in l) and values less than x are stored in right sub-tree (in r). But later on, your code contradict that statement by recursing to left sub-tree when x we look for is less than value in the node, and to right sub-tree when x is greater than value in the node. Thank you once again for a nice introduction to GADTs! -- Regards, Alexander Batischev PGP key 356961A20C8BFD03 Fingerprint: CE6C 4307 9348 58E3 FD94 A00F 3569 61A2 0C8B FD03 signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaskellDB-HDBC-PostgreSQL installation problem
AFAIK, persistent's PostgreSQL support does depend on libpq via postgresql-libpq. On Wed, Jan 9, 2013 at 12:39 PM, Alexander Alexeev m...@eax.me wrote: Try Persistent package. It doesn't depends on libpq and has many useful features (see http://www.yesodweb.com/book/persistent for details) On 01/09/2013 05:50 PM, Christopher Done wrote: Tricky. For what it's worth, if you can't figure this out in the end, you could perhaps use my pgsql-simple which is implemented in pure haskell: https://github.com/chrisdone/pgsql-simple It's been in use on hpaste.org for about 2 years. On 9 January 2013 14:44, Johannes.Reiher johannes.rei...@fh-zwickau.de wrote: Hello Community, I have a problem installing the HaskellDB-HDBC-PostgreSQL package with cabal. I'm using Haskell Platform in Windows and I tried to install this package, but there was the error could not find pq library. So I tried to install libpq wich includes pq but there was another error: this package needs a unix installation. Is there any way to install pq on Windows or get the HaskellDB-HDBC-PostgreSQL in another way? Thanks for your advice Johannes Reiher ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Alexander Alexeev http://eax.me/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is http://hackage.haskell.org/packages/hackage.html having a challenging serving up archive.tar?
:) -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Undo records
I think acid-state (http://hackage.haskell.org/package/acid-state) might do what you want, at least in broad strokes. It uses a durable transaction log to store query and update events. As far as I know, the interface to the library doesn't expose an undo/rollback function, so you'd have a bit of work to do to extend it to your use case. But the core functionality to make it possible should be there. Can you use ghc extensions aside from Template Haskell? Template Haskell you can do without with acid-state, but without GADTs and so on you'll have problems. On Sun, Jan 6, 2013 at 12:01 PM, Casey Basichis caseybasic...@gmail.comwrote: Hi, I am still getting a hang of Haskell. Sorry if the answer is obvious. What sorts of packages and approaches should I be looking at if I was looking to store something like an Undo stack into a database. Each table would refer to a function. Each records input and outputs would specify both a table ID and record ID. The records would also have a data and a Process ID to associate all functions to a specific process and give them an order. No records are ever deleted. Rolling something back is instead a process of recreating a new, modified graph by taking the old graph from the database. I should note that while I can generate some of the boiler parts from template haskell in advance I'm ultimately using a stage 1 compiler with no GHCI o template haskell. Thanks, Casey -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasic...@gmail.com 310.387.7540 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Undo records
Hi Ben, Thanks for the reply. I am planning on using Persistent which can work without template haskell, though I am planning on using the TH on my workstation to create the boiler code parts of the database setup. The part that I'm having trouble with is collecting the composed functions. It may be a very typical problem but I'm just lost. Let me just describe a simple example; A message comes through the FFI to: Haskell chooses criteria to select a sequence of data from the database --- many functions exist to do this, some may take a random number as a parameter, the seed needs to be stored Haskell similarly chooses a process to apply to the data --- A random number or other deterministic chain of functions The results from the processing are loaded into memory - (these are not the focus here) The minimal chain of functions, parameters and seeds is stored to allow for a deterministic recall/modification --- The input parameters and output parameters are Table and Row ID's So Haskell isn't reacting to many input events, just a trigger that may come with a few initialization parameters. If a function is composed of other functions which do not depend on external state they should not need to be stored in the database as they are implicit. I imagine this is a monad problem, but kind and what other things spring to mind that might help in approaching this kind of problem? Thanks, Casey On Wed, Jan 9, 2013 at 11:40 AM, Ben Doyle benjamin.peter.do...@gmail.comwrote: I think acid-state (http://hackage.haskell.org/package/acid-state) might do what you want, at least in broad strokes. It uses a durable transaction log to store query and update events. As far as I know, the interface to the library doesn't expose an undo/rollback function, so you'd have a bit of work to do to extend it to your use case. But the core functionality to make it possible should be there. Can you use ghc extensions aside from Template Haskell? Template Haskell you can do without with acid-state, but without GADTs and so on you'll have problems. On Sun, Jan 6, 2013 at 12:01 PM, Casey Basichis caseybasic...@gmail.comwrote: Hi, I am still getting a hang of Haskell. Sorry if the answer is obvious. What sorts of packages and approaches should I be looking at if I was looking to store something like an Undo stack into a database. Each table would refer to a function. Each records input and outputs would specify both a table ID and record ID. The records would also have a data and a Process ID to associate all functions to a specific process and give them an order. No records are ever deleted. Rolling something back is instead a process of recreating a new, modified graph by taking the old graph from the database. I should note that while I can generate some of the boiler parts from template haskell in advance I'm ultimately using a stage 1 compiler with no GHCI o template haskell. Thanks, Casey -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasic...@gmail.com 310.387.7540 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasic...@gmail.com 310.387.7540 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
Hi, Am Mittwoch, den 09.01.2013, 15:11 +0100 schrieb Erik Hesselink: We finally solved the problems by completely moving to strict map operations, strict MVar/TVar operations, and strict data types. do you mean strict by policy (i.e. before storing something in a [MT]Var, you ensure it is evaluated) or by construction (by `seq` or `deepseq`’ing everything before it is stored)? In the latter case: Seq or deeqseq? Again in the latter case: Do you worry about the performance of repeatedly deepseq’ing an already deepseq’ed and possibly large value? You are not the first user of Haskell who ends up with that approach to lazy evaluation. I’m not sure what that means for Haskell, though. Greetings, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaskellDB-HDBC-PostgreSQL installation problem
there was another error: this package needs a unix installation. you need to use MinGW, but it still fails because of a GHC bug http://hackage.haskell.org/trac/ghc/ticket/7103 https://github.com/lpsmith/postgresql-libpq/issues/7 -e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell.cs.yale.edu error
I was hoping to check on the status of Yampa, but: http://haskell.cs.yale.edu/ [an error occurred while processing this directive] You don't have permission to access the requested directory. There is either no index document or the directory is read-protected. [an error occurred while processing this directive] Do you know who maintains this website? Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 254
Welcome to issue 254 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers the
week of December 02, 2012 to January 05, 2013.
As some of you might have noticed, there has been an interruption in
the scheduled transmission of the newsletter. I have, over the past few
weeks, completed a move to NYC! It has been wonderful to meet many in
the community at the Haskell NYC meetups. Here is to a great year for
our cherised community.
Let's get things started out the right way, with a litte Lambda
Style :-)
[1] http://goo.gl/nQYdp
Quotes of the Week
* GuySteele: Some people prefer not to commingle the functional,
lambda-calculus part of a language with the parts that do side
effects. It seems they believe in the separation of Church and
state.
* edwardk: type level ieee floats are a crime against nature. i had
to implement them in c++ for template meta programming once. never
ever again
* acowley: (regarding Proxy) Haven't you ever wanted to put something
in a box and never think about it?
elliott: children
* merijn: xenocons: I spend the entire week grading FP homework, I
think it's impossible for you to surprise me :p
merijn: That's confusing :
* andr00: Today's software engineering word is farpotshket. This is
a Yiddish word meaning, broken, because someone tried to fix it.
* dmwit: I know, I know. 0, 1, many. But then I also write most of
my programs in a language whose type system has 4 levels. Four! Is
that even a number??
* aristid: a dubious motivation IMHO
edwardk: i've had worse =P
* ziarkaen: I'm thinking I can kill two birds with one stone by
learning Haskell while producing a website, but all the birds are
still alive at the moment.
* ion:
monad.bind = function (func, args) {
return func.apply(undefined,
[value].concat(Array.prototype.slice.apply(args || [])));
};
is idiomatic JavaScript?
* beaky: if stacks are recursion, what are queues?
Hafydd: Procrastination.
* elliott: I think lens is the first library I've seen that promises
letting you write abstract totally-inefficient-looking
compositional code and getting reliably good compilation which has
actually delivered on that promise.
* elliott: I didn't say half the things I said.
* shachaf: The two-letter and three-letter identifiers are for
edwardk's libraries. The one-letter identifiers are for his actual
code.
elliott: edwardk has non-library code?
* neutrino: in many ways, Haskell is like this primodial soup out of
which other languages end up springing
* mm_freak: bruce schneier is an endofunctor that turns all
automorphisms into identities
* roconnor: where are all the category theoriest? why don't they
already have all the answers for us?
edwardk: roconnor: this is the point in your career where you look
around for the cavalry and realize that you're it ;)
* cmccann: multi-letter type variables is an experimental new
extension
* elliott: I can't remember the last time I wrote any Haskell without
an evil grin.
* neutrino: when you're told you have to use javascript, the viable
alternative always remains in seppuku. and it's much more
honorable.
* shachaf: chrisdone: Please make Author not mandatory. [on hpaste]
donri: shachaf: just write not shachaf and no one will ever know
it's you
* tac: If you're not part of the solution, you're part of the
precipitate
* cmccann: some people blame themselves, some people blame the
language, but the people who really know what they're doing blame
shachaf.
Top Reddit Stories
* The end of an era, and the dawn of a new one
Domain: haskell.org, Score: 148, Comments: 32
On Reddit: [2] http://goo.gl/fiyVt
Original: [3] http://goo.gl/dlxsF
* Simon Peyton-Jones invests in FP Complete
Domain: fpcomplete.com, Score: 92, Comments: 15
On Reddit: [4] http://goo.gl/nPTk1
Original: [5] http://goo.gl/wzfpP
* 24 Days of Hackage - Thank YOU!
Domain: ocharles.org.uk, Score: 88, Comments: 12
On Reddit: [6] http://goo.gl/2yodj
Original: [7] http://goo.gl/hSsH6
* Heist 0.10...now with a 3000x performance improvement
Domain: snapframework.com, Score: 81, Comments: 38
On Reddit: [8] http://goo.gl/p7R7u
Original: [9] http://goo.gl/znugn
* 24 Days of Hackage: EKG
Domain: ocharles.org.uk, Score: 68, Comments: 15
On Reddit: [10] http://goo.gl/ltPb1
Original: [11] http://goo.gl/UeYOA
* pipes-3.0: Simpler, unified API
Domain: haskellforall.com, Score: 64, Comments: 71
On Reddit: [12] http://goo.gl/ZSVtT
Original: [13] http://goo.gl/6Yt01
* Hoodle : Pen note-taking program written in haskell
Domain: youtube.com, Score: 64, Comments: 21
On
Re: [arch-haskell] Signing errors
Hello, On 2013-01-09 at 13:30 +0100, Ramses wrote: With the repo being signed now, I get the following error when running pacman -Suy after updating my pacman.conf: error: haskell-core: signature from ArchHaskell (Magnus Therning) mag...@therning.org is unknown trust error: failed to update haskell-core (invalid or corrupted database (PGP signature)) snip, other repos error: database 'haskell-core' is not valid (invalid or corrupted database (PGP signature)) I imported the key as pacman asked me, but it seems I'm missing something. Pacman only imported the key into its keyring, but you have to sign it manually in order to also trust it. This is what the signature from ... is unknown trust message is about. See https://wiki.archlinux.org/index.php/Pacman-key#Adding_Unofficial_keys Does anyone here know how to fix this? You can trust Magnus' package signing key by running: pacman-key --lsign-key 4209170B Regards, Sebastian ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Signed repos
On Wed, Jan 9, 2013 at 12:54 PM, Fabio Riga rifa...@gmail.com wrote: I've now signed the official repos, both x86_64 and i686. The signing will work whether you access it as [haskell] or [haskell-core]. I've also signed the database, which means the following kind of entry will now work: [haskell-core] SigLevel = Required TrustedOnly Server = http://www.kiwilight.com/haskell/core/$arch Is kiwilight.com the new default server? At the moment I still use xsounds.org... No, it just happens to be the one I use, since it's also the one where I compile. All signatures have been pushed to xsounds.org as well. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
