Haskell.org GSOC: Ticket Queryhttp://ghc.haskell.org/trac/summer-of-code/query?status=!closed&priority=OK&desc=1&order=priority
Haskell.org Google Summer of Codeen-USHaskell.org GSOC/images/summerlambda.pnghttp://ghc.haskell.org/trac/summer-of-code/query?status=!closed&priority=OK&desc=1&order=priority
Trac 1.0.7http://ghc.haskell.org/trac/summer-of-code/ticket/1111
http://ghc.haskell.org/trac/summer-of-code/ticket/1111#1111: Bring Hat tracing back to lifeFri, 09 Mar 2007 14:45:22 GMTmalcolm.wallace@…<p>
The <a class="ext-link" href="http://haskell.org/hat"><span class="icon">​</span>Hat</a> tracer for Haskell is a very powerful tool for debugging and comprehending programs. Sadly, it suffers from bit-rot. It was written largely before the Cabal library packaging system was developed. It is difficult to get any non-trivial program to work with Hat, if the program uses any pre-packaged libraries outside the haskell'98 standard.
</p>
<p>
The aims of this project would be
</p>
<blockquote>
<p>
(a) to fix Hat so that it adequately traces hierarchical library packages
</p>
</blockquote>
<blockquote>
<p>
(b) to integrate support for tracing into Cabal, so a user can simply ask for the 'tracing' version of a package in addition to the 'normal' and 'profiling' versions.
</p>
</blockquote>
<blockquote>
<p>
(c) to develop a "wrapping" scheme whereby the code inside libraries does not in fact need to be traced at all, but instead Hat would treat the library functions as abstract entities.
</p>
</blockquote>
<h2 id="InterestedMentors">Interested Mentors</h2>
<ul><li>Malcolm Wallace (@ cs.york.ac.uk)
</li></ul><h2 id="InterestedStudents">Interested Students</h2>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1111#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1114
http://ghc.haskell.org/trac/summer-of-code/ticket/1114#1114: Sandboxed HaskellSun, 11 Mar 2007 20:14:45 GMTbenja.fallenstein@…<p>
<a class="ext-link" href="http://www.cse.unsw.edu.au/~dons/hs-plugins/"><span class="icon">​</span>hs-plugins</a> can dynamically compile and load Haskell code, but does not prevent plugins from using unsafePerformIO or unsafeCoerce#. I would like to be able to use hs-plugins to execute untrusted code. As far as I can see, two pieces of infrastructure are missing:
</p>
<ul><li>A way to ensure that a dynamically compiled program does not use any unsafe primitives.
</li><li>A way to limit the resources (clock cycles and RAM) used by an untrusted computation.
</li></ul><p>
It seems to me that the best way to achieve the first goal is to make GHC keep track during compilation of which functions are safe (do not call unsafe primitives, or, I suppose, are declared to be safe by a pragma in a trusted library). However, I know only very little about GHC internals.
</p>
<p>
One project I want to use this for would be a web server that lets users create Haskell-based web applications without having to set up their own Unix account etc. If this project is accepted, I'll build a prototype of this that can be used to test "sandboxed haskell" (no matter whether the project ends up being assigned to me or somebody else).
</p>
<h2 id="InterestedMentors">Interested Mentors</h2>
<ul><li>?
</li></ul><h2 id="InterestedStudents">Interested Students</h2>
<ul><li>Benja Fallenstein (benja.fallenstein@…) -- I'm not familiar with the internals of GHC at this point, but I'm willing to learn. :-) A knowledgable mentor would be good if I end up doing this project.
</li><li>Brandon Wilson (xelxebar) &lt;[bmw.stx@…]&gt;
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1114#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1116
http://ghc.haskell.org/trac/summer-of-code/ticket/1116#1116: Haskell Qt binding generatorMon, 12 Mar 2007 16:44:32 GMTWolfgang Jeltsch <g9ks157k@…><p>
The task is to write a program which generates a Haskell binding to the Qt library or parts of it. The program shall do the generation fully automatically, using the Qt header files or similar data as its input.
</p>
<h2 id="InterestedStudents">Interested Students</h2>
<ul><li>(2007) Soenke Hahn &lt;shahn@…&gt;
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1116#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1120
http://ghc.haskell.org/trac/summer-of-code/ticket/1120#1120: XML Schema implementationFri, 16 Mar 2007 17:05:23 GMTeq<p>
XML Schema(<a class="ext-link" href="http://en.wikipedia.org/wiki/XML_Schema"><span class="icon">​</span>http://en.wikipedia.org/wiki/XML_Schema</a>) is a format to define the structure of XML documents(like DTD, but more expressive). Since it's recommended by the W3C, many XML standards use it to specify their format. Some XML technologies, like WSDL(<a class="ext-link" href="http://en.wikipedia.org/wiki/WSDL"><span class="icon">​</span>http://en.wikipedia.org/wiki/WSDL</a>) use it to define new data structures.
</p>
<p>
This makes XML Schema a door-opener for the implementation of other XML technologies like SOAP.
The project could include the following:
</p>
<ul><li>Implementing a XML Schema parser(using for example HaXML)
</li><li>Building a tool for XML Schema -&gt; Haskell code transformation(like the DtdToHaskell tool included in HaXML)
</li><li>Creating a verifier that checks if a document conforms to a XML Schema
</li></ul><h2 id="InterestedMentors">Interested Mentors</h2>
<p>
Malcolm Wallace
</p>
<h2 id="InterestedStudents">Interested Students</h2>
<p>
Vlad Dogaru &lt;ddvlad*REMOVETHIS*@…&gt;
</p>
<p>
Saurabh Kumar &lt;saurabh.catch@…&gt;
</p>
<p>
Marius Loewe &lt;mlo@…&gt;
</p>
<p>
David McGillicuddy &lt;dmcgill9071@…&gt;
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1120#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1127
http://ghc.haskell.org/trac/summer-of-code/ticket/1127#1127: Machine learning libraryTue, 20 Mar 2007 22:11:50 GMTKetilMalde<p>
<strong>Note that this was proposed some years ago, and any prospective student should first identify a suitable mentor, and discuss the details with her.
</strong>
</p>
<p>
Machine learning includes many methods (e.g, neural networks, support vector machines, hidden markov models, genetic algorithms, self-organizing maps) that are applicable to classification and/or pattern recognition problems in many fields.
</p>
<p>
A selection of these methods should be implemented as a Haskell library, the choice would depend on the qualifications and interests of the student. Optionally, a more limited library with an application using it could be implemented.
</p>
<p>
My main interest is in bioinformatics, but as machine learning methods are useful in a vast number of fields, I'm happy to hear from prospective mentors and other people who are interested, as well as from prospective applicants.
</p>
<h2 id="PreviouslyInterestedStudents">Previously Interested Students</h2>
<ul><li>Anil Vaitla &lt;avaitla16@…&gt; (Matrix Decompositions, SVM, and HMM)
</li><li>Andreas Launila &lt;<a class="ext-link" href="http://lokoin.org/contact"><span class="icon">​</span>http://lokoin.org/contact</a>&gt; (SVM and HMM)
</li><li>Jiri Hysek (dvekravy) &lt;xhysek02@…&gt; (NN and GA)
</li><li>Charles Blundell &lt;blundellc@…&gt; (SVM, HMM, ID3/C4.5; already done NN, Q-learn, SOM, ~GA)
</li><li>P McArthur &lt;<a class="ext-link" href="http://www.dysfunctor.org/about/"><span class="icon">​</span>http://www.dysfunctor.org/about/</a>&gt; (Hidden Markov Model)
</li><li>Dave Tapley &lt;dukedave@…&gt; (Studying: &lt;<a class="ext-link" href="http://www.cse.dmu.ac.uk/msccir/structure.html"><span class="icon">​</span>http://www.cse.dmu.ac.uk/msccir/structure.html</a>&gt;)
</li><li>Ivan Dilchovski &lt;root.darkstar@…&gt; (currently doing graduation paper on NN)
</li><li>Dinesh G&lt;g.dinesh.cse@…&gt; (SVM, PCA, SVD, Random Projection, Cluterings techniques) Currently doing my masters in Indian Institute Of Science. Area Of Interest: Machine learning
</li><li>Moises Osorio &lt;wcoder.mx@…&gt; (Genetic algorithms)
</li></ul><h2 id="CurrentlyInterestedStudents">Currently Interested Students</h2>
<ul><li>Martin Boyanov &lt;mboyanov@…&gt; (HMM, k-means clustering, Naive Bayes,neural networks)
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1127#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1544
http://ghc.haskell.org/trac/summer-of-code/ticket/1544#1544: Parallel programming benchmarking and benchmark suiteWed, 19 Mar 2008 19:13:22 GMTdons<p>
GHC offers many features for muilticore, parallel programming, including a parallel runtime, a new parallel garbage collector, a suite of shared memory concurrency abstractions, and a sophisticated parallel stratgies library.
</p>
<p>
What's missing from this set is experience building parallel applications using the parallel runtime, and high level parallelism primitives.
</p>
<p>
In this project a parallelism benchmark suite, possibly ported from an existing suite, would be implemented, and used to gather experience and bug reports about the parallel programming infrastructure.
</p>
<p>
Improvements, to , say, Control.Parallel.Strategies , could result, as would a robust way of comparing parallel program performance between versions of GHC.
</p>
<h2 id="Interestedmentors">Interested mentors</h2>
<ul><li>Don Stewart
</li><li>Manuel Chakravarty
</li><li>Roman Leshchinskiy
</li></ul><h2 id="InterestedStudents">Interested Students</h2>
<ul><li>Donnie Jones &lt;donnie@…&gt;
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1544#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1547
http://ghc.haskell.org/trac/summer-of-code/ticket/1547#1547: FFI bridge to PythonWed, 19 Mar 2008 22:10:02 GMTdons<p>
Python has an impressive number of libraries we might want to utilise from Haskell (e.g.pygments is used in the new hpaste), also, being able to access Haskell from Python lowers the risk when integrating Haskell into new projects.
</p>
<p>
This project would seek to develop an Python&lt;-&gt;Haskell bridge, allowing the use of libraries on either side from each language.
</p>
<p>
Python's C-based FFI makes this not too daunting, and the pay off could be quite large.
Related projects: <a class="missing wiki">MissingPy?</a> and hpaste's light python binding.
</p>
<p>
We may also be able to get this funded under the (many) python slots.
</p>
<h2 id="Projectstocontact">Projects to contact</h2>
<p>
This could be funded under the Python project umbrella. Applications should also be submitted to them.
</p>
<h2 id="Interestedmentors">Interested mentors</h2>
<p>
Don Stewart
</p>
<h2 id="InterestedStudents">Interested Students</h2>
<p>
Michal Janeczek &lt;janeczek@…&gt;
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1547#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1548
http://ghc.haskell.org/trac/summer-of-code/ticket/1548#1548: xmonad: compositing supportWed, 19 Mar 2008 22:20:42 GMTdons<p>
<a class="ext-link" href="http://xmonad.org"><span class="icon">​</span>xmonad</a> is a tiling window manager for X11, and a <a class="ext-link" href="http://www.ohloh.net/tags/haskell"><span class="icon">​</span>popular</a> Haskell open source project with many users.
</p>
<p>
This project would seek to integrate "<a class="ext-link" href="http://en.wikipedia.org/wiki/Compiz"><span class="icon">​</span>compositing</a>" support into xmonad, creating the first compositing tiling window manager.
</p>
<p>
Compositing is the use 3D hardware accelaration to provide window effects, such as in the Apple "expose" functionality, and Compiz, an unix window manager supporting compositing effects.
</p>
<p>
By reusing the compositing libraries provided by "compiz", binding to them from Haskell, and integrating compositing hooks into xmonad, we could hope to write effects in Haskell, for the window manager.
</p>
<p>
This would make xmonad unique: the only tiling window manager with support for compositing. Additionally, a Haskell EDSL for describing effects would be of general utility. The result would be a novel UI interface, and would investigate how the user interface for a tiling wm can be enhanced via compositing.
</p>
<p>
The initial goal would be to bind to the basic library, providing a simple effect (such as shadowing), and then extend the supported effects as necessary.
</p>
<h2 id="Relatedmaterial">Related material</h2>
<p>
The xmonad feature ticket for this:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://code.google.com/p/xmonad/issues/detail?id=19"><span class="icon">​</span>http://code.google.com/p/xmonad/issues/detail?id=19</a>
</p>
</blockquote>
<h2 id="Organisationsthatmightbeinterested">Organisations that might be interested</h2>
<ul><li>Haskell.org
</li><li>X.org
</li><li>Portland State University
</li></ul><p>
Discussion will take place on the xmonad@ lists, in order to prepare good submissions to these groups.
</p>
<h2 id="Interestedmentors">Interested mentors</h2>
<ul><li>Don Stewart
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1548#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1550
http://ghc.haskell.org/trac/summer-of-code/ticket/1550#1550: wxHaskell improvementsWed, 19 Mar 2008 22:51:23 GMTdons<p>
wxWidgets are a funded project this year. Coordinate with them to work on wxHaskell improvements.
Needs support from the wxHaskell team
</p>
<p>
Things which look like they might be good summer of code projects:
</p>
<ul><li>Type-safe XRC support (and Document)
</li><li>Fancy vector graphics support on top of wxGraphicsContext
</li></ul><p>
Things we want for wxhaskell 0.12
</p>
<ul><li>better handling of extensions
</li><li>Merge WXSOEGraphics code.
</li></ul><p>
Daan's ideas from <a class="ext-link" href="http://haskell.org/haskellwiki/WxHaskell/Contribute"><span class="icon">​</span>http://haskell.org/haskellwiki/WxHaskell/Contribute</a>
</p>
<ul><li>Add new widget abstractions to the WX library
</li><li>Portable resources (see the page)
</li><li>Create a good tree control / list control abstraction (perhaps the higher level libraries like autoforms?)
</li></ul><p>
Other ideas
</p>
<ul><li>Better Cabalization (This is not just wxHaskell project. We should collaborate with Cabal developper.)
</li><li>Add com (ActiveX) support for Windows platform
</li></ul><p>
Todo: what else needs doing with wxHaskell?
</p>
<h2 id="Interestedmentors">Interested mentors</h2>
<p>
</p>
<ul><li>Kido Takahiro
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1550#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1555
http://ghc.haskell.org/trac/summer-of-code/ticket/1555#1555: Embedded Haskell: calling Haskell from other languagesThu, 20 Mar 2008 18:29:48 GMTdons<p>
The Haskell FFI, and in particular, GHC, supports "foreign export" of Haskell code to C, and
embedding Haskell modules inside C apps. However, this functionality is rarely used, and requires
a fair bit of manual effort.
</p>
<p>
This project would seek to simplify, polish and document the process of embedding and calling Haskell code from C, and languages that use the C ffi (Python, Erlang, C++ ...), providing a
canned solution for running Haskell fragments from projects written in other languages.
</p>
<p>
A good solution here has great potential to help Haskell adoption (as we've seen in Lua), by
mitigating the risk of using Haskell in a project.
</p>
<h2 id="Relatedorganisations">Related organisations</h2>
<p>
Depending on the language, we may be able to move this under another language umbrella (Python, Perl, Ruby, ... ?)
</p>
<h2 id="Interestedmentors">Interested mentors</h2>
<ul><li>Don Stewart
</li></ul><h2 id="Interestedstudents">Interested students</h2>
<ul><li>Ben Kalman
</li><li>Wojciech Cichon
</li><li>Damien Desfontaines
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1555#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1556
http://ghc.haskell.org/trac/summer-of-code/ticket/1556#1556: Further Parsec ImprovementsFri, 21 Mar 2008 17:16:09 GMTPhilippaCowderoy<p>
Last year's Summer of Code project led to Parsec3, a monad transformer version of Parsec with significantly more flexibility in the input it accepts. There is much work left that can be done though:
</p>
<ul><li>Regaining lost speed for common cases such as ParsecT Identity with [] as input stream
</li><li>Reworking the error handling and source position models to handle the increased variety in input streams, correct problems with error messages and enable greater integration with any underlying monad where appropriate
</li><li>Exploring further possibilities for optimisation
</li><li>Building examples, documentation and support libraries for parsing tasks outside Parsec's traditional domain such as binary parsing
</li></ul><h2 id="InterestedMentors">Interested Mentors</h2>
<ul><li>Philippa Cowderoy (Philippa) &lt;flippa@…&gt;
</li><li>Derek Elkins (ddarius) &lt;derek.a.elkins@…&gt;
</li><li>Dmitry Astapov (ADEpt) &lt;dastapov@…&gt;
</li></ul><h2 id="InterestedStudents">Interested Students</h2>
<ul><li>Matej Kollar &lt;kollar.208115@…&gt;
</li><li>Andre Murbach Maidl &lt;amaidl@…&gt;
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1556#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1564
http://ghc.haskell.org/trac/summer-of-code/ticket/1564#1564: C Bindings to Haskell ValuesThu, 05 Mar 2009 02:19:48 GMTaluink<p>
Write an tool to convert Haskell values, structures and functions, to C bindings.
</p>
<h2 id="Overview">Overview</h2>
<ul><li>Convert Functions
</li><li>Convert Data Structures
</li><li>Typing
</li><li>Documentation
</li></ul><h2 id="ConvertFunctions">Convert Functions</h2>
<p>
We need to find a way to convert Haskell functions, or pointers to, into C function pointers. This would allow many things to follow. Haskell class(HC) instances could have C Class(CC) definitions. So then calling the HC functions would be as simple as referring to the functions pointers stored in the CC. How to deal with general module functions is something to think about still. Something to also think about is how to convert the function pointers back to Haskell functions. This will be needed when passing function pointers to Haskell function calls. Do we want to allow the "lifting" of regular C functions into the pointers to Haskell functions so they can be passed to Haskell functions? This would almost seem required with such a system.
</p>
<h2 id="ConvertDataStructures">Convert Data Structures</h2>
<p>
Structures created with "data" will most likely be GObjects. Those done with "newtype" will most likely have to be duplicated, or maybe we can get away with #defines. If anything, we should probably be able to get away with a #define for "type" definitions. Some standard structures from the Prelude will have to be converted and included in the conversion tool.
</p>
<h2 id="Typing">Typing</h2>
<p>
Haskell has a, to put it lightly, strong typing system. We need to think about how to bring that into the C context. How much of it do we want to preserve?
</p>
<h2 id="Documentation">Documentation</h2>
<p>
Any good tool is useless without documentation. Part of the deliverables of this project will be documentation on usage, how it works, and some man pages.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1564#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1583
http://ghc.haskell.org/trac/summer-of-code/ticket/1583#1583: Language.C enhancementsTue, 30 Mar 2010 17:33:09 GMTatomb<p>
Three possibilities:
</p>
<p>
The first is to integrate preprocessing into the library. Currently, the library calls out to GCC to preprocess source files before parsing them. This has some unfortunate consequences, however, because comments and macro information are lost. A number of program analyses could benefit from metadata encoded in comments, because C doesn't have any sort of formal annotation mechanism, but in the current state we have to resort to ugly hacks (at best) to get at the contents of comments. Also, effective diagnostic messages need to be closely tied to original source code. In the presence of pre-processed macros, column number information is unreliable, so it can be difficult to describe to a user exactly what portion of a program a particular analysis refers to. An integrated preprocessor could retain comments and remember information about macros, eliminating both of these problems.
</p>
<p>
The second possible project is to create a nicer interface for traversals over Language.C ASTs. Currently, the symbol table is built to include only information about global declarations and those other declarations currently in scope. Therefore, when performing multiple traversals over an AST, each traversal must re-analyze all global declarations and the entire AST of the function of interest. A better solution might be to build a traversal that creates a single symbol table describing all declarations in a translation unit (including function- and block-scoped variables), for easy reference during further traversals. It may also be valuable to have this traversal produce a slightly-simplified AST in the process. I'm not thinking of anything as radical as the simplifications performed by something like CIL, however. It might simply be enough to transform variable references into a form suitable for easy lookup in a complete symbol table like I've just described. Other simple transformations such as making all implicit casts explicit, or normalizing compound initializers, could also be good.
</p>
<p>
A third possibility, which would probably depend on the integrated preprocessor, would be to create an exact pretty-printer. That is, a pretty-printing function such that pretty . parse is the identity. Currently, parse . pretty should be the identity, but it's not true the other way around. An exact pretty-printer would be very useful in creating rich presentations of C source code --- think LXR on steroids.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1583#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1591
http://ghc.haskell.org/trac/summer-of-code/ticket/1591#1591: GObject Introspection based static binding generator for Gtk2hsTue, 15 Feb 2011 18:32:44 GMTarsenm<p>
This was my project idea from last year, but I ended up not doing GSoC. It would be useful to have a static binding generator for Gtk2hs using data from gobject-introspection to do most of the work, making it easier to update and maintain the bindings to Gtk+ and company, and easier to add bindings for new GObject based libraries.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1591#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1596
http://ghc.haskell.org/trac/summer-of-code/ticket/1596#1596: A statistics library and environmentMon, 21 Mar 2011 10:49:58 GMTKetilMalde<p>
Although some statistics functionality exists in Haskell (e.g. in Bryan O'Sullivan's 'statistics' library), I think Haskell (or GHCI) could make sense as a more complete environment for statistical analysis.
</p>
<p>
I think a standard data type representing a data frame would be a cornerstone, and analysis and visualization could be built on top of this to become a complete analysis environment, as well as a standard library for use in regular applications.
</p>
<p>
This isn't necessarily a very difficult project, but for it to be acceptable it would probably need to be detailed and discussed a lot more, and one or more suitable mentors would need to step forward.
</p>
<p>
Edit: It would also be great to take advantage of Haskell's parallel support (R only has this as proprietary add-ons, I think), and type safety (for instance using the 'dimensional' library to keep track of units).
</p>
<p>
See also <a class="ext-link" href="http://neilmitchell.blogspot.com/2011/03/experience-report-functional.html"><span class="icon">​</span>http://neilmitchell.blogspot.com/2011/03/experience-report-functional.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1596#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1597
http://ghc.haskell.org/trac/summer-of-code/ticket/1597#1597: Platform neutral GUI leading to ... hackage 3Tue, 22 Mar 2011 15:59:28 GMTtirili<p>
It is hard in hackage to get an overview over nearly 3000 libraries, how popular a library is, examples of how to use it, see changes, etc. . Some of this is planned to be solved in hackage 2, which is very promising. I would like to extend this by displaying libraries like skyscrapers in a city as flow networks. For this I have developed several libraries to prepare this, see <a class="ext-link" href="http://www.haskellers.com/user/858"><span class="icon">​</span>http://www.haskellers.com/user/858</a> . I have have found a very general way to construct 3d shape based on symmetry classes in my diploma thesis (this also tackles this reddit proposal: <a class="ext-link" href="http://www.reddit.com/r/haskell_proposals/comments/fkqmc/platform_neutral_graphics_and_user_interface/"><span class="icon">​</span>http://www.reddit.com/r/haskell_proposals/comments/fkqmc/platform_neutral_graphics_and_user_interface/</a>). My plan is to change Sourcegraph (<a class="ext-link" href="http://hackage.haskell.org/package/SourceGraph"><span class="icon">​</span>http://hackage.haskell.org/package/SourceGraph</a>) to parse all packages and display them with WebGL or a 3d-engine.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1597#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1599
http://ghc.haskell.org/trac/summer-of-code/ticket/1599#1599: Improve several areas of EclipseFPThu, 24 Mar 2011 21:37:38 GMTserras<p>
Now, EclipseFP <a class="ext-link" href="http://eclipsefp.sourceforge.net/"><span class="icon">​</span>http://eclipsefp.sourceforge.net/</a> supports working with both Haskell and Cabal files, compiling and running the code. However, it would be great to make it a complete environment as for Java or C++. Some ideas would be:
</p>
<ul><li>Use the framework in Eclipse so that Haskell programmers could run Quickcheck, Smallcheck, HUnit test as Java programmers can run JUnit tests;
</li><li>Allow the programmers to run their executables under profiling environment and then show the results. This plug-in may be based in the ones for GProf or OProfile in the Linux Tools Eclipse project;
</li><li>Try to provide more code completion or <a class="missing wiki">IntelliSense?</a>-like things;
</li><li>Allow the user to access in a fast way information from functions (for example, if you Shift+click on a function name, the Haddock doc may appear)
</li></ul><h3 id="Interestedstudents">Interested students</h3>
<ul><li>Alejandro Serrano (serras)
</li><li>Saurabh Kumar &lt;saurabh.catch@…&gt;
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1599#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1600
http://ghc.haskell.org/trac/summer-of-code/ticket/1600#1600: Mathematical environment in HaskellThu, 24 Mar 2011 22:04:05 GMTserras<p>
Haskell is usually described as a language appropiate for people with a mathematically-oriented mind. However, I've found that there is no comprehensive library (or set of libraries) for doing maths in Haskell.
</p>
<p>
My idea would be to follow the path of the Sage project <a class="ext-link" href="http://www.sagemath.org/"><span class="icon">​</span>http://www.sagemath.org/</a>. That projects took a lots of libraries and programs already available and added a layer for communication with them in Python. The result is that now you can have a full-fledged mathematical environment while using your normal Python knowledge for GUI, I/O and so on...
</p>
<p>
The project can have several parts:
</p>
<ul><li>Try to come with a hierarchy of classes like the ones in Sage for the basic building blocks (this may start with the Numeric Prelude)
</li><li>Try to create bridges in Haskell as done in Sage
</li><li>Find a way to "import" code in Sage (some algorithms are written just in them) to the Haskell counterpart
</li></ul><p>
For free, GHCi could be used as the next Matlab :D
</p>
<h3 id="Interestedstudents">Interested students</h3>
<ul><li>Alejandro Serrano (serras)
</li></ul><h3 id="Interestedmentors">Interested mentors</h3>
<ul><li>Jacques Carette &lt;carette@…&gt;
</li></ul>Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1600#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1601
http://ghc.haskell.org/trac/summer-of-code/ticket/1601#1601: Library for the Arduino platformSat, 26 Mar 2011 16:29:34 GMTgoto<p>
The Arduino platform is an open electronics platform for easily building interactive objects. Arduino offers simple ways of getting creative with electronics and building your own devices without having to dive deep into microcontroller programming with c or asm. I think this is a great opportunity for the Haskell community to extend beyond the software world and to get people interested in Haskell who would otherwise not consider engaging with fp.
</p>
<p>
This project would aim at providing an extensible library for programming the Arduino platform, enabling a functional (and hopefully more intuitive) way of programming the Arduino hardware. The library would be designed on providing an API for interacting with Arduino. I think this would be a better way then to write a cross-compiler or to define a language subset.
</p>
<p>
If you have any thoughts or ideas please feel free to leave a comment.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1601#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1604
http://ghc.haskell.org/trac/summer-of-code/ticket/1604#1604: Embedding Haskell in C++: The FFI upside-downFri, 01 Apr 2011 12:26:36 GMTbschuur<p>
The idea is to, following in the footsteps of tickets <a class="assigned ticket" href="http://ghc.haskell.org/trac/summer-of-code/ticket/1555" title="proposed-project: Embedded Haskell: calling Haskell from other languages (assigned)">#1555</a> and <a class="new ticket" href="http://ghc.haskell.org/trac/summer-of-code/ticket/1564" title="proposed-project: C Bindings to Haskell Values (new)">#1564</a>, make accessing Haskell functions from C++ as conveniently as possible by creating a tool which easily exposes Haskell functions to C++.
</p>
<h1 id="Why">Why?</h1>
<p>
The main rationale behind this, is that pure code should be called from impure code. This is a paradigm already present in Haskell in the form of the IO monad. Thus Haskell should be invoked from an external (impure) language, not the other way around.
</p>
<p>
The FFI is mostly used in the opposite direction, because it is usually employed to create wrappers for external libraries.
</p>
<h1 id="Implementation">Implementation</h1>
<p>
A big part of exposing Haskell functionality to another language is marshalling data structures between the two languages. We could use the following system to derive a c++ representation for Haskell datatypes:
</p>
<p>
To keep things initially simple one could start with mutually recursive datatypes with type parameters (no nested datatypes or functions with constructors). For these there is a straightforward (automatic) translation from Haskell types into c++ types:
</p>
<ul><li>Datatypes become virtual classes
</li><li>Constructors become subclasses of their datatype
</li><li>Constructor parameters become class-variables
</li><li>Type parameters become templates
</li></ul><p>
Standard Haskell types such as integers/lists/maybe/map could be treated separately to create native c++ representations.
</p>
<p>
For functions we want exposed to c++, a wrapper function is created which calls the original Haskell function (via C). This is also where the marshalling of arguments/results takes place. Initially only first-order functions will be supported. A system to support higher-order functions (which implies functions have to become first-class in c++) may be possible but this would be future work.
</p>
<h1 id="Use-case">Use-case</h1>
<p>
A possible use-case for this system would be a code editor. The (impure) gui can be written in c++ while the text editing functions and for example parsing for code-highlighting can be provided by pure Haskell functions.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1604#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1605
http://ghc.haskell.org/trac/summer-of-code/ticket/1605#1605: A universal data store interface.Sun, 03 Apr 2011 08:02:34 GMTgregweber<p>
A lack of a high-level data store library is a huge weakness in haskell.
</p>
<p>
Data storage is absolutely critical for web development or any program that needs to persist data or whose data processing exceeds memory. Haskell web development has languished in part because one had to choose between lower-level SQL or Happstack's experimental data store that uses only the process memory. All other widely used programming languages have multiple ORMs for proven databases. Haskell needs some better database abstraction libraries.
</p>
<p>
The persistent library is a universal data store interface that already has PostgreSQL, Sqlite, MySQL, MongoDB, and experimental CouchDB backend. Most users of the Yesod web framework are using it, and it is also being used outside of web development. With some more improvements, persistent could become the go-to data store interface for haskell programmers.
</p>
<p>
We could create interfaces to more databases, but the majority of Haskell programs just need *a* database, and would be happy with a really good interface to any database. There is also a need to interface with existing SQL databases. So I would like to focus on making (SQL &amp; MongoDB) storage layers really good. MongoDB should be easier to create a great interface for.
</p>
<p>
We have moved Persistent in the direction of universal query interface to just a universal data store serialization interface. There are many critics of query interfaces for good reasons: we will never be able to solve all use cases.
</p>
<p>
I believe future work on Persistent should continue this recent direction of allowing for raw queries. One can now finally write raw SQL queries and get them automatically properly serialized. The next step is to make them extraordinarily type-safe. That is, we know at compile time that the queries are valid. They reference columns correctly and they are valid database queries. There is already an experimental implementation of this for SQL called persistent-hssqlppp that checks the validity of SQL statements at compile time.
</p>
<p>
Persistent's biggest limitation right now is the lack of a good technique for returning a projection of the data - we always give back a full record. This issue should be explored in the GSoC, but does not have to be solved.
</p>
<p>
Persistent already has a very good Quasi-Quoted DSL for creating a schema, but another task at hand is to write a convenient Template Haskell interface for declaring a schema. This should not be difficult because we already have all the tools in place.
</p>
<p>
There are also some possibilities for integrating with existing Haskell backends. One interesting option is integration with HaskellDB or DSH - HaskellDB does not automatically serialize to a Haskell record like Persistent does.
</p>
<p>
Michael Snoyman and Greg Weber are willing to mentor, and there is a large community of users willing to help or give feedback.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1605#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1607
http://ghc.haskell.org/trac/summer-of-code/ticket/1607#1607: Haskell for the "real-time web"Mon, 13 Feb 2012 19:19:27 GMTgregweber<p>
Note "real-time web" basically means not needing to refresh web pages, nothing to do with real-time systems.
</p>
<p>
Haskell has the best async IO implementation available. And yet, node.js is getting all the spotlight! This is in part a library issue. Node.js has several interfaces that use websockets and fall back to other technologies that are available.
</p>
<p>
I propose we create such a library for Haskell. We have already identified a language-independent design called sockjs. And there is already work under way on wai-sockjs, with good implementations of wai-eventsource and wai-websockets already available.
</p>
<p>
Such a library is a fundamental building block for interactive (real-time) web sites. There is also a use case for embedding a capable Haskell messaging server into a website ran on a slower dynamic language that has poor concurrency, like Ruby (some people embed node.js based messaging servers now). This gives Haskell a back door to getting adopted in other areas.
</p>
<p>
This should be easily achievable in a GSoC. In fact I think the biggest problem may be how to expand the scope of this to fit the summer. The Yesod web framework is now a very good server oriented web framework. A good wai-sockjs implementation could be nicely integrated with Yesod and other frameworks, but it could also be the building block for a great client-side abstraction in which a web page is automatically kept up to date in "real-time".
</p>
<p>
Michael Snoyman and myself are willing to mentor. We can probably also get those that have been involved with websockets related development to date to mentor or at least give assistance.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1607#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1611
http://ghc.haskell.org/trac/summer-of-code/ticket/1611#1611: Solve cabal dependency hellTue, 20 Mar 2012 06:53:27 GMTgregweber<ul><li>Installing a new package should never break an existing package install.
</li><li>If there is a correct way to configure dependencies, Cabal should resolve it.
</li><li>Local installs should have the same status as hackage installs (merge cabal-src-install)
</li></ul><p>
This project will likely have a greater community impact than all others combined.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1611#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1613
http://ghc.haskell.org/trac/summer-of-code/ticket/1613#1613: Haiku supportWed, 21 Mar 2012 00:20:22 GMTmcandre<p>
Port GHC to Haiku OS. <a class="ext-link" href="http://haiku-os.org/"><span class="icon">​</span>http://haiku-os.org/</a>
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1613#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1616
http://ghc.haskell.org/trac/summer-of-code/ticket/1616#1616: Implement Cabal<->OS package management systems relationsFri, 23 Mar 2012 14:32:38 GMTpassalaqua<p>
Currently cabal manages the installation of hackage projects relatively well provided (among other things) that you have all the necessary external tools available and installed.
</p>
<p>
However, when certain tools are not available, such as alex or happy or some external library that cabal checks for with pkg-config, we lose the automated aspect of compiling and installing packages and confused and frustrated users. That is particularly bad for new users or people just wishing to use a certain haskell program available in hackage for which their OS does not have a pre-packaged version (such as an installer in windows or .deb in <a class="missing wiki">Debian/Ubuntu?</a>).
</p>
<p>
For instance, when issuing the command <tt>cabal install gtk</tt> in a fresh environment (say, ubuntu), it is going to complain about the lack of gtk2hs-buildtools. Then when issuing the command <tt>cabal install gtk2hs-buildtools</tt> it complains about the lack of alex. Installing alex is also not enough, as you also need happy. Cabal does not indicate that at first, though. Installing alex and happy still does not solve your problems as gtk depends on cairo, which checks for cairo-pdf through pkg-config and fails.
</p>
<p>
Point being that even though it is quite easy to install all those packages (and some you might not even have to be explicitly installed, as it can be provided by your haskell platform package), this automated process becomes manual, interactive and boring.
</p>
<p>
I propose extending cabal in three ways:
</p>
<ul><li>Adding checks at the start of the compilation (of the first package) so as to solve all (or as many of) those dependencies at once:
<ul><li>If it's an external executable, such as alex and happy, and we don't see it installed and on the path, complain or add it to the dependencies list to be installed (if we know how to, through point no.2 below);
</li><li>If it's something that is checked by pkg-config down the chain, it'd be nice to know in advance so we can first bother about all the libraries that it might need at once and stop babysitting the install so issue warnings before continuing;
</li></ul></li><li>Extending cabal so that it can accept several environment aware plugins (and develop at least one):
<ul><li>I like the thought of issuing <tt>apt-get install cabal-install &amp;&amp; cabal update &amp;&amp; cabal install cabal-ubuntu-integration</tt> or something like that and have cabal be aware that it is a big boy now and can suggest the install of external libraries to satisfy pkg-config dependencies (the user would still have to confirm and provide credentials, however due to the point above that would be at the beginning and we still get a nearly hands-free install);
</li><li>Obviously we are not limited to Ubuntu, used on this example; Other apt and rpm based systems and mac package management systems such as fink (though I have very limited experience on this side of things) could be supported similarly; Even windows could be, though that would probably require mode code to download/install cygwin/msys/painkillers to build some of the external libraries or provide reduced functionality.
</li></ul></li><li>Extending cabal to provide dependencies information that can be converted for external packages registered in a system wide install:
<ul><li>For this I took inspiration on the g-cpan tool for gentoo, which allows you to create on-the-fly ebuild files for PERL modules available at CPAN<a class="missing changeset" title="No default repository defined">[1]</a>, which are then installed as regular packages on the system. I propose a generic way of doing this so that a simple haskell project can encapsulate the required conversion between .cabal and whatever recipe/ebuild/etc file your particular environment might need.
</li><li>Basically each package would be able to state: I depend on X, Y and Z libraries that are on hackage, E and F executables (which I might or might not know where they are) and on L, M and N libraries through pkg-config; mapping those names to packages from each package manager would still be a problem for the individual plugi-ns, though.
</li></ul></li></ul><p>
I think this would be a nice step in making Haskell even more accessible and slightly less frustrating for newcomers and for people trying interesting things in projects that depend on external libraries.
</p>
<p>
I do understand that cabal is not a package manager<a class="missing changeset" title="No default repository defined">[2]</a>, however I see no reason why it should not be able to check for dependencies and issue warnings and suggestions in this way. And since those are warnings and not errors, the user can always ignore them and proceed.
</p>
<ol><li><a class="ext-link" href="http://www.gentoo.org/proj/en/perl/g-cpan.xml"><span class="icon">​</span>http://www.gentoo.org/proj/en/perl/g-cpan.xml</a>
</li><li><a class="ext-link" href="http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/"><span class="icon">​</span>http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/</a>
</li></ol><p>
Edit: Talked to Jürrien about this ticket and he mentioned the text on link <a class="missing changeset" title="No default repository defined">[2]</a>. I'm editing to try to make things clearer.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1616#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1621
http://ghc.haskell.org/trac/summer-of-code/ticket/1621#1621: Snap: Implement type-safe URL support for the Snap Web FrameworkThu, 29 Mar 2012 14:01:06 GMTozataman<p>
Snap aims to be a fast, resiable, easy to use, high quality and high level web development framework for Haskell. More information on Snap can be found at <a class="ext-link" href="http://www.snapframework.com/"><span class="icon">​</span>http://www.snapframework.com/</a>.
</p>
<p>
Type safe URLs encode all accessible paths of a web application via an algebraic datatype defined specifically for the web application at hand. All urls within the application, then, are generated from this datatype, which ensures statically that no dead links are present anywhere in the application.
</p>
<p>
Furthermore, when the user-visible URLs need to change for various (possibly cosmetic) reasons, the change can be implemented centrally and propagated to all the places of use within the application.
</p>
<p>
The web-routes package on Hackage seems to provide a framework-agnostic way to handle type-safe URLs. However, it might be worthwhile to discuss if this is the right choice for Snap.
</p>
<p>
The scope of this project would include the following:
</p>
<ul><li>Evaluation of web-routes and development of an idiomatic solution for underlying type-safe URL support for snap, both at "snap-core" and "snap" package levels. The API design should specifically consider how all the pieces will come together given the highly flexible snaplet infrastructure that Snap provides to achieve modularity in web applications.
</li></ul><ul><li>Development of Haskell combinators/helpers, so that URLs for various pages can be generated programmatically anywhere in the application.
</li></ul><ul><li>Integration with Heist template system so that URLs for various pages, including all necessary parameters, can easily be generated in templates anywhere in the application.
</li></ul><ul><li>Development of test cases to be added to the appropriate snap test-suites.
</li></ul><ul><li>Implementation of the type-safe URL system for the Snap website, as an initial use case study and verification of the design.
</li></ul><ul><li>The project may involve Template Haskell to remove obvious boilerplate.
</li></ul><h2 id="InterestedMentors">Interested Mentors</h2>
<p>
Doug Beardsley
</p>
<p>
Greg Collins
</p>
<p>
Ozgun Ataman
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1621#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1653
http://ghc.haskell.org/trac/summer-of-code/ticket/1653#1653: PVP compliance checkerFri, 20 Feb 2015 02:42:56 GMTekmett<p>
A tool that is given two package tarballs (or similar) tells you which version number component that needs to be bumped and why. It should be integrated into the cabal workflow, perhaps into cabal itself.
</p>
<p>
(Probably too small to be a project on its own, suggested by Johan Tibell.)
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1653#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1655
http://ghc.haskell.org/trac/summer-of-code/ticket/1655#1655: Have GHC track the different library "ways" it has installedFri, 20 Feb 2015 02:44:30 GMTekmett<p>
Today GHC doesn't know if it has installed e.g. both the vanilla and profiling versions of a library. This leads to annoying error messages and an unpleasant experience when users want to profile something. If GHC tracked which versions of a library it had installed cabal could easily and automatically installed the missing profiling versions.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1655#changeloghttp://ghc.haskell.org/trac/summer-of-code/ticket/1656
http://ghc.haskell.org/trac/summer-of-code/ticket/1656#1656: Make parallel builds in GHC actually give speed-upsFri, 20 Feb 2015 02:46:29 GMTekmett<p>
Something is wrong in the parallel build implementation in GHC, as it doesn't even give good speed-ups in embarrassingly parallel cases on few cores (e.g. 2). Someone needs to profile GHC and work on speeding up parallel builds.
</p>
Resultshttp://ghc.haskell.org/trac/summer-of-code/ticket/1656#changelog