From: Eric Y. K. <eri...@gm...> - 2007-07-22 19:23:20
|
Hi wxhaskellers, Just forwarding a comment from Neil on Haskell Caf=E9. He has expressed a similar sentiment on #haskell a long time ago (which I think I have relayed as well). For the record, my participation in this project consists of reviewing incoming patches (if nobody else does), and pushing them to darcs. To be honest, I'm stretched too thin for even this meager job. Luckily, there have not been any patches for a while :-/. That said, I think wxhaskell is really handy. I like having a native GUI on every major platform (may not be perfect, but is a good compromise) and I like the relatively high level library. So it would be *really* nice to keep this project alive. I'll bet other users on this list agree with this sentiment. Jeremy and friends: anybody still have time to be working on this? And wxhaskell-users, are any of you willing to step up and take over the patch review job? Thanks! Neil Mitchell said: > Hi Bulat, >=20 > > can anyone provide wxHaskell already compiled/compilable with ghc 6.6.1= on > > Windows? >=20 > This is precisely the reason I switched to Gtk2Hs - Duncan provides > Windows installers as each new GHC release comes out. If wxHaskell > wants to stand any chance as an alternative GUI framework there really > _must_ be Windows binaries released concurrently with GHC versions... >=20 > Thanks >=20 > Neil --=20 Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon fran=E7ais. |
From: Neil M. <ndm...@gm...> - 2007-07-22 19:32:29
|
Hi Eric, > Just forwarding a comment from Neil on Haskell Caf=E9. He has expressed = a > similar sentiment on #haskell a long time ago (which I think I have > relayed as well). I just want to make it clear than I appreciate the work that has been done with wxHaskell, and indeed, it was the first Haskell GUI I started using. I have no particular desire for wxHaskell to be extended, but because every successive version of GHC is incompatible with the binaries, it is essential (in my opinion) that each GHC release has a corresponding wxHaskell Windows binary. I'm guessing that the job of producing a Windows installer is fairly easy, given the right build setup. Is there no Windows wxHaskell developer who is in a position to do this? Thanks Neil > > For the record, my participation in this project consists of reviewing > incoming patches (if nobody else does), and pushing them to darcs. To > be honest, I'm stretched too thin for even this meager job. Luckily, > there have not been any patches for a while :-/. > > That said, I think wxhaskell is really handy. I like having a native > GUI on every major platform (may not be perfect, but is a good > compromise) and I like the relatively high level library. So it would > be *really* nice to keep this project alive. I'll bet other users on > this list agree with this sentiment. > > Jeremy and friends: anybody still have time to be working on this? And > wxhaskell-users, are any of you willing to step up and take over the > patch review job? > > Thanks! > > Neil Mitchell said: > > Hi Bulat, > > > > > can anyone provide wxHaskell already compiled/compilable with ghc 6.6= .1 on > > > Windows? > > > > This is precisely the reason I switched to Gtk2Hs - Duncan provides > > Windows installers as each new GHC release comes out. If wxHaskell > > wants to stand any chance as an alternative GUI framework there really > > _must_ be Windows binaries released concurrently with GHC versions... > > > > Thanks > > > > Neil > > -- > Eric Kow http://www.loria.fr/~kow > PGP Key ID: 08AC04F9 Merci de corriger mon fran=E7ais. > > |
From: Eric Y. K. <eri...@gm...> - 2007-07-22 19:46:05
|
Hey Neil, On Sun, Jul 22, 2007 at 20:32:28 +0100, Neil Mitchell wrote: > I just want to make it clear than I appreciate the work that has been > done with wxHaskell, and indeed, it was the first Haskell GUI I > started using. Yep! I didn't feel any acrimony in your mail. Was forwarding it because I thought it was a useful remark and we needed the poke :-) > I have no particular desire for wxHaskell to be extended, but because > every successive version of GHC is incompatible with the binaries, it > is essential (in my opinion) that each GHC release has a corresponding > wxHaskell Windows binary. Indeed. In Jeremy's 'Reviving wxHaskell' mail, we had fixed some modest objectives, which were >> * Patches to ensure that wxHaskell compiles against latest wxWidgets >> versions on Mac, Linux and Windows (exists today) =20 Well, we got that working for wxWidgets 2.6, but this is a moving target and now it no longer compiles with 2.8. There is a hack floating around on the net which consists of using 2.4 compatibility and telling wxhaskell that really it's compiling against 2.4. Not sure that's the right way to go about it though. Alas, we are moving more slowly than our target. >> * Add Eric Kow's Unicode patches (exist today) Check. Unfortunately, I have not been able to back this up with any rigourous testing. Just a little demo program in the samples directory. >> * Produce suitable binary packages for whatever targets we can get=20 >> maintainers for, compatible with up-to-date versions of both GHC and >> wxWidgets. Uhh.... >> * Improve samples and documentation. I think we'd better ditch this objective and just focus on getting this thing out the door, imperfect as it may be. > I'm guessing that the job of producing a Windows installer is fairly > easy, given the right build setup. Is there no Windows wxHaskell > developer who is in a position to do this? I think Shelarchy might be our Windows guy. Any comments, Shelarchy? --=20 Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon fran=E7ais. |
From: shelarcy <she...@gm...> - 2007-07-24 00:38:52
|
Hello Eric, On Mon, 23 Jul 2007 04:46:00 +0900, Eric Y. Kow <eri...@gm...> wrote: >>> * Produce suitable binary packages for whatever targets we can get >>> maintainers for, compatible with up-to-date versions of both GHC and >>> wxWidgets. > > Uhh.... > >>> * Improve samples and documentation. > > I think we'd better ditch this objective and just focus on getting this > thing out the door, imperfect as it may be. > >> I'm guessing that the job of producing a Windows installer is fairly >> easy, given the right build setup. Is there no Windows wxHaskell >> developer who is in a position to do this? > > I think Shelarchy might be our Windows guy. Any comments, Shelarchy? Yes, I'm Windows developper and I put a few version of Windows installer on my project( Kamiariduki)'s file space. http://sourceforge.net/project/showfiles.php?group_id=168626 But ... there is a problem. First, it's not official release. People search binary file for wxHaskell's website first, and if they don't get any imformation that, many of probabry give up to use wxHaskell. Some people try to build wxHaskell, but sadly this is not easy task. Because wxHaskell site's Building Guide is out of date. Okay, we have another imformation on Haskell.org, but this is not easy to reach there. http://www.haskell.org/haskellwiki/WxHaskell/Install Some people reached unofficial release fortunately. (This is very difficult. Because there is no link from official pages.) But it's just unofficial release, so they can't expected to get binary as soon as new GHC is released or solving building problem (if that is occur). SourceForge don't accept same name. So I don't want to put new binary, if anyone donesn't say problem. I want to hold name to use more better patched version (e.g. version of supporting more wxWidgets' feature). I think unofficial release must make good the shortage for official release, not release constantly instead of releasing official one. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
From: Neil M. <ndm...@gm...> - 2007-07-24 09:06:12
|
Hi > Yes, I'm Windows developper and I put a few version of Windows installer > on my project( Kamiariduki)'s file space. > > But ... there is a problem. > First, it's not official release. Why not? Can't this be promoted to the "official windows version"? It seems the problem I've been complaining about has been solved modulo alpha renaming! Thanks Neil |
From: Eric Y. K. <eri...@gm...> - 2007-07-24 04:57:56
|
Hi, On Tue, Jul 24, 2007 at 09:39:21 +0900, shelarcy wrote: > Some people try to build wxHaskell, but sadly this is not easy task. > Because wxHaskell site's Building Guide is out of date. > Okay, we have another imformation on Haskell.org, but this is not > easy to reach there. We have full control of the wxhaskell homepage (it's in the darcs repo), so couldn't we at least update the official build instructions? Cheers, --=20 Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon fran=E7ais. |
From: shelarcy <she...@gm...> - 2007-08-16 08:38:56
|
Hi, On Tue, 24 Jul 2007 13:57:50 +0900, Eric Y. Kow <eri...@gm...> wrote: >> Some people try to build wxHaskell, but sadly this is not easy task. >> Because wxHaskell site's Building Guide is out of date. >> Okay, we have another imformation on Haskell.org, but this is not >> easy to reach there. > > We have full control of the wxhaskell homepage (it's in the darcs repo), > so couldn't we at least update the official build instructions? Now I almost finished to work with adding my interesting features. So, I'm strating to update the build instructions. But ... I changed my mind that wxStyledTextCtrl's --with-stc option isn't reasonable. Because I found wxc already has some contrib libraries layer (e.g. gizmos is wrapped by eljgizmos, svg wrapped by eljdcsvg.cpp ...), and you can install all contrib libraries by using make install at once in contrib/src directory, instead of installing per libraries. So I want to change building process. But ... we have two option. 1. Change --with-stc to --with-contrib - this is conservative way. Merit - Building process is simpler. But we already has complexy by supporing GHC 6.6.x or higher. So we don't expect much. Demerit - We need to add #ifdef compilation flag when we want to support other contrib libraries. It's messy work. - Users must check supporting feature on their wxHaskell, When they want to use contrib libraries. And If there isn't, they must build wxHaskell again. 2. Support contrib libraries in default configuration. Merit - The reverse side of 1.'s Demerit. Demerit - User must build and install contrib libraries, before building wxHaskell. So they can meet building problem. But we can solve it by updating building Guide (And I'm doing that). I already provided patch 1. to Windows platform by this patch. http://www.mail-archive.com/wxh...@li.../msg00198/darcs73b086 > Sat Aug 11 22:28:34 =93=8C=8B=9E (=95W=8F=80=8E=9E) 2007 shelarcy <shelarc= > y...@gm...> > * Support builing without STC library for wxWidgets 2.6.4 Becuase current we can't build wxHaskell with wxWidgets 2.6.4 by current Visual Studio project. (I'm sorry for forgotten to notice Visual C++ issue.) http://www.haskell.org/pipermail/haskell-cafe/2007-July/029439.html And If we choose 2., I withdraw this patch. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
From: Eric Y. K. <eri...@gm...> - 2007-08-16 20:08:08
|
> 2. Support contrib libraries in default configuration. > Merit > - The reverse side of 1.'s Demerit. > Demerit > - User must build and install contrib libraries, before building > wxHaskell. So they can meet building problem. But we can solve > it by updating building Guide (And I'm doing that). You seem to be saying that this is the simpler choice as far as the code goes. I also get the impression that it is the most straightforwardly extensible, so I suppose this is what I would support. --=20 Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon fran=E7ais. |
From: Jeremy O'D. <jer...@gm...> - 2007-08-20 15:42:27
|
Hmm, Somehow I missed this when I sent out a mail on almost the same subject just now... On 16/08/07, Eric Y. Kow <eri...@gm...> wrote: > > 2. Support contrib libraries in default configuration. > > Merit > > - The reverse side of 1.'s Demerit. > > Demerit > > - User must build and install contrib libraries, before building > > wxHaskell. So they can meet building problem. But we can solve > > it by updating building Guide (And I'm doing that). This really only works as an option if we decide that users must build wxWidgets from source *before* they can build wxHaskell. > You seem to be saying that this is the simpler choice as far as the code > goes. I also get the impression that it is the most straightforwardly > extensible, so I suppose this is what I would support. It is certainly the simplest option in terms of maintaining wxHaskell, but I think it means that we need to provide compiled binary packages for wxWidgets on all supported platforms, since it is not particularly straightforward to build wxWidgets appropriately for use with wxHaskell (especially under the latest versions of Visual Studio - Microsoft have replaced DLL hell with manifest hell. Grr...) It's likely to be irritating to Linux users who are used to "apt-get install wxWidgets" as their usual approach to installing libraries. I've detailed what would probably be needed to cleanly support contrib in the other mail. In short, it's a directory structure (and Haskell modules) per contrib module. I'd prefer to do it in as clean a manner as possible, but I admit that it's far from easy to get right. Regards Jeremy |
From: shelarcy <she...@gm...> - 2007-08-20 17:48:14
|
Hi Jeremy, On Tue, 21 Aug 2007 00:42:26 +0900, Jeremy O'Donoghue <jer...@gm...> wrote: > On 16/08/07, Eric Y. Kow <eri...@gm...> wrote: >> > 2. Support contrib libraries in default configuration. >> > Merit >> > - The reverse side of 1.'s Demerit. >> > Demerit >> > - User must build and install contrib libraries, before building >> > wxHaskell. So they can meet building problem. But we can solve >> > it by updating building Guide (And I'm doing that). > > This really only works as an option if we decide that users must build > wxWidgets from source *before* they can build wxHaskell. Really? I think that nowadays wxWidgets packager worried about wxPython. And wxPython depends on contribs. http://www.wxpython.org/builddoc.php So macports' wxWidgets also support contribs. http://svn.macports.org/repository/macports/trunk/dports/graphics/wxWidgets/Portfile http://svn.macports.org/repository/macports/trunk/dports/python/py-wxpython/Portfile And according to below Packages' information, libwxgtk-dev package depends on wx-common package and wx-common replaces libwxgtk2.4-contrib-dev package. http://apt.tt-solutions.com/debian/dists/etch/main/binary-i386/Packages So I want to know about wxWidgets package's condition. > It's likely to be irritating to Linux users who are used to "apt-get > install wxWidgets" as their usual approach to installing libraries. Is this right? Any packages system's wxWidgets doesn't have contrib? Or any package system doesn't choose version that supports contrib? Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
From: Jeremy O'D. <jer...@gm...> - 2007-08-21 09:12:59
|
Hi Shelarcy, On 20/08/07, shelarcy <she...@gm...> wrote: > > On Tue, 21 Aug 2007 00:42:26 +0900, Jeremy O'Donoghue <jer...@gm...> wrote: > > > > This really only works as an option if we decide that users must build > > wxWidgets from source *before* they can build wxHaskell. > > Really? > I think that nowadays wxWidgets packager worried about wxPython. > And wxPython depends on contribs. > > http://www.wxpython.org/builddoc.php [snip other examples of bindings depending on contrib] > So I want to know about wxWidgets package's condition. > > > It's likely to be irritating to Linux users who are used to "apt-get > > install wxWidgets" as their usual approach to installing libraries. > > Is this right? > Any packages system's wxWidgets doesn't have contrib? Or any package > system doesn't choose version that supports contrib? So far as I can tell, Debian supports contrib on wxWidgets 2.4 but not 2.6 (and doesn't yet have a wxWidgets 2.8 package), so I do think this is an issue, e.g.: http://packages.debian.org/unstable/libdevel/libwxgtk2.4-contrib-dev http://packages.debian.org/unstable/libdevel/libwxgtk2.6-dev However, I'm convinced by your argument that the contrib components are useful, and that we should depend on them - I think that all it means is that we need to provide binaries for wxWidgets for those who have neither the time nor inclination to build themselves. Therefore, I'll complete the updates to the build system on the basis that contrib components (and OpenGL support) have been compiled into wxWidgets. Regards Jeremy |