Re: [wxhaskell-users] problems buiding wxHaskell on Windows
Antton Tapani wrote: Installer would indeed be very nice, but it takes a lot of work to create and maintain universal installer and it would currently benefit only a handful of people. I'm guessing the majority of wxhaskell users are fairly savvy developers, so it would not seem worth the trouble. That of course quickly becomes self fulfilling statement since it will actively drive away people who have no interest in fiddling with the nuances of the installation process. They may give it a try, but fail and give up and you never hear from them. I will devote some time on this if I end up using haskell on more projects. Most people who wish to use wxhaskell are not likely to participate in its development, but at the same time people are less willing to develop a library with only few users. Haskell platform itself is pretty much single click installation, and it is very easy to get started with. Ideally that should be the case with every gui toolkit as well. [Cross posting to the libraries list.] Actually, maybe it's possible to integrate the creation of one-click installers with the Haskell Platform efforts? The best option would be to have wxHaskell to become part of the platform, but it probably doesn't meet the criteria for inclusion right now. But the focus is on the underlying C libraries anyway, these are the things that are tricky to install. Of course, someone has to prepare an installer, this amount of work doesn't magically disappear. But maybe it's a good idea to share common infrastructure, resources and knowledge with the Haskell Platform effort? Things that can be shared are: * the guy with the hat on top (release manager) who prods people to stay in sync * testing infrastructure (I have this romantic image where the Haskell Platforms hackers have access to a vast cloud of virtual machines to test their installation on different systems) * shell scripts for automating the creation of installers. (I for one have no clue how to create an installer on MacOS X.) So, the idea would be to have several installers: the Haskell Platform as a basis and then several Pillars on top, for instance the GUI Pillar that includes binaries for wxHaskell and GTK, or a Web Pillar that collects several web packages as soon as they become tricky to install with cabal (yesod platform). The latter should probably be a user install, not a global one. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Using wxHaskell on Mac OS x
Andrew Butterfield wrote: $ ghc --make -package wx HelloWorld.hs [2 of 2] Compiling Main ( HelloWorld.hs, HelloWorld.o ) Linking HelloWorld ... ld: warning: in /opt/local/lib/libwx_osx_cocoau_xrc-2.9.dylib, file was built for unsupported file format which is not the architecture being linked (i386) ld: warning: in /opt/local/lib/libwx_osx_cocoau_webview-2.9.dylib, file was built for unsupported file format which is not the architecture being linked (i386) [..] Undefined symbols: _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_open) _locale_charset, referenced from: _localeEncoding in libHSbase-4.3.1.0.a(PrelIOUtils.o) _iconv, referenced from: _hs_iconv in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_close) ld: symbol(s) not found collect2: ld returned 1 exit status [~/Documents/wxOnMacOSX] $ Yay, I know what's going on! * The first error messages indicate that GHC complains about your wxWidgets installation being 32bit. This means that you have a 64bit GHC. The solution is to install the wxWidgets library with the +universal flag, i.e. sudo port install wxWidgets-devel +universal It might be that you have to do the same with the dependencies of the wxWidgets-devel port. You can set the +universal flag globally in /opt/local/etc/macports/variants.conf * The undefined symbols are due to two different libiconv, one provided by OS X and one provided by Macports. The solution is to tell GHC to prefer the former ghc --make -package wx HelloWorld.hs -L/usr/lib Both these issues can be avoided by using homebrew. Whether this merely trades them for other issues is another question, of course... Concerning the EnableGUI thing, it will be obsolete very soon. I have submitted a patch to Jeremy who will upload a new version to hackage once he has tested all platforms. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] [Announce] wxHaskell 0.90
Conal Elliott wrote: I'm excited to see progress in ghci-friendliness! I installed wxWidgets-devel-2.9.3 via macports and then wxHaskell, and I get the following when trying to run a simple wxHaskell program in ghci: Loading package wxc-0.90.0.2 ... can't load framework: QuickTime (dlopen(/System/Library/Frameworks/QuickTime.framework/QuickTime, 9): no suitable image found. Did find: /System/Library/Frameworks/QuickTime.framework/QuickTime: no matching architecture in universal wrapper /System/Library/Frameworks/QuickTime.framework/QuickTime: no matching architecture in universal wrapper) Any suggestions? I'm using Mac OS 10.6.8 and GHC-7.0.4 from the Haskell Platform. It appears to me that the QuickTime framework only supports 32bit and PPC architectures $ cd /System/Library/Frameworks/QuickTime.framework/ $ lipo -info QuickTime Architectures in the fat file: QuickTime are: i386 ppc7400 This means that you can't link it with 64bit code. As far as I understand the situation, Apple is doing a complete reimplementation of QuickTime. The legacy QuickTime framework as used by the QuickTime Player 7 will not be updated to 64bit. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] Issues with GHCi support and TextCtrl
Hello, I'm currently updating reactive-banana-wx to use the new wx-0.90 branch and I've encountered a few issues with GHCi support and TextCtrl widgets. GHCi support is currently a mixed blessing on MacOS X. It works the first time but tends to crash when trying to call the start function again. Of course, this is not unexpected, but maybe it's possible to fix it to some extend. I had similar problems when dealing with the OpenAL or the GLFW frameworks, the solution was often to simply skip the termination routines. Not pretty, but it works. On that note, the EnableGUI trick is very cumbersome, it would be nicer if this could simply be integrated into wxHaskell, i.e. calling the start function will immediately enable the GUI thing. I can try to look into this. The more important issue is that TextCtrl widgets have changed their behavior: the entry function will now create a multiline widget! To create a single-line text entry widgets, I have to use the textCtrlEx function with flag 0 . This is extremely weird. Also, the latter widget sometimes crashes on me when trying to set the text, but the former doesn't. This is so weird that I can't even tell whether the problem is likely with wxWidgets or with the Haskell bindings. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] [Announce] wxHaskell 0.90
Eric Kow wrote: On 14 Apr 2012, at 00:16, Eric Kow wrote: Now some good and bad news for MacOS: seems to build fine if you have GHC 7.0.4. GHC 7.4.1 may require a minor patch that's in the darcs repo, probably something worth a micro release of wxc. Better news! Getting this working was just a matter of tacking on --use-llvm I've updated http://www.haskell.org/haskellwiki/WxHaskell/Mac If you've recently struggled getting wxHaskell working on MacOS X, I'd appreciate your feedback on things that you might trip over. *Hopefully* this new release allows people to just make wxHaskell work with just very common components: HP, HomeBrew. Thanks for the new wxHaskell release! I just tripped over a bug in the Setup.hs belonging to wxc that prevented me from compiling wxHaskell with 32bit architecture. The problem is the following: in the function linkSharedLib , the function runProgram is commented out and the function system is used instead. This is not correct because gcc may (and in my case: does) carry additional command line options! (Besides, the verbose output is lost.) Apparently, this was done because the runProgram didn't work for some reason. The reason is that some command line options are actually two arguments. In particular, setting the output file via -o ++ out_dir / sharedLibName ver basename, is not correct, the right way to go about it are two arguments -o, out_dir / sharedLibName ver basename, Same for the -install_name option. Four lines need to be changed in the linkCxxOpts file, then runProgram will work. Apologies for the long description, I just don't know how to send a patch. With the changes above, I'm able to link several example programs and run them. Some have issues, likely due to the Cocoa version of wxWidgets. Haven't tried GHCi yet. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wxHaskell layout tips/tricks
Eric Kow wrote: It's been a while since I've written a wxHaskell GUI from scratch, so I got a good opportunity to (re)experience the sort of struggle from years back :-) I can't claim to be an expert, but here are some (potentially incorrect!) notes from last night's fighting with wxHaskell http://www.haskell.org/haskellwiki/WxHaskell/Layout Along with the code sample and screenshot to go with it. (You may want to link to the code from the wiki page?) Now maybe I'll have a chance to see if reactive banana will make life any easier hooking it up to actual moving parts. I'd like to encourage you to bring up any banana-related trouble with me or StackOverflow. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Looking for macosx-app? Try cabal-macosx
Eric Kow wrote: The wxHaskell docs mention a shell script called macosx-app, but it got lost in our big build system cleanup. Now we have a replacement. Andy Gimblett's cabal-macosx package provides - Cabal hooks to build an app bundle - a very thin CLI wrapper called 'macosx-app' The latter is intended for use with little one-off applications too small to merit Cabalisation. You should be able to use it the same way as the old shell script. The CLI is currently on GitHub only at the moment, but I think Andy is planning to upload it to Hackage :-) https://github.com/gimbo/cabal-macosx We might want to consider having the wx package depend on cabal-macosx, although this isn't strictly speaking necessary Awesome! I'm using both already, with a macosx-app script that I had pilfered from a StackOverflow thread. Great that it's included in the cabal package now. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Haskell Platform roadmap?
Jeremy O'Donoghue wrote: - Extend Graphics.UI.WX so that more of the core functionality has high-level wrappers, e.g. for Grid, List boxes etc. I would love to see an FRP wrapper around parts of wxHaskell, and think we could reinstate one or more of the FRP libraries, for example. Making GUI programming less like C programming would do a lot to promote Haskell GUI development, but it requires much better Haskell-fu than I have to offer. I'm currently working on the FRP part [1]. It turns out that FRP is completely orthogonal to wxHaskell; there is no need to add special support for FRP in the GUI library. A handful of convenience wrappers [2] are enough to transform wxHaskell into a fully featured FRP-GUI library. In other words, you can simply focus on the mid-level GUI bindings and get that into the platform. If anything, it would be very useful to fix the GHCi issue. Developing an FRP library is still a very experimental activity and having GHCi support makes prototyping a lot faster. (Conal Elliott would agree with that.) [1]: http://hackage.haskell.org/package/reactive-banana [2]: http://hackage.haskell.org/package/reactive-banana-wx Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
