From ndmitchell at gmail.com Sat Feb 10 14:55:33 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Feb 10 14:49:56 2007 Subject: Cannot import List(intersperse), possibly bug #17 Message-ID: <404396ef0702101155v7fa55043kea1a976e7abbd813@mail.gmail.com> Hi I don't seem to be able to do: import List(intersperse) in Hugs Sep 2006 - it says: ERROR file:.\Taut.hs - Unknown entity "intersperse" imported from module "List" import Data.List(intersperse) works fine This issue breaks SmallCheck This looks similar to issue #17 in the bug tracker, but more general: http://hackage.haskell.org/trac/hugs/ticket/17 Thanks Neil From ross at soi.city.ac.uk Sun Feb 11 03:57:01 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Feb 11 03:51:24 2007 Subject: Cannot import List(intersperse), possibly bug #17 In-Reply-To: <404396ef0702101155v7fa55043kea1a976e7abbd813@mail.gmail.com> References: <404396ef0702101155v7fa55043kea1a976e7abbd813@mail.gmail.com> Message-ID: <20070211085701.GA3475@soi.city.ac.uk> On Sat, Feb 10, 2007 at 07:55:33PM +0000, Neil Mitchell wrote: > I don't seem to be able to do: > > import List(intersperse) > > in Hugs Sep 2006 - it says: > > ERROR file:.\Taut.hs - Unknown entity "intersperse" imported from module > "List" Odd. It works fine for me (under Linux). From ndmitchell at gmail.com Sun Feb 11 13:15:59 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Feb 11 13:10:21 2007 Subject: Cannot import List(intersperse), possibly bug #17 In-Reply-To: <20070211085701.GA3475@soi.city.ac.uk> References: <404396ef0702101155v7fa55043kea1a976e7abbd813@mail.gmail.com> <20070211085701.GA3475@soi.city.ac.uk> Message-ID: <404396ef0702111015mdb2859fobc486faaa57c923a@mail.gmail.com> Hi > > I don't seem to be able to do: > > > > import List(intersperse) > > > > in Hugs Sep 2006 - it says: > > > > ERROR file:.\Taut.hs - Unknown entity "intersperse" imported from module > > "List" > > Odd. It works fine for me (under Linux). Works fine on my home machine as well, no idea what the difference between the two systems is. I'll reinstall my work machine and see if this still reoccurs. Thanks Neil From iavor.diatchki at gmail.com Sun Feb 11 22:30:12 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Feb 11 22:24:32 2007 Subject: Scoping bug in module system implementation Message-ID: <5ab17e790702111930t2e11bc9fm8f681934e37e5f42@mail.gmail.com> Hello, Consider the following two modules: > module A where x = True > module B where > import A > x = 'a' > test = let x = "" in x Upon loading "B", Hugs (Sept 2006) erroneously reports: Ambiguous variable occurrence "x" *** Could refer to: B.x A.x The variable "x" in the definition of "test" refers to the locally defined "x", and not the top-level name, so there is no ambiguity. -Iavor From ross at soi.city.ac.uk Mon Feb 12 05:47:46 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 12 05:42:08 2007 Subject: Scoping bug in module system implementation In-Reply-To: <5ab17e790702111930t2e11bc9fm8f681934e37e5f42@mail.gmail.com> References: <5ab17e790702111930t2e11bc9fm8f681934e37e5f42@mail.gmail.com> Message-ID: <20070212104746.GA11787@soi.city.ac.uk> On Sun, Feb 11, 2007 at 07:30:12PM -0800, Iavor Diatchki wrote: > Consider the following two modules: > > >module A where x = True > > >module B where > >import A > >x = 'a' > >test = let x = "" in x > > Upon loading "B", Hugs (Sept 2006) erroneously reports: > Ambiguous variable occurrence "x" > *** Could refer to: B.x A.x Thanks for the neat report. This is nor fixed in CVS. BTW, feel free to use the bug tracker. From trac at galois.com Tue Feb 13 07:02:21 2007 From: trac at galois.com (Hugs) Date: Tue Feb 13 06:56:37 2007 Subject: [Hugs] #54: INTERNAL ERROR: build Message-ID: <061.153c1cc27ae5c4eb0ce045718bf41284@localhost> #54: INTERNAL ERROR: build --------------------------+------------------------------------------------- Reporter: guest | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: build system | Version: current Keywords: | --------------------------+------------------------------------------------- Main> fvsp 450 INTERNAL ERROR: build Please report this Hugs bug to http://hackage.haskell.org/trac/hugs //code pots :: Num a => a -> [a] pots x = scanl (*) 1 (repeat x) factoriales :: [Integer] factoriales = scanl (*) 1 [1..] fvsp :: Integer -> Int fvsp n = length (takeWhile not (zipWith (<) (pots n) factoriales)) -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Tue Feb 13 08:13:23 2007 From: trac at galois.com (Hugs) Date: Tue Feb 13 08:07:36 2007 Subject: [Hugs] #54: INTERNAL ERROR: build In-Reply-To: <061.153c1cc27ae5c4eb0ce045718bf41284@localhost> References: <061.153c1cc27ae5c4eb0ce045718bf41284@localhost> Message-ID: <070.5c639ffc66cc914ba5d3d67d1933d1f2@localhost> #54: INTERNAL ERROR: build ---------------------+------------------------------------------------------ Reporter: guest | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: hugs | Version: current Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by ross): * component: build system => hugs Comment: You didn't mention which version of Hugs you're using, or on what system. I'm unable to reproduce this with the Sep 2006 release under Linux. -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From ndmitchell at gmail.com Thu Feb 15 18:12:04 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 15 18:06:10 2007 Subject: Hugs does not free file handles on stop pressed Message-ID: <404396ef0702151512x74743f37l6ba3c9329841c667@mail.gmail.com> Hi, If you abort a Hugs computation which has an open file handle, it remains open. I.e. do a writeFile "filename.txt" (show (1, last [1..])), press Stop or Ctrl+C and the file handle remains open. However, doing "print 1", or just about anything as the next operation, results in the file handle being closed after that command aborts. I suspect that this means there is some routine out there that closes the file handles and does the tidy up - if it could be invoked on abort that would be handy. Thanks Neil From claus.reinke at talk21.com Thu Feb 15 18:28:26 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Feb 15 18:26:16 2007 Subject: graceful degradation in the case of errors References: <404396ef0702151512x74743f37l6ba3c9329841c667@mail.gmail.com> Message-ID: <015601c75159$813baf20$a3007ad5@cr3lt> something has been bugging me about recent windows hugs versions, but I always forget to report it, and Neil's mentioning file handles reminded me: 1. when any source module has an error on load, Hugs stops in the middle of that module, being entirely useless until I comment out the offending lines, save and reload, or unload everything but the Prelude. I'd prefer if Hugs reported the error in the offending module, but did not commit to loading it unless successful. In other words, loading modules ought to be a series of transactions: - start transaction loading module X - if error occurs, report, abort current transaction, and stop loading - if free of errors, commit to loading module X, and continue loading the first thing I tend to try when I get an error on load is to inspect the types/behaviour of some of the things loaded before the error, or try to figure out what I've misunderstood about the things used at the error location. but with the current arrangement, I can't use my Hugs session to do any of that. 2. problem 1 is made worse because minhugs seems to do an implicit load (at the next command) when the file changes on disc. this means that I can't save edits in the editor unless I'm sure the code loads without errors, and it also means that I can't use my Hugs session independently of my editing. I'm pretty sure 2 is recent, 1 may have been standard Hugs behaviour for some time. but both are rather annoying, imho. thanks, claus From ndmitchell at gmail.com Thu Feb 15 18:39:11 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 15 18:33:20 2007 Subject: graceful degradation in the case of errors In-Reply-To: <015601c75159$813baf20$a3007ad5@cr3lt> References: <404396ef0702151512x74743f37l6ba3c9329841c667@mail.gmail.com> <015601c75159$813baf20$a3007ad5@cr3lt> Message-ID: <404396ef0702151539l39eddf7dwacf0d6004d6ec03e@mail.gmail.com> Hi Claus, > 1. when any source module has an error on load, Hugs stops in the middle > of that module, being entirely useless until I comment out the offending > lines, save and reload, or unload everything but the Prelude. I find that annoying too, and generally keep a separate WinHugs copy open at all times to do :t commands when things break. I thought this might be a big architectural change, or I would have suggested it. > 2. problem 1 is made worse because minhugs seems to do an implicit > load (at the next command) when the file changes on disc. WinHugs always had this ability, but it was turned off by default. I find this very useful, and while its annoying to some people, I find that for beginners (esp those without loads of computer experience) if you have this turned off then they get loads of issues with evaluating code which is different to that which is saved. One term demonstrating programming and watching people make this error will convince you this should be the default of everything! Kent University even wrote their own editor/interpreter so the students can't forget to save before evaluating. That said, its still just an option: File / Options / Compile Time / Automatically Reload Modified Files Thanks Neil From claus.reinke at talk21.com Thu Feb 15 19:11:06 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Feb 15 19:05:17 2007 Subject: graceful degradation in the case of errors References: <404396ef0702151512x74743f37l6ba3c9329841c667@mail.gmail.com><015601c75159$813baf20$a3007ad5@cr3lt> <404396ef0702151539l39eddf7dwacf0d6004d6ec03e@mail.gmail.com> Message-ID: <016401c7515e$f4d6c500$a3007ad5@cr3lt> Hi Neil, >> 1. when any source module has an error on load, Hugs stops in the middle >> of that module, being entirely useless until I comment out the offending >> lines, save and reload, or unload everything but the Prelude. > > I find that annoying too, and generally keep a separate WinHugs copy > open at all times to do :t commands when things break. I thought this > might be a big architectural change, or I would have suggested it. if it was haskell, one could just keep a list of successfully loaded modules, and reload only those after an error message. but even with Mark's functional c coding, c isn't haskell, so you might be right - being in c certainly keeps me from looking into it;-). I just thought I'd report it for the record, and for the brave folks who keep the innards of Hugs up to date. > that for beginners (esp those without loads of computer experience) if > you have this turned off then they get loads of issues with evaluating > code which is different to that which is saved. One term demonstrating > programming and watching people make this error will convince you this > should be the default of everything! I don't think so!-) I've been there with all kinds of other computing issues for beginners, and even non-beginners. yes, it is annoying if one spends time debugging non-bugs because of invisible version mismatch (meta-programming adds new levels to that kind of fun..). what I would like to see instead is winhugs changing colour or giving a message if the loaded version is not the newest version on disk (that is also more or less standard behaviour in good editors, I think). a gui ought to assist, not to dictate presumably better behaviour - beware of the paper clip:-) that way, beginners, teachers, and advanced programmers out of their depth have a visual reminder that they are not working with the newest version, but they remain in control (eg, I sometimes use hugs to experiment with the code I'm putting together in the editor, referring to definitions already tested and successfully loaded in the old Hugs session, and I tend to save the editor session before I switch windows; autoload forces me either to skip the save, or to interrupt my train of thought to edit the current fragment into something loadable). that said, having the option of automatic reload is probably useful, and many will just select it for themselves or for their students. but for many others, old habits die hard!-) > That said, its still just an option: > File / Options / Compile Time / Automatically Reload Modified Files or :set -A, which I missed. thanks, now switched off. one problem solved! claus From ndmitchell at gmail.com Thu Feb 15 20:01:01 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 15 19:55:07 2007 Subject: graceful degradation in the case of errors In-Reply-To: <016401c7515e$f4d6c500$a3007ad5@cr3lt> References: <404396ef0702151512x74743f37l6ba3c9329841c667@mail.gmail.com> <015601c75159$813baf20$a3007ad5@cr3lt> <404396ef0702151539l39eddf7dwacf0d6004d6ec03e@mail.gmail.com> <016401c7515e$f4d6c500$a3007ad5@cr3lt> Message-ID: <404396ef0702151701r4f591a8au873afb5b4133f5d3@mail.gmail.com> Hi > if it was haskell, one could just keep a list of successfully loaded modules, > and reload only those after an error message. If it was well written in Haskell :) Haskell makes it harder to write bad code, but it doesn't make it that easy to change things, usually. > I just thought I'd report it for the record, and for the > brave folks who keep the innards of Hugs up to date. One thing I noticed reading through the recent History of Haskell paper, all the compilers that have fallen by the way side have done so because they were not written in Haskell or had a dependency on a different language such as Scheme. I think its very impressive that Hugs is still such a powerful and well maintained system! > what I would like to see instead is winhugs changing colour or giving a message > if the loaded version is not the newest version on disk (that is also more or > less standard behaviour in good editors, I think). a gui ought to assist, not > to dictate presumably better behaviour - beware of the paper clip:-) It would be nice, I'll see if it is easily doable - depends how the reload code is structured. Thanks Neil From ross at soi.city.ac.uk Fri Feb 16 08:58:07 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Feb 16 08:52:19 2007 Subject: Hugs does not free file handles on stop pressed In-Reply-To: <404396ef0702151512x74743f37l6ba3c9329841c667@mail.gmail.com> References: <404396ef0702151512x74743f37l6ba3c9329841c667@mail.gmail.com> Message-ID: <20070216135807.GB8639@soi.city.ac.uk> On Thu, Feb 15, 2007 at 11:12:04PM +0000, Neil Mitchell wrote: > If you abort a Hugs computation which has an open file handle, it > remains open. I.e. do a writeFile "filename.txt" (show (1, last > [1..])), press Stop or Ctrl+C and the file handle remains open. > > However, doing "print 1", or just about anything as the next > operation, results in the file handle being closed after that command > aborts. I suspect that this means there is some routine out there that > closes the file handles and does the tidy up - if it could be invoked > on abort that would be handy. It's done by the garbage collector. It was invoked, but there were still references to the handle at that time. Now fixed in CVS. From trac at galois.com Tue Feb 20 15:30:58 2007 From: trac at galois.com (Hugs) Date: Tue Feb 20 15:24:48 2007 Subject: [Hugs] #55: Ctrl+E/L/R in WinHugs changes the text alignment Message-ID: <061.37fe6b223bff2e098cc427789e2be99a@localhost> #55: Ctrl+E/L/R in WinHugs changes the text alignment ---------------------+------------------------------------------------------ Reporter: neil | Owner: neil Type: defect | Status: new Priority: minor | Milestone: Component: winhugs | Version: 200609 Keywords: | ---------------------+------------------------------------------------------ In WinHugs pressing Ctrl+E at the edit prompt will centre the text. -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Tue Feb 20 15:32:19 2007 From: trac at galois.com (Hugs) Date: Tue Feb 20 15:26:09 2007 Subject: [Hugs] #56: Print the evaluation count in the status bar Message-ID: <061.a5108a63c9513abf6b06e599d5f7a8c0@localhost> #56: Print the evaluation count in the status bar ---------------------+------------------------------------------------------ Reporter: neil | Owner: neil Type: defect | Status: new Priority: minor | Milestone: Component: winhugs | Version: 200609 Keywords: | ---------------------+------------------------------------------------------ Always print the evaluation count in the status bar, its plenty of space and currently dead space otherwise. Also means we can have one less option. -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Tue Feb 20 15:33:22 2007 From: trac at galois.com (Hugs) Date: Tue Feb 20 15:27:14 2007 Subject: [Hugs] #57: Display "Files loaded do not match those on disk" message if this is true Message-ID: <061.1a0ffc05b8c2e73a75c9494644b809dd@localhost> #57: Display "Files loaded do not match those on disk" message if this is true -------------------------+-------------------------------------------------- Reporter: neil | Owner: neil Type: enhancement | Status: new Priority: minor | Milestone: Component: winhugs | Version: 200609 Keywords: | -------------------------+-------------------------------------------------- Display a warning that the files on disk have changed, if this is readily possible. Claus would like this. -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Tue Feb 20 15:38:27 2007 From: trac at galois.com (Hugs) Date: Tue Feb 20 15:32:18 2007 Subject: [Hugs] #56: Print the evaluation count in the status bar In-Reply-To: <061.a5108a63c9513abf6b06e599d5f7a8c0@localhost> References: <061.a5108a63c9513abf6b06e599d5f7a8c0@localhost> Message-ID: <070.32832d7d7d803856ada5da2e530a7da3@localhost> #56: Print the evaluation count in the status bar --------------------------+------------------------------------------------- Reporter: neil | Owner: neil Type: enhancement | Status: new Priority: minor | Milestone: Component: winhugs | Version: 200609 Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by neil): * type: defect => enhancement -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From trac at galois.com Tue Feb 20 16:20:26 2007 From: trac at galois.com (Hugs) Date: Tue Feb 20 16:14:18 2007 Subject: [Hugs] #57: Display "Files loaded do not match those on disk" message if this is true In-Reply-To: <061.1a0ffc05b8c2e73a75c9494644b809dd@localhost> References: <061.1a0ffc05b8c2e73a75c9494644b809dd@localhost> Message-ID: <070.9a1fa93a5ff284affb6fa1b3fb308fb9@localhost> #57: Display "Files loaded do not match those on disk" message if this is true --------------------------+------------------------------------------------- Reporter: neil | Owner: neil Type: enhancement | Status: new Priority: minor | Milestone: Component: winhugs | Version: 200609 Resolution: | Keywords: --------------------------+------------------------------------------------- Comment (by claus): to expand slightly: winhugs has an option to automatically reload files when they have changed on disk. instead of the reload, i'd just like to see a visual indication (modified prompt/frame colour/printed message). should be the same code? -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell From Dave at haskell.org Sun Feb 25 16:58:33 2007 From: Dave at haskell.org (Dave@haskell.org) Date: Sun Feb 25 16:52:07 2007 Subject: SOE Message-ID: <20070225215205.A70743244C1@www.haskell.org> I don't know if this is a bug, but... When I start hugs98 (March 2005) and then attempt to load all the SOE source modules, Hugs.Base> :load Animation.lhs Code.html Draw.lhs Fal.lhs MDL.lhs Memo1.lhs Music.lhs Perform.lhs Picture.lhs Reactimate.lhs Region.lhs Robot.lhs Shape.lhs SimpleGraphics.lhs Snowflake.lhs Streams.lhs Trees.lhs I get two errors: The first error is that the module Win32misc is not found. I deleted all references to Win32misc from the SOE files (I'm running on OpenBSD) and that problem went away. Then I got another error: ROR "./Picture.lhs":24 - Undefined type constructor "RGB" Where is this constructor defined? Thanks, Dave Feustel From lifemk2 at gmail.com Tue Feb 27 12:17:40 2007 From: lifemk2 at gmail.com (Tom Purnell) Date: Tue Feb 27 12:19:02 2007 Subject: Undefined variable bug References: <20040110223816.GA29372@serpens.ins.cwi.nl> Message-ID: John Tromp cwi.nl> writes: > > I just found out that I can circumvent the problem by > adding a line > > import Char > > to my loaded file. > > regards, > -john > Just wanted to say thank-you for saving me a lot of googling and trying to work out what stupid mistake I was making in my first foray into the world of Haskell / Hugs Tom From trac at galois.com Tue Feb 27 12:59:50 2007 From: trac at galois.com (Hugs) Date: Tue Feb 27 12:53:18 2007 Subject: [Hugs] #58: WinHugs can't paste into an interact session Message-ID: <061.aac5f37ca85eb3b3270761c84303ea80@localhost> #58: WinHugs can't paste into an interact session -------------------------+-------------------------------------------------- Reporter: neil | Owner: neil Type: enhancement | Status: new Priority: minor | Milestone: Component: winhugs | Version: 200609 Keywords: | -------------------------+-------------------------------------------------- > interact id {hit ctrl+v, or paste} Nothing happens, would be nice if it sent the characters in the paste buffer to the getChar function. Reported by Tom Shackell -- Ticket URL: Hugs Hugs 98, an interpreter for Haskell