From: Jeremy O'D. <jer...@gm...> - 2012-01-05 17:44:36
|
Hi Lists, I am please to announce that wxHaskell 0.13.2 has just been uploaded to Hackage. This is mainly a bugfix release, although it brings a few useful changes: - Changes to support build under Haskell Platform 2011.4.0.0 - OpenGL support if your wxWidgets build is configured with it (reinstated functionality) - StyledTextControl support if your wxWidgets build is configured with it (reinstated functionality) This is intended to be the final wxHaskell release supporting wxWidgets 2.8.x. Provided that you have a suitable Unicode wxWidgets 2.8 install configured on your machine, you should be able to install with. cabal install wx In the near future, we will be committing an updated wxHaskell release supporting wxWidgets 2.9, but this implies a number of breaking API changes, and the size of team supporting wxHaskell is not large enough to cover both. As such, this release is recommended to those who will not be able to move to wxWidgets 2.9 and later. The next release has more significant improvements planned, including wrapping several additional wxWIdgets libraries and restoring correct operation in GHCi. We do not have a formal timeline as yet, but the code is working in test repositories, and mainly needs work to make it cross-platform clean. This release has been tested on the following platforms: - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode, Release) - OpenGL is not enabled on the test platform, so OpenGL samples do not work. - StyledTextControl is not enabled on the test platform, so STC samples do not work. - All other sample code compiles, links and runs, but has only been tested for Unicode wxWidgets builds. - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10 - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev, libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa, libglu1-mesa-dev, mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6 - Cabal packages: strict, stm, OpenGL, cabal-install - OpenGL is enabled on the test platform, and the samples compile and run. - StyledTextControl is not enabled on the test platform, so STC samples do not work. - All other sample code compiles, links and runs, but has only been tested for Unicode wxWidgets. I do not have access to an OS X platform for test, so would appreciate feedback on any issues found by OS X users. There are known to be issues on 64 bit OS X builds, which will be addressed in the next release. The source repository at code.haskell.org has not yet been updated with the patches. This will happen in the next day or so. Best regards Jeremy |
From: shelarcy <she...@gm...> - 2012-01-06 15:13:13
Attachments:
missing.dpatch
|
Hello, This version has two installing problem. 1. wxdirect's sdist dropped IOExtra module, so I can't install this version. I uploaded newer version for fixing this problem, and attached a patch for fixing same problem in Dave's wxhaskell-dev branch. 2. It seems that wxcore depends on Eric's wx-config implicitly at least Windows environment. "cabal install" fail with wx-config-win binary, and "cabal install" success with Eric's one. If wxcore depends on wx-config package in only Windows environment, I think we should upload Eric's wx-config package, and modify wxcore to denped on wx-config package on Windows environment for workaround. if os(windows) Build-Depends: wx-config wx-config package isn't uploaded yet. So, I don't upload newer version, nor attach patch for fixing this problem. Best Regards, On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue <jer...@gm...> wrote: > Hi Lists, > > I am please to announce that wxHaskell 0.13.2 has just been uploaded to > Hackage. > > This is mainly a bugfix release, although it brings a few useful changes: > > - Changes to support build under Haskell Platform 2011.4.0.0 > - OpenGL support if your wxWidgets build is configured with it > (reinstated functionality) > - StyledTextControl support if your wxWidgets build is configured with > it (reinstated functionality) > > This is intended to be the final wxHaskell release supporting wxWidgets > 2.8.x. > > Provided that you have a suitable Unicode wxWidgets 2.8 install configured > on your machine, you should be able to install with. cabal install wx > > In the near future, we will be committing an updated wxHaskell release > supporting wxWidgets 2.9, but this implies a number of breaking API > changes, and the size of team supporting wxHaskell is not large enough to > cover both. As such, this release is recommended to those who will not be > able to move to wxWidgets 2.9 and later. > > The next release has more significant improvements planned, including > wrapping several additional wxWIdgets libraries and restoring correct > operation in GHCi. We do not have a formal timeline as yet, but the code is > working in test repositories, and mainly needs work to make it > cross-platform clean. > > This release has been tested on the following platforms: > > - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode, > Release) > - OpenGL is not enabled on the test platform, so OpenGL samples do > not work. > - StyledTextControl is not enabled on the test platform, so STC > samples do not work. > - All other sample code compiles, links and runs, but has only been > tested for Unicode wxWidgets builds. > - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10 > - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev, > libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa, libglu1-mesa-dev, > mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6 > - Cabal packages: strict, stm, OpenGL, cabal-install > - OpenGL is enabled on the test platform, and the samples compile and > run. > - StyledTextControl is not enabled on the test platform, so STC > samples do not work. > - All other sample code compiles, links and runs, but has only been > tested for Unicode wxWidgets. > > I do not have access to an OS X platform for test, so would appreciate > feedback on any issues found by OS X users. There are known to be issues on > 64 bit OS X builds, which will be addressed in the next release. > > The source repository at code.haskell.org has not yet been updated with the > patches. This will happen in the next day or so. -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
From: Jeremy O'D. <jer...@gm...> - 2012-01-08 22:54:34
|
Hi Shelarcy, It's great to see you back... 2012/1/6 shelarcy <she...@gm...> > This version has two installing problem. > > 1. wxdirect's sdist dropped IOExtra module, so I can't install this > version. > I uploaded newer version for fixing this problem, and attached a patch > for fixing same problem in Dave's wxhaskell-dev branch. I have just applied this to my local repo, and it will be uploaded tonight. Thanks. > > 2. It seems that wxcore depends on Eric's wx-config implicitly at least > Windows environment. "cabal install" fail with wx-config-win binary, > and "cabal install" success with Eric's one. If wxcore depends on > wx-config package in only Windows environment, I think we should upload > Eric's wx-config package, and modify wxcore to denped on wx-config package > on Windows environment for workaround. > > if os(windows) > Build-Depends: wx-config This is surprising. I am using wx-config-win on my Windows environment (when I run wx-config -v, I get "wx-config revision 26 2006-12-21"). I deliberately did not choose to use Eric's version as he had noted some issues with it. We should investigate your problem further (I am also using wPack 2.8.12) Best regards Jeremy |
From: Dave T. <dav...@gm...> - 2012-01-06 16:03:14
|
2012/1/6 shelarcy <she...@gm...> > Hello, > > This version has two installing problem. > > 1. wxdirect's sdist dropped IOExtra module, so I can't install this > version. > I uploaded newer version for fixing this problem, and attached a patch > for fixing same problem in Dave's wxhaskell-dev branch. > Good catch, thanks, I've pushed to the -dev branch. > > 2. It seems that wxcore depends on Eric's wx-config implicitly at least > Windows environment. "cabal install" fail with wx-config-win binary, > Can you remember how this failed, or send some output from the failure, and also let us know what version of wxWidgets you have? I'm hoping you say you have wx-2.9.x, in which case it could be this issue: http://code.google.com/p/wx-config-win/issues/detail?id=21 and "cabal install" success with Eric's one. If wxcore depends on > wx-config package in only Windows environment, I think we should upload > Eric's wx-config package, and modify wxcore to denped on wx-config package > on Windows environment for workaround. > > if os(windows) > Build-Depends: wx-config > > wx-config package isn't uploaded yet. So, I don't upload newer version, > nor attach patch for fixing this problem. > We're still making a decision on whether to continue using wx-config(-win), or to adopt Eric's one. I'm going to see if I can get a conversation going with the wxWidgets people and then I'll send out another mail. Cheers, > > > Best Regards, > > > > On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue < > jer...@gm...> wrote: > >> Hi Lists, >> >> I am please to announce that wxHaskell 0.13.2 has just been uploaded to >> Hackage. >> >> This is mainly a bugfix release, although it brings a few useful changes: >> >> - Changes to support build under Haskell Platform 2011.4.0.0 >> - OpenGL support if your wxWidgets build is configured with it >> (reinstated functionality) >> - StyledTextControl support if your wxWidgets build is configured with >> >> it (reinstated functionality) >> >> This is intended to be the final wxHaskell release supporting wxWidgets >> 2.8.x. >> >> Provided that you have a suitable Unicode wxWidgets 2.8 install configured >> on your machine, you should be able to install with. cabal install wx >> >> In the near future, we will be committing an updated wxHaskell release >> supporting wxWidgets 2.9, but this implies a number of breaking API >> changes, and the size of team supporting wxHaskell is not large enough to >> cover both. As such, this release is recommended to those who will not be >> able to move to wxWidgets 2.9 and later. >> >> The next release has more significant improvements planned, including >> wrapping several additional wxWIdgets libraries and restoring correct >> operation in GHCi. We do not have a formal timeline as yet, but the code >> is >> working in test repositories, and mainly needs work to make it >> cross-platform clean. >> >> This release has been tested on the following platforms: >> >> - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode, >> Release) >> - OpenGL is not enabled on the test platform, so OpenGL samples do >> not work. >> - StyledTextControl is not enabled on the test platform, so STC >> samples do not work. >> - All other sample code compiles, links and runs, but has only been >> >> tested for Unicode wxWidgets builds. >> - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10 >> - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev, >> >> libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa, >> libglu1-mesa-dev, >> mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6 >> - Cabal packages: strict, stm, OpenGL, cabal-install >> - OpenGL is enabled on the test platform, and the samples compile and >> run. >> - StyledTextControl is not enabled on the test platform, so STC >> samples do not work. >> - All other sample code compiles, links and runs, but has only been >> >> tested for Unicode wxWidgets. >> >> I do not have access to an OS X platform for test, so would appreciate >> feedback on any issues found by OS X users. There are known to be issues >> on >> 64 bit OS X builds, which will be addressed in the next release. >> >> The source repository at code.haskell.org has not yet been updated with >> the >> patches. This will happen in the next day or so. >> > > -- > shelarcy <shelarcy hotmail.co.jp> > http://page.freett.com/**shelarcy/ <http://page.freett.com/shelarcy/> > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
From: Peter S. <si...@cr...> - 2012-01-07 21:55:24
|
Hi guys, > I am please to announce that wxHaskell 0.13.2 has just been uploaded > to Hackage. when I try to build the latest version on Linux/x86_64 running NixOS, I get the following error at configure time: Setup: Missing dependency on a foreign library: * Missing C library: wx_gtk2u_media-2.8 I searched my hard disk for that library, and apparently my installed copy of wxGTK-2.8.12 doesn't have it. There are plenty of libwx_gtk2u_* libraries, but none of them is called "media". Does anyone know how wxGtk must be built in order to make sure that library exists? Is there some special configure flag, maybe? Take care, Peter |
From: Henning T. <le...@he...> - 2012-01-08 11:39:32
|
On Sat, 7 Jan 2012, Peter Simons wrote: > Hi guys, > > > I am please to announce that wxHaskell 0.13.2 has just been uploaded > > to Hackage. > > when I try to build the latest version on Linux/x86_64 running NixOS, I > get the following error at configure time: > > Setup: Missing dependency on a foreign library: > * Missing C library: wx_gtk2u_media-2.8 > > I searched my hard disk for that library, and apparently my installed > copy of wxGTK-2.8.12 doesn't have it. There are plenty of libwx_gtk2u_* > libraries, but none of them is called "media". Is it the only missing header? Once when I tried to install wxhaskell I got a lot of missing header errors although all dev packages were installed. They went away when I installed 'g++'. It was a plain Haskell development machine before :-) |
From: Jeremy O'D. <jer...@gm...> - 2012-01-08 23:47:52
|
On 5 January 2012 17:44, Jeremy O'Donoghue <jer...@gm...>wrote: > > > The source repository at code.haskell.org has not yet been updated with > the patches. This will happen in the next day or so. > > The source repository at code.haskell.org has now been updated with wxHaskell 0.13.2 plus the two patches (add IOExtra to wxdirect and remove old-time from wxcore) from Shelarcy. I suggest a period of one more week (i.e. until 15th Jan 2012) for any further issues or fixes on the 0.13.2 series. After that, Dave, Eric and others will start to upload the changes needed to support wxWidgets 2.9.x. These changes will not work against wxWidgets 2.8.x installations, and are pretty significant in places. Please expect the main repo to unstable for a while after next Sunday. Best regards Jeremy |
From: Jeremy O'D. <jer...@gm...> - 2012-01-09 09:52:14
|
Hi Peter, On 8 January 2012 11:39, Henning Thielemann <le...@he...>wrote: > > On Sat, 7 Jan 2012, Peter Simons wrote: > > > Hi guys, > > > > > I am please to announce that wxHaskell 0.13.2 has just been uploaded > > > to Hackage. > > > > when I try to build the latest version on Linux/x86_64 running NixOS, I > > get the following error at configure time: > > > > Setup: Missing dependency on a foreign library: > > * Missing C library: wx_gtk2u_media-2.8 > > > > I searched my hard disk for that library, and apparently my installed > > copy of wxGTK-2.8.12 doesn't have it. There are plenty of libwx_gtk2u_* > > libraries, but none of them is called "media". > > Is it the only missing header? Once when I tried to install wxhaskell I > got a lot of missing header errors although all dev packages were > installed. They went away when I installed 'g++'. It was a plain Haskell > development machine before :- > I'm not so familiar with NixOS - I did my testing on an Ubuntu 10.4 VMWare image. However, I have built wxWidgets more often than I care to think about. To solve the particular issue you have, you need '--enable-mediactrl' in your configure script for wxWidgets. I think you probably want something like the following if you want all of the wxHaskell features: ./configure --enable-unicode --enable-html --enable-xrc --enable-aui --enable-stc --enable-mediactrl --enable-richtext --with-gtk=2 --with-opengl Hope this helps. Best regards Jeremy |
From: Jeremy O'D. <jer...@gm...> - 2012-01-09 17:04:20
|
Hi Dave, all On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote: > 2012/1/6 shelarcy <she...@gm...> > >> 2. It seems that wxcore depends on Eric's wx-config implicitly at least >> Windows environment. "cabal install" fail with wx-config-win binary, >> > > Can you remember how this failed, or send some output from the failure, > and also let us know what version of wxWidgets you have? > I'm hoping you say you have wx-2.9.x, in which case it could be this issue: > http://code.google.com/p/wx-config-win/issues/detail?id=21 > > and "cabal install" success with Eric's one. If wxcore depends on >> wx-config package in only Windows environment, I think we should upload >> Eric's wx-config package, and modify wxcore to denped on wx-config package >> on Windows environment for workaround. >> >> if os(windows) >> Build-Depends: wx-config >> >> wx-config package isn't uploaded yet. So, I don't upload newer version, >> nor attach patch for fixing this problem. >> > > We're still making a decision on whether to continue using > wx-config(-win), or to adopt Eric's one. > I'm going to see if I can get a conversation going with the wxWidgets > people and then I'll send out another mail. > Now that the 0.13 branch looks like it is finished, I have pulled your development repo (so as to be up to date), and started to look at Windows support. Needless to say, I have immediately hit the wx-config roadblock, since I have compiled a release build of wxWidgets 2.9.3, and wx-config-win only knows about debug builds. I am leaning towards doing something with Eric's wx-config. There are a couple of reasons for this: - It keeps us in control of our own destiny; - Haskell is a *much* more pleasant implementation language for a utility which mainly does text processing than C++. Does the group have an opinion on this? My feeling is that since the last commit to wx-config-win was in 2006, it may be a while before fixes come along, and even then, we will probably need to write the patches. Regards Jeremy |
From: Dave T. <dav...@gm...> - 2012-01-09 18:09:55
|
On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote: > Hi Dave, all > On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote: > >> 2012/1/6 shelarcy <she...@gm...> >> >>> 2. It seems that wxcore depends on Eric's wx-config implicitly at least >>> Windows environment. "cabal install" fail with wx-config-win binary, >>> >> >> Can you remember how this failed, or send some output from the failure, >> and also let us know what version of wxWidgets you have? >> I'm hoping you say you have wx-2.9.x, in which case it could be this >> issue: >> http://code.google.com/p/wx-config-win/issues/detail?id=21 >> >> and "cabal install" success with Eric's one. If wxcore depends on >>> wx-config package in only Windows environment, I think we should upload >>> Eric's wx-config package, and modify wxcore to denped on wx-config >>> package >>> on Windows environment for workaround. >>> >>> if os(windows) >>> Build-Depends: wx-config >>> >>> wx-config package isn't uploaded yet. So, I don't upload newer version, >>> nor attach patch for fixing this problem. >>> >> >> We're still making a decision on whether to continue using >> wx-config(-win), or to adopt Eric's one. >> I'm going to see if I can get a conversation going with the wxWidgets >> people and then I'll send out another mail. >> > > Now that the 0.13 branch looks like it is finished, I have pulled your > development repo (so as to be up to date), and started to look at Windows > support. > Excellent, I hope it's not too much of a nightmare, I played around a little with my branch in Windows, but I'm primarily in Ubuntu. > > Needless to say, I have immediately hit the wx-config roadblock, since I > have compiled a release build of wxWidgets 2.9.3, and wx-config-win only > knows about debug builds. > Welcome to the party :) Just for the sake of clarity, I feel obliged to question your use of the words "release" and "debug"; are you aware of the "Debug Build Changes in wx3"? Here's the news: http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html (seeing the date of the post made me realise just how far behind we are, and also how slow the wxWidgets release cycles are!) That has manifested itself in this known issue with wx-config-win: http://code.google.com/p/wx-config-win/issues/detail?id=21 Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc? I dutifully downloaded the free version of Visual C++ 2010 express, loaded the wxWidgets 2.9.3 project, built, and ran some sample code. However when I tried to use wx-config-win I realised that it required a "build.cfg" file, which isn't generated when you build with VC++ (I suppose because VC++ manages all the build settings itself, and so doesn't need to export anything). Without this one is unable to install wxHaskell. I turned to the wiki and discovered this: http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup) Using it as a guide (note that one can't use wxPack because there are no wxPack releases for the development (2.9.x) releases of wxWidgets) I was (almost) able to cabal install wxHaskell from my darcsden branch (it failed because I didn't --with-OpenGL the wxWidgets configure, and then I ran out of time). > I am leaning towards doing something with Eric's wx-config. There are a > couple of reasons for this: > > - It keeps us in control of our own destiny; > - Haskell is a *much* more pleasant implementation language for a > utility which mainly does text processing than C++. > > Does the group have an opinion on this? My feeling is that since the last > commit to wx-config-win was in 2006, it may be a while before fixes come > along, and even then, we will probably need to write the patches. > Ah, well, yes.. Firstly the pro-(wx-config-win) items: * I contacted the owner of wx-config-win and he made me an owner of the Google code project, so we're 'in charge' now. * I got a small discussion going on its existence in #wxwidgets on freenode. The consensus is that, because /most/ people use Visual Studio (in some flavour) to develop with wxWidgets in Windows, there simply wasn't the need to maintain wx-config-win. As a result it was never stable enough to merit merging in to the wxWidgets code base. By comparison the wx-config we know and love on Linux systems (and, I presume, OS X?) is essential and so well maintained: http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in (I didn't realise until recently that it is just a shell script, copied in to your install dir and symlinked into your PATH). And now the cons: * It is woefully out of date. There are 18 open issues ( http://code.google.com/p/wx-config-win/issues/list) and who knows how many undiscovered bugs. * As mentioned, the wxWidgets community doesn't seem desperately fussed about its existence, so long as Visual Studio is around * It's implementation is in need of an overhaul, as identified by the previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6) So, in summary, I'm not sure. My optimist, open-source heart says we should resurrect the wx-win-config project. My do-it-the-right-way heart says we ditch the existing C++ source and replicate the shell script (Windows PowerShell anyone?) My everything-is-wonderful-with-Haskell heart says let's just roll our own, no one uses wx-config-win anyway, and all it does it find a few headers and libs. > Regards > Jeremy > |
From: Jeremy O'D. <jer...@gm...> - 2012-01-09 22:19:12
|
On 9 January 2012 18:09, Dave Tapley <dav...@gm...> wrote: > On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote: > >> On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote: >> >>> 2012/1/6 shelarcy <she...@gm...> >>> >> >> Needless to say, I have immediately hit the wx-config roadblock, since I >> have compiled a release build of wxWidgets 2.9.3, and wx-config-win only >> knows about debug builds. >> > > Welcome to the party :) > Just for the sake of clarity, I feel obliged to question your use of the > words "release" and "debug"; are you aware of the "Debug Build Changes in > wx3"? > Here's the news: > http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html > (seeing the date of the post made me realise just how far behind we are, > and also how slow the wxWidgets release cycles are!) > > I wasn't aware of the blog posting, but I did realise that there were changes in this area - some of this is covered in the install instructions. Strictly I built with: BUILD=release DEBUG_INFO=default DEBUG_FLAG=1 This means I keep the asserts, which seemed like an appropriate configuration for wxHaskell development. > > That has manifested itself in this known issue with wx-config-win: > http://code.google.com/p/wx-config-win/issues/detail?id=21 > > Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc? > I dutifully downloaded the free version of Visual C++ 2010 express, loaded > the wxWidgets 2.9.3 project, built, and ran some sample code. However when > I tried to use wx-config-win I realised that it required a "build.cfg" > file, which isn't generated when you build with VC++ (I suppose because > VC++ manages all the build settings itself, and so doesn't need to export > anything). Without this one is unable to install wxHaskell. > I built with gcc. I have played with VC++ in the past, because the build 'just works' but it was really too painful to sort out the configuration. > > I turned to the wiki and discovered this: > http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup) > > Using it as a guide (note that one can't use wxPack because there are no > wxPack releases for the development (2.9.x) releases of wxWidgets) I was > (almost) able to cabal install wxHaskell from my darcsden branch (it failed > because I didn't --with-OpenGL the wxWidgets configure, and then I ran out > of time). > > >> I am leaning towards doing something with Eric's wx-config. There are a >> couple of reasons for this: >> >> - It keeps us in control of our own destiny; >> - Haskell is a *much* more pleasant implementation language for a >> utility which mainly does text processing than C++. >> >> Does the group have an opinion on this? My feeling is that since the last >> commit to wx-config-win was in 2006, it may be a while before fixes come >> along, and even then, we will probably need to write the patches. >> > Ah, well, yes.. > Firstly the pro-(wx-config-win) items: > * I contacted the owner of wx-config-win and he made me an owner of the > Google code project, so we're 'in charge' now. > * I got a small discussion going on its existence in #wxwidgets on > freenode. The consensus is that, because /most/ people use Visual Studio > (in some flavour) to develop with wxWidgets in Windows, there simply wasn't > the need to maintain wx-config-win. As a result it was never stable enough > to merit merging in to the wxWidgets code base. By comparison the wx-config > we know and love on Linux systems (and, I presume, OS X?) is essential and > so well maintained: > > http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in > (I didn't realise until recently that it is just a shell script, copied in > to your install dir and symlinked into your PATH). > I did know that wx-config is just a shell script. I'm not so surprised that most wxWidgets developers on Windows use VS. It's a really nce development environment. I actually think they advertise support for too many build options when in reality only a few of them get any serious use. I was actually planning on looking carefully at wx-config while updating Eric's Haskell wx-config :-) > > And now the cons: > * It is woefully out of date. There are 18 open issues ( > http://code.google.com/p/wx-config-win/issues/list) and who knows how > many undiscovered bugs. > * As mentioned, the wxWidgets community doesn't seem desperately fussed > about its existence, so long as Visual Studio is around > * It's implementation is in need of an overhaul, as identified by the > previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6) > I tend to think that you've hit on the problem with this approach. The wxWidgets community doesn't really care. Therefore we would be left maintaining a piece of C++ to support what is basically our own need. > > So, in summary, I'm not sure. > My optimist, open-source heart says we should resurrect the wx-win-config > project. > My do-it-the-right-way heart says we ditch the existing C++ source and > replicate the shell script (Windows PowerShell anyone?) > My everything-is-wonderful-with-Haskell heart says let's just roll our > own, no one uses wx-config-win anyway, and all it does it find a few > headers and libs. > > I think a port of wx-config (shell) to Haskell is probably easier than doing a port into PowerShell (which I've never touched...), but I take your point about the 'right way'. I'll nail my colours to the mast and leave things open for debate after that. - My day job is C++. Thus I tend to tolerate doing it for my 'fun' projects where it is needed (e.g. wrapping a C++ library), but I kind-of prefer to spend my spare time writing Haskell rather than C++ ;-) - While the 'community' aspect of having a wxC is superficially attractive, I think history is against the idea that it is something the world really needs: - wxC has been moribund for years. I don't think it's been touched for over 5 years. This suggests that there is not so much demand out there. - wxHaskell has struggled for contributons for as long as I remember. I basically became involved because I didn't want to see it bit-rot. What I *do* believe is that there is a real demand in the Haskell community for a GUI with native look and feel, commercial-friendly licensing and ease of installation. My preference, therefore, is to move wxHaskell in that direction as far as possible, and to make the bar for becoming a developer as low as possible for Haskell developers. Basically, I want to enable the Haskell ecosystem, and that's why I'm a big fan of cabal install, despite its limitations as a generalised build system. Having said my piece, I fully understand why others may have a different view, and I think if there was I strong indication that other language communities had a serious interest in using and helping to maintain wxC, I would be easily persuaded in that direction. What I don't really believe is in 'if you build it, they will come'. I'll leave things for a couple of days to let others have their say, and then follow the community preference. Best regards Jeremy |
From: Dave T. <dav...@gm...> - 2012-01-10 17:02:12
|
On 9 January 2012 22:19, Jeremy O'Donoghue <jer...@gm...>wrote: > On 9 January 2012 18:09, Dave Tapley <dav...@gm...> wrote: > >> On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote: >> >>> On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote: >>> >>>> 2012/1/6 shelarcy <she...@gm...> >>>> >>> >>> Needless to say, I have immediately hit the wx-config roadblock, since I >>> have compiled a release build of wxWidgets 2.9.3, and wx-config-win only >>> knows about debug builds. >>> >> >> Welcome to the party :) >> Just for the sake of clarity, I feel obliged to question your use of the >> words "release" and "debug"; are you aware of the "Debug Build Changes in >> wx3"? >> Here's the news: >> http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html >> (seeing the date of the post made me realise just how far behind we are, >> and also how slow the wxWidgets release cycles are!) >> >> > I wasn't aware of the blog posting, but I did realise that there were > changes in this area - some of this is covered in the install instructions. > Strictly I built with: > > BUILD=release > DEBUG_INFO=default > DEBUG_FLAG=1 > Yikes, these flags are very (imho) counter-intuitive. Referencing a thread I have going: https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/JYd4ydh6v-IJ Vadim states that: "DEBUG_FLAG is correctly set to 1 indicating that debug code is not disabled (which is the default)". So I'm substituting "not disable" with "enabled" and reading it as: a release build with debugging enabled, or as you put it: This means I keep the asserts, which seemed like an appropriate > configuration for wxHaskell development. > What I'm not sure about here is whether the "BUILD" flag is superfluous under any GCC build, or just non-Windows GCC builds. A question which I'm asking about here: https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/nfUuz_cg-HUJ If the answer to my question there is "under Windows using MSVC", and if we accept that wxHaskell isn't going to support an MSVC build of wxWidgets (which I get the impression is the case); then I suppose that wxC can be completely agnostic to all the (non-libs) wxWidgets build type information (namely: release/debug, debugging flag on/off). Thoughts? > >> >> That has manifested itself in this known issue with wx-config-win: >> http://code.google.com/p/wx-config-win/issues/detail?id=21 >> >> Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc? >> I dutifully downloaded the free version of Visual C++ 2010 express, >> loaded the wxWidgets 2.9.3 project, built, and ran some sample code. >> However when I tried to use wx-config-win I realised that it required a >> "build.cfg" file, which isn't generated when you build with VC++ (I suppose >> because VC++ manages all the build settings itself, and so doesn't need to >> export anything). Without this one is unable to install wxHaskell. >> > > I built with gcc. I have played with VC++ in the past, because the build > 'just works' but it was really too painful to sort out the configuration. > Hazaa, I'm going to say it again: *wxHaskell doesn't support an MSVC build of wxWidgets* Is that the sort of message we can put out? > >> I turned to the wiki and discovered this: >> http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup) >> >> Using it as a guide (note that one can't use wxPack because there are no >> wxPack releases for the development (2.9.x) releases of wxWidgets) I was >> (almost) able to cabal install wxHaskell from my darcsden branch (it failed >> because I didn't --with-OpenGL the wxWidgets configure, and then I ran out >> of time). >> >> >>> I am leaning towards doing something with Eric's wx-config. There are a >>> couple of reasons for this: >>> >>> - It keeps us in control of our own destiny; >>> - Haskell is a *much* more pleasant implementation language for a >>> utility which mainly does text processing than C++. >>> >>> Does the group have an opinion on this? My feeling is that since the >>> last commit to wx-config-win was in 2006, it may be a while before fixes >>> come along, and even then, we will probably need to write the patches. >>> >> Ah, well, yes.. >> Firstly the pro-(wx-config-win) items: >> * I contacted the owner of wx-config-win and he made me an owner of the >> Google code project, so we're 'in charge' now. >> * I got a small discussion going on its existence in #wxwidgets on >> freenode. The consensus is that, because /most/ people use Visual Studio >> (in some flavour) to develop with wxWidgets in Windows, there simply wasn't >> the need to maintain wx-config-win. As a result it was never stable enough >> to merit merging in to the wxWidgets code base. By comparison the wx-config >> we know and love on Linux systems (and, I presume, OS X?) is essential and >> so well maintained: >> >> http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in >> (I didn't realise until recently that it is just a shell script, copied >> in to your install dir and symlinked into your PATH). >> > > I did know that wx-config is just a shell script. I'm not so surprised > that most wxWidgets developers on Windows use VS. It's a really nce > development environment. I actually think they advertise support for too > many build options when in reality only a few of them get any serious use. > > I was actually planning on looking carefully at wx-config while updating > Eric's Haskell wx-config :-) > I did actually miss another 'pro' here: I think it's fair to say that wx-config-win is more 'complete' than Eric's Haskell implementation, insomuch as all that's required to fix the "wx-config roadblock" is (I think) changing this line as per Vadim's suggestion : http://code.google.com/p/wx-config-win/source/browse/trunk/wx-config-win.cpp#952 > > >> >> And now the cons: >> * It is woefully out of date. There are 18 open issues ( >> http://code.google.com/p/wx-config-win/issues/list) and who knows how >> many undiscovered bugs. >> * As mentioned, the wxWidgets community doesn't seem desperately fussed >> about its existence, so long as Visual Studio is around >> * It's implementation is in need of an overhaul, as identified by the >> previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6 >> ) >> > > I tend to think that you've hit on the problem with this approach. The > wxWidgets community doesn't really care. Therefore we would be left > maintaining a piece of C++ to support what is basically our own need. > >> >> So, in summary, I'm not sure. >> My optimist, open-source heart says we should resurrect the wx-win-config >> project. >> My do-it-the-right-way heart says we ditch the existing C++ source and >> replicate the shell script (Windows PowerShell anyone?) >> My everything-is-wonderful-with-Haskell heart says let's just roll our >> own, no one uses wx-config-win anyway, and all it does it find a few >> headers and libs. >> >> > > I think a port of wx-config (shell) to Haskell is probably easier than > doing a port into PowerShell (which I've never touched...), but I take your > point about the 'right way'. > > I'll nail my colours to the mast and leave things open for debate after > that. > > - My day job is C++. Thus I tend to tolerate doing it for my 'fun' > projects where it is needed (e.g. wrapping a C++ library), but I kind-of > prefer to spend my spare time writing Haskell rather than C++ ;-) > - While the 'community' aspect of having a wxC is superficially > attractive, I think history is against the idea that it is something the > world really needs: > - wxC has been moribund for years. I don't think it's been touched > for over 5 years. This suggests that there is not so much demand out there. > - wxHaskell has struggled for contributons for as long as I > remember. I basically became involved because I didn't want to see it > bit-rot. > > > What I *do* believe is that there is a real demand in the Haskell > community for a GUI with native look and feel, commercial-friendly > licensing and ease of installation. My preference, therefore, is to move > wxHaskell in that direction as far as possible, and to make the bar for > becoming a developer as low as possible for Haskell developers. Basically, > I want to enable the Haskell ecosystem, and that's why I'm a big fan of > cabal install, despite its limitations as a generalised build system. > > Having said my piece, I fully understand why others may have a different > view, and I think if there was I strong indication that other language > communities had a serious interest in using and helping to maintain wxC, I > would be easily persuaded in that direction. What I don't really believe is > in 'if you build it, they will come'. > > I'll leave things for a couple of days to let others have their say, and > then follow the community preference. > I don't know either, needs more input I think :( > > Best regards > Jeremy > |
From: Peter S. <si...@cr...> - 2012-01-13 18:07:13
|
Hi Jeremy, > To solve the particular issue you have, you need '--enable-mediactrl' > in your configure script for wxWidgets. you were right, that did the trick. I also had to add 'gstreamer' as a build input. Without that package the build wxGTK failed to produce the media sublibrary -- but it failed silently and kept on building regardless. Duh! Anyway, NixOS now has the latest version of wxHaskell. Thank you for your efforts. I noticed, by the way, that wxHaskell doesn't compile with GHC 7.2.2: | Building wx-0.13.2... | Preprocessing library wx-0.13.2... | [ 1 of 16] Compiling Graphics.UI.WX.Types ( src/Graphics/UI/WX/Types.hs, dist/build/Graphics/UI/WX/Types.o ) | [ 2 of 16] Compiling Graphics.UI.WX.Attributes ( src/Graphics/UI/WX/Attributes.hs, dist/build/Graphics/UI/WX/Attributes.o ) | [ 3 of 16] Compiling Graphics.UI.WX.Layout ( src/Graphics/UI/WX/Layout.hs, dist/build/Graphics/UI/WX/Layout.o ) | [ 4 of 16] Compiling Graphics.UI.WX.Classes ( src/Graphics/UI/WX/Classes.hs, dist/build/Graphics/UI/WX/Classes.o ) | [ 5 of 16] Compiling Graphics.UI.WX.Media ( src/Graphics/UI/WX/Media.hs, dist/build/Graphics/UI/WX/Media.o ) | | src/Graphics/UI/WX/Media.hs:48:10: | Illegal instance declaration for `Sized (Bitmap a)' | (All instance types must be of the form (T a1 ... an) | where a1 ... an are *distinct type variables*, | and each type variable appears at most once in the instance head. | Use -XFlexibleInstances if you want to disable this.) | In the instance declaration for `Sized (Bitmap a)' | | src/Graphics/UI/WX/Media.hs:69:10: | Illegal instance declaration for `Sized (Image a)' | (All instance types must be of the form (T a1 ... an) | where a1 ... an are *distinct type variables*, | and each type variable appears at most once in the instance head. | Use -XFlexibleInstances if you want to disable this.) | In the instance declaration for `Sized (Image a)' | | src/Graphics/UI/WX/Media.hs:93:10: | Illegal instance declaration for `Media (Sound a)' | (All instance types must be of the form (T a1 ... an) | where a1 ... an are *distinct type variables*, | and each type variable appears at most once in the instance head. | Use -XFlexibleInstances if you want to disable this.) | In the instance declaration for `Media (Sound a)' | builder for `/nix/store/r486ymv1ci2zdlfh282a7x4fk4cnffb7-haskell-wx-ghc7.2.2-0.13.2.drv' failed with exit code 1 Take care, Peter |
From: Dave T. <duk...@gm...> - 2012-01-16 16:21:46
|
On 13 January 2012 17:33, Peter Simons <si...@cr...> wrote: > Hi Jeremy, > > > To solve the particular issue you have, you need '--enable-mediactrl' > > in your configure script for wxWidgets. > > you were right, that did the trick. I also had to add 'gstreamer' as a > build input. Without that package the build wxGTK failed to produce the > media sublibrary -- but it failed silently and kept on building > regardless. Duh! > > Anyway, NixOS now has the latest version of wxHaskell. Thank you for > your efforts. > > I noticed, by the way, that wxHaskell doesn't compile with GHC 7.2.2: > > | Building wx-0.13.2... > | Preprocessing library wx-0.13.2... > | [ 1 of 16] Compiling Graphics.UI.WX.Types ( src/Graphics/UI/WX/Types.hs, dist/build/Graphics/UI/WX/Types.o ) > | [ 2 of 16] Compiling Graphics.UI.WX.Attributes ( src/Graphics/UI/WX/Attributes.hs, dist/build/Graphics/UI/WX/Attributes.o ) > | [ 3 of 16] Compiling Graphics.UI.WX.Layout ( src/Graphics/UI/WX/Layout.hs, dist/build/Graphics/UI/WX/Layout.o ) > | [ 4 of 16] Compiling Graphics.UI.WX.Classes ( src/Graphics/UI/WX/Classes.hs, dist/build/Graphics/UI/WX/Classes.o ) > | [ 5 of 16] Compiling Graphics.UI.WX.Media ( src/Graphics/UI/WX/Media.hs, dist/build/Graphics/UI/WX/Media.o ) > | > | src/Graphics/UI/WX/Media.hs:48:10: > | Illegal instance declaration for `Sized (Bitmap a)' > | (All instance types must be of the form (T a1 ... an) > | where a1 ... an are *distinct type variables*, > | and each type variable appears at most once in the instance head. > | Use -XFlexibleInstances if you want to disable this.) > | In the instance declaration for `Sized (Bitmap a)' > | > | src/Graphics/UI/WX/Media.hs:69:10: > | Illegal instance declaration for `Sized (Image a)' > | (All instance types must be of the form (T a1 ... an) > | where a1 ... an are *distinct type variables*, > | and each type variable appears at most once in the instance head. > | Use -XFlexibleInstances if you want to disable this.) > | In the instance declaration for `Sized (Image a)' > | > | src/Graphics/UI/WX/Media.hs:93:10: > | Illegal instance declaration for `Media (Sound a)' > | (All instance types must be of the form (T a1 ... an) > | where a1 ... an are *distinct type variables*, > | and each type variable appears at most once in the instance head. > | Use -XFlexibleInstances if you want to disable this.) > | In the instance declaration for `Media (Sound a)' > | builder for `/nix/store/r486ymv1ci2zdlfh282a7x4fk4cnffb7-haskell-wx-ghc7.2.2-0.13.2.drv' failed with exit code 1 Could this be as simple as using FlexibleInstances? Perhaps someone else has a better grasp of the implications of FlexibleInstances? > > Take care, > Peter > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > wxhaskell-users mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users |