From HaskellWiki
< HacBerlin2014
Revision as of 12:14, 26 September 2014 by Dreixel (talk | contribs)
Jump to: navigation, search

Here is a list of potential topics for HacBerlin2014, originally extracted from the notes participants gave when registering.

Please extend, update and refine this list!

  • Darcs, darcsden
  • cabal2nix
  • A GHC bug squashing race would be fun.
  • Perhaps also some GHC hacking.
  • ghc, extensible-effects, (progression), (complexity)
  • ghc-imported-from
  • I'd like to get to know the GHC codebase / become involved in compiler/RTS development
  • I'm interested in doing some work on pattern synonyms in GHC.
  • Not sure yet, I have some ideas for work on Cabal or Hackage.
  • cabal-install. Make the constraint solver more efficient.
  • Library maintenance. I'm going to try to make maintenance releases for a number of libraries and tools, including generics-sop, multirec, gdiff, tilt, lhs2tex
  • Some SaaS webapp, or some systems tool
  • most likely Haskell + FPGAs, but for it might be easier
  • A lazy evaluation Database called Gödel"
  • Omega 2 (theory and footwork)
  • I'm also interested in game / openGL programming
  • I've got some web development (backend / app server) projects of my on; sharing experience with other Haskellers about that would be nice.
  • Frankly, I haven't gotten my hands dirty on any larger projects yet. Nevertheless, I'd be glad to jump in anywhere a beginner isn't too much of a hassle!"
  • Frozone
  • dockercook
  • rocksdb-haskell, rocksdb haskell server
  • I am building a gossip message bus in Erlang + Thrift and would like to build a client in Haskell. No prior experience with Haskell so should be rather interesting.
  • I would like to implement a decision tree library in Haskell.
  • Not decided, yet. Was also thinking that universal Cabal file parsing library would be helpful. Most importantly something that preserves original formatting. Just a thought. :-)
  • TracWiki writer for Pandoc (or if some other project catches my eye...)
  • LambdaCube 3D Stunts (game remake with lambdacube) LambdaCube Stunts Resurrection
  • One of https://github.com/ocharles/engine.io https://github.com/meiersi/blaze-react https://github.com/ghcjs/ghcjs-vdom
  • Having not that much experience in Haskell, i'm interested in almost everything, that is within my comfort zone. An idea i have for some time now is to make Hackage a little friendlier by giving users the possibility to sort/filter search results by certain criteria. Like filtering out packages, that were lastly updated a couple of years ago or sort them by 'newest upload' first.
  • data synchronization (as in http://ipsit.bu.edu/documents/ieee-it3-web.pdf)
  • improved build system for Haskell (hermetic builds (e.g. http://blog.johantibell.com/2012/03/cabal-of-my-dreams.html)"
  • LensRef
  • LGtk
  • I am a beginner in haskell, have worked through the most chapters of the wikipedia-book on haskell. Monads I find not especially interesting, but complicated. Types are interesting. So I'm open for much.
  • whatever you let me work on ;)
  • Whatever project I'll be able to help with.
  • something neat. I'm very much a newbie, so I'll just see how I can help.
  • Infrastructure, Web, E-Commerce
  • I don't have a strong preference about that. i never visited a hackathon before so i think i have to see how everything works when i am at the hackathon.
  • also things related to DICOM file archiving.
  • Ontology Editor, 3d Tree Canvas,...
  • postgresql-crud (to be announced), monad-classes, wai-predicates, anything interesting.
  • Getting rid of cabal hell. Doing DevOps stuff and compiling a working tool chain. Continue "LYAH"
  • Parsing tools.
  • language-swift: Starting as new project. Library to analyse and generate code for Apple's new programming language Swift. Similar to language-c and hopefully at some point the base for something hlint like for Swift.

Project Proposal for the haskell Hackathon Berlin 2015

A Testcase generator for system tests. With as few lines as possible generate as most test scripts as possible, part test-cases are combinable. Language for generating the testcases: haskell, with embedded DSL. Language of the test scripts: ruby, python, perl, c++, ... (it depends) test target: an embedded device, a mail server, a web-service, ..., but at first no GUI.

The existing example: There exists a test generating tool named ""tedeso"" by Siemens. Tedeso has 2 major building blocks: - variables/instances of classes with attributes: The attributes can have different values and the test script is executed with all instances. Each test script uses one instance. - branching: do this or do this or do this: the different test scripts are generated by following the different pathes. Each test script is one path. - a GUI, with which you can draw a testcase. But this can be omitted. In my point of view, it is not practical. A test script written in a good embedded dsl is better readable and better comparable with older versions.

The haskell testcase generator shall go beyond Tedeso: It shall easily be possible to combine (parts of) testcases to build bigger ones. Haskell is good for that purpose, because the part test scripts are functions, without side effects. The testcases could have attributes, which say something of the condition or state that is fulfilled or reached by the (part-)test script.

Bigger challenges:

1.) If the attributes of the part test scripts ar cleverly chosen, can they form a kind of formal specification of the system under test?

2.)If someone asks, possibly after years, what the system under test does under certain circumstances, can you ask the set of your test programs what happens ? Possibly: "" Yes, we have tested it in 2015, and the test ran ok!"", without actually running the test, just by typing the specification of the question to your test environment ? A solution could be a database of test cases or a analyzation of the test programs (perhaps with template haskell? I do not know much about it.)

3.)Can one make a test case by saying: "" a.) Go to state X, in any possible way. b.) Do this special. (perhaps test a new requirement, that is just implemented) c.) After that you are in state Y. Do some arbitrarily chosen part-testcases begining with that state Y.""

The 2 major building blocks of tedeso, variables and branching, are easily done with haskell. That have I already programmed, as a beginner in haskell, who i am. But there seems to be much possible in testing with haskell. For Open source programs there is the need for good system test tools. When I look at open source source code, I do not find many test cases, if any. Perhaps could a easy usable system test environment improve the quality of open source software.

Pedro's working topics

I plan to be mostly working on Chordify-related stuff. But I will also discuss some GHC Generics stuff with Gabor and Andres, and I might have a look at some of the tickets on this list: https://ghc.haskell.org/trac/ghc/wiki/PedrosTickets

In general, if you're interested in some GHC hacking, I can try to help you get along the source code.

Also, I think it would be great to have Haskell implementations of the constant-Q transform and the reassignment spectrogram that are independent of the FFT implementation, and use REPA or Vector under the hood. If you happen to be interested in this, do get in touch.