__color__ ticket summary priority milestone type owner status created _changetime _description _reporter 3 1555 Embedded Haskell: calling Haskell from other languages OK proposed-project madtroll assigned 2008-03-20T11:29:48-0700 2012-03-20T07:23:18-0700 "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. 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. 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. == Related organisations == Depending on the language, we may be able to move this under another language umbrella (Python, Perl, Ruby, ... ?) == Interested mentors == * Don Stewart == Interested students == * Ben Kalman * Wojciech Cichon * Damien Desfontaines" dons 1 1602 Supply dependencies for non-simple cabal build types (eg, Setup.hs) not yet rated proposed-project new 2011-03-28T10:09:35-0700 2012-05-31T22:17:10-0700 "Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult. A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal. Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools. I think something akin to the Library section would work for this, e.g.; {{{ CustomBuild Setup-is: Setup.hs Build-Depends: ... Build-tools: ... ... (I expect that most of the fields applicable to Library would also apply here.) }}}" creswick 1 1604 Embedding Haskell in C++: The FFI upside-down not yet rated proposed-project new 2011-04-01T05:26:36-0700 2011-04-01T05:26:36-0700 "The idea is to, following in the footsteps of tickets #1555 and #1564, make accessing Haskell functions from C++ as conveniently as possible by creating a tool which easily exposes Haskell functions to C++. = Why? = 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. The FFI is mostly used in the opposite direction, because it is usually employed to create wrappers for external libraries. = Implementation = 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: 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: * Datatypes become virtual classes * Constructors become subclasses of their datatype * Constructor parameters become class-variables * Type parameters become templates Standard Haskell types such as integers/lists/maybe/map could be treated separately to create native c++ representations. 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. = Use-case = 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." bschuur 1 1605 A universal data store interface. not yet rated proposed-project new 2011-04-03T01:02:34-0700 2012-03-26T15:26:18-0700 "A lack of a high-level data store library is a huge weakness in haskell. 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. 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. 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 & MongoDB) storage layers really good. MongoDB should be easier to create a great interface for. 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. 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. 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. 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. 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. Michael Snoyman and Greg Weber are willing to mentor, and there is a large community of users willing to help or give feedback." gregweber 1 1607 "Haskell for the ""real-time web""" not yet rated proposed-project new 2012-02-13T11:19:27-0800 2012-02-17T16:07:50-0800 "Note ""real-time web"" basically means not needing to refresh web pages, nothing to do with real-time systems. 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. 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. 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. 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"". 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." gregweber 1 1608 Implement 2-3 concurrent data structures from the literature not yet rated proposed-project rrnewton new 2012-02-15T20:01:36-0800 2012-04-02T12:05:02-0700 "The GHC Haskell compiler recently gained the capability to generate atomic compare-and-swap (CAS) assembly instructions. This opens up a new world of lock-free data-structure implementation possibilities. Furthermore, it's an important time for concurrent data structures. Not only is the need great, but the design of concurrent data structures has been a very active area in recent years, as summarized well by Nir Shavit in this article: http://cacm.acm.org/magazines/2011/3/105308-data-structures-in-the-multicore-age/ Because Haskell objects containing pointers can't efficiently be stored outside the Haskell heap, it is necessary to reimplement these data structures for Haskell, rather than use the FFI to access external implementations. There are already a couple of data structures implemented in the following library (queues and deques) : https://github.com/rrnewton/haskell-lockfree-queue But, this leaves many others, such as: * Concurrent Bags * Concurrent Priority Queues A good point of reference would be the libcds collection of concurrent data structures for C++ (or those that come with Java or .NET): http://libcds.sourceforge.net/ One of the things that makes implementing these data structures fun is that they have very short algorithmic descriptions but a high density of thought-provoking complexity. A good GSoC project would be to implement 2-3 data structures from the literature, and benchmark them against libcds implementations. == Interested Mentors == Ryan Newton == Interested Students (Include enough identifying info to find/reach you!) == Sergiu Ivanov kodoque Mathias Bartl Aleksandar Kodzhabashev == UPDATE == This ticket has been '''REFACTORED'''. It is now specifically focused on deques, bags, or priority queues. For anyone interested in concurrent hash-tables / hashmaps take a look at ticket #1617. == Recommended Papers with State-of-the-art Algorithms == * http://www.cse.chalmers.se/~tsigas/papers/Lock%20Free%20Bag%20SPAA11.pdf " rrnewton 1 1609 GHCi in the web browser not yet rated proposed-project apfelmus new 2012-02-17T08:07:27-0800 2012-03-19T14:25:49-0700 "GHCi in the web browser Imagine that you're drawing a picture in Haskell with the [http://projects.haskell.org/diagrams/gallery.html diagrams] package. Wouldn't it be awesome if you could just enter the expression into GHCi and it would draw the picture right there, like this? [[Image(http://apfelmus.nfshost.com/blog/2012/02/14-summer-of-code-proposal/diagram.png, 50%)]] And what about entering a function of type `Double -> Double` in the interpreter and immediately seeing a graph of it? [[Image(http://apfelmus.nfshost.com/blog/2012/02/14-summer-of-code-proposal/function.png, 50%)]] The goal of this proposal is to create a Haskell interpreter that is capable of displaying images, animations and even interactive programs. For maximum adoption and reuse, the GUI of the new interactive interpreter is to be implemented as a HTML page in the web browser. The GUI communicates with a server that is responsible for evaluating Haskell expressions. == Project Scope == This endeavor should emphasize modularity and reuse. The first step would be to create a small JavaScript object that represents a Haskell interpreter and supports functions like `GHCi.load(uri)` or `GHCi.eval(expr)` and to implement corresponding server code. For maximum modularity, the server should load source files from a URI. Since we are now in a HTML page, the server can return values in the form of arbitrary images, animations, hyperlinks and so on. Implementing this is not entirely straightforward, but most of the difficult problems have probably already been solved by prior work, like Chris Done's [http://tryhaskell.org/ TryHaskell] online interpreter and Péter Diviánszky's [http://pnyf.inf.elte.hu/fp/Diagrams_en.xml#moving-diagrams activehs] online courses. Building on these simple yet powerful basics, the view opens up to a wide range of possible applications: * A replacement for the ''local GHCi'', by running the server locally. Since the server can load from arbitrary URIs, this already allows us to code collaboratively with [Etherpad]. * Integration with ''source code editors'' and IDEs like [http://macromates.com/ TextMate]. In particular, augment compilation error with hyperlinks that point back to the source file. * Turn GHCi into an ''online service'', using the SafeHaskell extension. * Implementation of a ''notebook model'' (like Mathematica) that goes beyond the linear command line model of the traditional GHCi. * Integrate into ''documentation tools'' like Haddock or Brent Yorgey's [http://projects.haskell.org/diagrams/manual/diagrams-manual.html diagrams user guide], so that explanations and API documentation can now be enhanced with live examples. * Building a ''multiple user environment'' for use in teaching. A single interpreter session can be shared across different clients, be made read-only, and so on. * Displaying ''interactive values''. So far, the display is limited to static values, possibly animated with JavaScript. But what about interactive values that communicate back with the server to evaluate more Haskell functions? Conal Elliott's [http://www.haskell.org/haskellwiki/Tangible_Value tangible values] are the right abstraction for this. * ... Of course, this list is just a taste of the possibilities and not everything can be implemented in one summer. Still, I'm sure that the end result will be fantastic and that the emphasis on modularity will enable the Haskell community to build more awesome things on top. == Interested Mentors == Heinrich Apfelmus == Interested Students == " apfelmus 1 1610 Cabal support for the UHC JavaScript backend not yet rated proposed-project new 2012-03-11T04:49:37-0700 2012-03-20T12:35:54-0700 "We recently improved the UHC JavaScript backend[1] and showed that we can use it to write a complete front end for a web application[2]. A summary and demo of our results is available online[3]. Currently, however, it is still quite inconvenient to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. The programmer currently manually specifies include paths to the source of the used modules. Improving this situation is the goal for this GSoC project: make it possible to type `cabal configure && cabal build` and find a complete JS application in the project's dist folder. Successful completion of this project would go a long way towards making the UHC JS backend more usable and as a result, make Haskell a practical language to use for client-side programming. In solving this problem, one will have to think about how to deal with external Haskell libraries (UHC compiles JS from its internal core representation, so storing pre-compiled object files won't work in this case) and perhaps external JS libraries as well. One will also need to modify Cabal so that it becomes possible to select a specific UHC backend in your cabal files. Ideally, only one cabal file for an entire web application is needed; for both the front-end and backend application. An additional goal (in case of time to spare) would be the creation of a UHC JS-specific Haskell Platform-like distribution, so that programmers interested in using this technology can get started right away. Of course, such a distribution would have to be installed alongside the regular Haskell Platform. As for mentoring is concerned, I (Jurriën) might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there. [1] http://www.norm2782.com/improving-uhc-js-report.pdf [[BR]] [2] http://alessandrovermeulen.me/2012/01/26/getting-rid-of-javascript-with-haskell/ [[BR]] [3] http://uu-computerscience.github.com/uhc-js/ [[BR]]" norm2782 1 1611 Solve cabal dependency hell not yet rated proposed-project new 2012-03-19T23:53:27-0700 2012-04-02T13:26:53-0700 " * Installing a new package should never break an existing package install. * If there is a correct way to configure dependencies, Cabal should resolve it. * Local installs should have the same status as hackage installs (merge cabal-src-install) This project will likely have a greater community impact than all others combined." gregweber 1 1612 Working on the scoutess build-bot / continuous integration software not yet rated proposed-project new 2012-03-20T16:46:45-0700 2012-03-20T16:46:45-0700 "Scoutess aims at providing the Haskell community a powerful and viable build bot with a few key services like dependency tracking, on-commit build testing, nightly builds with handling of multiple GHC versions (and dependency versions), report generation, etc. Of course, all the builds will be sandboxed and many of the services will be configurable (and in particular, you will be able to turn them on/off). Some of the possible tasks include: - writing the sandboxed building service around cabal-dev, virtualhenv or hs-env, and integrating it with the current code-base (for example, making it use the 'LocalHackage' service instead of just fetching packages over and over again) - writing the dependency-tracking service (which would eventually also include tracking the development repositories of the dependencies) - working on the report generation and posting system (but that would most likely require the build service to be implemented) See http://alpmestan.wordpress.com/ for more details about this GSoC proposal." alpmestan 1 1613 Haiku support not yet rated proposed-project new 2012-03-20T17:20:22-0700 2012-04-24T20:47:36-0700 Port GHC to Haiku OS. http://haiku-os.org/ mcandre 1 1614 Replicating backend for AcidState. not yet rated proposed-project new 2012-03-20T23:46:31-0700 2012-03-21T13:19:53-0700 "[http://acid-state.seize.it/ AcidState] is a high performance library for adding ACID (http://en.wikipedia.org/wiki/ACID) guarantees to (nearly) any kind of Haskell data structure. In layman's term, it's a library that will make your data persist even in the event of, say, a power outage. [http://acid-state.seize.it/ AcidState] relies on an on-disk transaction log from which to recreate the Haskell data structure if your application crashed unexpectedly. This makes the hard drive a single point of failure (leading to the loss of data, even) and the low reliability of hard drives simply does not merit this. I propose that this should be solved by replicating the state across a cluster of machines. Each machine would keep a copy of the transaction log on disk and the single point of failure would be gone. When thinking about this project, one has to keep the CAP theorem (http://en.wikipedia.org/wiki/CAP_theorem) in mind. In particular, I propose consistency and availability to be guaranteed. Partition tolerance (compared to consistency and availability) has fewer uses and is much harder to implement. [http://acid-state.seize.it/ AcidState] is already structured for multiple backends so few, if any, internal changes are required before this project can begin. == Interested mentors: == * Jeremy Shaw (an officially accepted haskell.org mentor) == Interested students: == * David Himmelstrup. " Lemmih 1 1616 Implement Cabal<->OS package management systems relations not yet rated proposed-project new 2012-03-23T07:32:38-0700 2012-04-04T13:17:44-0700 "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. 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 Debian/Ubuntu). For instance, when issuing the command {{{cabal install gtk}}} in a fresh environment (say, ubuntu), it is going to complain about the lack of gtk2hs-buildtools. Then when issuing the command {{{cabal install gtk2hs-buildtools}}} 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. 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. I propose extending cabal in three ways: * 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: * 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); * 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; * Extending cabal so that it can accept several environment aware plugins (and develop at least one): * I like the thought of issuing {{{apt-get install cabal-install && cabal update && cabal install cabal-ubuntu-integration}}} 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); * 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. * Extending cabal to provide dependencies information that can be converted for external packages registered in a system wide install: * 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[1], 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. * 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. 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. I do understand that cabal is not a package manager[2], 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. 1. http://www.gentoo.org/proj/en/perl/g-cpan.xml 1. http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ Edit: Talked to Jürrien about this ticket and he mentioned the text on link [2]. I'm editing to try to make things clearer." passalaqua 1 1617 Implement Concurrent Hash-table / Hashmap using cutting edge techniques from the literature not yet rated proposed-project new 2012-03-25T12:16:22-0700 2012-03-30T08:55:49-0700 "This ticket has been factored out of ticket #1608: http://hackage.haskell.org/trac/summer-of-code/ticket/1608 The description and justification for that ticket still apply, but ticket #1608 is now focused on bag and deque structures, and this ticket is focused on hash tables. == Interested Mentors == Greg Collins Ryan Newton == Interested Students (Include enough identifying info to find/reach you!) == Loren Davis Aleksandar Kodzhabashev Mathias Bartl Florian Hartwig ([http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/florianhartwig/1 proposal]) " rrnewton 1 1618 Add NUMA-supporting features to GHC not yet rated proposed-project new 2012-03-26T07:49:46-0700 2012-03-26T07:51:24-0700 "This ticket is an adaptation of [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022199.html Sajith Sasidharan's mailing list post]. Broadly, idea is to improve support for NUMA systems. Specifically: * '''Thread pinning''' Real physical processor affinity with [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v:forkOn forkOn]. We need to pin to specific CPUs if we want to. (Currently, the number passed to forkOn is interpreted as number modulo the value returned by [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v:getNumCapabilities getNumCapabilities]). * '''Process pinning''': when launching processes, we might want to specify a list of CPUs rather than the number of CPUs, so that we can pin a process to a particular NUMA node. Say, a -N [0,1,3] flag rather than -N 3 flag. * '''Memory locality''': From a very recent [http://groups.google.com/group/parallel-haskell/browse_thread/thread/7ec1ebc73dde8bbd discussion on parallel-haskell], we learned that there is a clear path to improving the storage manager's NUMA support. The hypothesis is that allocating ''node-local'' nurseries per Capability will improve performance over the bump-pointer approach in `allocate`. We might use the NUMA-aware allocation primitives from the [http://www.open-mpi.org/projects/hwloc/ Portable Hardware Locality (hwloc)] library for this. * '''Logging and tracing''' Add NUMA-specific event logging and profiling information to support performance analysis and debugging of user-level NUMA-aware programs. == Interested Mentors == '''Needed'''! I ([acfoltzer@gmail.com Adam Foltzer]) know the outlines of the problems fairly well, but have no experience hacking on RTS code. I would be willing to take on a supporting role, but such experience seems necessary to mentor this project. == Interested Students (Include enough identifying info to find/reach you!) == * [sasasidh@indiana.edu Sajith Sasidharan] " acfoltzer 1 1619 Tweak memory-reuse analysis tools for GHC compatibility not yet rated proposed-project new 2012-03-26T15:15:48-0700 2012-03-27T06:28:18-0700 "Some program instrumentation and analysis tools are language agnostic. Pin and Valgrind use binary rewriting to instrument an x86 binary on the fly and thus in theory could be used just as well for a Haskell binary as for one compiled by C. Indeed, if you download Pin from pintool.org, you can use the included open source tools to immediately begin analyzing properties of Haskell workloads -- for example the total instruction mix during execution. The problem is that aggregate data for an entire execution is rather coarse. It's not correlated temporally with phases of program execution, nor are specific measured phenomena related to anything in the Haskell source. This could be improved. A simple example would be to measure memory-reuse distance (an architecture-independent characterization of locality) but to distinguish garbage collection from normal memory access. It would be quite nice to see a histogram of reuse-distances in which GC accesses appear as a separate layer (different color) from normal accesses. How to go about this? Fortunately, the existing MICA pintool can build today (v0.4) and measure memory reuse distances. http://boegel.kejo.be/ELIS/mica/ In fact, it already produces per-phase measurements where phases are delimited by dynamic instruction counts (i.e. every 100M instructions). All that remains is to tweak that definition of phase to transition when GC switches on or off. How to do that? Well, Pin has existing methods for targeted instrumentation of specific C functions: http://www.cs.virginia.edu/kim/publicity/pin/docs/45467/Pin/html/group__RTN__BASIC__API.html#g8622a6ba858eb8d55df4e006eb165e57 By targeting appropriate functions in the GHC RTS, this analysis tool could probably work without requiring any GHC modification at all. A further out goal would be to correlate events observed by the binary rewriting tool and those recorded by GHC's traceEvent. Finally, as it turns out this would NOT be the first crossing of paths between GHC and binary rewriting. Julian Seward worked on GHC before developing valgrind: http://www.techrepublic.com/article/open-source-awards-2004-julian-seward-for-valgrind/5136747 == Interested Mentors == Ryan Newton Others?? == Interested Students (Include enough identifying info to find/reach you!) == " rrnewton 1 1620 haskell-type-exts not yet rated proposed-project nibro new 2012-03-28T02:52:44-0700 2012-04-03T09:19:26-0700 "== What? == The [http://hackage.haskell.org/package/haskell-src-exts haskell-src-exts] library (HSE) is very popular for manipulating Haskell source code in a wide range of scenarios, such as (syntactic) preprocessors (e.g. hsx), syntax highlighting, refactoring and code inspection (e.g. hlint), etc. A commonly sought feature, that would enable a multitude of new and improved scenarios, is the ability to type-check the code, and annotate the AST with type information. Type-driven refactoring, type-aware code inspection, type-based preprocessing, ... Lots of pure awesomeness lies in that direction. Sadly, HSE has no type-checking abilities. For those who seek such, we are forced to point in the direction of the dark cave that is the GHC API. While GHC is an utterly awesome compiler, there are several reasons why this is not an ideal situation. First, GHC was designed and built for optimization, which means that even the early stages of the compilation pipeline contain features that cater to later optimization, but that are (at best) unnecessary for a front-end tool. Second, the API into GHC internals is defined as an afterthought. Some good work has been done to make it somewhat palatable, but it remains a fact that GHC's primary purpose is not to be a library for integration in tools, and this shows. Overall, depending on GHC when all you want is front-end capabilities like parsing and typechecking, is really like using the proverbial sledge hammer. Also, at the meta level, GHC deserves ""competition"". Right now GHC is de facto the only implementation of Haskell, and as such it more or less defines the progress of Haskell. Too often this leads to overly pragmatic choices, which lead to inconsistencies and headaches for tool programmers. Having a separate, stand-alone front end library would help set higher standards. So - what we need is a type checker that works on the HSE AST: haskell-type-exts! == How? == I now hear you think: ""This is too much, an enormous project, surely it can't be done as a GSoC project?"" Sure it can! By walking in the footsteps of giants, and following GHC's approach. This can be achieved by closely observing the documentation provided by [1] and [2], with a bit of [3] thrown into the mix. I already have a basic library that provides most of the core framework necessary to cover extensions, but at this time it's mostly just scaffolding. It needs a lot of love, to provide cover for all the various available extensions, but I'm confident it can be done satisfactorily as a GSoC project. Still, it would be reasonable to modularize the task. Certain features are more crucial than others to support, simply because they have a more profound impact on the overall type-checking. Higher-rank types, GADTs and type families (and fundeps) are likely the most important ones to get right. There are also some design issues to get right (e.g. using pure substitution vs efficient mutable variables). I (Niklas Broberg) am more than willing to mentor this project. === Further reading: === * [1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. * [2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. !OutsideIn(X) – Modular type inference with local assumptions * [3] M. P. Jones. Typing Haskell in Haskell" nibro 1 1621 Snap: Implement type-safe URL support for the Snap Web Framework not yet rated proposed-project mightybyte new 2012-03-29T07:01:06-0700 2012-04-03T22:47:50-0700 "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 http://www.snapframework.com/. 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. 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. 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. The scope of this project would include the following: - 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. - Development of Haskell combinators/helpers, so that URLs for various pages can be generated programmatically anywhere in the application. - 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. - Development of test cases to be added to the appropriate snap test-suites. - Implementation of the type-safe URL system for the Snap website, as an initial use case study and verification of the design. - The project may involve Template Haskell to remove obvious boilerplate. == Interested Mentors == Doug Beardsley Greg Collins Ozgun Ataman" ozataman 1 1625 Achat De Finasteride not yet rated spam weledobace new 2012-12-04T02:16:29-0800 2012-12-04T02:16:29-0800 "[[Image(http://i.imgur.com/nn6Yk.jpg, link=http://www.vnetweb.com/)]] prix finasteride 10 acheter propecia 5 milligrams finasteride prix canada propecia and avodart prix finasteride en france propecia demangeaisons vente finasteride allemagne propecia sans ordonnance arimidex finasteride acheter propecia en ligne prix du finasteride 5mg propecia 10 ou 20 mg prix finasteride en pharmacie achat propecia sur internet achat finasteride canada propecia and breast cancer finasteride mode d action propecia histoire acheter finasteride propecia litigation vente de finasteride au maroc propecia pendant 5 ans proscar finasteride propecia peau grasse finasteride 4mg propecia petit prix achat finasteride bon prix propecia usa acheter finasteride 20mg acheter propecia en ligne moin cher finasterid 5 mg effets secondaires propecia finasteride finastéride prix propecia 0.25mg finasteride ligne propecia wiki finasteride wikipedia propecia fer finasteride dhea propecia anger " weledobace 1 1626 Commander du Dapoxetine En Ligne not yet rated spam weledobace new 2012-12-04T06:18:49-0800 2013-04-02T04:55:03-0700 "[[Image(http://i.imgur.com/JVOsK.jpg, link=http://bit.ly/ZxGc2W)]] == '''[http://bit.ly/ZxGc2W Commander Médicaments sans Ordonnance]''' == --- http://www.wear-with-all.com/ priligy 5 mg prix dapoxetine 10 mg priligy generique canada dapoxetine 5 prix achat priligy original acheter dapoxetine moins cher priligy achat espagne dapoxetine 5 mg preis achat priligy france acheter du dapoxetine au québec priligy generique discount comparatif dapoxetine générique doctissimo priligy achat comparatif dapoxetine 4mg priligy 20 mg prix vente dapoxetine maroc priligy generique en pharmacie dapoxetine generique 20mg priligy 20mg pas cher vente générique dapoxetine priligy comparateur de prix dapoxetine achat internet vente priligy en belgique vente dapoxetine ligne priligy vente libre dapoxetine prix officiel priligy prix maroc acheter dapoxetine paris acheter priligy en toute securite vente de dapoxetine 5 mg priligy generique france achat dapoxetine achat de priligy en france acheter dapoxetine quebec achat priligy 10mg achat dapoxetine vente de priligy en belgique achat dapoxetine générique priligy prix de vente achat dapoxetine en martinique" weledobace 2 1579 Implement overlap and exhaustiveness checking for pattern matching good proposed-project new 2009-04-03T02:02:46-0700 2012-03-26T09:40:28-0700 "GHC's current checker for overlaps and exhaustiveness patterns is in need of an overhaul. There are several bugs and missing features. For example, GADTs are not taken into account. The project would involve the analysis of the current implementation, specification of bugs and desired features, design and implementation of an improved checker. The project is mentioned on: http://hackage.haskell.org/trac/ghc/wiki/ProjectSuggestions http://hackage.haskell.org/trac/ghc/ticket/595 = Interested Mentors = = Interested Students = * Eugen Jiresch ( e0204097(_atsign_)student.tuwien.ac.at ) * Saurabh Kumar ( saurabh.catch@gmail.com ) * Ben Ross (benjross@cs.washington.edu) " euschn 2 1582 LLVM optimisation passes / tables next to code good proposed-project new 2010-03-16T06:54:10-0700 2013-04-12T07:43:12-0700 "Project 1: LLVM optimisation passes ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1) Clearly identify issues with LLVM produced assembly code in the context of GHC * This can be done by examining how it compares to the native code generator on nofib benchmarks * You might be able to get some mileage from simply eyeballing the assembly and looking for ""obvious"" stupidity, like the ESP issue David spotted * The result of this part should be a simple set of Haskell test cases, the assembly they produced, what the assembly *should* be (roughly) and perhaps some notes on what might fix it 2) The second part would be to identify the lowest hanging fruit from those things identified in 1) and make changes to the LLVM output / write LLVM optimisations (apparently this is a joy to do, the LLVM framework is very well designed) to fix the issues Separating the project into two parts like this means that we could get something out of the project even if the student is unable to make significant progress with LLVM itself in the GSoC timeframe. Having a clear description of the problems involved + simple benchmark programs would be a huge help to someone attempting part 2) in the future, or they could serve as the basis for feature requests to the LLVM developers. Project 2: Tables next to code ~~~~~~~~~~~~~~~~~~~~~~ My feeling is that this is the more challenging of the two projects, as it is likely to touch more of LLVM / GHC. However, it is likely to yield a solid 6% speedup. It seems there are two implementation options: 1) Postprocessor ala the Evil Mangler (a nice self contained project, but not the best long term solution) 2) Modify LLVM to support this feature Other ~~~~~~ Either project could include looking at the impact of using llvm for link time optimisation, and a particularly able student might be able to attempt both halves. See also the thread at http://www.haskell.org/pipermail/cvs-ghc/2010-February/052606.html and David's thesis http://docs.google.com/viewer?url=http%3A%2F%2Fwww.cse.unsw.edu.au%2F~pls%2Fthesis%2Fdavidt-thesis.pdf" batterseapower 2 1584 ThreadScope with custom probes. good proposed-project new 2010-04-01T12:46:56-0700 2010-04-01T12:46:56-0700 ThreadScope lets us monitor thread execution. The Haskell Heap Profiler lets us monitor the Haskell heap live. HPC lets us monitor which code is execution and when. These should all be in an integrated tool for monitoring executing Haskell processes. dons 2 1585 Combine Threadscope with Heap Profiling Tools good proposed-project new 2010-04-01T12:48:16-0700 2010-04-02T04:36:01-0700 ThreadScope lets us monitor thread execution. The Haskell Heap Profiler lets us monitor the Haskell heap live. HPC lets us monitor which code is execution and when. These should all be in an integrated tool for monitoring executing Haskell processes. dons 2 1588 GHCi support for Cabal good proposed-project new 2011-02-13T16:06:11-0800 2011-02-13T16:06:11-0800 "GHCi is a real boon to productivity as it enables programmers to quickly compile and test their code. However, using GHCi in Cabal projects is not as simple as running `ghci ` as there's often a need to run preprocessors (e.g. hsc2hs) or rebuild dependencies first. You might also need to pass `.c` files, used in foreign imports, to `ghci`. Cabal could make all this much easier. It already knows how to rebuild/regenerate dependencies and create a set of options to pass to GHC. Task: Implement `cabal ghci`, which runs all the required steps (e.g. preprocessing) to create a source tree that can be loaded into GHCi. There's already a partial implementation that can serve as a starting point: http://hackage.haskell.org/trac/hackage/ticket/382 Sub tasks: 1. Refactor the flag generation code used to invoke `ghc` and use it to invoke `ghci` (see half finished implementation in the above ticket). 2. Implement a submodule that sets up the flags to `ghci`, similar to the modules that are used to call e.g. `ghc` or `ld`. 3. Implement `cabal ghci [MODULE NAME]`. " tibbe 2 1589 Benchmarking support for Cabal good proposed-project new 2011-02-13T16:29:07-0800 2011-02-13T16:29:07-0800 "If you want to use e.g. Criterion to write benchmarks for your library you'll need to maintain a separate Makefile for building and running your benchmarks and thereby duplicate lots of the work that Cabal already does. Task: Implement `cabal benchmark`, modelled after `cabal test`. Add a new benchmark stanza to Cabal e.g. {{{ name: mylib ... benchmark my-benchmark hs-source-dirs: benchmarks main-is: Benchmarks.hs type: stdio-1.0 build-depends: base, Criterion, mylib }}} Use a similar API split that we have for testing. The basic type of benchmark is just a simple executable that can be built and run. Results are output to stdout. The detailed interface would allow Cabal to see results of individual benchmarks and output these to e.g. a CSV file for later plotting/comparing. " tibbe 2 1590 Merge cabal-dev's sandboxed build support into Cabal good proposed-project new 2011-02-13T16:32:47-0800 2012-03-06T15:00:12-0800 "cabal-dev allows developers to build packages in their own sandboxes, using a separate package database for each. This allows for isolated builds and prevents breakages due e.g. package upgrades. Merging cabal-dev into Cabal allows us to share lots of code and makes the feature more accessible to developers. For more information, see the cabal-dev package http://hackage.haskell.org/package/cabal-dev and the corresponding Cabal ticket http://hackage.haskell.org/trac/hackage/ticket/780 " tibbe 2 1592 C++ -> Haskell FFI Generator using SWIG good proposed-project new 2011-03-14T15:07:05-0700 2012-04-04T08:48:43-0700 "I'd like to head up the implementation of a basic SWIG module that will properly generate appropriate C wrappers and hsc files that implement C++ classes, inheritance, and method calls appropriately. This would include generating type classes that emulate upcasting and public methods, proper handling of typedefs to correspond in Haskell, generating accessors for public class members, and creating equivalent constant variables in the Haskell code, and finally converting enums into data types. Thoughts?" dainanaki 2 1593 GHC Cross Compiler good proposed-project new 2011-03-18T17:31:46-0700 2011-03-28T14:26:13-0700 "It would be great if GHC supported cross compilation. GHC is reasonably well designed that adding cross compilation should be a reasonable student project. Using unregisterised mode, GHC's rts is largely unix portable C and the C code generator compiles Haskell to portable C. More interesting is the LLVM backend which supports both GHC's unregisterised and registerised modes and is by default capable of cross compilation. A large part of this project would be getting GHC to build such that it can cross compile. (e.g have the RTS built in two ways, one for the host platform and one for the target platform and have all libraries built both ways as well). Once this is done changing the actual ghc compiler to support cross compilation should be fairly straight forward. This work would contribute to one day having GHC support compiling to ARM platforms such as iOS, Android and Windows 7 phone." dterei 2 1598 Improve/rewrite HDBC backends good proposed-project new 2011-03-23T08:33:41-0700 2011-03-23T08:33:41-0700 "cf http://www.haskell.org/pipermail/haskell-cafe/2011-February/089535.html Although there are a number of issues with HDBC backends, the main one is that nearly everything goes through strings, even when drivers offer support for proper wire formats. This makes large inserts of selects much slower than necessary, and consume much more space than necessary as well. Along with this, there's no implementation of batched inserts. And finally, there's BLOB support. Additionally, the backends could be simplified. That is to say, that when HDBC was produced, there were no seperate bindings packages for most databases. So the backends include the bindings themselves. But now there are seperate packages that just provide simple bindings to e.g. sqlite and postgres. It would be very good to switch over to those libraries where possible, and where such packages don't exist to split out, e.g., the direct ODBC bindings to a separate package as well. This would help maintainability and future development. HDBC remains by far the most used Haskell database package, and now that John Goerzen has announced plans to switch to BSD licensing, there's no obstacle to its use across the board except for it's current limitations. It would be far better for the Haskell community to bring HDBC up to snuff as a single intermediate tool for accessing multiple database backends than to continue down the path of a profusion of competing single-db bindings that higher-level libraries are forced to access individually. Major points from the above email reproduced below: 1. I have no Windows development platform. I can't test the releases on Windows. Many Windows users don't have the skill to diagnose problems. These problems do eventually get fixed when a Windows user with that skill comes along -- and I appreciate their efforts very much! -- but it takes longer than it ought to. 2. The ODBC documentation is monumentally terrible, and the API is perhaps only majestically terrible, and it is not 100% clear to me all the time that I have it right. A seasoned ODBC person would be ideal here. 3. Issues exist with transferring binary data and BLOBs to/from at least PostgreSQL databases and perhaps others. There appear to be bugs in the backend for this, but BLOB support in the API may need to be developed as well. 4. Although the API supports optimizations for inserting many rows at once and precompiled queries, most backends to not yet take advantage of these optimization. 5. I have received dueling patches for whether foreign imports should be marked ""safe"" or ""unsafe"" on various backends. There seems to be disagreement in the community about this one. 6. Many interactions with database backends take place using a String when a more native type could be used for efficiency. This project maybe rather complex given varying types of column data in a database -- what it expects for bound parameters and what it returns. The API support is there for it though. " gbaz 2 1603 New frontend for HackageDB good proposed-project new 2011-03-28T15:36:08-0700 2011-04-05T02:41:19-0700 "This project would aim at building a new fronted for the HackageDB. There are many platforms out there that have a very good way to handle library/plugin distribution and I think there are several things that can be learned from there. By now the HackageDB has many libraries, but it is very confusing to find the right one and to find out which one to use. The are several things a new platform could contain: * Give users the ability to reputate themselfs within the community.[[br]] This should include a profile page for each user that shows uploaded packages from this user, reviews he wrote and informations about himself which he provides.[[br]][[br]] There should also be an activity overview for each user, where you can see the last things he did. I would also add the ability to ""follow"" other packages and users, which enables you to see specific activies and news. * Ability to rank packages by stars (0..5)[[br]] I think this makes more sense than thumbs up/down, since you can calculate a more detailed average ranking. * Ability to leave reviews for packages * Develop an algorithm that provides a rating for each package, based on downloads, average rating by users, dependencies, etc. Okay, this is just a wrapup of some ideas I carried around with me, please feel free to leave comments or thoughts." goto 2 1622 General FFI improvements good proposed-project julek new 2012-04-05T03:35:24-0700 2012-04-05T03:35:24-0700 " What I would like to do is to improve the integration of C/C++ with Haskell, particularly in calling Haskell from C/C++. Currently ghc is able to generate stubs to export functions whose arguments are simple types such as CInts into C/C++. The stub generated is always in an extern ""C"" clause due to the fact that ghc does not as yet implement the C++ calling conventions as defined in the ""The Haskell 98 Foreign Function Interface 1.0"" (http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi.pdf) So a first step would be to implement this calling convention to bring it up to speed with the above referenced report. This shouldn't be too hard and mostly involves implementing C++ name mangling conventions. Next, I would like to extend the stub generation so as to be able to deal with more complex types. The type systems in C++ and Haskell have many analogous syntaxes that can be easily exploited to provide strong compatibility and interoperability between the two languages. For example a simple type such as: data Foo = A | B Could be implemented as an enum in C/C++: enum Foo {A, B}; More advanced types that take arguments such as: data Tree = Node Left Right | Leaf Could be converted to a struct in C/C++: struct Tree { struct Tree* left; struct Tree* right; }; Types that have functions that act on them such as: data IntContainer = IntContainer Int getInt :: IntContainer -> Int getInt (IntContainer a) = a could have these functions automatically converted to C/C++: struct IntContainer { int a; }; extern int getInt_hs(IntContainer a); This also opens up the possibility of exploiting C/C++ name mangling conventions, to allow the _hs postfix I'm suggesting here to be eliminated. Haskell classes: class Arithmetic a where (+) :: a -> a -> a (*) :: a -> a -> a (-) :: a -> a -> a (/) :: a -> a -> a could be implemented using C++ functions with virtual members: class Monad { public: virtual Monad add(Monad a, Monad b); virtual Monad mult(Monad a, Monad b) virtual Monad neg(Monad a, Monad b); virtual Monad div(Monad a, Monad b); } All types of single/multiple instancing (i.e. either directly or through requirements of instances) would be implemented using single/multiple inheritance. Obviously, this example is rather contrived due to the conversion of the function names. The fact that the rules that govern function naming in Haskell are much more permissive than those of C/C++ might cause compatibility issues. This can be worked around by implementing a similar syntax to that currently used for function imports by the FFI. E.g..: foreign export ccall ""bind"" >>= :: CInt -> CInt Similar to: foreign import ccall ""f"" func :: CInt -> CInt The latter is the current syntax for imports. The name given for the export would be checked for legality in the namespace of the target language. Alternatively this could be done in an automated manner using some naming conventions as well as operator polymorphism, but this would probably sacrifice ease of use. Finally polymorphic Haskell functions/types can be implemented in C++ using templates. I would like to extend ghc to implement enhanced C/C++ stub generation using the methods described above as well as to generate Haskell stubs which describe the Haskell CType equivalents of the Haskell types defined, functions for conversion between the two and function stubs to convert the types, run the Haskell function and convert back as required. On top of this I'd like to write C/C++ libraries for dealing with most of the standard Haskell types such as Maybe, Either, etc... Finally, I'd like to work on ironing out any bugs that remain in the RTS when it is used in ""multilingual"" situations, as well as improving it's performance in this situation. I think that extending ghc to the level required by ""The Haskell 98 Foreign Function Interface 1.0"" specification and above would reap significant benefit to the Haskell community. The improved integration into C/C++ would open the door for this to happen for several other languages and would make Haskell more widespread. Many Haskell beginners are daunted by the falsely perceived complexity of working with Haskell IO and monads, but love using the massive advantages that the paradigm gives in a non monadic context. Due to this, simplifying the interoperability between Haskell and C/C++ would enable many of these users to stick around for longer and perhaps encourage them to eventually look deeper into the language. This would make the size of the community grow and make the use of Haskell more widespread, potentially reaping benefits for the community at large. I believe this could be implemented within the time frame given for GSOC. " julek 3 1537 Add NVIDIA CUDA backend for Data Parallel Haskell OK proposed-project new 2008-03-12T12:59:24-0700 2012-03-15T13:26:21-0700 "= Introduction = This ticket proposes to add a NVIDIA CUDA backend for the Data Parallel Haskell extension of GHC. = CUDA = To quote [http://en.wikipedia.org/wiki/CUDA Wikipedia] on CUDA: ''""CUDA (""Compute Unified Device Architecture""), is a GPGPU technology that allows a programmer to use the C programming language to code algorithms for execution on the GPU... CUDA gives developers unfettered access to the native instruction set and memory of the massively parallel computational elements in CUDA GPUs. Using CUDA, Nvidia !GeForce-based GPUs effectively become powerful, programmable open architectures like today’s CPUs (Central Processing Units). By opening up the architecture, CUDA provides developers both with the low-level, deterministic, and for repeatable access to hardware that is necessary API to develop essential high-level programming tools such as compilers, debuggers, math libraries, and application platforms.""'' To me, the exciting thing about CUDA is, if not the technology itself the high availability of CUDA enabled ""graphic"" cards. It is [http://www.gpgpu.org/sc2007/SC07_CUDA_1_Introduction_Luebke.pdf estimated] that by the end of 2007 there will be over 40,000,000 CUDA-capable GPUs! Also see the [http://www.nvidia.com/cuda NVIDIA CUDA site]. = Data Parallel Haskell = To quote [http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell the Haskell Wiki] on DPH: ''""Data Parallel Haskell is the codename for an extension to the Glasgow Haskell Compiler and its libraries to support nested data parallelism with a focus to utilise multi-core CPUs. Nested data parallelism extends the programming model of flat data parallelism, as known from parallel Fortran dialects, to irregular parallel computations (such as divide-and-conquer algorithms) and irregular data structures (such as sparse matrices and tree structures)...""'' = The project = It turns out people are actually already working on this. See [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/37390/focus=37509 this thread] on haskell-cafe. I actually think this project is to big for a Google Summer of Code project. It's more suitable for a Masters project I guess. However the project can be broken into several sub-projects that each address a different research question. Immediate questions that come to mind are for example: 1. How to compile DPH code to CUDA C code? 2. How to integrate normal Haskell code with CUDA backed DPH code? 3. '''''''''' = Interested Mentors = * ? = Interested Students = * ?" basvandijk 3 1541 Type-level programming library OK proposed-project new 2008-03-18T17:17:20-0700 2012-03-19T08:10:20-0700 "GHC's new support for type families provides a fairly convenient and rather expressive notation for type-level programming. Just like their value-level counterparts, many type-level programs rely on a range of operations (e.g., type-level lists and lookup functions) that are common to different applications and should be part of a standard library, instead of being re-implemented with every new type-level program. As a concrete example of a sophisticated use of type-level programming, see for example Andrew Appleyard's C# binding and its encoding of C#'s sub-typing and overload resolution algorithm: [https://www.cse.unsw.edu.au/~pls/thesis/aja-thesis.pdf] The primary goal of this project is to develop a support library for type-level programming by looking at existing type-level programs and what sort of infrastructure they need. A secondary goal is to acid test the rather new type family functionality in GHC and explore its current limitations. == Interested Mentors == * Manuel Chakravarty <[mailto:chak@cse.unsw.edu.au]> * Edward Kmett <[mailto:ekmett@gmail.com]> * Jacques Carette <[mailto:carette@mcmaster.ca]> == Interested Students == * Thomas Schilling <[mailto:nominolo@gmail.com]> * John Morrice <[mailto:spoon@killersmurf.com]>" chak 3 1543 Performant Amazon S3 interface OK proposed-project new 2008-03-19T12:03:41-0700 2009-03-28T00:08:03-0700 "Amazon S3 , http://aws.amazon.com/s3 , is an online storage system for internet applcations, providing a simple interface to store and retrieve data from anywhere on the web. The storage is highly scalable. This project would extend and improve the current s3 bindings, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hS3 to supprt bytestring based network, and the full features of the system. A simple, well structured interface should make it easy to store and retrieve large amounts of data in Haskell, using this service. == Interested mentors == Don Stewart == Interested Students == * abdullah <[mailto:abdullah.ak2002@gmail.com]>" dons 3 1544 Parallel programming benchmarking and benchmark suite OK proposed-project new 2008-03-19T12:13:22-0700 2008-03-26T13:57:47-0700 "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. What's missing from this set is experience building parallel applications using the parallel runtime, and high level parallelism primitives. 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. Improvements, to , say, Control.Parallel.Strategies , could result, as would a robust way of comparing parallel program performance between versions of GHC. == Interested mentors == * Don Stewart * Manuel Chakravarty * Roman Leshchinskiy == Interested Students == * Donnie Jones <[mailto:donnie@darthik.com]> " dons 3 1547 FFI bridge to Python OK proposed-project new 2008-03-19T15:10:02-0700 2008-03-22T08:15:01-0700 "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. This project would seek to develop an Python<->Haskell bridge, allowing the use of libraries on either side from each language. Python's C-based FFI makes this not too daunting, and the pay off could be quite large. Related projects: MissingPy and hpaste's light python binding. We may also be able to get this funded under the (many) python slots. == Projects to contact == This could be funded under the Python project umbrella. Applications should also be submitted to them. == Interested mentors == Don Stewart == Interested Students == Michal Janeczek <[mailto:janeczek@gmail.com]> " dons 3 1548 xmonad: compositing support OK proposed-project new 2008-03-19T15:20:42-0700 2009-03-23T11:39:20-0700 "[http://xmonad.org xmonad] is a tiling window manager for X11, and a [http://www.ohloh.net/tags/haskell popular] Haskell open source project with many users. This project would seek to integrate ""[http://en.wikipedia.org/wiki/Compiz compositing]"" support into xmonad, creating the first compositing tiling window manager. 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. 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. 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. 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. == Related material == The xmonad feature ticket for this: http://code.google.com/p/xmonad/issues/detail?id=19 == Organisations that might be interested == * Haskell.org * X.org * Portland State University Discussion will take place on the xmonad@ lists, in order to prepare good submissions to these groups. == Interested mentors == * Don Stewart" dons 3 1550 wxHaskell improvements OK proposed-project new 2008-03-19T15:51:23-0700 2009-03-06T00:06:23-0800 "wxWidgets are a funded project this year. Coordinate with them to work on wxHaskell improvements. Needs support from the wxHaskell team Things which look like they might be good summer of code projects: * Type-safe XRC support (and Document) * Fancy vector graphics support on top of wxGraphicsContext Things we want for wxhaskell 0.12 * better handling of extensions * Merge WXSOEGraphics code. Daan's ideas from http://haskell.org/haskellwiki/WxHaskell/Contribute * Add new widget abstractions to the WX library * Portable resources (see the page) * Create a good tree control / list control abstraction (perhaps the higher level libraries like autoforms?) Other ideas * Better Cabalization (This is not just wxHaskell project. We should collaborate with Cabal developper.) * Add com (ActiveX) support for Windows platform Todo: what else needs doing with wxHaskell? == Interested mentors == * Kido Takahiro" dons 3 1556 Further Parsec Improvements OK proposed-project new 2008-03-21T10:16:09-0700 2012-03-21T14:34:05-0700 "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: * Regaining lost speed for common cases such as ParsecT Identity with [] as input stream * 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 * Exploring further possibilities for optimisation * Building examples, documentation and support libraries for parsing tasks outside Parsec's traditional domain such as binary parsing == Interested Mentors == * Philippa Cowderoy (Philippa) <[mailto:flippa@flippac.org]> * Derek Elkins (ddarius) <[mailto:derek.a.elkins@gmail.com]> * Dmitry Astapov (ADEpt) <[mailto:dastapov@gmail.com]> == Interested Students == * Matej Kollar <[mailto:kollar.208115@gmail.com]> * Andre Murbach Maidl <[mailto:amaidl@inf.puc-rio.br]>" PhilippaCowderoy 3 1583 Language.C enhancements OK proposed-project new 2010-03-30T10:33:09-0700 2010-04-02T05:58:00-0700 "Three possibilities: 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. 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. 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." atomb 3 1591 GObject Introspection based static binding generator for Gtk2hs OK proposed-project new 2011-02-15T10:32:44-0800 2011-04-28T16:45:15-0700 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. arsenm 3 1596 A statistics library and environment OK proposed-project new 2011-03-21T03:49:58-0700 2011-04-06T03:22:20-0700 "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. 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. 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. 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). See also http://neilmitchell.blogspot.com/2011/03/experience-report-functional.html" KetilMalde 3 1597 Platform neutral GUI leading to ... hackage 3 OK proposed-project new 2011-03-22T08:59:28-0700 2011-03-23T00:53:02-0700 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 http://www.haskellers.com/user/858 . 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: http://www.reddit.com/r/haskell_proposals/comments/fkqmc/platform_neutral_graphics_and_user_interface/). My plan is to change Sourcegraph (http://hackage.haskell.org/package/SourceGraph) to parse all packages and display them with WebGL or a 3d-engine. tirili 3 1599 Improve several areas of EclipseFP OK proposed-project new 2011-03-24T14:37:38-0700 2011-04-01T12:15:06-0700 "Now, EclipseFP [http://eclipsefp.sourceforge.net/] 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: * Use the framework in Eclipse so that Haskell programmers could run Quickcheck, Smallcheck, HUnit test as Java programmers can run JUnit tests; * 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; * Try to provide more code completion or IntelliSense-like things; * 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) === Interested students === * Alejandro Serrano (serras) * Saurabh Kumar " serras 3 1600 Mathematical environment in Haskell OK proposed-project new 2011-03-24T15:04:05-0700 2012-03-20T17:24:41-0700 "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. My idea would be to follow the path of the Sage project [http://www.sagemath.org/]. 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... The project can have several parts: * 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) * Try to create bridges in Haskell as done in Sage * Find a way to ""import"" code in Sage (some algorithms are written just in them) to the Haskell counterpart For free, GHCi could be used as the next Matlab :D === Interested students === * Alejandro Serrano (serras) === Interested mentors === * Jacques Carette <[mailto:carette@mcmaster.ca]>" serras 3 1601 Library for the Arduino platform OK proposed-project new 2011-03-26T09:29:34-0700 2011-04-01T07:49:55-0700 "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. 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. If you have any thoughts or ideas please feel free to leave a comment." goto 3 1564 C Bindings to Haskell Values OK spam aluink new 2009-03-04T18:19:48-0800 2010-04-01T12:35:23-0700 "Write an tool to convert Haskell values, structures and functions, to C bindings. == Overview == * Convert Functions * Convert Data Structures * Typing * Documentation == Convert Functions == 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. == Convert Data Structures == 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. == Typing == 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? == Documentation == 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." aluink 3 36 HaRe in GHC OK proposed-project none new 2006-04-25T18:07:20-0700 2008-03-31T21:35:27-0700 "The Haskell Refactorer, [http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html HaRe], is a tool for refactoring Haskell systems. !HaRe handles multi-module systems, and respects layout and comments, so that refactored code looks as much as possible like the original. !HaRe covers the whole of Haskell 98, and uses the [http://www.cse.ogi.edu/PacSoft/projects/programatica/ Programatica] system for its front end functionality. Unfortunately, !HaRe does not cover the whole of GHC Haskell. The aim of this project is to port !HaRe to the GHC API, so that !HaRe can extend its user base (and indeed be used to refactor itself!). This project builds on a [http://www.cs.kent.ac.uk/pubs/2005/2266/content.pdf feasibility study by Chris Ryder], which covers much of the tricky preliminary investigative work. == Interested Mentors == * (2006) Simon Thompson <[mailto:s.j.thompson@kent.ac.uk]> == Interested Students == * (2006) Pepe Iborra <[mailto:mnislaih@gmail.com]> * (2008) Benedikt Huber <[mailto:benedikt.huber@gmail.com]> * (2008) Chaddaï Fouché <[mailto:chaddai.fouche@gmail.com]>" paolo 3 50 Visual Haskell OK proposed-project none new 2006-04-26T05:30:57-0700 2008-03-25T11:06:32-0700 "Visual Haskell is the Microsoft Visual Studio plugin for Haskell development, released in September 2005. There's lots to do in Visual Haskell. There are plenty of enhancements that could be added; some ideas are [http://darcs.haskell.org/vshaskell/TODO here]. == Interested Mentors == * Simon Marlow <[mailto:simonmar@microsoft.com]> == Interested Students == * Rafael Vargas <[mailto:rafavargas@ieee.org]>" simonmar@… 3 1111 Bring Hat tracing back to life OK proposed-project none new 2007-03-09T06:45:22-0800 2008-03-19T18:24:54-0700 "The [http://haskell.org/hat Hat] 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. The aims of this project would be (a) to fix Hat so that it adequately traces hierarchical library packages (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. (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. == Interested Mentors == * Malcolm Wallace (@ cs.york.ac.uk) == Interested Students ==" malcolm.wallace@… 3 1114 Sandboxed Haskell OK proposed-project none new 2007-03-11T13:14:45-0700 2009-02-11T07:47:45-0800 "[http://www.cse.unsw.edu.au/~dons/hs-plugins/ hs-plugins] 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: * A way to ensure that a dynamically compiled program does not use any unsafe primitives. * A way to limit the resources (clock cycles and RAM) used by an untrusted computation. 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. 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). == Interested Mentors == * ? == Interested Students == * Benja Fallenstein ([mailto:benja.fallenstein@gmail.com benja.fallenstein@gmail.com]) -- 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. * Brandon Wilson (xelxebar) <[bmw.stx@gmail.com]>" benja.fallenstein@… 3 1116 Haskell Qt binding generator OK proposed-project none new 2007-03-12T09:44:32-0700 2009-03-23T11:45:14-0700 "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. == Interested Students == * (2007) Soenke Hahn <[mailto:shahn@cs.tu-berlin.de]>" Wolfgang Jeltsch 3 1120 XML Schema implementation OK proposed-project none new 2007-03-16T10:05:23-0700 2012-03-23T01:52:10-0700 "XML Schema(http://en.wikipedia.org/wiki/XML_Schema) 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(http://en.wikipedia.org/wiki/WSDL) use it to define new data structures. This makes XML Schema a door-opener for the implementation of other XML technologies like SOAP. The project could include the following: * Implementing a XML Schema parser(using for example HaXML) * Building a tool for XML Schema -> Haskell code transformation(like the !DtdToHaskell tool included in HaXML) * Creating a verifier that checks if a document conforms to a XML Schema == Interested Mentors == Malcolm Wallace == Interested Students == Vlad Dogaru <[mailto:ddvlad*REMOVETHIS*@rosedu.org]> Saurabh Kumar <[mailto:saurabh.catch@gmail.com]> Marius Loewe <[mailto:mlo@informatik.uni-kiel.de]> David !McGillicuddy <[mailto:dmcgill9071@gmail.com]>" eq 3 1127 Machine learning library OK proposed-project none new 2007-03-20T15:11:50-0700 2012-03-20T17:21:44-0700 "'''Note that this was proposed some years ago, and any prospective student should first identify a suitable mentor, and discuss the details with her. ''' 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. 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. 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. == Previously Interested Students == * Anil Vaitla <[mailto:avaitla16@gmail.com]> (Matrix Decompositions, SVM, and HMM) * Andreas Launila (SVM and HMM) * Jiri Hysek (dvekravy) <[mailto:xhysek02@stud.fit.vutbr.cz]> (NN and GA) * Charles Blundell <[mailto:blundellc@googlemail.com]> (SVM, HMM, ID3/C4.5; already done NN, Q-learn, SOM, ~GA) * P !McArthur <[http://www.dysfunctor.org/about/]> (Hidden Markov Model) * Dave Tapley <[mailto:dukedave@gmail.com]> (Studying: <[http://www.cse.dmu.ac.uk/msccir/structure.html]>) * Ivan Dilchovski <[mailto:root.darkstar@gmail.com]> (currently doing graduation paper on NN) * Dinesh G<[mailto:g.dinesh.cse@gmail.com]> (SVM, PCA, SVD, Random Projection, Cluterings techniques) Currently doing my masters in Indian Institute Of Science. Area Of Interest: Machine learning * Moises Osorio <[mailto:wcoder.mx@gmail.com]> (Genetic algorithms) == Currently Interested Students == * Martin Boyanov <[mailto:mboyanov@gmail.com]> (HMM, k-means clustering, Naive Bayes,neural networks)" KetilMalde