Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Tue, Mar 10, 2009 at 11:19 AM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: The Google Summer of Code will be running again this year. Once again, haskell.org has the opportunity to bid to become a mentoring organisation. (Although, as always, there is no guarantee of acceptance.) Google is now accepting applications: Indeed. Since I am (perhaps by default) the GSoC org admin for haskell.org once again this year, and will shortly need to list our mentors on our application form, I am now soliciting volunteers to be mentors. Please email me directly. The mentoring group has two main jobs: I took the liberty to create a People2009 page: http://hackage.haskell.org/trac/summer-of-code/wiki/People2009 -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) 2. darcs send which goes through the usual interactive console but then prompts with a file save pane where you will save the .dpatch (easy contribution). 3. graphical dependency chart for patches (also shows conflict patches as merges). On Wed, Feb 11, 2009 at 11:52 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: Here are the projects I favor (in no particular order): […] * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/ . Perhaps the specific project could be making TortoiseDarcs not Windows specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don't want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
2009/2/12 Matthew Elder m...@mattelder.org: would love to see this. basic features first i suppose. here are some of my ideas: meld-like diff view would be great too. http://meld.sourceforge.net/ -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. By the way: I think it may be worthwile to contact Google to point out the recent growth of Haskell community. I don't know on what basis they assign the slots, but it may be beneficial to do so. All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Thu, 12 Feb 2009, Conrad Parker wrote: 2009/2/12 Don Stewart d...@galois.com: Thanks for the analysis, this clarifies things greatly. Feasibility and scope is a big part of how we determine what projects to work on. I agree that it's beyond the scope of a SoC project. Rather than H.263 or H.264 I was going to suggest implementation of Theora or OMS, both of which avoid the patent issues and have publicly available specs: http://theora.org/doc/Theora.pdf http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf Scanning those documents should give anyone a fair idea of the amount of work involved. My understanding is that OMS is of a similar complexity to H.263, and H.264 is more complex than any of these. For Theora playback we've found that the largest CPU load comes from colorspace conversion, where the YUV output of the codec needs to be converted to RGB for some targets (like Firefox). That is some fairly straightforward array processing, and would be a good place to start for anyone trying to implement video codecs in Haskell. That is great idea and a great seed to plant. Wonder if Theora is as good as H.264 in terms of video quality and bandwidth usage? Theora codec is being used in Ekiga (popular SIP/H.323 video softphone but that thing keeps crashing on me :( ) Jamie Conrad. gtener: On Wed, Feb 11, 2009 at 21:00, Jamie hask...@datakids.org wrote: Hi Gwern, On Wed, 11 Feb 2009, Gwern Branwen wrote: I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? I have no idea, I have not dig deeper into H.263 C source code but I guess it should be quite trivial as it is a black box with video frame input and output with several parameters for encoding and just frame in/out for decoding. I didn't dig into the source code either, but I've just skimmed through Wikipedia page on that codec: http://en.wikipedia.org/wiki/H.263 and in seems far from trivial. Anything that has 23 annexes is likely to be quite complex :-) Therefore I seriously doubt chances for success of such project. I did some checks: in libavcodec at least following files consist of implementation of H.263: h263.c h263data.h h263dec.c h263.h h263_parser.c h263_parser.h How many lines are there? [te...@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46217 2032 h263.h 91282 2361 h263_parser.c 29165 1047 h263_parser.h 7591 24232 261470 razem In Haskell project one would also need to provide some additional utility code which is part of libavcodec. Fast grep shows the tip of an iceberg: [te...@laptener libavcodec]$ grep include h263* | grep -v h263.c:#include dsputil.h h263.c:#include avcodec.h h263.c:#include mpegvideo.h h263.c:#include h263data.h h263.c:#include mpeg4data.h h263.c:#include mathops.h h263data.h:#include mpegvideo.h h263dec.c:#include avcodec.h h263dec.c:#include dsputil.h h263dec.c:#include mpegvideo.h h263dec.c:#include h263_parser.h h263dec.c:#include mpeg4video_parser.h h263dec.c:#include msmpeg4.h h263.h:#include config.h h263.h:#include msmpeg4.h h263_parser.c:#include parser.h h263_parser.h:#include parser.h Bottom line: I don't think it is reasonable to assume anyone without previous knowledge of H.263 is able to fit that project into one summer. But! It's Haskell community, and people here see the impossible happen from time to time ;-) All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Malcolm.Wallace: Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. I agree: the big projects can stand on their own. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
gtener: On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. By the way: I think it may be worthwile to contact Google to point out the recent growth of Haskell community. I don't know on what basis they assign the slots, but it may be beneficial to do so. In the past it has been based on scale of mentors, proposals and students. If we're under-allocated, that can sometimes be addressed, however. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Thu, 12 Feb 2009, Achim Schneider wrote: Jamie hask...@datakids.org wrote: For Theora playback we've found that the largest CPU load comes from colorspace conversion, where the YUV output of the codec needs to be converted to RGB for some targets (like Firefox). That is some fairly straightforward array processing, and would be a good place to start for anyone trying to implement video codecs in Haskell. That is great idea and a great seed to plant. Wonder if Theora is as good as H.264 in terms of video quality and bandwidth usage? Theora isn't meant to be a H.264 competitor, but a replacement for flash, wmv and the ilk. I dare to guess that it works decent for low bitrates, especially if you're more interested in detecting shapes than skin pores. I guess you just have to do field tests: encoding video on the fly just isn't what general-purpose CPUs are made for, it's the playing field of processors that take SIMD seriously, i.e. GPUs. Signers (deaf people or hearing people who know sign language) naturally put strong emphasize on smooth video quality (i.e. at least 25 fps with no blurries/fuzzy). I use Mirial Softphone (to me, a best H.323/SIP video softphone so far, run on Windows) and it runs very nicely and perfectly on my Dell 1 GHz Centrind Duo laptop in both H.263 and H.264 (I even tried H.264 at 704x576 at 30 FPS and it works real nice). However Mirial sure did display CPU overload message time to time on my Samsung NC10 netbook especially using H.264 and result in pixelization of video frames. So no problem at all with my Dell laptop but kind of borderline on Atom 1.6Ghz netbook. I agree it would surely help offload the CPU work when there is hardware encoder/decoder present in GPU. I see more and more GPU now support H.264 decoder which is nice. Jamie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Matthew Elder wrote: would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) Extending this idea, I'd like to see some 3D visualization of the file hierarchy and the partial hierarchy for the patch/diff being considered. That is: not just per-file diff views, but also per-project views. It'd also be nice to see this with more than one layer of diff at a time so you can get an idea about potential conflicts and what parts of the project are getting heavily changed. Felipe Lessa wrote: 2009/2/12 Matthew Elder m...@mattelder.org: would love to see this. basic features first i suppose. here are some of my ideas: meld-like diff view would be great too. http://meld.sourceforge.net/ I especially like the highlighting of what has changed within the line, rather than diff's usual answer of durr, it's different. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
+1 for some graphical tools for darcs, especially even a graphical merge tool (and a console/curses based version as well, to be sure). And +1 for darcs and xmonad applying as mentoring organizations in their own right. For that matter, it might be worthwhile for GHC to apply as well! That would ensure some dedicated compiler slots, and more could be contributed from the main haskell.org pool as appropriate. As well, I know that there's quite a nice new hackage2 almost rolled out, but I'm sure that there's at least an SoC project or two worth of feature additions to that as well. Off the top of my head, and bearing in mind that some might be further along than I think: a generalized way to search the package database, slicing and dicing by upload time, authors/maintainers, popularity, limiting views to packages that build on certain platforms, etc; some thought into security measures; a ratings system and associated reviews (thread/ wikibased); ways to mark packages as depreciated/for historic purposes. And there's bound to be more. As for numerics, I recall that Greg Wright, who knows whereof he speaks, had some particular issues that he thought no existing library addressed. I can't recall the details or do them justice, but perhaps he might care to enlighten us? Cheers, Sterl. On Feb 12, 2009, at 3:16 AM, Matthew Elder wrote: would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) 2. darcs send which goes through the usual interactive console but then prompts with a file save pane where you will save the .dpatch (easy contribution). 3. graphical dependency chart for patches (also shows conflict patches as merges). On Wed, Feb 11, 2009 at 11:52 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: Here are the projects I favor (in no particular order): […] * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http:// tortoisedarcs.sourceforge.net/. Perhaps the specific project could be making TortoiseDarcs not Windows specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don't want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
2009/2/11 Gwern Branwen gwe...@gmail.com: [^complaints]: I can hear the wankers in the peanut gallery - Yeah, and it's been buggy ever since! Hush you. Those (aforementioned) people should keep in mind we tried to keep the scope of the project down to just making the new Haddock support the features of the old Haddock (no type inference, docs for GHC extensions, etc). Most of the bugs concerning the pre-GHC subset of Haddock have now been fixed (although there are a few left). Most other problems we're currently seeing is with GHC extensions, like for instance Template Haskell.You should not blame the SoC project so much for this (although it could have handled extensions more gracefully). The project was also run in a time when the GHC API was not so evolved and had a bug or two. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Seems like it is ok to write H.264 in Haskell and released via GPL license? There is theora.org but H.264 would be ideal. Ditto for H.263. Software patent issues are entirely orthogonal to the copyright issues of who wrote what under which license. That's why software patents suck so very hard. See https://secure.wikimedia.org/wikipedia/en/wiki/Software_patent#Free_and_open_source_software https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_software gwern Thanks for the links. What I understand is some standard body create the specs, the role, the purpose, the protocols (i.e. H.323 by ITU Telecommunication Standardization Sector) then one can create programs that follow those protocols and don't have to concern about patent license at all, is that correct? I just checked H.264 and yes JVT (the creator of H.264/MPEG 4/AVC specs/protocol) require patent licensing. Oh well... I guess JVT does not do something with x264/ffmpeg cause they are totally free, but let say if I include the H.264 code from x264/ffmpeg in my application and sell for some $$$ then JVT's lawyers could run after me, is that correct? I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) Jamie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Wed, Feb 11, 2009 at 10:00 AM, Jamie hask...@datakids.org wrote: Seems like it is ok to write H.264 in Haskell and released via GPL license? There is theora.org but H.264 would be ideal. Ditto for H.263. Software patent issues are entirely orthogonal to the copyright issues of who wrote what under which license. That's why software patents suck so very hard. See https://secure.wikimedia.org/wikipedia/en/wiki/Software_patent#Free_and_open_source_software https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_software gwern Thanks for the links. What I understand is some standard body create the specs, the role, the purpose, the protocols (i.e. H.323 by ITU Telecommunication Standardization Sector) then one can create programs that follow those protocols and don't have to concern about patent license at all, is that correct? In general, you can't say that just because it was generated by some standards body it will be usable. Standards bodies often only have to make their work available under 'reasonable and non discriminatory' terms, which should be read 'not ruinously high license fees' (see https://secure.wikimedia.org/wikipedia/en/wiki/Reasonable_and_Non_Discriminatory_Licensing ). RAND terms are, of course, hopelessly strict for any FLOSS purposes. I just checked H.264 and yes JVT (the creator of H.264/MPEG 4/AVC specs/protocol) require patent licensing. Oh well... I guess JVT does not do something with x264/ffmpeg cause they are totally free, but let say if I include the H.264 code from x264/ffmpeg in my application and sell for some $$$ then JVT's lawyers could run after me, is that correct? If JVT has patented any of the techniques in the x264/ffmpeg codebase, then they can come after you if you distribute in *any* manner. An example: the RIAA is still allowed to sue file-sharers even though the sharers aren't seeing a penny in any way. I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) Jamie It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
gwern0: (The following is a quasi essay/list of past Summer of Code projects; my hope is to guide thinking about what Summer of Code projects would be good to pick, and more specifically what should be avoided. If you're in a hurry, my conclusions are at the bottom. The whole thing is written in Markdown; for best results pass it through Pandoc or view it via your friendly local Gitit wiki.) Thanks for the write up! We explicitly pushed harder in 2008 to clarify and simplify the goals of the projects, ensure adequate *prior Haskell experience* and to focus on libraries and tools that directly benefit the communtity. And our success rate was much higher. So: look for things that benefit the largest number of Haskell developers and users, and from students with proven Haskell development experience. You can't learn Haskell from zero on the job, during SoC. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
bulat.ziganshin: Hello Jamie, Wednesday, February 11, 2009, 5:54:09 AM, you wrote: Seems like it is ok to write H.264 in Haskell and released via GPL license? anyway it's impossible due to slow code generated by ghc Been a long time since you did high perf code -- we routinely now write code that previously was considered not feasible. However, I would say it needs an optimisation expert, yes, in any language. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Wed, Feb 11, 2009 at 12:27 PM, Don Stewart d...@galois.com wrote: gwern0: (The following is a quasi essay/list of past Summer of Code projects; my hope is to guide thinking about what Summer of Code projects would be good to pick, and more specifically what should be avoided. If you're in a hurry, my conclusions are at the bottom. The whole thing is written in Markdown; for best results pass it through Pandoc or view it via your friendly local Gitit wiki.) Thanks for the write up! We explicitly pushed harder in 2008 to clarify and simplify the goals of the projects, ensure adequate *prior Haskell experience* and to focus on libraries and tools that directly benefit the communtity. Oh, I didn't know that about prior experience. (I was tired enough when I finished it that I decided to not look at the students involved - how much prior experience they had, and how involved they were in the Haskell community afterwards.) And our success rate was much higher. That certainly does seem to be true. Looking over the 2008 projects, I see 0 outright failures (compared to 2 in 2006), and only 1 or 2 which might turn out to be unsuccessful (the physics engine, and perhaps GMap or the GHC API improvements). So: look for things that benefit the largest number of Haskell developers and users, and from students with proven Haskell development experience. You can't learn Haskell from zero on the job, during SoC. -- Don Inexperience is a good criterion to add to the 3 I had in my conclusion, certainly. -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
2009/2/10 John Van Enk vane...@gmail.com: I'd like to see some good libgcrypt[1] bindings to complement our existing cryptography packages. /jve Here are the projects I favor (in no particular order): * I'd like to see the X-saiga parser library finished: http://hackage.haskell.org/trac/summer-of-code/ticket/1558 * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/. Perhaps the specific project could be making TortoiseDarcs not Windows specific? * Graphical reduction http://hackage.haskell.org/trac/summer-of-code/ticket/83 We already have some of it done in Lambdabot, but a full implementation would be very nice. * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). XMonad is one of the flagship applications of Haskell, and there are quite a few would-be users of compositing support who either go without or limp by with xcompmgr. * Haddock in general could use work (http://hackage.haskell.org/trac/summer-of-code/ticket/45). Everyone uses Haddock, sooner or later... * Sandboxed Haskell (http://hackage.haskell.org/trac/summer-of-code/ticket/1114). This is a personal wish of mine; safe code would certainly let me simplify mueval! -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Hi Gwern, On Wed, 11 Feb 2009, Gwern Branwen wrote: I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? I have no idea, I have not dig deeper into H.263 C source code but I guess it should be quite trivial as it is a black box with video frame input and output with several parameters for encoding and just frame in/out for decoding. That could be a seed to create Haskell library of video/audio codecs. One mentioned that C based ffmpeg library is buggy with memory leaks left and center (and probably right too :) Ouch! gwern Jamie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
bulat.ziganshin: Hello Don, Wednesday, February 11, 2009, 8:28:33 PM, you wrote: anyway it's impossible due to slow code generated by ghc Been a long time since you did high perf code -- we routinely now write code that previously was considered not feasible. which is still slower than C and need more time to write However, I would say it needs an optimisation expert, yes, in any language. there are experts, includingyou, in making haskell specific code as fast as possible, but i don't know anyone using haskell to write high-performance code. so you ask for non-existing specialists We're doing it at Galois regularly. Check out the blog. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Wed, Feb 11, 2009 at 21:00, Jamie hask...@datakids.org wrote: Hi Gwern, On Wed, 11 Feb 2009, Gwern Branwen wrote: I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? I have no idea, I have not dig deeper into H.263 C source code but I guess it should be quite trivial as it is a black box with video frame input and output with several parameters for encoding and just frame in/out for decoding. I didn't dig into the source code either, but I've just skimmed through Wikipedia page on that codec: http://en.wikipedia.org/wiki/H.263 and in seems far from trivial. Anything that has 23 annexes is likely to be quite complex :-) Therefore I seriously doubt chances for success of such project. I did some checks: in libavcodec at least following files consist of implementation of H.263: h263.c h263data.h h263dec.c h263.h h263_parser.c h263_parser.h How many lines are there? [te...@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46217 2032 h263.h 91282 2361 h263_parser.c 29165 1047 h263_parser.h 7591 24232 261470 razem In Haskell project one would also need to provide some additional utility code which is part of libavcodec. Fast grep shows the tip of an iceberg: [te...@laptener libavcodec]$ grep include h263* | grep -v h263.c:#include dsputil.h h263.c:#include avcodec.h h263.c:#include mpegvideo.h h263.c:#include h263data.h h263.c:#include mpeg4data.h h263.c:#include mathops.h h263data.h:#include mpegvideo.h h263dec.c:#include avcodec.h h263dec.c:#include dsputil.h h263dec.c:#include mpegvideo.h h263dec.c:#include h263_parser.h h263dec.c:#include mpeg4video_parser.h h263dec.c:#include msmpeg4.h h263.h:#include config.h h263.h:#include msmpeg4.h h263_parser.c:#include parser.h h263_parser.h:#include parser.h Bottom line: I don't think it is reasonable to assume anyone without previous knowledge of H.263 is able to fit that project into one summer. But! It's Haskell community, and people here see the impossible happen from time to time ;-) All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Thanks for the analysis, this clarifies things greatly. Feasibility and scope is a big part of how we determine what projects to work on. gtener: On Wed, Feb 11, 2009 at 21:00, Jamie hask...@datakids.org wrote: Hi Gwern, On Wed, 11 Feb 2009, Gwern Branwen wrote: I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? I have no idea, I have not dig deeper into H.263 C source code but I guess it should be quite trivial as it is a black box with video frame input and output with several parameters for encoding and just frame in/out for decoding. I didn't dig into the source code either, but I've just skimmed through Wikipedia page on that codec: http://en.wikipedia.org/wiki/H.263 and in seems far from trivial. Anything that has 23 annexes is likely to be quite complex :-) Therefore I seriously doubt chances for success of such project. I did some checks: in libavcodec at least following files consist of implementation of H.263: h263.c h263data.h h263dec.c h263.h h263_parser.c h263_parser.h How many lines are there? [te...@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46217 2032 h263.h 91282 2361 h263_parser.c 29165 1047 h263_parser.h 7591 24232 261470 razem In Haskell project one would also need to provide some additional utility code which is part of libavcodec. Fast grep shows the tip of an iceberg: [te...@laptener libavcodec]$ grep include h263* | grep -v h263.c:#include dsputil.h h263.c:#include avcodec.h h263.c:#include mpegvideo.h h263.c:#include h263data.h h263.c:#include mpeg4data.h h263.c:#include mathops.h h263data.h:#include mpegvideo.h h263dec.c:#include avcodec.h h263dec.c:#include dsputil.h h263dec.c:#include mpegvideo.h h263dec.c:#include h263_parser.h h263dec.c:#include mpeg4video_parser.h h263dec.c:#include msmpeg4.h h263.h:#include config.h h263.h:#include msmpeg4.h h263_parser.c:#include parser.h h263_parser.h:#include parser.h Bottom line: I don't think it is reasonable to assume anyone without previous knowledge of H.263 is able to fit that project into one summer. But! It's Haskell community, and people here see the impossible happen from time to time ;-) All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Do we already have enough information to turn http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized package? I think Iteratees may prove themselves as useful as ByteStrings. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa felipe.le...@gmail.com wrote: Do we already have enough information to turn http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized package? I think Iteratees may prove themselves as useful as ByteStrings. I still haven't figured out what the correct definition of Iteratee would look like. The Iteratee code that Oleg wrote seems to have the structure of some kind of two level monad. I think that's the reason for the frequent occurrences of == and liftI in the code. There seems to be some things we yet have to discover about Iteratees. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
2009/2/12 Don Stewart d...@galois.com: Thanks for the analysis, this clarifies things greatly. Feasibility and scope is a big part of how we determine what projects to work on. I agree that it's beyond the scope of a SoC project. Rather than H.263 or H.264 I was going to suggest implementation of Theora or OMS, both of which avoid the patent issues and have publicly available specs: http://theora.org/doc/Theora.pdf http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf Scanning those documents should give anyone a fair idea of the amount of work involved. My understanding is that OMS is of a similar complexity to H.263, and H.264 is more complex than any of these. For Theora playback we've found that the largest CPU load comes from colorspace conversion, where the YUV output of the codec needs to be converted to RGB for some targets (like Firefox). That is some fairly straightforward array processing, and would be a good place to start for anyone trying to implement video codecs in Haskell. Conrad. gtener: On Wed, Feb 11, 2009 at 21:00, Jamie hask...@datakids.org wrote: Hi Gwern, On Wed, 11 Feb 2009, Gwern Branwen wrote: I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? I have no idea, I have not dig deeper into H.263 C source code but I guess it should be quite trivial as it is a black box with video frame input and output with several parameters for encoding and just frame in/out for decoding. I didn't dig into the source code either, but I've just skimmed through Wikipedia page on that codec: http://en.wikipedia.org/wiki/H.263 and in seems far from trivial. Anything that has 23 annexes is likely to be quite complex :-) Therefore I seriously doubt chances for success of such project. I did some checks: in libavcodec at least following files consist of implementation of H.263: h263.c h263data.h h263dec.c h263.h h263_parser.c h263_parser.h How many lines are there? [te...@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46217 2032 h263.h 91282 2361 h263_parser.c 29165 1047 h263_parser.h 7591 24232 261470 razem In Haskell project one would also need to provide some additional utility code which is part of libavcodec. Fast grep shows the tip of an iceberg: [te...@laptener libavcodec]$ grep include h263* | grep -v h263.c:#include dsputil.h h263.c:#include avcodec.h h263.c:#include mpegvideo.h h263.c:#include h263data.h h263.c:#include mpeg4data.h h263.c:#include mathops.h h263data.h:#include mpegvideo.h h263dec.c:#include avcodec.h h263dec.c:#include dsputil.h h263dec.c:#include mpegvideo.h h263dec.c:#include h263_parser.h h263dec.c:#include mpeg4video_parser.h h263dec.c:#include msmpeg4.h h263.h:#include config.h h263.h:#include msmpeg4.h h263_parser.c:#include parser.h h263_parser.h:#include parser.h Bottom line: I don't think it is reasonable to assume anyone without previous knowledge of H.263 is able to fit that project into one summer. But! It's Haskell community, and people here see the impossible happen from time to time ;-) All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: Here are the projects I favor (in no particular order): […] * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/. Perhaps the specific project could be making TortoiseDarcs not Windows specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don’t want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
SNMP would be really cool. So far the best implementation of SNMP I've had the pleasure to work with is part of the Erlang OTP distribution, and being able to compete with Erlang on that level would be really nice. On Tue, Feb 10, 2009 at 7:18 AM, Jamie hask...@datakids.org wrote: What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is getting very popular nowadays and it would be great to have encoder and decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) as a base to start with. Jamie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Tuesday 10 February 2009 07:18:00 am Jamie wrote: What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is getting very popular nowadays and it would be great to have encoder and decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) as a base to start with. Jamie GSoC is run out of the US, where software patents would prevent a student from taking this task. -- Conrad Meyer kon...@tylerc.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Tue, 10 Feb 2009, Conrad Meyer wrote: On Tuesday 10 February 2009 07:18:00 am Jamie wrote: What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is getting very popular nowadays and it would be great to have encoder and decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) as a base to start with. Jamie GSoC is run out of the US, where software patents would prevent a student from taking this task. via http://www.videolan.org/developers/x264.html x264 is a free library for encoding H264/AVC video streams. The code is written from scratch by Laurent Aimar, Loren Merritt, Eric Petit (OS X), Min Chen (vfw/asm), Justin Clay (vfw), Måns Rullgård, Radek Czyz, Christian Heine (asm), Alex Izvorski, and Alex Wright. It is released under the terms of the GPL license. Seems like it is ok to write H.264 in Haskell and released via GPL license? There is theora.org but H.264 would be ideal. Ditto for H.263. Conrad Meyer kon...@tylerc.org Jamie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
2009/2/10 Jamie hask...@datakids.org: On Tue, 10 Feb 2009, Conrad Meyer wrote: On Tuesday 10 February 2009 07:18:00 am Jamie wrote: What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is getting very popular nowadays and it would be great to have encoder and decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) as a base to start with. Jamie GSoC is run out of the US, where software patents would prevent a student from taking this task. via http://www.videolan.org/developers/x264.html x264 is a free library for encoding H264/AVC video streams. The code is written from scratch by Laurent Aimar, Loren Merritt, Eric Petit (OS X), Min Chen (vfw/asm), Justin Clay (vfw), Måns Rullgård, Radek Czyz, Christian Heine (asm), Alex Izvorski, and Alex Wright. It is released under the terms of the GPL license. Seems like it is ok to write H.264 in Haskell and released via GPL license? There is theora.org but H.264 would be ideal. Ditto for H.263. Conrad Meyer kon...@tylerc.org Jamie Software patent issues are entirely orthogonal to the copyright issues of who wrote what under which license. That's why software patents suck so very hard. See https://secure.wikimedia.org/wikipedia/en/wiki/Software_patent#Free_and_open_source_software https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_software -- gwern signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
(The following is a quasi essay/list of past Summer of Code projects;
my hope is to guide thinking about what Summer of Code projects would
be good to pick, and more specifically what should be avoided.
If you're in a hurry, my conclusions are at the bottom.
The whole thing is written in Markdown; for best results pass it
through Pandoc or view it via your friendly local Gitit wiki.)
# Summer of Code
As part of Google's [Summer of
code](http://en.wikipedia.org/wiki/Google_Summer_of_Code)[](http://code.google.com/soc/)
program, Google sponsors 5-10 [projects for
Haskell](http://hackage.haskell.org/trac/summer-of-code/).
The Haskell Summer of Codes have often produced excellent results, but
how excellent is excellent? Are there any features or commonalities
between successful projects or unsuccessful ones?
(This questions are particularly important as SoC 2009 isn't too far
away; yet we don't have even a general sense of where we are.)
## Example retrospective: Debian
An energetic blogger Debian developer has produced
[a](http://www.milliways.fr/2009/01/20/debian-2008-where-now-1/)
[three](http://www.milliways.fr/2009/01/28/debian-2008-where-now-2/)
[part](http://www.milliways.fr/2009/02/02/debian-2008-where-now-3/)
series on the many Debian-related Summer of Code projects.
The results are interesting: some projects were a failure and the
relevant student drifted away and had little to do with Debian again;
and some were great successes. I don't discern any particular lessons
there, except perhaps one against hubris or filling unclear needs.
Let's see whether that holds true of Haskell.
### Haskell retrospective
Haskell wasn't part of the first Summer of Code in 2005, but it was
accepted for 2006. We start there.
2006
The 2006 [homepage](http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2006)
lists the following projects:
- Fast Mutable Collection Types for Haskell
Caio Marcelo de Oliveira Filho, mentored by Audrey Tang
This ultimately resulted in the
[HsJudy](http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsJudy)
library ('fast mutable collection' here meaning 'array'; see the
[application](http://darcs.haskell.org/judy/SOC_APP.txt)). HsJudy was
apparently used in Pugs at one time, but no more. Thus, I judge this
to have been **unsuccessful**.
- Port Haddock to use GHC
David Waern, mentored by Simon Marlow
**Successful**. Haddock has used the GHC API ever since.[^complaints]
- A model for client-side scripts with HSP
Joel Björnson, mentored by Niklas Broberg
Was initially unsuccessful, but seems to've been picked up again.
So I give this a tentative **successful**
- GHCi based debugger for Haskell
José Iborra López, mentored by David Himmelstrup
**Successful**. The GHCi debugger was accepted into GHC HEAD, and
by now is in production use,
- HaskellNet
Jun Mukai, mentored by Shae Erisson
**Unsuccessful**. HaskellNet is dead, and nothing of it has
propagated elsewhere. (I'm not entirely sure what happened with the
HaskellNet code - I know of
[two](http://darcs.haskell.org/SoC/haskellnet/)
[repos](http://stuff.mit.edu/afs/sipb/project/suez/src/haskell/haskellnet/),
but that's about it.) Shae tells me that this poor uptake is probably
due to a lack of advertising, and not any actual defect in the
HaskellNet code.
- Language.C - a C parser written in Haskell
Marc van Woerkom, mentored by Manuel Chakravarty
**Failure**. According to [Don Stewart's
outline](http://www.haskell.org/pipermail/haskell-cafe/2007-February/022509.html)
of the 2006 SoC, this project was not completed.
- Implement a better type checker for Yhc
Leon P Smith, mentored by Malcolm Wallace
**Failure**. See Language.C
- Thin out cabal-get and integrate in GHC
Paolo Martini, mentored by Isaac Jones
**Successful**. Code is in Cabal, which we all know and love.
- Unicode ByteString, Data.Rope, Parsec for generic strings
Spencer Janssen, mentored by Don Stewart
**Successful**. (Again, per Don.)
4 successful; 2 unsuccessful; and 2 failures.
2007
The [2007 homepage](http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2007)
- Darcs conflict handling
Jason Dagit, mentored by David Roundy
**Successful**. The work was successful in almost completely
getting rid of the exponential conflict bug, and has been in the
regular releases of Darcs 2.x for some time now.
- Automated building of packages and generation of Haddock documentation
Sascha Böhme, mentored by Ross Paterson
**Successful**. The auto build and doc generation are
long-standing and very useful parts of Hackage.
- Rewrite the typechecker for YHC and nhc98
Mathieu Boespflug, mentored by Malcolm Wallace
Unknown.
- Cabal Configurations
Thomas Schilling, mentored by Michael Isaac Jones
**Successful**. Cabal configurations have been around for a while
and are very useful for enabling/disabling things
- Update
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Tue, Feb 10, 2009 at 6:26 AM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: Gentle Haskellers, The Google Summer of Code will be running again this year. Once again, haskell.org has the opportunity to bid to become a mentoring organisation. (Although, as always, there is no guarantee of acceptance.) If you have ideas for student projects that you think would benefit the Haskell community, now is the time to start discussing them on mailing lists of your choice. 1. Binding for FireBird RDBMS. 2. Library for manipulate ODF. 3. Binding to OOo UNO. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
