GSOC Project Ideas

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GSOC Project Ideas

Allan Gardner
I went through the GSOC trac, most of the Haskell IRC logs, and the Haskell idea reddit. So now I have a list of ideas (grouped by category):

infrastructure:
  • C++ integration (e.g. finish https://github.com/ofan/hqt https://github.com/ofan/fficxx )
  • Ada/Python/... integration
  • gobject bindings (gtk2hs stuff)
  • cabal improvements - Haddock flags (https://github.com/haskell/cabal/issues/1585), custom setup improvements (https://github.com/haskell/cabal/issues/948), some sort of plugin system for tests/docs/other random things (BNFC), clean up and merge parallel build code, package management, ...
  • Hackage2 improvements - voting, rewrite auth system, speed up reverse-deps enough to enable on main site, package wiki/comments, deprecations w/ links, create haddock even if the package doesn't build, ...
  • scale up Hoogle so it can search all of hackage by default
  • scoutess work (integration with with hackage, ghc snapshots, ...)
libraries:
  • email/PIM library (MIME, imap, ical, XMPP, WebDav, ... probably make use of a lot of old HaskellNet code)
  • comprehensive Date/Time API - there are lots of Hackage libs, but none do e.g. internationalization - aim to be backwards-compatible with time
  • highlight code using inferred types - HsColour + haskell-src/type-exts ? (maybe not enough for a GSOC?)
  • implement miscellaneous concurrent data structures
  • darcs improvements (performance, storage, ...)
  • fix pandoc conversion issues
  • ... (there were a lot of other libraries, but one of the blog posts said not do a library project because hackage already has too many and designing a good API from scratch is hard)
GHC project ideas:
  • package improvements - finish multiple package stuff, sign and verify packages, ...
  • port GHC build system to shake (faster, progress indicators, written in Haskell, ...)
  • implement something like ccache or distcc for GHC
  • rewrite the GHC pattern overlap/exhaustiveness analysis (https://ghc.haskell.org/trac/ghc/ticket/595, 10 years old!)
  • make GHC deterministic (refactor Unique + other nondeterminism sources, make a pure parser and/or typechecker API)
  • port Hat to the GHC api and integrate it into GHCi's :trace mode so omniscient debugging is available by default
  • implement typed core as another IL, either above or below old-core ("Types are Calling Conventions" paper)
  • other type-level programming library/project (units, extended arithmetic solver, true dependent types, linear types, ...)
GHC backend-ish:
  • customizable RTS - remove unused RTS functions, write your own concurrency primitives, ...
  • resurrect Immix patches and try to get incremental GC
  • implement loop unrolling in GHC
  • allow LLVM phases to be written in Haskell (bindings already used, so it's just dealing with the FFI's and GHC's options handling...)
I've tried putting these by two people (edwardk and carter) on #haskell-gsoc, and they both said that all the GHC ideas are too hard for a GSOC. Can I get a third opinion?

Also, please tell me if I left anything important out (I see a Yi proposal on this mailing list; that would be in the ... in libraries).

Finally, some sort of idea of which ideas are most likely to get accepted would be helpful. https://docs.google.com/forms/d/1rEobhHwFpjzPnra9L1TmrozWNFFyAVNPmdUMCcT--3Q/viewanalytics says the top priorities are GHC, Cabal, and Hackage, so since GHC is (apparently) out I guess that means I should look more at my Cabal, Hackage, and Hoogle ideas... is this sensible?

-- Allan Gardner

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GSOC Project Ideas

Jason Dagit-3



On Mon, Mar 10, 2014 at 9:31 PM, Allan Gardner <[hidden email]> wrote:
 
I've tried putting these by two people (edwardk and carter) on #haskell-gsoc, and they both said that all the GHC ideas are too hard for a GSOC. Can I get a third opinion?

I absolutely agree. The thing about GSoC is that the time is short and relative to that the proposals tend to be ambitious. To make the best of the time you have, it's really important to understand what changes need to be made and to have a pretty solid idea of how you'll implement it.

Of course, that's not the full story. GSoC is also an important mentoring opportunity as well. So you're not expected to know everything or all the technical details. Just keep in mind the time goes fast and that you probably won't have much time left if you need to spend time getting up to speed.

The exception would be if you have previous experience with modifying ghc. In that case, it might be reasonable to do a ghc-based proposal.

I hope that helps,
Jason

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GSOC Project Ideas

Luite Stegeman
In reply to this post by Allan Gardner
I've compiled a list of ideas for my current pet project, GHCJS [1] (Haskell to JavaScript compiler). While it's not exactly a central part of the Haskell ecosystem, it could be a fun compiler project to work on. Since it's a cabal package and the RTS is written in JavaScript, it's much more accessible than GHC itself.

GHCJS' evaluation model is quite close to GHC's, with lightweight threads, dynamically growing stacks, (async) exceptions, lazy IO, MVar, weak refs and all. This year I'm hoping to get some extra tooling for GHCJS that can also benefit Haskell in general.

One of the projects on the list is tracing/stepping through Haskell code, compiled by GHCJS, in the browser. I did a one evening experiment last year (with a now ancient GHCJS) and that already looked quite interesting [2]. The goal is to add interactivity and a nice user interface, with better rendering of the heap and stack data structures. Another useful thing would be profiling support: In the browser it'd be much easier to build a GUI that lets you pause a running program and collect memory allocation data from some specific thing you're interested in (for example pushing a single event through an FRP system).

The new tools would go well with Dan Frumin's last year's interactive-diagrams [3] GSoC project that runs or compiles Haskell code in a sandbox on the server. If we just upgrade the tools in the sandbox, users could paste some Haskell in the pastebin and immediately step/trace through the evaluation for example. Interactive-diagrams already has the ability to automatically show input fields or select boxes for users to supply the arguments if the input is a function.

While not for beginners, I think that students with reasonably good Haskell and JavaScript skills and some interest in RTS internals should be able to build something that's useful (and I have a good idea of what's going to be involved in both projects). The list [1] has more ideas, if anyone is interested in discussing projects, come to IRC, #ghcjs or #haskell-gsoc on freenode, github tickets / email also welcome.

luite

[3] http://paste.hskll.org/ (sorry if it's down, one of the hdds in the server died recently, i'm moving everything over to a faster new server)


On Tue, Mar 11, 2014 at 5:31 PM, Allan Gardner <[hidden email]> wrote:
I went through the GSOC trac, most of the Haskell IRC logs, and the Haskell idea reddit. So now I have a list of ideas (grouped by category):

infrastructure:
  • C++ integration (e.g. finish https://github.com/ofan/hqt https://github.com/ofan/fficxx )
  • Ada/Python/... integration
  • gobject bindings (gtk2hs stuff)
  • cabal improvements - Haddock flags (https://github.com/haskell/cabal/issues/1585), custom setup improvements (https://github.com/haskell/cabal/issues/948), some sort of plugin system for tests/docs/other random things (BNFC), clean up and merge parallel build code, package management, ...
  • Hackage2 improvements - voting, rewrite auth system, speed up reverse-deps enough to enable on main site, package wiki/comments, deprecations w/ links, create haddock even if the package doesn't build, ...
  • scale up Hoogle so it can search all of hackage by default
  • scoutess work (integration with with hackage, ghc snapshots, ...)
libraries:
  • email/PIM library (MIME, imap, ical, XMPP, WebDav, ... probably make use of a lot of old HaskellNet code)
  • comprehensive Date/Time API - there are lots of Hackage libs, but none do e.g. internationalization - aim to be backwards-compatible with time
  • highlight code using inferred types - HsColour + haskell-src/type-exts ? (maybe not enough for a GSOC?)
  • implement miscellaneous concurrent data structures
  • darcs improvements (performance, storage, ...)
  • fix pandoc conversion issues
  • ... (there were a lot of other libraries, but one of the blog posts said not do a library project because hackage already has too many and designing a good API from scratch is hard)
GHC project ideas:
  • package improvements - finish multiple package stuff, sign and verify packages, ...
  • port GHC build system to shake (faster, progress indicators, written in Haskell, ...)
  • implement something like ccache or distcc for GHC
  • rewrite the GHC pattern overlap/exhaustiveness analysis (https://ghc.haskell.org/trac/ghc/ticket/595, 10 years old!)
  • make GHC deterministic (refactor Unique + other nondeterminism sources, make a pure parser and/or typechecker API)
  • port Hat to the GHC api and integrate it into GHCi's :trace mode so omniscient debugging is available by default
  • implement typed core as another IL, either above or below old-core ("Types are Calling Conventions" paper)
  • other type-level programming library/project (units, extended arithmetic solver, true dependent types, linear types, ...)
GHC backend-ish:
  • customizable RTS - remove unused RTS functions, write your own concurrency primitives, ...
  • resurrect Immix patches and try to get incremental GC
  • implement loop unrolling in GHC
  • allow LLVM phases to be written in Haskell (bindings already used, so it's just dealing with the FFI's and GHC's options handling...)
I've tried putting these by two people (edwardk and carter) on #haskell-gsoc, and they both said that all the GHC ideas are too hard for a GSOC. Can I get a third opinion?

Also, please tell me if I left anything important out (I see a Yi proposal on this mailing list; that would be in the ... in libraries).

Finally, some sort of idea of which ideas are most likely to get accepted would be helpful. https://docs.google.com/forms/d/1rEobhHwFpjzPnra9L1TmrozWNFFyAVNPmdUMCcT--3Q/viewanalytics says the top priorities are GHC, Cabal, and Hackage, so since GHC is (apparently) out I guess that means I should look more at my Cabal, Hackage, and Hoogle ideas... is this sensible?

-- Allan Gardner

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GSOC Project Ideas

Brent Yorgey-2
In reply to this post by Allan Gardner
I'd like to point out that we also have a list of diagrams-related
projects here:

  http://www.haskell.org/haskellwiki/Diagrams/Projects

Some (though not all) of them would make good GSoC projects,
especially those that push diagrams more in the direction of being a
useful general-purpose tool for other Haskellers, or result in
spinning off useful general-purpose Haskell packages.  Diagrams is a
lot of fun to work on and we had two successful diagrams-related GSoC
projects last summer (one creating an interactive diagrams pastebin,
http://paste.hskell.org/, which also resulted in spinning off several
libraries; and one adding a diagrams backend for the Chart library).

Some particularly good potential projects include:

  - Implementing a general graph-drawing library on top of diagrams
    (note this doesn't include doing graph *layout*, just drawing; but
    could include making it easy to e.g. use graphviz to do the graph
    layout and diagrams to do the drawing).

  - Converting SVG files to diagrams and/or improving diagrams' SVG
    output (optimizing the size of generated files, adding features
    like grouping for transparency, node ids, etc.)

  - Adding the ability to edit diagrams (e.g. "make everything black
    and white" or "make all the circles 50% bigger"); this is a big
    missing feature and would involve some fun gymnastics with zippers
    and lenses.

We're happy to discuss these or other ideas on the #diagrams IRC
channel.

-Brent

On Mon, Mar 10, 2014 at 10:31:02PM -0600, Allan Gardner wrote:

> I went through the GSOC trac, most of the Haskell IRC logs, and the Haskell
> idea reddit. So now I have a list of ideas (grouped by category):
>
> infrastructure:
>
>    - C++ integration (e.g. finish https://github.com/ofan/hqt
>    https://github.com/ofan/fficxx )
>    - Ada/Python/... integration
>    - gobject bindings (gtk2hs stuff)
>    - cabal improvements - Haddock flags (
>    https://github.com/haskell/cabal/issues/1585), custom setup improvements
>    (https://github.com/haskell/cabal/issues/948), some sort of plugin
>    system for tests/docs/other random things (BNFC), clean up and merge
>    parallel build code, package management, ...
>    - Hackage2 improvements - voting, rewrite auth system, speed up
>    reverse-deps enough to enable on main site, package wiki/comments,
>    deprecations w/ links, create haddock even if the package doesn't build, ...
>    - scale up Hoogle so it can search all of hackage by default
>    - scoutess work (integration with with hackage, ghc snapshots, ...)
>
> libraries:
>
>    - email/PIM library (MIME, imap, ical, XMPP, WebDav, ... probably make
>    use of a lot of old HaskellNet code)
>    - comprehensive Date/Time API - there are lots of Hackage libs, but none
>    do e.g. internationalization - aim to be backwards-compatible with time
>    - highlight code using inferred types - HsColour + haskell-src/type-exts
>    ? (maybe not enough for a GSOC?)
>    - implement miscellaneous concurrent data structures
>    - darcs improvements (performance, storage, ...)
>    - fix pandoc conversion issues
>    - ... (there were a lot of other libraries, but one of the blog posts
>    said not do a library project because hackage already has too many and
>    designing a good API from scratch is hard)
>
> GHC project ideas:
>
>    - package improvements - finish multiple package stuff, sign and verify
>    packages, ...
>    - port GHC build system to shake (faster, progress indicators, written
>    in Haskell, ...)
>    - implement something like ccache or distcc for GHC
>    - rewrite the GHC pattern overlap/exhaustiveness analysis (
>    https://ghc.haskell.org/trac/ghc/ticket/595, 10 years old!)
>    - make GHC deterministic (refactor Unique + other nondeterminism
>    sources, make a pure parser and/or typechecker API)
>    - port Hat to the GHC api and integrate it into GHCi's :trace mode so
>    omniscient debugging is available by default
>    - implement typed core as another IL, either above or below old-core
>    ("Types are Calling Conventions" paper)
>    - other type-level programming library/project (units, extended
>    arithmetic solver, true dependent types, linear types, ...)
>
> GHC backend-ish:
>
>    - customizable RTS - remove unused RTS functions, write your own
>    concurrency primitives, ...
>    - resurrect Immix patches and try to get incremental GC
>    - implement loop unrolling in GHC
>    - allow LLVM phases to be written in Haskell (bindings already used, so
>    it's just dealing with the FFI's and GHC's options handling...)
>
> I've tried putting these by two people (edwardk and carter) on
> #haskell-gsoc, and they both said that all the GHC ideas are too hard for a
> GSOC. Can I get a third opinion?
>
> Also, please tell me if I left anything important out (I see a Yi proposal
> on this mailing list; that would be in the ... in libraries).
>
> Finally, some sort of idea of which ideas are most likely to get accepted
> would be helpful.
> https://docs.google.com/forms/d/1rEobhHwFpjzPnra9L1TmrozWNFFyAVNPmdUMCcT--3Q/viewanalyticssays
> the top priorities are GHC, Cabal, and Hackage, so since GHC is
> (apparently) out I guess that means I should look more at my Cabal,
> Hackage, and Hoogle ideas... is this sensible?
>
> -- Allan Gardner

> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GSOC Project Ideas

Brent Yorgey-2
On Tue, Mar 11, 2014 at 11:27:31AM -0400, Brent Yorgey wrote:
> projects last summer (one creating an interactive diagrams pastebin,
> http://paste.hskell.org/, which also resulted in spinning off several

Whoops, that should be

  http://paste.hskll.org

Although it's (temporarily) down at the moment, oh well. =)

-Brent
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GSOC Project Ideas

Michel Kuhlmann
In reply to this post by Allan Gardner
I would like to see gitit2 [1] replacing gitit [2].

gitit2 uses yesod as a foundation; currently not all features of gitit
are implemented yet; despite from that, it is not up-to-date  with current
yesod (not compiling).

The old gitit has quite some bugs; and it is not easy to extent it.

-Michel

[1]: https://github.com/jgm/gitit2.git
[2]: https://github.com/jgm/gitit.git
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GSOC Project Ideas

Carter Schonwald
I don't think gitit2 is ready for a Gsoc (and I say that as Somone who might be taking over working on it...)

On Friday, March 14, 2014, Michel Kuhlmann <[hidden email]> wrote:
I would like to see gitit2 [1] replacing gitit [2].

gitit2 uses yesod as a foundation; currently not all features of gitit
are implemented yet; despite from that, it is not up-to-date  with current
yesod (not compiling).

The old gitit has quite some bugs; and it is not easy to extent it.

-Michel

[1]: https://github.com/jgm/gitit2.git
[2]: https://github.com/jgm/gitit.git
_______________________________________________
Haskell-Cafe mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-Cafe@haskell.org&#39;)">Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe