Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Tue, Mar 10, 2009 at 11:19 AM, Malcolm Wallace 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
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
> > 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: * To look after students and their projects if/when they are accepted. If you have suggested, or feel strongly about, or have experience relevant to a particular project (currently on the trac[1], or reddit[2] - if not, then add it!), please consider volunteering to mentor it. This requires a commitment of maybe up to five hours a week (but often less) during the student coding phase (23rd May - 17th Aug). Having multiple mentors for a single project area is no problem - it just means more backup for students. * To review and rank student proposals. This requires a commitment of several hours across the review period (roughly 23rd March - 15th April), and also some enthusiasm for generally promoting projects that will benefit the Haskell community as a whole. The reviewers include all those who are willing to look after students for the summer. Of course there is no guarantee that your project will actually get student participation, but if you don't play at this stage, you definitely won't get one! Regards, Malcolm [1] http://hackage.haskell.org/trac/summer-of-code/ [2] http://www.reddit.com/r/haskell_proposals/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Tue, Feb 10, 2009 at 3:26 PM, 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. We especially encourage students to communicate > with the wider community: if you keep your ideas private, you have a > much worse chance of acceptance than if you develop ideas in > collaboration with those who will be your "customers", end-users, or > fellow-developers. This is the open-source world! > > The timeline is that Haskell.org will apply for GSoC membership between > 9-13 March, and if we are successful, students can submit applications > between 23 March - 3 April. Google is now accepting applications: http://google-opensource.blogspot.com/2009/03/google-summer-of-code-applications-now.html ___ 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 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
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
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 Here is an idea that if done right might bootstrap Haskell real world applications with the help of greed and adrenaline:-) The ignition: (0) Bind Haskell to an automatic trading platform [API] (1) write real-time streamer and stock scanner. [PType] should offer more than was demonstrated in [F#] (2) Join [apps] from any angle (3) Consider a [DSL] for data analysis or write an [EasyLanguage] [API] http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc [F#] http://channel9.msdn.com/pdc2008/TL11/ [PType] http://research.nii.ac.jp/~hu/pub/aplas04-xu.pdf [apps] http://www.interactivebrokers.com/en/general/poll/ibconsultants.php?accept_disclaimer=T&ib_entity=llc [DSL] http://www.cc.gatech.edu/~saswat/research/one.pdf [EasyLanguage] https://www.tradestation.com/support/books/pdf/EL_Essentials.pdf https://www.tradestation.com/support/books/pdf/EL_FunctionsAndReservedWords_Ref.pdf ___ 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 : > 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
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 ___ 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 > 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 ___ 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 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
[Haskell-cafe] Re: [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. ___ 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 : 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? [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
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 ___ 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 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
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. ___ 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
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
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? >> >> [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
On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa 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
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
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Hi all, On Tue, Feb 10, 2009 at 3:26 PM, Malcolm Wallace wrote: > 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. We especially encourage students to communicate > with the wider community (...) I have a project that I've tinkered with doing for a while, but have never actually gotten around to, and I'm wondering whether there would be interest from the community in using it. Actually, two related projects: (1) A library for working with hashable data structures, including a hashable finger tree with sequence, map and set types based on it. Surprisingly, there does not seem to be much library support for working with hashes in Haskell beyond the bare-bones, imperative Data.HashTable, even though pure functional programming and hashes Go Well Together. I'm pulling these bounds out of my intuition, but hashable collections should give amortized O(1) comparison for equality and amortized O(log n) comparison for order, and you could use them as set values and map keys without efficiency blowing up in your face. The library should probably also include support for hashtables based on the various kinds of pure and monad-encapsulated arrays we have in Haskell, and maybe include support for interning values; unsafePerformIO, weak references and friends were originally introduced with the intention to support interned values in a way that programmers can tailor to their own needs, but it would be nice to have some default library support. (2) Based on this, a serialization library that would recognize if it has already written a particular value from memory to the same file, and write a pointer to the first occurrence of that value instead of serializing the actual value again, making it efficient to serialize versioned data structures. The idea is to make something similar to HAppS' MACID, but where MACID serializes the different kinds of updates that you can do for your data, this library would simply do the update in memory, then serialize the whole updated value to disk, but actually *writing* only the *new* parts of the data structure. (I think this could be simpler to use, and would be in a sense more elegant and 'haskelly' than the MACID approach. On the other hand, we already *have* MACID.) So, anybody out there who looks at these things and thinks "this could be useful"? :-) Thanks, - Benja ___ 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 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
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? [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[2]: [Haskell-cafe] 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, Bulatmailto:bulat.zigans...@gmail.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
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[2]: [Haskell-cafe] 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, Bulatmailto:bulat.zigans...@gmail.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
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
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [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. ___ 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 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
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
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[2]: [Haskell-cafe] 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, > > Bulatmailto:bulat.zigans...@gmail.com > > 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 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_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: Re[2]: [Haskell-cafe] 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 ___ 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[2]: [Haskell-cafe] 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, Bulatmailto:bulat.zigans...@gmail.com 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/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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] 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, Bulatmailto:bulat.zigans...@gmail.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
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. ___ 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/
Re: [Haskell-cafe] Re: [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_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
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___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
I would love a mentor to help me with a Haskell binding to libnova. This is part of a larger project I have in mind, but the libnova binding seems like the first step. I don't expect this to be picked as an official GSoC, but this seemed like a good time to look for a mentor for this project. Michael Litchard 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. We especially encourage students to communicate > with the wider community: if you keep your ideas private, you have a > much worse chance of acceptance than if you develop ideas in > collaboration with those who will be your "customers", end-users, or > fellow-developers. This is the open-source world! > > The timeline is that Haskell.org will apply for GSoC membership between > 9-13 March, and if we are successful, students can submit applications > between 23 March - 3 April. > > If you wish to help publicise GSoC amongst students, there are official > posters/fliers available (not specific to haskell.org): > >http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers > > Regards, >Malcolm > ___ > Haskell mailing list > hask...@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ 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 ___ 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
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 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Malcolm.Wallace: > 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. We especially encourage students to communicate > with the wider community: if you keep your ideas private, you have a > much worse chance of acceptance than if you develop ideas in > collaboration with those who will be your "customers", end-users, or > fellow-developers. This is the open-source world! > And I'll just note that since December we've been running a proposal submission site here, where you can vote and comment on ideas, http://www.reddit.com/r/haskell_proposals/top/ A great place to suggest ideas! -- 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
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 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
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
