Hi, With the patches that have been submitted, the bug list for WinHugs hits 0, see http://www.haskell.org/hawiki/NeilMitchell_2fHugsNotes . If anyone knows of any other bugs, or finds any, please let me know. If anyone thinks anything in the polish section is a bit more important also let me know. I think I'm ready for limited beta testing, so if anyone wants that also let me know. Also if anyone has any overall comments (I miss this, why did you change that, how do I do this, i can't see the use of that) I'd love to hear them. When does it suit to release WinHugs? It needs a bit longer for beta testing etc, but is a Hugs release being planned soon, or should WinHugs be released separately? How stable is the Hugs code base, i.e. is it release worthy? Thanks Neil
On Wed, Sep 07, 2005 at 04:10:57PM +0100, Neil Mitchell wrote:
With the patches that have been submitted, the bug list for WinHugs hits 0, see http://www.haskell.org/hawiki/NeilMitchell_2fHugsNotes .
If you don't count interact as a bug. Do getChar/putChar work?
If anyone knows of any other bugs, or finds any, please let me know. If anyone thinks anything in the polish section is a bit more important also let me know. I think I'm ready for limited beta testing, so if anyone wants that also let me know. Also if anyone has any overall comments (I miss this, why did you change that, how do I do this, i can't see the use of that) I'd love to hear them.
A WinHugs blurb for the User's Guide is important; it doesn't have to be very long. What would :main do? You might like to check whether HGL works with WinHugs: try running main in hugsdir/demos/HGL/GTest.hs -- it should pop up lots of windows that react to events in different ways (README in that directory gives the details).
When does it suit to release WinHugs? It needs a bit longer for beta testing etc, but is a Hugs release being planned soon, or should WinHugs be released separately? How stable is the Hugs code base, i.e. is it release worthy?
It would be great if a release of the whole thing could be done soon. As I understand it, the state of play is: - Hugs is ready under Unix. - The programs and libraries build under MSYS+MinGW and appear to work. - Need to check whether the Unicode stuff works under Windows. - The plain interpreter hasn't been built under VC++ for some time; someone needs to do that and test it. - WinHugs builds under MSYS+MinGW, but the executable just hangs. (Not essential to fix this, but would be nice.) - Someone will have to do the Windows packaging, including the program compiled with VC++ (for the stack overflow protection) and the documentation is HTML Help form.
If you don't count interact as a bug. Do getChar/putChar work? putChar works fine, getChar doesn't. I can probably fix this up in the long run, I just don't have a clue where to start for now - the whole flow of control with the message pump, setjmp, polling etc. is quite confusing.
A WinHugs blurb for the User's Guide is important; it doesn't have to be very long. That's easy enough. I'll submit something.
What would :main do? ":main arg1 arg2" would invoke main, but getArgs would return ["arg1","arg2"] for that execution. This would be fantastically useful for testing console programs. This would be a Hugs improvement, not specific to WinHugs.
You might like to check whether HGL works with WinHugs: try running main in hugsdir/demos/HGL/GTest.hs -- it should pop up lots of windows that react to events in different ways (README in that directory gives the details).
First off, it doesn't load. By changing the path from {Hugs}\packages\* to: {Hugs}\packages\HGL;{Hugs}\packages\Win32; I get it to load. Is this a Windows problem, or a more general problem? Once I get it running, typing main brings up all the windows. Unfortunately playing with them gives warnings like: Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention. inside incMallocPtrRefCnt And every so often it crashes.
- Need to check whether the Unicode stuff works under Windows. I doubt it, but fundamentally the controls are all operating system controls, and should support unicode. Its just a case of replacing char* and CHAR* for LPTSTR, then checking.
- The plain interpreter hasn't been built under VC++ for some time; someone needs to do that and test it. I did it when I submitted the project files for msc, its fine for basic use, I didn't extensively test it.
- WinHugs builds under MSYS+MinGW, but the executable just hangs. (Not essential to fix this, but would be nice.) I will install the required MSYS+MinGW and see what happens, I wouldn't have expected it to hang, but it should be fixable.
- Someone will have to do the Windows packaging, including the program compiled with VC++ (for the stack overflow protection) and the documentation is HTML Help form. I don't know how to compile the HTML Help, but I'm sure I can figure it out. I have builds of the 3 binaries for Hugs.
Thanks Neil
On Wed, Sep 07, 2005 at 05:37:06PM +0100, Neil Mitchell wrote:
If you don't count interact as a bug. Do getChar/putChar work? putChar works fine, getChar doesn't. I can probably fix this up in the long run, I just don't have a clue where to start for now - the whole flow of control with the message pump, setjmp, polling etc. is quite confusing.
Ah
What would :main do? ":main arg1 arg2" would invoke main, but getArgs would return ["arg1","arg2"] for that execution. This would be fantastically useful for testing console programs. This would be a Hugs improvement, not specific to WinHugs.
If the Main module imports System.Environment, you can get this effect via Main> withArgs ["arg1","arg2"] main (there's withProgName too)
You might like to check whether HGL works with WinHugs: try running main in hugsdir/demos/HGL/GTest.hs -- it should pop up lots of windows that react to events in different ways (README in that directory gives the details).
First off, it doesn't load. By changing the path from {Hugs}\packages\* to: {Hugs}\packages\HGL;{Hugs}\packages\Win32;
I get it to load. Is this a Windows problem, or a more general problem?
That seems to imply that the \* feature isn't working under Windows, so none of the packages are available. Can you load Distribution.Simple? (But it does work when built with MSYS+MinGW, as does HGL itself.)
- WinHugs builds under MSYS+MinGW, but the executable just hangs. (Not essential to fix this, but would be nice.) I will install the required MSYS+MinGW and see what happens, I wouldn't have expected it to hang, but it should be fixable.
You also need MSYSdtk. The commands to build winhugs aren't in the Makefile yet. By hang, I mean it doesn't even create a window.
- Someone will have to do the Windows packaging, including the program compiled with VC++ (for the stack overflow protection) and the documentation is HTML Help form. I don't know how to compile the HTML Help, but I'm sure I can figure it out. I have builds of the 3 binaries for Hugs.
There's nothing in the Makefile, but I understand xsltproc can generate it from the .xml files. There's also the MSI packaging. Sigbjorn, are you there?
If you bundle up the installable tree in some form, I could wrap it up as an .msi installer
What do you use to make the installer? Do you have any scripts for it already? That way I could do it, provided it doesn't rely on any commercial tools I don't have. I did briefly look at writing a wix script (http://sourceforge.net/projects/wix) today, which would generate an MSI. I'm not sure I'll ever have time to finish it though. Thanks Neil
Am Freitag, 9. September 2005 23:05 schrieb Neil Mitchell:
What do you use to make the installer? Do you have any scripts for it already? That way I could do it, provided it doesn't rely on any commercial tools I don't have.
This is on my wish list for a loooong time: I would *highly* prefer if we had an automated way of baking all our Haskell software (GHC, Hugs, Alex, Haddock, Happy, ...) into an .msi, using only *freely* availabe tools...
I did briefly look at writing a wix script (http://sourceforge.net/projects/wix) today, which would generate an MSI. I'm not sure I'll ever have time to finish it though.
There is another maintained free project on SF for building installers, I'm not sure if it's better or worse than the one already mentioned: http://sourceforge.net/projects/nsis I already had a short look at both wix and nsis, but I simply did not manage to find enough time and energy to commit something useful for us. Any help here would be highly appreciated. (=> hint ;-) Cheers, S.
On Wed, Sep 07, 2005 at 05:37:06PM +0100, Neil Mitchell wrote:
First off, it doesn't load. By changing the path from {Hugs}\packages\* to: {Hugs}\packages\HGL;{Hugs}\packages\Win32;
I get it to load. Is this a Windows problem, or a more general problem?
I may have fixed the \* feature now -- try loading Distribution.Simple. If not, have a look at the Windows version of scanSubDirs() in machdep.h and see if there are any glaring mistakes.
Once I get it running, typing main brings up all the windows. Unfortunately playing with them gives warnings like:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
inside incMallocPtrRefCnt
And every so often it crashes.
There seems to be a problem with a VC-compiled binary loading DLLs produced by MinGW.
I may have fixed the \* feature now You have correctly.
* The wrapper FFI doesn't work. This means that the Win32 library and the OpenGL library probably don't work (along with any other
I have rebuilt my hugsdir using the make command, and rebuilt lots of other things, and now I have all the OpenGL examples running perfectly, including keyboard input. libraries that use wrappers). I don't know if it ever worked or not, but based on "make check" failures, there is something wrong. I don't have a clue if it ever did, I've never used it and I don't know how.
The fptools Makefile system has htmlhelp target which builds both GHC
userguide and all library documentations for HTML Help. I hope that it
can be addopted for Hugs. I already have added HTML Help support for
Haddock.
Cheers,
Krasimir
2005/9/7, Neil Mitchell
If you don't count interact as a bug. Do getChar/putChar work? putChar works fine, getChar doesn't. I can probably fix this up in the long run, I just don't have a clue where to start for now - the whole flow of control with the message pump, setjmp, polling etc. is quite confusing.
A WinHugs blurb for the User's Guide is important; it doesn't have to be very long. That's easy enough. I'll submit something.
What would :main do? ":main arg1 arg2" would invoke main, but getArgs would return ["arg1","arg2"] for that execution. This would be fantastically useful for testing console programs. This would be a Hugs improvement, not specific to WinHugs.
You might like to check whether HGL works with WinHugs: try running main in hugsdir/demos/HGL/GTest.hs -- it should pop up lots of windows that react to events in different ways (README in that directory gives the details).
First off, it doesn't load. By changing the path from {Hugs}\packages\* to: {Hugs}\packages\HGL;{Hugs}\packages\Win32;
I get it to load. Is this a Windows problem, or a more general problem?
Once I get it running, typing main brings up all the windows. Unfortunately playing with them gives warnings like:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
inside incMallocPtrRefCnt
And every so often it crashes.
- Need to check whether the Unicode stuff works under Windows. I doubt it, but fundamentally the controls are all operating system controls, and should support unicode. Its just a case of replacing char* and CHAR* for LPTSTR, then checking.
- The plain interpreter hasn't been built under VC++ for some time; someone needs to do that and test it. I did it when I submitted the project files for msc, its fine for basic use, I didn't extensively test it.
- WinHugs builds under MSYS+MinGW, but the executable just hangs. (Not essential to fix this, but would be nice.) I will install the required MSYS+MinGW and see what happens, I wouldn't have expected it to hang, but it should be fixable.
- Someone will have to do the Windows packaging, including the program compiled with VC++ (for the stack overflow protection) and the documentation is HTML Help form. I don't know how to compile the HTML Help, but I'm sure I can figure it out. I have builds of the 3 binaries for Hugs.
Thanks
Neil _______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
Am Mittwoch, 7. September 2005 18:37 schrieb Neil Mitchell:
[...]
- Someone will have to do the Windows packaging, including the program compiled with VC++ (for the stack overflow protection) and the documentation is HTML Help form.
I don't know how to compile the HTML Help, but I'm sure I can figure it out. I have builds of the 3 binaries for Hugs.
My usual wish for a binary release on Windows: Can we make sure that the OpenGL/GLUT/OpenAL packages are included? This would involve installing the right headers/libraries on the build machine and tell the build system about the respective paths. On the target machines it will only require the GLUT/OpenAL DLLs, and these only in the case that the corresponding packages are actually used. Cheers, S.
On Wed, Sep 07, 2005 at 05:37:06PM +0100, Neil Mitchell wrote:
Once I get [HGL] running, typing main brings up all the windows. Unfortunately playing with them gives warnings like:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
inside incMallocPtrRefCnt
And every so often it crashes.
This might be fixed now. You'll need to regenerate the libraries under MinGW before trying them with the MSVC-generated (win)hugs.
On Sun, Sep 11, 2005 at 11:58:34AM +0100, Ross Paterson wrote:
On Wed, Sep 07, 2005 at 05:37:06PM +0100, Neil Mitchell wrote:
Once I get [HGL] running, typing main brings up all the windows. Unfortunately playing with them gives warnings like:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
inside incMallocPtrRefCnt
And every so often it crashes.
This might be fixed now.
Sadly not.
On 9/7/05, Neil Mitchell
Hi,
With the patches that have been submitted, the bug list for WinHugs hits 0, see http://www.haskell.org/hawiki/NeilMitchell_2fHugsNotes .
There seem to be two serious known bugs in Hugs on Windows: * The wrapper FFI doesn't work. This means that the Win32 library and the OpenGL library probably don't work (along with any other libraries that use wrappers). I don't know if it ever worked or not, but based on "make check" failures, there is something wrong. * "interact" and "getChar" don't work in CVS WinHugs, but they worked before (right?). This is a regression. "interact" and "getChar" are in the Haskell 98 prelude. I think that implementing the Haskell 98 standard should always be priority #1. When does it suit to release WinHugs? It needs a bit longer for beta testing
etc, but is a Hugs release being planned soon, or should WinHugs be released separately? How stable is the Hugs code base, i.e. is it release worthy?
I think it would be confusing to users to release WinHugs seperately from the command line Hugs. Next weekend I will verify that (Win)Hugs from CVS builds correctly using MS Visual Studio 2003. I would recommend making a test release soon. That way, people downloading WinHugs for their Fall semester CS courses can test it out and report bugs. - Brian
participants (6)
-
Brian Smith -
Krasimir Angelov -
Neil Mitchell -
Ross Paterson -
Sigbjorn Finne -
Sven Panne