From: Daan L. <da...@cs...> - 2005-05-08 08:11:28
|
Announcement: wxHaskell version 0.9.4, update 1 ---------------------------------------------------------------------- <http://wxhaskell.sourceforge.net> This is a bugfix release of wxHaskell version 0.9.4 for Windows platforms with GHC 6.4. The interpreter GHCi 6.4 now works with wxHaskell without problems. Thanks to Sigbjorn Finne for fixing this bug. As always, first uninstall before re-installing: - click on "wxhaskell-0.9.4\bin\wxhaskell-unregister.bat" - remove the "wxhaskell-0.9.4" directory - unzip the new release - click on "wxhaskell-0.9.4\bin\wxhaskell-register.bat" Have fun, Daan Leijen. ---------------------------------------------------------------------- wxHaskell is a portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore build on top of wxWidgets -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Since most of the interface is automatically generated from the wxEiffel binding, the current release of wxHaskell already supports about 75% of the wxWindows functionality -- about 2900 methods in 500 classes with 1400 constant definitions. wxHaskell has been build with GHC 6.x on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows, Linux (RPM) and MacOS X. And even if you don't intend to write GUI's yourself, it will be fun to check out the screenshots at <http://wxhaskell.sourceforge.net>. ---------------------------------------------------------------------- Version 0.9.4-1 ------------- Bugfixes: - Compile the wx library with -fvia-C. This prevents crashes in GHCi-6.4.(Fix is found by Sigbjorn Finne) Version 0.9.4 ------------- Backward compatible additions: - Adapted the configuration, make files, and install scripts to work with GHC 6.4. - Adapted the wxHaskell C-layer to work with wxWidgets 2.6.0 - Made "Object" an instance of Ord Version 0.9 ------------- Non backward compatible changes: - Changed "image" attribute to "picture" Backward compatible additions: - Added Multiple OpenGL Canvas example and fixed old example. - Much improved process support in WXCore.Process. Use "processExecAsyncTimed" instead of "processExecASync". - Full printing support in WXCore.Print - Added SpintControl events. - Fixed bug in MultiListBoxes where selections would only be added. - Added "pixelBufferGetPixels" and "pixelBufferSetPixels" and according functions for images. - Added "image" and made it an instance of the "Sized" class exported "imageCreateFromPixels" and "imageCreateFromPixelArray" - Added "drawImage" - Removed dependency on "readline" package in ghc 6.2.2 - Added "--cache" argument to configure script Bug fixes: - fixed "on command" event handlers in submenus. |
From: Claus R. <cla...@ta...> - 2005-05-08 10:42:37
|
Hi Daan, that's good news! as you will see from the imminent communities report, I was just about to give up on wxhaskell:-) But I don't quite understand your latest mails: is the updated wxHaskell really meant for the (now) old ghc 6.4.0?? There are quite a few more bugfixes in 6.4.1, and it is now required for building ghc HEAD, I think, so wouldn't it be more useful to have wxHaskell work with 6.4.1 on windows? cheers, claus > This is a bugfix release of wxHaskell version 0.9.4 for Windows > platforms with GHC 6.4. The interpreter GHCi 6.4 now works with > wxHaskell without problems. Thanks to Sigbjorn Finne for fixing this > bug. >Well, thanks to the hard work of Sigbjorn Finne, >I have found a way to use GHCi-6.4 without crashing >on windows. So, I'll make a new updated release soon >that works with the standard GHCi-6.4.0 -- hopefully, >this saves you the work of rebuilding. |
From: Daan L. <da...@cs...> - 2005-05-08 12:06:10
|
Claus Reinke wrote: >Hi Daan, > >that's good news! as you will see from the imminent communities >report, I was just about to give up on wxhaskell:-) > > ?? Why would you give up on wxHaskell? :-) Seriously, if you have real problems, please tell me so and we can see what to do about it. >But I don't quite understand your latest mails: is the updated >wxHaskell really meant for the (now) old ghc 6.4.0?? There are >quite a few more bugfixes in 6.4.1, and it is now required for >building ghc HEAD, I think, so wouldn't it be more useful to >have wxHaskell work with 6.4.1 on windows? > > Hmm, when I do "ghc --version" it says: > The Glorious Glasgow Haskell Compilation System, version 6.4 I guessed tis means 6.4.0 and that 6.4.1 is the current development version of ghc. I plan to only release binary versions for stable versions of ghc -- people with development versions of ghc are usually able to build wxHaskell themselves. The latest development version of GHC works out of the box with wxHaskell as it has real bugfixes that fix the current problems on windows (while my bugfix release works around it). -- Daan. >cheers, >claus > > > >>This is a bugfix release of wxHaskell version 0.9.4 for Windows >>platforms with GHC 6.4. The interpreter GHCi 6.4 now works with >>wxHaskell without problems. Thanks to Sigbjorn Finne for fixing this >>bug. >> >> > > > >>Well, thanks to the hard work of Sigbjorn Finne, >>I have found a way to use GHCi-6.4 without crashing >>on windows. So, I'll make a new updated release soon >>that works with the standard GHCi-6.4.0 -- hopefully, >>this saves you the work of rebuilding. >> >> > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: NEC IT Guy Games. >Get your fingers limbered up and give it your best shot. 4 great events, 4 >opportunities to win big! Highest score wins.NEC IT Guy Games. Play to >win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 >_______________________________________________ >wxhaskell-users mailing list >wxh...@li... >https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > > |
From: Claus R. <cla...@ta...> - 2005-05-08 12:43:30
|
>?? Why would you give up on wxHaskell? :-) Seriously, if you >have real problems, please tell me so and we can see what >to do about it. well, our problem was that no one was even listening to the problems we told you about!-) >Hmm, when I do "ghc --version" it says: >> The Glorious Glasgow Haskell Compilation System, version 6.4 >I guessed tis means 6.4.0 and that 6.4.1 is the current >development version of ghc. I plan to only release binary >versions for stable versions of ghc -- people with development >versions of ghc are usually able to build wxHaskell themselves. > >The latest development version of GHC works out of the box >with wxHaskell as it has real bugfixes that fix the current >problems on windows (while my bugfix release works around it). Sigbjorn has set up nightly builds of both HEAD and STABLE for mingw, and has merged the fixes to the STABLE branch while bumping the version number to 6.4.1. So, windows ghc users are no longer poor cousins, and can get the benefits of bug-fixes without going for development builds (which are somewhere in the 6.5 region) or waiting for infrequent releases. no need for ugly work-arounds;-) http://www.haskell.org//pipermail/cvs-all/2005-May/040980.html http://www.haskell.org//pipermail/cvs-all/2005-May/040972.html http://www.haskell.org/ghc/dist/stable/dist as for being able to build wxhaskell themselves, I'm in the process of giving that a go (windows xp with cygwin and mingw,ghc-6.4.1, wxhaskell-src-0.9.4-1.zip,wxWidgets 2.6.0+2 patches). wxWidgets seems to have built and installed just fine, and ./configure for wxHaskell works, but when trying to make wxHaskell, I get the error below. Any suggestions? cheers, claus .. g++ -c wxc/src/treectrl.cpp -o out/wxc/treectrl.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -I C:/cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/treectrl.cpp: In function `void wxTreeCtrl_GetFirstChild(void*, void*, void*, void*)': wxc/src/treectrl.cpp:333: warning: `GetFirstChild' is deprecated (declared at C:/cygwin/usr/local/include/wx-2.6/wx/msw/treectrl.h:407) wxc/src/treectrl.cpp: In function `void wxTreeCtrl_GetNextChild(void*, void*, void*, void*)': wxc/src/treectrl.cpp:338: warning: `GetNextChild' is deprecated (declared at C:/cygwin/usr/local/include/wx-2.6/wx/msw/treectrl.h:409) g++ -c wxc/src/image.cpp -o out/wxc/image.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC:/ cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/image.cpp:124:2: warning: no newline at end of file g++ -c wxc/src/apppath.cpp -o out/wxc/apppath.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC :/cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/apppath.cpp:114:2: warning: no newline at end of file g++ -c wxc/src/db.cpp -o out/wxc/db.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC:/cyg win/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/db.cpp: In function `int wxDbColInf_GetColumnSize(wxDbColInf*)': wxc/src/db.cpp:1035: `class wxDbColInf' has no member named `columnSize' wxc/src/db.cpp: In function `int wxDbColInf_GetBufferLength(wxDbColInf*)': wxc/src/db.cpp:1044: `class wxDbColInf' has no member named `bufferLength' wxc/src/db.cpp: In function `wxDbColInf* wxDb_GetResultColumns(wxDb*, int*)': wxc/src/db.cpp:1158: `class wxDbColInf' has no member named `columnSize' make: *** [out/wxc/db.o] Error 1 |
From: Daan L. <da...@cs...> - 2005-05-08 16:25:40
|
Claus Reinke wrote: >>?? Why would you give up on wxHaskell? :-) Seriously, if you >>have real problems, please tell me so and we can see what >>to do about it. >> >> > >well, our problem was that no one was even listening to >the problems we told you about!-) > > Hmm, maybe this was related that I was accidently unsubscribed from this list for a few months.. :-( Well, hopefully I'll listen better from now on. However, I will have little time till October, afterwards I'll be doing more development work again. >>Hmm, when I do "ghc --version" it says: >> >> >>>The Glorious Glasgow Haskell Compilation System, version 6.4 >>> >>> >>I guessed tis means 6.4.0 and that 6.4.1 is the current >>development version of ghc. I plan to only release binary >>versions for stable versions of ghc -- people with development >>versions of ghc are usually able to build wxHaskell themselves. >> >>The latest development version of GHC works out of the box >>with wxHaskell as it has real bugfixes that fix the current >>problems on windows (while my bugfix release works around it). >> >> > >Sigbjorn has set up nightly builds of both HEAD and STABLE >for mingw, and has merged the fixes to the STABLE branch while >bumping the version number to 6.4.1. So, windows ghc users are >no longer poor cousins, and can get the benefits of bug-fixes >without going for development builds (which are somewhere in >the 6.5 region) or waiting for infrequent releases. no need for >ugly work-arounds;-) > > Great. >http://www.haskell.org//pipermail/cvs-all/2005-May/040980.html >http://www.haskell.org//pipermail/cvs-all/2005-May/040972.html >http://www.haskell.org/ghc/dist/stable/dist > >as for being able to build wxhaskell themselves, I'm in the process >of giving that a go (windows xp with cygwin and mingw,ghc-6.4.1, >wxhaskell-src-0.9.4-1.zip,wxWidgets 2.6.0+2 patches). wxWidgets >seems to have built and installed just fine, and ./configure for >wxHaskell works, but when trying to make wxHaskell, I get the >error below. Any suggestions? > > First of all, I strongly recommend wxWidgets 2.4.2 since it is the only version that works with ghci. Newer wxWidgets version use static initializers that are not properly desctructed when the dynamic link library is not re-loaded. Furthermore, there doesn't seem to be that many new features useful on Windows. >.. >g++ -c wxc/src/treectrl.cpp -o >out/wxc/treectrl.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -I >C:/cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include >wxc/src/treectrl.cpp: In function `void wxTreeCtrl_GetFirstChild(void*, void*, > void*, void*)': >wxc/src/treectrl.cpp:333: warning: `GetFirstChild' is deprecated (declared at > C:/cygwin/usr/local/include/wx-2.6/wx/msw/treectrl.h:407) >wxc/src/treectrl.cpp: In function `void wxTreeCtrl_GetNextChild(void*, void*, > void*, void*)': >wxc/src/treectrl.cpp:338: warning: `GetNextChild' is deprecated (declared at > C:/cygwin/usr/local/include/wx-2.6/wx/msw/treectrl.h:409) > > These are "innocent" warnings -- wxHaskell still uses the deprecated interface. It would be nice to upgrade though .. >g++ -c wxc/src/image.cpp -o >out/wxc/image.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC:/ >cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include >wxc/src/image.cpp:124:2: warning: no newline at end of file >g++ -c wxc/src/apppath.cpp -o >out/wxc/apppath.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC >:/cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include >wxc/src/apppath.cpp:114:2: warning: no newline at end of file >g++ -c wxc/src/db.cpp -o >out/wxc/db.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC:/cyg >win/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include >wxc/src/db.cpp: In function `int wxDbColInf_GetColumnSize(wxDbColInf*)': >wxc/src/db.cpp:1035: `class wxDbColInf' has no member named `columnSize' >wxc/src/db.cpp: In function `int wxDbColInf_GetBufferLength(wxDbColInf*)': >wxc/src/db.cpp:1044: `class wxDbColInf' has no member named `bufferLength' >wxc/src/db.cpp: In function `wxDbColInf* wxDb_GetResultColumns(wxDb*, int*)': >wxc/src/db.cpp:1158: `class wxDbColInf' has no member named `columnSize' >make: *** [out/wxc/db.o] Error 1 > > Hmm, not good -- it is even my own code :-) An easy fix would be to disable the odbc when building wxWidgets (./configure --disable-odbc). However, I have build wxHaskell with odbc on Windows -- but I was using Visual C++ 6.0. So, if you have visual studio, I recommend building it using the visual studio project. It is all explained in the build guide. With wxHaskell, you would do: > ./configure --with-msc [--wxc-libname=wxcd] open the visual studio project wxc/wxc-2.x.dsw build the dll > make Anyways, I'll try to look into it -- it seems that the make commands for newer wxWidgets is lagging behind (on Linux and MacOSX I normally build with odbc enabled). -- Daan. > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: NEC IT Guy Games. >Get your fingers limbered up and give it your best shot. 4 great events, 4 >opportunities to win big! Highest score wins.NEC IT Guy Games. Play to >win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 >_______________________________________________ >wxhaskell-users mailing list >wxh...@li... >https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > > |
From: Conal E. <co...@co...> - 2005-05-08 20:57:33
|
If anyone does compile up a 6.4.1-compatible version of wxHaskell and is willing to share it, please say so. Sounds like there are still some hitches in compiling under windows. - Conal -----Original Message----- From: wxh...@li... [mailto:wxh...@li...] On Behalf Of Daan Leijen Sent: Sunday, May 08, 2005 9:25 AM To: Claus Reinke Cc: The wxHaskell Mailing List Subject: Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release Claus Reinke wrote: ?? Why would you give up on wxHaskell? :-) Seriously, if you have real problems, please tell me so and we can see what to do about it. well, our problem was that no one was even listening to the problems we told you about!-) Hmm, maybe this was related that I was accidently unsubscribed from this list for a few months.. :-( Well, hopefully I'll listen better from now on. However, I will have little time till October, afterwards I'll be doing more development work again. Hmm, when I do "ghc --version" it says: The Glorious Glasgow Haskell Compilation System, version 6.4 I guessed tis means 6.4.0 and that 6.4.1 is the current development version of ghc. I plan to only release binary versions for stable versions of ghc -- people with development versions of ghc are usually able to build wxHaskell themselves. The latest development version of GHC works out of the box with wxHaskell as it has real bugfixes that fix the current problems on windows (while my bugfix release works around it). Sigbjorn has set up nightly builds of both HEAD and STABLE for mingw, and has merged the fixes to the STABLE branch while bumping the version number to 6.4.1. So, windows ghc users are no longer poor cousins, and can get the benefits of bug-fixes without going for development builds (which are somewhere in the 6.5 region) or waiting for infrequent releases. no need for ugly work-arounds;-) Great. http://www.haskell.org//pipermail/cvs-all/2005-May/040980.html <http://www.haskell.org/pipermail/cvs-all/2005-May/040980.html> http://www.haskell.org//pipermail/cvs-all/2005-May/040972.html <http://www.haskell.org/pipermail/cvs-all/2005-May/040972.html> http://www.haskell.org/ghc/dist/stable/dist as for being able to build wxhaskell themselves, I'm in the process of giving that a go (windows xp with cygwin and mingw,ghc-6.4.1, wxhaskell-src-0.9.4-1.zip,wxWidgets 2.6.0+2 patches). wxWidgets seems to have built and installed just fine, and ./configure for wxHaskell works, but when trying to make wxHaskell, I get the error below. Any suggestions? First of all, I strongly recommend wxWidgets 2.4.2 since it is the only version that works with ghci. Newer wxWidgets version use static initializers that are not properly desctructed when the dynamic link library is not re-loaded. Furthermore, there doesn't seem to be that many new features useful on Windows. .. g++ -c wxc/src/treectrl.cpp -o out/wxc/treectrl.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -I C:/cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/treectrl.cpp: In function `void wxTreeCtrl_GetFirstChild(void*, void*, void*, void*)': wxc/src/treectrl.cpp:333: warning: `GetFirstChild' is deprecated (declared at C:/cygwin/usr/local/include/wx-2.6/wx/msw/treectrl.h:407) wxc/src/treectrl.cpp: In function `void wxTreeCtrl_GetNextChild(void*, void*, void*, void*)': wxc/src/treectrl.cpp:338: warning: `GetNextChild' is deprecated (declared at C:/cygwin/usr/local/include/wx-2.6/wx/msw/treectrl.h:409) These are "innocent" warnings -- wxHaskell still uses the deprecated interface. It would be nice to upgrade though .. g++ -c wxc/src/image.cpp -o out/wxc/image.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC:/ cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/image.cpp:124:2: warning: no newline at end of file g++ -c wxc/src/apppath.cpp -o out/wxc/apppath.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC :/cygwin/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/apppath.cpp:114:2: warning: no newline at end of file g++ -c wxc/src/db.cpp -o out/wxc/db.o -MD -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-ansi-release-static-2.6 -IC:/cyg win/usr/local/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -Iwxc/include wxc/src/db.cpp: In function `int wxDbColInf_GetColumnSize(wxDbColInf*)': wxc/src/db.cpp:1035: `class wxDbColInf' has no member named `columnSize' wxc/src/db.cpp: In function `int wxDbColInf_GetBufferLength(wxDbColInf*)': wxc/src/db.cpp:1044: `class wxDbColInf' has no member named `bufferLength' wxc/src/db.cpp: In function `wxDbColInf* wxDb_GetResultColumns(wxDb*, int*)': wxc/src/db.cpp:1158: `class wxDbColInf' has no member named `columnSize' make: *** [out/wxc/db.o] Error 1 Hmm, not good -- it is even my own code :-) An easy fix would be to disable the odbc when building wxWidgets (./configure --disable-odbc). However, I have build wxHaskell with odbc on Windows -- but I was using Visual C++ 6.0. So, if you have visual studio, I recommend building it using the visual studio project. It is all explained in the build guide. With wxHaskell, you would do: > ./configure --with-msc [--wxc-libname=wxcd] open the visual studio project wxc/wxc-2.x.dsw build the dll > make Anyways, I'll try to look into it -- it seems that the make commands for newer wxWidgets is lagging behind (on Linux and MacOSX I normally build with odbc enabled). -- Daan. ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ wxhaskell-users mailing list wxh...@li... https://lists.sourceforge.net/lists/listinfo/wxhaskell-users |
From: Claus R. <cla...@ta...> - 2005-05-08 21:54:02
|
>If anyone does compile up a 6.4.1-compatible version of wxHaskell and is willing to share it, please say so. >Sounds like there are still some hitches in compiling under windows. - Conal that is most likely because I tried to build with the current stable wxWidgets version instead of the older 2.4.2 recommended by Dan. which is not to say that wxHaskell shouldn't try to keep pace with wxWidgets;-). I'm currently trying to build with ghc-6.5 (one of the snapshots after Sigbjorn's fix, so I'm using an unpatched wxHaskell 0.9.4) and have been a lot more successful with wxWindows 2.4.2. The build looks fairly clean and doesn't take all that long. No need to meddle with sh/bash, do any of the other fiightening things mentioned in wxHaskell's cygwin installation guide, or do anything to PATH other than adding ghc-6.5/bin, and prefixing Mingw/bin. Neither do any of the other problems mentioned in my previous mail appear in this case. There were only two small things: - wxWidgets make install didn't copy all of the include files to the installation directory (just copying the one file mentioned on the wxHaskell building page seems to be sufficient, but I still wonder what is going on there) - ghc-6.5's haddock needs to be told where to find its auxiliary files, which it is searching in the wrong directory (-l c:/ghc/ghc-6.5/docs/html/libraries helps). The problem I have at the moment is that I'm doing this on a remote machine, so I can't really test there, and I need to package things up to copy them here. But "make dist" fails for wxHaskell, with what seems to be a cygwin problem: C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487 5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization /bin/bash: fork: No such file or directory make: *** [wxc-dist] Error 129 (I added SHELL=/bin/bash to makefile, in case that would help, but as you can see, it didn't). I haven't found any real info about this problem, other than that it has been reported with fairly recent cygwin builds and not fixed in Cygwin DLL 1.5.15-1 release. the suggested fix was to try the development snapshots of cygwin.. so it may be fixed in the current cygwin already (1.5.16-1 release). but I don't know how to remote update cygwin (my only access point is via said cygwin;-), so this will have to wait till tomorrow. Apart from that, building with the older wxWidgets version and a fixed ghc seems to be painless, as Daan suggested. cheers, claus ps I only hope Daan will catch up with wxWidgets before the gap gets too wide, with all his other commitments. |
From: Daan L. <da...@cs...> - 2005-05-09 07:32:09
|
Claus Reinke wrote: >>If anyone does compile up a 6.4.1-compatible version of wxHaskell and is willing to share it, please say so. >>Sounds like there are still some hitches in compiling under windows. - Conal >> >> >that is most likely because I tried to build with the current stable wxWidgets >version instead of the older 2.4.2 recommended by Dan. which is not to say >that wxHaskell shouldn't try to keep pace with wxWidgets;-). > > Yes, in principle, building on windows with wxWidgets 2.4.2 should be fairly painless. > ps I only hope Daan will catch up with wxWidgets before the > gap gets too wide, with all his other commitments. I do try to keep pace with wxWidgets: on GTK wxHaskell uses 2.6.0 by default and on MacOSX 2.5.4 -- so everything is fine still. Since the Linux build doesn't use ODBC, I never spotted the faults that you encountered on Windows. I keep using 2.4.2 on windows since it 1) seems to have just the same set of features as 2.6 2) is very stable 3) is the only version that works well with ghci About the last point: all the newer versions of wxWidgets rely on static initializers: these are initialized when the dynamic link library is loaded (like static C++ constructors) -- when ghci loads. When I run a program from ghci, everything is fine. However, ghci keeps the dll loaded and does not reinitialize the library. When running the program again from the command line, the library is in a random state and (usually) crashes. The fix is not easy: either the wxWidgets library needs a thorough cleanup to be more stateless, or the ghci interpreter needs special code to reload dynamic link libraries. I like the last solution but it is a tricky business :-) -- Daan. > >I'm currently trying to build with ghc-6.5 (one of the snapshots after Sigbjorn's >fix, so I'm using an unpatched wxHaskell 0.9.4) and have been a lot more >successful with wxWindows 2.4.2. The build looks fairly clean and doesn't >take all that long. No need to meddle with sh/bash, do any of the other >fiightening things mentioned in wxHaskell's cygwin installation guide, or do >anything to PATH other than adding ghc-6.5/bin, and prefixing Mingw/bin. >Neither do any of the other problems mentioned in my previous mail appear >in this case. There were only two small things: > >- wxWidgets make install didn't copy all of the include files > to the installation directory (just copying the one file mentioned > on the wxHaskell building page seems to be sufficient, but I still > wonder what is going on there) > >- ghc-6.5's haddock needs to be told where to find its auxiliary > files, which it is searching in the wrong directory > (-l c:/ghc/ghc-6.5/docs/html/libraries helps). > >The problem I have at the moment is that I'm doing this on a remote >machine, so I can't really test there, and I need to package things up >to copy them here. But "make dist" fails for wxHaskell, with what >seems to be a cygwin problem: > >C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487 > 5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization >/bin/bash: fork: No such file or directory >make: *** [wxc-dist] Error 129 > >(I added SHELL=/bin/bash to makefile, in case that would help, but >as you can see, it didn't). I haven't found any real info about this >problem, other than that it has been reported with fairly recent >cygwin builds and not fixed in Cygwin DLL 1.5.15-1 release. the >suggested fix was to try the development snapshots of cygwin.. >so it may be fixed in the current cygwin already (1.5.16-1 release). > >but I don't know how to remote update cygwin (my only access >point is via said cygwin;-), so this will have to wait till tomorrow. > >Apart from that, building with the older wxWidgets version >and a fixed ghc seems to be painless, as Daan suggested. > >cheers, >claus > >ps I only hope Daan will catch up with wxWidgets before the > gap gets too wide, with all his other commitments. > > > > |
From: Claus R. <cla...@ta...> - 2005-05-11 02:16:31
|
>I keep using 2.4.2 on windows since it > >1) seems to have just the same set of features as 2.6 >2) is very stable >3) is the only version that works well with ghci 1) - there seem to be a few new features, but I don't have any urgent need for them yet - more interesting is that the change logs show a number of bug-fixes and minor improvements 2) hmm. you mean "insufficiently tested"?-) 3) now, this is the worrying bit: if I take your and shelarcy's comments, it seems that the further one moves from 2.4.2 towards the current stable version, the more features stop cooperating with the Haskell side tools. unless that can be fixed, wxHaskell will be cut off from bug fixes, improvements, and new features developed in wxWidgets. (and don't tell me its only on windows, please - if it isn't portable, with roughly the same feature-/bug-set, it isn't of any use!-). even using different versions on different platforms is not quite the kind of portability I would be hoping for.. >About the last point: all the newer versions of wxWidgets rely on static >initializers: these are initialized when the dynamic link library is loaded >(like static C++ constructors) -- when ghci loads. When I run a program from >ghci, everything is fine. However, ghci keeps the dll loaded and does not >reinitialize the library. When running the program again from the command line, >the library is in a random state and (usually) crashes. The fix is not easy: >either the wxWidgets library needs a thorough cleanup to be more stateless, or >the ghci interpreter needs special code to reload dynamic link libraries. I like >the last solution but it is a tricky business :-) you can already defer the -package wx option until after you've started your ghci session, indeed 6.5 will infer the package from the module and load when running main for the first time. so loading dlls is not tied to loading ghci but to when ghci loads the package. and if I keep loading different modules that need different packages, then ghci should really provide a way to get rid of packages and their dlls (which it doesn't). I don't remember enough of my C++, but aren't static initialisers meant to initialise persistent state? so you're saying that you can still use ghci for an interactive session with several commands, but there is no way to tell ghci that the current session is ended, and that the dll should be reloaded for a new session (short of exiting ghci..)? It is unlikely that wxWindows will change its ways for us, so I guess you're right - one needs a way to reset ghci. but if dynamic loading already works, unloading shouldn't be difficult any more (unless dynamic loading is handwritten instead of using the native support libraries?). and once the dll is unloaded, setting the package again should work. have you asked the ghci gurus? from a quick browse through ghci/{Linker,ObjLink}.lhs and rts/Linker.c, it seems that (amongst lots of stuff I won't even try to understand) there are special cases explicitly to avoid unloading and re-loading an already loaded lib - perhaps some of those can simply be dropped, or at least, a forced unload/reload be provided? it might not be all that tricky - but the gurus will know!-) cheers, claus |
From: Daan L. <da...@cs...> - 2005-05-11 07:49:55
|
Claus Reinke wrote: >>I keep using 2.4.2 on windows since it >> >>1) seems to have just the same set of features as 2.6 >>2) is very stable >>3) is the only version that works well with ghci > > > 1) - there seem to be a few new features, but I don't have any urgent > need for them yet > - more interesting is that the change logs show a number of bug-fixes > and minor improvements > > 2) hmm. you mean "insufficiently tested"?-) > > 3) now, this is the worrying bit: if I take your and shelarcy's comments, > it seems that the further one moves from 2.4.2 towards the current > stable version, the more features stop cooperating with the Haskell > side tools. unless that can be fixed, wxHaskell will be cut off from > bug fixes, improvements, and new features developed in wxWidgets. Yes, these are vallid concerns. Of course, in the long run, I hope that ghci gets fixed and is able to reload the dynamic link libraries. If you think about it, it should do so anyway for *all* dynamically linked code -- it is a miracle that other libraries work correctly :-) If this is not going to happen, someone will have to bite the bullet and write a "re-initializer" for wxWidgets, but this is potentially a lot of work and will need maintenance all the time -- something I try to avoid. > (and don't tell me its only on windows, please - if it isn't portable, > with roughly the same feature-/bug-set, it isn't of any use!-). even > using different versions on different platforms is not quite the > kind of portability I would be hoping for.. Well, even if you use the same library version the portability will *not* be perfect. This can be considered *the* feature of wxWidgets: since it uses native widgets it gives a native look-and-feel, but also small differences between platforms. My main goal for the "wx" layer is to create programs that run directly on each platform -- but it might be that a final program needs some tuning for each particular platform. "WXCore.Defines" can be used to write platform specific code. >>About the last point: all the newer versions of wxWidgets rely on static >>initializers: these are initialized when the dynamic link library is loaded >>(like static C++ constructors) -- when ghci loads. When I run a program from >>ghci, everything is fine. However, ghci keeps the dll loaded and does not >>reinitialize the library. When running the program again from the command line, >>the library is in a random state and (usually) crashes. The fix is not easy: >>either the wxWidgets library needs a thorough cleanup to be more stateless, or >>the ghci interpreter needs special code to reload dynamic link libraries. I like >>the last solution but it is a tricky business :-) > > > you can already defer the -package wx option until after you've started > your ghci session, indeed 6.5 will infer the package from the module and > load when running main for the first time. so loading dlls is not tied to > loading ghci but to when ghci loads the package. and if I keep loading > different modules that need different packages, then ghci should really > provide a way to get rid of packages and their dlls (which it doesn't). > > I don't remember enough of my C++, but aren't static initialisers > meant to initialise persistent state? so you're saying that you can > still use ghci for an interactive session with several commands, but > there is no way to tell ghci that the current session is ended, and that > the dll should be reloaded for a new session (short of exiting ghci..)? Here is an example in C: > static Handle window = NULL; > > void runWxWidgets( void ) { > if (window == NULL) { window = osCreateWindowHandle(); } > osShowModalWindow( window ); > } When I create a haskell wrapper for "runWxWidgets", the first invokation from ghci works fine. However, the next invokation crashes ghci as it still uses the "old" window handle that is no longer valid for the OS. In reality, it is a bit more complicated since a static C++ object does not just get a value assigned, but also runs the code of the constructor. There is generally no documented way to run the destructor except for "unloading" the dll. > It is unlikely that wxWindows will change its ways for us, so I guess > you're right - one needs a way to reset ghci. but if dynamic loading > already works, unloading shouldn't be difficult any more (unless > dynamic loading is handwritten instead of using the native support > libraries?). and once the dll is unloaded, setting the package again > should work. have you asked the ghci gurus? > > from a quick browse through ghci/{Linker,ObjLink}.lhs and > rts/Linker.c, it seems that (amongst lots of stuff I won't even try to > understand) there are special cases explicitly to avoid unloading > and re-loading an already loaded lib - perhaps some of those can > simply be dropped, or at least, a forced unload/reload be provided? > it might not be all that tricky - but the gurus will know!-) The GHC guru's know about this particular problem. However, *someone* will have to do it -- even though it is maybe not too hard to implement it, it surely requires knowledge of ghc and intricate linker issues. It would be very cool to have this working though :-) Cheers, Daan. |
From: Daan L. <da...@cs...> - 2005-05-09 07:35:05
|
Claus Reinke wrote: >- wxWidgets make install didn't copy all of the include files > to the installation directory (just copying the one file mentioned > on the wxHaskell building page seems to be sufficient, but I still > wonder what is going on there) > > It is a bug in wxWindows where a header file was accidently forgotten in the install script. -- Daan. |
From: Claus R. <cla...@ta...> - 2005-05-10 23:57:52
|
> - wxWidgets make install didn't copy all of the include files > to the installation directory (just copying the one file mentioned > on the wxHaskell building page seems to be sufficient, but I still > wonder what is going on there) ah, there are several of them, a pair for each platform, of which only one is copied. but this is an _old_ _stable_ release! why hasn't it been patched? > .. But "make dist" fails for wxHaskell, with what > seems to be a cygwin problem: > > C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487 > 5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization > /bin/bash: fork: No such file or directory > make: *** [wxc-dist] Error 129 updating cygwin didn't help. but slowing down the process revealed another error hidden behind this one, namely execvp complaining about too long a commandline. and if I do "make dist -n", I'm not really surprised about that complaint - have you ever looked at the things you're building there with your nice makefile function library?-) perhaps it is not so much a cygwin bug but an excessive use of resources? or is it an unfortunate implementation failing to keep up with your demands? anyway: removing the "echo" part from the cp&echo-function was sufficient to let "make dist" go through, but I'm somewhat surprised that you didn't have the same problem when building your distribution for the webpage. any ideas? cheers, claus ps. oh, the build with 6.5 on winxp works (thoroughly tested using wx/BouncingBalls;-), although 6.5 still has some issue when running under bash, so one has to run ghci under cmd instead.. it seems others have already seen that in their own builds, but I didn't want to leave the error message issue open on the list. |
From: Daan L. <da...@cs...> - 2005-05-11 07:31:21
|
Hi Claus, Claus Reinke wrote: >>- wxWidgets make install didn't copy all of the include files >> to the installation directory (just copying the one file mentioned >> on the wxHaskell building page seems to be sufficient, but I still >> wonder what is going on there) > > ah, there are several of them, a pair for each platform, of which only > one is copied. but this is an _old_ _stable_ release! why hasn't it > been patched? No sane person builds wxWidgets with "make & mingw" on a windows platform :-) (and thus, it becomes a low priority issue for the wxWidgets people) >>.. But "make dist" fails for wxHaskell, with what >>seems to be a cygwin problem: >> >>C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487 >> 5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization >>/bin/bash: fork: No such file or directory >>make: *** [wxc-dist] Error 129 > > > updating cygwin didn't help. but slowing down the process revealed > another error hidden behind this one, namely execvp complaining about > too long a commandline. and if I do "make dist -n", I'm not really > surprised about that complaint - have you ever looked at the things > you're building there with your nice makefile function library?-) Ah, I had this problem in another library of me.. You are right, the command line will be way too long. Thanks for pointing this out, I'll put it on the TODO list. > ps. oh, the build with 6.5 on winxp works (thoroughly tested > using wx/BouncingBalls;-), although 6.5 still has some issue > when running under bash, so one has to run ghci under cmd > instead.. it seems others have already seen that in their own > builds, but I didn't want to leave the error message issue > open on the list. That is good to know. Thanks. -- Daan. |
From: shelarcy <she...@ca...> - 2005-05-09 06:26:13
|
Read this thread, then I try to build wxHskell with wxWidgets 2.6.0. Okay, I see. wxHaskell can't use with wxWidgets 2.6.0's dll. If use wxWidgets 2.6.0 on Windows, there are many problem. Visual C++ 7.1 (Visual Studio .NET 2003) build wxc successfuly, and build wxHaskell successfuly too. But If use wxHaskell with wxWidgets 2.6.0's dll then libwxcore2.a and wxcore2.o can't resolve wxc print function, so both ghc and ghci can't use wxHaskell with wxWidgets 2.6.0's dll. Yes, I knew current version doesn't match Visual C++ 7.1 (e.g. Visual C++ 7.X's wxcdll doen't work with OpenGL Canvas.), so I don't know Visual C++ 6.0 has same problem. But this conclusion - If want to build wxHaskell on Windows, don't use wxWidgets 2.6.0 - are commonly. I think this problem doesn't exist in wxWidgets 2.5.3. Only ghci problem (and 7.1's OpenGL prolem) exists. On Sun, 08 May 2005 18:25:25 +0200, Daan Leijen <da...@cs...> wrote: >> as for being able to build wxhaskell themselves, I'm in the process >> of giving that a go (windows xp with cygwin and mingw,ghc-6.4.1, >> wxhaskell-src-0.9.4-1.zip,wxWidgets 2.6.0+2 patches). wxWidgets >> seems to have built and installed just fine, and ./configure for >> wxHaskell works, but when trying to make wxHaskell, I get the >> error below. Any suggestions? > > (snip compiler error message) > However, I have build wxHaskell with odbc on Windows -- but I was using > Visual C++ 6.0. > So, if you have visual studio, I recommend building it using the visual > studio > project. It is all explained in the build guide. With wxHaskell, you > would do: > > > ./configure --with-msc [--wxc-libname=wxcd] > > open the visual studio project wxc/wxc-2.x.dsw > build the dll > > > make > > First of all, I strongly recommend wxWidgets 2.4.2 since it is the only > version that works with ghci. Newer wxWidgets version use static > initializers that are not properly desctructed when the dynamic > link library is not re-loaded. Furthermore, there doesn't seem to > be that many new features useful on Windows. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/ |