Hi,
I've been working on rewriting WinHugs recently, to make it work and
to make it more Windows compliant. I have put a screenshot up at
http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php, and my todo
list is http://www.haskell.org/hawiki/NeilMitchell/HugsNotes which
includes the bugs I'm working on, and a list of the good and bad
points about the rewrite. I have a version which I am now using as my
primary development environment. Its stable and reliable. Out of the
bugs mentioned in the Todo list only the options dialog not giving
people -/+98 and other super-haskell options is real enough to stop
people using it, if they want non-standard haskell. All the others are
very minor.
While I'm rewriting it I've tried to reduce the amount Hugs knows
about WinHugs. For example, I've removed #include
On Wed, Aug 31, 2005 at 03:41:50PM +0100, Neil Mitchell wrote:
I've been working on rewriting WinHugs recently, to make it work and to make it more Windows compliant. I have put a screenshot up at http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php, and my todo list is http://www.haskell.org/hawiki/NeilMitchell/HugsNotes which includes the bugs I'm working on, and a list of the good and bad points about the rewrite. I have a version which I am now using as my primary development environment. Its stable and reliable.
Sounds good (though the loss of interact is a worry). Does the new version work with Win95?
Out of the bugs mentioned in the Todo list only the options dialog not giving people -/+98 and other super-haskell options is real enough to stop people using it, if they want non-standard haskell. All the others are very minor.
This is no worse than the old WinHugs, though, isn't it?
Once the first modifications are made to the hugs directory, the existing winhugs code will be dead forever, the two code bases are sufficiently different that its unlikely to be able to run them side by side off the same hugs code, without some effort (not too much, but I can't imagine anyone will want to do it).
With this in mind, how would be best to go about merging in WinHugs2?
1) Delete WinHugs and start from scratch. 2) Make a WinHugs2 directory, and keep WinHugs around for the past, accepting it probably won't build. 3) Find someone who wants to resurect the dead WinHugs1... (maybe)
Lets do 1). The past is recorded by CVS.
And also when does WinHugs2 integration want to take place?
How about right now? As for documentation, It would probably suffice to give a screenshot and a bit of advertising, as the rest is presumably self-explanatory. You could check the statements in http://cvs.haskell.org/Hugs/pages/hugsman/windows.html#sect8.2 but don't use any of the text from there.
Sounds good (though the loss of interact is a worry). Yes, interact is an unfortunate casualty. I hope to be able to put it back at some point, but it will be quite a bit of work, and involves me understanding more of how hugs works.
Does the new version work with Win95? Maybe, I don't know anyone who has Win95, so its a bit hard to test. If it doesn't, then I should be able to fix it easily enough. I have avoided API's which aren't explicitly supported on Win95.
giving people -/+98 and other super-haskell options is real enough to stop people using it, if they want non-standard haskell. All the others are very minor. This is no worse than the old WinHugs, though, isn't it?
It is worse. The old version lets you change things like overlapping instances etc, the new one doesn't. You can still use :set to make the alterations. Its intended to add these back, and should be relatively easy - its just because I stick to standard haskell its not been necessary.
And also when does WinHugs2 integration want to take place?
How about right now?
Sounds good. Maybe I could send a big zip with all the files for the WinHugs directory and then send smaller, self-contained patches for the hugs directory over about a week? I guess people will want to look at the hugs patches closer, and some of them could do with slight tidy ups. With regards to teh documentation at http://cvs.haskell.org/Hugs/pages/hugsman/windows.html#sect8.2:
It also stores options in a .ini file. It stores options in the registry, and has done for a while now, several years at least.
In addition, the current implementation uses a compute-intensive polling process to detect certain events, and this can incur a fairly substantial performance penalty. For these reasons, the Hugs for Windows front-end is not recommended for work on large projects.
No polling anymore, which is why interact broke, and one of the reasons for a speed increase. Thanks Neil
On Wed, Aug 31, 2005 at 04:44:00PM +0100, Neil Mitchell wrote:
Sounds good. Maybe I could send a big zip with all the files for the WinHugs directory and then send smaller, self-contained patches for the hugs directory over about a week?
OK. Private mail will do for the zip file.
Hi, http://www-users.york.ac.uk/~ndm500/temp/ In this directory are two zip files: winhugs.zip, this is the complete contents of src/winhugs. Everything in the existing directory needs to be deleted first, then this zip extracted in its place. There are a few files that survived intact, about 3, but not many. Most files are deleted or brand new, a few are modified. resource.zip, this is for src/winhugs/resource. Leave the existing directory as is, and extract these files over the top. Some are additions, some are replacements. There is relatively little change to this. Perhaps it would be a good idea to do a CVS Tag before making these changes, to make it easier if anyone needs to get back before this change happens. With these changes the things that are lacking to build WinHugs are project files (mine are located outside the CVS tree entirely, so I'll move them in as a patch in a bit) and some patches to the Hugs source code, which I'll send in easily digestible chunks over the next week. Thanks Neil
participants (2)
-
Neil Mitchell -
Ross Paterson