Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Yay! Thanks Paul! It's always good to have more folks confirm the problems are solved than not! Another cool direction 7.8 will allow is using the various llvm ffi bindings from ghci! On Wednesday, October 2, 2013, Paul Liu wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-ca-- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Logo Macbook Decal
I've heard good things about teespring. I gather it's like a kickstarter but specifically for t-shirts. They seem to have some procedures[1] in place specifically for non-profit organizations, which might be a good option for supporting haskell.org. [1]: http://teespring.com/solutions (confusingly, the page is titled enterprise solutions, but I think it's actually about non-profit organizations) Assuming the campaign isn't hard to set up, it's probably worth doing. I know I'd certainly buy a shirt. Or maybe a sweatshirt. A campaign like this might also make a good rally point for informing the community that haskell.org is now a registered non-profit :). On Tue, Oct 1, 2013 at 8:19 PM, Jason Dagit dag...@gmail.com wrote: On Tue, Oct 1, 2013 at 3:50 PM, Kyle Hanson hanoo...@gmail.com wrote: I ordered mine! Does anyone know if there is any place where I could order pre-made Haskell t-shirt that benefits haskell.org too? I don't know where, but I just wanted to say thank you to both you and Ryan and everyone else who buys one. Setting something up like this is great! And we definitely want to encourage it. So if you do find a place to order shirts (maybe cafepress?) please let us know. You might also like to know that haskell.org can now accept donations directly: http://www.haskell.org/haskellwiki/Donate_to_Haskell.org Gershom announced it at the recent Haskell Implementors Workshop and we're still working on getting the word out to a wider audience. In the future, haskell.org would like to use donations to buy dedicated development time for key bits of Haskell infrastructure. I think we'll have more to say about that in a week or two (work in progress). Thanks for your support! Jason ___ 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] Any precedent or plan for guaranteed-safe Eq and Ord instances?
Ryan Newton wrote: Here are some examples: - data Foo = Bar | Baz instance Eq Foo where _ == _ = True instance Ord Foo where compare Bar Bar = EQ compare Bar Baz = LT compare _ _ = error I'm partial! - These would allow LVish's runPar to non-determinstically return Bar or Baz (thinking they're the same based on Eq). Or it would allow runPar to nondeterministically crash based on different schedulings hitting the compare error or not [1]. [..] [1] If you're curious why this happens, its because the Ord instance is used by, say, Data.Set and Data.Map for the keys. If you're inserting elements in an arbitrary order, the final contents ARE deterministic, but the comparisons that are done along the way ARE NOT. I'm not sure whether the Eq instance you mention is actually incorrect. I had always understood that Eq denotes an equivalence relation, not necessarily equality on the constructor level. One prominent example would be equality of Data.Map itself: two maps are equal if they contain the same key-value pairs, map1 == map2 = toAscList map1 == toAscList map2 but that doesn't mean that their internal representation -- the balanced tree -- is the same. Virtually all exported operations in Data.Map preserve this equivalence, but the library is, in principle, still able to distinguish equal maps. In other words, equality of abstract data types is different from equality of algebraic data types (constructors). I don't think you'll ever be able to avoid this proof obligation that the public API of an abstract data type preserves equivalence, so that LVish will yield results that are deterministic up to equivalence. However, you are mainly focused on equality of keys for a Map. In this case, it might be possible to move towards pointer equality and use things like Hashable or StableName . 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] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, Oct 02, 2013 at 11:24:39AM +0200, Heinrich Apfelmus wrote: I'm not sure whether the Eq instance you mention is actually incorrect. I had always understood that Eq denotes an equivalence relation, not necessarily equality on the constructor level. There's a difference between implementors being able to distingush equals, and application programmers. Internal implementations are allowed to break all sorts of invariants, but, by definition, APIs shouldn't. Are there examples where application programmers would like there so be some f, a and b such that a == b but f a /= f b (efficiency concerns aside)? I can't think of any obvious ones. One prominent example would be equality of Data.Map itself: two maps are equal if they contain the same key-value pairs, map1 == map2 = toAscList map1 == toAscList map2 but that doesn't mean that their internal representation -- the balanced tree -- is the same. Virtually all exported operations in Data.Map preserve this equivalence, but the library is, in principle, still able to distinguish equal maps. I had a quick skim of http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map-Lazy.html to find such examples, and the only one that jumped out was showTree. Are there others? Still, although the library is, in principle, able to distinguish equal maps, isn't this just a leaking implementation detail? Is it somehow of benefit to API users? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
* Heinrich Apfelmus apfel...@quantentunnel.de [2013-10-02 11:24:39+0200] In other words, equality of abstract data types is different from equality of algebraic data types (constructors). I don't think you'll ever be able to avoid this proof obligation that the public API of an abstract data type preserves equivalence, so that LVish will yield results that are deterministic up to equivalence. It still seems to fit nicely into Safe Haskell. If you are the implementor of an abstract type, you can do whatever you want in the Eq instance, declare your module as Trustworthy, and thus take the responsibility for soundness of that instance w.r.t. your public API. Roman signature.asc Description: 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
Hi, as for wxHaskell, it is currently maintained at https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5 and GHC 7.6. Work is underway to fix various bugs introduced over time by changes in wxWidgets, but we (i.e. https://github.com/wxHaskell?tab=members) hope to release announce in not too much time. cheers, Atze On 30 Sep, 2013, at 20:32 , Conal Elliott co...@conal.net wrote: Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: 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 - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 | Email: a...@uu.nl ... / |___\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
Hi, Roman Cheplyaka wrote: It still seems to fit nicely into Safe Haskell. If you are the implementor of an abstract type, you can do whatever you want in the Eq instance, declare your module as Trustworthy, and thus take the responsibility for soundness of that instance w.r.t. your public API. A possible problem with marking instance Eq as an unsafe feature is that many modules would be only Trustworthy instead of Safe. So if I don't trust the authors of a module (because I don't know them), I cannot safely use their code just because they implement their own Eq instance? That would go against my every purely functional module is automatically safe because the compiler checks that it cannot launch the missiles understanding of Safe Haskell. Actually, Eq instances are not unsafe per se, but only if I also use some other module that assumes certain properties about all Eq instances in scope. So in order to check safety, two independent modules (the provider and the consumer of the Eq instance) would have to cooperate. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Roshask
Hi, I'm trying to get things up and running but I keep having problems with the following. When I follow the instructions on https://github.com/acowley/roshask/wiki/Getting-Started I run into the following: tijn@tt:~/MyPackage$ roshask dep Looking for [std_msgs], dependencies of /home/tijn/MyPackage roshask: Couldn't find path to package std_msgs On Friday, January 11, 2013 10:53:38 PM UTC+1, Anthony Cowley wrote: I know that it probably needs updating for Groovy. I don't think it has many users, which makes it more challenging to keep things running smoothly, but I'm willing to help any interested parties get it up and running. Anthony On Fri, Jan 11, 2013 at 4:37 PM, Tijn van der Zant robo...@gmail.comjavascript: wrote: Hi, I want to use Haskell to program my robot using ros. I've found roshask https://github.com/acowley/roshask and I was wondering if someone on this list has experience with it and can tell me how good it is. Thanx! --Tijn ___ Haskell-Cafe mailing list haskel...@haskell.org javascript: http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list haskel...@haskell.org javascript: 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] Any precedent or plan for guaranteed-safe Eq and Ord instances?
* Tillmann Rendel ren...@informatik.uni-marburg.de [2013-10-02 13:19:38+0200] Hi, Roman Cheplyaka wrote: It still seems to fit nicely into Safe Haskell. If you are the implementor of an abstract type, you can do whatever you want in the Eq instance, declare your module as Trustworthy, and thus take the responsibility for soundness of that instance w.r.t. your public API. A possible problem with marking instance Eq as an unsafe feature is that many modules would be only Trustworthy instead of Safe. So if I don't trust the authors of a module (because I don't know them), I cannot safely use their code just because they implement their own Eq instance? That would go against my every purely functional module is automatically safe because the compiler checks that it cannot launch the missiles understanding of Safe Haskell. Actually, Eq instances are not unsafe per se, but only if I also use some other module that assumes certain properties about all Eq instances in scope. So in order to check safety, two independent modules (the provider and the consumer of the Eq instance) would have to cooperate. Good point! Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. * The default definitions of (/=), (), () and `compare` are law. * (==) is reflexive and transitive * (=) is antisymmetric ((x = y y = x) `implies` (x == y)) * (=) is 'total' (x = y || y = x) * (=) is transitive Currently, reflexivity of (==) is broken in the Prelude (let x = 0/0 in x == x). I know this is for IEEE 754 compliance, but c'mon, this is Haskell, we can have better ways of dealing with NaNs. -Stijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, 2 Oct 2013 15:46:42 +0200, Stijn van Drongelen rhym...@gmail.com wrote: I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. * The default definitions of (/=), (), () and `compare` are law. * (==) is reflexive and transitive * (=) is antisymmetric ((x = y y = x) `implies` (x == y)) * (=) is 'total' (x = y || y = x) * (=) is transitive Currently, reflexivity of (==) is broken in the Prelude (let x = 0/0 in x == x). I know this is for IEEE 754 compliance, but c'mon, this is Haskell, we can have better ways of dealing with NaNs. Like making Double not be an instance of Eq? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
Only for meanings of better which do not imply as good performance. On 2 October 2013 14:46, Stijn van Drongelen rhym...@gmail.com wrote: I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. * The default definitions of (/=), (), () and `compare` are law. * (==) is reflexive and transitive * (=) is antisymmetric ((x = y y = x) `implies` (x == y)) * (=) is 'total' (x = y || y = x) * (=) is transitive Currently, reflexivity of (==) is broken in the Prelude (let x = 0/0 in x == x). I know this is for IEEE 754 compliance, but c'mon, this is Haskell, we can have better ways of dealing with NaNs. -Stijn ___ 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] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, Oct 2, 2013 at 3:49 PM, Niklas Haas hask...@nand.wakku.to wrote: On Wed, 2 Oct 2013 15:46:42 +0200, Stijn van Drongelen rhym...@gmail.com wrote: I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. * The default definitions of (/=), (), () and `compare` are law. * (==) is reflexive and transitive * (=) is antisymmetric ((x = y y = x) `implies` (x == y)) * (=) is 'total' (x = y || y = x) * (=) is transitive Currently, reflexivity of (==) is broken in the Prelude (let x = 0/0 in x == x). I know this is for IEEE 754 compliance, but c'mon, this is Haskell, we can have better ways of dealing with NaNs. Like making Double not be an instance of Eq? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Like making IEEE754 Doubles not an instance of Eq. Normal and denormal Doubles should have Eq instances. ___ 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
Hi, The best low-level foundation libraries that I know of are the Enlightenment Foundation Libraries (EFL) [1,2]. They are cross-platform : they support many backends (X11, OpenGL, framebuffer...) and are used on desktops and mobile devices (even to provide games on the French Free ISP box). It seems that they also work on exotic platforms such as Windows and Mac OS. They are fully written in C, hence are easy to build and to use from Haskell. Evas [3] is a stateful canvas onto which shapes and texts can be drawn. It supports OpenGL regions [4]. Ecore [5] is used to manage windows, timers, etc. especially with Ecore_Evas [6]. Edje allows you to clearly separate UI and the rest of the code. The same thing has been integrated into Qt with QML (and was present in Delphi decades ago ;)). It makes it easy to create animated UI, etc. Finally, Elementary is a standard widget toolkit based on Edje, Evas and Ecore. The good news is that I have been working on an Haskell binding for the EFL [7]. The bad news is that it is not complete. Evas, Ecore and Ecore_Evas are partially done but need more polishing and testing. This simple example here [8] works well in GHCI (even better than when the program is compiled because I haven't yet figured out why the text is not displayed in this latter case...). I do not plan to write bindings for Edje and Elementary as I would prefer an Haskell DSL to replace Edje and a widget toolkit on top of it (another project seems to provide some bindings for Elementary [9]). If you want to use the EFL as a working foundation, I can try to work a little bit more on the binding. Cheers Sylvain [1] http://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries [2] http://www.enlightenment.org/p.php?p=aboutl=en [3] http://docs.enlightenment.org/auto/evas [4] http://docs.enlightenment.org/auto/evas/group__Evas__GL.html [5] http://docs.enlightenment.org/auto/ecore/ [6] http://docs.enlightenment.org/auto/ecore/group__Ecore__Evas__Group.html [7] https://github.com/hsyl20/graphics-efl [8] https://github.com/hsyl20/graphics-efl/blob/master/examples/Simple.hs [9] https://bitbucket.org/arrowdodger/efl-haskell Le 27/09/2013 05:32, Conal Elliott a écrit : 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] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, Oct 02, 2013 at 03:46:42PM +0200, Stijn van Drongelen wrote: * Operators in Eq and Ord diverge iff any of their parameters are bottom. What's the benefit of this requirement, as opposed to, for example False = _ = True ... Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
* Stijn van Drongelen rhym...@gmail.com [2013-10-02 15:46:42+0200] I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. This outlaws the Eq instances of lists, trees, and other (co)recursive types. Furthermore, in this formulation, even Eq for tuples is illegal, because (undefined, something) == somethingElse is going to diverge. Roman signature.asc Description: 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
Hi Atze. I'm glad to hear that some work is going into wxHaskell. Do you know about the issue that arose roughly 7-8 years ago that prevented opening more than one top-level window per process? It had to do with a change to initialization techniques, and made wxHaskell no longer useful with GHCi. -- Conal On Wed, Oct 2, 2013 at 3:24 AM, Atze Dijkstra a...@uu.nl wrote: Hi, as for wxHaskell, it is currently maintained at https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5 and GHC 7.6. Work is underway to fix various bugs introduced over time by changes in wxWidgets, but we (i.e. https://github.com/wxHaskell?tab=members) hope to release announce in not too much time. cheers, Atze On 30 Sep, 2013, at 20:32 , Conal Elliott co...@conal.net wrote: Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: 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 - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 | Email: a...@uu.nl ... / |___\ ___ 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
Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, Oct 2, 2013 at 4:17 PM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: What's the benefit of this requirement, as opposed to, for example False = _ = True I was trying to cover for void types, where the only sensible definitions are instance Eq Void where _ == _ = error void (==) instance Ord Void where _ = _ = error void (=) This is because reflexivity must be guaranteed, so undefined == undefined may not yield False, but I doubt error foo == (let x = x in x) should yield True either. But perhaps this exception deserves its own rule. On Wed, Oct 2, 2013 at 5:36 PM, Roman Cheplyaka r...@ro-che.info wrote: * Stijn van Drongelen rhym...@gmail.com [2013-10-02 15:46:42+0200] I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. This outlaws the Eq instances of lists, trees, and other (co)recursive types. Furthermore, in this formulation, even Eq for tuples is illegal, because (undefined, something) == somethingElse is going to diverge. Roman I knew this was going to bite me in the ass. Let me try again: * Operators in Eq and Ord may only diverge when any of their parameters are bottom. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, Oct 2, 2013 at 6:57 PM, Stijn van Drongelen rhym...@gmail.comwrote: On Wed, Oct 2, 2013 at 5:36 PM, Roman Cheplyaka r...@ro-che.info wrote: * Stijn van Drongelen rhym...@gmail.com [2013-10-02 15:46:42+0200] I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. This outlaws the Eq instances of lists, trees, and other (co)recursive types. Furthermore, in this formulation, even Eq for tuples is illegal, because (undefined, something) == somethingElse is going to diverge. Roman I knew this was going to bite me in the ass. Let me try again: * Operators in Eq and Ord may only diverge when any of their parameters are bottom. What am I thinking. Scratch that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] lvish 1.0 -- successor to monad-par
Ryan Newton rrnew...@gmail.com writes: Hi all, I'm pleased to announce the release of our new parallel-programming library, LVish: hackage.haskell.org/package/lvish It provides a Par monad similar to the monad-par package, but generalizes the model to include data-structures other than single-assignment variables (IVars). For example, it has lock-free concurrent data structures for Sets and Maps, which are constrained to only grow monotonically during a given runPar (to retain determinism). This is based on work described in our upcoming POPL 2014 paper: Do you have any aidea why the Haddocks don't yet exist. If I recall correctly, under Hackage 1 the module names wouldn't be made links until Haddock generation had completed. Currently the lvish modules' point to non-existent URLs. Also, is there a publicly accessible repository where further development will take place? Cheers, - Ben pgppP5lQOaZx3.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, Oct 2, 2013 at 5:18 AM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: Are there examples where application programmers would like there so be some f, a and b such that a == b but f a /= f b (efficiency concerns aside)? I can't think of any obvious ones. Yes, and we already handle it properly: Prelude let f = (1.0 /) Prelude let (z, negz) = (0.0, -0.0) Prelude z == negz True Prelude f z /= f negz True This is *not* an IEEE Floats are weird thing. Application programmers want 0.0 to equal -0.0, but -Infinity to not be equal to Infinity. Of course, given how many IEEE Floats are weird things there are, you can reasonably consider ignoring this example. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
So i think we can conclude the following 1) things are not perfect currently. But it requires some huge type class changes to have a better story 2) certain types of data types will need to be newtyped to have instances that play nice with Ryans concurrency work. Thats ok. Theres often good reasons for those illegal instances. There is no sound and COMPLETE way to enforce having good instances, and thats a good thing, though having more libs work correctly is always a good thing 3) as always, people complain about floats, when the real issue is the current numerical type classes, which are wrong in a number of ways. I hope to experiment with my own ideas in that direction soon. Not worth a boring no ideas worth taking seriously cafe thread On Wed, Oct 2, 2013 at 2:39 PM, Mike Meyer m...@mired.org wrote: On Wed, Oct 2, 2013 at 5:18 AM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: Are there examples where application programmers would like there so be some f, a and b such that a == b but f a /= f b (efficiency concerns aside)? I can't think of any obvious ones. Yes, and we already handle it properly: Prelude let f = (1.0 /) Prelude let (z, negz) = (0.0, -0.0) Prelude z == negz True Prelude f z /= f negz True This is *not* an IEEE Floats are weird thing. Application programmers want 0.0 to equal -0.0, but -Infinity to not be equal to Infinity. Of course, given how many IEEE Floats are weird things there are, you can reasonably consider ignoring this example. mike ___ 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
Great to hear that we're getting some payoff for the switch to dynamic linking in GHCi. Thanks for testing! Cheers Simon On 02/10/2013 07:23, Paul Liu wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is
Re: [Haskell-cafe] [ANN] lvish 1.0 -- successor to monad-par
that may or may not be a bug on the hackage server side, just brought it to duncan's attention and put a ticket for it on trac https://github.com/haskell/hackage-server/issues/119 On Wed, Oct 2, 2013 at 1:05 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ryan Newton rrnew...@gmail.com writes: Hi all, I'm pleased to announce the release of our new parallel-programming library, LVish: hackage.haskell.org/package/lvish It provides a Par monad similar to the monad-par package, but generalizes the model to include data-structures other than single-assignment variables (IVars). For example, it has lock-free concurrent data structures for Sets and Maps, which are constrained to only grow monotonically during a given runPar (to retain determinism). This is based on work described in our upcoming POPL 2014 paper: Do you have any aidea why the Haddocks don't yet exist. If I recall correctly, under Hackage 1 the module names wouldn't be made links until Haddock generation had completed. Currently the lvish modules' point to non-existent URLs. Also, is there a publicly accessible repository where further development will take place? Cheers, - Ben ___ 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] [ANN] lvish 1.0 -- successor to monad-par
i mean github On Wed, Oct 2, 2013 at 3:53 PM, Carter Schonwald carter.schonw...@gmail.com wrote: that may or may not be a bug on the hackage server side, just brought it to duncan's attention and put a ticket for it on trac https://github.com/haskell/hackage-server/issues/119 On Wed, Oct 2, 2013 at 1:05 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ryan Newton rrnew...@gmail.com writes: Hi all, I'm pleased to announce the release of our new parallel-programming library, LVish: hackage.haskell.org/package/lvish It provides a Par monad similar to the monad-par package, but generalizes the model to include data-structures other than single-assignment variables (IVars). For example, it has lock-free concurrent data structures for Sets and Maps, which are constrained to only grow monotonically during a given runPar (to retain determinism). This is based on work described in our upcoming POPL 2014 paper: Do you have any aidea why the Haddocks don't yet exist. If I recall correctly, under Hackage 1 the module names wouldn't be made links until Haddock generation had completed. Currently the lvish modules' point to non-existent URLs. Also, is there a publicly accessible repository where further development will take place? Cheers, - Ben ___ 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
No. GLFW does not give you any UI elements, just basic windowing and input handling. Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell. On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott co...@conal.net wrote: Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem.
[Haskell-cafe] Newclasses
Newclasses are not a new vision of classes! Not at all! Newclasses could elegant solve several instance problems! 1) we want to have partly applied instances, like Parent2Child: Parent a = Child a like instance Applicative m = Monad m where return = pure -- we won't define here (=) 2) we want to have superclass' instances, like Child2Parent: Child a = Parent a like instance Monad m = Applicative m where pure = return (*) = ap 3) we want to have default instances outside of class and as many as possible, not the only one. like class Foo a where foo :: ... default foo :: ... foo = ... 4) we want to have multi-class instances to separate (or unite) classes like type Stringy a = (Show a, Read a) instance Stringy SomeData where read = ... show = ... (4)th problem we could solve separately, but maybe it isn't easy enough to do such de-sugaring, and it could much easier to add them in newclasses. (3)rd problem is solved partly, but not in universal way, non-flexible and a bit ugly. (2)nd problem is solved, but it is mostly impossible to use them and it is not recommend to use it for overlapping and incoherent issues. (1)st problem is unsolved at all (partly, it is possible to make depended classes, but checker don't check if we implement parent classes). This is a compose proposal. Newclasses solve these problems at once! As newtype is a data looking like a type, same newclass is looking like a class, but is mostly an instance! Mostly, but not full. To best understanding what newclasses is, let's look at (1)st problem: -- we wish to write -- instance Applicative m = Monad m where -- return = pure -- we write newclass instead of instance -- add = and giving a name to newclass like a class -- this is not instance, so newclass can't overlap with any instance newclass (Applicative m) = Monad m = ApMonad m where return = pure data D a instance Applicative D where pure = ... (*) = ... -- creating instances from newclass is intuitive -- we implement here Monad class, not ApMonad; ApMonad is a just newclass instance ApMonad D where -- we already have 'return = pure', so we define only (=) (=) = ... What do we see here? Newclass looks like class, but it's mostly an instance! Newclass: Grammar: newclass constraint = Parent a = NewClassName a where ... As class, newclass has a name, which is unique and can't conflict with any other newclass or class names. As class, methods of newclass could be empty or implemented. As class, methods of newclass are not use in function inference. As class we can make an instance of newclasses and overwrite any of his functions! But, instance of newclass IS an instance of the parent (!)class! So, newclasses is like a de-sugaring. As instance, newclass contains only parents methods! On contrary to instancess, we don't use newclasse directly, it only help us to create instances. If we allow for newclass to be as Parent not only classes, but newclasses, then newclass can't be recursive: neither of his (Grand)Parent could be he by himself. If we allow for newclass muliple Parents, we solve (4)th problem too. Examples: We have: class Functor f where fmap :: (a - b) - f a - f b class Applicative f where -- without Functor f =, this is a misfeature pure :: a - f a (*) :: f (a - b) - f a - f b class Monad m where return :: a - m a (=) :: m a - (a - m b) - m b class Ord' a where -- without Eq a =, this is a misfeature ... compare a b-- not as in Prelude | a b = LT | a b = GT | otherwise = EQ (1)st, Parent2Child: Common pattern to write newclass like: newclass Parent a = Child a = ParChild a where ... Examples: newclass (Applicative m) = Monad m = ApMonad m where return = pure data C1 a ... instance Applicative C1 where pure = ... (*) = ... instance ApMonad C1 where -- return is already defined (=) = ... -- newclass (Ord' a) = Eq a = OEq a where a == b = case compare a b of EQ - True _ - False data C2 ... instance Ord' C2 where () = ...
Re: [Haskell-cafe] Newclasses
Hi! Your first two cases will be fixed in 7.10, as Applicative finally becomes a superclass of Monad. I haven't really looked at your third case, so I can't comment on that. Your fourth case is something I'd really like to see solved properly (*together* with a better record system), but as you say, it could be solved separately. Also, I don't see why it would be a misfeature to have Eq as a superclass of Ord, or Functor as a superclass of Applicative. -Stijn ___ 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
Interesting. How are the aesthetics? Can you point me to screen shots? It'd be a lot of work, but one cool project would be to create *beautiful* GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we could afford to put a lot into visual details. A complementary project is designing a semantically precise and elegant (denotative/genuinely functional to use Peter Landin's terms) GUI DSEL that would be simpler and more powerful than the conventional OO-inspired libraries we have so much trouble getting to work in Haskell. I've thought about this sort of thing on and off for a very long time and would be happy to be involved if others are interested also. Together, these two efforts would yield an approach to GUIs that is beautiful inside and out. -- Conal On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu nine...@gmail.com wrote: No. GLFW does not give you any UI elements, just basic windowing and input handling. Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell. On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott co...@conal.net wrote: Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
[Haskell-cafe] ANN: Nomyx 0.3 beta, the game where you can change the rules
Hello everybody! I released the third beta of Nomyx http://www.nomyx.net, the only game where You can change the rules! The second beta was a success. Great players (byorgey, nomeata, Toxaris...) proposed amazing rules, effectively building a nice universe. For example, a banking system in ecu was proposed, with cash monies and even a way to buy pies! Other rules like different democratic systems were proposed. You can check those rules in this thread: http://www.nomyx.net/forum/viewtopic.php?f=4t=1520 Let's start a new game! I propose to set it in the medieval era. Dear rulers, I'll let your imagination speak! Please login to the game here: www. nomyx.net:8000/Nomyx. The corresponding forum thread is here: http://www.nomyx.net/forum/viewtopic.php?f=4t=1523 Some background: this is an implementation of a Nomic [2] game in Haskell(I believe the first complete implementation of a Nomic game on a computer). In a Nomyx game you can change the rules of the game itself while playing it. The players can submit new rules or modify existing ones, thus completely changing the behaviour of the game through time. The rules are managed and interpreted by the computer. They must be written in the Nomyx language http://hackage.haskell.org/package/Nomyx-Language, which is a subset of Haskell. At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! Here is a video introduction and first tutorial of the game: http://vimeo.com/58265498 The example file gives a lot of examples of rules that you can submit: www. nomyx.net:8000/src/Language/Nomyx/Examples.hs changes in V0.3: - creation of admin role - inputs made by the rules now include checkboxes, buttons, textarea - outputs made by the rules are now managed (create, update, delete) - refactored the GUI - bumped to GHC 7.6 - compilation errors are displayed in context - bug fixes Cheers, Corentin [1] www.nomic.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] Penny - double-entry accounting
I'm pleased to make the first public announcement of the availability of Penny, a double-entry command-line accounting system. Penny is inspired by Ledger, an excellent program in its own right. Ledger's websites and sales pitches are much better developed than those for Penny, so first take a look at Ledger's website to see if the concepts behind this program interest you: http://www.ledger-cli.org/ With that in mind, here is what distinguishes Penny from Ledger: * Smarter report formatting. When using Ledger I rarely bothered to reformat the reports because I could never remember how to use the cryptic formatting strings. Penny automatically formats reports to fit the width of your screen. You can easily add or remove information in your reports. * Use of color. Color is baked into Penny, making reports easier to read. It takes advantage of 256-color terminals where available. * Adherence to double-entry accounting principles. Ledger will allow you to enter unbalanced transactions. Penny never allows this. Even infinitesimally unbalanced transactions will render your entire ledger invalid. * Different handling of commodities. In part because of the strict adherence to double-entry accounting principles, Penny handles commodities (e.g. transactions involving multiple currencies, or currency and equities) differently than Ledger. Some might regard Penny's handling of commodities to be a pain, but I think it results in a system that is more predictable, has no corner cases, and is easy to test. * More orthogonal command-line interface. For example, in Ledger, you use one set of options to filter postings by date, and a different set of options to control the dates of postings that are shown in the register report. Penny uses identical options for these two purposes; what these options mean depends on where they appear on the command line. In addition, in Penny you can build filtering expressions of arbitrary complexity, using either infix or reverse polish notation. * Automated import of postings. You can import postings from your bank as long as it gives you OFX files. Many financial institutions supply OFX files, as it is the format used by Quicken and by the now-defunct Microsoft Money. Penny can also help automate a great deal of the process of reconciling your ledger with bank statements. This removes an enormous amount of the drudgery that is associated with maintaining a ledger. * Exposes a Haskell API. This is actually the primary reason I wrote Penny. I run several automated checks on my ledger. Doing this in Ledger was growing difficult because I had no standalone parser for the ledger files. With Penny I can easily write additional small programs to check up on the consistency of my ledger (for instance, to make sure I'm not using invalid accounts, or to make sure that a particular account has postings within a given time period.) The power of Haskell makes this much easier than it would be if I used a dynamically typed language like Haskell or, as I used to do with Ledger, a random assemblage of shell, Awk scripts, Haskell, and more. Another child of Ledger that is written in Haskell is hledger: http://hledger.org/ hledger is a great program; if you like it, please continue using it. In addition to what you can glean from the bullets above, here are some key ways Penny differs from hledger: * hledger is at least partially compatible with Ledger; Penny is incompatible with Ledger. There currently is no program to convert Ledger files to the format Penny uses (I once wrote such a program to convert my Ledger files to Penny; after that the program was of no use to me and the file format has since changed, rendering that code useless.) * hledger has a web interface. Penny does not and I doubt it ever will. * hledger has a robust community; Penny does not. * hledger supports more of Ledger's feature set with features such as timelog support, periodic reports, and balance assertions. Penny does not have these features. * hledger uses floating-point types to represent amounts: http://hackage.haskell.org/package/hledger-lib-0.21.3/docs/Hledger-Data-Types.html#t:Quantity Penny uses only integers: http://hackage.haskell.org/package/penny-0.30.0.0/docs/Penny-Lincoln-Bits-Qty.html This page summarizes why that matters: http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency * Penny is BSD3; hledger is GPL. And an entirely subjective comparison that may be biased: Penny is designed from the ground up to use Haskell's static type system and its module system to its maximum advantage, which makes Penny easier to use as a base for your own programs to check your ledger, and which reduces bugs. Penny has been in development for over a year now, and I use it to maintain my financial records. A set of QuickCheck tests, in conjunction with maximum exploitation of Haskell's static type system, help ensure the correctness of the
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
I only managed to find some screenshots from Harley Trung's class projects a few years ago: https://github.com/harleyttd/keyboard-fretboard/blob/master/demo2.png https://github.com/harleyttd/InstrVislizr/blob/master/stereo.png It was nothing fancy, only basic widgets, single font, not skinnable. The design was based on your Phooey work, monadic composition of UI elements wired by signals. I deliberately made the layout not reactive in order to simplify implementation. Regards, Paul Liu On Wed, Oct 2, 2013 at 3:28 PM, Conal Elliott co...@conal.net wrote: Interesting. How are the aesthetics? Can you point me to screen shots? It'd be a lot of work, but one cool project would be to create *beautiful* GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we could afford to put a lot into visual details. A complementary project is designing a semantically precise and elegant (denotative/genuinely functional to use Peter Landin's terms) GUI DSEL that would be simpler and more powerful than the conventional OO-inspired libraries we have so much trouble getting to work in Haskell. I've thought about this sort of thing on and off for a very long time and would be happy to be involved if others are interested also. Together, these two efforts would yield an approach to GUIs that is beautiful inside and out. -- Conal On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu nine...@gmail.com wrote: No. GLFW does not give you any UI elements, just basic windowing and input handling. Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell. On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott co...@conal.net wrote: Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of
