Re: [GHC] #5509: quotes pretty-printer not working as comments specify
#5509: quotes pretty-printer not working as comments specify
-+--
Reporter: mgsloan1 |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.2.1
Keywords: prettyprint | Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect warning at
compile-time
-+--
Comment(by simonpj@…):
commit ba60fc61ba5bbac8d0bbeb719fe26daa4058e1c5
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Thu Sep 29 09:45:42 2011 +0100
Make Outputable.quotes do what the comments say
Outputable.quotes claimed to drop the quotes if the enclosed thing has
a trailing single quote; but its implementation checked for
a *leading* quote.
Fixes Trac #5509
compiler/utils/Outputable.lhs |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5509#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] #5509: quotes pretty-printer not working as comments specify
#5509: quotes pretty-printer not working as comments specify +--- Reporter: mgsloan1 | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.2.1 Resolution: fixed | Keywords: prettyprint Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | +--- Changes (by simonpj): * status: new = closed * resolution: = fixed Comment: Done. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5509#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] #5448: GHC stuck in infinite loop compiling with optimizations
#5448: GHC stuck in infinite loop compiling with optimizations
-+--
Reporter: ronwalf | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: Compiler|Version: 7.0.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: MacOS X
Blocking: | Architecture: x86_64 (amd64)
Failure: Compile-time crash |
-+--
Changes (by simonpj):
* milestone: = _|_
Comment:
I've also added documentation
{{{
commit b347eff0cd771ab9e1f3a80c6c91615255e4fe41
Author: Simon Peyton Jones simo...@microsoft.com
Date: Thu Sep 29 09:42:53 2011 +0100
Document -fsimpl-tick-count
docs/users_guide/flags.xml | 166
+++-
docs/users_guide/using.xml | 92 +++-
2 files changed, 144 insertions(+), 114 deletions(-)
}}}
I'll leave the ticket open to keep track of the main issue (that the
compiler can loop), but with milestone of bottom.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5448#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] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---+ Reporter: jeffz1| Owner: Type: bug | Status: patch Priority: normal| Milestone: 7.2.1 Component: GHCi |Version: 7.0.1 Resolution:| Keywords: Testcase:| Blockedby: Difficulty: Unknown | Os: Windows Blocking:| Architecture: x86 Failure: None/Unknown | ---+ Changes (by keloglan2011): * status: new = patch Comment: fryguybob's solution worked. Thanks fryguybob. :) (renaming mingwex.dll to m.dll and putting it in your path solves it without recompiling anything ) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3242#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5520: Spurious warning with new associated types and MultiParamTypeClasses
#5520: Spurious warning with new associated types and MultiParamTypeClasses -+-- Reporter: batterseapower|Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time -+-- Comment(by simonpj): What do you want? * Do not emit such warnings at all * Emit only if a flag says so (curent the flag is `-fwarn-missing- methods` but we could be more specific, `-fwarm-missing-ats`, I suppose * See if there's a top level instance (in this module? imported?). I rather not do this; it seems too non-local to me, and would be significant effort. Maybe an assocaited type isn't the right thing for this case? And it's only a warning! Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5520#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] #5514: bad variable escape analysis when TypeFamilies are enabled
#5514: bad variable escape analysis when TypeFamilies are enabled -+-- Reporter: dmwit |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonpj): I'm on it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5514#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] #5204: request better error message for malformed quasiquoted declaration
#5204: request better error message for malformed quasiquoted declaration
-+--
Reporter: nr|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.4.1
Component: Compiler (Parser) | Version: 7.0.3
Keywords: quasiquotation, pads-haskell | Testcase: attached to ticket
Blockedby:| Difficulty:
Os: Linux | Blocking:
Architecture: x86 | Failure: Other
-+--
Comment(by gmainland):
You're right, this is a terrible error message and it's my fault. The
attached patch gives this error message instead:
{{{
Pnm.hs:17:7: unterminated quasiquotation at end of input
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5204#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] #3897: reading a large String as Double takes too long
#3897: reading a large String as Double takes too long +--- Reporter: maeder |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: Prelude | Version: 6.12.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux| Blocking: Architecture: x86 | Failure: Runtime performance bug +--- Comment(by maeder): I've noticed the same problem for the float parsers in `Text.ParserCombinators.Parsec.Token.exponent'` (or Text.Parsec.Token) that use `10^e` to compute the factor. Using '10**e' instead (hopefully) solved the problem in my `Text.ParserCombinators.Parsec.Number` module (function `exponentValue`) from http://hackage.haskell.org/package/parsec- numbers -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3897#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] #5481: Associated type defaults + MultiParamTypeClasses error
#5481: Associated type defaults + MultiParamTypeClasses error
+---
Reporter: illissius | Owner:
Type: bug| Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.3
Resolution: fixed | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: GHC rejects valid program |
+---
Comment(by simonpj):
No, it should work ''neither way''! In any type instance, whether
associated or not, the variables mentioned on the RHS must be a subset of
those on the LHS. So the above code should fail with
{{{
T5481.hs:6:5:
The RHS of an associated type declaration mentions type variable `b'
All such variables must be bound on the LHS
T5481.hs:8:5:
The RHS of an associated type declaration mentions type variable `a'
All such variables must be bound on the LHS
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5481#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] #5204: request better error message for malformed quasiquoted declaration
#5204: request better error message for malformed quasiquoted declaration -+-- Reporter: nr|Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.4.1 Component: Compiler (Parser) | Version: 7.0.3 Keywords: quasiquotation, pads-haskell | Testcase: attached to ticket Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86 | Failure: Other -+-- Comment(by simonpj): Thanks. I'll apply. Can you make a test pls? S -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5204#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] #5516: Universally quantified GADT context leads to overlapping instance
#5516: Universally quantified GADT context leads to overlapping instance -+-- Reporter: andersk |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- Comment(by simonpj): I'm not sure what the issue is here. Is there a bug? Can we just close this? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5516#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] #5237: Inefficient code generated for x^2
#5237: Inefficient code generated for x^2 ---+ Reporter: scpmw |Owner: Type: bug | Status: patch Priority: normal |Milestone: 7.4.1 Component: libraries/base | Version: 7.0.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime performance bug ---+ Comment(by simonpj): I'm still unclear what the problem is. Could you boil out a standalone case that illustrates the problem you are trying to solve. The numeric system is complicated and my brain is small. Thanks. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5237#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] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by simonpj): Could someone summarise exactly what the problem is here? It looks like a fiddly corner case so it would help to have a precise, standalone description of the problem. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#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] #5481: Associated type defaults + MultiParamTypeClasses error
#5481: Associated type defaults + MultiParamTypeClasses error
+---
Reporter: illissius | Owner:
Type: bug| Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.3
Resolution: fixed | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: GHC rejects valid program |
+---
Comment(by illissius):
Hmm. Intuitively, though, taking the original example:
{{{
class Foo a b where
type X a
type X a = b
type Y b
type Y b = a
}}}
The default associated types aren't actual type family instance
declarations, otherwise they'd result in overlap every time a specific
instance chose a different RHS from the default. The defaults only get
instantiated (if that's the right terminology) when an instance for the
class is actually declared.
So if I write
{{{
instance Foo Int Char
}}}
what that really means is
{{{
instance Foo Int Char where
type X Int = Char
type Y Char = Int
}}}
No type variables on the RHS!
There'd be nothing at all preventing me from writing that manually, or
from writing it the same way at the top level with non-associated type
families. It'd merely be longer.
Am I wrong?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5481#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] #5481: Associated type defaults + MultiParamTypeClasses error
#5481: Associated type defaults + MultiParamTypeClasses error
+---
Reporter: illissius | Owner:
Type: bug| Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.3
Resolution: fixed | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: GHC rejects valid program |
+---
Comment(by simonpj):
But if you said
{{{
instance Foo [a] [b]
}}}
you'd generate the bogus instance
{{{
instance Foo [a] [b] where
type X [a] = [b]
type Y [b] = [a]
}}}
I think that defaults should always generate correct code. At lesat that's
the conservative choice.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5481#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] #5481: Associated type defaults + MultiParamTypeClasses error
#5481: Associated type defaults + MultiParamTypeClasses error +--- Reporter: illissius | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.3 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | +--- Comment(by illissius): Good point. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5481#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] #5500: old-time fails to build
#5500: old-time fails to build -+-- Reporter: jmitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/old-time |Version: 7.0.4 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Compile-time crash | -+-- Comment(by jmitchell): Any idea when a fixed old-time will be released for cabal to install? Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5500#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] #5514: bad variable escape analysis when TypeFamilies are enabled
#5514: bad variable escape analysis when TypeFamilies are enabled
-+--
Reporter: dmwit |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonpj@…):
commit 9aa66e06f220ce6318d9f72e3112912da7dc4c45
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Thu Sep 29 16:06:17 2011 +0100
Eliminate alleged optimisation that means we bogusly did NoGen
Fixes Trac #5514. The fix is simply to delete some code.
compiler/typecheck/TcBinds.lhs |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5514#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] #5513: panic! (the 'impossible' happened) on ‘deriving instance lowercase_name a’
#5513: panic! (the 'impossible' happened) on ‘deriving instance lowercase_name
a’
-+--
Reporter: andersk | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Compile-time crash
-+--
Comment(by simonpj@…):
commit ce1f1cd5f0ec5f07475e44cf2b7f72e0cbb8a963
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Thu Sep 29 16:47:57 2011 +0100
Tidy up the shape-checking for instance types
(in instance and standalone deriving decls)
Fixes Trac #5513.
compiler/parser/Parser.y.pp |7 +++
compiler/parser/RdrHsSyn.lhs | 21 -
compiler/rename/RnNames.lhs | 10 +++---
compiler/rename/RnSource.lhs |4 ++--
compiler/rename/RnTypes.lhs | 17 -
5 files changed, 28 insertions(+), 31 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5513#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] #5515: panic! (the 'impossible' happened) with evil self-referential instance
#5515: panic! (the 'impossible' happened) with evil self-referential instance
-+--
Reporter: andersk | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Compile-time crash
-+--
Comment(by simonpj@…):
commit 817d1b047b538e408a8758a18270c51d429de670
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Thu Sep 29 16:05:16 2011 +0100
Fix scoping for RHS of associated type decls (fixes Trac #5515)
We should not allow things like
class C a b where
type F a :: *
instance C (p,q) r where
type F (p,q) = r -- No! fvs(rhs) should be a subset
-- of fvs(lhs)
compiler/hsSyn/HsDecls.lhs | 11 ---
compiler/rename/RnSource.lhs | 42
++
2 files changed, 34 insertions(+), 19 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5515#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] #5204: request better error message for malformed quasiquoted declaration
#5204: request better error message for malformed quasiquoted declaration
-+--
Reporter: nr|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.4.1
Component: Compiler (Parser) | Version: 7.0.3
Keywords: quasiquotation, pads-haskell | Testcase: attached to ticket
Blockedby:| Difficulty:
Os: Linux | Blocking:
Architecture: x86 | Failure: Other
-+--
Comment(by gmainlan@…):
commit 20548c92fb307fc012956c66efa9164843d921c7
{{{
Author: Geoffrey Mainland gmain...@microsoft.com
Date: Thu Sep 29 12:31:49 2011 +0100
Give a better error message for unterminated quasiquotations (fixes
#5204).
compiler/parser/Lexer.x | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5204#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] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by maeder): When converting a pat or a funlhs into a sequence for the fixity resolution, prefix minus signs are currently wrongly ignored as more atomic lpats. If fixity resolution succeeds with these minus signs considered, then it should be checked if the argument of all minus signs is (still) a plain integer or float (as required by the grammar for lpat). The current parsing of patterns (with minus signs deeper in the trees) is rather unhelpful, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by maeder): P.S. you need to be able to distinguish -1 from (-1) when constructing the sequence for fixity resolution (the latter case is really atomic). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5516: Universally quantified GADT context leads to overlapping instance
#5516: Universally quantified GADT context leads to overlapping instance -+-- Reporter: andersk |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- Comment(by andersk): Even if GHC is unable to use the polymorphic evidence, I feel like its presence should not cause an error when the code would otherwise have worked. If that’s true, this is a regression from 7.0. But probably nobody writes code like this, so I guess the question is whether there’s now a good reason to disallow it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5516#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] #5237: Inefficient code generated for x^2
#5237: Inefficient code generated for x^2
---+
Reporter: scpmw |Owner:
Type: bug | Status: patch
Priority: normal |Milestone: 7.4.1
Component: libraries/base | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime performance bug
---+
Comment(by daniel.is.fischer):
The problem is that if you write `expr ^ 2` in the source, that's exactly
what you get. But it's not what you want.
Consider the programme
{{{
{-# LANGUAGE BangPatterns #-}
module Main (main) where
import System.Environment (getArgs)
fun :: Double - Double
fun x = go 0 0.5
where
go !acc z
| x z = acc
| otherwise = go (acc + z^2) (z+0.25)
main :: IO ()
main = getArgs = mapM_ (print . fun . read)
}}}
Compiling it with ghc-7.2.1, I get nearly 32K of Core and an executable
delivering
{{{
dafis@schwartz:~/Haskell/BeginnersTesting ./squareTest721 +RTS -s -RTS
1.2e7
2.304720013998e21
2,304,132,792 bytes allocated in the heap
186,544 bytes copied during GC
28,992 bytes maximum residency (1 sample(s))
26,288 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max
pause
Gen 0 4411 colls, 0 par0.01s0.01s 0.s
0.s
Gen 1 1 colls, 0 par0.00s0.00s 0.0004s
0.0004s
INITtime0.00s ( 0.00s elapsed)
MUT time2.53s ( 2.53s elapsed)
GC time0.02s ( 0.01s elapsed)
EXITtime0.00s ( 0.00s elapsed)
Total time2.54s ( 2.54s elapsed)
%GC time 0.6% (0.6% elapsed)
Alloc rate910,944,778 bytes per MUT second
Productivity 99.4% of total user, 99.4% of total elapsed
}}}
Compiling it with ghc-7.3.20110926 with rewrite rules, I get 6.6K of Core
and an executable delivering
{{{
dafis@schwartz:~/Haskell/BeginnersTesting ./squareTest73R +RTS -s -RTS
1.2e7
2.304720013998e21
132,184 bytes allocated in the heap
3,304 bytes copied during GC
44,200 bytes maximum residency (1 sample(s))
17,240 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max
pause
Gen 0 0 colls, 0 par0.00s0.00s 0.s
0.s
Gen 1 1 colls, 0 par0.00s0.00s 0.0001s
0.0001s
INITtime0.00s ( 0.00s elapsed)
MUT time0.07s ( 0.07s elapsed)
GC time0.00s ( 0.00s elapsed)
EXITtime0.00s ( 0.00s elapsed)
Total time0.07s ( 0.07s elapsed)
%GC time 0.1% (0.1% elapsed)
Alloc rate1,767,189 bytes per MUT second
Productivity 99.5% of total user, 103.1% of total elapsed
}}}
Since `(^)` is `{-# INLINABLE #-}`, GHC will most of the time create a
type-specialised version of the exponentiation-by-repeated-squaring
algorithm (a wrapper to test that the exponent isn't negative and to
unpack the arguments if applicable, and two loops for the work). That
function is then called with an exponent of 2. This creates a lot of code,
much of which is never used (one loop runs twice, the other not at all).
And it is an out-of-line function call, which can cost a lot of time in a
loop.
Having GHC rewrite `expr ^ 2` into `expr * expr`, a) no code for `(^)` has
to be generated (or linked), b) for many types you get an inline
multiplication instead of a function call.
Theoretically, a compiler could in such a situation, when one argument is
statically known at compile time, try to evaluate the function a few steps
to see what gives (the speculative loop unrolling mentioned by scpmw in
the ticket). In this case, it'd find
{{{
2 0 ? No = calculate f x 2
even 2 ? Yes = calculate f (x*x) 1
even 1 ? No = 1 == 1 ? Yes = result is (x*x)
}}}
I would expect it to be tremendously hard to implement such a speculative
evaluation in a way that would often yield useful results and not unduly
increase compile times, though.
So while no true magic is available, let's add a few rewrite rules to
catch the cases where using `(^)` hurts most:
{{{
{-# RULES
^2/Integer forall x. x ^ (2 :: Integer) = x*x
^3/Integer forall x. x ^ (3 :: Integer) = (x*x)*x
^4/Integer forall x. x ^ (4 :: Integer) = let y = x*x in y*y
#-}
}}}
Fine. Now scpmw's `2.0 ^ 2`
Re: [GHC] #5519: Some unicode symbols are not allow in literal characters or strings
#5519: Some unicode symbols are not allow in literal characters or strings --+- Reporter: ertai | Owner: Type: bug | Status: closed Priority: normal| Component: Compiler Version: 7.2.1 | Resolution: duplicate Keywords:| Testcase: Blockedby:| Os: Linux Blocking:| Architecture: x86_64 (amd64) Failure: None/Unknown | --+- Changes (by daniel.is.fischer): * status: new = closed * resolution: = duplicate Comment: Duplicate of #5518 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5519#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] #4451: Re-linking avoidance is too aggressive
#4451: Re-linking avoidance is too aggressive -+-- Reporter: simonmar |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.4.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Other -+-- Changes (by jwlato): * cc: jwlato@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4451#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] #5282: Bizarre results from -P profiler on OS X
#5282: Bizarre results from -P profiler on OS X -+-- Reporter: bos |Owner: Type: bug | Status: new Priority: high |Milestone: 7.4.1 Component: Runtime System| Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: x86_64 (amd64)| Failure: Incorrect result at runtime -+-- Changes (by jwlato): * cc: jwlato@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5282#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5514: bad variable escape analysis when TypeFamilies are enabled
#5514: bad variable escape analysis when TypeFamilies are enabled ---+ Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.3 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by dmwit): * status: new = closed * resolution: = fixed Comment: Fix works perfectly. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5514#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] #5501: randomR overflow
#5501: randomR overflow --+- Reporter: daniel.is.fischer |Owner: rrnewton Type: bug| Status: new Priority: normal |Milestone: Component: libraries/random | Version: 7.2.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime --+- Changes (by igloo): * owner: = rrnewton -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5501#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] #5509: quotes pretty-printer not working as comments specify
#5509: quotes pretty-printer not working as comments specify +--- Reporter: mgsloan1 | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.2.1 Resolution: fixed | Keywords: prettyprint Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | +--- Comment(by igloo): Would it make more sense to never quote identifiers? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5509#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] #5237: Inefficient code generated for x^2
#5237: Inefficient code generated for x^2
--+-
Reporter: scpmw| Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.4.1
Component: libraries/base |Version: 7.0.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Linux
Blocking: | Architecture: x86_64 (amd64)
Failure: Runtime performance bug |
--+-
Changes (by igloo):
* status: patch = new
Comment:
So if I understand correctly, the problem is that with `q.hs`:
{{{
{-# RULES ^^^2/Integer forall x. x ^^^ (2 :: Integer) = x * x #-}
{-# SPECIALISE (^^^) :: Integer - Integer - Integer #-}
{-# NOINLINE (^^^) #-}
(^^^) :: (Num a, Integral b) = a - b - a
x ^^^ y = 1
v :: Integer
v = 8 ^^^ 2
main :: IO ()
main = print v
}}}
we get the specialisation matching and not the rule, and thus the result
is 1 rather than 64:
{{{
$ ghc -O -ddump-rule-firings q.hs
[1 of 1] Compiling Main ( q.hs, q.o )
Rule fired: Class op fromInteger
Rule fired: SPEC Main.^^^
Rule fired: Class op show
Linking q ...
$ ./q
1
}}}
If we comment out the specialisation then we get the desired:
{{{
$ ghc -O -ddump-rule-firings q.hs
[1 of 1] Compiling Main ( q.hs, q.o )
Rule fired: ^^^2/Integer
Rule fired: Class op *
Rule fired: timesInteger
Rule fired: Class op show
Linking q ...
$ ./q
64
}}}
(as a sidenote, I think the rule should be
{{{
{-# RULES ^^^2/Integer forall x. x ^^^ (2 :: Integer) = let v = x in v *
v #-}
}}}
in case x is a large expression)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5237#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] #5484: HEAD build fails with ghc-7.2.1
#5484: HEAD build fails with ghc-7.2.1 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: highest|Milestone: 7.4.1 Component: Build System | Version: 7.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Building GHC failed --+- Changes (by tibbe): * cc: johan.tibell@… (added) Comment: Broken on Mac OS X 10.7 as well. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5484#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] #5518: Some unicode symbols are not allow in literal characters or strings
#5518: Some unicode symbols are not allow in literal characters or strings
---+
Reporter: ertai |Owner:
Type: bug | Status: infoneeded
Priority: normal |Milestone:
Component: Compiler| Version: 7.2.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
---+
Changes (by igloo):
* status: new = infoneeded
Comment:
It works for me:
{{{
$ hexdump -C q.hs
0a 6d 61 69 6e 20 3d 20 70 75 74 43 68 61 72 20 |.main =
putChar |
0010 27 e2 82 96 27 0a 0a |'...'..|
0017
$ ghc -c q.hs
$
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5518#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] #5237: Inefficient code generated for x^2
#5237: Inefficient code generated for x^2
--+-
Reporter: scpmw| Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.4.1
Component: libraries/base |Version: 7.0.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Linux
Blocking: | Architecture: x86_64 (amd64)
Failure: Runtime performance bug |
--+-
Comment(by daniel.is.fischer):
Yes. And with
{{{
{-# RULES ^^^2/Bothforall (x :: Integer). x ^^^ (2 :: Integer) = x
#-}
}}}
alongside the two others, that fires.
Re sidenote: yes, it should be for safety. That occurred to me today too.
I've done a few tests and so far GHC always was clever enough to share the
expression, but it's better not to rely on it.
With regard to the rule/specialisation competition, what if the `{-#
SPECIALISE #-}` pragma is removed? Due to the `{-# INLINABLE #-}`, with
optimisations, specialisations will (probably) be created at the call
sites, won't they? So then we wouldn't need the extra rules. However, I
think that the specialisations would be created in each module and not
once per programme/package, and that would mean code-bloat. So what would
be worse, more rules or the code-bloat?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5237#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5509: quotes pretty-printer not working as comments specify
#5509: quotes pretty-printer not working as comments specify +--- Reporter: mgsloan1 | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.2.1 Resolution: fixed | Keywords: prettyprint Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | +--- Comment(by mgsloan1): -- 'quotes' encloses something in single quotes... hehe, 'nice'. Thanks for the quick fix! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5509#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] #5507: Template Haskell needs extra library dirs
#5507: Template Haskell needs extra library dirs ---+ Reporter: jwlato |Owner: igloo Type: bug | Status: new Priority: normal |Milestone: Component: Template Haskell| Version: 7.2.1 Keywords: template haskell, link | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Compile-time crash ---+ Changes (by igloo): * owner: = igloo * os: Unknown/Multiple = MacOS X Comment: Works for me on Linux. I'll try on OS X. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5507#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] #5430: System.Time.formatCalendarTime: %j starts at 0 whereas strftime's %j starts at 1
#5430: System.Time.formatCalendarTime: %j starts at 0 whereas strftime's %j starts at 1 +--- Reporter: guest|Owner: igloo Type: bug | Status: new Priority: normal |Milestone: Component: libraries/haskell98 | Version: 6.12.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux| Blocking: Architecture: x86 | Failure: Documentation bug +--- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5430#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] #5523: Mistake in error messages for importing infix constructors
#5523: Mistake in error messages for importing infix constructors
-+--
Reporter: ivanm | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.0.4 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
With the following import statement:
{{{
import Data.Sequence((:))
}}}
GHC provides the error:
{{{
test.hs:1:22:
In module `Data.Sequence':
`:' is a data constructor of `ViewL'
To import it use
`import Data.Sequence (ViewL (:))'
or
`import Data.Sequence (ViewL (..))'
Failed, modules loaded: none.
}}}
However, that first fix isn't correct: it ''should'' be:
{{{
import Data.Sequence(ViewL((:)))
}}}
(which is a bit of a mouthful :p).
I don't have access to 7.2.1, so I'm not sure if this error still exists.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5523
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] #5373: -rtsopts is not respected with -dynamic on Windows
#5373: -rtsopts is not respected with -dynamic on Windows -+-- Reporter: simonmar |Owner: Type: bug | Status: new Priority: high |Milestone: 7.4.1 Component: Compiler | Version: 7.0.4 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by btutt): * cc: bill@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5373#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: Bug#639015: [Pkg-haskell-maintainers] libffi soname change upcoming
On 27/08/2011 13:04, Joachim Breitner wrote: Hi Simon, Am Donnerstag, den 25.08.2011, 10:58 +0100 schrieb Simon Marlow: On 24/08/2011 13:12, Joachim Breitner wrote: Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose: The question that has to be answered first is: Assume the libraries do not depend on libffi themselves, and only ghc does. Now you update libffi and ghc gets rebuilds, what will happen: A) The haskell ABIs stay the same, the existing library packages can still be used. Great. B) The haskell ABIs change. We’ll have to binNMU all Haskell libraries, but oh well, not bad thanks to BD-Uninstallable-support in wanna-build and autosigning. C) The haskell ABIs do not change, but the old library builds are broken nevertheless. Big mess. Hard to recover from, because builds are not ordered automatically any more. Needs lots of NMUes and Dep-Waits. sorry, I don't get the `C' case. why should these be broken by a libffi or libgmp change? Maybe it’s an unrealistic example, but I could imagine that ghc some data type (size) defined by libffi is used when generating code for a haskell library under the assumption that it has the same structure/size in the run time system and/or other used haskell libraries. But instead of making blind guesses, maybe GHC upstream can enlighten us: Is it safe to build ghc and a Haskell library, then upgrade libffi to a new version (with soname bump), rebuild ghc, but use the previous library build? So there might be difficulties because we build static libraries. E.g. the RTS would have been built against the previous libffi, but would then be linked against the new one, which might be ABI-incompatible. Shared libraries would notice the upgrade and use the old ABI, but static libraries won't. How is this supposed to work, incidentally? I just checked the Drepper document about shared libraries and he doesn't seem to mention this problem. How do other packages with static libraries deal with this? In Debian, we only build Haskell libraries still exclusively statically. I’m not sure if I got your conclusion: Do you expect problems if the RTS and libraries were built against different versions of libffi, or not? Sorry for the delay, just going through my inbox and I think I missed your message before. To answer your question: yes I would expect problems. My question was: how do other (non-Haskell) packages on Debian that contain static libraries deal with this problem? We should follow whatever approach is used by others. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Segfault while building GHC HEAD on Mac OS X 10.7/XCode 4.1
The build fails with a segfault when building HEAD using GHC 7.2, OS X 10.7, and XCode 4.1 Any ideas? tibbe@redwood:ghc (master)$ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/ghc-stage1 -H64m -O -fasm-package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O -dcore-lint -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Debug.hs -o libraries/ghc-prim/dist-install/build/GHC/Debug.o make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Debug.o] Segmentation fault: 11 make: *** [all] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segfault while building GHC HEAD on Mac OS X 10.7/XCode 4.1
There's a ticket for this problem, but it doesn't look like any progress has been made so far: http://hackage.haskell.org/trac/ghc/ticket/5484 From the ticket, it seems like a platform-independent problem with building HEAD using ghc-7.2.1. Best, -Judah On Thu, Sep 29, 2011 at 3:35 PM, Johan Tibell johan.tib...@gmail.com wrote: The build fails with a segfault when building HEAD using GHC 7.2, OS X 10.7, and XCode 4.1 Any ideas? tibbe@redwood:ghc (master)$ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/ghc-stage1 -H64m -O -fasm -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O -dcore-lint -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Debug.hs -o libraries/ghc-prim/dist-install/build/GHC/Debug.o make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Debug.o] Segmentation fault: 11 make: *** [all] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] getting started
i have hugs i am installing haskell-platform when i run in hugs using :load it does nothing -- View this message in context: http://haskell.1045720.n5.nabble.com/getting-started-tp4848583p4852361.html Sent from the Haskell - Haskell mailing list archive at Nabble.com. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] getting started
On 29 September 2011 19:14, haskell shubhammaheshwa...@gmail.com wrote: i have hugs i am installing haskell-platform when i run in hugs using :load it does nothing Just loading a file doesn't do anything, you have to give it a command to do. Run main or something inside hugs. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] getting started
yes it works i have to send an email to beggin...@haskell.com -- View this message in context: http://haskell.1045720.n5.nabble.com/getting-started-tp4848583p4852537.html Sent from the Haskell - Haskell mailing list archive at Nabble.com. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] getting started
...and later after you got past the basics and you get to monads, if you have problems understanding them, you should try this tutorial which is a pretty good lecture http://mvanier.livejournal.com/3917.html On Thu, Sep 29, 2011 at 1:23 PM, haskell shubhammaheshwa...@gmail.com wrote: yes it works i have to send an email to beggin...@haskell.com -- View this message in context: http://haskell.1045720.n5.nabble.com/getting-started-tp4848583p4852537.html Sent from the Haskell - Haskell mailing list archive at Nabble.com. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] getting started
thanks for the links -- View this message in context: http://haskell.1045720.n5.nabble.com/getting-started-tp4848583p4852954.html Sent from the Haskell - Haskell mailing list archive at Nabble.com. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] network 2.3.05 on windows 7 with ghc-7.2.1
Hi, If someone here managed to build network 2.3.05 on windows 7 with ghc-7.2.1 , could you kindly pass me the trick? The config step fails with missing header. I tried running it with mingw (tried with the latest one too - just in case : http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/ ) I did not face any issue for the same thing on linux. Many thanks, Hemanth K I have done exactly this with the same versions. No problems. I used the MINGW that comes with ghc-7.2.1. I probably executed the configure under MSYS though, which probably makes the difference. Rene. _ Thanks! Your approach worked perfectly. All I had to do was to ensure that the msys uses ghc's mingw to configure and build successfully. thank you regards, Hemanth K ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network 2.3.05 on windows 7 with ghc-7.2.1
Hi everybody, this evening (29th of September) there will be a meeting of people interested in Haskell or functional programming in general in Munich at Cafe Puck: http://www.cafepuck.de/ The meeting will start at 19h30 (german time). Sorry for being late with this announcement. Nevertheless, please feel free to join us. Have a nice day, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Munich Haskell Meeting Tonight
Sorry for the bad subject... Here comes my announcement again: Hi everybody, this evening (29th of September) there will be a meeting of people interested in Haskell or functional programming in general in Munich at Cafe Puck: http://www.cafepuck.de/ The meeting will start at 19h30 (german time). Sorry for being late with this announcement. Nevertheless, please feel free to join us. Have a nice day, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Munich Haskell Meeting Tonight
Eh, I was in munich last month for a week. If you announce future meetings here I might make it up there. It's a ~4 hour trip. Ciao! 2011/9/29 Dr. Heinrich Hördegen hoerde...@funktional.info: Sorry for the bad subject... Here comes my announcement again: Hi everybody, this evening (29th of September) there will be a meeting of people interested in Haskell or functional programming in general in Munich at Cafe Puck: http://www.cafepuck.de/ The meeting will start at 19h30 (german time). Sorry for being late with this announcement. Nevertheless, please feel free to join us. Have a nice day, Heinrich ___ 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] Turn GC off
To me this sounds like a problem where Erlang might be a better choice. On Wed, Sep 28, 2011 at 4:04 PM, Andreas Voellmy andreas.voel...@gmail.com wrote: On Sat, Sep 17, 2011 at 1:38 AM, Jesse Schalken jesseschal...@gmail.com wrote: There might be a way to do it, I don't know, but this sounds like an XY problem. Can I ask what you're trying to achieve by doing this, or is it just out of curiosity regarding how much garbage is created? (It's a lot, by the way. Since the only thing a purely functional program can do is create data and read data (as opposed to create, read and update in an impure program) I imagine a purely functional program without GC would hit OOM very, very quickly.) Sure. I'm writing a server that serves a number of long-lived TCP connections. The clients can be served mostly independently; there is a bit of shared state among the different connections. I'd like to use the concurrency available to scale the server to handle a large number of clients. Ideally I would just use more cores to handle a larger number of clients. It seems that GC is the biggest obstacle to doing this. The problem seems to be that the current GC stops all the processors before performing a GC. With a large number of processors this becomes expensive, and I find that a program that has really high mutator productivity with one processor can get terrible productivity at 12 or more processors. Of course, it helps to reduce the allocation rate of the program, but even after being very careful about how much memory is allocated, GC still takes up a significant amount of time. So I was looking for a way to turn off GC altogether just as an experiment to see how the program would perform without all the GC pauses. --Andreas On Thu, Sep 15, 2011 at 2:42 AM, Andreas Voellmy andreas.voel...@gmail.com wrote: Hi everyone, Is there a way to completely turn garbage collection off in the Haskell runtime system? I'm aware of the -A runtime option, but I'd like to completely turn it off, if possible. I'm OK with running the program until it runs out of memory, and I'm willing to recompile GHC if needed. Regards, Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LLVM: function pointer in global struct
Hi everyone,
Using the LLVM bindings, I'm trying to create an initialized global
struct variable containing a pointer to a function.
{-# LANGUAGE ScopedTypeVariables #-}
import LLVM.Core
import Data.Word
import LLVM.Util.File(writeCodeGenModule)
sm_module = do
tick :: Function (Word32 - IO Word32) - createFunction
ExternalLinkage $ \x - ret x
info - createNamedGlobal False ExternalLinkage sm_info $
constStruct (tick ())
return info
I run into a complaint that this pointer isn't constant when it's part
of a global variable initializer.
No instance for (llvm-0.10.0.1:LLVM.Core.CodeGen.IsConstStruct
(Function (Word32 - IO Word32) : ()) a0)
arising from a use of `constStruct'
Possible fix:
add an instance declaration for
(llvm-0.10.0.1:LLVM.Core.CodeGen.IsConstStruct
(Function (Word32 - IO Word32) : ()) a0)
In the second argument of `($)', namely `constStruct (tick ())'
In a stmt of a 'do' expression:
info - createNamedGlobal False ExternalLinkage sm_info
$ constStruct (tick ())
In a stmt of a 'do' expression:
tick :: Function (Word32 - IO Word32) - createFunction
ExternalLinkage
$ \ x - ret x
I suppose this is because of
-- |A function is simply a pointer to the function.
type Function a = Value (Ptr a)
being a Value instead of ConstValue. Is there a way around this?
Cheers
Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: GA-1.0, a library for working with genetic algorithms
Hello, I'm proud to announce the v1.0 release of GA [1], my library for working with genetic algorithms in Haskell. Source repo is available on github. [2] This is a major version bump compared to the previous v0.2 release, because the library is pretty mature now in my view. Major features: * flexible user-friendly API for working with genetic algorithms * Entity type class to let user define entity definition, scoring, etc. * abstraction over monad, resulting in a powerful yet simple interface * support for scoring entire population at once * support for checkpointing each generation, and restoring from last checkpoint * convergence detection, as defined by user * also available: random searching, user-defined progress output * illustrative toy examples included I'm happy to take any questions or suggestions that you might have. [1] http://hackage.haskell.org/package/GA [2] https://github.com/boegel/GA ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HackageDB User Account
Hi Jonathan, On 21 Sep 2011, at 22:41, Jonathan Frywater wrote: How does one go about getting an account? I sent an email to the address provided at http://hackage.haskell.org/packages/accounts.html but haven't received any response yet. Since it's been over 3 weeks, I decided to try my luck here. Ross is usually quite responsive. Try resending him your email, maybe he missed it for some reason. I got a password reset for Hackage a couple of weeks ago in a matter of hours. Kenneth___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
On Wed, Sep 28, 2011 at 6:04 AM, Andreas Voellmy andreas.voel...@gmail.comwrote: Sure. I'm writing a server that serves a number of long-lived TCP connections. How many are you looking at? (ROFLSCALEhttp://www.youtube.com/watch?v=majbJoD6fzo?) And how much activity? Do you need real-time responses? It seems that GC is the biggest obstacle to doing this. The problem seems to be that the current GC stops all the processors before performing a GC. Each OS thread gets its own bump-pointer nursery; minor collections of this nursery do not result in whole system pauses. This should be small enough to fit into a Core's cache (the default 512 kB is usually okay) so we can keep the entire nursery in cache while GC'ing it, keeping its cost close to that of stack. However, if you add an external pointer to large data or thunks in the nursery - e.g. by mutating a shared IORef - you can undermine the benefits of the nursery. It might be worth trying to do more work without mutations, and try to force evaluation of data before writing it to a variable. The idea is to keep the nursery busy so that the second-generation collectors don't need to be. Controlling memory is also important. Use iteratees to help make guarantees about memory consumption. Ideally, you can keep each TCP connection under some fixed live space cost - e.g. 2-4 MB. This keeps GCs small and cheap, and also allows the entire thread to fit into the CPU's larger caches, thus reducing scheduling and evaluation costs. Indeed, controlling memory is the most important thing you should do to reduce GC costs and improve performance. GC only touches live memory. Avoiding allocations is much less important than controlling amount of live memory. Regards, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal rebuilding of the C++ code for wxHaskell
Hi all, I've been trying to resolve a compile time issue[1] with
wxHaskell, and I thought I'd throw it open to see if anyone on cafe
can help.
Here's the crux of the issue:
The Setup.hs for wxcore (the major component of wxHaskell) uses
simpleUserHooks, overriding only confHook.
However there is also cleanHook, which is defined by simpleUserHooks to be:
cleanHook = \p _ _ f - clean p f,
If you consult the source for clean[2] you'll see that it tries to
remove the whole dist/ directory rather than tracking exactly what
files we created in there. I presume that's why we have to do a full
re-build every time?
To try and circumvent this I modified the definition of main in
Setup.hs to this:
main = defaultMainWithHooks simpleUserHooks { confHook = myConfHook,
cleanHook = (\_ _ _ _ - return ())}
Unfortunately it still seems to re-build all the C++ on each 'install'
from cabal.
Not sure why?
Dave,
[1] http://sourceforge.net/mailarchive/message.php?msg_id=2807
[2] Taken from
http://www.haskell.org/ghc/docs/6.10.4/html/libraries/Cabal/src/Distribution-Simple.html#simpleUserHooks
-- Cleaning
clean :: PackageDescription - CleanFlags - IO ()
clean pkg_descr flags = do
let distPref = fromFlag $ cleanDistPref flags
notice verbosity cleaning...
maybeConfig - if fromFlag (cleanSaveConf flags)
then maybeGetPersistBuildConfig distPref
else return Nothing
-- remove the whole dist/ directory rather than tracking exactly what files
-- we created in there.
chattyTry removing dist/ $ do
exists - doesDirectoryExist distPref
when exists (removeDirectoryRecursive distPref)
-- these live in the top level dir so must be removed separately
removeRegScripts
-- Any extra files the user wants to remove
mapM_ removeFileOrDirectory (extraTmpFiles pkg_descr)
-- If the user wanted to save the config, write it back
maybe (return ()) (writePersistBuildConfig distPref) maybeConfig
where
removeFileOrDirectory :: FilePath - IO ()
removeFileOrDirectory fname = do
isDir - doesDirectoryExist fname
isFile - doesFileExist fname
if isDir then removeDirectoryRecursive fname
else if isFile then removeFile fname
else return ()
verbosity = fromFlag (cleanVerbosity flags)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Programming with arrows, exercises
Hello. I am reading Programming with Arrows by John Hughes (very helpful and interesting!), the book has an exercises requiring a module called Circuits for checking the answer. There should be things like class ArrowCircuit and various functions related to digital logic circuits simulation. Does anybody know where can I find one? Thanks, Sergey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell i18n best practices
Hello list. I've been trying to figure a nice method to provide localisation. An application is deployed using a conventional installer. The end-user is not required to have the Haskell runtimes, compiler or platform. The application should bundle ready to use translation data. What I am after is simple; an intuitive way that an interested translator, with little knowledge of Haskell, can look at and create valid translation data. This is what I've been looking at lately. The first thing I noticed was the GNU gettext implementation for Haskell. The wiki page [1] has a nice explanation by Aufheben. The hgettext package is found here [2]. I don't know if this is a bad habit, but I had already separated the dialogue text in the code with variables holding the respective strings. At this time, I thought there could be some other way than gettext. Then I figured how to import localisation data, that the program loads, from external files. The data type is basically a tuple with variable-names associated with strings. This is bit like the file-embed package [3]. Still uncomfortable with i18n, I learned about the article I18N in Haskell in yesod blog [4]. I'd like to hear more about it. What is considered the best practice for localisation? -- [1] http://www.haskell.org/haskellwiki/Internationalization_of_Haskell_programs [2] http://hackage.haskell.org/packages/archive/hgettext/ [3] http://hackage.haskell.org/package/file-embed [4] http://www.yesodweb.com/blog/2011/01/i18n-in-haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
Hi all, I've been trying to resolve a compile time issue[1] with
wxHaskell, and I thought I'd throw it open to see if anyone on cafe
can help.
Here's the crux of the issue:
The Setup.hs for wxcore (the major component of wxHaskell) uses
simpleUserHooks, overriding only confHook.
However there is also cleanHook, which is defined by simpleUserHooks to
be:
cleanHook = \p _ _ f - clean p f,
If you consult the source for clean[2] you'll see that it tries to
remove the whole dist/ directory rather than tracking exactly what
files we created in there. I presume that's why we have to do a full
re-build every time?
To try and circumvent this I modified the definition of main in
Setup.hs to this:
main = defaultMainWithHooks simpleUserHooks { confHook = myConfHook,
cleanHook = (\_ _ _ _ - return ())}
Unfortunately it still seems to re-build all the C++ on each 'install'
from cabal.
Not sure why?
Dave,
[1] http://sourceforge.net/mailarchive/message.php?msg_id=2807
[2] Taken from
http://www.haskell.org/ghc/docs/6.10.4/html/libraries/Cabal/src/Distribution-Simple.html#simpleUserHooks
-- Cleaning
clean :: PackageDescription - CleanFlags - IO ()
clean pkg_descr flags = do
let distPref = fromFlag $ cleanDistPref flags
notice verbosity cleaning...
maybeConfig - if fromFlag (cleanSaveConf flags)
then maybeGetPersistBuildConfig distPref
else return Nothing
-- remove the whole dist/ directory rather than tracking exactly what
files
-- we created in there.
chattyTry removing dist/ $ do
exists - doesDirectoryExist distPref
when exists (removeDirectoryRecursive distPref)
-- these live in the top level dir so must be removed separately
removeRegScripts
-- Any extra files the user wants to remove
mapM_ removeFileOrDirectory (extraTmpFiles pkg_descr)
-- If the user wanted to save the config, write it back
maybe (return ()) (writePersistBuildConfig distPref) maybeConfig
where
removeFileOrDirectory :: FilePath - IO ()
removeFileOrDirectory fname = do
isDir - doesDirectoryExist fname
isFile - doesFileExist fname
if isDir then removeDirectoryRecursive fname
else if isFile then removeFile fname
else return ()
verbosity = fromFlag (cleanVerbosity flags)___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
On Thu, Sep 29, 2011 at 7:15 PM, DukeDave duked...@gmail.com wrote: Hi all, I've been trying to resolve a compile time issue[1] with wxHaskell, and I thought I'd throw it open to see if anyone on cafe can help. Here's the crux of the issue: The Setup.hs for wxcore (the major component of wxHaskell) uses simpleUserHooks, overriding only confHook. However there is also cleanHook, which is defined by simpleUserHooks to be: cleanHook = \p _ _ f - clean p f, If you consult the source for clean[2] you'll see that it tries to remove the whole dist/ directory rather than tracking exactly what files we created in there. I presume that's why we have to do a full re-build every time? To try and circumvent this I modified the definition of main in Setup.hs to this: Why do you want to change the behavior of the 'clean' hook? Most users would expect it to clear out everything that 'configure', 'build' and such have done. I would be cautious about subverting user expectations like that. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: GA-1.0, a library for working with genetic algorithms
This is neat - thanks for putting in the time and effort (and
releasing the work to Hackage). A few questions:
* What GA-nerdy things does this do under the hood (I haven't looked
at the source)? It looks like it's a GA framework almost more than
the actual algorithm itself. I see crossover and mutation can be
defined by the user and understand there are limitations to what the
GA package can do (seeing as it is so polymorphic), but certainly it
could provide alternate fitness measures (adjusted, normalized,
standard), over-selection, elitism, automatically defined functions
(sometimes called encapsulation), and optimization (I think this is
referred to as editing by Koza).
* Have you considered using Binary or Serialize to make the
checkpointing? (I assume checkpointing is using the Show and Read
instances right now)
* Have you considered alternate random sources (Mersenne)? Perhaps
I'm being silly as most GAs are computationally dominated by the
fitness measurement.
* Is there a plan for parallel computations? Beyond what I can do
with scorePop?
* What does it mean if a score returns 'Nothing'?
On a related note, I've recently put some work into using the Typeable
and Dynamic modules to build a GA system in which the primitives could
hold heterogeneous types. I'll describe it below incase you are 1)
interested in doing it yourself, but actually completeing it (unlike
me) or 2) are already doing it so I won't be tempted to revisit the
work and duplicate effort. From the look of your package, this would
be just an special instance of your Entity class.
The basic idea was to allow the use of arbitrary Haskell types to be
lifted into a generic genetic algorithm:
{- BEGIN CODE -}
evolveSolution = do
let funcs = [mkPrim (:), mkPrim lookup, mkPrim delete, mkPrim
insert] ++ map mkPrim [0..100] ++ map mkPrim [(+),(*),(-)]
allFuncs = funcs ++ primsForContainersPackage -- my package
should have eventually provided such collections
fitness f = f 503 == 0
gaConf = mkGA funcs (mkPrim fitness) defaultConfig
in evolve gaConf
{- END CODE -}
In the system each individual is an operator and a list of arguments,
each contained in their own Dynamic type. All individuals include 1)
a mapping from type to sub-trees that are of that type and 2) a
mapping of types to functions that will construct the same individual
(that is: Map typ (typ - Individual)). The union of the domain of
these to mappings show what, if any, opportunities for crossover exist
between any two individuals.
The global configuration maintains all the primitives needed to
generate new individuals, which means sub-trees can also be generated
to allow mutation.
The main two issues that made me stop (read: I didn't recognize these
as the core issue till I'd already hacked around without thinking
about why what I'm doing wasn't quite right) were:
1) I didn't have a good way to dynamically safely coerce one type,
ty1, into another type, ty2. For example, when given t_1 - t_2 -
... - t_n - r and needed b_1 - b_2 - ... - b_m - r where m
n and there was a injective mapping between the b, t type variables I
still had bugs in the actual coercion.
A more concrete example of this point: given Int - Float - Float,
I wanted to coerce it into a function of type Float - Int - Float
or Float - Float or Int - Float. Usually my solution worked,
but I think a bug lingered (needs testing, which I don't have time
for now).
2) Generation of individuals in highly heterogenious configurations
was basically non-terminating without special effort. I was going to
make a routine to compute the minimum depth given any particular
primitive, then removed any primitive from consideration if the
minimum depth put me over the maximum depth for the individual.
So a bit long winded, but that was the effort in a nutshell. If
nothing else I hope it was entertaining. I'm sure it's doable but I
haven't the time of focus to do it properly, and won't for a while.
Cheers,
Thomas
On Thu, Sep 29, 2011 at 12:45 PM, Kenneth Hoste kenneth.ho...@gmail.com wrote:
Hello,
I'm proud to announce the v1.0 release of GA [1], my library for working with
genetic algorithms in Haskell.
Source repo is available on github. [2]
This is a major version bump compared to the previous v0.2 release, because
the library is pretty mature now in my view.
Major features:
* flexible user-friendly API for working with genetic algorithms
* Entity type class to let user define entity definition, scoring, etc.
* abstraction over monad, resulting in a powerful yet simple interface
* support for scoring entire population at once
* support for checkpointing each generation, and restoring from last
checkpoint
* convergence detection, as defined by user
* also available: random searching, user-defined progress output
* illustrative toy examples included
I'm happy to take any questions or suggestions that you might have.
[1]
Re: [Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
On Friday, 30 September 2011 01:42:00 UTC+1, Antoine Latter wrote: Why do you want to change the behavior of the 'clean' hook? Most users would expect it to clear out everything that 'configure', 'build' and such have done. I would be cautious about subverting user expectations like that. I'm only inquiring about changing the clean hook for this specific project, not cabal in general. And the reason I'm looking to change it is that building the C++ component takes a long time (over five minutes on my fairly average laptop), so cleaning everything every time is an extremely annoying inconvenience. My main questions are: 1. Is there some reason (other than 'safety') that cabal install cleans everything up? 2. Why does setting cleanHook to return () not have any effect? Thanks, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
On 30/09/11 02:45, DukeDave wrote: 1. Is there some reason (other than 'safety') that cabal install cleans everything up? As far as I've experienced and understand it, it doesn't - it's more that GHC can detect when Haskell modules don't need recompiling while the same is not true for C or C++ sources. For example, I change one module and see GHC report only that module and its dependents being recompiled, while the other compiled modules are reused from previous 'cabal install' runs. The C-sources: are recompiled every time even if unchanged, which I too find it somewhat annoying even with my small projects. 2. Why does setting cleanHook to return () not have any effect? I think becausae the clean hook is probably not called by 'cabal install', but by 'cabal clean'. Claude ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
On Thu, Sep 29, 2011 at 3:14 PM, David Barbour dmbarb...@gmail.com wrote: minor collections of this nursery do not result in whole system pauses. Yes, they do. GHC has a parallel garbage collector (so collection pauses the mutator threads, and collects garbage -in parallel- on multiple CPUs) but it in no way has a concurrent one. Every OS thread has its own young-gen heap space, and the old-generation heap space is shared amongst every CPU. But any young-gen GC will cause all mutator threads to pause no matter what the state of the others is. That said, Simon^2 has done research on this problem recently. They recently published a paper about 'local' garbage collection for individual OS threads, where every thread has its own, private nursery, that may be collected independently of all other CPUs, which promotes objects into the global heap when necessary for access from other threads. The design is reminiscent of older work on the same topic (thread-local heaps,) but adds a bunch of tasty work they did. You can find this branch of GHC with 'local heaps' here, in the local-gc branch of the git repository: https://github.com/ghc/ghc/tree/local-gc This new local collector branch is not, I repeat, not part of GHC and hasn't been merged. It's not certain if it ever will be, I think. The paper conclusion addresses the fact the scalability improvements as a result of this new collector are nowhere near as dramatic as they had hoped, and it's not certain the improvements they did get are worth the substantial complexity increase. It doesn't address the old-gen GC - any old-gen GCs still pause all mutator threads before continuing. They do note however that this local allocation strategy could be combined with a real concurrent/incremental GC for the old-generation, which would help control pause times more over the whole lifetime of an application. You can find all the juicy details in their paper Multicore garbage collection with thread local heaps, located near the top of Simon's webpage here: http://research.microsoft.com/en-us/people/simonpj/ -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
Thank you for the clarification. I had read those papers, but I was under the impression that it was something already part of GHC 7. Regards, Dave On Thu, Sep 29, 2011 at 8:45 PM, austin seipp a...@hacks.yi.org wrote: On Thu, Sep 29, 2011 at 3:14 PM, David Barbour dmbarb...@gmail.com wrote: minor collections of this nursery do not result in whole system pauses. Yes, they do. GHC has a parallel garbage collector (so collection pauses the mutator threads, and collects garbage -in parallel- on multiple CPUs) but it in no way has a concurrent one. Every OS thread has its own young-gen heap space, and the old-generation heap space is shared amongst every CPU. But any young-gen GC will cause all mutator threads to pause no matter what the state of the others is. That said, Simon^2 has done research on this problem recently. They recently published a paper about 'local' garbage collection for individual OS threads, where every thread has its own, private nursery, that may be collected independently of all other CPUs, which promotes objects into the global heap when necessary for access from other threads. The design is reminiscent of older work on the same topic (thread-local heaps,) but adds a bunch of tasty work they did. You can find this branch of GHC with 'local heaps' here, in the local-gc branch of the git repository: https://github.com/ghc/ghc/tree/local-gc This new local collector branch is not, I repeat, not part of GHC and hasn't been merged. It's not certain if it ever will be, I think. The paper conclusion addresses the fact the scalability improvements as a result of this new collector are nowhere near as dramatic as they had hoped, and it's not certain the improvements they did get are worth the substantial complexity increase. It doesn't address the old-gen GC - any old-gen GCs still pause all mutator threads before continuing. They do note however that this local allocation strategy could be combined with a real concurrent/incremental GC for the old-generation, which would help control pause times more over the whole lifetime of an application. You can find all the juicy details in their paper Multicore garbage collection with thread local heaps, located near the top of Simon's webpage here: http://research.microsoft.com/en-us/people/simonpj/ -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
