Hi, I've compiled up all the WinHugs goodies, including the new installer, into an installable package. Its available at http://www-users.york.ac.uk/~ndm500/temp/WinHugs_2005-10-06.exe [17Mb]. If anyone wants to try it out, i'd be greateful to hear any feedback! http://www.haskell.org/hawiki/NeilMitchell/HugsNotes lists all the things that are "wrong" with it. The only big thing is no uninstaller, and since its installation is basically creating a directory, thats not so much of a problem (it can be uninstalled by hand with the delete key in about 10 seconds). Comments, complaints, bug reports all welcome. If you just download it and it all works fine I'd still be interested in hearing that. Thanks Neil
I tried WinHugs and found the following problems:
- I am using TextPad but it takes too long time to open TextPad from Hugs.
- In the module manager the "Add" button does nothing, or at least I
don't know how to use it.
- Prelude.getLine function works but I can't see the characters which
I am typing in.
- Prelude.interact starts an infinite loop and I can type in what ever
I want but the interactive function is never called. I tried "interact
id" expression.
Krasimir
2005/10/6, Neil Mitchell
Hi,
I've compiled up all the WinHugs goodies, including the new installer, into an installable package. Its available at http://www-users.york.ac.uk/~ndm500/temp/WinHugs_2005-10-06.exe [17Mb]. If anyone wants to try it out, i'd be greateful to hear any feedback! http://www.haskell.org/hawiki/NeilMitchell/HugsNotes lists all the things that are "wrong" with it. The only big thing is no uninstaller, and since its installation is basically creating a directory, thats not so much of a problem (it can be uninstalled by hand with the delete key in about 10 seconds).
Comments, complaints, bug reports all welcome. If you just download it and it all works fine I'd still be interested in hearing that.
Thanks
Neil _______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
- I am using TextPad but it takes too long time to open TextPad from Hugs. It opens textpad using dde, and if you system has a badly behaved dde
Hi, program running (one that accepts the incomming dde calls but does not respond) then it requires a dde handshake timeout to continue - which typically takes about 20 seconds. I use textpad and its all fine, so I suspect this is a problem with your system and not with hugs. If you change the options to use c:\program files\textpad\textpad.exe to open the thing it will open faster, but may open multiple instances. Maybe upgrading textpad might help? Does the issue manifest itself when the text editor is set to notepad? [see options]
- In the module manager the "Add" button does nothing, or at least I don't know how to use it. Ah, the module manager. I have no idea what it did before and even less idea what it does now. Did you used to use the module manager? I'm inclined to kill it but left it for compatability reasons.
- Prelude.getLine function works but I can't see the characters which I am typing in. This seems to be by design, and a feature of hugs, my supervisor distributes a patch which changes this in the York uni copy of hugs. If this is not intentional can someone please say and i'll happily change the behaviour.
- Prelude.interact starts an infinite loop and I can type in what ever I want but the interactive function is never called. I tried "interact id" expression. See prelude.getLine. It does execute, but it doesn't echo what you type. i.e. when you type "a", the id function returns a, which is what you see, but you don't see the original a you type. This is the same as teh previous complaint, and if I fix one the other will have the same fix.
So basically: 1) DDE with textpad, seems like its outside my control 2) getChar doesn't echo its input, should it? Thanks for your help Neil
2005/10/6, Neil Mitchell
Hi,
- I am using TextPad but it takes too long time to open TextPad from Hugs. It opens textpad using dde, and if you system has a badly behaved dde program running (one that accepts the incomming dde calls but does not respond) then it requires a dde handshake timeout to continue - which typically takes about 20 seconds. I use textpad and its all fine, so I suspect this is a problem with your system and not with hugs. If you change the options to use c:\program files\textpad\textpad.exe to open the thing it will open faster, but may open multiple instances. Maybe upgrading textpad might help? Does the issue manifest itself when the text editor is set to notepad? [see options]
NotePad is working fine. I the problem is that you are using DDEOPN32.EXE. I tried to associate .txt extension to TextPad and when I am opening any text file from Windows Explorer then it is working fine. From Tools/Folder Options menu in Windows Explorer you can see that it is launching TextPad directly through DDE. Some times ago I was using TextPad in this way and it was working fine. Unfortunately currently I can't remember the details. I think that you should use the DDE API directly.
- In the module manager the "Add" button does nothing, or at least I don't know how to use it. Ah, the module manager. I have no idea what it did before and even less idea what it does now. Did you used to use the module manager? I'm inclined to kill it but left it for compatability reasons.
It was a long time since I used Hugs for the last time. Usually I am using GHC but I was curious to see how the new WinHugs looks like. The "Add" button should open a dialog where I should be able to select a new Haskell module to load in Hugs.
- Prelude.getLine function works but I can't see the characters which I am typing in. This seems to be by design, and a feature of hugs, my supervisor distributes a patch which changes this in the York uni copy of hugs. If this is not intentional can someone please say and i'll happily change the behaviour.
It is strange and it is inconsistent with GHC.
- Prelude.interact starts an infinite loop and I can type in what ever I want but the interactive function is never called. I tried "interact id" expression. See prelude.getLine. It does execute, but it doesn't echo what you type. i.e. when you type "a", the id function returns a, which is what you see, but you don't see the original a you type. This is the same as teh previous complaint, and if I fix one the other will have the same fix.
ok. Cheers, Krasimir
NotePad is working fine. I the problem is that you are using DDEOPN32.EXE. This is provided by TextPad, see their FAQ for workarounds, you
Hi, probably have Outlook 2000 in workgroup mode or Lotus Notes. If you manually edit the editor command to "C:\Program Files\TextPad 4\TextPad.exe -s %s(%d)" (select custom under editors), it should work again. I think this is the best solution (not sure why dde seems to be prefered), so will fix this for the next beta. I haven't found a command line flag reference for textpad, so have no idea what -s does...
"Add" button should open a dialog where I should be able to select a new Haskell module to load in Hugs. Yep, the old version of WinHugs did that, will patch it.
Regarding interact and getLine, the behaviour is unchanged from previous versions of WinHugs, and Hugs on Windows. However, older versions on Solaris do echo the input. Looking at GHCi, it echos by line, not by character. If someone gives me a spec, or at least a hint as to what the right behaviour is I will implement it :) Thanks - thats at least 2 genuine bugs and one bizare behaviour identified! Neil
On Thu, Oct 06, 2005 at 04:59:00PM +0100, Neil Mitchell wrote:
Regarding interact and getLine, the behaviour is unchanged from previous versions of WinHugs, and Hugs on Windows. However, older versions on Solaris do echo the input. Looking at GHCi, it echos by line, not by character. If someone gives me a spec, or at least a hint as to what the right behaviour is I will implement it :)
Under Unix, echoing is left to the OS. The usual OS setting is to echo by characters. I thought plain hugs running in a Windows console window did this too, but haven't checked. (Older versions of Hugs turned off OS echoing and echoed to stdout themselves for getChar but not interact, which caused wierd behaviour if stdin and/or stdout were redirected.) So I'd prefer to have characters echoed as they're typed, but don't know what is the cleanest way to achieve this under WinHugs. It's also convenient that characters are line-buffered by default under Unix, because this allows users to correct their input before they hit return. On the downside, getChar doesn't execute as early as some might expect. Again no clue regarding WinHugs, but if it's messy, this isn't as important as echoing. Echoing can be controlled from within Haskell programs using System.IO.hSetEcho (calls setEchoTerminal() in machdep.c), and buffering with System.IO.hSetBuffering (calls setBuffTerminal() in machdep.c).
Under Unix, echoing is left to the OS. The usual OS setting is to echo by characters. I thought plain hugs running in a Windows console window did this too, but haven't checked. It doesn't.
So I'd prefer to have characters echoed as they're typed, but don't know what is the cleanest way to achieve this under WinHugs. There are two solutions:
1) Add it to WinHugs, easy enough, just make the typed character handler also write a character (currently it deliberately blocks it). This won't fix it in command line hugs. 2) Add it to Hugs, on windows platform explicitly do a getchar, putchar. WinHugs would receive this fix automatically because it traps putchar. As for line buffering, this should be something specified by the standard. Lines can be buffered with a unlines . map (reverse . reverse) . lines style construct, and this was how I was taught to use interact with buffering. Neil
On Thu, Oct 06, 2005 at 07:26:21PM +0100, Neil Mitchell wrote:
Under Unix, echoing is left to the OS. The usual OS setting is to echo by characters. I thought plain hugs running in a Windows console window did this too, but haven't checked. It doesn't.
How odd. I just tried plain hugs (both a mingw-compiled version and the VC-compiled one you sent me) from the explorer in NT4 and it worked as I'd hoped it would: Hugs> getLine >>= print hello "hello" i.e. it echoed each character as I typed it, and I was able to correct the input with backspace before hitting return. Same for interact.
Hi,
Ok, my bad - it was working on windows console all along but with the
line buffering which confused me. This patch implements echoing the
character for WinHugs. It doesn't buffer lines, but its probably
enough for now.
Thanks
Neil
On 10/7/05, Ross Paterson
On Thu, Oct 06, 2005 at 07:26:21PM +0100, Neil Mitchell wrote:
Under Unix, echoing is left to the OS. The usual OS setting is to echo by characters. I thought plain hugs running in a Windows console window did this too, but haven't checked. It doesn't.
How odd. I just tried plain hugs (both a mingw-compiled version and the VC-compiled one you sent me) from the explorer in NT4 and it worked as I'd hoped it would:
Hugs> getLine >>= print hello "hello"
i.e. it echoed each character as I typed it, and I was able to correct the input with backspace before hitting return. Same for interact.
_______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
On Thu, Oct 06, 2005 at 02:06:37PM +0100, Neil Mitchell wrote:
I've compiled up all the WinHugs goodies, including the new installer, into an installable package. Its available at http://www-users.york.ac.uk/~ndm500/temp/WinHugs_2005-10-06.exe [17Mb]. If anyone wants to try it out, i'd be greateful to hear any feedback! http://www.haskell.org/hawiki/NeilMitchell/HugsNotes lists all the things that are "wrong" with it. The only big thing is no uninstaller, and since its installation is basically creating a directory, thats not so much of a problem (it can be uninstalled by hand with the delete key in about 10 seconds).
Comments, complaints, bug reports all welcome. If you just download it and it all works fine I'd still be interested in hearing that.
The installer requires MSVCR71.dll. I understand that this is available at no charge with the MVC kit 2003, but that this is only for Win2000 and later.
The installer requires MSVCR71.dll. I understand that this is available at no charge with the MVC kit 2003, but that this is only for Win2000 and later.
I'm pretty sure its available for Windoes 95 and later, and can be redistributed by anyone. Its a result of compiling with Visual Studio 2003, nothing fundamentally to do with the code. I'll recompile the installer with Visual Studio 6, that will make it depend on a different version of the runtime which is installed on practically every computer, and is certainly available for installing on Windows any version. Thanks Neil
The installer requires MSVCR71.dll. I understand that this is available at no charge with the MVC kit 2003, but that this is only for Win2000 and later.
This patch changes the project file to build static versions of the required dll's into the program. This increases the base installer size by 30Kb, but removes requirements on any dll's beyond those provided by standard windows 95 and above. It also toggles on a pile of size optimisations which get back 5Kb of that increase, so the end installer size is 55Kb, and entirely any windows compatible. I'll think about bundling an appropriate copy of MSVCR71.dll with WinHugs.exe in the installer, will fix that in the next few days. Thanks Neil
On Mon, Oct 10, 2005 at 03:49:51PM +0100, Neil Mitchell wrote:
I'll think about bundling an appropriate copy of MSVCR71.dll with WinHugs.exe in the installer, will fix that in the next few days.
According to the EULA http://msdn.microsoft.com/visualc/vctoolkit2003/eula.aspx, you'll need a click-wrap licence around it.
According to the EULA http://msdn.microsoft.com/visualc/vctoolkit2003/eula.aspx, you'll need a click-wrap licence around it.
Thats for the Visual Studio toolkit - the freely downloadable compiler and linker from Microsoft. I am using the full Visual Studio package, which doesn't have those restrictions.
On Tue, Oct 11, 2005 at 10:56:50AM +0100, Neil Mitchell wrote:
According to the EULA http://msdn.microsoft.com/visualc/vctoolkit2003/eula.aspx, you'll need a click-wrap licence around it.
Thats for the Visual Studio toolkit - the freely downloadable compiler and linker from Microsoft. I am using the full Visual Studio package, which doesn't have those restrictions.
Clauses 2 and 3 govern redistributable code. Doesn't the VS EULA have similar clauses?
It has similar and different clauses. From what I can tell, as long as
we distribute them only to run on Windows (i.e. not intentionally Wine
compliant) then we're ok. Of course, I could be completely wrong, its
a massive pile of confusing legalise. (and the license is also
copyrighted, so I can't even show you a copy!)
I don't know of any other open source project that even thinks of
displaying a microsoft license in front of their open source project,
so I'd be tempted just to ignore this happily.
On 10/11/05, Ross Paterson
On Tue, Oct 11, 2005 at 10:56:50AM +0100, Neil Mitchell wrote:
According to the EULA http://msdn.microsoft.com/visualc/vctoolkit2003/eula.aspx, you'll need a click-wrap licence around it.
Thats for the Visual Studio toolkit - the freely downloadable compiler and linker from Microsoft. I am using the full Visual Studio package, which doesn't have those restrictions.
Clauses 2 and 3 govern redistributable code. Doesn't the VS EULA have similar clauses?
_______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
On Tue, Oct 11, 2005 at 11:42:15AM +0100, Neil Mitchell wrote:
It has similar and different clauses. From what I can tell, as long as we distribute them only to run on Windows (i.e. not intentionally Wine compliant) then we're ok. Of course, I could be completely wrong, its a massive pile of confusing legalise. (and the license is also copyrighted, so I can't even show you a copy!)
Since I can't see the VS licence, I'll have to stick with the VS Toolkit licence. Windows-only distribution covers 3.1(ii), but it's 3.1(iii) that requires the click-wrap licence.
I don't know of any other open source project that even thinks of displaying a microsoft license in front of their open source project, so I'd be tempted just to ignore this happily.
I don't think that matters, but I believe the Python people have worried about it. The inclusion of MS-licensed code means the package is no longer wholloy open source.
participants (3)
-
Krasimir Angelov -
Neil Mitchell -
Ross Paterson