Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals

[GHC]

#5218: Add unpackCStringLen# to create Strings from string literals
-+--
Reporter:  tibbe |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  high  |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.0.3   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:|Testcase:  
   Blockedby:|Blocking:  
 Related:  5877  |  
-+--
Changes (by reinerp):

  * related:  => 5877


Comment:

 See also #5877

-- 
Ticket URL: 
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] #5877: Make StringPrimL take [Word8]

[GHC]

#5877: Make StringPrimL take [Word8]
--+-
 Reporter:  reinerp   |  Owner:  reinerp 
 Type:  feature request   | Status:  patch   
 Priority:  normal|  Component:  Template Haskell
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:  5218  |  
--+-
Changes (by reinerp):

  * owner:  => reinerp
  * related:  => 5218


-- 
Ticket URL: 
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] #5877: Make StringPrimL take [Word8]

[GHC]

#5877: Make StringPrimL take [Word8]
--+-
 Reporter:  reinerp   |  Owner:  
 Type:  feature request   | Status:  patch   
 Priority:  normal|  Component:  Template Haskell
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
Changes (by reinerp):

  * status:  new => patch


-- 
Ticket URL: 
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] #5877: Make StringPrimL take [Word8]

[GHC]

#5877: Make StringPrimL take [Word8]
--+-
 Reporter:  reinerp   |  Owner:  
 Type:  feature request   | Status:  new 
 Priority:  normal|  Component:  Template Haskell
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 This is a follow-up of
 [http://hackage.haskell.org/trac/ghc/ticket/5218#comment:12 PHO's comment]
 on #5218:


 
 What concerns me is that there seems no means of creating primitive byte-
 array literals with TH. That is, the  Lit type currently only has a
 constructor {{{StringPrimL String}}} which represents an {{{Addr#}}}
 literal encoded in UTF-8, thus {{{unsafePackAddressLen 3
 "\NUL\NUL\NUL"#}}} works but {{{unsafePackAddressLen 3 $(litE $
 StringPrimL "\NUL\NUL\NUL")}}} doesn't. So we probably need to make a
 change to the type of StringPrimL:

 {{{
 data Lit = CharL Char
  | StringL String
  | ...
  | StringPrimL [Word8] -- Raw, non-encoded "..."# literal.
 }}}

 

 I attach patches which implement this change.

-- 
Ticket URL: 
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] #2986: :info printing instances often isn't wanted

[GHC]

#2986: :info printing instances often isn't wanted
-+--
Reporter:  Remi  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  lowest|   Milestone:  7.6.1   
   Component:  GHCi  | Version:  6.10.1  
Keywords:  :info instances   |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by Remi):

 The reason I chose the minus-version is because it was the smallest
 version, and didn't change the default behaviour, but I personally prefer
 Simon's suggestion too, at least if :i keeps meaning :info...

-- 
Ticket URL: 
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] #5862: Need kind annotations

[GHC]

#5862: Need kind annotations
-+--
Reporter:  simonpj   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.4.1   
Keywords:  PolyKinds |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by kosmikus):

 * cc: andres@… (added)


Comment:

 My very first attempt with the new kind system additions also failed due
 to the lack of kind variable annotations. If needed, I can reconstruct the
 example(s). I'd certainly like them to be added. (Furthermore, I'd really
 like error messages to actually mention kinds rather than numbers of type
 arguments.)

-- 
Ticket URL: 
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] #5862: Need kind annotations

[GHC]

#5862: Need kind annotations
-+--
Reporter:  simonpj   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.4.1   
Keywords:  PolyKinds |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by goldfire):

 * cc: eir@… (added)
  * keywords:  => PolyKinds


Comment:

 I have attached KindFams.hs which shows another case of wanting explicit
 kind variables. I have more use cases if you want them...

-- 
Ticket URL: 
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] #5824: ARM StgRun register clobber list is broken

[GHC]

#5824: ARM StgRun register clobber list is broken
---+
Reporter:  bgamari |   Owner:  simonmar
Type:  bug |  Status:  patch   
Priority:  high|   Milestone:  7.4.2   
   Component:  Runtime System  | Version:  7.4.1-rc2   
Keywords:  |  Os:  Unknown/Multiple
Architecture:  arm | Failure:  None/Unknown
  Difficulty:  Unknown |Testcase:  
   Blockedby:  |Blocking:  
 Related:  |  
---+

Comment(by nomeata):

 Replying to [comment:26 kgardas]:
 > Simon, could you be so kind and apply two attached patches provided by
 me (kgardas)?

 Preferably also to the branch that becomes 7.4.2, to avoid avoidable
 patching in the distribution packages, if that is compatible with your
 release policy.

-- 
Ticket URL: 
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] #5824: ARM StgRun register clobber list is broken

[GHC]

#5824: ARM StgRun register clobber list is broken
---+
Reporter:  bgamari |   Owner:  simonmar
Type:  bug |  Status:  patch   
Priority:  high|   Milestone:  7.4.2   
   Component:  Runtime System  | Version:  7.4.1-rc2   
Keywords:  |  Os:  Unknown/Multiple
Architecture:  arm | Failure:  None/Unknown
  Difficulty:  Unknown |Testcase:  
   Blockedby:  |Blocking:  
 Related:  |  
---+

Comment(by kgardas):

 Simon, could you be so kind and apply two attached patches provided by me
 (kgardas)? It looks like, they are working for both Ubuntu and Debian
 folks. Thanks!

-- 
Ticket URL: 
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] #5824: ARM StgRun register clobber list is broken

[GHC]

#5824: ARM StgRun register clobber list is broken
---+
Reporter:  bgamari |   Owner:  simonmar
Type:  bug |  Status:  patch   
Priority:  high|   Milestone:  7.4.2   
   Component:  Runtime System  | Version:  7.4.1-rc2   
Keywords:  |  Os:  Unknown/Multiple
Architecture:  arm | Failure:  None/Unknown
  Difficulty:  Unknown |Testcase:  
   Blockedby:  |Blocking:  
 Related:  |  
---+

Comment(by nomeata):

 Ok, built worked fine, so from my side you can go ahead and apply the
 patch. Thanks!

-- 
Ticket URL: 
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] #5868: Wrong error messages with qualified imports

[GHC]

#5868: Wrong error messages with qualified imports
-+--
Reporter:  SimonHengel   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  _|_ 
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * difficulty:  => Unknown
  * milestone:  => _|_


Comment:

 Correct.

 By the time we get to the type checker, GHC has forgotten ''how'' the
 entity was referenced and has simply recorded ''what'' entity was
 referenced. In this case it knows that you are talking about "the `bar`
 defined in module `Bar`", but has forgotten what you called it.   Then
 when it prints the error message it tries to find some unambiguous name
 for it; hence the result.

 It isn't perfect I grant you.  One way to improve matters might be to
 change the `HsExpr` data type a bit, so instead of
 {{{
 data HsExpr id = HsVar id
 | ...
 }}}
 we have
 {{{
 data HsExpr id = HsVar id RdrName
 | ...
 }}}
 so that every `HsVar` remembers how it was originally specified.  That
 would catch 90% of the cases, but I worry about the others (eg qualified
 use of data constructors in patterns).  A more thorough solution might be
 to make the renamer produce `HsExpr (Name, RdrName)` rather than `HsExpr
 Name`.  But it's also pretty expensive.

 My gut feel is to let sleeping dogs lie unless more people pipe up that
 this is really painful.

 Simon

-- 
Ticket URL: 
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] #5757: zero unexpected failures on all tier 1 platforms

[GHC]

#5757: zero unexpected failures on all tier 1 platforms
-+--
Reporter:  simonmar  |   Owner:  
Type:  task  |  Status:  new 
Priority:  highest   |   Milestone:  7.4.2   
   Component:  Test Suite| Version:  7.2.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:  #5785 |  
-+--

Comment(by nomeata):

 Now most other Debian arches have build the testsuite
 (https://buildd.debian.org/status/package.php?p=ghc-testsuite), here are
 the results:

 [https://buildd.debian.org/status/fetch.php?pkg=ghc-testsuite&arch
 =kfreebsd-amd64&ver=7.4.1-3&stamp=1329221894 kfreebsd-amd64]:
 {{{
 OVERALL SUMMARY for test run started at Tue Feb 14 11:44:16 UTC 2012
 3036 total tests, which gave rise to
11974 test cases, of which
0 caused framework failures
 9215 were skipped

 2706 expected passes
   44 expected failures
0 unexpected passes
9 unexpected failures

 Unexpected failures:
cabalghcpkg01 [bad stderr] (normal)
codeGen/should_run   cgrun025 [exit code non-0] (normal)
deriving/should_run  T3087 [exit code non-0] (normal)
lib/Concurrent   QSemN001 [bad exit code] (normal)
lib/Regexregex003 [exit code non-0] (normal)
perf/compilerT3064 [stat not good enough] (normal)
rts  derefnull [bad stderr] (normal)
rts  divbyzero [bad stderr] (normal)
rts  exec_signals [bad stdout] (normal)
 }}}

 [https://buildd.debian.org/status/fetch.php?pkg=ghc-
 testsuite&arch=kfreebsd-i386&ver=7.4.1-3&stamp=1329218147 kfreebsd-i386]:
 {{{
 OVERALL SUMMARY for test run started at Tue Feb 14 09:30:59 UTC 2012
 3036 total tests, which gave rise to
11974 test cases, of which
0 caused framework failures
 9216 were skipped

 2707 expected passes
   43 expected failures
0 unexpected passes
8 unexpected failures

 Unexpected failures:
cabalghcpkg05 [bad stderr] (normal)
codeGen/should_run   cgrun025 [exit code non-0] (normal)
deriving/should_run  T3087 [exit code non-0] (normal)
lib/Concurrent   QSemN001 [bad exit code] (normal)
lib/Regexregex003 [exit code non-0] (normal)
rts  derefnull [bad stderr] (normal)
rts  divbyzero [bad stderr] (normal)
rts  exec_signals [bad stdout] (normal)
 }}}

 [https://buildd.debian.org/status/fetch.php?pkg=ghc-
 testsuite&arch=mips&ver=7.4.1-3&stamp=1329221065 mips]:
 {{{
 OVERALL SUMMARY for test run started at Tue Feb 14 09:42:34 UTC 2012
 3035 total tests, which gave rise to
 6890 test cases, of which
0 caused framework failures
 4479 were skipped

 2318 expected passes
   68 expected failures
1 unexpected passes
   24 unexpected failures

 Unexpected passes:
quasiquotation  T5204 (normal)

 Unexpected failures:
cabal/cabal04 cabal04 [bad exit code] (normal)
codeGen/should_runcgrun025 [exit code non-0] (normal)
deriving/should_run   T3087 [exit code non-0] (normal)
driver5313 [exit code non-0] (normal)
driver/recomp009  recomp009 [bad exit code] (normal)
ghc-api/dynCompileExprdynCompileExpr [exit code non-0] (normal)
ghci/linking  ghcilink001 [bad exit code] (normal)
ghci/linking  ghcilink002 [bad exit code] (normal)
ghci/linking  ghcilink003 [bad exit code] (normal)
ghci/linking  ghcilink004 [bad exit code] (normal)
ghci/linking  ghcilink005 [bad exit code] (normal)
ghci/linking  ghcilink006 [bad exit code] (normal)
lib/ConcurrentQSemN001 [bad exit code] (normal)
lib/Regex regex003 [exit code non-0] (normal)
perf/compiler T4801 [stat too good] (normal)
perf/should_run   3586 [exit code non-0] (normal)
perf/should_run   T3736 [bad stderr] (normal)
profiling/should_run  T5559 [bad heap profile] (profasm)
rts   4850 [bad exit code] (normal)
rts   T2615 [exit code non-0] (normal)
rts   T5423 [bad stderr] (normal)
safeHaskell/safeLanguage  SafeLang01 [stderr mismatch] (normal)
safeHaskell/safeLanguage  SafeLang12 [stderr mismatch] (normal)
safeHaskell/safeLanguage  SafeLang16 [stderr mismatch] (normal)
 }}}

 [https://buildd.debian.org/

Re: [GHC] #5620: Dynamic linking and threading does not work on Windows

[GHC]

#5620: Dynamic linking and threading does not work on Windows
---+
Reporter:  Lennart |   Owner:  igloo
Type:  bug |  Status:  new  
Priority:  high|   Milestone:  7.4.2
   Component:  Runtime System  | Version:  7.2.1
Keywords:  |  Os:  Windows  
Architecture:  x86 | Failure:  Runtime crash
  Difficulty:  Unknown |Testcase:   
   Blockedby:  |Blocking:   
 Related:  |  
---+

Comment(by rl):

 FWIW, 7.4.1 doesn't emit a warning here.

-- 
Ticket URL: 
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] #5876: Dynamically linked programs can't be run on Windows without significant effort (was: Dynamic libraries don't work on Windows)

[GHC]

#5876: Dynamically linked programs can't be run on Windows without significant
effort
+---
  Reporter:  rl |  Owner: 
  Type:  bug| Status:  new
  Priority:  normal |  Milestone: 
 Component:  Compiler   |Version:  7.4.1  
Resolution: |   Keywords: 
Os:  Windows|   Architecture:  x86
   Failure:  Runtime crash  | Difficulty:  Unknown
  Testcase: |  Blockedby: 
  Blocking: |Related: 
+---
Changes (by rl):

  * status:  closed => new
  * resolution:  duplicate =>


Comment:

 True, the segfault is, sorry about this. However, there still doesn't seem
 to be a sane way to actually run dynamically linked programs on Windows.
 This is a bug, IMO. I've renamed the ticket accordingly.

-- 
Ticket URL: 
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] #5876: Dynamic libraries don't work on Windows

[GHC]

#5876: Dynamic libraries don't work on Windows
+---
  Reporter:  rl |  Owner: 
  Type:  bug| Status:  closed 
  Priority:  normal |  Milestone: 
 Component:  Compiler   |Version:  7.4.1  
Resolution:  duplicate  |   Keywords: 
Os:  Windows|   Architecture:  x86
   Failure:  Runtime crash  | Difficulty:  Unknown
  Testcase: |  Blockedby: 
  Blocking: |Related: 
+---
Changes (by igloo):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => duplicate


Comment:

 Thanks for the report. This is a duplicate of #5620.

-- 
Ticket URL: 
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] #4139: Spurious non-exhaustive pattern match warnings are given using GADTs

[GHC]

#4139: Spurious non-exhaustive pattern match warnings are given using GADTs
+---
  Reporter:  blarsen|  Owner:   

  Type:  bug| Status:  new  

  Priority:  normal |  Milestone:  7.0.1

 Component:  Compiler   |Version:  7.4.1

Resolution: |   Keywords:  GADTs, 
warnings, pattern matching
Os:  Unknown/Multiple   |   Architecture:  
Unknown/Multiple 
   Failure:  Incorrect warning at compile-time  | Difficulty:  Unknown  

  Testcase: |  Blockedby:   

  Blocking: |Related:   

+---
Changes (by simonpj):

  * difficulty:  => Unknown


Comment:

 Good example.  It has the same cause as #3927. Sorry no imminent cure.
 Needs someone to pay proper attention to it.

-- 
Ticket URL: 
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] #5876: Dynamic libraries don't work on Windows

[GHC]

#5876: Dynamic libraries don't work on Windows
---+
 Reporter:  rl |  Owner:  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Compiler
  Version:  7.4.1  |   Keywords:  
   Os:  Windows|   Architecture:  x86 
  Failure:  Runtime crash  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+
 I tried to compile hello-world with -dynamic and -threaded on Windows:

 {{{
 ghc -o tst.exe Tst.hs -dynamic -threaded
 ./tst.exe
 }}}

 This fails both on cygwin and on mingw: the former can't find
 `libHSbase-4.5.0.0-ghc7.4.1.dll` and the latter `libHSrts_thr-
 ghc7.4.1.dll`. The only solution to this seems to be to find and copy all
 DLLs from the GHC distribution to a separate directory and to make sure
 that this directory is on the search path. If I install packages, I have
 to find and copy those DLLs, too. This makes working with dynamically
 linked programs rather harder than it should be.

 After doing that, hello world segfaults if I compile with -threaded. It
 seems to work without -threaded, but that isn't useful for us.

-- 
Ticket URL: 
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] #2986: :info printing instances often isn't wanted

[GHC]

#2986: :info printing instances often isn't wanted
-+--
Reporter:  Remi  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  lowest|   Milestone:  7.6.1   
   Component:  GHCi  | Version:  6.10.1  
Keywords:  :info instances   |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by spl):

 I like that even better, Simon, though I would use {{{:instances}}} and
 keep {{{:i}}} as the shortcut for {{{:info}}} as was mentioned in previous
 comments. It appears that you care the most about the UI here and nobody
 is really in disagreement, so I think you should use whatever you find
 appropriate.

-- 
Ticket URL: 
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] #2986: :info printing instances often isn't wanted

[GHC]

#2986: :info printing instances often isn't wanted
-+--
Reporter:  Remi  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  lowest|   Milestone:  7.6.1   
   Component:  GHCi  | Version:  6.10.1  
Keywords:  :info instances   |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 UI suggestion.  I suggest that
  * `:info C` never mentions instances of C
  * `:instance C` describes all instances involving C

 There's also a current bug which is that we don't currently report type-
 family instance at all.

 I personally dislike the "-" syntax; very un-discoverable.

 Simon

-- 
Ticket URL: 
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] #5550: GHC infinite loop when compiling vector

[GHC]

#5550: GHC infinite loop when compiling vector
-+--
Reporter:  simonpj   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  low   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.2.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:|Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by liyang):

 * cc: hackage.haskell.org@… (added)


-- 
Ticket URL: 
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] #5534: ghci -fobject-code strangeness

[GHC]

#5534: ghci -fobject-code strangeness
-+--
Reporter:  simonmar  |   Owner:  simonmar
Type:  bug   |  Status:  new 
Priority:  high  |   Milestone:  7.4.2   
   Component:  GHCi  | Version:  7.2.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonmar):

  * owner:  => simonmar
  * difficulty:  => Unknown
  * priority:  low => high
  * milestone:  7.6.1 => 7.4.2


-- 
Ticket URL: 
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] #5143: Soft heap limit flag

[GHC]

#5143: Soft heap limit flag
-+--
Reporter:  simonmar  |   Owner:  simonmar
Type:  task  |  Status:  new 
Priority:  normal|   Milestone:  7.6.1   
   Component:  Runtime System| Version:  7.0.3   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonmar):

  * priority:  low => normal
  * difficulty:  => Unknown


Comment:

 Back to normal - we do want this, or something like it.

-- 
Ticket URL: 
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] #2437: More accurate package dependencies

[GHC]

#2437: More accurate package dependencies
--+-
 Reporter:  simonmar  |   Type:  task  
   Status:  new   |   Priority:  lowest
Milestone:  7.6.1 |  Component:  Package system
  Version:  6.8.3 |   Keywords:
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple  
  Failure:  None/Unknown  | Difficulty:  Moderate (less than a day)
 Testcase:|  Blockedby:
 Blocking:|Related:
--+-
Changes (by simonmar):

  * failure:  => None/Unknown


Comment:

 I tried to implement the suggestion from #3560, thinking it would be easy,
 but there are two reasons we link in packages eagerly when they are
 mentioned on the command line:

  * So that you can link in extra object files or libraries that depend on
 the packages.  e.g. `ghc -package foo -lbar` where `bar` is a C library
 that depends on something in `foo`.  So we could link in `foo` eagerly if
 and only if there are extra C libs or objects to link in, but

  * Haskell code can depend on a C function exported by a package, and the
 normal dependency tracking that TH uses can't know about these
 dependencies.  The test `ghcilink004` relies on this, for example.

 I conclude that we need two `-package` flags: one that says "this is a
 package I want to make available", and one that says "this is a package I
 want to link in eagerly".  Would that be too complicated for users?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs