[haskell.org Google Summer of Code 2013] Approved Projects

We've worked our way through the project approval process for another year. This year we accepted 9 projects for haskell.org in general and are hosting 2 additional projects for darcs as an umbrella organization. haskell.org: * Parallelise 'cabal build' by Mikhail Glushenkov, mentored by Johan Tibell * Extending GHC to support building modules in parallel by Patrick Palka, mentored by Thomas Schilling * Communicating with mobile devices by Marcos Pividori, mentored by Michael Snoyman * Improve Haddock Markup and Capabilities by Fūzetsu, mentored by Simon Hengel * Haskell Qt Binding Generator by Zhengliang Feng, mentored by Carter Schonwald with help from Ian-Woo Kim * Improve the feedback of the cabal-install dependency solver by Martin Ruderer, mentored by Andres Löh * Interactive-diagrams and a paste site with the ability for dynamic rendering of diagrams by Dan Frumin, mentored by Luite Stegeman * Overloaded record fields for GHC by Adam Gundry, mentored by Simon Peyton-Jones * Port Charts to use Diagrams by Jan Bracker, mentored by Tim Docker darcs: * Better record command for darcs by José Neder, mentored by Gillaume Hoffmann * Enhancing Darcsden by BSRK Aditya, mentored by Ganesh Sittampalam Students have from now through Jun 16th to get up to speed and get to know their mentors. And while the summer of code officially starts on Jun 17th, keep in mind that the mid-term evaluations aren't that much farther behind, starting July 29th, so you'll want to hit the ground running. If you put in a project proposal and it wasn't accepted and/or you would like feedback, please feel free to email me or contact me on the #haskell-gsoc channel on irc.freenode.net. We received more proposals than slots this year, and so we were forced to make a few hard decisions. Shachaf Ben-Kiki is helping out as this year's backup administrator and he should also be able to help out with administrivia or questions as well. I'd like to thank everyone for participating in the selection process and I think we can look forward to another excellent summer of code! Edward Kmett haskell.org Google Summer of Code Administrator

Edward Kmett
* Haskell Qt Binding Generator by Zhengliang Feng, mentored by Carter Schonwald with help from Ian-Woo Kim
Interesting, as this has been done at least twice before. Is there a public write-up of what's going to be different this time?

There should be a link from the google-melange website, but one slight
shift in focus is on either getting SWIG bindings or possibly even using
Ian-Woo Kim's C++FFI tools. Carter may be able to go into more detail.
On Wed, May 29, 2013 at 6:46 AM, harry
Edward Kmett
writes: * Haskell Qt Binding Generator by Zhengliang Feng, mentored by Carter Schonwald with help from Ian-Woo Kim
Interesting, as this has been done at least twice before. Is there a public write-up of what's going to be different this time?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

This one caught my attention as well. I didn't see any contact information for the participants (I didn't look too hard, I admit), but I was wondering if they had considered basing their work off of Qt Smoke. The smoke project (http://techbase.kde.org/Development/Languages/Smoke) is used by a few other Qt bindings projects and provides some common infrastructure and already went through the trouble of parsing all of the headers in a qt-friendly way. I think smoke would have the advantage of sharing the burden with other language bindings (Ruby, C#, and perl, at least). Perhaps an argument could be made that requiring smoke might be painful, but I imagine it could be tossed into a cabal package fairly easily. I started playing with generating Qt bindings for Haskell with smoke if the GSoC project might find it useful: https://github.com/travitch/humidor On Wed, May 29, 2013 at 11:51:57AM -0400, Edward Kmett wrote:
There should be a link from the google-melange website, but one slight shift in focus is on either getting SWIG bindings or possibly even using Ian-Woo Kim's C++FFI tools. Carter may be able to go into more detail.
On Wed, May 29, 2013 at 6:46 AM, harry
wrote: Edward Kmett
writes: * Haskell Qt Binding Generator by Zhengliang Feng, mentored by Carter Schonwald with help from Ian-Woo Kim
Interesting, as this has been done at least twice before. Is there a public write-up of what's going to be different this time?
_______________________________________________ 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

Edward Kmett
There should be a link from the google-melange website, but one slight shift in focus is on either getting SWIG bindings or possibly even using Ian-Woo Kim's C++FFI tools. Carter may be able to go into more detail.
There's almost no information in the google project abstract. My concern is that the problem isn't generating the bindings (as I've said, that's been done twice before). It's that Qt's slots-and-signals are horrible to use from the Haskell side. If the student hasn't already got a good idea of how to solve this, I fear that this project will be just generate another unusable set of bindings.

When submissions are put in, there is a way for mentors to talk to students
to ask for more details. Those don't show up in the published abstract you
can see at the end.
The discussion shifted towards focusing on getting things to a point where
Haskell can meaningfully use SWIG rather than on Qt per se but it is good
to keep such a concrete goal in mind when working on something as abstract
as SWIG.
I agree that Qt has a somewhat horrible API. =)
-Edward
On Wed, May 29, 2013 at 12:34 PM, harry
Edward Kmett
writes: There should be a link from the google-melange website, but one slight shift in focus is on either getting SWIG bindings or possibly even using Ian-Woo Kim's C++FFI tools. Carter may be able to go into more detail.
There's almost no information in the google project abstract. My concern is that the problem isn't generating the bindings (as I've said, that's been done twice before). It's that Qt's slots-and-signals are horrible to use from the Haskell side. If the student hasn't already got a good idea of how to solve this, I fear that this project will be just generate another unusable set of bindings.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

indeed, i'm the principal mentor for this project, though as mentioned
Ian-Woo will hopefully be helping out too.
I'm going to *help* focus the project on being a tool thats not focused on
QT, though if something nice can be worked out in that direction, great!
indeed, I suspect Edward, Ian-Woo and I will spend some small amount of
time at HackPhi trying to figure out some good avenues of attack to make
this a successful project that is used by the community and as actively
maintained.
cheers
-Carter
On Wed, May 29, 2013 at 12:55 PM, Edward Kmett
When submissions are put in, there is a way for mentors to talk to students to ask for more details. Those don't show up in the published abstract you can see at the end.
The discussion shifted towards focusing on getting things to a point where Haskell can meaningfully use SWIG rather than on Qt per se but it is good to keep such a concrete goal in mind when working on something as abstract as SWIG.
I agree that Qt has a somewhat horrible API. =)
-Edward
On Wed, May 29, 2013 at 12:34 PM, harry
wrote: Edward Kmett
writes: There should be a link from the google-melange website, but one slight shift in focus is on either getting SWIG bindings or possibly even using Ian-Woo Kim's C++FFI tools. Carter may be able to go into more detail.
There's almost no information in the google project abstract. My concern is that the problem isn't generating the bindings (as I've said, that's been done twice before). It's that Qt's slots-and-signals are horrible to use from the Haskell side. If the student hasn't already got a good idea of how to solve this, I fear that this project will be just generate another unusable set of bindings.
_______________________________________________ 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

On Wed, May 29, 2013 at 10:47 AM, Carter Schonwald
indeed, i'm the principal mentor for this project, though as mentioned Ian-Woo will hopefully be helping out too.
I'm going to *help* focus the project on being a tool thats not focused on QT, though if something nice can be worked out in that direction, great!
Are you folks aware of the work on this topic by Tristan Ravitch? https://github.com/travitch/foreign-inference Jason

Ooo. Thanks Jason.
That looks like a fleshed out version of the approach I was leaning towards
at least thinking about. I'll check it out when I have time in a few days.
On May 29, 2013 1:57 PM, "Jason Dagit"
On Wed, May 29, 2013 at 10:47 AM, Carter Schonwald
wrote: indeed, i'm the principal mentor for this project, though as mentioned Ian-Woo will hopefully be helping out too.
I'm going to *help* focus the project on being a tool thats not focused on QT, though if something nice can be worked out in that direction, great!
Are you folks aware of the work on this topic by Tristan Ravitch? https://github.com/travitch/foreign-inference
Jason
participants (5)
-
Carter Schonwald
-
Edward Kmett
-
harry
-
Jason Dagit
-
Tristan Ravitch