From trac at galois.com Wed Oct 17 08:09:07 2007 From: trac at galois.com (Hugs) Date: Wed Oct 17 08:07:16 2007 Subject: [Hugs] #79: Memory leak ? Message-ID: <045.32610e867f9ac75b040ad184ec969098@localhost> #79: Memory leak ? --------------------+------------------------------------------------------- Reporter: guest | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: hugs | Version: 200609 Keywords: | --------------------+------------------------------------------------------- Lately I've come across a most interesting error. With this code for rev: {{{ rev [] xs = xs rev (x:xs) ys = rev xs (x:ys) }}} Hugs returned: {{{ Main> rev tab1 [] ERROR - Garbage collection fails to reclaim sufficient space Main> }}} After some tests I've found out that (of course after restarting Hugs) that request to print on screen ''tab'' where the code is {{{ tab = [1..1000000] }}} will result in a same crash (ERROR - Garbage collection fails to reclaim sufficient space). Results where like this:[[BR]] {{{ . . . 246368,246369,246370,246371,246372,246373,246374,246375,246376,246377,246378,246379,246380,246381,246382,246383,246384,246385,246386,246387,246388,246389,246390,246391,246392,246393,246394,246395,246396,246397,246398,246399,246400,246401,246402,246403,246404,246405,246406,246407,246408,246409,246410 ERROR - Garbage collection fails to reclaim sufficient space Main> }}} Yet still request to simply print [1..1000000] is managed without this problem (of course after restarting Hugs). Seems like some sort of a memory leak, but in which part? After those problems occure there are problems to do much simpler thing. Example:[[BR]] {{{ Main> (length tab) `seq` "" " ERROR - Garbage collection fails to reclaim sufficient space Main> [1..100] [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23, ERROR - Garbage collection fails to reclaim sufficient space Main> }}} Looks like the constructor '..' works well because there is no problem with printing [1..n] where n > 1 000 000 but on the other hand there seem to be problems on passing such list (even shorter) to a variable ''tab''.[[BR]] 1. Is this passing blocks garbage collector from cleaning this memory once it's aloccated during printing?[[BR]] 2. Maybe it was intentional because of something I don't know. If it is, please could You explain why? [[BR]] Many thanks for Your time.[[BR]] Simon Laszczynski (bast_ian@poczta.onet.pl) [[BR]] PS: Forgive me my bad english. -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Wed Oct 17 09:02:53 2007 From: trac at galois.com (Hugs) Date: Wed Oct 17 09:01:02 2007 Subject: [Hugs] #79: Memory leak ? In-Reply-To: <045.32610e867f9ac75b040ad184ec969098@localhost> References: <045.32610e867f9ac75b040ad184ec969098@localhost> Message-ID: <054.f117a3c20d3787393c03cb3388d0de12@localhost> #79: Memory leak ? ----------------------+----------------------------------------------------- Reporter: guest | Owner: nobody Type: defect | Status: closed Priority: major | Milestone: Component: hugs | Version: 200609 Resolution: invalid | Keywords: ----------------------+----------------------------------------------------- Changes (by ross): * status: new => closed * resolution: => invalid Comment: This is all expected behaviour. In the first case, computing the reverse requires building the whole list, and it doesn't fit. It the second, if you say `print [1..1000000]`, the front part of the list is evaluated and printed, but since there are no more references to it, it can be reclaimed by the garbage collector. But when you have a definition `tab = [1..1000000]`, printing evaluates the whole list, but it can't be reclaimed, because there is still a reference to it, namely `tab`. -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Wed Oct 17 09:07:11 2007 From: trac at galois.com (Hugs) Date: Wed Oct 17 09:05:20 2007 Subject: [Hugs] #78: getCh In-Reply-To: <045.3a0f212f275ade585f69f5b8181c8ab4@localhost> References: <045.3a0f212f275ade585f69f5b8181c8ab4@localhost> Message-ID: <054.e39077c08bd3decddbe4cc33a55a7126@localhost> #78: getCh ----------------------+----------------------------------------------------- Reporter: guest | Owner: nobody Type: defect | Status: closed Priority: minor | Milestone: Component: hugs | Version: 200609 Resolution: wontfix | Keywords: ----------------------+----------------------------------------------------- Changes (by ross): * status: new => closed * resolution: => wontfix Comment: It was a Hugs-only function, and now it's gone. You should be able to get the same effect with `hSetBuffering` and `hSetEcho` (from `System.IO`). -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From bird at comlab.ox.ac.uk Wed Oct 17 11:50:21 2007 From: bird at comlab.ox.ac.uk (Richard Bird) Date: Wed Oct 17 11:48:49 2007 Subject: [Hugs] #78: getCh In-Reply-To: <054.e39077c08bd3decddbe4cc33a55a7126@localhost> References: <045.3a0f212f275ade585f69f5b8181c8ab4@localhost> <054.e39077c08bd3decddbe4cc33a55a7126@localhost> Message-ID: <47162F3D.3070106@comlab.ox.ac.uk> Of course, I tried that before sending a bug, but it doesn't work. For example, > getCh = do {hSetBuffering stdin NoBuffering; > hSetEcho stdin False; > x <- getChar; > hSetEcho stdin True; > return x} > getMyLine = do {x <- getCh; > if x=='\n' then > do {putChar x; return ""} > else > do {if x=='b' then > putStr "\b \b" > else putChar x; > xs <- getMyLine; > return (x:xs)} } doesn't work in the expected way. Hugs wrote: > #78: getCh > ----------------------+----------------------------------------------------- > Reporter: guest | Owner: nobody > Type: defect | Status: closed > Priority: minor | Milestone: > Component: hugs | Version: 200609 > Resolution: wontfix | Keywords: > ----------------------+----------------------------------------------------- > Changes (by ross): > > * status: new => closed > * resolution: => wontfix > > Comment: > > It was a Hugs-only function, and now it's gone. You should be able to get > the same effect with `hSetBuffering` and `hSetEcho` (from `System.IO`). > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Hugs-Bugs mailing list > Hugs-Bugs@haskell.org > http://www.haskell.org/mailman/listinfo/hugs-bugs From ross at soi.city.ac.uk Wed Oct 17 13:37:45 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Oct 17 13:36:05 2007 Subject: [Hugs] #78: getCh In-Reply-To: <47162F3D.3070106@comlab.ox.ac.uk> References: <045.3a0f212f275ade585f69f5b8181c8ab4@localhost> <054.e39077c08bd3decddbe4cc33a55a7126@localhost> <47162F3D.3070106@comlab.ox.ac.uk> Message-ID: <20071017173745.GA4330@soi.city.ac.uk> On Wed, Oct 17, 2007 at 04:50:21PM +0100, Richard Bird wrote: >> It was a Hugs-only function, and now it's gone. You should be able to >> get the same effect with `hSetBuffering` and `hSetEcho` (from `System.IO`). > > Of course, I tried that before sending a bug, > but it doesn't work. OK, there's a bug in setBuffering on terminals, now fixed in the development version. (untested on Windows, though.) From trac at galois.com Sun Oct 21 09:55:34 2007 From: trac at galois.com (Hugs) Date: Sun Oct 21 09:53:30 2007 Subject: [Hugs] #73: Sieve of Eratosthenes crashes if using "Integer" while not if using "Int" In-Reply-To: <045.d9a24485367d566d68d53aecacecb854@localhost> References: <045.d9a24485367d566d68d53aecacecb854@localhost> Message-ID: <054.0a5d510e070fad9bfd3691d8034b395b@localhost> #73: Sieve of Eratosthenes crashes if using "Integer" while not if using "Int" ---------------------+------------------------------------------------------ Reporter: guest | Owner: nobody Type: defect | Status: new Priority: minor | Milestone: Component: hugs | Version: 200609 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by guest): Test Trac email again. [http://www.seductionbase.com/ seduction] [http://www.seductionbase.com/pickuplines pickup] -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Sun Oct 21 09:57:57 2007 From: trac at galois.com (Hugs) Date: Sun Oct 21 09:55:52 2007 Subject: [Hugs] #29: WinHugs: $$ last value doesn't work In-Reply-To: <044.10d46e9697245001f935c4950491a61f@localhost> References: <044.10d46e9697245001f935c4950491a61f@localhost> Message-ID: <053.3c4a2274df36d3395783151eb57d6083@localhost> #29: WinHugs: $$ last value doesn't work -----------------------+---------------------------------------------------- Reporter: neil | Owner: neil Type: defect | Status: closed Priority: critical | Milestone: next release Component: winhugs | Version: 200605 Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment (by guest): Test Trac email again. [http://www.seductionbase.com/ seduction] [http://www.seductionbase.com/pickuplines pickup] -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Sun Oct 21 09:58:01 2007 From: trac at galois.com (Hugs) Date: Sun Oct 21 09:56:00 2007 Subject: [Hugs] #59: missing and/or erroneous output in deteministic function run from WinHUGS cmd line! In-Reply-To: <070.f928da020bbc4106dd30ed4cfbefbf30@localhost> References: <070.f928da020bbc4106dd30ed4cfbefbf30@localhost> Message-ID: <079.bb1ace67ee3583aec83b615a1a9fb7af@localhost> #59: missing and/or erroneous output in deteministic function run from WinHUGS cmd line! ---------------------------------------------+------------------------------ Reporter: ettinger@elmgate.eclipse.co.uk | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: hugs | Version: 200609 Resolution: | Keywords: inconsistent expression evaluation ---------------------------------------------+------------------------------ Comment (by guest): Test Trac email again. [http://www.seductionbase.com/ seduction] [http://www.seductionbase.com/pickuplines pickup] -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From ndmitchell at gmail.com Thu Oct 25 07:14:47 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Oct 25 07:12:35 2007 Subject: :r myfile.hs does nothing Message-ID: <404396ef0710250414q788f0f42n7a7d808b3ccfcf55@mail.gmail.com> Hi While teaching beginners I noticed that about 5 of them made the same mistake. They were typing ":r filename.hs" to load a file, which doesn't load a file, but reloads the currently active module (the Prelude in this case). It was made worse by the fact that their file was sum.hs and contained an implementation of sum which they had to test - and the Prelude version hid their error. Is there anything that can be typed after ":r" which gives the command any effect? If not, perhaps ":r anything" should be reported to the user as a warning or an error. To compare to GHC's behaviour: GHCi Prelude> :r Ok, modules loaded: none. Prelude> :r foo.hs module does not exist Prelude> Thanks Neil