date:20111019

Re: [GHC] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments

2011-10-19 Thread GHC

#5529: Newtypes with hidden constructors cannot be passed as FFI arguments
---+
Reporter:  mikhail.vorozhtsov  |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 mikhail.vorozhtsov):

 To sum things up.

 1. Exported constructors do not help programmers to get the FFI import's
 types right, as GHC provides no way to (automatically) assert that type X
 is a wrapper (using arbitrary number of layers) around "primitive" type
 which is equivalent to the desired C type y_t.

 2. GHC's FFI implementation does need to know the representations of the
 types used in an FFI import. But this information does not necessarily
 need to be passed around in the form of exported constructors. Store it
 somewhere else in the module interface and leave the export list to
 programmers.

-- 
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] #5563: ANNOUNCE file is from GHC 6.10

2011-10-19 Thread GHC

#5563: ANNOUNCE file is from GHC 6.10
---+
  Reporter:  GregWeber |  Owner:  
  Type:  bug   | Status:  new 
  Priority:  normal|  Milestone:  
 Component:  Compiler  |Version:  7.2.1   
Resolution:|   Keywords:  
  Testcase:|  Blockedby:  
Difficulty:| Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by GregWeber):

  * status:  patch => new


-- 
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] #5563: ANNOUNCE file is from GHC 6.10

2011-10-19 Thread GHC

#5563: ANNOUNCE file is from GHC 6.10
-+--
Reporter:  GregWeber |Owner:  
Type:  bug   |   Status:  patch   
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by GregWeber):

  * status:  infoneeded => 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

Re: [GHC] #4900: DEPENDS pragma

2011-10-19 Thread GHC

#4900: DEPENDS pragma
-+--
Reporter:  cdsmith   |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  7.4.1   
   Component:  Build System  |  Version:  
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by GregWeber):

 I am hoping to finish this weekend during the VirtuaHac so i will be done
 in time for the next GHC release.

 Still need help though, particularly with connecting GHC to the Quasi
 Monad. Latest diff is here:
 
https://github.com/gregwebs/ghc/compare/ghc:ceef80b2fbd414c701bb2a346226a357475983ad...dependent2

-- 
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] #5561: assertion overriden by other exceptions

2011-10-19 Thread GHC

#5561: assertion overriden by other exceptions
--+-
  Reporter:  MikolajKonarski  |  Owner:
  Type:  bug  | Status:  closed
  Priority:  normal   |  Milestone:
 Component:  Compiler |Version:  7.3   
Resolution:  fixed|   Keywords:
  Testcase:  assert   |  Blockedby:
Difficulty:   | Os:  Linux 
  Blocking:   |   Architecture:  x86_64 (amd64)
   Failure:  Incorrect result at runtime  |  
--+-
Changes (by igloo):

  * status:  new => closed
  * testcase:  => assert
  * resolution:  => fixed


Comment:

 Done:
 {{{
 commit cc4774d8b1e2736c4b9171db05451ba6355c98b6
 Author: Ian Lynagh 
 Date:   Wed Oct 19 22:23:19 2011 +0100

 If an assertion fails, through it rather than a deeper error; fixes
 #5561

 An expression like
 assert False (throw e)
 should throw the assertion failure rather than e
 }}}

-- 
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] #5543: Building on OS X 10.5 with XCode 3.4.1 runs into "ld: unknown option: -no_compact_unwind"

2011-10-19 Thread GHC

#5543: Building on OS X 10.5 with XCode 3.4.1 runs into "ld: unknown option:
-no_compact_unwind"
--+-
  Reporter:  thorkilnaur  |  Owner: 
  Type:  bug  | Status:  closed 
  Priority:  normal   |  Milestone: 
 Component:  Compiler |Version:  7.3
Resolution:  fixed|   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  MacOS X
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-
Changes (by igloo):

  * status:  patch => closed
  * resolution:  => fixed


Comment:

 That's great; thanks Thorkil! Applied.

-- 
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] #2132: Optimise nested comparisons

2011-10-19 Thread GHC

#2132: Optimise nested comparisons
-+--
Reporter:  simonpj   |Owner:  simonpj
Type:  bug   |   Status:  patch  
Priority:  low   |Milestone:  7.4.1  
   Component:  Compiler  |  Version:  6.8.2  
Keywords:| Testcase: 
   Blockedby:|   Difficulty:  Unknown
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Runtime performance bug
-+--

Comment(by basvandijk):

 Replying to [comment:18 michalt]:
 > Note that this optimization goes a bit further than your example. For
 > instance, once it knows `x ># y` and `y >=# z` it can optimize away `x
 <# z`.

 This is possible with sub-rules:

 {{{
 {-# RULES
 forall x y t f.
   (case (x ># y) of
  True  -> t
  False -> f
   )
   =
   (case (x ># y) of
  True  -> t {{ forall z t2 f2.
(case (y >=# z) of
  True  -> t2
  False -> f2
)
=
(case (y >=# z) of
  True  -> t2 {{(x <# z)=False}}
  False -> f2
)
 }}
  False -> f
   )
   #-}
 }}}


 > Similarly knowing `x ># 100` and `y <# 10` it can get rid of `x ==# y`.
 > That would be probably quite difficult to do with rules (even extended).

 Encoding it for the concrete `100` and `10` is easy. However encoding it
 for all numbers is not possible without having the ability to reason about
 numbers in the language of RULES.

 I'm sure your patch is way more powerful since I expect it will have this
 ability. I do wonder if sub-rules have other useful applications?

-- 
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] #2132: Optimise nested comparisons

2011-10-19 Thread GHC

#2132: Optimise nested comparisons
-+--
Reporter:  simonpj   |Owner:  simonpj
Type:  bug   |   Status:  patch  
Priority:  low   |Milestone:  7.4.1  
   Component:  Compiler  |  Version:  6.8.2  
Keywords:| Testcase: 
   Blockedby:|   Difficulty:  Unknown
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Runtime performance bug
-+--

Comment(by michalt):

 Replying to [comment:17 basvandijk]:
 > Would it be hard to extend the language of RULES so that a user can
 perform
 > this optimization instead of the compiler? ..

 Note that this optimization goes a bit further than your example. For
 instance, once it knows `x ># y` and `y >=# z` it can optimize away `x <#
 z`.
 Similarly knowing `x ># 100` and `y <# 10` it can get rid of `x ==# y`.
 That would be probably quite difficult to do with rules (even extended).

-- 
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] #5543: Building on OS X 10.5 with XCode 3.4.1 runs into "ld: unknown option: -no_compact_unwind"

2011-10-19 Thread GHC

#5543: Building on OS X 10.5 with XCode 3.4.1 runs into "ld: unknown option:
-no_compact_unwind"
+---
Reporter:  thorkilnaur  |   Owner: 
Type:  bug  |  Status:  patch  
Priority:  normal   |   Component:  Compiler   
 Version:  7.3  |Keywords: 
Testcase:   |   Blockedby: 
  Os:  MacOS X  |Blocking: 
Architecture:  x86  | Failure:  Building GHC failed
+---
Changes (by thorkilnaur):

  * status:  new => patch


Comment:

 Uploaded patch for suggested solution to this problem: Validated on Mac OS
 X 10.5 and Linux. Interestingly, on Linux:
 {{{
 checking whether ld understands -no_compact_unwind... yes
 }}}
 Although not ideal, this is currently harmless, at least given the
 conditions on {{{-no_compact_unwind}}} use in
 {{{compiler/main/DriverPipeline.hs}}}. And please note: I have not had the
 opportunity to test this under circumstances where
 {{{-no_compact_unwind}}} actually should be used.

 Best regards
 Thorkil

-- 
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] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments

2011-10-19 Thread GHC

#5529: Newtypes with hidden constructors cannot be passed as FFI arguments
---+
Reporter:  mikhail.vorozhtsov  |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 mikhail.vorozhtsov):

 Once again, I, as a programmer, am completely fine if the module
 documentation says that MyType mirrors time_t, exported constructor
 doesn't help me a bit (one way to ensure that would be by writing
 something like {{{let unused = MyType (undefined :: CTime)}}}, but what
 about {{{newtype MyType = MyType Int64}}} (assuming time_t ~ int64_t), how
 would you check all possibilities?). GHC doesn't ensure that FFI import's
 types are right (with respect to the C types), programmer does. Well,
 exporting guts may be seen as a sort of documentation, but I'd rather not
 encourage/require that practice.

-- 
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] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments

2011-10-19 Thread GHC

#5529: Newtypes with hidden constructors cannot be passed as FFI arguments
---+
Reporter:  mikhail.vorozhtsov  |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 igloo):

 The point is, if you FFI import a C function that takes a `time_t`, then
 you can't pass it a `MyType` unless you know that `MyType` is represented
 by `CTime` (e.g. `newtype MyType = MyType CTime`). If `MyType` is abstract
 then you don't know that.

-- 
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] #5548: Problem while pasting code into ghci

2011-10-19 Thread GHC

#5548: Problem while pasting code into ghci
+---
  Reporter:  gawi   |  Owner:  igloo 
  Type:  bug| Status:  closed
  Priority:  high   |  Milestone:  7.4.1 
 Component:  GHCi   |Version:  7.0.2 
Resolution:  fixed  |   Keywords:
  Testcase: |  Blockedby:
Difficulty: | Os:  Linux 
  Blocking: |   Architecture:  x86   
   Failure:  Other  |  
+---
Changes (by igloo):

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


Comment:

 Patch pulled.

-- 
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] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications (was: Add Show and Binary instances for TypeRep)

2011-10-19 Thread GHC

#3480: Easily make Typeable keys pure, so that Typeable can be handled 
efficiently
across communications
-+--
  Reporter:  guest   |  Owner:  
  Type:  task| Status:  closed  
  Priority:  normal  |  Milestone:  7.2.1   
 Component:  libraries/base  |Version:  
Resolution:  fixed   |   Keywords:  Typeable, efficiency
  Testcase:  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by simonmar):

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


Comment:

 Changing the title back and closing the ticket again; new ticket is #5568.

-- 
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] #5568: Add Show and Binary instances for TypeRep

2011-10-19 Thread GHC

#5568: Add Show and Binary instances for TypeRep
-+--
Reporter:  simonmar  |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  7.4.1   
   Component:  libraries/base|  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
 (was a re-opening of #3480; copied into a new ticket so we can leave #3480
 dead and buried)

 Unfortunately the new !TypeRepKey type is abstract and provides no
 operations apart from Eq and Ord instances. Hence, there is still no way
 to write a type representation into a file or across the wire. Jush
 showing a !TypeRep won't cut it, since that loses the distinctions between
 similarly named types in different modules.

 So, I think we need a Show instance for !TypeRepKey, or better yet, a
 Binary instance. Moreover, a non-deprecated pure function `TypeRep ->
 TypeRepKey` is in place, since the keys have an actual use as a compact,
 efficient, and serializable injection of the typereps.

 Alternatively, the Show instance of !TypeRep could be made injective by
 printing out the package and module.

 === Commentary from #3480 ===

 simonmar says:

   I've exposed the representation via the Data.Typeable.Internal  module.
 Of course that's not guaranteed to be a stable API, but I'm happy to add a
 stable API if we can agree on what it should be. Lennart Augustsson and
 Neil Mitchell are doing exactly this (serialising !TypeRep) - I think
 they're using the Data.Typeable.Internal API right now.

   So what shall we do?

 Lennart says:

   For older versions of ghc I just used (show . typeOf). When ghc 7.2
 broke this I had to start using Internal, so now I use tyConModule and
 tyConName to emulate the behaviour of the old show.

 lealanko says:

   I'm sorry for messing up the ticket. I had assumed that the missing Show
 instance had been a simple oversight. If so, this would suffice:

 {{{
 instance Show TypeRepKey where
   show (TypeRepKey (Fingerprint hi lo)) = printf "%016x%016x" hi lo
 }}}

   A Binary instance is more difficult: where would it be put? It cannot be
 in Typeable.hs (as base cannot depend on binary), but it cannot be in
 Binary.hs either (as !TypeRepKey is opaque and not exposed from Typeable).

   I don't think it's a good idea to make TypeReps themselves publicly
 deserializable, as that would allow the creation of fake typereps. A
 separate one-way injection to a serializable !TypeRepKey seems much more
 secure.

-- 
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] #5549: ~100% performance regression in HEAD compared to ghc6.12, ~22% compared to 7.0.4

2011-10-19 Thread GHC

#5549: ~100% performance regression in HEAD compared to ghc6.12, ~22% compared 
to
7.0.4
---+
Reporter:  tomaszw |Owner: 
Type:  bug |   Status:  new
Priority:  high|Milestone:  7.4.1  
   Component:  Compiler|  Version:  7.3
Keywords:  performance regression  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  Linux   | Blocking: 
Architecture:  x86 |  Failure:  Runtime performance bug
---+
Changes (by simonmar):

  * priority:  normal => high
  * milestone:  => 7.4.1


Comment:

 let's add the program as a regression test, and look into the difference
 in allocations (if it's still there).

-- 
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] #5561: assertion overriden by other exceptions

2011-10-19 Thread GHC

#5561: assertion overriden by other exceptions
--+-
  Reporter:  MikolajKonarski  |  Owner:
  Type:  bug  | Status:  new   
  Priority:  normal   |  Milestone:
 Component:  Compiler |Version:  7.3   
Resolution:   |   Keywords:
  Testcase:   |  Blockedby:
Difficulty:   | Os:  Linux 
  Blocking:   |   Architecture:  x86_64 (amd64)
   Failure:  Incorrect result at runtime  |  
--+-

Comment(by simonpj):

 I agree with Simon.  It's true that
   `(throw this && throw that)`
 should be allowed to return either exception `this` or `that`, but
`assert False (throw this)`
 should really report the assertion failure, not throw the exception.

 Putting an example like this with the modification to `assertError`, plus
 a pointer to the ticket, would be good. Ian can you do?

 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] #5562: document sync-all in README

2011-10-19 Thread GHC

#5562: document sync-all in README
---+
  Reporter:  GregWeber |  Owner:  simonmar
  Type:  bug   | Status:  closed  
  Priority:  high  |  Milestone:  7.4.1   
 Component:  Compiler  |Version:  7.2.1   
Resolution:  fixed |   Keywords:  
  Testcase:|  Blockedby:  
Difficulty:| Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by simonmar):

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


-- 
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] #4245: ghci panic: thread blocked indefinitely in an MVar operation

2011-10-19 Thread GHC

#4245: ghci panic: thread blocked indefinitely in an MVar operation
---+
Reporter:  pturnbull   |Owner:  igloo 
Type:  bug |   Status:  new   
Priority:  high|Milestone:  7.4.1 
   Component:  GHCi|  Version:  6.12.3
Keywords:  MVar| Testcase:
   Blockedby:  |   Difficulty:
  Os:  MacOS X | Blocking:
Architecture:  x86_64 (amd64)  |  Failure:  GHCi crash
---+

Comment(by simonmar):

 See also #5565

-- 
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] #5565: ghc reports a bug after interrupt

2011-10-19 Thread GHC

#5565: ghc reports a bug after interrupt
-+--
  Reporter:  kop |  Owner:   
  Type:  bug | Status:  closed   
  Priority:  normal  |  Milestone:   
 Component:  GHCi|Version:  7.0.3
Resolution:  duplicate   |   Keywords:  Interrupt
  Testcase:  |  Blockedby:   
Difficulty:  | Os:  Windows  
  Blocking:  |   Architecture:  x86  
   Failure:  GHCi crash  |  
-+--
Changes (by simonmar):

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


Comment:

 I think this is probably the same as #4245, although it is provoked by
 backgrounding on OS X.  Hopefully it is the same underlying bug.

-- 
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] #5561: assertion overriden by other exceptions

2011-10-19 Thread GHC

#5561: assertion overriden by other exceptions
--+-
  Reporter:  MikolajKonarski  |  Owner:
  Type:  bug  | Status:  new   
  Priority:  normal   |  Milestone:
 Component:  Compiler |Version:  7.3   
Resolution:   |   Keywords:
  Testcase:   |  Blockedby:
Difficulty:   | Os:  Linux 
  Blocking:   |   Architecture:  x86_64 (amd64)
   Failure:  Incorrect result at runtime  |  
--+-

Comment(by simonmar):

 Tricky one, but I think we should "fix" it with `lazy` as suggested, and
 put a comment pointing to this ticket next to the fix.

-- 
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] #5564: Panic in ghci name suggestion

2011-10-19 Thread GHC

#5564: Panic in ghci name suggestion
-+--
Reporter:  judahj|Owner:  simonmar
Type:  bug   |   Status:  new 
Priority:  high  |Milestone:  7.4.1   
   Component:  GHCi  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by simonmar):

  * owner:  => simonmar
  * priority:  normal => high
  * component:  Compiler => GHCi
  * milestone:  => 7.4.1


Comment:

 I'm fixing this.

-- 
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] #5565: ghc reports a bug after interrupt

2011-10-19 Thread GHC

#5565: ghc reports a bug after interrupt
--+-
Reporter:  kop|Owner:
Type:  bug|   Status:  new   
Priority:  normal |Milestone:
   Component:  GHCi   |  Version:  7.0.3 
Keywords:  Interrupt  | Testcase:
   Blockedby: |   Difficulty:
  Os:  Windows| Blocking:
Architecture:  x86|  Failure:  GHCi crash
--+-

Comment(by porges):

 Note that that last one was not after interrupt.

 I tried to recreate the conditions under which it happened the second
 time, then starting writing up this bug report. Went back to the window
 and then mistyped ':r'.

-- 
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] #5565: ghc reports a bug after interrupt

2011-10-19 Thread GHC

#5565: ghc reports a bug after interrupt
--+-
Reporter:  kop|Owner:
Type:  bug|   Status:  new   
Priority:  normal |Milestone:
   Component:  GHCi   |  Version:  7.0.3 
Keywords:  Interrupt  | Testcase:
   Blockedby: |   Difficulty:
  Os:  Windows| Blocking:
Architecture:  x86|  Failure:  GHCi crash
--+-
Changes (by porges):

  * architecture:  Unknown/Multiple => x86


-- 
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] #5565: ghc reports a bug after interrupt

2011-10-19 Thread GHC

#5565: ghc reports a bug after interrupt
-+--
Reporter:  kop   |Owner:
Type:  bug   |   Status:  new   
Priority:  normal|Milestone:
   Component:  GHCi  |  Version:  7.0.3 
Keywords:  Interrupt | Testcase:
   Blockedby:|   Difficulty:
  Os:  Windows   | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  GHCi crash
-+--
Changes (by porges):

  * architecture:  x86 => Unknown/Multiple


Comment:

 I just got this (Windows 7, x64). No backgrounding. I managed to reproduce
 it once but not sure how.

 I will attach a GHCi session log.

-- 
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] #2132: Optimise nested comparisons

2011-10-19 Thread GHC

#2132: Optimise nested comparisons
-+--
Reporter:  simonpj   |Owner:  simonpj
Type:  bug   |   Status:  patch  
Priority:  low   |Milestone:  7.4.1  
   Component:  Compiler  |  Version:  6.8.2  
Keywords:| Testcase: 
   Blockedby:|   Difficulty:  Unknown
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Runtime performance bug
-+--
Changes (by basvandijk):

 * cc: v.dijk.bas@… (added)


Comment:

 Would it be hard to extend the language of RULES so that a user can
 perform this optimization instead of the compiler? I'm thinking about
 something like this:

 {{{
 {-# RULES
 forall x y t f.
   (case (x ># y) of
  True  -> t
  False -> f
   )
   =
   (case (x ># y) of
  True  -> t {{(x ==# y)=False}}
  False -> f
   )
   #-}
 }}}

 The `v {{subrules}}` syntax assigns ''sub-RULES'' to the variable `v`.
 `subrules` is a list of RULES of the form `p1 = e1, p2 = e2 ... pn = en`
 which are applied to the expression that `v` refers to.

 I think it would be nice if sub-RULES have the same (or a very similar)
 syntax that normal RULES have. They should even be able to quantify new
 variables.

 The way I expect this to be used most often is that the sub-RULES describe
 the actual substitutions while the ''top-level'' RULE only describes
 context. However it should be possible that both the top-level and the
 sub-rules describe transformations.

 This probably deserves its own ticket so I stop now.

-- 
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] #5562: document sync-all in README

2011-10-19 Thread GHC

#5562: document sync-all in README
-+--
Reporter:  GregWeber |Owner:  simonmar
Type:  bug   |   Status:  new 
Priority:  high  |Milestone:  7.4.1   
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by marlowsd@…):

 commit ddd3c5199fd40386c6385689fdf5c542f831bcf0
 {{{
 Author: Simon Marlow 
 Date:   Wed Oct 19 10:37:08 2011 +0100

 add info about pulling changes (#5562)

  README |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)
 }}}

-- 
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] #5562: document sync-all in README

2011-10-19 Thread GHC

#5562: document sync-all in README
-+--
Reporter:  GregWeber |Owner:  simonmar
Type:  bug   |   Status:  new 
Priority:  high  |Milestone:  7.4.1   
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by simonmar):

  * owner:  => simonmar
  * priority:  normal => high
  * milestone:  => 7.4.1


-- 
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] #5548: Problem while pasting code into ghci

2011-10-19 Thread GHC

#5548: Problem while pasting code into ghci
--+-
Reporter:  gawi   |Owner:  igloo
Type:  bug|   Status:  new  
Priority:  high   |Milestone:  7.4.1
   Component:  GHCi   |  Version:  7.0.2
Keywords: | Testcase:   
   Blockedby: |   Difficulty:   
  Os:  Linux  | Blocking:   
Architecture:  x86|  Failure:  Other
--+-
Changes (by simonmar):

  * owner:  judahj => igloo
  * priority:  normal => high
  * milestone:  => 7.4.1


Comment:

 Let's make sure we get this into 7.4.1.

-- 
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] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments

Re: [GHC] #5563: ANNOUNCE file is from GHC 6.10

Re: [GHC] #5563: ANNOUNCE file is from GHC 6.10

Re: [GHC] #4900: DEPENDS pragma

Re: [GHC] #5561: assertion overriden by other exceptions

Re: [GHC] #5543: Building on OS X 10.5 with XCode 3.4.1 runs into "ld: unknown option: -no_compact_unwind"

Re: [GHC] #2132: Optimise nested comparisons

Re: [GHC] #2132: Optimise nested comparisons

Re: [GHC] #5543: Building on OS X 10.5 with XCode 3.4.1 runs into "ld: unknown option: -no_compact_unwind"

Re: [GHC] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments

Re: [GHC] #5529: Newtypes with hidden constructors cannot be passed as FFI arguments

Re: [GHC] #5548: Problem while pasting code into ghci

Re: [GHC] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications (was: Add Show and Binary instances for TypeRep)

[GHC] #5568: Add Show and Binary instances for TypeRep

Re: [GHC] #5549: ~100% performance regression in HEAD compared to ghc6.12, ~22% compared to 7.0.4

Re: [GHC] #5561: assertion overriden by other exceptions

Re: [GHC] #5562: document sync-all in README

Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation

Re: [GHC] #5565: ghc reports a bug after interrupt

Re: [GHC] #5561: assertion overriden by other exceptions

Re: [GHC] #5564: Panic in ghci name suggestion

Re: [GHC] #5565: ghc reports a bug after interrupt

Re: [GHC] #5565: ghc reports a bug after interrupt

Re: [GHC] #5565: ghc reports a bug after interrupt

Re: [GHC] #2132: Optimise nested comparisons

Re: [GHC] #5562: document sync-all in README

Re: [GHC] #5562: document sync-all in README

Re: [GHC] #5548: Problem while pasting code into ghci

28 matches

Site Navigation

Mail list logo

Footer information