Re: [Haskell] Google Summer of Code 2009

newer
Is using Data.Dynamic considered a...

older
Re: Type families not as useful...

Jamie

10 Feb 2009 10 Feb '09

10:18 a.m.

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

Show replies by date

David Leimbach

10 Feb 10 Feb

10:53 a.m.

New subject: [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 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

John Van Enk

4:08 p.m.

New subject: [Haskell] Google Summer of Code 2009

I'd like to see some good libgcrypt[1] bindings to complement our existing cryptography packages. /jve [1] http://www.gnupg.org/documentation/manuals/gcrypt/ On Tue, Feb 10, 2009 at 10:18 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Gwern Branwen

11 Feb 11 Feb

2:45 p.m.

New subject: [Haskell] Google Summer of Code 2009

2009/2/10 John Van Enk :

...

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

Wolfgang Jeltsch

12 Feb 12 Feb

2:52 a.m.

New subject: [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

Matthew Elder

3:16 a.m.

New subject: [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 < g9ks157k@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

Felipe Lessa

4:30 a.m.

New subject: [Haskell] Google Summer of Code 2009

2009/2/12 Matthew Elder :

...

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.

wren ng thornton

2:22 p.m.

New subject: [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 :

...
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

Sterling Clover

11:56 p.m.

New subject: [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 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

Malcolm Wallace

5:36 a.m.

New subject: [Haskell] Google Summer of Code 2009

Gwern Branwen 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

Krzysztof Skrzętnicki

7:12 a.m.

New subject: [Haskell] Google Summer of Code 2009

On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace wrote:

...

Gwern Branwen 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

Don Stewart

10:48 a.m.

New subject: [Haskell] Google Summer of Code 2009

gtener:

...

On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace wrote:

...
Gwern Branwen 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

Don Stewart

10:34 a.m.

New subject: [Haskell] Google Summer of Code 2009

Malcolm.Wallace:

...

Gwern Branwen 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

Conrad Meyer

10 Feb 10 Feb

5:49 p.m.

New subject: [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

Jamie

9:54 p.m.

New subject: [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 >

Jamie

Gwern Branwen

10:01 p.m.

New subject: [Haskell] Google Summer of Code 2009

2009/2/10 Jamie :

...

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 >

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... & https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_sof... -- gwern

Gwern Branwen

11:35 p.m.

New subject: [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 the Hat tracer Kenn Knowles, mentored by Malcolm Wallace **Unsuccessful**. The update apparently happened, since the [Hat homepage](http://www.haskell.org/hat/) says "Version 2.06 released 2nd Oct 2008", but it is [described](http://www.haskell.org/hat/download.html) as unmaintained, and I can't seem to find any examples of people actually using Hat. - Generalizing Parsec to ParsecT and arbitrary input (ByteStrings) Paolo Martini, mentored by Philippa Jane Cowderoy **Success**. But a mixed one – I understand the performance is terrible so few people use it. - Shared Libraries for GHC Clemens Fruhwirth, mentored by Simon Marlow **Unsuccessful**. The situation is unclear to me, but I know that for some period dynamic linking worked for some platforms. However, it's 2009 and I still have static linking; so I'm going to chalk this one up as existing but not in use. - "Libcurl" Mieczysław Bąk, mentored by Bryan O'Sullivan **Success**. Libcurl does exist and has been used, and is maintained. I understand it has been used, even if I personally don't know of any examples. - "Extending GuiHaskell: An IDE for Haskell Hackers" Asumu Takikawa, mentored by Neil David Mitchell **Failure**. GuiHaskell does not exist in any usable form. (The homepage summarizes the situation thusly: ["**Warning**: This project is fragile, unfinished, and I do not recommend that anyone tries using it."](http://www-users.cs.york.ac.uk/~ndm/guihaskell/)) 4 successes; 2 unsuccessful; 1 failure, and 1 unknown. ##### See also - [The Monad.Reader's](http://haskell.org/haskellwiki/The_Monad_Reader) [issue 9](http://haskell.org/sitewiki/images/5/5d/TMR-Issue9.pdf) covers SoC projects - http://www.serpentine.com/blog/2007/04/12/haskellorg-and-googles-summer-of-c... #### 2008 The [2008 homepage](http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008) isn't so kind enough as to list all the projects as before, but it does tell us that only 7 projects were accepted by Google. So we can work from the [code.google.com](http://code.google.com/p/google-summer-of-code-2008-haskell/downloads/list) page which lists 6: - "C99 Parser/Pretty-Printer" by Benedikt Huber, mentored by Iavor Diatchki **Success**. The first try failed, but the second won through, and now people are doing things like [parsing the Linux kernel](http://www.galois.com/blog/2008/09/17/parsing-the-linux-kernel-with-haskell-...) with it. - "GMap - Fast composable maps" by Jamie Brandon **Successful**. GMap is on [Hackage](http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gmap), and I believe I've seen it used. - "Haskell API Search" Neil Mitchell **Successful**. The improved performance and search capability have made it into Hoogle releases. - "Cabal 'make-like' dependency framework" Andrea Vezzosi **Successful**? (I don't actually know, but this probably made it into Cabal.) - "GHC plugins" Maximilian Conroy Bolingbroke **Successful**? - "Data parallel physics engine" Roman Cheplyaka **Unsuccessful**? It seems to be finished but no use made of the actual engine (that I can see mentioned on the [engine's blog](http://physics-dph.blogspot.com/)). - "GHC API". Thomas Schilling According to the [Haskell Weekly News](http://sequence.complete.org/hwn/20080702):

...

"Thomas Schilling (nominolo) is working on improvements to the GHC API. Officials at HWN headquarters have released a statement reversing their previous position regarding the existence of Thomas, citing regrettably faulty information to explain their previous misapprehensions. Expect to hear more from Thomas soon, now that he has finished graduating and moving."

5 successful, 1 unsuccessful, 1 unknown. (These assessments are the most untrustworthy of all, since relatively little time has passed; it's much easier to see whether 2006 projects have had a lasting effect than these 2008 projects.) ##### See also - The Monad.Reader's [Issue 12](http://haskell.org/sitewiki/images/f/f0/TMR-Issue12.pdf) #### 2009 Yet to come.. The student apps are due during 23 March – 3 April. Look forward to it! #### Haskell roundup So, what lessons can we learn from the 3 SoCs? It seems to me like there are roughly 3 groups explanations of unsuccess or failure fall into. They are: 1) _Hubris_. GuiHaskell is probably a good example; it is essentially a bare-bones IDE, from its description. It is expecting a bit much of a single student in a single summer to write *that*! 2) _Unclear use_. HsJudy is my example here. There are already so many arrays and array types in Haskell! What does HsJudy bring to the table that justifies a FFI dependency? Who's going to use it? Pugs initially did apparently, but perhaps that's just because it was there - when I looked at Pugs/HsJudy in 2007, certainly Pugs had no need of it. (The data parallel physics engine is probably another good example. Is it just a benchmark for the GHC developers? Is it intended for actual games? If the former, why is it a SoC project, and if the latter, isn't that a little hubristic?) 3) _Lack of propaganda_. One of the reasons Don Stewart's bytestring library is so great is his relentless evangelizing of their benefits, which convinces people to actually take the effort to learn and use them, and eventually by network effects the whole Haskell community is affected & improved. Some of these SoC projects suffer from a distinct lack of community buy-in - who used HaskellNet? Who used Hat when it was updated? Indifference can be fatal, and can defeat the point of a project. What good is a library that no one uses? These aren't academic research projects which accomplish their task just by existing, after all. They're supposed to be useful to real Haskellers. [^complaints]: I can hear the wankers in the peanut gallery - "Yeah, and it's been buggy ever since!" Hush you. -- gwern

David Waern

11 Feb 11 Feb

5:40 a.m.

New subject: [Haskell] Google Summer of Code 2009

2009/2/11 Gwern Branwen :

...

[^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

Don Stewart

12:27 p.m.

New subject: [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

Gwern Branwen

12:49 p.m.

New subject: [Haskell] Google Summer of Code 2009

On Wed, Feb 11, 2009 at 12:27 PM, Don Stewart 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

Jamie

10 a.m.

New subject: [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... & https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_sof...

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

Gwern Branwen

10:12 a.m.

New subject: [Haskell] Google Summer of Code 2009

On Wed, Feb 11, 2009 at 10:00 AM, Jamie 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... & https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_sof...

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_Discrimina... ). 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

Jamie

3 p.m.

New subject: [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

Krzysztof Skrzętnicki

6:19 p.m.

New subject: [Haskell] Google Summer of Code 2009

On Wed, Feb 11, 2009 at 21:00, Jamie 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? [Tener@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46 217 2032 h263.h 91 282 2361 h263_parser.c 29 165 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: [Tener@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

Don Stewart

6:31 p.m.

New subject: [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 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?

[Tener@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46 217 2032 h263.h 91 282 2361 h263_parser.c 29 165 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:

[Tener@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

Conrad Parker

9:06 p.m.

New subject: [Haskell] Google Summer of Code 2009

2009/2/12 Don Stewart :

...

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 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?

[Tener@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46 217 2032 h263.h 91 282 2361 h263_parser.c 29 165 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:

[Tener@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

Jamie

12 Feb 12 Feb

7:45 a.m.

New subject: [Haskell] Google Summer of Code 2009

On Thu, 12 Feb 2009, Conrad Parker wrote:

...

2009/2/12 Don Stewart :

...
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 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?

[Tener@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46 217 2032 h263.h 91 282 2361 h263_parser.c 29 165 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:

[Tener@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

Achim Schneider

9:23 a.m.

New subject: [Haskell] Google Summer of Code 2009

Jamie wrote:

...

On Thu, 12 Feb 2009, Conrad Parker wrote:

...
2009/2/12 Don Stewart :

...
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 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. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Jamie

1:19 p.m.

New subject: [Haskell] Google Summer of Code 2009

On Thu, 12 Feb 2009, Achim Schneider wrote:

...

Jamie 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

Bulat Ziganshin

11 Feb 11 Feb

4:40 a.m.

New subject: Re[2]: Re: [Haskell] Google Summer of Code 2009

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 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jamie

9:06 a.m.

New subject: Re[2]: Re: [Haskell] Google Summer of Code 2009

Hi Bulat, On Wed, 11 Feb 2009, Bulat Ziganshin wrote:

...

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

I see, I guess I'll have to stuck with C version of H.264 in my Haskell programs. Maybe in future when ghc have better optimizations. At least one can write various subset of H.323 standard in Haskell as the only part of H.323 subset that is CPU intensive is video/audio codecs, the rest is just mainly network I/O code. http://www.h323plus.org/standards/

...

Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jamie

C.M.Brown

10:34 a.m.

New subject: Re[2]: Re: [Haskell] Google Summer of Code 2009

Hi Jamie, As a side note - I'd be very interested to see a Haskell implementation of H264 decoding. I'm currently having to use the ffmpeg library in C, and it's notoriously buggy with memory leaks left right and centre. A haskell solution would be very much welcome! Regards, Chris. On Wed, 11 Feb 2009, Jamie wrote:

...

Hi Bulat,

On Wed, 11 Feb 2009, Bulat Ziganshin wrote:

...
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

I see, I guess I'll have to stuck with C version of H.264 in my Haskell programs. Maybe in future when ghc have better optimizations.

At least one can write various subset of H.323 standard in Haskell as the only part of H.323 subset that is CPU intensive is video/audio codecs, the rest is just mainly network I/O code. http://www.h323plus.org/standards/

...
Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jamie _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Sebastian Sylvan

10:05 a.m.

New subject: Re[2]: Re: [Haskell] Google Summer of Code 2009

On Wed, Feb 11, 2009 at 9:40 AM, Bulat Ziganshin wrote:

...

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

Impossible? Really? How does performance relate to it being possible to write? I would be surprised if it was indeed impossible to get something that runs fine one *some* machine. It may be difficult to beat C, but that doesn't mean it's impossible to write something useful. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

Don Stewart

12:28 p.m.

New subject: [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

Bulat Ziganshin

2:53 p.m.

New subject: Re[2]: Re: [Haskell] Google Summer of Code 2009

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 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Don Stewart

3:58 p.m.

New subject: [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

Bulat Ziganshin

4:21 p.m.

New subject: Re[2]: Re: [Haskell] Google Summer of Code 2009

Hello Don, Wednesday, February 11, 2009, 11:58:13 PM, you wrote:

...

...
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.

i scanned through http://www.galois.com/blog/category/haskell/ and don't found anything about this. probably we mean different things - i'm saying about implementation of cpu-intensive algorithms like deflate, md5 or mpeg for crypto-algos we have haskell library and afair it was 3-10 times slower than C equivalents and probably harder to write too? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Achim Schneider

1:25 p.m.

New subject: [Haskell] Google Summer of Code 2009

Bulat Ziganshin wrote:

...

impossible

impossible, adj: 1) admittance of loosing an argument 2) tease to make someone do something -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Alexandr N. Zamaraev

12:47 a.m.

New subject: [Haskell] Google Summer of Code 2009

On Tue, Feb 10, 2009 at 6:26 AM, Malcolm Wallace
 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.

5943

Age (days ago)

5946

Last active (days ago)

List overview

Download

38 comments

20 participants

participants (20)

Achim Schneider
Alexandr N. Zamaraev
Bulat Ziganshin
C.M.Brown
Conrad Meyer
Conrad Parker
David Leimbach
David Waern
Don Stewart
Felipe Lessa
Gwern Branwen
Jamie
John Van Enk
Krzysztof Skrzętnicki
Malcolm Wallace
Matthew Elder
Sebastian Sylvan
Sterling Clover
Wolfgang Jeltsch
wren ng thornton