[GHC] #883: cannot use (!) as an infix operator

[GHC]

#883: cannot use (!) as an infix operator
-+--
Reporter:  [EMAIL PROTECTED]  |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  6.6
   Component:  Compiler  |  Version:  6.5
Severity:  normal| Keywords: 
  Os:  Unknown   |   Difficulty:  Unknown
Architecture:  Unknown   |  
-+--
When I tried to compile following code with ghc-6.5.20060830,
 {{{
 {-# INLINE (!) #-}
 -- | Returns the element of an immutable array at the specified index.
 (!) :: (IArray a e, Ix i) => a i e -> i -> e
 arr ! i = case bounds arr of (l,u) -> unsafeAt arr (index (l,u) i)
 }}}
 I got error messages below
 {{{
 Data/ArrayBZ/Internals/IArray.hs:109:11: Not in scope: `!'
 Data/ArrayBZ/Internals/IArray.hs:111:0: Not in scope: `!'
 Data/ArrayBZ/Internals/IArray.hs:201:49: Not in scope: `!'
 }}}

 The above code is a part of !ArrayRef library written by Bulat Ziganshin.

-- 
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] #882: Overflow bug in System.Time

[Sigbjorn Finne]

The fix is trivial though (and have been applied to HEAD) --
 http://hackage.haskell.org/trac/ghc/ticket/588

--sigbjorn

GHC wrote:

#882: Overflow bug in System.Time
---+
Reporter:  simonpj |Owner: 
Type:  bug |   Status:  new
Priority:  normal  |Milestone: 
   Component:  libraries/base  |  Version:  6.4.2  
Severity:  normal  | Keywords: 
  Os:  Unknown |   Difficulty:  Unknown
Architecture:  Unknown |  
---+

Frederik Eaton reports: The Glorious Glasgow Haskell Compilation System,
 version 6.4.3.20060816
 {{{
 > now <- getClockTime
 > addToClockTime (TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour =
 0, tdMin = 0, tdSec = 0, tdPicosec = }) now
 *** Exception: Time.toClockTime: picoseconds out of range

 }}}

 This is clearly a bug.  Simon Marlow comments: System.Time is kind-of
 deprecated: the new time package is intended to supercede it, but I have
 been reluctant to really deprecate System.Time because it comes from
 Haskell98, and also because we don't have much experience with its
 replacement.

  



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


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

[GHC] #882: Overflow bug in System.Time

[GHC]

#882: Overflow bug in System.Time
---+
Reporter:  simonpj |Owner: 
Type:  bug |   Status:  new
Priority:  normal  |Milestone: 
   Component:  libraries/base  |  Version:  6.4.2  
Severity:  normal  | Keywords: 
  Os:  Unknown |   Difficulty:  Unknown
Architecture:  Unknown |  
---+
Frederik Eaton reports: The Glorious Glasgow Haskell Compilation System,
 version 6.4.3.20060816
 {{{
 > now <- getClockTime
 > addToClockTime (TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour =
 0, tdMin = 0, tdSec = 0, tdPicosec = }) now
 *** Exception: Time.toClockTime: picoseconds out of range

 }}}

 This is clearly a bug.  Simon Marlow comments: System.Time is kind-of
 deprecated: the new time package is intended to supercede it, but I have
 been reluctant to really deprecate System.Time because it comes from
 Haskell98, and also because we don't have much experience with its
 replacement.

-- 
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] #881: Improve space profiling for references

[GHC]

#881: Improve space profiling for references
+---
Reporter:  simonpj  |Owner: 
Type:  feature request  |   Status:  new
Priority:  normal   |Milestone: 
   Component:  Profiling|  Version:  6.4.2  
Severity:  normal   | Keywords: 
  Os:  Unknown  |   Difficulty:  Unknown
Architecture:  Unknown  |  
+---
GHC's great space profiling tools don't appear to be much help when your
 leaked memory is stored in references (IORefs, StablePtrs, etc).  I had
 a real-life case where the allocation profile showed me where the leaked
 data came from, and I could guess that it was being held by some
 reference, but I couldn't tell which one.  Retainer set profiling showed
 a big suspicious entry for "SYSTEM", but I couldn't find any way to
 pinpoint the problem.  (It ended up being a missing freeStablePtr in
 hsgnutls, found by code inspection.)

 Here's a contrived example that just allocates a bunch of IORefs:
 {{{
 import Control.Monad
 import Data.IORef

 main = repeatM (newIORef [1,2,3])
 repeatM io = liftM2 (:) io (repeatM io)
 }}}
 Retainer set profiling shows everything in "SYSTEM".  None of the other
 profiling methods say anything interesting either.  What I'd like to
 get, I think, is (1) your memory is being held in IORefs (2) allocated
 by this cost center and (3) being retained by this cost center.  I guess
 I'm looking for something like a memory profiler for a traditional
 language.

 Andrew Pimlott

 Simon Marlow comments: "The relevant predicate "is retainer" is pretty
 much built into the retainer profiler, and it returns true only for thunks
 if I recall correctly.  Being able to tweak this, or maybe just install a
 better default would be an improvement.

-- 
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] #880: someFunction :: TypeRep -> Int

[GHC]

#880: someFunction :: TypeRep -> Int
+---
Reporter:  guest|Owner: 
Type:  feature request  |   Status:  new
Priority:  normal   |Milestone: 
   Component:  libraries/base   |  Version:  6.4.2  
Severity:  normal   | Keywords: 
  Os:  Unknown  |   Difficulty:  Easy (1 hr)
Architecture:  Unknown  |  
+---
Now that TypeRep share their keys using RTS internal allocation, can we
 get a function in Data.Typeable (or even GHC.Exts) that retrieves the Int
 key?  Currently my job code (OpenAFP) and Pugs both uses "show :: TypeRep
 -> String" as the key for Map, but I think it'd be much, much faster if
 either TypeRep supports Ord natively, or (preferably) that we can get a
 Int out of it.

 Thanks!
 Audrey

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