From trac at galois.com Thu Nov 1 15:18:51 2007 From: trac at galois.com (Hugs) Date: Thu Nov 1 15:16:10 2007 Subject: [Hugs] #51: The WinHugs uninstaller.exe doesn't work! In-Reply-To: <045.e5b6b255a4bc37f00ff0939840bb53f4@localhost> References: <045.e5b6b255a4bc37f00ff0939840bb53f4@localhost> Message-ID: <054.f3449c36e7f5bd0d58e7dd5627a908c5@localhost> #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: > > > {{{ > > > > > >
 > 
> Build Log >
  
 > 

------- Build started: Project: Uninstaller, Configuration: Release|Win32 ------- >

>
> Command Lines >
  
Uninstaller - up-to-
 date.
>
> }}} > > 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: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Thu Nov 1 15:19:22 2007 From: trac at galois.com (Hugs) Date: Thu Nov 1 15:16:42 2007 Subject: [Hugs] #42: WinHugs uninstaller crashes In-Reply-To: <050.1e1520ee74457c04ad0ecfdd9115fd24@localhost> References: <050.1e1520ee74457c04ad0ecfdd9115fd24@localhost> Message-ID: <059.f79f6a8c3ebcaf0c6a2589398eeea4aa@localhost> #42: WinHugs uninstaller crashes -------------------------+-------------------------------------------------- Reporter: briansmith | Owner: neil Type: defect | Status: closed Priority: major | Milestone: Component: winhugs | Version: 200609 Resolution: duplicate | Keywords: -------------------------+-------------------------------------------------- Comment (by guest): Hello, I would like to know if this problem has been resolved as I too have been having the same problem with uninstalling winhugs. Peter Replying to [ticket:42 briansmith]: > I will attach a screenshot of the error. > > The error is: > {{{ > 16 bit MS-DOS Subsystem > C:\PROGRA~1\WINHUG~1\UNINST~1.EXE > The NTVDM CPU has encountered an illegal instruction. > }}} > > I am using Windows XP SP2 using NTFS. My "Program Files" directory has very strict ACL permissions (only Administrators can modify anything). > > It seems strange that the uninstaller is a 16-bit console application. -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Tue Nov 13 12:56:46 2007 From: trac at galois.com (Hugs) Date: Tue Nov 13 12:53:26 2007 Subject: [Hugs] #80: A curious stack overflow problem Message-ID: <045.6c93537d44c1cbc5fe090879b58d8b23@localhost> #80: A curious stack overflow problem --------------------+------------------------------------------------------- Reporter: guest | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: hugs | Version: 200609 Keywords: | --------------------+------------------------------------------------------- Suppose I define > natmin :: [Int] -> Int > natmin = foldr1 min > where min x y = if x==0 || x<=y then x else y I would expect the same behaviour from natmin ([1..10000] ++ [0..]) as from or ([False | i <- [1..10000]] ++ [True | i <- [1..]]) But the first gives stack overflow, and the second doesn't. The problem does not exist with GHCi. Richard Bird bird@comlab.ox.ac.uk -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Wed Nov 14 03:00:00 2007 From: trac at galois.com (Hugs) Date: Wed Nov 14 02:56:40 2007 Subject: [Hugs] #80: A curious stack overflow problem In-Reply-To: <045.6c93537d44c1cbc5fe090879b58d8b23@localhost> References: <045.6c93537d44c1cbc5fe090879b58d8b23@localhost> Message-ID: <054.86c5f3ff49de90de4df04ede78d6cd24@localhost> #80: A curious stack overflow problem ----------------------+----------------------------------------------------- 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: The behaviour is standard outermost evaluation, driven by the different properties of min and (||). The same thing happens with ghci, if you make the first list a bit longer. (The infinite lists make no difference: singleton lists [1] or [True] give the same effect.) -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From ndm at cs.york.ac.uk Tue Nov 27 16:04:06 2007 From: ndm at cs.york.ac.uk (Neil Mitchell) Date: Tue Nov 27 16:00:01 2007 Subject: Fwd: Question In-Reply-To: References: Message-ID: <404396ef0711271304p1dddb5fbk1dfc25745f565f4d@mail.gmail.com> Hi A user asked: --------------------------------------------------- I installed WinHugs on a Winodw Xp machine went into settings and set the search path to be(shown exactly as :set is listing it). Search path : -P.;{Hugs}\packages\*;c:\haskell I am keeping my fact.hs files(well my one and only at this time) in c:\haskell. Hugs> :load fact.hs ERROR - Unable to open file "fact.hs" Hugs> :load "c:\haskell\fact.hs" Fact> --------------------------------------------------- I realise that that isn't expected to work (the search path appears to be only for modules not files), but I do wonder why not. An equivalent feature request is: :l List -- works fine :l List.hs -- doesn't Thanks Neil