darcs and Google Summer of Code
Dear Haskellers, Recently, there has been a suggestion that darcs apply to be a mentoring organisation for Google Summer of Code in its own right. Thanks! I think we will definitely try this out! Ideas: GUI and hashed-storage ----------------------------- So far, we have two active projects, active in the sense that there are interested students and mentors. The first is to work towards a sort of graphical interface for darcs (as has been suggested on this list). I suspect that we what we will likely do with this idea is to refine it into something that may either be part of a GUI (like a patch dependency viewer), or which will make it much easier for third parties to write a GUI in the future. I'll note that last year, we had a few interested students for this year and a potential mentor (Shelarcy from wxHaskell). Hopefully we can call on them again this year? There is also some work by Wolgang Jeltsch and students that we could talk about extending into a GSoC project. The second idea is to continue our performance work. Petr Ročkai has done some very interesting work in optimising the way that darcs stores files for its hashed and darcs-2 format repositories. In one of his tests, he reports having a possible tenfold speed-up in darcs whatsnew times, and a halving of the number of filesystem calls in one his tests. http://bugs.darcs.net/issue1202. It would be very interesting to see Petr continue this sort of work and perhaps tie it into of some of the other optimisations the darcs community have in mind. Anyway, you may be interested to know that we have a parallel discussion going on about this on the darcs-users list: http://lists.osuosl.org/pipermail/darcs-users/2009-February/017766.html We are also keeping a summary of this discussion here with our active ideas: http://wiki.darcs.net/index.html/GoogleSummerOfCode Hackathon --------- Finally, darcs will be holding its second hacking sprint within the Haskell Hackathon, April 17-19, Utrecht. There's already at least 5 of us from darcs/camp, and we would love to see more of you. Or if you're already planning on joining Hac5, come hack a little darcs while you're there! http://wiki.darcs.net/index.html/Sprints/2009-04 Hope to see you soon, -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9
Am Mittwoch, 18. Februar 2009 10:54 schrieb Eric Kow:
The first is to work towards a sort of graphical interface for darcs (as has been suggested on this list). I suspect that we what we will likely do with this idea is to refine it into something that may either be part of a GUI (like a patch dependency viewer), or which will make it much easier for third parties to write a GUI in the future.
What do you mean with “something which will make it much easier for third parties to write a GUI in the future”?
I'll note that last year, we had a few interested students for this year and a potential mentor (Shelarcy from wxHaskell). Hopefully we can call on them again this year? There is also some work by Wolgang Jeltsch
Wol*f*gang, please. :-)
and students that we could talk about extending into a GSoC project.
I would really like if patch viewer and GUI GSoC plans would be coordinated with me. There will probably some students that will start working on a darcs GUI next week. In addition there might be other students working on a patch viewer in spring or summer.
We are also keeping a summary of this discussion here with our active ideas:
How can I get write access for this page? I’ve put myself as a potential mentor on the old Haskell SoC ticket (http://hackage.haskell.org/trac/summer-of-code/ticket/17). However, one or two years ago I was told that mentoring is a very time-consuming thing (and to my knowledge, you don’t get any payments for that, at least for Haskell projects). So if some other person wants to mentor a Grapefruit-based GUI or patch viewer project, I’d be very happy and would support this person the best I can. Best wishes, Wolfgang
Hi Wolgang, On Wed, Feb 18, 2009 at 12:53:23 +0100, Wolfgang Jeltsch wrote:
What do you mean with “something which will make it much easier for third parties to write a GUI in the future”?
Kari's example of GUI-friendly optimisations might be one thought. More generally, I was thinking of some kind of darcs library design work: now that we have exposed all our modules in a sort of darcs library, how we can grow this into a proper library that people can "safely" use (safe in the sense that the library makes it very clear what kinds of operations are read-only, or to what extent operations are "atomic", preferably with atomic repository-manipulating functions only being exposed and not their underlying substeps). The library could also tackle issues like darcs sending messages back to the user (right now, we just putStrLn, but what if we want them to go a special Window?) Sorry if these are vague thoughts. In general, it would be nice to see a some summer of code projects that emphasised foundational work.
I'll note that last year, we had a few interested students for this year and a potential mentor (Shelarcy from wxHaskell). Hopefully we can call on them again this year? There is also some work by Wolgang Jeltsch
Wol*f*gang, please. :-)
Argh, after looking Jeltsch up to make sure I got that right, I had to go make a typo on the easy part. :-D
How can I get write access for this page?
Very sorry for the delayed response: http://wiki.darcs.net/index.html/UserPreferences
I’ve put myself as a potential mentor on the old Haskell SoC ticket (http://hackage.haskell.org/trac/summer-of-code/ticket/17).
Thanks!
However, one or two years ago I was told that mentoring is a very time-consuming thing (and to my knowledge, you don’t get any payments for that, at least for Haskell projects).
While the darcs project would be grateful if you wanted to donate us your mentor payment, we certainly do not want to make you feel obliged to do so. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9
Am Samstag, 21. Februar 2009 16:18 schrieb Eric Kow:
Hi Wolgang,
Hmm, wrong again. ;-)
On Wed, Feb 18, 2009 at 12:53:23 +0100, Wolfgang Jeltsch wrote:
What do you mean with “something which will make it much easier for third parties to write a GUI in the future”?
Kari's example of GUI-friendly optimisations might be one thought.
More generally, I was thinking of some kind of darcs library design work: now that we have exposed all our modules in a sort of darcs library, how we can grow this into a proper library that people can "safely" use (safe in the sense that the library makes it very clear what kinds of operations are read-only, or to what extent operations are "atomic", preferably with atomic repository-manipulating functions only being exposed and not their underlying substeps). The library could also tackle issues like darcs sending messages back to the user (right now, we just putStrLn, but what if we want them to go a special Window?)
Tomorrow, I will discuss with the first half of my student project students (3 students) about what exact topic they will pursue. My idea is to let them start a Grapefruit-based darcs GUI. They should not use the currenct darcs interface directly where it doesn’t fit GUI frontends well. Instead they should write a wrapper around the “ugly” parts which exposes a “nice” interface. Later, one could merge this wrapper into the darcs codebase so that darcs exports the “nice” interface then. The GUI code wouldn’t have to change much then. In April, the second half of the students will start with their project. If there is some graphics support in Grapefruit at that time then they might work on a patch viewer. What do you think about that? Best wishes, Wolfgang
Hi, (carefully avoiding your name :-P) On Mon, Feb 23, 2009 at 16:08:18 +0100, Wolfgang Jeltsch wrote:
Tomorrow, I will discuss with the first half of my student project students (3 students) about what exact topic they will pursue. My idea is to let them start a Grapefruit-based darcs GUI. They should not use the currenct darcs interface directly where it doesn’t fit GUI frontends well. Instead they should write a wrapper around the “ugly” parts which exposes a “nice” interface. Later, one could merge this wrapper into the darcs codebase so that darcs exports the “nice” interface then. The GUI code wouldn’t have to change much then.
It would be interesting to see how they get on writing their wrapper around the darcs "library" as opposed to making darcs invocations (although if you were to go the latter route, I noticed that the patch-tag folks have uploaded a 'DarcsHelpers' package which may be of some use.
In April, the second half of the students will start with their project. If there is some graphics support in Grapefruit at that time then they might work on a patch viewer.
What do you think about that?
In addition to my previous suggestion that the students hang out in #darcs, maybe they could start some sort of blog detailing their progress, and with the occasional screenshot? It would be a great addition to the darcs planet: http://planet.darcs.net Thanks! -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9
participants (2)
-
Eric Kow -
Wolfgang Jeltsch