- Hugs-Bugs - Haskell.org

Re: [Hugs] #51: The WinHugs uninstaller.exe doesn't work!
by Hugs 01 Nov '07

01 Nov '07

#51: The WinHugs uninstaller.exe doesn't work! -----------------------+---------------------------------------------------- Reporter: guest | Owner: neil Type: defect | Status: assigned Priority: critical | Milestone: Component: winhugs | Version: current Resolution: | Keywords: setup uninstall -----------------------+---------------------------------------------------- Comment (by guest): Hello, I would like to know if this problem (and more importantly the problem from track 42) has been resolved as I too have been having the same problem with uninstalling winhugs and I am getting the error message mentioned in track 42. http://hackage.haskell.org/trac/hugs/ticket/42 Replying to [ticket:51 guest]: > Hi guys! > > I was trying to uninstall WinHugs in order to install a newer version, and I found that the uninstaller.exe program doesn't work. > > I opened the uninstaller.exe with a hex editor, and I found that it's not a valid executable file. It's some weird combination of HTML and executable code. These are the first 15 lines of the uninstaller.exe file: > > > {{{ > <html> > <head> > <META HTTP-EQUIV="Content-Type" content="text/html; charset=Windows-1252"> > </head> > <body> > <pre> > <table width=100% bgcolor=#CFCFE5><tr> <td> <font face=arial size=+3> > Build Log > </font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5> </td><td width=0 bgcolor=#FFFFFF> </td><td width=*><pre> > <h3>------- Build started: Project: Uninstaller, Configuration: Release|Win32 ------- > </h3> > </pre></table><table width=100% bgcolor=#DFDFE5><tr><td><font face=arial size=+2> > Command Lines > </font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5> </td><td width=0 bgcolor=#FFFFFF> </td><td width=*><pre>Uninstaller - up-to- date.</pre></table><table width=100% height=20 bgcolor=#CFCFE5><tr><td><font face=arial size=+2> > </font></table></body></html> > }}} > > I hope this is not difficult to fix. > > Greetings, > -- L e a n d r o < c a f e s o l o [at] g m a i l [dot] c o m > -- Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/51#comment:5> Hugs <http://www.haskell.org/hugs/> Hugs 98, an interpreter for Haskell

1 0

:r myfile.hs does nothing
by Neil Mitchell 25 Oct '07

25 Oct '07

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

1 0

Re: [Hugs] #59: missing and/or erroneous output in deteministic function run from WinHUGS cmd line!
by Hugs 21 Oct '07

21 Oct '07

#59: missing and/or erroneous output in deteministic function run from WinHUGS cmd line! ---------------------------------------------+------------------------------ Reporter: ettinger(a)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: <http://hackage.haskell.org/trac/hugs/ticket/59#comment:4> Hugs <http://www.haskell.org/hugs/> Hugs 98, an interpreter for Haskell

1 0

Re: [Hugs] #29: WinHugs: $$ last value doesn't work
by Hugs 21 Oct '07

21 Oct '07

#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: <http://hackage.haskell.org/trac/hugs/ticket/29#comment:5> Hugs <http://www.haskell.org/hugs/> Hugs 98, an interpreter for Haskell

1 0

Re: [Hugs] #73: Sieve of Eratosthenes crashes if using "Integer" while not if using "Int"
by Hugs 21 Oct '07

21 Oct '07

#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: <http://hackage.haskell.org/trac/hugs/ticket/73#comment:4> Hugs <http://www.haskell.org/hugs/> Hugs 98, an interpreter for Haskell

1 0

Re: [Hugs] #78: getCh
by Hugs 17 Oct '07

17 Oct '07

#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: <http://hackage.haskell.org/trac/hugs/ticket/78#comment:1> Hugs <http://www.haskell.org/hugs/> Hugs 98, an interpreter for Haskell

3 2

[Hugs] #79: Memory leak ?
by Hugs 17 Oct '07

17 Oct '07

#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(a)poczta.onet.pl) [[BR]] PS: Forgive me my bad english. -- Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/79> Hugs <http://www.haskell.org/hugs/> Hugs 98, an interpreter for Haskell

1 1

[Hugs] #77: Binding variables on the prompt
by Hugs 17 Sep '07

17 Sep '07

#77: Binding variables on the prompt -------------------------------------------------+-------------------------- Reporter: apfelmus | Owner: nobody Type: enhancement | Status: new Priority: major | Milestone: Component: hugs | Version: current Keywords: interactive prompt variable binding | -------------------------------------------------+-------------------------- In GHCi, it's possible to bind variables at the interactive prompt, like {{{ > let x = 1 > x + 1 2 > y <- readFile "Foo.bar" "Hello World" > length y 11 }}} The rule is that the bindings are legal in the do-notation for the IO- monad. For details, see [http://www.haskell.org/ghc/docs/latest/html/users_guide/ch03s04.html Interactive evaluation at the prompt] in the GHC user's guide. I'm dearly missing this feature in Hugs! -- Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/77> Hugs <http://www.haskell.org/hugs/> Hugs 98, an interpreter for Haskell

1 0

curiosity, bug, or just dead code?
by Claus Reinke 11 Sep '07

11 Sep '07

consider this module, which is accepted by ghci-6.6.1: module T where import qualified Prelude as T(length) import Prelude(length) length = 0 there is no way to refer to either length, as both 'length' and 'T.length' are ambiguous (ghci complains on uses of either name). but is it a bug? then again, everything is implicitly exported, and there are two possible 'T.length'.. (hugs [20051031] complains about conflicting exports, on loading T). now for the good part: module Q where import T main = print T.length loads fine, and running main returns 0. Ok, modules loaded: Q, T. *Q> main 0 so this must be a bug, right? or a matter of interpretation? not everything is exported implicitly: imported items, whether unqualified or qualified and renamed to share the current module as qualifier are not exported by default. and changing module T where to module T(module T) where leads to conflicting export errors on load in ghci. currently, i think ghci is right, and hugs is wrong (note that my hugs is rather old, though), but it wasn't what i expected. claus

2 1

Problem with uninstalling WinHugs
by Peter Wong 28 Aug '07

28 Aug '07

Hello, I have been trying to uninstall WinHugs (Sep 2006 Release) and everytime the program catches the following exception message from a popup window titled "16 bit MS-DOS Subsystem" and terminates. C:\PROGRA~1\WinHugs\UNINST~1.EXE The NTVDM CPU has encountered an illegal instruction. CS:0f3d IP:0130 OP:63 6f 6e 74 65 Choose 'Close' to terminate the application. It will be great if someone could advise me on that. Thanks. Peter

1 0