Re: [GHC] #2050: GHCi should keep a persistent history file

[GHC]

#2050: GHCi should keep a persistent history file
+---
Reporter:  ajd  |Owner:  ajd
Type:  feature request  |   Status:  new
Priority:  normal   |Milestone: 
   Component:  GHCi |  Version:  6.8.2  
Severity:  normal   |   Resolution: 
Keywords:   | Testcase: 
Architecture:  Unknown  |   Os:  Unknown
+---
Changes (by ajd):

  * owner:  => ajd

Comment:

 I think System.Posix.Readline already has a binding to those functions via
 the addHistory function. I just finished writing a simple implementation;
 I'll post a patch when it builds and tests.

-- 
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] #2050: GHCi should keep a persistent history file

[GHC]

#2050: GHCi should keep a persistent history file
+---
Reporter:  ajd  |Owner: 
Type:  feature request  |   Status:  new
Priority:  normal   |Milestone: 
   Component:  GHCi |  Version:  6.8.2  
Severity:  normal   |   Resolution: 
Keywords:   | Testcase: 
Architecture:  Unknown  |   Os:  Unknown
+---
Comment (by judah):

 I have also often wished for this.  The header ``
 provides the functions `read_history` and `write_history` which are also
 present in editline.  This task will be easy to implement if we add those
 to the readline and editline packages.  (Although, a pure Haskell
 implementation would probably also be pretty easy to write.)

-- 
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] #2050: GHCi should keep a persistent history file

[GHC]

#2050: GHCi should keep a persistent history file
+---
Reporter:  ajd  |Owner: 
Type:  feature request  |   Status:  new
Priority:  normal   |Milestone: 
   Component:  GHCi |  Version:  6.8.2  
Severity:  normal   |   Resolution: 
Keywords:   | Testcase: 
Architecture:  Unknown  |   Os:  Unknown
+---
Changes (by Isaac Dupree):

 * cc: [EMAIL PROTECTED] (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

[GHC] #2050: GHCi should keep a persistent history file

[GHC]

#2050: GHCi should keep a persistent history file
+---
Reporter:  ajd  |   Owner: 
Type:  feature request  |  Status:  new
Priority:  normal   |   Component:  GHCi   
 Version:  6.8.2|Severity:  normal 
Keywords:   |Testcase: 
Architecture:  Unknown  |  Os:  Unknown
+---
 It would be nice if GHCi kept a persistent history of commands like bash
 does. This would be especially useful in testing: if one is trying to get
 a certain command to work, and the command is at all complicated, it is
 annoying to have to copy and paste or retype the command every time you
 want to see if the function works.

-- 
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] #2049: GHCi doesn't fully load previously broken modules

[GHC]

#2049: GHCi doesn't fully load previously broken modules
+---
Reporter:  ajd  |   Owner: 
Type:  bug  |  Status:  new
Priority:  normal   |   Component:  GHCi   
 Version:  6.8.2|Severity:  normal 
Keywords:   |Testcase: 
Architecture:  Unknown  |  Os:  Unknown
+---
 Scenario:

 I have a project with three modules: Mod1, Mod2 and Mod3. Mod3 calls an
 undefined function and so shouldn't load. I call GHCi as

 ghci Mod3.hs

 The output looks like this:

  GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
  Loading package base ... linking ... done.
  [1 of 3] Compiling Mod1 ( Mod1.hs, interpreted )
  [2 of 3] Compiling Mod2 ( Mod2.hs, interpreted )
  [3 of 3] Compiling Mod3 ( Mod3.hs, interpreted )

  Mod3.hs:6:6: Not in scope: `foo'

  Mod3.hs:6:12: Not in scope: `barf'
  Failed, modules loaded: Mod2, Mod1.

 The problem comes when I edit the file using GHCi's :e command and then
 reload with :r. The output looks like this (which is strange in itself,
 because the modules are listed in the wrong order):

  *Mod2> :r
  [3 of 3] Compiling Mod3 ( Mod3.hs, interpreted )
  Ok, modules loaded: Mod2, Mod3, Mod1.

 The problem is this: when I call a function from Mod3 from the GHCi
 toplevel, I get a "not in scope" error. I can call the function as
 "Mod3." but "Mod3" does not show up in GHCi's tab
 completion. I don't believe that this is the correct behavior.

-- 
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] #2048: Add split and splitWith to Data.List

[GHC]

#2048: Add split and splitWith to Data.List
-+--
Reporter:  twanvl|   Owner:
Type:  proposal  |  Status:  new   
Priority:  normal|   Component:  libraries/base
 Version:  6.8.2 |Severity:  normal
Keywords:|Testcase:
Architecture:  Unknown   |  Os:  Unknown   
-+--
 An often requested function is 'split', to split a list into parts
 delimited by some separator. ByteString has the functions split and
 splitWith for this purpose. I propose we add equivalents to Data.List.

-- 
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] #1826: unable to list source for should never occur

[GHC]

#1826: unable to list source for  should never occur
-+--
 Reporter:  guest|  Owner: 
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone:  6.8.3  
Component:  GHCi |Version:  6.8.1  
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Multiple   
   Os:  Multiple |  
-+--
Comment (by igloo):

 I've improved the error, but I'm not sure how to tell if we are running
 with `:trace`; is there an easy way?

-- 
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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks

[GHC]

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-+--
 Reporter:  maeder   |  Owner: 
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler |Version:  6.8.2  
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Multiple   
   Os:  MacOS X  |  
-+--
Comment (by maeder):

 I've missed #1975, so go ahead and fix 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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks

[GHC]

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-+--
 Reporter:  maeder   |  Owner: 
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler |Version:  6.8.2  
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Multiple   
   Os:  MacOS X  |  
-+--
Comment (by judah):

 Replying to [comment:11 maeder]:
 > Check at least in my (recently attached) version that passes -F properly
 to gcc and ld for ghc-6.8.3, I've removed checking the home directory, so
 the above objections are no longer valid.

 If I understand correctly, that latest version fixes bug #1975 (see that
 ticket for a test case).  For organization's sake, can we keep this ticket
 about adding `$HOME/Library/Frameworks`, and use #1975 to track that bug
 and its fixes?

-- 
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] #1012: ghc panic with mutually recursive modules and template haskell

[GHC]

#1012: ghc panic with mutually recursive modules and template haskell
--+-
 Reporter:  guest |  Owner: 
 Type:  bug   | Status:  reopened   
 Priority:  normal|  Milestone:  6.10 branch
Component:  Template Haskell  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:  TH_import_loop|   Architecture:  Multiple   
   Os:  Multiple  |  
--+-
Changes (by simonpj):

  * milestone:  _|_ => 6.10 branch

Comment:

 Fair enough. I have taken a little look at this, based on fons's
 suggestion "``every module M that depends on a module C in a cycle, but is
 not a member of that cycle, should have an implicit dependency on each of
 the modules C1.. Cn in the cycle.``". Yes, I think that would not be too
 hard to do.  There are two places to think about:

  * `ghc --make`: When deciding the up-sweep order, first do a SCC analysis
 finding strongly connected components of modules, and top-sort those
 components.  Then linearise each component. That gives a linear order that
 respects fons's suggestion.

  * `ghc -M`: similar story, but less neat.  We have to emit lots of extra
 dependencies in the `makefile`, so that M depends on C1..Cn.

 Not very hard, but more than an hours work.  Let's do it for 6.10.

 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] #2040: GADT regression

[GHC]

#2040: GADT regression
-+--
 Reporter:  guest|  Owner:  chak   
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler (Type checker)  |Version:  6.8.2  
 Severity:  normal   | Resolution: 
 Keywords:  gadt | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by simonpj):

  * owner:  => chak
  * difficulty:  => Unknown
  * milestone:  => 6.10 branch

Comment:

 Thanks for a good report.

 Having looked at the code, I think it's quite surprising that 6.8.1 worked
 at all.  Just for the record (I don't expect users to understand this
 bit), the problem is this.  Here's a smaller version of the code,
 decorated with constraints:
 {{{
 foo2 :: W (S ()) -> W (S ()) -> ()
 foo2 (W (_ :: W a1))-- C a1 b1, S () ~ S b1
  (W (_ :: W a2))-- C a2 b2, S () ~ S b2
  =
   case {-# Needs C a1 (S ()) #-}
proof :: Teq a1 (S ()) of
 Teq -> {-# Provides a1~S () #-}
   {-# Needs: C a2 (S ()) #-}
   (proof :: Teq a2 (S ()))
`seq` ()
 }}}
 The inner use of `proof` gives rise to a constraint `(C a2 (S ()))`.  This
 is wrapped in an implication constraint because of the enclosing case
 expression.  But the `tci_reft` of that implication constraint does not
 include the type refinements from the enclosing pattern matches.  So when
 `reduceImplication` makes that the current type refinement, we're missing
 the outer refinements.

 This is a clear bug in 6.8.2, since there is no use of type functions.  It
 would in principle be fixable in 6.8.3, but it's not completely trivial to
 do, so I'm disinclined to attempt it since we are rejigging the whole
 machinery for the HEAD.

 Meanwhile the HEAD falls over (which it should not) because the constraint
 simplifier is not deducing all the things it should.  This is Manuel's
 pigeon at the moment, so I'm assigning the bug to him.  In due course this
 program should join the test suite.

 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] #2046: Parse errors for mismatched brackets are awful

[GHC]

#2046: Parse errors for mismatched brackets are awful
---+
 Reporter:  NeilMitchell   |  Owner:   
 Type:  feature request| Status:  closed   
 Priority:  normal |  Milestone:   
Component:  Compiler (Parser)  |Version:  6.6.1
 Severity:  minor  | Resolution:  duplicate
 Keywords: | Difficulty:  Unknown  
 Testcase: |   Architecture:  Unknown  
   Os:  Unknown|  
---+
Comment (by NeilMitchell):

 A simple fix would be that if the parsing fails with a "possibly incorrect
 indentation" style warning, you rerun the lexer over the original file,
 without inserting symbols based on indentation. After you have this raw
 lexical stream, you do a simple scan with a bracket stack and check
 everything matches up. If it doesn't, you give a very precise error
 indicating exactly which bracket was not match. If it does, you fall back
 to the same situation we have now.

 Assuming the lexer is sufficiently modular, this should be easy (at a
 guess), and not complicate any other part of the compiler.

-- 
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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks

[GHC]

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-+--
 Reporter:  maeder   |  Owner: 
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler |Version:  6.8.2  
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Multiple   
   Os:  MacOS X  |  
-+--
Comment (by maeder):

 Delete "and link with frameworks located in $HOME/Library/Frameworks" from
 the description of this ticket.

-- 
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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks

[GHC]

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-+--
 Reporter:  maeder   |  Owner: 
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler |Version:  6.8.2  
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Multiple   
   Os:  MacOS X  |  
-+--
Comment (by maeder):

 Check at least in my (recently attached) version that passes -F properly
 to gcc and ld for ghc-6.8.3, I've removed checking the home directory, so
 the above objections are no longer valid.

-- 
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] #459: Bad parse error message

[GHC]

#459: Bad parse error message
---+
 Reporter:  nobody |  Owner:  simonmar
 Type:  bug| Status:  new 
 Priority:  normal |  Milestone:  _|_ 
Component:  Compiler (Parser)  |Version:  6.4.1   
 Severity:  minor  | Resolution:  None
 Keywords: | Difficulty:  Unknown 
 Testcase: |   Architecture:  Unknown 
   Os:  Unknown|  
---+
Changes (by simonmar):

  * priority:  low => normal

Comment:

 See also #2046.  Raising priority based on feedback.

-- 
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] #2046: Parse errors for mismatched brackets are awful

[GHC]

#2046: Parse errors for mismatched brackets are awful
---+
 Reporter:  NeilMitchell   |  Owner:   
 Type:  feature request| Status:  closed   
 Priority:  normal |  Milestone:   
Component:  Compiler (Parser)  |Version:  6.6.1
 Severity:  minor  | Resolution:  duplicate
 Keywords: | Difficulty:  Unknown  
 Testcase: |   Architecture:  Unknown  
   Os:  Unknown|  
---+
Changes (by simonmar):

  * component:  Compiler => Compiler (Parser)
  * difficulty:  => Unknown
  * status:  new => closed
  * resolution:  => duplicate

Comment:

 This is a long-standing problem, see #459 :-)

 The "possibly incorrect indentation" message arises because the token the
 parser is looking at is one that was generated by layout.  I honestly
 don't know whether there's anything we can easily do to improve matters in
 the context of the current parser, but I suspect not.

 Anyway, I propose to look at it next time I'm in the area.

-- 
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] #2047: ghc compiled program crashes with segfault when using -M and/or -c

[GHC]

#2047: ghc compiled program crashes with segfault when using -M and/or -c
+---
 Reporter:  mte |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.8.3  
Component:  Runtime System  |Version:  6.8.2  
 Severity:  critical| Resolution: 
 Keywords:  gc segfault | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Windows |  
+---
Changes (by simonmar):

  * difficulty:  => Unknown
  * milestone:  => 6.8.3

Comment:

 This certainly sounds like a bug in the compacting GC.  Without means to
 reproduce it though, it's impossible to diagnose.

 If you could reproduce the error in non-proprietary code, or somehow
 arrange to give me the code with a no-redistribution license, that would
 help a lot.

 If you need to use `-M` without the compacting GC, the workaround is to
 add `-c100`, which should disable the automatic compacting GC threshold.

-- 
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