Re: [Haskell-cafe] Is fusion overrated?
Yes, the goal isn't so much to improve complexity (both are O(1)) but to reduce the constant factor on that O(1). In an inner loop like that, allocator/gc calls by far dominate the cost of the program. If you can remove them, you've improved the performance of the program by 10-100x. In the case where everything is Int, you can even unbox and get entirely in registers, which gives you comparable performance to a hand-tuned C or assembly language loop. -- ryan On Tue, May 17, 2011 at 10:55 PM, Roman Cheplyaka r...@ro-che.info wrote: If one thinks about Haskell data structures as of ordinary data structures, fusion seems a great deal -- instead of producing intermediate lists and possibly running out of memory, we just run a loop and use constant amount of space. But Haskell data structures are quite different -- they are produced as demanded. Consider the example from the Stream Fusion paper[1]: f :: Int → Int f n = sum [ k ∗ m | k ← [1..n], m ← [1..k ] ] Assuming the sum is a strict left fold, it consumes elements of lists one-by-one and runs in constant space. The list part can be transformed to foldr (++) [] $ map (\k - map (\m - k*m) [1..k]) [1..n] which is capable of producing elements one-by-one. So the whole thing probably should run in constant space as well. Of course I don't claim that fusion is useless -- just trying to understand the problem it solves. Are we saving a few closures and cons cells here? [1] Stream Fusion. From Lists to Streams to Nothing at All. Duncan Coutts, Roman Leshchinskiy, Don Stewart. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. ___ 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] Is fusion overrated?
On 18/05/2011, at 15:55 , Roman Cheplyaka wrote: Of course I don't claim that fusion is useless -- just trying to understand the problem it solves. Are we saving a few closures and cons cells here? And thunk allocations, and thunk entries. Entering a thunk costs upwards of 20 cycles, while performing a single addition should only cost one. Imagine every thunk entry is a function call. You don't want to call a whole function just to add two numbers together. Those few closures and cons cells can be surprisingly expensive when compared to native ALU instructions on a modern machine. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is fusion overrated?
Also, we do fusion on strict structures (e.g. vectors), where you get back O(n) on each fused point. Obviously, it is less of a win on lazy structures than the (pathological) case of strict data, but it is still a win. -- Don On Tue, May 17, 2011 at 11:07 PM, Ben Lippmeier b...@ouroborus.net wrote: On 18/05/2011, at 15:55 , Roman Cheplyaka wrote: Of course I don't claim that fusion is useless -- just trying to understand the problem it solves. Are we saving a few closures and cons cells here? And thunk allocations, and thunk entries. Entering a thunk costs upwards of 20 cycles, while performing a single addition should only cost one. Imagine every thunk entry is a function call. You don't want to call a whole function just to add two numbers together. Those few closures and cons cells can be surprisingly expensive when compared to native ALU instructions on a modern machine. 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] why doesn't ghc give you a type signature that works ?
(Re-CC-ing the list) On 18 May 2011 15:16, bri...@aracnet.com wrote: On Wed, 18 May 2011 13:52:46 +1000 Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: What's happening is that the type involves the FFTWReal class. However, this isn't immediately visible to ghci as it isn't in scope, but it can figure out that it's found in Math.FFT.Base. As such, you need to import that module as well (as opposed to just the Math.FFT class you have already imported). Well now, that makes perfect sense doesn't it ? I think my problem is that I think if I import the top-level module then the sub-modules should also be visible, provided I use the full name, or in the case of a qualified name, something link FFT.Base.FFTWReal. Clearly this is not the case, but why not ? Is it just the convention that haskell chose, or is there a reason for it ? Consider Data.ByteString vs Data.ByteString.Lazy; the have the exact same API but for completely different types. Also, it's quite often for package foo to have module Data.Foo, and then module bar extends it with module Data.Foo.Bar; should importing Data.Foo also bring in Data.Foo.Bar? What happens if bar isn't installed? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. Jurriën On 18 May, 2011, at 08:29 , Tom Murphy wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ 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] Status of Haskell + Mac + GUIs graphics
Along the same lines, once or twice I've needed to create a desktop version of a web app, which is what I wrote wai-handler-webkit[1] for. It only really builds properly on Linux for now, but if the need arises I don't see any reason it wouldn't work for Mac/Windows as well. Michael [1] http://hackage.haskell.org/package/wai-handler-webkit 2011/5/18 Jurriën Stutterheim j.stutterh...@me.com: A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. Jurriën On 18 May, 2011, at 08:29 , Tom Murphy wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ 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] Status of Haskell + Mac + GUIs graphics
Conal Elliott wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! I've asked a similar question on stackoverflow http://stackoverflow.com/questions/5868916/ and answered it myself. Basically, GLFW works (on my machine) as long as you don't call the GLFW.terminate function. The answer includes an example program that you can try out. It might be worth to include the extra hoops (EnableGUI) in the GLFW package. 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] Exception for NaN
Casey McCann syntaxgli...@gmail.com writes: At any rate, I think we already violate the spec by not having the required unordered result for comparisons, and just treating every comparison involving a NaN as GT. I don't think considering NaN as e.g. less than -Inf would violate the spec *more*. Well, it'd be insult to injury. If memory serves me, the standard behavior is that NaN =/= NaN evaluates as true, and every other comparison evaluates as false. Okay. I was basing my argument on the Wikipedia page, and it seems to operate with a special unordered value for comparisons. You could still preserve this behavior and get sensible sorting behavior, by defining an Ord instance where you explicitly specify 'compare' along with the boolean operators, and base sorting on it, rather than them. But you'd still have inconsistencies, for instance: compare NaN _ = LT NaN _ = False and minimum xs might not be the same as head (sort xs) And so on. (Of course, the current situation is that Prelude minimum [1,2,0/0,3] 3.0 or, probably causing this: Prelude max (0/0) 1 NaN Prelude max 1 (0/0) 1.0 so again, perhaps there is room for improvement here?) But I guess it is a matter of lipstick on a pig... How so? In that floating point values aren't going to be a pretty sight no matter what. It currently seems to violate almost every obvious invariant. What it mostly boils down to is that Haskell makes you expect things to be simple and consistent and clearly-defined and floating point values just simply aren't. Exactly. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is fusion overrated?
Roman Cheplyaka wrote: Of course I don't claim that fusion is useless -- just trying to understand the problem it solves. Are we saving a few closures and cons cells here? In addition to what everyone else said, fusion can be a big win when it allows further optimisations. For instance, fusing map (+1) . map (+2) can eliminate 1 addition per iteration. Even without taking allocation into account, most of the reasons for why loop fusion is a worthwhile optimisation in C apply to Haskell, too! Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
I have developed a GUI app using wxHaskell I develop using GHCi - invaluable I can run the application once form GHCi, and then a re-run crashes, but - usually after a run there is enough time to re-start GHCi while I tihnk about what needs fixing next - usually I can still run tests and queries from GHCi afterwards... This works because I develop in Windows using GHC 6.10.4 wxHaskell 0.11.1.2 - I haven't upgraded because I believe the GHCi behaviour worsens on later versions of GHC (I'm open to correction on this) - a student of mine has been able to build it on linux using the latest versions of everything - I had to revise some of my code simply because later GHC versions introduced new keywords So - to summarise If you are happy to develop using 6.10.4, on Windows then wxHaskell is workable with GHCi It seems to then build ok on Linux Alas - I have yet to be able to build it on Mac OS X (Snow Leopard) The app ? - see http://www.scss.tcd.ie/Andrew.Butterfield/Saoithin/ On 18 May 2011, at 00:24, Conal Elliott wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. School of Computer Science and Statistics, Room F.13, O'Reilly Institute, Trinity College, University of Dublin http://www.cs.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Is there a library that satisfies 2 of your 3 points? * Works with ghci * Supports OpenGL. I've struggled to get: * A window with opengl * Running interactively from ghci * Working cross platform Anyone know of a solution for that? If there's a library that handles that, then there's at least a sensible base to build a pure functional GUI system on. Cheers, Sam From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 18 May 2011 00:24 To: Haskell Cafe Subject: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
On 18/05/2011 2:02 PM, Ville Tirronen wrote: Hello, I have successfully* built HOpenCV on windows with openCV 2.0 on windows (XP). * by successfully, I mean compiled and linked, library and test.hs. The test did give me an error: test-hopencv.exe: user error (Failed to create camera) which, I have not bothered to follow up any further. The build process was as follows (your paths will differ): 1) I installed openCV to C:\apps\OpenCV2.0 2) I unzipped HOpenCV-0.1.2.2 to some directory 3) edited cabal file edited the following entries to include-dirs: c:\apps\OpenCV2.0\include\opencv extra-lib-dirs: c:\apps\OpenCV2.0\lib and also edited the extra-libraries to ... extra-libraries: highgui200, cv200, cxcore200 4) then set Path=%PATH%;c:\apps\OpenCV2.0\bin unless when installing OpenCV you added the install path to your path.. 5) then ghc Setup build --hsc2hs-options=-L -Wl,-( the --hsc2hs-options=-L -Wl,-( option is neccessary in order to ovoid errors like dist\ghc\6.12.3\build\AI\CV\OpenCV\CV_hsc_make.o:CV_hsc_make.c:(.text+0x85a): un defined reference to `cvFree_' for some reason (and I really can't understand why) gcc requires the highgui200, cv200, cxcore200 libraries after the object (normally dosn't) and the -L -Wl,-( instructs hsc2hs to pass -Wl,-C to gcc, which in turn instructs gcc to pas -( to the linker which in turn tells the linker to re-read the libraries to resolve the references. (somewhere something is going wrong) 6) run the test ... Hi, Yes, I understand that - but if there is some install or usage dependency, or install procedure, I would hope to see it documented somewhere; perhaps I missed that? The only installation procedure I can document is how to do this in linux. My guess is that it must be similar with windows. 1. Get the opencv library from opencv.willowgarage.com 2. Install it and make a note where it installs 3. cabal install CV. If this fails with missing C libraries, then, (4). cabal install CV --with-extra-lib-dirs=where_the_opencv_libs_are --with-extra-include-dirs=where_the_opencv_includes_are However, wait few hours so I can push a new version to hackage. There are few things I've already discovered that fail to work with other people and I think I can fix them. Disclaimer: The CV package is something I threw together, originally in pre-cabal times. Back then I arguably wasn't a very good haskell-programmer and the whole thing was under an nda. Since then I've casually evolved the library to suit my needs. After I saw CV-combinators library released I made a petition to publish my codes in hopes that it would help other people doing similar things. In short, although CV package is very very useful for me, it is not a perfect binding, and the implementation isn't really smart at places. I would like to make it great, however. ___ 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] Haskell memory model (was iterIO-0.1)
On 17/05/2011 00:44, dm-list-haskell-c...@scs.stanford.edu wrote: But I've never heard anyone claim that a prerequisite to Haskell being useful as a parallel programming language is a well-defined memory model. I think there's a couple of reasons for that: - deterministic parallel programming models (e.g. Strategies, monad-par) don't care about memory models. These are the first port of call for parallel programming. Okay, well, I make this claim as a C/C++ programmer more used to writing low-level/kernel code than functional code. So I'm thinking less of things like deterministic scientific codes and more along the lines of network servers processing lots of messages and other asynchronous events happening in a non-deterministic order anyway. I think several programming patterns would be useful in Haskell that require some understanding of the memory model. One that particularly jumps to mind is the read-copy-update (RCU) pattern for frequently accessed but seldom updated data (configuration state, routing tables, etc.) As you've described them, IORefs are well suited to such a pattern because reads are very cheap and updates happen through an atomic pointer write. But if the documentation doesn't say that readIORef is supposed to be cheap (or imply so by mentioning that readIORef exposes the underlying hardware's memory consistency), then there's no way to tell that IORefs are suitable for RCU, so people may think they have to do something uglier using peek and poke. Ok. I'm not sure how feasible RCU is with IORefs, or even whether it's necessary. After all, the usual pattern of having readers use readIORef while writers use atomicModifyIORef gives the RCU cost model (zero overhead for readers, expensive writes) with far less complexity. Garbage collection does the job of reclamation automatically. Have I missed something here? A slight improvement over this scheme is to use TVar with readTVarIO for the readers (no transaction involved), and transactions for the writers. This greatly increases the scope of what a writer can do, since they can perform an update on a bunch of state at the same time. The situation is complicated somewhat by generational garbage collection, which can create weird performance artifacts when mutation is involved. Actually: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent-MVar.html There's nothing in the documentation for MVars that says anything about sequential consistency. That's true, though I think most readers would assume sequential consistency in the absence of any statements to the contrary (obviously you are a counter example ;-). If you take my example from the previous email, replace writeIORef with (\p v - modifyMVar_ p $ return v), replace all other occurrences of IORef with MVar, nothing in the docs suggests you won't see the critical section message printed twice. There is an operational semantics in the Concurrent Haskell paper that does not admit the behaviour you describe, but I'll add something to the docs to that effect. Presumably modifyMVar must take a spinlock. Moreover, to be correct on x86, the spinlock must execute an LFENCE after acquiring the lock and an SFENCE prior to releasing the lock. But does readMVar acquire the spinlock, or is it optimized to take advantage of pointer-sized writes being atomic? That's a good point - readMVar cannot be optimised to avoid the lock. In fact, readMVar is just readMVar m = do x - takeMVar m; putMVar m x; return x although there have been suggestions that we should make it atomic. If we were to do so, it would still have to use a barrier to avoid reordering. Systems have memory models for a reason; you can't get away from them entirely for all applications. Haskell's strength, I think, is in making sure that 99+% of code can't possibly depend on the memory model. For functional and ST code, you don't even need to look at the code to know that this is true--safety is guaranteed by the types (modulo some unsafe stuff I hope will be even easier to detect with ghc 7.2...). But for that last little bit of tricky code, the best you can do is specify the behavior of the building blocks and maybe provide some useful architecture-independent wrappers for things (e.g., abstracted memory barriers). Agree 100%. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
Hey thanks a bunch! Just to clarify matters: HOpenCV is an alternative (and more refined) effort of binding opencv, while CV package is set of bindings I've developed around opencv for various projects I've been involved with. But I'm pretty certain that the same steps for building work for both. Is there anyone on the list who cares to try? test-hopencv.exe: user error (Failed to create camera) which, I have not bothered to follow up any further. Just out of curiosity, what kind of camera did you have plugged in at the time? Ville ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Random thoughts about typeclasses
Robert, 2011/5/16 Robert Clausecker fuz...@gmail.com: I found out, that GHC implements typeclasses as an extra argument, a record that stores all functions of the typeclass. So I was wondering, is there a way (apart from using newtype) to pass a custom record as the typeclass record, to modify the behavior of the typeclass? I thought about something like this: You may be interested in Agda's upcoming instance arguments (inspired upon Scala implicits and Agda's implicit arguments). These will be available in Agda 2.2.12 (you may find references to an older name non-canonical implicit arguments). The new type of function arguments are automatically inferred from call-site scope unless they are explicitly provided. Type classes are directly (not just under the hood) modelled as records, and you can do what you suggest. You can also define local instances, and there are other advantages. We have chosen a more limited-power instance search though. More discussion online. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.InstanceArguments http://people.cs.kuleuven.be/~dominique.devriese/agda-instance-arguments/ I believe a similar Haskell extension (perhaps with a less principled instance search) would improve and simplify Haskell's type class system. By the way, Kahl and Scheffczyk proposed extending Haskell with named instances in 2001 which allowed something like this to a limited extent. Look for Named instances for Haskell Type Classes in Google Scholar. Dominique ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building Haskell Platform natively for 64bit Windows
Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? I have no problem using 32bit version until I need more than 2GB of RAM. I went through some older threads, but description like: 1) install gcc 2) install ghc 3) build platform is something that didn't work well. Is there some more detailed description or recommended versions etc? If there is none then there is no need to respond. Thanks, regards J. -- John Sneer johnsn...@operamail.com -- http://www.fastmail.fm - Does exactly what it says on the tin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell lib in non-Haskell program
Hi all, I'd like to share my experiences packaging a Haskell program so that it can be used as a library by a non-Haskell application. I hope somebody might be able to (A) confirm that I'm doing the right thing or better still (B) suggest some corrections and/or simplifications. My objectives are: 1. For the non-Haskell application to use my library 2. ... without any Haskell infrastructure on the machine I think this means I want a shared library [1,2] although I'm a little bit fuzzy on the issue. I am not particularly concerned about the size of my executable or libraries. Including the Haskell RTS and my package deps is acceptable if that's what it takes to meet my primary and secondary objectives. I am targeting Windows and MacOS X. For Windows, my approach is to build a giant DLL with all the Haskell stuff statically linked in. For MacOS X I am using the `-dynamic` flag to compile all my dependencies (actually, I just set shared: True in cabal config) as well as the `-shared` flag. I am also now using GHC 7.0.3 with the latest (at the time of this writing) Haskell Platform (2011.2.0.1) [1] http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries [2] http://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared-libs.html#id555945 The whole thing -- You can see my efforts so far with darcs get --lazy http://code.haskell.org/GenI cd GenI cabal install cd geniwrapper make MacOS X users should be able to download http://erickow.com/tmp/MinimalGenI-OSX.tar.gz and run a test-mac.sh script which compiles a program with GCC using GenI, runs it and outputs some JSON string. Exposing some C functions and using them -- So far, I think I know how to expose some of library as C functions and to compile a little program written in C that uses this library. ghc --make -fvia-C MinimalGenI # provides some C functions via FFI exports ghc -c StartEnd.c # http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html ghc test-c.c MinimalGenI.o MinimalGenI_stub.o StartEnd.o\ -package GenI -package utf8-string\ -o test-c.o I notice that -fvia-C is going away, but I'm going to ignore this fact for now and assume/hope that doing without it will be easy Building a Windows shared library -- As I understand it, it is possible to build a Windows DLL, albeit one containing the Haskell RTS and all my Haskell libraries statically linked in. Users can download the DLL and link it to their Visual Basic programs without having to touch GHC. The extra work involved looks like this: ghc MinimalGenI.o MinimalGenI_stub.o StartEnd.o\ -package GenI -package utf8-string\ -shared -o MinimalGenI.dll ghc test-c.c MinimalGenI.dll -o test-c2 Note that building test-c.c with ghc does not meet my second objective of being able to combine Haskell lib with non-Haskell program sans Haskell infrastructure. However, I think I know how to do it for MacOS X and that the procedure would be more or less the same. I have not looked into it. [3] http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html Building a MacOS X shared library -- For MacOS X, I would almost like to generate a gigantic file like the Windows DLL. But maybe that's the wrong thing to want. I do almost exactly the same thing, except that instead of distributing a single giant file, I track down a whole bunch of dependencies and copy over the dylib files for them. Note that as a prerequisite, this requires reinstalling a lot of packages with --enable-shared (I just edit ~/.cabal/config and set shared to True). ghc MinimalGenI.o MinimalGenI_stub.o StartEnd.o\ -package GenI -package utf8-string\ -dynamic -shared -o MinimalGenI.dylib ghc test-c.c MinimalGenI.dylib -o test-c2 As an alternative to building with GHC, I can compile test-c.c and link with MinimalGenI.dylib directly with GCC. It's a little bit hairy. What I did was to run ghc with -v3 to see what gcc commands it was running, clean them up and package them in a script (test-mac.sh attached). It's a little bit voodoo-ish, a lot of flags that I don't really understand the significance of, and some libraries I'm not 100% clear on why I need the static versions for. Also I find it slightly odd that I can't seem to just merge the first two steps of the process, producing/assembling assembly code for test.c. In any case, it seems to work... Packaging the MacOS X shared library -- I'm trying to distribute my Haskell library in a way that does not require the user to install anything beyond XCode. To do this, I track
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. The Web application idea might be a useful workaround for some, like X11 may be acceptable for others, but these could be thought of as exceptions that prove the rule. If that's enough to solve the problem, then there would appear to be little call for Mac GUI applications. My only Haskell application on my ancient PPC Mac uses the terminal, but long ago I tried a Haskell Cocoa library, HOC, that would have supported native graphics, if it had worked for me. Has anyone taken that route with an application? I have been using native API graphics on another more obscure platform (Haiku), of course not portable but much easier to get working than the gigantic cross platform GUI toolkits, and maybe that would address the chicken vs egg problem that helps make Mac GUI apps a non-issue for Haskell. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs graphics)
Hi On Wed, May 18, 2011 at 09:18:42 +0100, Andrew Butterfield wrote: Alas - I have yet to be able to build it on Mac OS X (Snow Leopard) For what it's worth, I'm still using wxHaskell on MacOS X (also Snow Leopoard) The tricky bits are that you have to 1. install wxWidgets by hand, being sure to enable Unicode and to compile a 32 bit version: arch_flags=-arch i386 ./configure CFLAGS=$arch_flags\ CXXFLAGS=$arch_flags\ CPPFLAGS=$arch_flags\ LDFLAGS=$arch_flags\ OBJCFLAGS=$arch_flags\ OBJCXXFLAGS=$arch_flags\ --enable-unicode 2. do the Rez and app bundle magic which is now handily encapsulated in the cabal-macosx package on hackage I also have patches to make it work with the latest Haskell Platform and will put them on Hackage shortly assuming nobody objects darcs get --lazy http://darcsden.com/kowey/wxhaskell Unfortunately, this does not address Conal's issue about using wxHaskell with GHCi on Mac. I do wish somebody had a free week to concentrate on the issue. Maintainer Jeremy made some progress on it, the last time I checked... -- Eric Kow http://erickow.com pgplsou93emGR.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is fusion overrated?
On Wed, May 18, 2011 at 2:04 AM, Ryan Ingram ryani.s...@gmail.com wrote: Yes, the goal isn't so much to improve complexity (both are O(1)) but to reduce the constant factor on that O(1). In an inner loop like that, allocator/gc calls by far dominate the cost of the program. If you can remove them, you've improved the performance of the program by 10-100x. Yes, this is important. Fusion is an obvious win on strict structures, because it can make the space usage asymptotically better. However, even if this doesn't happen for lazy structures, fusion can save a lot of _time_. It won't make the time complexity asymptotically better, but it can save an amount of work proportional to the complexity of the algorithm. For instance, I was playing around with uvector a while back, and needed foldr or something similar that wasn't available. So I wrote something like: foldr f z s = if null s then z else f (head s) (tail s) This all ran in constant space, but tail re-unfolds the entire stream every time, so this function has time complexity O(n^2). The nth element chugs through n allocation-followed-by-deallocations before it becomes usable, which can all be done in constant space, but takes linear time. Fusion won't save you in this example (to my knowledge). But if you compose k functions from lists to lists together, you'll have k allocations-followed-by-deallocations on every element that makes it all the way through the pipeline. You'll see O(1) space usage, but your time usage has a c*k*n term simply from being expressed by a composition pipeline, where c is the cost of the unnecessary boxing. Fusion eliminates this term. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is fusion overrated?
which is capable of producing elements one-by-one. So the whole thing probably should run in constant space as well. Besides reducing the amount of GC calls, performance would also improve because the GC calls that remain are cheaper. The original program may run in constant space, but the fused program may use even a smaller constant space. Which in turn means that whenever the GC needs to make a pass, it is faster. Facundo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell memory model (was iterIO-0.1)
At Wed, 18 May 2011 09:56:22 +0100, Simon Marlow wrote: Ok. I'm not sure how feasible RCU is with IORefs, or even whether it's necessary. After all, the usual pattern of having readers use readIORef while writers use atomicModifyIORef gives the RCU cost model (zero overhead for readers, expensive writes) with far less complexity. Garbage collection does the job of reclamation automatically. Have I missed something here? Right, that's what I was calling RCU. Usually the hard part in RCU is the garbage collection. Obviously if you needed to do something else like close a file handle, then IORefs are not sufficient. But for a lot of applications of RCU, IORefs plus garbage collection should be sufficient. A slight improvement over this scheme is to use TVar with readTVarIO for the readers (no transaction involved), and transactions for the writers. This greatly increases the scope of what a writer can do, since they can perform an update on a bunch of state at the same time. Good point. There is an operational semantics in the Concurrent Haskell paper that does not admit the behaviour you describe, but I'll add something to the docs to that effect. Ah, you got me. I probably should have looked at that paper, which is linked to from Control.Concurrent. Still, in some cases (not necessarily here), papers are static and code continues to evolve, so it's nice to stuff documented in haddock as well. That's a good point - readMVar cannot be optimised to avoid the lock. In fact, readMVar is just readMVar m = do x - takeMVar m; putMVar m x; return x although there have been suggestions that we should make it atomic. If we were to do so, it would still have to use a barrier to avoid reordering. What would be even cooler would be if swapMVar could be made atomic. Or better yet, if there could be a compareAndSwapMVar, since on some architectures (though not x86) that could be a single instruction and allow for truly wait-free data types. (That might not be possible without sacrificing referential transparency, since the obvious implementation would involve comparing pointers rather than values.) David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] blaze-builder and FlexibleInstances in code that aims to become part of the Haskell platform
Hello Haskell-Cafe,
my main question is whether requiring FlexibleInstances is a problem
for code that aims to become part of the Haskell platform. The
following explanation gives the context for this question.
As some of you may know the blaze-builder library is now used in quite
a few places. That's nice, but it doesn't mean that blaze-builder is a
finished solution to the problem of providing an API for
high-performance buffered output (creation of chunked representations)
of sequences of bytes.
In fact, one of my current goals with this work is to polish it such
that it can be integrated into the 'bytestring' library. This has the
benefit that functions that create lazy bytestrings (e.g., pack, map,
unfoldr, filter) can be implemented such that they create well-sized
chunks even if the argument bytestring is hugely fragmented. Moreover,
this integration also establishes a single builder type as the output
representation. Therefore, other creators of bytestrings (e.g.,
'text', 'base16-bytestring', 'zlib') can provide results of type
Builder, which enables O(1) appends of their results and the
preservation of well-sizedness of the created chunks.
As part of this goal, I'm currently working on the first of the
following three points that are paramount to achieving great encoding
performance:
1. Ensure that individual Haskell values are encoded with minimal overhead.
2. Ensure that concatenation of sequences of bytes is efficient.
3. Ensure that the average chunk size is large.
The core principle used to tackle (1) is avoiding intermediate data
structures. The core abstraction used is the one of a Write (see [1]
for the corresponding library.)
data Write a = Write Int (a - Ptr Word8 - IO (Ptr Word8))
A value `Write bound io :: Write a` denotes an encoding scheme for
values of type `a` that uses at most `bound` bytes space. Given a
values `x :: a` and a pointer `po` to the next free byte `io x po`
encodes `x` to memory starting from `po` and returns the pointer to
the next free byte after the encoding of `x`.
In most cases Writes are used as an abstract datatype. They serve as
an interface between implementors of the low-level bit-twiddling
required to efficiently implement encodings like UTF-8 or Base16 and
the providers of efficient traversal functions through streams of
Haskell values. Hence, typical users of Writes are functions like
fromWrite :: Write a - a - Builder
fromWriteList :: Write a - [a] - Builder
fromWriteUnfoldr :: Write b - (a - Maybe (b, a)) - a - Builder
mapWriteByteString :: Write Word8 - S.ByteString - Builder
They consume the given datastructure efficiently and wrap the Writes
in the bounds checking code to detect when a buffer is full and
request a new one.
There are many providers of Writes. Each bounded-length-encoding of a
standard Haskell value is likely to have a corresponding Write. For
example, encoding an Int32 as a big-endian, little-endian, and
host-endian byte-sequence is currently achieved with the following
three functions.
writeInt32BE :: Write Int32
writeInt32LE :: Write Int32
writeInt32HE :: Write Int32
I would like to avoid naming all these encodings individually.
Especially, as the situation becomes worse for more elaborate
encodings like hexadecimal encodings. There, we encounter encodings
like the utf8-encoding of the hexadecimal-encoding with lower-case
letters of an Int32.
writeInt32HexLowerUtf8 :: Write Int32
I really don't like that. Therefore, I'm thinking about the following
solution based on type-classes. We introduce a single typeclass
class Writable a where
write :: Write a
and use a bunch of newtypes to denote our encodings.
newtype Ascii7 a = Ascii7 { unAscii7 :: a }
newtype Utf8 a = Utf8 { unUtf8 :: a }
newtype HexUpper a = HexUpper { unHexUpper :: a }
newtype HexLower a = HexLower { unHexLower :: a }
...
Assuming FlexibleInstnaces, we can write encodings like the above
hex-encoding as instances
instance Write (Utf8 (HexLower Int32)) where
write = ...
This composes rather nicely and allows the implementations to exploit
special properties of the involved data. For example, if we also had a
HTML escaping marker
newtype Html a = Html { unHtml :: a }
Then, the instance
instance Write (Utf8 (HTML (HexLower Int32))) where
write (Utf8 (HTML (HexLower i))) = write (Utf8 (HexLower i))
exploits that no HTML escaping is required for a hex-number. Assuming
FlexibleContexts, the user can also build abbreviations for builders
using fixed encodings.
utf8 :: Writable (Utf8 a) = a - Builder
utf8 = fromWrite write . Utf8
Note that, on the Builder level, a probably better way would be to
have an analogous 'ToBuilder' typeclass to abstract the various
encodings. Part of these instances then reuse the corresponding
instances from Writable.
I think this type-class based interface to select the correct
efficient implementation of an
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Wed, May 18, 2011 at 11:09 AM, Jason Dagit dag...@gmail.com wrote: Support for OpenGL comes in different levels of quality, as I'm discovering. It would seem that Mesa (ie., linux support), only officially supports OpenGL 2.1 [1] despite being released on 6 April 2011. I haven't been able to get OpenGL 3.0+ specific features to work on linux with Haskell yet. [1] http://www.mesa3d.org/relnotes-7.10.2.html Sorry, I forgot the link! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Tue, May 17, 2011 at 4:24 PM, Conal Elliott co...@conal.net wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. Support for OpenGL comes in different levels of quality, as I'm discovering. It would seem that Mesa (ie., linux support), only officially supports OpenGL 2.1 [1] despite being released on 6 April 2011. I haven't been able to get OpenGL 3.0+ specific features to work on linux with Haskell yet. I find that you really want OpenGL 3.1 or newer. The Khronos group really did a lot of nice things with the 3.x specification and 4.x is even better. Some people in this thread have suggested doing web apps. This won't work well yet for people who want OpenGL support. My experiments with webgl show that it's not mature yet. You have to target a specific browser and OS at the moment, with linux having the worst support by far. Firefox 4 and Chrome on windows fair the best so far. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. Yes, I know the feeling all too well. I'd like to fix this situation. I took over maintainership of the Haskell OpenGL bindings hoping that I could improve them. We now have a google summer of code student working on the bindings to update them and improve the overall quality. That's just one piece of the puzzle. If you'd like to contribute to that piece of the puzzle we have an organization on github for Haskell OpenGL: https://github.com/haskell-opengl Send some pull requests or add bug tickets! As you point out we also need better libraries for creating the OpenGL context. I wrote up my searches on that front here: http://blog.codersbase.com/2011/03/picking-gui-library-to-use-with-opengl.html My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Wed, May 18, 2011 at 2:50 AM, John Sneer johnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11, Donn Cave d...@avvanta.com wrote: Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. If we use Haskell essentially as a JS abstraction layer, we lose all type safety (in the event that anyone goes in and tinkers with the generated JS). A main reason people are showing interest in FP is because of purity, and therefore its potential speed on multicore machines. If we just generate to JS, this is also lost. In fact, speed on single-core machines is lost also. Again, my 2¢, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] blaze-builder and FlexibleInstances in code that aims to become part of the Haskell platform
On Wed, May 18, 2011 at 12:32 PM, Simon Meier iridc...@gmail.com wrote:
Hello Haskell-Cafe,
There are many providers of Writes. Each bounded-length-encoding of a
standard Haskell value is likely to have a corresponding Write. For
example, encoding an Int32 as a big-endian, little-endian, and
host-endian byte-sequence is currently achieved with the following
three functions.
writeInt32BE :: Write Int32
writeInt32LE :: Write Int32
writeInt32HE :: Write Int32
I would like to avoid naming all these encodings individually.
Especially, as the situation becomes worse for more elaborate
encodings like hexadecimal encodings. There, we encounter encodings
like the utf8-encoding of the hexadecimal-encoding with lower-case
letters of an Int32.
writeInt32HexLowerUtf8 :: Write Int32
I really don't like that. Therefore, I'm thinking about the following
solution based on type-classes. We introduce a single typeclass
class Writable a where
write :: Write a
and use a bunch of newtypes to denote our encodings.
newtype Ascii7 a = Ascii7 { unAscii7 :: a }
newtype Utf8 a = Utf8 { unUtf8 :: a }
newtype HexUpper a = HexUpper { unHexUpper :: a }
newtype HexLower a = HexLower { unHexLower :: a }
...
Assuming FlexibleInstnaces, we can write encodings like the above
hex-encoding as instances
instance Write (Utf8 (HexLower Int32)) where
write = ...
This composes rather nicely and allows the implementations to exploit
special properties of the involved data. For example, if we also had a
HTML escaping marker
newtype Html a = Html { unHtml :: a }
Then, the instance
instance Write (Utf8 (HTML (HexLower Int32))) where
write (Utf8 (HTML (HexLower i))) = write (Utf8 (HexLower i))
If I were authoring the above code, I don't see why that code is any
easier to write or easier to read than:
urf8HtmlHexLower i = utf8HexLower i
And if I were using the encoding functions, I would much prefer to see:
urf8HtmlHexLower magicNumber
In my code, instead of:
write $ Utf8 $ HTML $ HexLower magicNumber
In addition, this would be difficult for me as a developer using the
proposed library, because I would have no way to know which
combinations of newtypes are valid from reading the haddocks.
Maybe I'm missing something fundamental, but this approach seems more
cumbersome to me as a library author (more boilerplate) and as the
user of the library (less clarity in the docs and in the resultant
code).
Antoine
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable). And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Count me as onboard; I'm just not sure which ship I'm on yet. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
Thanks! I’ll wait, and then try this later today. And another previous note also described a successful install, I can also try that. It seems to me that having easy install of such common libraries is a big advantage of C++/C#/.. even SML(!), and is important to wider usage of Haskell. From: Ville Tirronen [mailto:alea...@gmail.com] Sent: Tuesday, May 17, 2011 11:33 PM To: Gregory Guthrie Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows? Hi, Yes, I understand that - but if there is some install or usage dependency, or install procedure, I would hope to see it documented somewhere; perhaps I missed that? The only installation procedure I can document is how to do this in linux. My guess is that it must be similar with windows. 1. Get the opencv library from opencv.willowgarage.comhttp://opencv.willowgarage.com 2. Install it and make a note where it installs 3. cabal install CV. If this fails with missing C libraries, then, (4). cabal install CV --with-extra-lib-dirs=where_the_opencv_libs_are --with-extra-include-dirs=where_the_opencv_includes_are However, wait few hours so I can push a new version to hackage. There are few things I've already discovered that fail to work with other people and I think I can fix them. Disclaimer: The CV package is something I threw together, originally in pre-cabal times. Back then I arguably wasn't a very good haskell-programmer and the whole thing was under an nda. Since then I've casually evolved the library to suit my needs. After I saw CV-combinators library released I made a petition to publish my codes in hopes that it would help other people doing similar things. In short, although CV package is very very useful for me, it is not a perfect binding, and the implementation isn't really smart at places. I would like to make it great, however. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs graphics)
The tricky bits are that you have to 1. install wxWidgets by hand, being sure to enable Unicode and to compile a 32 bit version: arch_flags=-arch i386 ./configure CFLAGS=$arch_flags\ CXXFLAGS=$arch_flags\ CPPFLAGS=$arch_flags\ LDFLAGS=$arch_flags\ OBJCFLAGS=$arch_flags\ OBJCXXFLAGS=$arch_flags\ --enable-unicode Is there a way to build an installer that would make this process easier? Unfortunately, this does not address Conal's issue about using wxHaskell with GHCi on Mac. I do wish somebody had a free week to concentrate on the issue. Maintainer Jeremy made some progress on it, the last time I checked... Do you have the link for the progress so far? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Thanks, Heinrich! I tried your sample code (having grabbed compiled EnableGUI.hs). Works okay, including multiple calls to 'main'. There are a few subtle quirks. I don't see the usual bottom-right resize icon (three parallel lines at 45 degrees), and the Zooom/2 program for convenient window moving resizing isn't able to move resize this one window. Have you noticed something similar? - Conal On Wed, May 18, 2011 at 12:33 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! I've asked a similar question on stackoverflow http://stackoverflow.com/questions/5868916/ and answered it myself. Basically, GLFW works (on my machine) as long as you don't call the GLFW.terminate function. The answer includes an example program that you can try out. It might be worth to include the extra hoops (EnableGUI) in the GLFW package. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ 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] Status of Haskell + Mac + GUIs graphics
On 18 May 2011 19:25, Tom Murphy amin...@gmail.com wrote: I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, ... I don't think that not having something as desireable good GUI suited anyone much, nor has it actually been a low priority - a lot of work has gone into the tools we have (and those that are now bit-rotted). It's more a case of an industrial level of effort is needed to develop and maintain a GUI solution. Java's Swing and Microsoft's Dot.Net had teams of programmers building them as loss leaders to establish their platforms. Similarly even GTK has had huge amount of resources invested in it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal On Wed, May 18, 2011 at 11:42 AM, Tom Murphy amin...@gmail.com wrote: My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable). And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Count me as onboard; I'm just not sure which ship I'm on yet. Tom ___ 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] Status of Haskell + Mac + GUIs graphics
Conal Elliott wrote: Thanks, Heinrich! I tried your sample code (having grabbed compiled EnableGUI.hs). Works okay, including multiple calls to 'main'. There are a few subtle quirks. I don't see the usual bottom-right resize icon (three parallel lines at 45 degrees), and the Zooom/2 program for convenient window moving resizing isn't able to move resize this one window. Have you noticed something similar? Indeed, same problem here. While I can resize the window, it doesn't show the corresponding icon. (I don't use Zooom/2.) This seems to be a problem with the GLFW library; you may want to file a bug report. I glean from Apple's documentation that a a judicious call to [window setShowsResizeIndicator:TRUE] at the time of window creation might solve the problem. Cocoa is always a little unpredictable when creating UI elements from scratch. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GPL, LGPL, and GHC Linking
Hello everyone! I just want to let you know that I have written a blog post about my thoughts about the issue of GHC linking and the General Public Licenses. I welcome any feedback or discussions around it. You can find the post at http://www.jonkristensen.com/gpl-lgpl-and-ghc-linking/. Warm regards, Jon Kristensen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (20th ed., May 2011)
On behalf of all the contributors, I am pleased to announce that the Haskell Communities and Activities Report (20th edition, May 2011) is now available in PDF and HTML formats: http://haskell.org/communities/05-2011/report.pdf http://haskell.org/communities/05-2011/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: == End of October 2011: target deadline for contributions to the November 2011 edition of the HCA Report == Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in October (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Regarding 3: I was not implying that Haskell should be used only for replacing JS. Far from it. I was just saying that we need a solid way to generate JS from Haskell so that we can profit even more from Haskell's type safety and not have to suffer from the mess that is JS. My Snap-based application is also perfectly type-safe, on the server. It's fast too. :) On 18 May, 2011, at 20:25 , Tom Murphy wrote: On 5/18/11, Donn Cave d...@avvanta.com wrote: Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. If we use Haskell essentially as a JS abstraction layer, we lose all type safety (in the event that anyone goes in and tinkers with the generated JS). A main reason people are showing interest in FP is because of purity, and therefore its potential speed on multicore machines. If we just generate to JS, this is also lost. In fact, speed on single-core machines is lost also. Again, my 2¢, Tom ___ 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] ANNOUNCE: levmar-1.0
Dear all, I released levmar-1.0, an implementation of the Levenberg-Marquardt minimization algorithm that can be used for least squares, curve fitting and nonlinear programming. The most important change in this release is the use of vectors and matrices from the hmatrix package (which uses the high performance vector package). An application at work became 25 times faster when switching to the new levmar! I'm not sure this major speedup can be entirely attributed to the switch from lists to vectors. I also switched the FFI types from CDouble to Double in the internal bindings-levmar package. This made the expensive realToFrac conversions from CDouble to Double unnecessary which I believe had a big impact. API Documentation: http://hackage.haskell.org/package/levmar-1.0 I also switched the repository from darcs to git and hosted it on github: https://github.com/basvandijk/levmar/ Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11, Jurriën Stutterheim j.stutterh...@me.com wrote: Regarding 3: I was not implying that Haskell should be used only for replacing JS. Far from it. I was just saying that we need a solid way to generate JS from Haskell so that we can profit even more from Haskell's type safety and not have to suffer from the mess that is JS. My Snap-based application is also perfectly type-safe, on the server. It's fast too. :) Jurriën, I completely agree that we need a good JS generator. My response was just to the idea that web apps (with JS) could be a replacement for other GUI solutions. I wasn't implying you were saying we should only use Haskell for JS. Most useful Haskell apps right now are pretty GUI-free! Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] blaze-builder and FlexibleInstances in code that aims to become part of the Haskell platform
On Wed, May 18, 2011 at 12:32 PM, Simon Meier iridc...@gmail.com wrote: I think this type-class based interface to select the correct efficient implementation of an encoding is rather nice. However, I don't know if 'FlexibleInstances' and 'FlexibleContexts' are fine to use in code that aims to become part of the Haskell platform. Moreover, I might well overlook some drawbacks of this design. I forgot to answer your main question :-) I don't have a problem with these extensions being in the Haskell Platform, as the platform currently only targets GHC, but the bytestring package itself might have a higher standard of portability. Have you heard from the 'bytestring' maintainers? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No fish, please
On 18/05/2011 05:28 AM, Don Stewart wrote: I'm intrigued by the idea of Hackage docs that don't use Haddock. This is basically the reason I asked. Currently Cabal assumes that Haddock is the only tool of its kind. If somebody built a better Haddock, you wouldn't be able to use it. (Unless you named the executable haddock and made it accept the same command options.) Also, Haddock generates API reference documentation. It does not really support generating tutorials, introductions, HOWTOs, and all the other types of useful documentation that a project ought to have. IF you do have better docs, host them somewhere, and put a link prominently in the .cabal file synopsis. That works, but it does mean that you can't read the documentation offline. (It also requires you to have somewhere to host, which not everybody has. Hackage provides hosting for the code itself, but you can only host documentation there if it's Haddock.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No fish, please
On Wednesday 18 May 2011 23:39:47, Andrew Coppin wrote: On 18/05/2011 05:28 AM, Don Stewart wrote: I'm intrigued by the idea of Hackage docs that don't use Haddock. This is basically the reason I asked. Currently Cabal assumes that Haddock is the only tool of its kind. If somebody built a better Haddock, you wouldn't be able to use it. (Unless you named the executable haddock and made it accept the same command options.) Or maybe support for that tool would be integrated into Cabal and cabal and hackage. But even while such a tool is not yet available, it would be worth thinkng about hackage offering the possibility to display other docs than haddock- generated ones. Also, Haddock generates API reference documentation. It does not really support generating tutorials, introductions, HOWTOs, and all the other types of useful documentation that a project ought to have. IF you do have better docs, host them somewhere, and put a link prominently in the .cabal file synopsis. That works, but it does mean that you can't read the documentation offline. Make it downloadable? Include the docs in the package (extra-source-files: thedocs.tar.gz) and mention it in the package descripiton for a (less than optimal) workaround. (It also requires you to have somewhere to host, which not everybody has. Haskellwiki, bitbucket, github, ... Hackage provides hosting for the code itself, but you can only host documentation there if it's Haddock.) Yes, hackage is code hosting and not tutorial etc. hosting. Maybe integrating that would be a good thing, but even so, there are feasible ways of making additional documentation available. Sure, a centralised documentation-hosting would have advantages over sprinkling over all the free project-hosting services, but the situation is not unbearably dire as is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No fish, please
On 19 May 2011 08:09, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Wednesday 18 May 2011 23:39:47, Andrew Coppin wrote: (It also requires you to have somewhere to host, which not everybody has. Haskellwiki, bitbucket, github, ... Also if you have a project on code.haskell.org, then you also can have a website for it on projects.haskell.org -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs graphics)
On Wed, May 18, 2011 at 15:06:02 -0400, Tom Murphy wrote: Is there a way to build an installer that would make this process easier? I've sent a pull request to the maintainer of homebrew. Hopefully it should then just be a matter of brew install wxmac Homebrew's wxWidgets already builds 32 bit, but it omitted the enable-unicode, which is what my patch fixes) Unfortunately, this does not address Conal's issue about using wxHaskell with GHCi on Mac. I do wish somebody had a free week to concentrate on the issue. Maintainer Jeremy made some progress on it, the last time I checked... Do you have the link for the progress so far? Jeremy's blog seems to talk about this: http://wewantarock.wordpress.com/ I remember that the impression that Brian Lewis was also looking into this at some point http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00744.html If anybody knows what this unknown symbol `__dso_handle' means and what we can do about it, it could be a great help I wonder if GHC 7 makes any of this easier... -- Eric Kow http://erickow.com pgpnPJd9AeMiH.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 182
Welcome to issue 180 of the HWN, a newsletter covering developments in the Haskell community. This release covers the week of May 8 to 14, 2011. Announcements Eric Kow released the second edition of Parallel Haskell Digest [http://goo.gl/OXGIw]. Don Stewart sent in a proposal from the Haskell.org committee to incorporate Haskell.org [http://goo.gl/X1j8i]. Lazycat Manatee has released a new version of Manatee [http://goo.gl/vVTgy]. Quotes of the Week * Richard O'Keefe: [On iterators and generators] This being Haskell, I'm expecting to see Cogenerator... * luqui: Haskell is a DSL for writing monad tutorials. * mattmight: Coq is a tool for turning ordinary programs into POPL papers. * kmc: most CS courses will teach you four kinds of Java * geheimdienst: haskell makes hard things easy and easy things a strong lax monoidal endofunctor ... * spoolio: Haskell programmers know the cost of nothing, the type of everything, and might know the value of a few things later. * catamorphism: FP is related to FP in the same way that UML is related to OOP. * geheimdienst: * geheimdienst will from now on use a function carpeTiem aliased to getCurrentTime * edwardk: [on data-accessor] However, its choice of internal representation makes me throw up in my mouth a little bit Top Reddit Stories * Fancy function graphs! Domain: pnyf.inf.elte.hu, Score: 47, Comments: 21 On Reddit: http://goo.gl/ibZO1 Original: http://goo.gl/24hQ6 * Online SVG figures with Haskell Domain: self.haskell, Score: 46, Comments: 11 On Reddit: http://goo.gl/jgxk4 * Erlang-in-Haskell: an implementation of an Erlang-like distributed computing framework for Haskell Domain: hackage.haskell.org, Score: 41, Comments: 2 On Reddit: http://goo.gl/yMMRG Original: http://goo.gl/eq6s3 * Why Eager Languages Don't Have Products and Lazy Languages Don't Have Sums Domain: james-iry.blogspot.com, Score: 38, Comments: 35 On Reddit: http://goo.gl/ngpNe Original: http://goo.gl/2O6yq * Introducing JsonGrammar Domain: martijn.van.steenbergen.nl, Score: 34, Comments: 2 On Reddit: http://goo.gl/wiGI9 Original: http://goo.gl/ns20k * The reasons I don't write all my code in Haskell Domain: codeflow.wordpress.com, Score: 33, Comments: 34 On Reddit: http://goo.gl/HMZ8c Original: http://goo.gl/hyuSa * Experimental GHC with GHCJS built in and Cabal support for JavaScript files Domain: article.gmane.org, Score: 30, Comments: 3 On Reddit: http://goo.gl/8zzZT Original: http://goo.gl/MQMvN * Two fun bits of Haskell teaching news Domain: serpentine.com.nyud.net, Score: 28, Comments: 3 On Reddit: http://goo.gl/JQUtF Original: http://goo.gl/mYz1q * Themes on Streams Domain: byorgey.wordpress.com, Score: 26, Comments: 1 On Reddit: http://goo.gl/ywP1K Original: http://goo.gl/ywPnl * CmdArgs - Fighting the GHC Optimiser Domain: neilmitchell.blogspot.com, Score: 20, Comments: 15 On Reddit: http://goo.gl/0WThF Original: http://goo.gl/CgCgz Top StackOverflow Questions * Safe execution of untrusted Haskell code votes: 19, answers: 2 http://goo.gl/9eHuc * When do I use ByteString and when do I not? votes: 16, answers: 2 http://goo.gl/vVQig * Why can I not make String an instance of a typeclass? votes: 14, answers: 3 http://goo.gl/Pn8DS * Android application in haskell votes: 11, answers: 1 http://goo.gl/UfnA1 * What are the most important abstractions in Haskell? Monads? Applicatives? votes: 9, answers: 3 http://goo.gl/RaXVQ About the Haskell Weekly News To help create new editions of this newsletter, please send stories to dstc...@gmail.com. Until next time, Daniel Santa Cruz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Jurriën Stutterheim: A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. For cross-platform apps, I have to agree. The effort required to build and maintain a cross-platform GUI toolkit is hard to justify given HTML 5 and related technologies. Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one. Manuel On 18 May, 2011, at 08:29 , Tom Murphy wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ 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] Status of Haskell + Mac + GUIs graphics
On 5/18/11 2:25 PM, Tom Murphy wrote: I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. I agree with these disagreements. Web apps have long been touted as a replacement for desktop apps. For certain specific kinds of domains people have been able to realize them sufficiently well as web apps. But I am still of the firm belief that there are numerous domains where browser-based UIs are wholly inappropriate. Thus, GUIs (especially OS-integrated GUIs) will remain a necessity for the foreseeable future. Moreover, for many people, the lack of native GUI support calls into question how mature and ready for serious work a language is; so developing a solid GUI story can be important publicity work. Beyond this, I can't say, since I rarely work on tools that require graphical interfaces. But I'd love to see a nice Cocoa--Haskell bridgework, since that's the kind of GUI I'm most liable to use/need. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11 10:54 PM, Manuel M T Chakravarty wrote: Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one. Well, there may be some non-trivial technical work in figuring out how to do good Haskell-like high-level bindings, rather than low-level bindings that shove everything into IO. Also, ensuring type safety across the border is extremely non-trivial, especially because Objective C's object system is on the untyped/Smalltalk end of things. It's possible to just treat their types like they do, but I'm sure many Haskellers would prefer to make the typing more explicit and checkable (so long as it's still usable). But yes, the mere process of making bindings isn't especially cumbersome. Anyone interested in prior art should take a look at the Perl--ObjectiveC bridgework, CamelBones: http://camelbones.sourceforge.net/ -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Quoth wren ng thornton w...@freegeek.org, ... But yes, the mere process of making bindings isn't especially cumbersome. Anyone interested in prior art should take a look at the Perl--ObjectiveC bridgework, CamelBones: http://camelbones.sourceforge.net/ Note (again) that there's already some work in this area, http://code.google.com/p/hoc/ My recollection from trying it several years ago was that there must indeed have been something especially cumbersome about it, given the prodigiously long time it would take to build an application, but it could be better now. In any case, I don't think it would be a crime to try a fresh start. With good Haskell-like high-level bindings, or not. If I were to work on it (as I was somewhat inspired to think about after reading Jason Dagit's comments), it would be the thinnest possible layer, with names unchanged and semantics preserved as possible. High level bindings can be applied on top of that, as required. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one. Can anyone point me to a good resource comparing the pros and cons of developing (say, Cocoa) bindings vs. using a cross-platform library with native look-and-feel like Wx? Thanks, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
