Re: [wxhaskell-devel] The future of wxC
On 16 January 2012 00:46, Eric Kow eric@gmail.com wrote: I was going to post on your blog, but you beat me to mentioning it. So better hear it from me, you should totally use GitHub for wxC. Plus it would be a chance to work with darcs-bridge maybe. 1. Eric will probably kill me for saying this, but I think GitHub is probably the right place, possibly keeping Sourceforge as the project website and distribution point (I personally don't much like git, but it has mindshare, and probably makes more sense than Darcs for a non-Haskell project - plus my experience with patch-tag and darcsden has been that 'getting going' on a Windows machine is far from trivial). I could be persuaded to change my mind on this one, but probably only if one of the Darcs hosts can get the experience 'right' on Windows clients. 2. Keep the Cabal-based build system to start with, until there is clear evidence of non-Haskell contributions. 1. If wxC turns out to have legs, the main areas to attack should be: 1. Move to bakefile based build. 2. Automated generation of the binding. If I may weight in.. I like the idea of moving wxC to a separate project, to at least open it up to other communities, and I'd be happy to have it on GitHub, if that's the consensus. What ever decision we make, do we want to hold off the move on to code.haskell.org until we've made a decision? Actually, it might be easier to get moved across in our current state, and then move out wxC afterwards? R.e. Point 1.2. In the list above, I've been keeping half an eye on this -cafe thread, which seems to be getting more attention than I had anticipated: http://www.mail-archive.com/haskell-cafe@haskell.org/msg96678.html I may be getting ahead of myself.. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] The 'making wxC build on all platforms thread
Hi all, Sorry I've been a little quiet the last week or two, rest assured I have lurking all along. On 22 January 2012 00:37, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: I now have wxC building on Windows. Details below and patches attached. Excellent! I'll take a look. Jeremy On 18 January 2012 23:34, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: On 17 January 2012 22:40, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: On 17 January 2012 21:38, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: Hi all, I have collected together all of the people who I know are making the effort to build Dave's latest code on different platforms. I'd also like to introduce Andrej, who is testing wxC in the context of D (so could we go easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in this thread :-) I'd suggest that we try to pull together all of the experiences into a single thread - makes it easier for people to keep up. For the moment, I'd like to bring up my experience with wxC on Windows: First, you need at least a patch to wx-config-win32 which sorts out library names (msys libraries are incorrectly named due to a 2.8/2.9 change) At line 948 of wx-config-win.cpp, you need: if (cfg[BUILD] == “debug” cfg[DEBUG_FLAG] == “default”) po[WXDEBUGFLAG] = “”; if (cfg[DEBUG_FLAG] == “1″) po[WXDEBUGFLAG] = “”; Second, in wxc/Setup.hs you need to change line 82 (just after output readProcess “wx-config” [--libs, std,gl,stc,xrc,richtext,aui,media, --cppflags] “” This is needed because wx-config-win does not support the new ‘all’ flag, and I haven’t had time to fix wx-config-win properly. Third, the library then builds for me, but fails to link (link errors in StyledTextCtrl). I hope to work out why tonight or tomorrow. I've worked out why, but haven't fixed it. wx-config-win doesn't know about some of the new libraries, and is giving incorrect results in other cases. I don't have time to fix this tonight, but: C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxcwx-config --libs base,gl,xrc,richtext,aui,media returns -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_richtext -lwxmsw29u_gl -lopengl32 -lglu32 -lwxmsw29u_media -lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxcwx-config --libs returns -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_html -lwxmsw29u_adv -lwxmsw29u_core -lwxbase29u_xml -lwxbase29u_net -lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lw xregexu -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 Missing base libraries in red. I'll try to fix this tomorrow. I have managed to make wx-config-win work, at least for my configuration. There is a known bug which I lack the will to fix right now - the command line parser in wx-config-win is very rudimentary and thinks that wx-config --libs all --cppflags is looking for the additional library --cppflags. The work-around is to call wx-config --cppflags --libs all - I have changed wxc\Setup.hs to call wx-config this way. Changes to wx-config-win are quite numerous. The most notable is that the Unix wx-config has the set of libraries available (e.g. for all) hard-coded into it (when wx-config.in is turned into wx-config by configure). On Windows this is not possible, so I have written a function which goes to the library directory of the selected wxWidgets install and enumerates all of the wx-related libraries. This is a bit fragile really, since it assumes that future wxWidgets libraries follow the current naming convention, but it works for now. I don't have access to the wx-config-win svn repo, so the updated file is attached. Oh, and it also builds under VS2010 now (I wanted a decent debugger!). A couple of minor patches were needed to wxc to make it build. These are: - Reversed the order of libraries, to correctly permit static linking (because MinGW GCC actually statically links the implibs). - Don't specify wxWidgets version for Windows (wx-config-win doesn't support). We do show the detected version, however. - Work-around for the wx-config-win --cppflags bug noted above. - Add the -Wl,enable-auto-import link flag on Windows, which gets rid of a lot of spurious link warnings. - Made wxc.a and wxc.dll build in the dist\build directory, so install succeeds. - Added undef cases for wxAUI event wrappers I am now failing to build wxcore. This is faling to find the wxc header files on Windows (it is looking for them in ./include/wxc). I notice that Dave has already marked the wxcInstallDir function as dubious, so I'll
Re: [wxhaskell-devel] I declare the wxHaskell repo open for merging of wxWidgets 2.9.x support
On 15 January 2012 22:38, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: Hi developers, Think the subject says it all :-) Bwahahahaa. So, this is code.haskell.org? How does one go about obtaining access? Jeremy -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
On 12 January 2012 15:09, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: Thank you Kenneth, That's an extremely detailed and complete set of notes. It is very much appreciated. I'd also like to offer my thanks, this is extremely useful to us. Best regards Jeremy On 12 January 2012 14:52, Frodo Kenny frodoken...@gmail.com wrote: Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci. Here are some notes and patches for OS X. I'm running Lion (10.7.2) and getting wxwidgets running actually took the most time. 1) wxwidgets First of all, Haskell and wxwidgets must use the same architecture, i.e. both 32-bit or both 64-bit. This never occurred to me, well spotted. We should check this, so I've created a ticket: https://sourceforge.net/tracker/?func=detailaid=3472972group_id=73133atid=536848 The standard build is 64-bit, but wxwidgets includes the QuickTime framework which is only available in 32-bit. It builds and ghc only gives a warning, but ghci will give an error (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture). To build 32-bit you can use --enable-macosx_arch=i386. It looks like quicktime is only used for PICT support, which is disabled in 64-bit builds anyway, so I made a patch that disables quicktime for both 32 and 64 bit cocoa builds. By further disabling the ppc architecture, we can make a universal 32/64-bit binary with: =remove -arch ppc in configure =remove -framework QuickTime in configure =remove PICT by __LP64__ - __WXOSX_COCOA__ in bitmap.c, fontenum.c, metafile.cpp ./configure --disable-debug --disable-dependency-tracking --with-osx_cocoa --disable-webkit --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk --with-macosx-version-min=10.6 --enable-universal_binary make install Note that on lion with the latest Xcode, 10.6 is the lowest sdk version. I use Homebrew so I attached a formula for it. To install homebrew: /usr/bin/ruby -e $(curl -fsSL https://raw.github.com/gist/323731) Then put wxosx.rb in /usr/local/Library/Formula and run: brew install wxosx I'm not an OS X person, so this doesn't really mean anything to me; is it something which should be on the wiki? 2) wxhaskell installing wxc gives: cd wxc cabal install - error wxEVT_WEBKIT_ was not declared… so I disabled webkit in wxwidgets above. -ld: file not found: undefined =change -Wl,undefined to -Wl,-undefined in linkCxxOpts in Setup.hs installing wxcore -* Missing C library: wxc name is wxc.so instead of libwxc.dylib =change for sharedLibName: OSX - lib ++ addExtension basename .dylib in Setup.hs ghc --make HelloWorld.hs Undefined symbols for architecture x86_64: _expEVT_DIALUP_DISCONNECTED I don't know where this is coming from (dialupman is enabled in wxwidgets) so I commented out the DIALUP lines in wxc_glue.h ./HelloWorld - dlopen(dist/build/libwxc.dylib) failed The final problem is that a dylib contains an absolute paths used for linking, and the library is expected to be found at that locations. To set this path we must pass the -install_name argument when linking libwxc.dylib = OSX - [-dynamiclib, -o ++ out_dir / sharedLibName ver basename, -install_name ++ basepath / sharedLibName ver basename, -Wl,-undefined,dynamic_lookup] in linkCxxOpts, thus needing an extra basepath argument this is found by adding = inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr local_bld_info NoCopyDest to myBuildHook and also using an extra argument for linkSharedLib. Thank you very much for the patch, but I have one tiny request: I can't apply wxhaskell-osx.patch because the structure doesn't match the one on my system. Could you record it with darcs and send the patch bundle as an attachment (darcs send -o mypatch.dpatch) http://darcs.net/manual/Darcs_commands.html#SECTION00661000 http://darcs.net/manual/Darcs_commands.html#SECTION00664000 Also, if you record the patches your name will forever be attached to them and you will received the karma you deserve :) 3) using wxhaskell ghc --make seems to work with the limited testing that I did ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread. ghci creates a new thread for each computation and under os x the gui apparently must run on the main (first) thread. This is solved by: ghci -fno-ghci-sandbox Another good tip for the wiki perhaps? I wonder if there is a way to indicate at a package level that this is required? However, keyboard input is not directed to the gui but to the ghci terminal… There used to be an EnableGUI module to fix this (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not seem to work anymore. The window can be closed and restarted from ghci though. However, the
Re: [wxhaskell-devel] Weird implementation of wxTreeCtrl_GetBoundingRect
On 11 January 2012 00:56, Dave Tapley duked...@gmail.com wrote: Does anyone know why wxTreeCtrl_GetBoundingRect is implemented [1] such that: 1. It returns a null pointer on non-Windows platforms. 2. It disregards the returned value and returns GetRect(). It came in with: wxhaskell-from-cvs @ 2004-09-14 10:27:48 by dleijen. Dave, [1] http://darcsden.com/DukeDave/wxhaskell-dev/wxc/cpp/treectrl.cpp#L-535 Well, I've 'fixed' it, and it appears to work just fine in Ubuntu: http://darcsden.com/DukeDave/wxhaskell-dev/patch/2012050758-a1f0b I'm still curious if anyone can answer my original two questions. -- 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 wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2
On 9 January 2012 22:19, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: On 9 January 2012 18:09, Dave Tapley dave.a.tap...@gmail.com wrote: On 9 January 2012 17:04, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: On 6 January 2012 16:02, Dave Tapley dave.a.tap...@gmail.com wrote: 2012/1/6 shelarcy shela...@gmail.com 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
Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2
2012/1/8 shelarcy shela...@gmail.com Hi, I think that we can remove old-time dependency from wxcore now. Because wxcore uses old-time's System.Time modules in only Graphics.UI.WXCore.Db module, and that module is removed this version. I attached a patch for removing old-time dependency in Dave's wxhaskell-dev branch. (This patch also includes one more change that removing unused wxhaskell/src/eiffel directory.) Thanks again, I've applied these to my branch also. It's funny you should spot that unnecessary old-time dependency now, because I spotted and removed the .Db sample code at at almost exactly the same time (I was trying to build all the samples..): http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120107182358-a1f0b Best Regards, On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue jeremy.odonog...@gmail.com 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. (snip) 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 shelarcyhotmail.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 wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2
On 9 January 2012 17:04, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: Hi Dave, all On 6 January 2012 16:02, Dave Tapley dave.a.tap...@gmail.com wrote: 2012/1/6 shelarcy shela...@gmail.com 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
Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2
2012/1/6 shelarcy shela...@gmail.com 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 jeremy.odonog...@gmail.com 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 shelarcyhotmail.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 wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Happy New Year, wxHaskellers
On 4 January 2012 18:23, Eric Kow eric@gmail.com wrote: On 4 Jan 2012, at 16:59, Dave Tapley wrote: Also, I imagine that while this brings us closer to wxHaskell in GHCi, we would still need to solve the second start crash? https://sourceforge.net/tracker/?func=detailaid=1610984group_id=7the3133atid=536845 Well, I just had a look, and that issue seems to have gone away in my darcsden branch! I've added a comment to the tracker. Wow! If this works, Conal might be pleased. It certainly seems to, insomuch as the given test code no longer causes a crash :) By the way, you mentioned wx-config (I get the feeling you'd asked me a direct question and I forgot to answer). Did you have a look at the Haskell code in our repo which provides a wx-config replacement? The replacement is very very stupid and needs generalising, but it might be easier to bring it closer to the kind of completeness we need than to maintain the C++ one. Ah, yes, I suspected this would need some debate. I was on the cusp of merging in your wx-config implementation, namely: http://darcsden.com/kowey/wxhaskell/browse/wx-config/ But then I got a reply from the previous project leader wx-config-win: http://code.google.com/p/wx-config-win/ He had hoped that one day wx-config-win might be merged in to wxWidgets, but noted that it had fallen behind the project and had several known issues: http://code.google.com/p/wx-config-win/issues/list Personally I feel that (for similar arguments to those for maintaining wxC as a language-agnostic project) we should pursue wx-config-win. Thoughts? -- Eric Kow http://erickow.com -BEGIN PGP SIGNATURE- iEYEARECAAYFAk8EmT4ACgkQBUrOwgisBPnz/wCdEapNshQh+ZqEh2SyyXi/uXO9 5lcAnRymzM7qQnzru6cdKpoTqZZ3kQM4 =hcbP -END PGP SIGNATURE- -- 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 wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Happy New Year, wxHaskellers
On 2 January 2012 08:48, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: Hi lists, A Happy New Year to all, and with it a chance to talk about some imminent changes in wxHaskell. There is nothing new in this mail for those who follow the wxhaskell-devel list, but for users who are interested in the evolution of the project, I thought this would be a good time to summarise. First, there will be a new release of wxHaskell in the next few days. This is mainly a bugfix edition, but also reinstates some features which were lost with Cabalization. Specifically: - Styled Text Control support - OpenGL support - Support for building on Haskell Platform 2011.4 This will be the last update of wxHaskell to support the wxWidgets 2.8.x releases. Thanks for taking care of this last release Jeremy :) Following shortly afterwards, the very exciting news is that a number of people (Dave Tapley in particular) have been putting a lot of work over the last few months towards support of the wxWidgets 2.9 releases. This does introduce a small number of breaking changes as the wxWidgets API has changed in places, but brings with it quite a number of improvements: Just to note again, I've been pushing all my 2.9 dev work here: http://darcsden.com/DukeDave/wxhaskell-dev That branch's wxC configure will fail if wx-config reports a version other than 2.9.x, see readWxConfig in: http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs - wxC is built as a shared library. This means that wxHaskell works in GHCi again, which has been one of the most requested bugfixes over the past 18 months or so. - Support for wxPropertyGrid and associated classes. - Support for the wxWidgets AUI classes. - Support for wxMediaControl. - Removal of legacy use of Eiffel files to generate constant definitions. This is only of interest to developers, but is far cleaner. - Build system improvements to reduce 'unnecessary' rebuilding of source files - again, one for developers. - Support for 64bit OS X platforms. We will make a release of wxHaskell with all of the new features soon after the changes have been merged into the main repository, and have been more fully tested on all of our supported platforms. Yes the testing on more platforms is where the emphasis needs to be here. I'm primarily working in Ubuntu, but I did do a small amount of work trying to ensure Windows is supported in my branch. One hurdle I ran in to is that wx-config-win is unmaintained and no longer works with wxWidgets 2.9.x: http://code.google.com/p/wx-config-win/ The good news is that I emailed the old maintainer and he both responded and made me an owner of that project. I just need to make some small changes there, and then we should be able to get wxHaskell building in Windows against 2.9.x, see here: http://code.google.com/p/wx-config-win/issues/detail?id=21 Best regards Jeremy -- 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 wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- 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 wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
On 12 December 2011 17:18, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: Hi Dave, all, This is fantastic news - especially the bit about GHCi. I have put a couple of general comments inline, but it looks like you have found most of the issues, at least on Linux. I think that at least some of the issues would go away if, as you say, we could have an entirely separate cabal project (perhaps wxc) for this shared library, and then have wxcore depend on it? In this case, we would be able to ensure that libwxc.so.x.y.z (or wxc.dll or libwxc.dylib or whatever) was in a 'normal' place before wxcore gets built. On 9 December 2011 14:13, Dave Tapley duked...@gmail.com wrote: On 8 December 2011 22:34, Dave Tapley duked...@gmail.com wrote: Hello everyone, I wrote a story, and I invite you all to comment and help me make it better. As an experiment I've decided to put it on hpaste instead of having the mail thread get out of hand (I'm also cross posting it to the cabal list and have mentioned it in #haskell, and I want to keep all correspondence in one place): http://hpaste.org/55027 Ha, well that was good timing for hpaste to go down! Here's it is: I've been trying to resurrect the idea of building a shared library for the C++ component of the wxhaskell library. Jeremy (to my knowledge) first put this forward, here: http://wewantarock.wordpress.com/2010/11/01/working-around-the-static-libstdc-restriction/ In addition to the advantages he lists there, I have the following reason: When building wx-core (in its current incarnation) cabal will *always* rebuild all the C++ code, which takes a majority of the build time. This becomes very frustrating when you change one line of Haskell and have to wait seven minutes to rebuild. I complained about it here: http://sourceforge.net/mailarchive/message.php?msg_id=2807 So, I decided to try and stop this complete C++ rebuild, I partially succeed, but I eventually got stuck for reasons I complained here: http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html Side note: I did eventually discover why (or, where) the c-sources (cSources) list is used to compile and link, and it is here: http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-GHC.html#buildLib You can see: | filename - cSources libBi] under -- build any C sources, and you can see: cSharedObjs = map (`replaceExtension` (dyn_ ++ objExtension)) (cSources libBi) under -- link:. Is this assumption correct? This is correct - it's the standard way Cabal builds C/C++ code. To be honest, this is really a consequence of the fact that Cabal is more of a tool for simple distribution than a Make replacement, and the developers probably didn't expect Cabal would be used to build large bodies of C++ code. My approach is far from perfect, too - in fact it is incorrect because I don't do dependency tracking on header files, so if you edit a header, it (incorrectly) fails to rebuild. This is because I wasn't keen on rewriting 'make' in the wxHaskell build system - it seems to me like something Cabal could usefully support. I did play with some very hacky code which automatically rebuilt all of the C++ code if any header is newer than any C++ source. This is aesthetically dreadful, but it somewhat captures the reality, since in practice, pretty much all of the C++ files depend on all of the headers (and it's easy to write). On reflection, we should probably do this as what exists at present could lead to unexpectedly incorrect code being generated if someone is in full flow of development. I'll see if I can dig up some code - I think I have it somewhere. You know, I'm surprised this didn't occur to me until now: Does the C++ code actually need to use cabal at all? If it's a separate project, perhaps it would be more sensible to use a C++ oriented build system? Then, unless I'm missing something, it can install the headers somewhere, and wxcore can run wxdirect on the headers are currently. The big disadvantage I can see with moving the C++ out of the wxcore project is lots of pain for users when they 'cabal update' and suddenly wxcore fails because they need to update the C++ headers / library. Another disadvantage is that this will make development a little more painful (although the time saved not having to rebuild all the C++ is a huge bonus) because you wouldn't (without some hackery) be able to use cabal-dev as described here: http://haskell.org/haskellwiki/WxHaskell/Development/Environment#Building_and_testing_wxHaskell I happened upon this (dead) project, which I seems to have the goal I am outlining: http://wxc.sourceforge.net/ At this point I thought about either: 1. Getting the cabal source and starting to write code to give BuildInfo a cObjs in addition to cSources. 2. Picking up Jeremy's shared library code, so wxhaskell would have its own code to build the library
[wxhaskell-devel] No more Eiffel
Firstly I'd like to say thanks to Eric for offering up these patches, I've only been working with wxHaskell for a few months, but I must say I wholeheartedly welcome the work; I for one don't want to see wxHaskell go the same way as ewxw! I just have a few requests/questions for you Eric: 1. Could you indicate exactly which patches are required (I've never applied a darcs patch from an email, so I'm curious to try), or: 2. Are the patches available on a darcs repo somewhere? Either way I'd like to get the de-eiffel-ification in to my darcsden wxhaskell-devel branch[1] 3. I see that you've removed all the wxACCEL_ALT: INTEGER is 1 style constant exports; with them removed how to do the constants get exposed in Haskell? 4. How WIP do you mean by WIP? :) Cheers! Dave, [1] http://darcsden.com/DukeDave/wxhaskell-dev -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] OpenGL support
Hi again Jeremy, Did the work on OpenGL, or the branch you mention on darcsden[1] ever get anywhere? I'd like to nominate myself to work on it :) I've created my own wxhaskell branch on darcsden[2], to which I'm committing all the wx-2.9 dev build / GTK2 / I don't care about supporting wx 2.9 patches I've been accumulating over the past few months. [1] http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00925.html [2] http://darcsden.com/DukeDave/wxhaskell-dev -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] SourceForge project
Hi all, would someone like to add me (davetapley) to the SourceForge.net project. It doesn't look like there has been much activity on it, I assume this is just through lack of interest/development, and not because we've moved somewhere else? I'd like to start looking at getting OpenGL support back in, and I thought I might as well pick up this[1] ticket if I'm going to do so. Thanks, Dave [1] https://sourceforge.net/tracker/?func=detailatid=536848aid=2992082group_id=73133 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] Wrapping wxAny
Hi all, I've spent a few hours now trying to wrap the wxAny class, I just wondered if anyone had given any thought to this (or it's 2.8 predecessor: wxVariant) already? It's needed because I'm wrapping this functionality: http://docs.wxwidgets.org/2.9.2/classwx_property_grid_event.html#577d7fb277be169e295726878dcbb7db (wxVariant is automatically promoted to the preferred wxAny in 2.9) Dave, -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Wrapping wxAny
Hi all, I'm still struggling along with this. I've summarised my current problem here: http://hpaste.org/51854 If any of you would be kind enough to take a look. Dave, On 27 September 2011 21:05, Dave Tapley duked...@gmail.com wrote: Hi all, I've spent a few hours now trying to wrap the wxAny class, I just wondered if anyone had given any thought to this (or it's 2.8 predecessor: wxVariant) already? It's needed because I'm wrapping this functionality: http://docs.wxwidgets.org/2.9.2/classwx_property_grid_event.html#577d7fb277be169e295726878dcbb7db (wxVariant is automatically promoted to the preferred wxAny in 2.9) Dave, -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] wxString handling broken when using wx 2.9
On 20 September 2011 20:57, Dave Tapley duked...@gmail.com wrote: Hi Eric, Am I correct in recalling that you did some of the work to get wxHaskell supporting unicode? I've using wxHaskell with wxWidgets 2.9.2 (the latest development release) and it seems that any attempt to get back a wxString in Haskell code will result in a Prelude.chr: bad argument: crash at run time; I've verified that the same code works correctly with wxWidgets 2.8. A good example is ./samples/wx/ListCtrl.hs, you will get the crash when you click on an item in the list. Now the good news is that this is almost certainly related to the changes to unicode handling in wxWidgets: http://docs.wxwidgets.org/2.9/overview_changes_since28.html But I thought I'd send out a message asking for a sanity check before I get too busy working on fixing it. Dave, Good news everyone! This is fixed, at least for GTK2 with wx-2.9, I don't know if it breaks building against previous versions, perhaps someone would like to find out? Dave, Patch attached. fix_for_prelude_chr_error Description: Binary data -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Compile time for wxcore
On 21 September 2011 17:33, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: Hi Dave, On 20 September 2011 17:58, Dave Tapley duked...@gmail.com wrote: On 16 September 2011 23:30, Dave Tapley duked...@gmail.com wrote: I presume everyone has a very long compile time when building wxcore? Specifically rebuilding everything under src/cpp/ every time.. Has anyone ever looked into avoiding this complete rebuild? I've just spent a few hours looking deeper in to this and come across two issues: 1. There is a very informative blog post[1] written by Jeremy, which deals with the subject of Compiling C or C++ code from within Cabal. Unfortunately I can't find any of the code mentioned in the post in the project, specifically I tried to find a myBuildHook in ./wxcore/Setup.hs (I also looked in previous revisions using a trackdown grep[2]) but I didn't find anything. Perhaps someone with better knowledge of the project can comment on if/where/when the code in the post was used? The code sits on my development machine. It works, but with a fairly serious limitation. The limitation is that I do not do any dependency tracking. It works by checking if an object file is older than its corresponding source file. This works fine for .cpp files but breaks if you change a header. Short of writing a complete dependency tracker, this is hard to fix, and in truth I think it belongs in Cabal. If Cabal wants to say that it can compile C/C++ code, it should be the one to do so correctly, especially as dependency tracking for C/C++ is vile and compiler dependent(*). Firstly welcome back, and thanks for taking the time to reply :) Ah, this all makes more sense now. Do you know if there is any documentation on cabal's C/C++ compiling abilities? I still have no idea how the confHook stuff actually results in code being built, because I don't see any reference to the C++ code (i.e. wxcore/src/cpp/) in Setup.hs, only the calling of 'wxdirect' to generate them, and use of 'libBuildInfo' to set up GCC. I would be very happy to put the code out there as a GitHub gist or similar - it's only in one or two files, and quite easy to follow, but I don't feel it is ready for prime time due to the limitations noted above. Well, for me, the compile time of the C++ component is around four minutes, which proves to be a real pain when you miss one semi-colon. I'd certainly like to give your code a go, and I shall do so whilst heeding your warning :) (*) one option might be to do this only for GCC, as in practice we only really support GCC anyway. 2. Inspecting the wxdirect code you can see that System.IO.writeFile is used to write all the generated code[3], but no test is performed to see if the output file has actually changed. Thus the file is always opened for write, and so its modification time is changed, and so everything is recompiled every time wxcore is built. I have have written a local patch which replaces the writeFile function with one which first checks whether the string to be written differs (aside from date/time stamp) to the current one; it only performs the writeFile if there has been a change. Using this patch none of the Haskell code is re-built, but unfortunately all the C++ code is. This is a nice patch - I think we should apply it. Excellent, well at the moment it's a rather 'quick' implementation, comprising of the following function: writeFileIfRequired :: FilePath - String - IO () writeFileIfRequired f str = readFile f = evaluate = \str' - when (not $ and $ zipWith isSame (lines str) (lines str')) (writeFile f str) where isSame l1 l2 = (UTC `isInfixOf` l1) || (UTC `isInfixOf` l2) || (l1 == l2) You'll note the the use of (UTC `isInfixOf`), this is my nasty hack to get around the fact that the time of generation is written in to the file, and this obviously changes every time. Unless anyone has a good reason not to, I'd like to suggest we remove this generated on... lines (but leave in the don't edit this blurb), if someone really wants to know they can always check the file modification time? Dave, Jeremy -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Patches to build wxHaskell with wxWidgets 2.9.2 GTK on Linux
On 29 July 2011 08:54, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Dave Tapley wrote: Hmm, further to this: $ darcs pull Pulling from http://code.haskell.org/wxhaskell;... Official wxHaskell darcs repository ** No remote changes to pull in! $ cd wx $ cabal configure Resolving dependencies... Configuring wx-0.13.1... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package wxcore-0.13.1 requires containers-0.3.0.0 package wxdirect-0.13.1 requires containers-0.4.0.0 package wxcore-0.13.1 requires parsec-2.1.0.1 package wxdirect-0.13.1 requires parsec-3.1.1 You may need to bump dependency version. Are you using GHC 7.0? The easiest way to proceed is probably to copy the version constraints from the *latest* packages on hackage: http://hackage.haskell.org/package/wx http://hackage.haskell.org/package/wxcore http://hackage.haskell.org/package/wxdirect and then reconfigure, rebuild and reinstall these packages. Thank you for your response. I actually resolved the problem in a different way, I found my don't worry, I have fixed it email to the list sat in my drafts folder; sorry about that :| After some discussion on #haskell it transpired that it was a problem local to my machine probably caused by this 'issue': http://www.vex.net/~trebla/haskell/sicp.xhtml#pigeon Some how I had ended up with ghc-pkg having both containers-0.3.0.0 and containers-0.4.0.0 registered, with wxcore and wxdirect compiled again each one respectively. By removing everything which depended on containers-0.4.0.0 and then containers-0.4.0.0 itself I was able to rebuild and reinstall wxdirect (only after running 'cabal clean') pinned to containers-0.3.0.0, this allowed wx to configure without issue. Dave, Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Patches for wxWidgets 2.9.2 GTK2 Linux
On 29 July 2011 21:40, Dave Tapley duked...@gmail.com wrote: Hi all, So I can now build the latest from the wxHaskell darcs repo, but only after applying the attached patches. Quite a lot of them are very hack it to make it work patches, but I thought I'd offer them to the list for review before cleaning them up. Comments are welcome. Dave, Forgot to attach. patches_for_2.9.2_gtk2_linux Description: Binary data -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Property sheet
On 29 July 2011 21:49, Dave Tapley duked...@gmail.com wrote: Hi Jeremy, Did you ever make a start wrapping wxPropertyGrid? http://permalink.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1016 I'm going to have a go now. Dave, In my quest to understand how a class from wxWidgets is wrapped I took at look at wxSlider as it shares the same class hierarchy as wxPropertyGrid and 'slider' is a fairly distinct term. Searching for 'slider' in the wxHaskell code I extracted the following references to it. Does this look complete? If anyone could comment further on what function each part provides I'd be very grateful. # HAND-WRITTEN FILES # ./wx/src/Graphics/UI/WX/Controls.hs: Haskell impl ./wxcore/src/eiffel/wx_defs.e: Eiffel alias for wxEVT_COMMAND_SLIDER_UPDATED as expEVT_COMMAND_SLIDER_UPDATED ./wxcore/src/include/wxc.h: TClassDefExtend saying wxSlider95 and wxSliderMSW are wxSlider ./wxcore/src/include/wxc_glue.h: Decl of int expEVT_COMMAND_SLIDER_UPDATED(); TClassDefExtend saying wxSlider is a wxControl Decl of many wxSlider_ methods such as wxSlider_ClearSel Decl of wxXmlResource_GetSlider method ./wxcore/src/haskell/Graphics/UI/WXCore/Layout.hs: This code is commented out ./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs: Exports sliderOnCommand, sliderGetOnCommand Def for sliderOnCommand which sends wxEVT_COMMAND_SLIDER_UPDATED and take an eventHandler Def for sliderGetOnCommand which returns the event handler ./wxcore/src/cpp/extra.cpp: ifdef wxUSE_SLIDER wxT(SLIDER) ./wxcore/src/cpp/eljslider.cpp: EWXWEXPORT calls for all the wxSlider_ methods decl'd in wxc_glue.h ./wxcore/src/cpp/eljrc.cpp: BUILD_XRCGETCTRL_FN(Slider) (constructs functions for geting control pointers out of window hierarchies created from XRC files. The functions themselves) ./wxcore/src/cpp/defs.cpp:EWXWCONSTANTINT(wxEVT_COMMAND_SLIDER_UPDATED,wxEVT_COMMAND_SLIDER_UPDATED) ./wxcore/src/cpp/eljevent.cpp: MAKE_EVENT_WRAPPER(EVT_COMMAND_SLIDER_UPDATED) # MISC FILES # ./wxcore/wxcore.cabal: add src/cpp/eljslider.cpp to c-sources ./samples/test/XRCControls/XRCControls_Wx.hs: test code for xrc # GENERATED FILES # ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs: File generated by wxDirect from ./wxcore/src/include/wxc.h: Export of (wxEVT_COMMAND_SLIDER_UPDATED :: EventId) Export of many slider functions such as sliderClearSel, these match the wxSlider_ methods decl'd in wxc_glue.h Export of xmlResourceGetSlider function decl'd in wxc_glue.h Definition for slider functions using FFI foreign import ccall Definition of wxEVT_COMMAND_SLIDER_UPDATED which imports the enum value Definition of xmlResourceGetSlider using FFI foreign import ccall ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassInfo.hs: File generated by wxDirect Export of classSlider, classSlider95, classSliderMSW Export of downcastSlider, downcastSlider95, downcastSliderMSW Definition classSlider functions which bind them to the their C++ class names using a classInfoFindClass function Definition of downcast functions using an objectCast function ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs: File generated by wxDirect from ./wxcore/src/include/wxc.h: Exports Slider, TSlider, CSlider, and 95 and MSW variants Definitions of these as data types, encapsulating the class hierarchy from C++ classes. TSlider is the inheritance type, CSlider is the abstract type. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] Conflicting exports in wxcore
Yep, I see this¹ as well, I'll take a look now. Dave, ¹ http://sourceforge.net/mailarchive/message.php?msg_id=27810904 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] Patches to build wxHaskell with wxWidgets 2.9.2 GTK on Linux
Please find attached a darcs patch file with the changes I had to make to build wxcore. Feel free to have a look and comment, they are all very much make it compile changes and I suspect I may have introduced badness (returning a null pointer). Unfortunately having made these changes and following these steps¹ I am now getting this error, which is a little confusing: wxhaskell-dev/wx$ sudo cabal install --global Resolving dependencies... cabal: dependencies conflict: wxcore-0.13.1 requires containers ==0.4.0.0 however containers-0.4.0.0 was excluded because wxcore-0.13.1 requires containers ==0.3.0.0 Its other dependencies have installed correctly: wxhaskell-dev/wx$ ghc-pkg list wxdirect /var/lib/ghc-6.12.1/package.conf.d wxdirect-0.13.1 wxhaskell-dev/wx$ ghc-pkg list wxcore /var/lib/ghc-6.12.1/package.conf.d wxcore-0.13.1 Any idea what this could mean? Dave, ¹ http://haskell.org/haskellwiki/WxHaskell/Building#Source_Release patches_for_2.9.2_gtk_linux Description: Binary data -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Specifying wxWidgets version to build wxHaskell with
On 26 July 2011 06:59, Eric Y. Kow eric@gmail.com wrote: On Tue, Jul 26, 2011 at 00:28:01 +0100, Dave Tapley wrote: I'm getting the impression that most people are using wxWidgets 2.9 with wxHaskell, is that a fair assumption? I was surprised by your impression, but now I see why you may feel that way. It turns out wxWidgets 2.9 was released early this month, on 2011-07-05. This makes it a bit more urgent for wxhaskell to support both (good thing Jeremy was working so furiously on that) This impression came primarily from the fact that I couldn't build wxhaskell again wxWidgets 2.8 (for the reasons I've sent other messages to the list). Unfortunately it seems it also won't build against the 2.9.2 dev release, but I'll post a separate message about that. I've just grabbed the latest dev release (2.9.2) of wxWidgets because I'm still getting errors trying to compile against the 2.8.10 version I got from the Ubuntu repositories (I'm going to post about those errors separately) and I'd just like to get something working. If you just want something that works, use wxWidgets 2.8 and the stable version of wxHaskell. Well, there are some features in wxWidgets which aren't supported by wxHaskell, so I was rather hoping to get it building so I can contribute to the project :) -- Eric Kow http://erickow.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Specifying wxWidgets version to build wxHaskell with
On 26 July 2011 09:15, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: On 26 July 2011 06:59, Eric Y. Kow eric@gmail.com wrote: On Tue, Jul 26, 2011 at 00:28:01 +0100, Dave Tapley wrote: I'm getting the impression that most people are using wxWidgets 2.9 with wxHaskell, is that a fair assumption? I was surprised by your impression, but now I see why you may feel that way. I think there's something of a mix. There are probably more wxWidgets 2.8 users out there, but most people don't install unless something has broken - say a new HP version comes out. I started to look at support for 2.9 when people started asking for 2.9 features. In particular, I believe that 2.9 can be compiled as a 64 bit library on newer Macs. It turns out wxWidgets 2.9 was released early this month, on 2011-07-05. This makes it a bit more urgent for wxhaskell to support both (good thing Jeremy was working so furiously on that) Hmmm. Nice to hear you say it, but truth be told, I rarely have the time to work 'furiously' on wxHaskell :-( Most work happens on intercontinental flights (good news: I have another one coming up in a couple of weeks). We have never had a good story for support of multiple versions, in part because wxdirect doesn't support conditional compilation, which means that we can't put #ifdefs around version/platform dependent parts of wxC headers. In the past we've sort of fudged the issue by officially supporting only one version, but I don't think that's a tenable position any longer. Eric's Haskell version of wx-config will help the 'library' aspect - especially if we start to use wxPack on Windows, so we can rely on having the libraries built in a specific way. We will need to make it work for 2.9 and 2.8 though - I think these will need to coexist for a while yet. I looked at fixing the existing wx-config source for 2.9 (ISTR it's in C++), but looking at the code I lost the will to live. It's rather, err, verbose. Haskell would be much better. I did sort-of warn the list that 2.9 work would likely destabilize the tip for a while. Perhaps we should do this work in a branch (I've never tried this in Darcs - how easy is it Eric?) Jeremy Let me know if there's any way I can help. I'm going to be relying on wxHaskell in the immediate future so I'm keen to familiarise myself with it because I suspect there are some 2.9 features I need which aren't implemented in wxHaskell presently. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04
On 26 July 2011 00:41, Dave Tapley duked...@gmail.com wrote:
On 25 July 2011 15:49, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote:
Hi all,
On 25 July 2011 07:45, Eric Y. Kow eric@gmail.com wrote:
On Mon, Jul 25, 2011 at 01:10:15 +0100, Dave Tapley wrote:
A very good suggestion.
I cabal unpacked wxcore-0.12.1.7 and it appears to have a fix in it¹.
Do we know why this fix is in the release, but not in darcs?
I suspect the answer lies somewhere in here:
darcs changes --repo http://code.haskell.org/wxhaskell --from-tag .
--match 'hunk 45999'
The answer is that it comes from my clean-up for wxWidgets 2.9, and is
probably a case of being over-zealous. The problem wasn't caught because
(most likely) no-one built tip for Gtk. It's not an environment I have
readily available to me.
I'm not sure that there is a straightforward way to get similar behaviour
on Gtk, so I think the only clean solution is to revert the old 'NULL'
implementation. What do you think?
EWXWEXPORT(wxCursor*,Cursor_CreateLoad)(wxString* name,long type,int
width,int height)
{
#if (wxVERSION_NUMBER = 2900)
wxBitmapType bm_type = (wxBitmapType) type;
#else
long bm_type = type;
#endif
#ifdef __WXGTK__
// See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45999
return NULL;
#else
return new wxCursor(*name, bm_type, width, height);
#endif
}
Regards
Jeremy
Having made these modifications I now get passed that error, but stumble on
this: http://hpaste.org/49525
Does anyone have any intuition why these files could be missing?
Hmm, I've switched to the 2.9.2 dev release of wxWidgets and I'm getting a
similar failures with:
Both with the latest wxHaskell in hackage: http://hpaste.org/49563
And with the latest from darcs: http://hpaste.org/49564
Does anyone have any suggestions as to a fix, or a more reliable build set
up?
Thanks,
Dave
--
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04
On 25 July 2011 15:49, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:
Hi all,
On 25 July 2011 07:45, Eric Y. Kow eric@gmail.com wrote:
On Mon, Jul 25, 2011 at 01:10:15 +0100, Dave Tapley wrote:
A very good suggestion.
I cabal unpacked wxcore-0.12.1.7 and it appears to have a fix in it¹.
Do we know why this fix is in the release, but not in darcs?
I suspect the answer lies somewhere in here:
darcs changes --repo http://code.haskell.org/wxhaskell --from-tag .
--match 'hunk 45999'
The answer is that it comes from my clean-up for wxWidgets 2.9, and is
probably a case of being over-zealous. The problem wasn't caught because
(most likely) no-one built tip for Gtk. It's not an environment I have
readily available to me.
I'm not sure that there is a straightforward way to get similar behaviour
on Gtk, so I think the only clean solution is to revert the old 'NULL'
implementation. What do you think?
EWXWEXPORT(wxCursor*,Cursor_CreateLoad)(wxString* name,long type,int
width,int height)
{
#if (wxVERSION_NUMBER = 2900)
wxBitmapType bm_type = (wxBitmapType) type;
#else
long bm_type = type;
#endif
#ifdef __WXGTK__
// See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45999
return NULL;
#else
return new wxCursor(*name, bm_type, width, height);
#endif
}
Regards
Jeremy
Well, the 2.9.2 dev release¹ appears to include that constructor (in
include/wx/gtk/cursor.h) if wxUSE_IMAGE is set.
So perhaps we should check that?
¹ http://www.wxwidgets.org/downloads/#latest_dev
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide. Store less, Store more with what you own, Move data to
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] Specifying wxWidgets version to build wxHaskell with
I'm getting the impression that most people are using wxWidgets 2.9 with wxHaskell, is that a fair assumption? I've just grabbed the latest dev release (2.9.2) of wxWidgets because I'm still getting errors trying to compile against the 2.8.10 version I got from the Ubuntu repositories (I'm going to post about those errors separately) and I'd just like to get something working. I have configure'd and make'd 2.9.2, I didn't want to make install because I don't want it to conflict with the 2.8.10 version. I see that the wxHaskell's Setup.hs uses wx-config, but I don't see any way to specify a prefix to wx-config, so I was just wondering how you guys get wxHaskell to build using a specific version of wxHaskell? The only approach I can see is to make sure the wx-config in your path in a symlink and that it points to the wxWidgets library you want to use. Thanks, Dave -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04
On 25 July 2011 15:49, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:
Hi all,
On 25 July 2011 07:45, Eric Y. Kow eric@gmail.com wrote:
On Mon, Jul 25, 2011 at 01:10:15 +0100, Dave Tapley wrote:
A very good suggestion.
I cabal unpacked wxcore-0.12.1.7 and it appears to have a fix in it¹.
Do we know why this fix is in the release, but not in darcs?
I suspect the answer lies somewhere in here:
darcs changes --repo http://code.haskell.org/wxhaskell --from-tag .
--match 'hunk 45999'
The answer is that it comes from my clean-up for wxWidgets 2.9, and is
probably a case of being over-zealous. The problem wasn't caught because
(most likely) no-one built tip for Gtk. It's not an environment I have
readily available to me.
I'm not sure that there is a straightforward way to get similar behaviour
on Gtk, so I think the only clean solution is to revert the old 'NULL'
implementation. What do you think?
EWXWEXPORT(wxCursor*,Cursor_CreateLoad)(wxString* name,long type,int
width,int height)
{
#if (wxVERSION_NUMBER = 2900)
wxBitmapType bm_type = (wxBitmapType) type;
#else
long bm_type = type;
#endif
#ifdef __WXGTK__
// See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45999
return NULL;
#else
return new wxCursor(*name, bm_type, width, height);
#endif
}
Regards
Jeremy
Having made these modifications I now get passed that error, but stumble on
this: http://hpaste.org/49525
Does anyone have any intuition why these files could be missing?
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide. Store less, Store more with what you own, Move data to
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04
Hmm, unfortunately whilst cabal configure now completes successfully, I am having a problem when doing cabal build, see output below. Could it be related to this: http://comments.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/298 ? src/cpp/eljcursor.cpp:23:0: error: no matching function for call to ‘wxCursor::wxCursor(wxString, long int, int, int)’ /usr/include/wx-2.8/wx/gtk/cursor.h:31:0: note: candidates are: wxCursor::wxCursor(const char*, int, int, int, int, const char*, const wxColour*, const wxColour*) /usr/include/wx-2.8/wx/gtk/cursor.h:29:0: note: wxCursor::wxCursor(const wxImage) /usr/include/wx-2.8/wx/gtk/cursor.h:27:0: note: wxCursor::wxCursor(int) /usr/include/wx-2.8/wx/gtk/cursor.h:26:0: note: wxCursor::wxCursor() /usr/include/wx-2.8/wx/gtk/cursor.h:23:0: note: wxCursor::wxCursor(const wxCursor) On 21 July 2011 23:00, Dave Tapley dave.a.tap...@gmail.com wrote: That was exactly the problem! Thank you very much Eric :) Dave, On 21 July 2011 22:44, Eric Y. Kow eric@gmail.com wrote: Hi Dave, On Thu, Jul 21, 2011 at 21:54:11 +0100, Dave Tapley wrote: I am having trouble compiling wxcore on Ubuntu 10.04. The source I am using I pulled with a darcs get from hackage, I then descended into the wxcore directory and did a cabal configure. I suspect that recent minor changes to our Setup.hs file have broken compatibility with wxWidgets 2.8. Could you try darcs obliterate -p Additional libraries required by wxWidgets 2.9 and see if it has any result? Alternatively, if you just want a working wxHaskell and aren't particularly interested in debugging this sort of thing, I'd suggest just doing cabal install wx and fetching the one on hackage for now. Thanks! -- Eric Kow http://erickow.com -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] Building wxcore on Ubuntu 10.04
Hi all, I am having trouble compiling wxcore on Ubuntu 10.04. The source I am using I pulled with a darcs get from hackage, I then descended into the wxcore directory and did a cabal configure. It gives me a * Missing C libraries: wx_baseu-2.8, wx_baseu_net-2.8, wx_baseu_xml-2.8... error, I have the .so files for libwx_baseu-2.8.so in my /usr/lib, but I don't have any headers in /usr/include, could this be a problem? If so then does anyone know where I can obtain these headers? I have already installed the libwxbase2.8-dev and libwxgtk2.8-dev packages. Running cabal configure -v3 I can see the first problem is this: /usr/bin/ld: cannot find -lwxmsw28ud_media Is it safe to assume that msw refers to MS Windows? If so should I be trying to link against this when building in Linux? I have pasted the full output from cabal configure -v3 here: http://hpaste.org/49326 Thanks, Dave -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
