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/issue?@columns=title,id,activity,status,assignedto&@filter=topic,status&topic=6&status=-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
At Wed, 6 Aug 2008 06:29:32 +0100, Eric Y. Kow wrote:
Dear Haskellers,
patch theory is still not defined clearly or rigorously enough for Haskellers
Are the darcs developers familiar with these papers (available on citeseer): Undo Actions in Collaborative Work, Prakash & Knister 1992 Undoing Actions in Collaborative Work: Framework and Experience, Prakash & Knister 1994 The papers describe an undo mechanism for multiuser collaborative editing which sounds like how I imagine darcs patch theory to be (and, they even run into the dreaded exponential merge bug and propose a solution). They include some formal reasoning that may be easy to adapt to darcs? hope this helps, j.
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:
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
On Wed, Aug 06, 2008 at 12:20:17AM -0700, Jeremy Shaw wrote:
Are the darcs developers familiar with these papers (available on citeseer):
Undo Actions in Collaborative Work, Prakash & Knister 1992 Undoing Actions in Collaborative Work: Framework and Experience, Prakash & Knister 1994
The papers describe an undo mechanism for multiuser collaborative editing which sounds like how I imagine darcs patch theory to be (and, they even run into the dreaded exponential merge bug and propose a solution).
They include some formal reasoning that may be easy to adapt to darcs?
I've just had a quick read of http://citeseer.ist.psu.edu/prakash92undoing.html AFAICS this only really deals with the case where there are no conflicts, and doesn't talk about merging. Thanks Ian
At Wed, 6 Aug 2008 10:48:03 +0100, Ian Lynagh wrote:
I've just had a quick read of http://citeseer.ist.psu.edu/prakash92undoing.html AFAICS this only really deals with the case where there are no conflicts, and doesn't talk about merging.
AFAIK, the papers do not talking about merging. They cover conflicts in the case where you want to remove/reorder an older patch which conflicts with a newer one. But, they do not cover conflicts happening during a merge. Based on those papers, and no knowledge of how darcs actually works I can only assume a merge works something like this: 1. find the common patches in both repos and reorder them to be at the beginning. 2. in some order apply the rest of the patches. When a conflict occurs, put some conflict markers in the file. Obviously, there are some big gaps in my understanding :) It is my hope that the framework and lemmas in those papers could be extended to include merging, etc. But, that assumes that the darcs patch theory and their multiple selective undo are sufficiently similar, which is beyond my knowledge. I have implemented some of the ideas from those papers here: http://src.seereason.com/collaborate/ Assuming the two systems are sufficiently similar, I would be interested in extending it to support darcs style merging. It seems like having a small (~200 lines) file which implements the core concepts of darcs patch theory in simplified context might be a useful way to learn about it ? Since I don't know the darcs internals or patch theory, I don't have a concept of how much is still missing (from those papers and my code), and I am not sure what parts of the darcs patch theory are giving people trouble. So, if this stuff is not valuable, I will not be suprised. But, if it is at all valuable, I would feel stupid not sharing it :) j.
On Wed, Aug 06, 2008 at 11:28:58AM -0700, Jeremy Shaw wrote:
At Wed, 6 Aug 2008 10:48:03 +0100, Ian Lynagh wrote:
I've just had a quick read of http://citeseer.ist.psu.edu/prakash92undoing.html AFAICS this only really deals with the case where there are no conflicts, and doesn't talk about merging.
AFAIK, the papers do not talking about merging.
They cover conflicts in the case where you want to remove/reorder an older patch which conflicts with a newer one.
Only in the case where you have already undone the newer one, and thus can just remove both the new patch and its inverse, I thought.
Since I don't know the darcs internals or patch theory, I don't have a concept of how much is still missing
The difficult part is still missing :-) Thanks Ian
At Wed, 6 Aug 2008 19:59:11 +0100, Ian Lynagh wrote:
On Wed, Aug 06, 2008 at 11:28:58AM -0700, Jeremy Shaw wrote:
At Wed, 6 Aug 2008 10:48:03 +0100, Ian Lynagh wrote:
I've just had a quick read of http://citeseer.ist.psu.edu/prakash92undoing.html AFAICS this only really deals with the case where there are no conflicts, and doesn't talk about merging.
AFAIK, the papers do not talking about merging.
They cover conflicts in the case where you want to remove/reorder an older patch which conflicts with a newer one.
Only in the case where you have already undone the newer one, and thus can just remove both the new patch and its inverse, I thought.
That sounds right to me.
Since I don't know the darcs internals or patch theory, I don't have a concept of how much is still missing
The difficult part is still missing :-)
Right, but is the difficulty in thinking up the ideas and figuring out solutions to the problems ? Or is the implementation also neccessarily very large and complex (even if implemented in my toy code which only has two operations: 'insert' and 'delete') I guess the best question is, how far from reality is the theory of patches as written in the darcs manual: http://darcs.net/manual/node8.html Is the additional complexity/difficulty in actually implementing functions like unwind, or is there just a bunch more theory missing from that page? Would a function like unwind be easier to implement, if it was done in my toy setting, and if I did not care about efficiency and computational complexity? thanks! j.
participants (3)
-
Eric Y. Kow -
Ian Lynagh -
Jeremy Shaw