Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conal, If there is a system like you describe, I'm not aware of it. Part of the problem is the state of the underlying C libraries: gtk+ - possible, but suffers from the drawbacks you mention on OSX and is reportedly difficult to install on windows wx - somehow I've never been able to build this to my satisfaction on OSX (meaning a 64-bit build with working wxHaskell) QT - never tried this, but my impression is the Haskell-QT bindings are a bit stale FLTK is probably the surest approach, but it will definitely not look like a native Mac app. IMHO FLTK is hideously ugly on any system. But it is relatively easy to build. How much windowing are you looking for? Would GLFW be an acceptable starting point? John L. On Fri, Sep 27, 2013 at 12:40 AM, Conrad Parker con...@metadecks.orgwrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
i know nothing on the gui tooling front, but i do know this: the ffi linking issues with GHCI *should* be fixed with ghc HEAD / 7.8. If you have linking problems with GHCi HEAD, please report it ASAP. All linking related issues that have historically plagued ghci should be resolved, at least on platforms where theres support for dynamic linking for ghc On Thu, Sep 26, 2013 at 11:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
John Lato jwl...@gmail.com writes: QT - never tried this, but my impression is the Haskell-QT bindings are a bit stale Yes, QtHaskell [1] has been inactive for three years, as far as I can tell. However, there are newish bindings [2] for the Qt Quick declarative UI stuff that's appeared in recent Qt versions -- see the package hsqml on hackage [3]. It hasn't had any new uploads to hackage since last year, but there was activity on its repo as recently as yesterday [4]. I've yet to see any applications built on it, but it looks exciting. -Keshav [1] http://qthaskell.berlios.de/ [2] http://www.gekkou.co.uk/software/hsqml/ [3] http://hackage.haskell.org/package/hsqml [4] http://patch-tag.com/r/komadori/HsQML/snapshots/all/history ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Conal Elliott wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Hello Conal, I have been similarly dissatisfied with the state of GUI libraries in Haskell and have finally started working on one myself: [threepenny-gui][1]. Threepenny-gui uses the web browser as a display, which means that it's cross-platform, easy to install and works from GHCi! On the flip side, it doesn't support native OpenGL. [1]: http://www.haskell.org/haskellwiki/Threepenny-gui Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Could threepenny work with webGL, or is that too far out of the scope of the project? I guess the overhead of having a server--even locally--and using a web browser might just be too much for many use cases. On Sep 27, 2013 1:51 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Hello Conal, I have been similarly dissatisfied with the state of GUI libraries in Haskell and have finally started working on one myself: [threepenny-gui][1]. Threepenny-gui uses the web browser as a display, which means that it's cross-platform, easy to install and works from GHCi! On the flip side, it doesn't support native OpenGL. [1]: http://www.haskell.org/**haskellwiki/Threepenny-guihttp://www.haskell.org/haskellwiki/Threepenny-gui Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
However, I would prefer to have two different types of libraries in haskell: For graphics, something like SFML or SDL, no GUI implicit. but with good/modern OpenGL. Maybe we won't need a direct binding, but rethinking who should be done a SDL-like library in Haskell. Yep, FRP is cool, but need clever people. Whenever I try to do a pet-game with that.. I always come back to C++. And for GUI, I had good feeling of gtk bindings in the past. Luis On Fri, Sep 27, 2013 at 5:32 AM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Tikhon Jelvis wrote: Could threepenny work with webGL, or is that too far out of the scope of the project? I guess the overhead of having a server--even locally--and using a web browser might just be too much for many use cases. Actually, I'm reading about WebGL right now, and it appears to me that it should be very easy to support in Threepenny. While the communication between browser and server is comparatively slow, most of the hard work is done in the shading language anyway. The browser retrieves shading code from a `script` tag. It's straightforward to create such a tag in Threepenny, populate it, and make a few JavaScript FFI calls to start the rendering process. I currently have no plans to add WebGL support myself, but all the ingredients are in place. (Maybe wait until threepenny-0.4 , as I'm currently simplifying the FFI a bit.) PS: Conal, if you want to see whether the Threepenny + WebGL route is viable for you, it's probably a good idea to do a quick test in plain HTML + JS first, to see whether performance is good enough for your purpose. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On 09/27/2013 04:32 AM, Conal Elliott wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. We are working on bindings to SDL 2 at the moment - https://github.com/Lemmih/hsSDL2. They are currently usable for most 'stock' work - drawing things, doing interaction, window management, etc. However, I'm afraid SDL bindings don't really solve what you want in terms of a GUI programming. SDL2 at least gives you a sane cross platform way to create a window with an OpenGL context, and to draw things using hardware acceleration. If you actually need widgets, then SDL probably won't help here. - ocharles signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hello, Keshav Kini wrote: [snip] However, there are newish bindings [2] for the Qt Quick declarative UI stuff that's appeared in recent Qt versions -- see the package hsqml on hackage [3]. It hasn't had any new uploads to hackage since last year, but there was activity on its repo as recently as yesterday [4]. I've yet to see any applications built on it, but it looks exciting. Yes, I'm afraid I've been failing to embrace the release early release often mantra with HsQML. I originally set myself some (fairly modest) goals for the next release. Unfortunately, I've had less time to spend on it than I'd like and it's delayed getting there. There has been a fair amount of interest via e-mail, but the dearth of releases has probably dissuaded people from using it. Also, I need to write more documentation and provide better examples. That said, I've got a ticket to the Haskell eXchange in London next month and I set myself a personal deadline of making a new release before then. So, having said that in public, I'll have to really try and keep to it ^_^'! The next release will add support for Qt signals, plus bug fixes and Mac support. For the next release after that, I plan to port the library to Qt 5. Regards, -- Robin KAY ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Music update
Yes, video was shot and several audio recordings taken. I'm mastering the audio and expect to have something in a week to share. On Mon, Sep 23, 2013 at 4:21 AM, Dan Krol orbliv...@gmail.com wrote: Will there be a video of the live premier? On Fri, Sep 20, 2013 at 12:14 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: Some might remember me asking about music packages a while back... An update: I ended up using Euterpea, which in turn uses both Codec.Midi and Sound.PortMidi. My working environment was to have my code loaded up in ghci, play MIDI into a software MIDI bus, and pipe that into MainStage 3 which ran the synths. The piece I was working on premiered last night at a concert in Wellington, NZ. The live recording will take a while, but you can hear a studio synth recording (from the above setup) here: https://soundcloud.com/mtnviewmark/plain-changes-2-all-synth-mix The code for the piece is all open source: https://github.com/mzero/PlainChanges2. In particular, there is a somewhat improved MIDI playerhttps://github.com/mzero/PlainChanges2/blob/master/src/Sound/MidiPlayer.hs in there. Enjoy! - Mark P.S.: Yes, and now that that's done with, I can get on with the next Haskell Platform release! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Proposal: new function for lifting
Everybody is claiming that using lift is a bad thing. So, I come to remedy this problem. Stop lifting, start using shinny operators like this one: (^$) :: Monad m = m a - (a - b - c) - m b - m c (^$) = flip liftM2 Then you can do wonderful stuff and you will never read the four-letter word in your code again: \ Just 42 ^$(+)$ Nothing Nothing \ Just 10 ^$(+)$ Just 20 Just 30 \ let add = (+) \ Just 30 ^$ add $ Just 12 Just 42 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Robin KAY komad...@gekkou.co.uk writes: Yes, I'm afraid I've been failing to embrace the release early release often mantra with HsQML. I originally set myself some (fairly modest) goals for the next release. Unfortunately, I've had less time to spend on it than I'd like and it's delayed getting there. There has been a fair amount of interest via e-mail, but the dearth of releases has probably dissuaded people from using it. Also, I need to write more documentation and provide better examples. That said, I've got a ticket to the Haskell eXchange in London next month and I set myself a personal deadline of making a new release before then. So, having said that in public, I'll have to really try and keep to it ^_^'! The next release will add support for Qt signals, plus bug fixes and Mac support. For the next release after that, I plan to port the library to Qt 5. Awesome! Thanks, Robin! -Keshav ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANN] New OpenCV Bindings
Hi all, I've been hard at work on a new set of OpenCV bindings that will hopefully solve a lot of the shortcomings with previous attempts. An automatic header parser has been used to generate a full set of Haskell bindings for the C++ API, and I'm now working to create a pleasant Haskell API. The plan is to expose major functionality through pipes for two reasons: 1) OpenCV is not very referentially transparent, and so you're stuck in IO for anything non-trivial. Lazy IO is potentially problematic, and so immediate incorporation of a proper streaming library is probably best. 2) Computer vision algorithms are frequently expressed in terms of pipelines of functionality, and a pipes approach can provide a very natural API for expressing these algorithms. At this stage, I could very much use input from anyone who's interested in these bindings. I've got the basics of a library forming, but there's a ton to do and help in the form of pull requests are very very welcome. I could also use feedback on what's been done so far (especially criticisms) as well as feature requests. The current plan is to develop the pipes API for the core functionality. The plan is to provide the major functionality from core, highgui, imgproc, features2d, contrib, ml, flann, video, and objdetect as quickly as I can before trying to cover any of the more specialized parts of the API. The functions and types from these modules (baring a few major and important exceptions) are automatically translated into C wrappers and raw Haskell bindings. If there's sufficient interest in these raw bindings separately from the API I'm developing, I'll release them as a separate package on Hackage. I'm calling my project revelation for the moment because I'm bad at naming things and it was the best pun I could come up with. Github: www.github.com/arjuncomar/revelation Regards, Arjun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: new function for lifting
Which lift? This one? class MonadTrans t where lift :: Monad m = m a - t m a -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-new-function-for-lifting-tp5737189p5737196.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: new function for lifting
Sorry for sending this twice; I didn't reply to the list initially. I thought people [1] were generally talking about lift from Control.Monad.Trans: class MonadTrans t where lift :: Monad m = m a - t m a The idea being that lifting through a monad stack feels tedious. The proposed solution is to use instances to do the lifting for you, like in mtl. So we've got instances like: MonadState s m = MonadState s (ReaderT r m) Which let you automatically lift get/put/modify up a stack, without doing any work. This is different from liftM*, which are about applying a pure function to monadic arguments. This can be done quite nicely with ($) and (*) from Data.Functor and Control.Applicative, respectively. Your first example can be written: (+) $ (Just 42) * Nothing Nick [1] http://blog.ezyang.com/2013/09/if-youre-using-lift-youre-doing-it-wrong-probably/ signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. GLFW-b satisfies all of these. There are two caveats: a) to use it with GHCi you'll need to use ghc 7.8 (when it comes out in a week or two); b) it's really only providing an OpenGL context and none of the other traditional GUI things like widgets and font rendering. As far as GHCi compatibility is concerned, the problem there isn't with GLFW or the Haskell bindings. GHCi has been toxic to these sorts of libraries for a long time due to some bugs and limitations. In GHC 7.8, there is a change to use the system wide linker by default and that removes one hurdle. The next hurdle is to make GHCi work better with libraries that use thread local storage that is pinned to the process's original thread. You can often workaround this limitation with -fghci-no-sandbox. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. wxHaskell + GHCi is likely affected by some of the things I mention above. You should give it another try when 7.8 lands. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Fri, 27 Sep 2013 05:32:18 +0200, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. : * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. : wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. : * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. - wxHaskell is now actively maintained; several people have contributed new functionality and solutions to bugs. I hope there will be more people to help squash bugs, extend functionality and make the installation procedure easier. - The problems with GHCi will probably be solved with GHC 7.8. - OpenGL is supported Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Non-termination using Free Monads and Data Types a la Carte
I am trying to use a data types a la carte approach to define a free monad
for templating purposes. I am using Edward Kmett's free package, and a
module implementing data types a la carte's injections, modelled on the
IOSpec Types module. I have written a few combinators, but I am stuck. My
program keeps diverging, and I don't see why.
Consider:
math :: Math :: f = MathExpr a - Free f ()
blank :: f :: (Textual :+: Math)
= Free f ()
- Free (Blank k f) ()
equals :: Free (Math :+: (Blank L Math)) ()
- Free (Math :+: (Blank R Math)) ()
- Free Equation ()
The intention is that a blank takes in a properly typed abstract syntax
tree and tags it with blank k, so that the parsers/renderers do the
right thing (when I get around to implementing them) The composition
(blank . math) has the type:
blank . math :: ( f :: (Textual :+: Math)
, Math :: f
) = MathExpr a - Free (Blank k f) ()
Notice that f must be simultaneously less than or equal to the join of
Textual and Math, and greater than or equal to Math. So the only
possibility for f is Math. (I realize the compiler can't infer this without
more work on my part)
The problem happens when I try to evaluate (using scoped type signatures to
get around my comment above):
test :: Free Equation ()
test = (hoistFree (inj :: Blank 'L Math a - (Math :+: Blank 'L Math) a)
. blank
. (math :: MathExpr x - Free Math ())
$ hi
)
`equals` (math $ world)
which apparently loops, pegging my CPU at 100%. The computation prints its
result as:
Free (Equation (Free (DirectSum {unDirectSum = Right
at which point the value is truncated and GHCi quits. So it apparently gets
as far as figuring out that the first argument to equals is in the latter
part of the direct sum, but it doesn't seem t be able to compute blank.
Relatively minimal source is available at:
monad: http://lpaste.net/93471
data types a la carte: http://lpaste.net/93472
All my functions are total and I don't see a bottom here, but I was never
any good at fixed point combinators. Any ideas?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] New OpenCV Bindings
After receiving feedback, I went ahead and split out the raw C wrappers and Haskell bindings. You can find them at www.github.com/arjuncomar/opencv-raw. I'll upload it to hackage as opencv-raw once I have uploader privileges. Regards, Arjun On Fri, Sep 27, 2013 at 4:09 PM, Arjun Comar nru...@gmail.com wrote: Hi all, I've been hard at work on a new set of OpenCV bindings that will hopefully solve a lot of the shortcomings with previous attempts. An automatic header parser has been used to generate a full set of Haskell bindings for the C++ API, and I'm now working to create a pleasant Haskell API. The plan is to expose major functionality through pipes for two reasons: 1) OpenCV is not very referentially transparent, and so you're stuck in IO for anything non-trivial. Lazy IO is potentially problematic, and so immediate incorporation of a proper streaming library is probably best. 2) Computer vision algorithms are frequently expressed in terms of pipelines of functionality, and a pipes approach can provide a very natural API for expressing these algorithms. At this stage, I could very much use input from anyone who's interested in these bindings. I've got the basics of a library forming, but there's a ton to do and help in the form of pull requests are very very welcome. I could also use feedback on what's been done so far (especially criticisms) as well as feature requests. The current plan is to develop the pipes API for the core functionality. The plan is to provide the major functionality from core, highgui, imgproc, features2d, contrib, ml, flann, video, and objdetect as quickly as I can before trying to cover any of the more specialized parts of the API. The functions and types from these modules (baring a few major and important exceptions) are automatically translated into C wrappers and raw Haskell bindings. If there's sufficient interest in these raw bindings separately from the API I'm developing, I'll release them as a separate package on Hackage. I'm calling my project revelation for the moment because I'm bad at naming things and it was the best pun I could come up with. Github: www.github.com/arjuncomar/revelation Regards, Arjun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
