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
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
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
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
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
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.
participants (3)
-
Claus Reinke -
Neil Mitchell -
Ross Paterson