[Haskell-cafe] blanket license for Haskell Platform?
So I'm combining Haskell software with some non-free/closed source work. I was wondering what sort of effort it would take to organise a blanket license for everything in the Haskell Platform, and whether it would be worthwhile to anybody. Here's my use case: - I am combining my Haskell [:-)] program with some non-free/closed source [:-(] software - My user is concerned that a large number of having a large number of individual licenses even though textually identical modulo author, date, etc would mean a big hassle getting their lawyers and their user's lawyers to sign off on each and every license I feel a bit embarrassed asking this as it's already great and also very convenient that I can just grab this closed source stuff, but suppose we were to decide that putting together some sort of blanket license for the Haskell Platform would be a good idea. How would we go about organising such an effort? I wonder if this is a sort of thing we could tie to the IHG... Thanks, -- Eric Kow http://erickow.com pgp8VHBXNDPT5.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] blanket license for Haskell Platform?
On Tue, Oct 25, 2011 at 21:46:21 +1100, Ivan Lazar Miljenovic wrote: - My user is concerned that a large number of having a large number of individual licenses even though textually identical modulo author, date, etc would mean a big hassle getting their lawyers and their user's lawyers to sign off on each and every license Why do their lawyers all need to sign off individually for BSD licenses (which if memory serves all platform libraries have to be licensed under, or some variant thereof)? At most it just means they need to lump them all into one big text file somewhere saying which libraries they used... (then again, IANAL, and don't charge by the hour to consider these complex technical questions :p). I find the whole thing baffling myself. I'd thought this would be the sensible thing to do, but I guess when it comes to these licensing things it's not the actual pain that counts, but the perceived potential pain. Know what I mean? It's similar to the won't touch with a 10ft pole attitude to the GPL that some entities may take. It's basically a precautionary la la la; I can't hear you or a conservative stance which consists of I don't understand this stuff, so I'm going to do the thing that seems safest to me, which may or may not be a reasonable reaction... Well, it would need copyright attribution/agreement of everyone that's ever committed code to any library/application to the Platform (which is why so many large projects want it) to re-license them AFAIK, which may be difficult. I could just say it'd be unrealistic. Just trying to be thorough. -- Eric Kow http://erickow.com pgpJtBqlfeVqc.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal license check?
On Mon, Oct 10, 2011 at 17:24:18 +0200, Henk-Jan van Tuyl wrote: I'd like a tool that takes a .cabal file as input and produces a list of all dependencies (recursive, all the way to 'base') and some metadata for each (most importantly, LICENSE) cab[0] can do that, for installed packages: cab deps -i -r -a vector Thanks! That's close enough. -- Eric Kow http://erickow.com pgpLY3fnHFC9s.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal license check?
Hi all, I'd like a tool that takes a .cabal file as input and produces a list of all dependencies (recursive, all the way to 'base') and some metadata for each (most importantly, LICENSE) Does this already exist, or will I to write it myself? I notice that there's a patch by Trevor Elliot to either Cabal or cabal-install that does something similar [1], and I know that Magnus Therning wrote a little tool that creates a GraphViz graph [2]... so it seems like all the pieces are there already. But is there anything in some sort of ready-to-go just-works state, doing everything including interacting with hackage and sucking down the cabal files it needs, etc? Thanks, Eric [1]: http://www.haskell.org/pipermail/cabal-devel/2010-October/006657.html [2]: http://therning.org/magnus/archives/534 -- Eric Kow http://erickow.com pgpZHM5wGwXPp.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parallel Haskell Digest 6
Parallel Haskell Digest === Edition 6 2011-10-06 Hello Haskellers! This edition of the Parallel Haskell Digest kicks off with some [warm feelings][n1] from BioHaskeller Ketil Malde Blessing of the day goes to the authors of threadscope. In fact, let me look it up: Donnie Jones, Simon Marlow, and Satnam Singh. I had an old STM experiment lying around, but couldn't quite make it go faster than the single threaded version. Today I installed threadscope, and a glance at the output sufficed to identify the problem, and now at least it's faster. Great tool! (But you all knew that, of course) Thanks indeed to the original authors of ThreadScope! Ketil made good use of the original ThreadScope. Since the original release, the folks at Well-Typed have taken over development on ThreadScope (Andres, Duncan, and Mikolaj) and are working to extend it so that it becomes even easier to squash those pesky performance bugs. These extensions, much like this digest, are made possible by the [Parallel GHC Project][n0]. We hope you'll love the results. News -- [Data Parallelism in Haskell][n2] slides and video Manuel Chakravarty came all the way from Sydney (that's 931 km!) to tell the Brisbane FP Group about work going on at UNSW on data parallel programming in Haskell. The talk covers a lot of ground. It's an hour and a half long and [It] motivates the use of functional programming for parallel, and in particular, data parallel programming and explains the difference between regular and irregular (or nested) data parallelism. It also discusses the Repa library (regular data parallelism for multicore CPUs), the embedded language Accelerate (regular data parallelism for GPUs), and Data Parallel Haskell (nested data parallelism for multicore CPUs). Both video and slides are available, so check it out! Word of the Month -- The word of the month is *dataflow* as in dataflow parallelism. (And if you've just seen Manuel's talk, not to be confused with data paralellism). With dataflow, we will be wrapping up our now four-part series on parallel programming in Haskell. In recent words of the month, we've been looking at various approaches for parallelising your way to faster code. We started with the parallel arrays library Repa, then moved on to the Haskell `par` and `pseq` primitives, and built from there to get Strategies. Now we'll be looking at `monad-par`, a library for *dataflow* parallelism. First, the bigger picture: why do we have another way of doing parallel programming in Haskell when we already have parallel arrays and Strategies? Part of the answer is parallelism is still a research topic, with new ideas coming out from time to time and some old ideas slowly withering away. For another part of the answer, it may help to think in terms of a trade-off between implicitness and performance, in other words, between Easy and Fast.  Not all problems are subject to the trade-off in the same way. It's also not always clear how they are. As a rough sketch, problems that require applying the same operation on a large number of simple object can get fast performance from a parallel arrays library. This is a form of data parallelism. If the problem does not lend itself to data parallelism, the next port of call is likely Strategies. If Strategies are not adequate for the desired speedups, the problem may require an even more explicit approach. Until recently, this meant “rolling your own” parallelism by using Concurrent Haskell: forking off threads, assigning tasks to them, and communicating finished work between them. Using concurrency for DIY parallelism is risky. It means venturing into IO, giving up determinism, exposing ourselves to all manner of side-effects, not to mention subtle concurrency bugs like deadlock. As Haskellers, we should demand better: safer, more predictable and easier to reason about. We want to have explicit fine-grained control without all the nasty side-effects. And now we can have it! The latest addition to the parallel Haskell quiver is the monad-par library. Programming in monad-par looks a lot like programming in Concurrent Haskell: data Par a instance Monad Par runPar :: Par a - a fork :: Par () - Par () data IVar a new :: Par (IVar a) put :: NFData a = IVar a - a - Par () get :: IVar a - Par a Instead of using `forkIO`, we use `fork` to create threads (not sparks!) and instead of using `MVar`s to communicate, we use `IVar`s. `MVar` and `IVar` behave in somewhat similar ways, in that any attempt to read from an `IVar` will wait until it has been filled. But this is also where differences emerge. Unlike their concurrent counterparts `IVar` may only be written to once; subsequent writes result in an error.
Re: [Haskell-cafe] Parallel Haskell Digest 6
Attached are the png files I refer to in this post. Check out the blog version to see it all in context http://www.well-typed.com/blog/60 On Thu, Oct 06, 2011 at 16:58:47 +0100, Eric Y. Kow wrote: First, the bigger picture: why do we have another way of doing parallel programming in Haskell when we already have parallel arrays and Strategies? Part of the answer is parallelism is still a research topic, with new ideas coming out from time to time and some old ideas slowly withering away. For another part of the answer, it may help to think in terms of a trade-off between implicitness and performance, in other words, between Easy and Fast.  ... But this doesn't really tell us all that much about how to use this library. For now we come back to our word *dataflow*. The dataflow model treats program as a little black box, an input goes in, an output comes out, and what happens in between is immaterial:  The program is represented as a directed graph (a *dataflow network*), with each node representing an individual operation (black boxes in their own right), and connections between the nodes expressing dependencies. In the graph above, `g` and `h` depend on the output of `f` (the same output - there is only one) and in turn, `i` depends on the output of both `g` and `h`.  -- Eric Kow http://erickow.com attachment: parallelism.pngattachment: dataflow-basic.pngattachment: dataflow-network.png pgpS125HOYpmW.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New: A French translation of Learn You A Haskell for Great Good!
On Wed, Sep 21, 2011 at 00:00:26 +0200, Valentin ROBERT wrote: http://lyah.haskell.fr Excellent http://haskell.fr Since you're starting from fresh, it would be great if the wiki were running Gitit instead of Mediawiki. Advantages: - Markdown is used in many places - You can have a Git/Darcs repository behind this See http://wiki.darcs.net for an example of this in action. Would be great if Haskell wiki were also running Gitit but that's a potentially a tougher nut to crack -- Eric Kow http://erickow.com pgpbyqUY94Xxb.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs checkin history?? forgot ....
On Fri, Sep 16, 2011 at 17:00:08 +1000, Ivan Lazar Miljenovic wrote: If I have a URL for a darcs repository, how can I get a listing of activity ... mainly checkin history e.g. name, date timestamp? darcs get repo cd repo-name darcs changes Alternatively, darcs changes --repo repo -- Eric Kow http://erickow.com pgpJh36SrGR3u.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parallel Haskell Digest 5
Parallel Haskell Digest === Edition 5 2011-08-31 Hello Haskellers! Eric here, reprising my role as Parallel Haskell Digester. Many thanks to Nick for good stewardship of the digest and nice new directions for the future. This month we have Erlang PhDs (and a postdoc), new partners, two Monad Reader articles in progress and some strategies. As usual, this digest is made possible by the [Parallel GHC Project][n0]. News -- [Scalable Erlang PostDoc and 2 PhD Studentships][n1] (8 Aug) What, Erlang?! Yes, you are reading the right digest. If you're generally into parallelism and concurrency in functional programming languages, you may be especially interested to know about this announcement from Phil Trinder. RELEASE project - A High-level Paradigm for Reliable Large-scale Server Software - is funded by the EU Framework 7 programme for 36 months from October 2011. Its aim is to scale the radical concurrency-oriented programming paradigm to build reliable general-purpose software, such as server-based systems, on massively parallel machines (100 000 cores). Word of the Month -- Last month, we had `par` and `pseq` as our twin words of the month. Let's pursue this little train of parallel thought; our next word the month is *strategy*. Strategies have been around since the 1993 paper [Algorithm + Strategy = Parallelism][asp]; that's before even we started using monads in Haskell! They've recently been revamped in Simon Marlow's [Seq no More][seq-nm] paper, and it's this version of strategies that we'll be exploring here. Strategies are built on top of the `par` and `pseq` primitives we saw in the [last digest][phd4]. They provide a nice way to express the often complicated logic we need to make the best use of parallelism in our code. Use of strategies can also help to make parallel code easier to read and maintain because they allow us to more cleanly separate the core logic from our code that which pertains to our use of parallelism. Before delving into strategies, let's take a small notational detour by introducing the `Eval` monad. Suppose we wanted a parallel version of the `map` function, something that would apply a function to each item of a list. Using the `par` and `pseq` from the last digest, we might express this function parMap :: (a - b) - [a] - [b] parMap f [] = [] parMap f (a:as) = b `par` bs `pseq` (b:bs) where b = f a bs = parMap f as If we look carefully at the code we can observe that there is something inherently sequential in the way we have expressed this parallel computation: first spark off `f a` then recurse to the tail of the list, and finally cons. The `Eval` monad builds off the insight that expressing parallelism is fundamentally (perhaps counterintuitively) about ordering things. Monads are well-suited for expressing ordering relationships, and so they have been been pressed to work for expressing parallel computation as well. data Eval a instance Monad Eval runEval :: Eval a - a rpar :: a - Eval a rseq :: a - Eval a `Eval` is just a strict identity monad, with `rpar` and `rseq` as counterparts to `par` and `pseq`. We use `Eval` to compose sequences of parallel computation, which we extract the results of by using the `runEval` function. If you're not familiar with monads, you can get away with just treating `Eval` as new notation, or rather, borrowed notation, the same that we use IO, parser combinator libraries, QuickCheck and a plethora of other useful monads. It's worth noting also that despite appearances, we are still in purely functional territory -- no IO here! -- with the notion of sequencing being limited to controlling parallelism and evaluation depth. To make use of `Eval` for our `parMap` function, we could write a version like the below. It introduces a change of type, from returning `[b]` to `Eval [b]`. In the general case, we could just use the `runEval` function to get our result back, but we are not baking it into `parMap` because we would typically want to use then function within a greater `Eval` context anyway. parMap :: (a - b) - [a] - Eval [b] parMap f [] = return [] parMap f (a:as) = do b - rpar (f a) bs - parMap f as return (b:bs) As before, this function captures the basic idea of its sequential counterpart `map`: apply function, recurse to tail, cons new head to new tail. This is a passable parallel map, but there are still two things which are unfortunate about it. First, we have repeated the implementation of map, not a big deal for such a small function but a potential maintenance problem for more complex code. Second, we have only captured one sort of parallel evaluation firing off sparks for all the cons cells, but in practice getting parallelism right requires some often
Re: [Haskell-cafe] Cabal-1.10.1.0 and bytestring-0.9.2.0 hackage problem.
Thanks! I was scratching my head at this On Thu, Aug 25, 2011 at 16:42:58 +0200, Bertram Felgenhauer wrote: 1. http://hackage.haskell.org/package/bytestring is now broken. 2. The downloadeble package index (00-index.tar) still contains the bytestring-0.9.2.0 cabal file, so the problem persists. As a workaround, one can remove the cabal file from the downloaded index manually, tar -f ~/.cabal/packages/hackage.haskell.org/00-index.tar --delete bytestring/0.9.2.0 gnutar for the apparently 50% of Haskellers (*) that use Macs * or at least those that attend UK hackathons -- Eric Kow http://erickow.com pgpAW3zBRxCoY.pgp Description: PGP signature ___ 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
[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] 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] Parallel Haskell Digest 2
Parallel Haskell Digest === Edition 2 2011-05-11 Hello Haskellers! Welcome to the second edition of the Parallel Haskell Digest, bringing you news, discussions and tasters of parallelism and concurrency in Haskell. The digest is made possible by the Parallel GHC project. More news about how we're doing below. Note that this edition of the digest may be best viewed in blog form at http://www.well-typed.com/blog/52 (there's an inline picture). News -- * Workshop of the 2nd SICSA MultiCore Challenge (27 May, Glasgow; registration deadline 18 May) The goal of the SICSA MultiCore challenge is to bring together researchers in the area of parallel programming, by implementing one or more challenge applications on (networks of) multi-core machines. The goal is to learn about the strengths and weaknesses of current systems for parallel programming by comparing them on a common application. The final workshop will feature presentations of the individual implementations, assessing both raw performance as well as ease of parallelisation and other aspects in the development of this parallel application. https://groups.google.com/d/topic/parallel-haskell/K-IJ2roA59I/discussion * Parallel Haskell Portal One of things I've been working on at Well-Typed is to help clean up the Haskell wiki documentation on parallelism and concurrency. There's still a bit of gardening to do, but we're ready to unveil what we have now. The Parallel Haskell portal is targeted primarily at people getting started with parallelism and concurrency in Haskell. It places a lot of emphasis on steering readers towards mature technologies, while still offering a path for more advanced users to dig deeper into current research. http://www.haskell.org/haskellwiki/Parallel Word of the Month -- This edition of the digest is brought to you by threads, threads and more threads. In the last digest, we took a look at Haskell sparks and particularly at how they differ from threads. Now let's delve a little bit deeper into threads. A thread of execution is a programming abstraction that helps the programmer separate concerns within a program. Consider a web server serving many documents to many clients simultaneously. The programmer may wish to use threads, using one thread per client making it easier to manage concurrent action. [1] In the Haskell world, this programming abstraction is provided by Haskell threads. To implement Haskell threads, the GHC runtime system uses what is known as a M:N threading model, where many Haskell threads are scheduled across a much smaller number of operating system threads. This model has two key benefits: * it can make use of multiple CPU cores * it allows Haskell threads to be very cheap Don Stewart illustrated this on StackOverflow with the following diagram, citing 2011 figures of a handful of CPUs, a dozen or so OS threads and tens of thousands of Haskell threads (plus for those of us interested in pure parallelism, millions of sparks). http://i.imgur.com/u53Uk.png If you want to try generating some figures for yourself, have a look at the benchmark utility at http://darcs.haskell.org/nofib/smp/threads005/Main.hs The benchmark tool creates a large pipeline of simultaneous Haskell threads, and tries to send a message through the pipeline, passing it from one thread to the next. On my laptop, I can create 1 Haskell threads in 0.074 seconds and pump Hello World through them in 0.07 seconds. That works out to 7.4 microseconds per thread (0.7 microseconds for pumping). How about giving it a shot on your computer? Haskell threads are very lightweight. For most concurrency needs, you can generally forget that operating system threads exist. Indeed, when the documentation for modules like Control.Concurrent refers to threads, or when Haskell hackers discuss threads in Haskell code it's a good bet that they're referring to Haskell threads rather than OS threads. That said, there are a few occasions where you may want to be aware about OS threads, in order of importance, if you * want your Haskell threads to be running in parallel on multiple cores (for better performance) instead of just being interleaved on a single core, or * need to make foreign calls concurrently with doing other things (eg. running Haskell code or making other foreign calls) Doing any of these things requires that you use GHC's multi-threaded runtime system. GHC currently uses a single-threaded runtime system by default, but until this changes, you will have to explicitly enable the multi-threaded one by linking your program with the flag `-threaded`. With the multi-threaded runtime system all Haskell threads are scheduled across multiple OS threads as opposed to being interleaved on a single one. This allows for
[Haskell-cafe] Haskell User Group starter kit
Hi all, We may be coming to a time where we start to see Haskell User Groups or Functional Programming clubs popping up all the over the place. Maybe it's a good time to put our heads together and figure out what we can do to nurture these groups, to keep them going strong rather than fizzling out. One idea might be create some sort of Haskell User Group starter kit so that individual groups can hit the ground running with some concrete ideas. http://www.haskell.org/haskellwiki/Haskell_User_Group My hope is that it would provide just enough material for a group to reach critical mass. So just enough stuff to account for the different kinds of activities a HUG may want to do (eg. Coding Dojos vs Talks vs Reading Group), but not so much that HUGs feel intimidated or stifled. Have you started a HUG recently? Or are you thinking of starting one? Maybe you could contribute just one idea to the kit? More welcome, of course :-) -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only) pgpuG7vIxZHIv.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parallel-haskell mailing list
Hi everybody, I thought I should point out that there is a mailing list dedicated to parallelism and concurrency in Haskell. The group exists to bring together the various groups in the Haskell community that are working on parallelism. It is intended to provide some visibility into the various efforts and to encourage collaboration. So if you want to know what's going on in the parallel Haskell world, this is the place to hang out. You can join the list by sending an email to parallel-haskell+subscr...@googlegroups.com You can also visit the group on the web at http://groups.google.com/group/parallel-haskell Or for those of you who prefer GMane http://dir.gmane.org/gmane.comp.lang.haskell.parallel Enjoy! Eric -- Got news for the Parallel Haskell Digest? Send a mail to e...@well-typed.com! pgp2azpIL6ffL.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parallel Haskell Digest 1
Parallel Haskell Digest === Edition 1 2011-03-31 http://www.well-typed.com/blog/52 Hello Haskellers! If you're in the mood for a HWN chaser, I'd like to introduce the first Parallel Haskell Digest, a newsletter aiming to show off all the work that's going on using parallelism and concurrency in the Haskell community. The digest is a bit of an experiment. For the community in general, I hope to help you catch up with a monthly recap of news, interesting blog posts and discussions about parallelism in Haskell. For people (like me) who are new to parallelism and concurrency in Haskell, or maybe just have a passing interest, I hope to give you little nibbles, with regular features like the Word of Month, Featured Code and Parallel Puzzlers. Finally, as a bit of disclosure, I'm writing this digest as part of my work to promote the Parallel GHC Project. So don't be surprised if I give it a little special emphasis :-) Word of the Month - This very first edition of the PH digest is brought to you by the word /spark/. You may have heard of sparks and threads in the same sentence. What's the difference? A Haskell thread is a thread of execution for IO code. Multiple Haskell threads can execute IO code concurrently and they can communicate using shared mutable variables and channels. Sparks are specific to parallel Haskell. Abstractly, a spark is a pure computation which may be evaluated in parallel. Sparks are introduced with the par combinator; the expression (x `par` y) sparks off x, telling the runtime that it may evaluate the value of x in parallel to other work. Whether or not a spark is evaluated in parallel with other computations, or other Haskell IO threads, depends on what your hardware supports and on how your program is written. Sparks are put in a work queue and when a CPU core is idle, it can execute a spark by taking one from the work queue and evaluating it. On a multi-core machine, both threads and sparks can be used to achieve parallelism. Threads give you concurrent, non-deterministic parallelism, while sparks give you pure deterministic parallelism. Haskell threads are ideal for applications like network servers where you need to do lots of I/O and using concurrency fits the nature of the problem. Sparks are ideal for speeding up pure calculations where adding non-deterministic concurrency would just make things more complicated. Parallel GHC project news -- The Parallel GHC Project is an MSR-funded project to push the real-world use of parallel Haskell. Part of this project involves effort by Well-Typed to provide tools for use by the general community: Work shall soon begin working on making the Modified Additive Lagged Fibonacci and perhaps other random number generators from the SPRNG library available in Haskell. Current plans are to implement the algorithms directly in Haskell, and to expose them as instances of System.Random.RandomGen. These generators are attractive for use in Monte Carlo simulations because they are splittable and have good statistical quality, while providing high performance. Work is underway on extending the GHC EventLog and associated tools (ghc-events, ThreadScope). The aim is to support profiling of multi-process or distributed Haskell systems such as client/server or MPI programs. This involves incorporate some changes made in related projects (Eden, EdenTV). This work may have some benefits even for profiling single-process programs. It should also allow comparative profiling where multiple runs of the same program (e.g. different inputs or slightly different code) are viewed on the same timeline. For more information on the Parallel GHC project, see http://www.haskell.org/haskellwiki/Parallel_GHC_Project Featured Code -- The feature code for this month is hulk, an IRC server in 1250 lines of code. Hulk was coded up by Chris Done in one evening, and it was used the next morning. (Chris has done a bit of cleaning up since). Here's what Chris had to say about his experience writing Hulk: Haskell's lightweight threads make it natural (and guilt-free!) to choose the design of one-thread-per-client. With a single MVar containing a pure value for the whole server-state, and the help of a monad stack of ReaderT(connection information), WriterT (replies) and StateT (user details), it was trivial to make the bulk of the code completely pure. LineBuffering on the (Handle-wrapped) sockets tripped me up; as opposed to NoBuffering, this did not behave as expected: *many* threads would block when only *one* should have. Overall, it was textbook Haskell; keep the main code pure, and only the truly impure in the outer shell. It's up on hackage so you can install it with a quick cabal install hulk You can also fork his code on GitHub
[Haskell-cafe] Re: [wxhaskell-users] problems using macports?
Hi Doaitse, On Thu, Sep 09, 2010 at 17:38:40 +0200, S. Doaitse Swierstra wrote: I am in my yearly fightto get a working combination of operating system (Snow Leopard), compiler version (6.12) , wxWidgets and wxHaskell on my Mac . After deleting most of my stuff, starting afresh, hours of building using macports etc. I finally get the message: I may have had a similar problem back in March: http://www.mail-archive.com/wxhaskell-us...@lists.sourceforge.net/msg00827.html Don't know if my explanation is sensible or not. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only) pgpW8LxWnWPFb.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] darcs hacking sprint 4 report
Hi everybody, Here's our report from ZuriHac. It's been also posted to the Darcs blog with a couple of photos stolen from Johan's blog, some Darcs rebase scribbling and a screenshot of Darcsden's intriguing fork-tracking feature... http://blog.darcs.net/2010/03/darcs-hacking-sprint-4-report.html The Fourth Darcs Hacking Sprint took place last weekend (19 to 21 March) as part of the Zurich Haskell Hackathon. We had a very productive sprint, a bit of code written, polished off many key discussions, had a little beer and a lot of fun. Overview == In this sprint, we worked on finishing some performance work for the upcoming Darcs 2.5 release this summer (hashed storage, patch index, global caches, inventory hashing); planning our work for the Darcs 2.6 release next year (smart servers, cache cleanup, darcs rebase) and working with new users of the Darcs library. Issues resolved --- * issue643 darcs send -o output - Guillaume Hoffmann * issue1473 annotate command line - Stefan Wehr * issue1456 portable darcs dist - Guillaume Hoffmann New Darcs Hackers == We're always happy to work with new Darcs developers. At this sprint, we were joined by four new contributors. Guillaume Hoffmann -- Guillaume has been writing our Darcs Weekly News articles for a year now. Over the weekend he got his first taste of Darcs hacking, knocking out three ProbablyEasy bugs (darcs dist internals, darcs send -o UI, darcs apply with gzipped patch bundles). Guillaume reports that he can see himself doing more of this in the future! Steven Keuchel -- Steven worked on a new feature to display the file contents hashed associated with any patch. This makes it easier for third party tools to inspect the patch files behind Darcs. Stefan Wehr and David Leuschner Stefan and David mostly worked on the Darcs Patch Manager, but to warm up, they tackled a couple of ProbablyEasy bugs, particularly a bug in darcs annotate that was affecting Redmine Hacking continued... == Bugfix: Darcs on Windows shares --- Salvatore tracked down the Windows regression on 2.4 that make Darcs not work on windows shares. Performance: Fast darcs annotate Benedikt Schmidt continued his work on the patch index (formerly known as the filecache). The patch index keeps track of which patches affect which files. This index will bring a big boost to darcs annotate performance, particularly for files which are affected by relative small number of patches. Performance: Global cache - Luca continued his work on breaking up the global cache ($HOME/.darcs/cache) into buckets for faster access. Working with Reinier and Petr, Luca has developed an approach to migrating from old style caches to the new style bucketed ones. He has also improved the implementation to use hard links, to avoid disk space doubling and to preserve backwards compatibility with prior versions of Darcs. Windows installer - Salvatore put together a nice Windows installer using the `bamse package http://hackage.haskell.org/package/bamse`_. It looks like we will be able to use this for the planned Darcs 2.5 release this summer. This work will also open the door to nicer integration with Windows tools, for example, using a bundled Tortoise SSH for better experience working with SSH passphrases. Interactive cherry picking -- Florent improved the quality of the Darcs cherry picking code, making it easier to fine tune our user interface and some day support graphical interfaces via the Darcs library. Witnessed list zippers for the win? Interactive diff Florent also started work on adding Darcs's interactive cherry picking to darcs diff, making it possible to choose a set of patches to view as a diff. Performance: Hashed storage completion -- Darcs has a representation of file and directory trees called slurpies. Petr polished off his work to replace the slurpies with his more efficient, general purpose hashed-storage library. Slurpies are going away, and Darcs will be faster for it. He and Ganesh also discussed how to gracefully transition from repositories created before the hashed-storage refactor. Performance: Using tags when writing patches Petr ported work by David Roundy to solve a `scalability regression http://bugs.darcs.net/issue1106`_ in hashed repositories. For darcs commands that write out patches, we had a naive hashing operation that does not account for the fact that patches behind tags cannot be modified. Darcs was unnecessarily traversing the entire sequence of patches
[Haskell-cafe] Re: Anyone up for Google SoC 2010?
On 31 Jan 2010, Malcolm Wallace pointed out: Google has announced that the Summer of Code programme will be running again this year. If haskell.org people would like to take part again this year, then we need volunteers: The Darcs Team would certainly be delighted to participate in GSoC 2010, perhaps under the haskell.org umbrella. Leslie Hawthorne from Google has suggested the possibility of them being able to wrangle an extra slot or two for [Haskell.org] if they are acting as an umbrella org for darcs. http://lists.osuosl.org/pipermail/darcs-users/2009-October/021761.html I think we should make it very very clear that we would like this! First, * suggestions for suitable projects (in the past this was organised using a reddit) * an administrator to co-ordinate the application to Google (I have done it for the last three years but am very willing to hand on to someone else) I'll mention the Darcs ideas page here: http://wiki.darcs.net/GoogleSummerOfCode We're particularly interested in three things: (i) making Darcs faster (ii) building nice GUI tools and (iii) working seamlessly with SVN/Git repositories As for (i), we are also particularly interested in benchmarking. Criterion and now Progression seem like really great tools; hopefully, we can put them to good use. Meanwhile, perhaps there is extra room for tools that help large programs in their benchmarking? Two particularities may be [A] not always knowing how to get good benchmarks out of large coarse grained tasks (run darcs check on this repository) and [B] big benchmarks (run darcs check... on the GHC repo) Google will accept applications from organisations in the period 8th - 12th March 2010, approx 1900UTC. If haskell.org is accepted again, students can apply between 29th March - 9th April. More volunteers will be required: * to review student applications and choose which to accept * to supervise the accepted students Both of these roles are called mentor in the Google system. Putting together a good team of mentors before applying as an organisation is helpful towards us being accepted into the programme. I'll volunteer as a mentor if it helps. Darcs users: if you have a few spare hours this summer, this would be a most excellent way to participate. Stick your hand up :-) -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpOxq0G55E2M.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Darcs fundraising 2010 - send us to ZuriHac! (only $957 more by 15 Feb)
Hi everybody, Here's the update for our second week of fundraising. We've managed to raise $1043. We're now halfway there! That's only $957 to go by the 15th of February. Many thanks to everybody who has made a donation so far. If you're still thinking of helping out, now is a good time! :-) Otherwise, stay tuned at http://darcs.net/donations.html for our progress. Eric PS. If you could send me an email when you make a donation, I can provide a daily update on our fundraising status. Donating by Google Checkout -- Donating via Google Checkout puts more of your donation to work, since Google charges no Checkout fees to 501(c)(3) organizations. Please visit http://darcs.net/donations.html for more details. Donating by check (USA) -- The next best option is to donate by check if you have a US bank account. Checks should be made payable to Software Freedom Conservancy, Inc., with Directed donation: Darcs in the memo. They can be mailed to Software Freedom Conservancy 1995 BROADWAY FL 17 NEW YORK NY 10023-5882 USA Donating by Paypal -- Please visit http://darcs.net/donations.html for more details. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgp4IDbDbenUN.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Darcs fundraising 2010 - send us to ZuriHac! (only $1333 more by 15 Feb)
Hi everybody, I'm just writing to thank everybody for your donations so far to the Darcs 2010 travel fund, and to give a little progress update. Thanks to your generous contributions, we've managed to raise $667, putting us 1/3 of the way there! We only have $1333 to go, that's a little over three hundred to meet last year's target and a thousand more to make our 2010 objectives. If you're still thinking of helping out, now is a good time! :-) Otherwise, stay tuned at http://darcs.net/donations.html for our progress. Eric PS. If you could send me an email when you make a donation, I can provide a daily update on our fundraising status. Donating by Google Checkout -- Donating via Google Checkout puts more of your donation to work, since Google charges no Checkout fees to 501(c)(3) organizations. Please visit http://darcs.net/donations.html for more details. Donating by check (USA) -- The next best option is to donate by check if you have a US bank account. Checks should be made payable to Software Freedom Conservancy, Inc., with Directed donation: Darcs in the memo. They can be mailed to Software Freedom Conservancy 1995 BROADWAY FL 17 NEW YORK NY 10023-5882 USA Donating by Paypal -- Please visit http://darcs.net/donations.html for more details. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpqQUmTfhsdW.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Darcs fundraising 2010 - send us to ZuriHac! ($2000 by 15 Feb)
Dear Haskellers, Since 2008, the Darcs Team has made a big push to find hacking time. We've been streamlining our patch approval processes, running Google Summer of Code projects and holding bi-annual hacking sprints. These efforts are starting to pay off, but we're not quite there yet and we still need your help! If you love Darcs and you want to see it succeed, if you want to see it get faster and easier to use, the best thing you can do is to send us your patches (how about attending a sprint?). But if you cannot do this, you can still support the cause. The 4th Darcs Hacking Sprint will be taking place in March as part of the Zurich Haskell Hackathon. Zurich presents a opportunity for us pull a lot of the Darcs team together, to recruit new developers to the project, and also to mingle with the wider Haskell community. We would love to subsidise travel costs to make it easier for developers to attend this sprint and the one after. Do you think you can help? How about sending just $20 our way? Donating to Darcs is now easier than ever, as we are now proud members of the Software Freedom Conservancy. You can either send us a cheque or use Paypal or Google Checkout. Furthermore, donations from US tax-payers will now be tax-deductible. More details below, or at http://darcs.net/donations.html Many thanks! Eric PS. If you could send me an email when you make a donation, I can provide a daily update on our fundraising status! Last year, we managed to raise a thousand dollars to send Darcs hackers to the Utrecht and Vienna hackathons. This year, I want to see if we can raise $2000 for Darcs hacking by the 14th of February. Stay tuned at http://darcs.net/donations.html for our progress. Only $1710 to go... :-) Donating by check (USA) -- If you have a US bank account, we prefer donations by check as they will go the longest way. Checks should be made payable to Software Freedom Conservancy, Inc., with Directed donation: Darcs in the memo. They can be mailed to Software Freedom Conservancy 1995 BROADWAY FL 17 NEW YORK NY 10023-5882 USA Donating by Paypal or Google Checkout -- Please visit http://darcs.net/donations.html for more details. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpMPvKkmtVap.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 74, Issue 53
Hi Iain, I'm taking the liberty of cc'ing wxhaskell-users. Iain said: I was trying to go through some of the wxHaskell examples, and they wouldn't work on my (Tiger) mac. Same thing happened with a few other wx apps I downloaded from Hackage. A bit of a rummage on the internet turned up an issue with wxMac[1]. You need to put the haskell executable in an OSX Application Bundle or you can't get focus on the window. Since I don't know how to use XCode (and quickly got bored of trying to find what I needed to do with it for my needs) I setup an applescript that builds a bare bones app bundle, with a basic plist file too. Thanks for your efforts! This is probably something others have gone though and, just in case it might be some use to others, I stuck it here (might be a little bit of overkill using Sourceforge, but I wasn't go to pay for the download space on my blog considering I have zero cash right now). http://sourceforge.net/projects/makebundle/ The applescript has a perl script in it too, so you'll need perl on your machine for it to work. Everything you need to know is in the readme. I've also done something similar http://koweycode.blogspot.com/2009/09/cabal-installing-graphical-apps-on.html only in Haskell and attempting to integrate into a Cabal Setup script. You may want to know about work by Andy Gimblett to package this up nicely: http://www.mail-archive.com/wxhaskell-us...@lists.sourceforge.net/msg00725.html I hope his work will one day may the macosx-app shell script obsolete. Cheers, -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpWaQ0iNxkwM.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Edinburgh Saturday Meetup - we are here! (Henderson's)
Dear Haskellers, Just for info, we are currently at Henderson's Cafe on Hanover St (just around the corner from the RCPE). If anybody needs to get in touch: Eric - +44 75187 28483 Dougal - +44 7814 412539 More details on the wiki if we move: http://www.haskell.org/haskellwiki/Hac7 -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgp9L0swITMVt.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] tomorrow: Edinburgh Meetup (Sat 29 Aug) and Hack Day (Sun 30 Aug)
Dear Haskellers, Last minute reminder: We will be having a Hack Day in Edinburgh on Sunday 30 August (ICFP venue). That's this weekend! For the interested, we will also be meeting up the day before 09:30 Saturday 29 August just outside the RCPE (ie. the ICFP venue again). We'll have a quick wander and hopefully find some nice places to sit, chat and hack. On Sunday the real Hack Day begins at the ICFP venue, rooms 4/5. http://www.haskell.org/haskellwiki/Hac7 And for the interested, Brent says: I'll be there Saturday morning---looking forward to meeting people! Also, I have purchased a ticket to hear a concert of some 16th-century a capella 16th-century music at the Canongate Kirk at 5pm on Saturday: http://www.edfringe.com/ticketing/detail.php?id=13649 Just thought I'd mention it, so if there's anyone else coming to the meetup day and 16th-century a capella sounds like your cup of tea, you can get a ticket too and we can go together. Looking forward to seeing you, Eric PS. Bring a name tag if you've got one. There are about 15 people registered so far. It's not too late to register! (yes, you could also just drop by...) -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpCNrkyR9Njj.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a newbies confusion with repositories - darcs or git
Hi Günther, But since I have the ambition to become a real haskeller I was gonna make myself acquainted with darcs. Should I skip that and head straight for git? My extremely biased opinion is that you skip git and go straight for darcs ;-) Why I love darcs Git is a fine revision control system; I like it and I intend to learn more about it. On the other hand, darcs does some unique, which makes it similar to Haskell (vs. other programming languages) in way, that one often has a hard time explaining to folks what it is that makes it so special (the good news is that the Haskell community is getting better and better at this! and hope that the same will happen for darcs). So let's give this a shot. Why darcs? In my opinion, the number one killer feature of darcs is that it knows how to merge changes without doing *any* guessing. It doesn't say well, I have this patch that's supposed to tweak line number 4, but oops, I think I see that the line must have moved down to line number 7 because it looks sort of similar. Instead darcs knows with 100% certainty where the right place to apply your patch is. This is because it uses the full history of patches where everything goes. There is a lot of talk about a theory of patches, and this is largely what it's about in the darcs world, finding a precise way to talk about patches. See why some Haskellers love it? It's not just that it's written in Haskell; it's that the whole thing is driven by something which is very clean, powerful and which delivers a concrete impact in the real world. We love this kind of precision not just because we're theory-fans, but because it delivers the goods. Being able to apply and unapply patches precisely means that we can merge changes all we want -- we know that darcs will always preserve user intent -- plus we can adopt all sorts of new behaviours like cherry-picking incoming patches (I'll take patch A, C and E; but not B and D please; oh, you tell me I can't have E without D? Very well, then) or cherry-picking changes that you want to undo (Oops, I actually didn't mean to write that thing in line 58 and 98, but I still want to keep that thing in line 68, so I'll darcs revert them... or Oops, actually I've shouldn't have pulled in change C, but I still want to keep changes D E, so I'll just say 'darcs obliterate -p C' to get rid of it). These kinds of operations happen seamlessly in darcs. There is no fuss, there is no worry; everything you can do in darcs, you can un-do. Anything you un-do in darcs, you can re-do. Darcs past, present and future == So darcs has a clean theory which makes it possible to use a revision control system in a new seamless way. Why isn't everybody using it? Conflicts: It used to be the case that darcs had theoretical problems dealing with large conflicts (representing a conflict would take exponential space depending on the patches involved). It took the darcs community many years to address, but we eventually did, by releasing darcs 2. Darcs 2 repositories add enough information to the representation of conflicts which allows us to avoid the exponential blow-up most of the time. For the most part, the problem is solved. There are still cases where this blow-up can happen (we call them conflict fights), but they are well understood and can be avoided. In the meantime, we have some folks in the community who are doing some long-term work refining the darcs theory yet again. Performance: In addition to the conflicts problem, darcs has suffered from a lack of optimisation. (In fact, many users may have complained about patch theory problems, when they may really have been suffering more from performance issues or a mixture of the two). We have had and still have some practical day-to-day performance issues. For example, some of my larger repositories suffer when I use them on an NFS share. Rather than things being instantaneous, they would take a few seconds and I would get annoyed. Or perhaps, darcs would make too many connections over a network to fetch a lot of little files instead of sending them over in one pack. Now that darcs 2 is out, we have been focusing the bulk of our energy on tackling these basic performance problems. For other Haskellers in the room, I should point out that hacking darcs performance would be a great way for you to hone your skills and to give back to the community. No patch theory needed! Anyway, I wouldn't be too worried about performance issues. Darcs performs just fine for small to medium sized repositories. The darcs darcs repository has over 7000 patches over 6 years with over 160 contributors, no sweat. Windows: darcs support for Windows used to be a bit uneven. There were a few details here and there that none of us had time to get to (especially since none of us were using Windows). Things have gotten quite a lot better since, and we now have a dedicated Windows Czar who is
[Haskell-cafe] darcs hacking sprint #1 (report)
Dear Haskellers, I thought some of you might be interested in our report from the darcs hacking sprint, held on 25-26 October. See also the blog version of it at http://blog.darcs.net/2008/10/darcs-hacking-sprint-1-report.html (it has photos). So how did that darcs hacking sprint go? Well, we had a lot of fun and we got a lot of work done, so I think we can safely say that it was a great success! What next? The sprint participants found themselves with a lot of good work started that we simply couldn't put down, so we have continued hacking into the week, turning many of our good starts into more concrete progress. There is still a lot of work to do so we want to make sure we keep that momentum going! The big challenge right now is to get all of the patches reviewed and merged back into darcs.net. Unfortunately, this is creating a delay in the usual patch review process as we clear our backlog. In the meantime, please continue sending your patches! Thanks very much to David Roundy for his advice before the sprint and cheerful handling of this patch influx; Galois, the University of Brighton and Université de Paris 7 for graciously hosting our three venues; and especially to everybody who participated or joined #darcs to cheer us on :-) The next sprint will be held in conjunction with the Haskell Hackathon, March 2009 in Utrecht, Netherlands. So see you in six months! Overview Total sprint patches: 234 Patches produced - during the sprint itself : 178 - as follow-up work: 56 Patches sent and - accepted into darcs.net : 43 - awaiting review : 191 (during defined as 25-27 October 2008 at 08:00 UTC) Site reports * Team Portland: - report: http://lists.osuosl.org/pipermail/darcs-users/2008-October/015082.html - pictures: http://blog.codersbase.com/2008/10/28/darcs-hacking-sprint-summary-from-portland-team/ * Team Brighton: - report: http://lists.osuosl.org/pipermail/darcs-users/2008-October/015122.html - pictures: http://koweycode.blogspot.com/2008/10/darcs-hacking-sprints-some-pictures.html - pictures: http://koweycode.blogspot.com/2008/10/darcs-hacking-sprint-team-brighton-day.html * Team Paris: - report: http://lists.osuosl.org/pipermail/darcs-users/2008-October/015215.html What we worked on - Warm up tasks = * Warn the user when the patch name looks like a command line option - http://bugs.darcs.net/issue395 - Participants: Reinier Lamers (Team Paris) - Status: Accepted! * Warn when tags are too short (length name 2) - http://bugs.darcs.net/issue1000 - Participants: Christian Kellerman - Status: Accepted! Optimisations = * Solved stack overflow when doing whatsnew on very large lines - http://bugs.darcs.net/issue1017 - Participants: Ganesh Sittampalam (Team Brighton) - Status: awaiting review * Smarter slurpies for faster directory lookups - http://bugs.darcs.net/issue711 - Participants: Ganesh Sittampalam (Team Brighton) - Status: awaiting review * Avoiding lstats in darcs whatsnew - http://bugs.darcs.net/issue390 - Participants: Reinier Lamers (Team Paris) - Status: needs tweaking * Bytestring optimisations - Participants: Don Stewart (Team Portland) - Status: awaiting review Performance-related features * Filecache to improve darcs annotate and darcs changes performance - Participants: Benedikt Schmidt - Status: still hacking! * Packs - http://wiki.darcs.net/index.html/Packs_Specification - Participants: Nicolas Pouillard, Florent Becker (Team Paris) - Status: plan is fleshed out; implementation started in branch * Chunky hunk representation - Participants: Ian Lynagh (Team Brighton) - Status: needs volunteer to start porting from camp to darcs * Global cache: enabled by default and more portable - http://bugs.darcs.net/issue839 - Participants: Simon Michael - Status: Accepted! * Networking performance (Team Paris) - Used tcpdump to examine network performance problems - New issues filed: * http://bugs.darcs.net/issue1167 - darcs-transfer mode versions * http://bugs.darcs.net/issue1168 - ssh pipelining * http://bugs.darcs.net/issue1170 - Nagle's algorithm - Participants: Team Paris - Status: needs implementation! Improved Windows support * Bugs fixed: - newline endings on Windows for HTTP module. - http://bugs.darcs.net/issue774 - fix character echo on win32. - http://bugs.darcs.net/issue1023 - bracket file writing to prevent windows permission errors. - http://bugs.darcs.net/issue784 - fix file handle leak and check for exceptions on process running. * Participants: Salvatore Insalaco * Status: Accepted! Infrastructure and cleanups === * Code cleanups - Added language pragmas in all files - Removed OldFastPackedString - Replaced FastPackedStrings api in
[Haskell-cafe] Re: [Haskell] Heads Up: code.haskell.org is upgrading to darcs 2
We are upgrading /usr/bin/darcs to version 2 on the machine that hosts code.haskell.org. That means it will be used by everyone who uses ssh to push or pull from a darcs repository on code.haskell.org. Pulling via http is completely unaffected. Thanks Duncan! Now my hope is that we can encourage the good folk at Galois to make a similar upgrade for darcs.haskell.org -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpqsdDI8O6LU.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] darcs hacking sprint, venues confirmed! (25-26 October)
Dear darcs users and Haskell hackers, Earlier I wrote an announcement for the darcs hacking sprint on 25-26 October. Tonight, I am delighted to announce that we have two venues confirmed for the sprint and one serious offer. Venues -- We plan to host the sprint across three sites: * CONFIRMED: Brighton, UK (University of Brighton) * CONFIRMED: Portland, USA(Galois Connections) * likely:Paris,France (Université Paris Diderot) So if you were waiting to book tickets, this is the time! For more details, please see http://wiki.darcs.net/index.html/Sprints Agenda -- During this first sprint, we shall be focusing our attention on the day to day performance issues that darcs users commonly face. This is what we are reaching for: 1. Fast network operations. We want to make it very pleasant for users to darcs get a repository and pull some patches to it over http and ssh. Git does this very well, and we plan to learn from them. 2. Cutting memory consumption. We want to profile the heck out of operations like darcs record, darcs convert and darcs whatsnew. What's eating up all the memory? And how can we can cut it down to size? 3. Responsiveness. Sometimes basic darcs commands can take long enough for programmers to lose their train of thought. We want to track down these lost seconds and kill that dreaded context switch. Of course, if you are interested in other areas, then you can work on those instead. Note that if you are new to the darcs code or to Haskell, there will also be a lot interesting jobs for you to get started with. Everyone will have something to hack on, so come join us! Thanks very much to the University of Brighton, Galois connections and University of Paris VII for their generous offers. Hope to see you there, everyone! :-) -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpA6LUf9gHEz.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] darcs hacking sprint (25-26 October)
Dear Haskellers, As Jason mentions, there has been recently been a lot of interest in darcs and an influx of new contributors. Thanks, everybody! Things are moving faster now with a few extra brains on board. We have some very ambitious plans, though and we still need all the help we can get. Do you think you might be interested in participating, but don't really know where to start? We may have just the solution for you: Darcs hacking sprint You are cordially invited to hack on darcs with us for a weekend, specifically, that of 25-26 October. We will primarily be working on performance hacking of all sorts http://wiki.darcs.net/DarcsWiki/Roadmap If there are sufficient new hackers, I plan to prepare an overview and a set of starter tasks to help you get to grips with the darcs code. Venues -- The venues are not yet fixed, although we have some tentative offers for space in London (thanks to Ganesh) and Portland (thanks to Galois). We will also be available via IRC, with some possibility for video-conferencing of some sort. For more information, please see http://wiki.darcs.net/index.html/Sprints If you have any suggestions for possible venues in London, please let me know. Our current London host can accommodate a handful of people, but we would love to have more people joining in on the fun! Also, if there are people who cannot make it to either London and Portland, perhaps you could gather into satellite teams? I hear Boulder, Colorado is a possibility. RSVP If you would like to participate in any way, please let me know * when you are available (25/26 October) * roughly where you are based * if you are willing to travel Again, if you have suggestions for a good London venue, please send them my way. Many thanks! -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpyIQqJiPlj9.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: darcs hacking sprint (25-26 October)
On Sun, Aug 17, 2008 at 21:33:17 +0100, Eric Y. Kow wrote: The venues are not yet fixed, although we have some tentative offers for space in London (thanks to Ganesh) and Portland (thanks to Galois). Correction! We have a tentative offer for space near *Cambridge* (thanks to Ganesh) and to Ian for picking up on the blunder. Thanks! -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgp5pu5RzF7Bu.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] helping you contribute to darcs (poll results so far)
Dear Haskellers, Last Friday, I had posted a message asking how the darcs community could a better job recruiting developers to hack on darcs. Thanks for all the great responses! I am gratified by the suggestions you have offered, as well as the recent uptick in community involvement. The responses so far fall along three themes: offering new features, improving code accessibility and shaking up the community: Features - GUI (david48, Bit Conner) - splitting/merging (Luke Palmer, Ben Franksen) - binary file handling (Jason Dusek) - ... already does what I want (Allan Clark, Andrew Coppin) Code accessibility - split into libs (Neil Mitchell) - unit tests! (Ashley Moran) - code documentation (Lele Gaifax) - patch theory docs (Apfelmus, Ferenc Wagner) - inherent simplicity of model, cf git (Austin Seipp) Community - release announcements (Brandon Allbery, Neil Mitchell, Don Stewart) - showing ways to help (Wren Ng Thorton, Ferenc Wagner) - announcing our need for help (Wren Ng Thorton) - easier entry point to darcs code, à la xmonad (Petr Rockai) - more active leadership (Don Stewart, Lele Gaifax) One thing which is clear is that the darcs team have failed to communicate effectively: the code is not as well-documented as it should be, patch theory is still not defined clearly or rigorously enough for Haskellers, the recent release announcements gave people the impression that darcs was being abandoned, and we haven't made it clear that we needed your help. We need your help - Hopefully one thing is clearer after this discussion. We definitely need your help! What we need most of all are some Haskell optimisation gurus to join the project, even in a minor way. Darcs 2 offers some huge improvements in safety and core efficiency. Unfortunately, these improvements are overshadowed by poor performance. Paradoxically speaking, darcs 2 just isn't fast enough for people to notice how much faster it has gotten! We need somebody to comb through our code and spot the silly things which are making performance suffer. Is there something too strict? Too lazy? Are going about IO completely the wrong way? There is no patch theory needed for this! Anybody with an eye for performance should be able to rip into this code and find something to fix. If you are not an optimisation guru, there are still loads of ways to help. For starters, you could help us to improve our support for Windows, or maybe some of the ProbablyEasy bugs: http://bugs.darcs.net/[EMAIL PROTECTED],id,activity,status,assignedto@filter=topic,statustopic=6status=-1,1,2,3,4,5,6,7 We will communicate better -- The darcs 2 release announcement was very frank, but it also painted an inaccurate picture of the situation. Here is a clearer picture: we are all still very interested in darcs and want to keep using it! If you have a large repository and you cannot wait for us to fix performance bugs, we wish you the best with git (etc). But if darcs can handle your repository, we hope you stick around. It is true that David is taking a lower profile, but this just means that he is not following every discussion on the mailing list or every new bug and feature request. David is still receiving patches and reviewing them on a daily basis, providing the usual technical insight. So keep sending those patches! That's all for now -- I am going to leave things here for now, despite all the interesting points we could still address and see where else the discussion leads. In my next reply, I hope to address some of the more of suggestions you have offered. Thanks again! -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpx2wdQW6wTl.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Avoiding boilerplate retrieving GetOpt cmd line args
Hi,
Here is a possible two part response. Not literate code, just using
to distinguish code from everything else.
A short answer
==
getFilter = getString f Markdown.pl
where f (Filter s) = Just s
f _ = Nothing
getDateFormat = getString f %B %e, %Y
where f (DateFormat s) = Just s
f _ = Nothing
For starters, you could squish these down into something like
flagToString :: Flag - Maybe String
flagToString (Filter s) = Just s
flagToString (DateFormat s) = Just s
...
flagToString _ = Nothing
Then you would have
getFilter = getString flagToString Markdown.pl
getDateFormat = getString flagToString %B %e, %Y
A long answer
=
I have noticed a lot of ways of dealing with GetOpt flags in Hakell
programs and thought it might be useful to catalogue them. A lot of
this could be wrong btw, for example, advantages/disadvantages. But I
think the general idea might be useful, so please add to this if you
see other solutions.
Solution #1 Ginormous record
Do you happen to have some giant recordful of command line parameters?
Something like
data Settings = Settings { filter :: Maybe String
, dateFormat :: Maybe String
, blahBlah :: Maybe Blah
...
, thisIsGetting :: RatherLargeIsntIt
}
emptySettings :: Settings
emptySettings = Settings { filter = Nothing
, dateFormat = Nothing
}
toSettings :: [Flag] - Settings
toSettings fs = toSettingsH fs emptySettings
toSettingsH :: [Flag] - Settings - Settings
toSettingsH (Filter s:fs) i = toSettingsH fs (i { filter = s })
toSettingsH (DateFormat s:fs) i = toSettingsH fs (i { dateFormat = i })
Note: You can make this a little less painful by factoring out the
recursion (took me a while to realise this!).
toSettings fs = foldr ($) emptySettings (map processFlag fs)
processFlag :: Flag - Settings - Settings
processFlag (Filter s) i = i { filter = Just s }
processFlag (DateFormat s) i = i { dateFormat = s }
...
Advantages:
- simple, easy to look up settings
Disadvantages:
boring; have to write
(i) Flag type
(ii) Settings record type
(iii) default Settings
(iv) processFlag entry
(v) GetOpt entry
record gets really really huge if you have a lot of flags
Solution #2 List of flags (darcs)
-
Don't bother keeping any records around, just pass around a big list of
flags to functions that depend on settings.
if the flag has any parameters, you can't just write (DateFormat
`elem` fs); you'll have to write some boilerplate along the lines
of
hasDateFormat :: [Flag] - Bool
hasDateFormat (DateFormat s:fs) = True
hasDateFormat (_:fs) = hasDateFormat fs
hasDateFormat [] = False
getDateFormat :: [Flag] - Maybe String
getDateFormat (DateFormat s:fs) = Just s
getDateFormat (_:fs) = getDateFormat fs
getDateFormat [] = Nothing
which again can be factored out...
fromDateFormat :: Flag - Maybe String
fromDateFormat (DateFormat x) = Just x
fromDateFormat _ = Nothing
hasDateFormat fs = any (isJust.fromDateFormat) fs
getDateFormat fs = listToMaybe $ mapMaybe fromDateFormat fs
Still, this is more pay-as-you-go in the sense that not all flags need
to be accessed, so maybe you end up writing less boilerplate overall
Advantages:
simple
very convenient to add flags (as a minimum, you have to write
(i) flag type
(ii) GetOpt entry
(iii) lookup code (but pay-as-you-go)
Disadvantages:
still a bit boilerplatey
Solution #3 No lists, just records (lhs2TeX)
--
This one is due to Andres Löh, I think although my rendition of it may
not be as nice as his.
Ever considered that your Settings record could almost be your Flag
type? The trick here is recognising that constructors are functions too
and what GetOpt really wants is just a function, not necessarily a
constructor.
type Flag a = (a - Settings - Settings)
options :: [OptDescr Flag]
options =
[ Option f [filter]
(ReqArg (\x s - s { filter = Just x }) TYPE)
blahblah
, Option d [date-format]
(ReqArg (\x s - s { dateFormat = Just x }) TYPE)
blahblah
]
Advantages:
very convenient/compact; have to write
(i) Flag type
(ii) Settings record type/GetOpt in one go
(iii) default Settings
easy to lookup flags
Disadvantages:
Not as flexible
- can't group flags into blocks and have different programs that use
different subsets of flags (without sharing the same Setting type)
- everything must go into Settings
- seems harder to say stuff like 'if flag X is set and flag Y are in
the list of Flags, then parameterise flag Z this way' or
'flags X and Y are mutually
[Haskell-cafe] Re: Avoiding boilerplate retrieving GetOpt cmd line args
To anyone who followed up on this thread (hi!). I have posted the GetOpt-summary part of my message on the wiki: http://www.haskell.org/haskellwiki/GetOpt Please update it with the relevant parts of your followups, and correct any silliness. Haven't had the time to look, but I'm particularly interested in what Johnathan suggested because (at a glance), it seems far less clumsy than my solution #4. As usual, don't hesitate to remove things from this page, rename it, etc. -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpBQ884kv2Eb.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] i need wxHaskell compiled for ghc 6.6.1 on Windows
Hi Bulat, can anyone provide wxHaskell already compiled/compilable with ghc 6.6.1 on Windows? Please try the darcs version darcs get http://darcs.haskell.org/wxhaskell It's probably simplest to get it working with wxWidgets 2.6.4 http://prdownloads.sourceforge.net/wxwindows/wxMSW-2.6.4-Setup.exe Best, -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpMW52c9Enq4.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New YAHT maintainer
Hi, I just wanted to announce that Sam Hughes will be taking over as Keeper of the YAHT. YAHT is the venerable Yet Another Haskell Tutorial. It is available both as a wikibook and as a PDF (*). The Keeper of the YAHT has the grave duty of synchronising the YAHT wikibook and tex source, and releasing an updated PDF from time to time. You can send modifications to YAHT either by (a) updating the wikibook or (b) darcs send'ing a patch to the tex source (patches will go to the Haskell Café mailing list for community review). Many thanks to Sam for stepping up! * http://darcs.haskell.org/yaht/yaht.pdf -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpnMyZ8ylfYQ.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Think of a monad...
Dear Haskellers, In the recent HWN, I noticed a new monad metaphor by Don Stewart: Think of a monad as a spacesuite full of nuclear waste in the ocean next to a container of apples. now, you can't put oranges in the space suite or the nucelar waste falls in the ocean, *but* the apples are carried around anyway, and you just take what you need This metaphor very clearly captures the essence of monads. Perhaps it will be even more helpful if accompanied by a small illustration: http://koweycode.blogspot.com/2007/01/think-of-monad.html I hope this turns out to be useful to somebody, -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpICTM7lBOKB.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] YAHT bug
Hi, The page says this was corrected in the wikibook, but it seems not to have been fixed in the darcs repository at haskell.org. Sorry for that. I still haven't worked out a smart way to update the darcs repository from the wikibook. I'm thinking of versioning a copy of the wiki pages with darcs, and using mvs to synch with the wiki. This will help me keep track of changes, which I can then manually transfer to the latex version. It is on my projects list; I just haven't gotten around to it yet. The intention is for the wikibook version to be the unstable YAHT and the latex version to be stable. I found no mentioning on the YAHT page of ways to change this, so sending a mail to this list seemed simplest to me. One way to do it would be to 1) retrieve with: darcs get http://darcs.haskell.org/yaht 2) edit the latex files in question 3) darcs record 4) darcs send I will then review the changes and push them in. Best, -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgplOFAd65tAr.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Since people keep saying the word wikibook, I will make the obligatory mention of http://en.wikibooks.org/wiki/Haskell It might not yet have the style/voice/sense of direction that we're discussing here, but maybe people might be interested in shaping that book into something really interesting? -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpgVb0V5K8cV.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] submenu doesn't seem to work properly in wxhaskell
Hi, Let's transfer this to wxhaskell-users. I've attached your example as a small .lhs file and makefile. For Debian Linux, uncomment the -lwx_gtk2u_gl-2.6 line or otherwise, modify to taste. The following code doesn't seem to work properly. Either the main entry (m1/mp1) or it's sub menu entry (ms1/mps1) do not seem to propagate the event when pressed. It is possible to make it working by uncomments the lines where the menu commands are registered in the frame. It seems to work fine on my Mac at least, unless I'm misunderstanding something. Selecting the menubar items m1 and ms1 both putStr their respective strings, as do mp1 and mps1 (right click on the main frame). On the other hand, under Linux, m1 does not putStr, whereas the others do. Is this the problem you are experiencing? -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpXSpqpru5In.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] submenu doesn't seem to work properly in wxhaskell
On Wed, Nov 15, 2006 at 23:10:44 +0100, Eric Y. Kow wrote: I've attached your example as a small .lhs file and makefile. For Debian Linux, uncomment the -lwx_gtk2u_gl-2.6 line or otherwise, modify to taste. Here are the files, really attached this time. -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. Dear all, The following code doesn't seem to work properly. Either the main entry (m1/mp1) or it's sub menu entry (ms1/mps1) do not seem to propagate the event when pressed. It is possible to make it working by uncomments the lines where the menu commands are registered in the frame. I have the following two questions: 1. Why doesn't the plain code work. Am I missing something or doing something wrong? 2. Doesn't registering eventhandlers in the frame introduce a memory/resource leak, especially in the case of popups? Any suggestions or comments appreciated. Thanks. Kind regards, Maarten module Main where import Graphics.UI.WX main :: IO () main = start gui gui :: IO () gui = do f - frame [ text := Hello world! ] m - menuPane [ text := Menu ] m1 - menuItem m [ text := Menu m1 , on command := putStrLn menu m1] -- set f [ on (menu m1) := putStrLn menu m1 ] menuLine m sub - menuPane [text := Sub menu] ms1 - menuItem sub [ text := submenu ms1 , on command := putStrLn submenu ms1 ] -- set f [ on (menu ms1) := putStrLn submenu ms1 ] menuSub m sub [ text := Sub ] menuItem m [text := Exit, on command := close f] set f [menuBar := [m], on mouse := mouseEvent f, clientSize := sz 200 200 ] return () mouseEvent f eventMouse = do case eventMouse of MouseRightDown mousePoint _ - doPopup f mousePoint _ - return () doPopup f mousePoint = do m - makePopupMenu f Popup Doesnt' work... menuPopup m mousePoint f objectDelete m makePopupMenu f c t = do mp - menuPane [ text := c ] mp1 - menuItem mp [ text := Popup mp1 , on command := putStrLn popup mp1] -- set f [ on (menu mp1) := putStrLn popup mp1 ] menuLine mp sub - menuPane [text := more text] mps1 - menuItem sub [ text := Popup mps1 , on command := putStrLn popup mps1] menuSub mp sub [ text := Sub ] -- set f [ on (menu mps1) := putStrLn popup mps1 ] return mp COMPILE=ghc -package wx #COMPILE+=-lwx_gtk2u_gl-2.6 ifeq ($(shell uname),Darwin) PREP=macosx-app else PREP=\# endif APPS= MenuProblems\ .PHONY: clean all: $(APPS) %: %.lhs $(COMPILE) -o $@ $ $(PREP) $@ clean: rm -rf $(APPS) *.o *.hi *.app pgpEw1kdUHxM2.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [wxhaskell-users] [Haskell-cafe] Announcement: new maintainers forr wxHaskell
On Tue, Nov 07, 2006 at 23:26:40 +0100, Henk-Jan van Tuyl wrote: I suggest [EMAIL PROTECTED], the GUI task force mailing list; nothing is going on there at the moment, but it seems the most appropriate list. Hmm... I guess I'm happy just using the wxhaskell-users list for now, but if we do switch to something, this is a likely candidate. Although in the future, if it does get more active, and more than one project decide to use the list, it might get confusing. Maybe that list would better be for cross toolkit discussions. -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpfmNMXoRsaZ.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ wxhaskell-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[Haskell-cafe] darcs get-together tuesday evening (2006-09-19 18:00)
Dear darcs users, hackers and observers (*), We're getting together around 18:00 this Tuesday to discuss and/or hack on darcs. This will be after the ICFP sessions for that day, in Portland, Oregon, specifically the Marriott downtown waterfront LL1. David Roundy will be there, Ian Lynagh and me too. Hope to see you there. (*) Sorry for the spam, Haskellers. I figured we might as well try to catch ICFP bystanders. -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpMDJnheBANk.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [wxhaskell-users] FW: Reviving wxHaskell
On Tue, Aug 01, 2006 at 13:03:52 -0700, Daan Leijen wrote: One potential challenge is to find a group of testers that are willing to help compiling wxHaskell on different target systems: Windows, MacOS X, and Unix/GTK variations. I volunteer to help test on MacOS X I am happy to give volunteers administrator privileges on the sourceforge site and help out with the initial transition and building the initial new release (which is generally a lot of careful work in compiling and packaging correctly). Why don't we make the switch to darcs while we're at it? Revision control may be the least of our worries, but I think that darcs would have been helpful specifically for our case (multiple revisions of my Unicode patch, Shelarcy's patches for Windows stuff, Mac Makefile stuff, the new DB-related issues). Keeping track of patch-on-patch-on-patch has gottten to be tricky. Having a truly patch-oriented system would 1. make it easier for outsiders to submit modifications 2. make us more resistant to the busy-ness of our project leaders So, should we go ahead and do this? Would hackage be the place to host this? How do we go about getting something set up on hackage? I really don't mean to evangelise, but I was just getting sick of keeping track of patches by hand. -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpRWXqfMuuig.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
