Folks, I'm on Mac OSX 10.4.3 with 1Gb of memory and GHC 6.4.1. I'm using HList to define 92 structures in a module. I'm not using classes. There's some nesting going on (see below). Few datypes above are data, mostly they are newtypes around Word32s, Strings, and lists of those. I have 40 newtypes that wrap HLists and homogeneous lists of HList types, 52 are type aliases around HLists. Both with and without -O ghc cannot compile my module. I run out of physical memory within 2-3 minutes and then it's just swapping (I think) and the system becomes totally unresponsive. Any ideas how to remedy this? I shudder at thinking about compiling this on Windows with 256Mb of memory. I will try to split the module into smaller modules and will report my findings. Thanks, Joel P.S. Some example types: newtype Tables = Tables [TableInfo] deriving (Show, Typeable) type TableInfo = AvgPot :*: NumPlayers :*: Waiting :*: PlayersFlop :*: TableName :*: TableID :*: GameType :*: InfoMaxPlayers :*: RealMoneyTable :*: LowBet :*: HighBet :*: MinStartMoney :*: MaxStartMoney :*: GamesPerHour :*: TourType :*: TourID :*: BetType :*: CantReturnLess :*: AffiliateID :*: NIsResurrecting :*: MinutesForTimeout :*: SeatsToResurrect :*: LangID :*: HNil -- http://wagerlabs.com/
Part of the problem seems to do with 218 newtypes that I have in one module that I'm importing and about 30 newtype/data in another imported module. I moved just 7 HList types into a separate module but still could not compile. I then tried just 4 and then just 2 and still no dice. This makes me think that the problem could be somewhere else. Could it have to do with HList enabling overlapped and undecided instances and ghc not being able to decide something? On Nov 9, 2005, at 4:06 PM, Joel Reymont wrote:
Folks,
I'm on Mac OSX 10.4.3 with 1Gb of memory and GHC 6.4.1. I'm using HList to define 92 structures in a module. I'm not using classes.
There's some nesting going on (see below). Few datypes above are data, mostly they are newtypes around Word32s, Strings, and lists of those. I have 40 newtypes that wrap HLists and homogeneous lists of HList types, 52 are type aliases around HLists.
Both with and without -O ghc cannot compile my module. I run out of physical memory within 2-3 minutes and then it's just swapping (I think) and the system becomes totally unresponsive.
On Windows with just 256Mb of memory the single HList type module compiles but the big one gives a heap exhausted message. On Nov 9, 2005, at 4:22 PM, Joel Reymont wrote:
Part of the problem seems to do with 218 newtypes that I have in one module that I'm importing and about 30 newtype/data in another imported module.
I moved just 7 HList types into a separate module but still could not compile. I then tried just 4 and then just 2 and still no dice. This makes me think that the problem could be somewhere else. Could it have to do with HList enabling overlapped and undecided instances and ghc not being able to decide something?
I narrowed the issue down to something that everyone can reproduce. Sample code that makes GHC 6.4.1 run out of memory is here: http://wagerlabs.com/Foo.hs Cabalized HList can be found here: http://www.cs.helsinki.fi/u/ekarttun/haskell/ Thanks, Joel -- http://wagerlabs.com/
Commenting these lines will let GHC start producing errors about instances that it cannot derive without -fglasgow-exts. Uncomment MinutesForTimeout and it will start to run out of memory again. --newtype Tables = Tables [TableInfo] deriving (Show, Typeable) --MinutesForTimeout :*: --SeatsToResurrect :*: --LangID :*: With -fglasgow-exts only the first line needs to be commented out for the code to compile. On Nov 9, 2005, at 5:08 PM, Joel Reymont wrote:
I narrowed the issue down to something that everyone can reproduce.
Sample code that makes GHC 6.4.1 run out of memory is here:
Cabalized HList can be found here:
I further narrowed it down to that first line. I also commented out all the Typeables and commented out the derivation of Tables entirely.
newtype Tables = Tables [TableInfo] -- deriving (Show, Typeable)
It does not compile without -fglasgow-exts but does compile using it. I then tried to add the following derivation instance Show Tables where show (Tables (x:xs)) = show' x ++ show' xs where show' [] = "" show' (x:xs) = show' x ++ show xs and ghc started exploding again. All the types in TableInfo are derived from Show. Joel -- http://wagerlabs.com/
Shae (#haskell) figured out that this is called for and that GHC has trouble deriving for large tuples. I have no idea what type of a performance hit this is gonna be but I hope it's resolved at compile- time and there's no impact afterwards. type TableInfo = TableInfo1 :*: TableInfo2 type TableInfo1 = AvgPot :*: NumPlayers :*: Waiting :*: PlayersFlop :*: TableName :*: TableID :*: GameType :*: InfoMaxPlayers :*: RealMoneyTable :*: LowBet :*: HighBet :*: HNil type TableInfo2 = MinStartMoney :*: MaxStartMoney :*: GamesPerHour :*: TourType :*: TourID :*: BetType :*: CantReturnLess :*: AffiliateID :*: NIsResurrecting :*: MinutesForTimeout :*: SeatsToResurrect :*: LangID :*: HNil Thanks, Joel -- http://wagerlabs.com/
participants (1)
-
Joel Reymont