Re: [Haskell-cafe] A small Darcs anomoly
On 28/04/2011 03:21 PM, Chris Smith wrote: On Thu, 2011-04-28 at 08:04 +0200, Bardur Arantsson wrote: There's also the fact that using in-repo branches means that all the tooling doesn't have to rely on any (fs-specific) conventions for finding branches. As someone who has admin'd a reasonably large Bazaar setup (where branch == directory similarly to Darcs) I can honestly say that this would be a HUGE boon. Just keep in mind that adding branches withing the repository is a massive increase in the conceptual complexity of the system, and it would IMO be very un-darcs-like to adopt something like that into the core mental model you need to use a darcs repository, only because of incidental conveniences Convention, rather than baking answers into tools, is the right way to solve organizational problems, and that's essentially what we're talking about here. And adding complexity every time someone has an awkward use case will lead (has led, in more systems than I can count) to an unusable result in the end. It seems half the people here think that having multiple branches per repo is a fantastic idea, while the other half think it's a stupid idea. Perhaps there is room for more than one revision control system based on change-sets in this world? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 04/28/2011 12:19 AM, Ganesh Sittampalam wrote: On 26/04/2011 12:17, Malcolm Wallace wrote: On 25 Apr 2011, at 11:13, Andrew Coppin wrote: On 24/04/2011 06:33 PM, Jason Dagit wrote: This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. Yes, this seems clear. I'm just wondering whether or not it's the best design choice. It seems to me to be a considerable insight. Branches and repositories are the same thing. There is no need for two separate concepts. The main reason other VCSes have two concepts is because one of them is often more efficiently implemented (internally) than the other. But that's silly - how much better to abstract over the mental clutter, and let the implementation decide how its internals look! So in darcs, two repositories on the same machine share the same files (like a branch), but if they are on different machines, they have separate copies of the files. The difference is a detail that you really don't need to know or care about. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, No, if on the same machine, the patches only appear once, it is just the index that duplicates some information (I think). In fact just as if it were a branch in another VCS. Unfortunately, I don't think this is quite true, because being able to switch between multiple branches in the same working directory means you can reuse build products when switching branches. Depending on how radical the branch shift is, this can be a substantial win, and it's the main reason that darcs might in future implement in-repo branching of some form. There's also the fact that using in-repo branches means that all the tooling doesn't have to rely on any (fs-specific) conventions for finding branches. As someone who has admin'd a reasonably large Bazaar setup (where branch == directory similarly to Darcs) I can honestly say that this would be a HUGE boon. Cheers, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On Thu, 2011-04-28 at 08:04 +0200, Bardur Arantsson wrote: There's also the fact that using in-repo branches means that all the tooling doesn't have to rely on any (fs-specific) conventions for finding branches. As someone who has admin'd a reasonably large Bazaar setup (where branch == directory similarly to Darcs) I can honestly say that this would be a HUGE boon. Just keep in mind that adding branches withing the repository is a massive increase in the conceptual complexity of the system, and it would IMO be very un-darcs-like to adopt something like that into the core mental model you need to use a darcs repository, only because of incidental conveniences (by incidental here, I mean that there is nothing wrong with the darcs model; it *is* true that branches and repositories are the same thing -- but it just turns out that, often, developers want several repositories for the same project). It seems to me the same problems could be solved without the necessary increase in complexity by: (a) Keeping repositories in sibling directories with names. (b) Keeping a working directory that you build in as one of these, and switching it to match various other named repositories as needed. Then your build files are still there. Surely there are things darcs could do to make some of those bits easier to do remotely (ssh to a remote machine in order to darcs-get from one directory to a new one is a pain, for sure). But those can be offered without in-repo branches, at the advantage of not really affecting people that don't use them. Convention, rather than baking answers into tools, is the right way to solve organizational problems, and that's essentially what we're talking about here. And adding complexity every time someone has an awkward use case will lead (has led, in more systems than I can count) to an unusable result in the end. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 2011-04-28 08:21 -0600, Chris Smith wrote: It seems to me the same problems could be solved without the necessary increase in complexity by: (a) Keeping repositories in sibling directories with names. (b) Keeping a working directory that you build in as one of these, and switching it to match various other named repositories as needed. Then your build files are still there. Unfortunately, sharing a build directory between separate repositories does not work. After a build from one repository, all the outputs from that build will have modification times more recent than all the files in the other repository. When switching branches, git (and other systems) update the mtimes on all files that changed, which will cause build systems to notice that the outputs are out of date. 'cd' does not do this. Thus, if you have separate repo directories (call them A and B) with different versions of some file, and you share a build directory between them, it is very likely that after building A, a subsequent build of B will fail to work correctly. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
Unfortunately, sharing a build directory between separate repositories does not work. After a build from one repository, all the outputs from that build will have modification times more recent than all the files in the other repository.Then I suggest that your build tools are broken. Rebuilding should not depend on an _ordering_ between modification times of source and object, merely on whether the timestamp of the source file is different to its timestamp the last time we looked. (This requires your build tools to keep a journal/log, yes, but it is the only safe way to do it.)It is relatively common to change source files to have an older timestamp rather than a newer one. This should not cause your build system to ignore them. It can happen for any number of reasons: restoring from backup, switching repository, bisecting the history of a repo, clock skew on different machines, Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 04/28/2011 05:23 PM, malcolm.wallace wrote: Unfortunately, sharing a build directory between separate repositories does not work. After a build from one repository, all the outputs from that build will have modification times more recent than all the files in the other repository. Then I suggest that your build tools are broken. Rebuilding should not depend on an _ordering_ between modification times of source and object, merely on whether the timestamp of the source file is different to its timestamp the last time we looked. (This requires your build tools to keep a journal/log, yes, but it is the only safe way to do it.) So 'make' is broken (in this regard)? Then - I fear - everyone has to cope with that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 2011-04-28 15:23 +, malcolm.wallace wrote: Then I suggest that your build tools are broken. Rebuilding should not depend on an _ordering_ between modification times of source and object, merely on whether the timestamp of the source file is different to its timestamp the last time we looked. (This requires your build tools to keep a journal/log, yes, but it is the only safe way to do it.) Right. The /order/ of the timestamps is wrong when a build directory is shared between repositories (isn't that what I said?). Try it yourself with cabal: it will fail. Consider two repos, A and B, each with different versions of foo.x, that (when compiled) produces the output foo.y. We store the build in the directory C. Initially, say A/foo.x has a mtime of 1, and B/foo.x has an mtime of 2. We do a build of A, producing the output file C/foo.y. say C/foo.y now has a mtime of 3. Now we do a build in B. The build system sees that C/foo.y has a mtime of 3, which is newer than B/foo.x's mtime of 2. The build system therefore does not rebuild C/foo.y. It is relatively common to change source files to have an older timestamp rather than a newer one. This should not cause your build system to ignore them. It can happen for any number of reasons: restoring from backup, switching repository, bisecting the history of a repo, clock skew on different machines, All of these operations update the mtimes on the files... -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
There seems to be some misunderstanding here. I didn't suggest you share a separate build directory between repositories... I suggested you have a single repository that is the one you are currently building in, and that you synchronize it with various other repositories as you swap branches. That process should touch the modification times on the files that are changed, such that your partial builds are as trustworthy as partial builds are likely to be (that is, not very... but passable). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 26/04/2011 12:17, Malcolm Wallace wrote: On 25 Apr 2011, at 11:13, Andrew Coppin wrote: On 24/04/2011 06:33 PM, Jason Dagit wrote: This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. Yes, this seems clear. I'm just wondering whether or not it's the best design choice. It seems to me to be a considerable insight. Branches and repositories are the same thing. There is no need for two separate concepts. The main reason other VCSes have two concepts is because one of them is often more efficiently implemented (internally) than the other. But that's silly - how much better to abstract over the mental clutter, and let the implementation decide how its internals look! So in darcs, two repositories on the same machine share the same files (like a branch), but if they are on different machines, they have separate copies of the files. The difference is a detail that you really don't need to know or care about. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, No, if on the same machine, the patches only appear once, it is just the index that duplicates some information (I think). In fact just as if it were a branch in another VCS. Unfortunately, I don't think this is quite true, because being able to switch between multiple branches in the same working directory means you can reuse build products when switching branches. Depending on how radical the branch shift is, this can be a substantial win, and it's the main reason that darcs might in future implement in-repo branching of some form. Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 25 Apr 2011, at 11:13, Andrew Coppin wrote: On 24/04/2011 06:33 PM, Jason Dagit wrote: This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. Yes, this seems clear. I'm just wondering whether or not it's the best design choice. It seems to me to be a considerable insight. Branches and repositories are the same thing. There is no need for two separate concepts. The main reason other VCSes have two concepts is because one of them is often more efficiently implemented (internally) than the other. But that's silly - how much better to abstract over the mental clutter, and let the implementation decide how its internals look! So in darcs, two repositories on the same machine share the same files (like a branch), but if they are on different machines, they have separate copies of the files. The difference is a detail that you really don't need to know or care about. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, No, if on the same machine, the patches only appear once, it is just the index that duplicates some information (I think). In fact just as if it were a branch in another VCS. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. Yes, this seems clear. I'm just wondering whether or not it's the best design choice. It seems to me to be a considerable insight. Presumably David thought the same. I won't deny that there is a certain simplifying elegance to it. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, No, if on the same machine, the patches only appear once, it is just the index that duplicates some information (I think). In fact just as if it were a branch in another VCS. 1. Conceptually, you have the same information twice. 2. I have no idea how to make Darcs do the thing with hard links (is that even supported under Windows?) I just copy the whole folder using the normal OS file tools. Either way, you lose the ability to see how branches are related to each other, which might be useful in some cases. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 26 April 2011 13:16, Andrew Coppin andrewcop...@btinternet.com wrote: 2. I have no idea how to make Darcs do the thing with hard links (is that even supported under Windows?) I just copy the whole folder using the normal OS file tools. darcs get path/to/other/local/repo Either way, you lose the ability to see how branches are related to each other, which might be useful in some cases. How do you see how git branches are related to each other? -- 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] A small Darcs anomoly
On Tue, Apr 26, 2011 at 6:35 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 26 April 2011 13:16, Andrew Coppin andrewcop...@btinternet.com wrote: 2. I have no idea how to make Darcs do the thing with hard links (is that even supported under Windows?) I just copy the whole folder using the normal OS file tools. darcs get path/to/other/local/repo More specifically than that. This is the workflow I follow with darcs repos. Say, that I want to get the Foo repo: mkdir ~/repos/Foo cd ~/repos/Foo darcs get http://example.com/Foo HEAD darcs get HEAD feature-branch Then I can send the patches from feature-branch to the official Foo repo at any time. I can also merge them back into HEAD doing a darcs pull from feature-branch to HEAD. I think this is quite comparable to the git workflow. Either way, you lose the ability to see how branches are related to each other, which might be useful in some cases. How do you see how git branches are related to each other? You can use gitk to see how the histories have interacted. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote: How do you see how git branches are related to each other? To some extent, you can see such a relation in gitk. For mercurial, hg glog also shows a bit. I suppose there's also something to visualise branches in bazaar, but I've never used that, so I don't know. So, with gitk/glog, you can see that foo branched off bar after commit 0de8793fa1bc..., then checkout/update to that commit [or bar's head], checkout/update to foo's head/tip and compare. Or there could be some feature I've never heard of yet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 2011-04-26 15:51 +0200, Daniel Fischer wrote: On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote: How do you see how git branches are related to each other? To some extent, you can see such a relation in gitk. For mercurial, hg glog also shows a bit. I suppose there's also something to visualise branches in bazaar, but I've never used that, so I don't know. So, with gitk/glog, you can see that foo branched off bar after commit 0de8793fa1bc..., then checkout/update to that commit [or bar's head], checkout/update to foo's head/tip and compare. No need to do a checkout; gitk can visualize any or all branches of the repository simultaneously. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On Tuesday 26 April 2011 16:04:55, Nick Bowler wrote: On 2011-04-26 15:51 +0200, Daniel Fischer wrote: On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote: How do you see how git branches are related to each other? To some extent, you can see such a relation in gitk. For mercurial, hg glog also shows a bit. I suppose there's also something to visualise branches in bazaar, but I've never used that, so I don't know. So, with gitk/glog, you can see that foo branched off bar after commit 0de8793fa1bc..., then checkout/update to that commit [or bar's head], checkout/update to foo's head/tip and compare. No need to do a checkout; gitk can visualize any or all branches of the repository simultaneously. Yes, at least if you're only interested in the genealogy. When I think about how branches are related, I think of contents at least as much as of genealogy. Can gitk show the code next to each other? I wouldn't be surprised, but I haven't yet found a way to do it (but I've only taken a couple of short looks, so that doesn't say much). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On Tue, Apr 26, 2011 at 3:16 PM, Andrew Coppin andrewcop...@btinternet.com wrote: Presumably David thought the same. I won't deny that there is a certain simplifying elegance to it. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, No, if on the same machine, the patches only appear once, it is just the index that duplicates some information (I think). In fact just as if it were a branch in another VCS. 1. Conceptually, you have the same information twice. 2. I have no idea how to make Darcs do the thing with hard links (is that even supported under Windows?) I just copy the whole folder using the normal OS file tools. Either way, you lose the ability to see how branches are related to each other, which might be useful in some cases. http://wiki.darcs.net/Ideas/Branches I would like to have in-place Darcs branches too but not for wasting space reason. It is nice to keep complete history of the project and with current loose coupling of branches it requires more discipline from me :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On Tue, 2011-04-26 at 16:34 +0200, Daniel Fischer wrote: On Tuesday 26 April 2011 16:04:55, Nick Bowler wrote: On 2011-04-26 15:51 +0200, Daniel Fischer wrote: On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote: How do you see how git branches are related to each other? To some extent, you can see such a relation in gitk. For mercurial, hg glog also shows a bit. I suppose there's also something to visualise branches in bazaar, but I've never used that, so I don't know. So, with gitk/glog, you can see that foo branched off bar after commit 0de8793fa1bc..., then checkout/update to that commit [or bar's head], checkout/update to foo's head/tip and compare. No need to do a checkout; gitk can visualize any or all branches of the repository simultaneously. Yes, at least if you're only interested in the genealogy. When I think about how branches are related, I think of contents at least as much as of genealogy. Can gitk show the code next to each other? I wouldn't be surprised, but I haven't yet found a way to do it (but I've only taken a couple of short looks, so that doesn't say much). I cannot say for gitk but gitview does it does it for sure: gitview --all --date-order Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
2. I have no idea how to make Darcs do the thing with hard links (is that even supported under Windows?) I just copy the whole folder using the normal OS file tools. darcs get path/to/other/local/repo Either way, you lose the ability to see how branches are related to each other, which might be useful in some cases. How do you see how git branches are related to each other? git show-branch [branches] It was one of nicest things in git for me when I stared to use it. xmms2-devel $ git show-branch ! [error-on-implicit] OTHER: wscript: make implicit function declarations an error in C code * [master] FEATURE(2184): Update pre-generated cython files. ! [missing-protos] OTHER: one more me in AUTHORS --- + [error-on-implicit] OTHER: wscript: make implicit function declarations an error in C code + [missing-protos] OTHER: one more me in AUTHORS + [missing-protos^] OTHER: explicitely declare g_sprintf() + [missing-protos~2] OTHER: explicitely declare semtimedop() +*+ [master] FEATURE(2184): Update pre-generated cython files. The simpler things are: git [log|diff] from..to git [log|diff] from...to Set of [commits|changes] to be added to another branch. -- Sergei signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 24/04/2011 06:33 PM, Jason Dagit wrote: On Sun, Apr 24, 2011 at 2:05 AM, Andrew Coppin andrewcop...@btinternet.com mailto:andrewcop...@btinternet.com wrote: So I was a little surprised to discover that... Darcs doesn't actually support doing this. Darcs is only really interested in the result of applying *all* changes in a repo. It seems daft to me that you would design a sophisticated system for splitting history into independent chunks, and then not let me manipulate them independently. This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. Yes, this seems clear. I'm just wondering whether or not it's the best design choice. To get the effect you want, you simply create two repositories. One having only the patches for ghc 6.6 and one having the patches of ghc 7.0 and then you pull just the patches you want from 7.0 into 6.6. There are options to 'darcs get' that help you select the right set of patches to help you create the two repositories. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, and you're not really storing the history of the relationship between two branches, only the history of the branch itself. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A small Darcs anomoly
I've discovered something interesting. Darcs stores history as a partially-ordered set of changes. This is a beautiful and elegant idea. In theory, this lets me apply any combination of changes, possibly generating file versions which have never actually existed before. (E.g., the new type checker from GHC 7.0 embedded in the GHC 6.6 codebase - not that I imagine it would compile, but in principle I can do it.) So I was a little surprised to discover that... Darcs doesn't actually support doing this. Darcs is only really interested in the result of applying *all* changes in a repo. If you want to apply some subset of changes, you need to make a seperate repo containing only the changes you want applied. It seems daft to me that you would design a sophisticated system for splitting history into independent chunks, and then not let me manipulate them independently. (If you think about it, the difference between, say, GHC 7.0 and GHC 6.6 is which set of changes are applied. Yet because Darcs doesn't support looking at it like this, you must have a completely seperate repo for each one...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On Sun, 24 Apr 2011, Andrew Coppin wrote: (If you think about it, the difference between, say, GHC 7.0 and GHC 6.6 is which set of changes are applied. Yet because Darcs doesn't support looking at it like this, you must have a completely seperate repo for each one...) But darcs shares the patch files between repositories on the same file system using hard links. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On Sun, Apr 24, 2011 at 2:05 AM, Andrew Coppin andrewcop...@btinternet.comwrote: I've discovered something interesting. Darcs stores history as a partially-ordered set of changes. This is a beautiful and elegant idea. In theory, this lets me apply any combination of changes, possibly generating file versions which have never actually existed before. (E.g., the new type checker from GHC 7.0 embedded in the GHC 6.6 codebase - not that I imagine it would compile, but in principle I can do it.) So I was a little surprised to discover that... Darcs doesn't actually support doing this. Darcs is only really interested in the result of applying *all* changes in a repo. If you want to apply some subset of changes, you need to make a seperate repo containing only the changes you want applied. It seems daft to me that you would design a sophisticated system for splitting history into independent chunks, and then not let me manipulate them independently. This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. To get the effect you want, you simply create two repositories. One having only the patches for ghc 6.6 and one having the patches of ghc 7.0 and then you pull just the patches you want from 7.0 into 6.6. There are options to 'darcs get' that help you select the right set of patches to help you create the two repositories. If you're interested in the details of how to do it, I would suggest asking on the darcs-users mailing list. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
