- The Perl core
- Toolchain Projects
- DBIx::Class and related toolchain (irc.perl.org#dbix-class)
- SDL Perl / Perl Gaming - http://sdl.perl.org
- Catalyst - http://www.catalystframework.org/
- Moose - http://www.iinteractive.com/moose/
- KiokuDB - http://www.iinteractive.com/kiokudb/
- Plack - http://plackperl.org/
- Mojo/Mojolicious - http://mojolicious.org/
- Reflex and/or POE (Perl Object Environment) - http://poe.perl.org/
- BioPerl - http://bio.perl.org
- Perl toolchain modules
- Padre, the Perl IDE http://padre.perlide.org/
- Bricolage, a Perl-based enterprise-class content management system
- Rakudo Perl 6
- Semantic Web with Perl
- Perl Data Language
- Juicer Resources
Summer of Code 2012 Project Ideas
This is an incomplete list of what various Perl project could see students doing for this year's summer of code.
If you're a student looking for a project and you don't find anything interesting to you and appropriate for your skills, be creative! Project ideas not on this page are very welcome and even encouraged.
use #p5p on irc.perl.org to discuss ideas with the prospective mentors
Work on implementing a small Meta Object Protocol (MOP) for the Perl core - this would include introspection for classes, methods, and attributes. This probably also means implementing "class", "method", and "has" keywords. The MOP should simply store names and a hash ref of "additional info". This means that something like Moose could ask for an attr's name & hashref and then use that info to generate accessors and such.
This feature does not require incorporating accessor generation into the core, it's just about declaration.
Optional bonus feature: role declaration? method modifiers?
Possible mentors: Stevan Little (for design), insert core hacker here (for implementation)
MAD, which stands for Miscellaneous Attribute Decoration, is a a tool to that can be used to turn Perl code into something easier to process than raw perl source code. Possible applications of it include a Perl 5 to Perl 6 translator, syntax highlighters, or converters for old dialects of Perl into newer ones without changing the behaviour of the code.
Unfortunately, MAD is currently broken. This happens regularly when some of the perl internals change and the MAD code isn't updated accordingly, mostly due to the MAD test suite not being run when running the regular perl test suite.
Properly integrating MAD into the core, my moving it from the mad/ subdirectory to lib/, and having it's test suite ran by default would fix that issue, and is part of this project.
In addition, MAD currently outputs XML and, even worse, outputs invalid XML in some cases. Using XML for MAD is problematic as there's no XML parser in the core perl distribution. Changing MAD's output format to JSON, and making the output actually valid is also part of this project.
Improving extendability of Perl with C and C++ libraries Perl's standard mechanism for creating extensions written in C or C++, is called XS for "eXternal Subroutine". In a nutshell, the author writes some interface code in a dialect of C with additional directives. A preprocessor that also handles Perl <-> C type conversions then generates much of the C code necessary to hook into the Perl virtual machine. Unfortunately, the implementation of the preprocessor has not aged as well as the general idea. Specifically the way that authors specify how Perl data structures should be converted to C data structures (the "typemap") is rather clumsy. The task would be to design and implement a better type mapping system for use in Perl/XS. This task requires at least a good knowledge of Perl and C.
Possible mentors: Steffen Mueller, Florian Ragwitz
Work on the hierarchical reorganization proposed by brian d foy. This includes:
- moving and renaming all the core docs into categories like "language", "tutorial", "reference", "embedding/XS", "platforms" ** should some documents be available in multiple categories (many things are arguably reference & language docs, or reference & embedding, for example)
- adjusting core tools to find them under their new names
- providing backwards compat/deprecation for old names
- making sure manpage generation still works - pod/core/syntax becomes perlcoresyntax.man?
Possible mentors: brian d foy, Dave Rolsky
There's a large list of TODO entries in the perltodo documentation, although not all will be suitable as projects. They are grouped roughly in estimated order of difficulty, starting with tasks that only require Perl knowledge ahead of those which require more skills such as familiarity with C, or familiarity with C and XS. Pick one or more related items, and chat to #p5p about how you're going to resolve them. Remember that you need to complete the project successfully in 3 months if you are to receive the full payment, so proposing a project that would also require you to learn new skills from scratch is going to seriously hamper your chances of success.
The core Perl distribution ships with a large collection of modules for performing common (and not so common) programming tasks. Some of these, like strict or B provide stable access to important language features. Others, like HTTP::Tiny, are used by the core CPAN tools to install third-party distributions. There is a third category, too: code that is just bundled for historical reasons, because it seemed useful at the time. For example, File::CheckTree. The code in the core should be sorted out so that unneeded distributions can be deprecated and later purged. Any "may be purged" distribution should be verified as removable: the whole core should build and test with that code removed.
There are several more possibilities not listed in perltodo: Improve B::CC, fix and improve Jit, restructure the core to help [llvm] to do linker optimizations, implement core optimizations for typed arrays and hashes.
Possible mentor: Reini Urban
Create a proper CPAN Testers 2.0 client. This would entail, at minimum, the following:
- extracting the functionality of CPAN::Reporter and relevant parts of CPANPLUS into a new, unified client
- providing new, pluggable transport options to replace Test::Reporter, which is too email-focused to be useful going forward. At a minimum, this must support HTTP(S) transport and raw socket transport (per Test::Reporter::Transport::Socket
- submitting reports as structured data, using the various components available in CPAN::Testers::Report instead of only plain text
- using CPAN::Testers::Config to standardize configuration, and creating a CLI user-interface for configuration
Possible mentors: dagolden, bingos
Currently the DBIx::Class test suite stands at more than 250 files with over 23,000 individual tests. However most of these run against the test-bundled DBD::SQLite. Moreover the tests that do run on other RDBMS share a lot of identical code which is currently copy pasted from test to test.
The proposed task is to introduce a "schema iterator" facility, which can re-run a set of tests under multiple $schema's based on the current DSNs available in the environment. As a side effect the test files can be reorganized in a more coherent t/ hierarchy. The task does not include fixing all bugs that will pop out upon completion of this project :)
The massive amount of improvements over the past couple of years left the core documentation lagging behind. Many new features were documented only in the reference pods, without updates to the CookBook, FAQ and other manual sections. Moreover the CookBook itself is becoming large and unwieldy and could use a major overhaul.
The proposed task is to reorganize the CookBook similar to how the Moose project has organized theirs, and to touch up some of the more arcane sections of the core docs (e.g. ::Relationship / ::Relationship::Base ).
The task will require (re)acquainting with the more advanced features of DBIx::Class and working with the project core devs to establish a set of current best practices for reference in Introductory documents.
Extract the database introspection bits from the DBIx::Class::Schema::Loader::DBI subclasses (and ::DBI itself) and create a new CPAN module, I was thinking DBIx::Introspector, but whichever name you like is fine with me. This module would then be very helpful for the work on SQL::Abstract 2 and other Perl ORMs like Fey and Rose, or for any other reason where introspecting a database would be helpful.
Schema::Loader does not yet do proper introspection of views, Results for views are generated just like for tables. Ideally, it would extract the view SQL and create proper DBIx::Class::ResultSource::View Results. Some sort of SQL introspection for the purpose of matching the keys (primary, unique) of the source table and definining them for the view would also be nice, as a bonus feature!
Rewrite SQLA::Tree to emit/consume ASTs as per the SQLA specification. This will serve as a springboard for Data::Query implementation. The end goal is to allow for more robust and accurate SDQ/DDL parsing and interpretation.
You can find a list of SDL Perl project ideas here. They include things such as
- Game Engine
- Cross thread queuing for SDL_perl
- Game Physics
- and more!
use #sdl on irc.perl.org to discuss ideas with mentors.
use #catalyst-dev on irc.perl.org to discuss ideas with the prospective mentors, like t0m, konobi, kd, rafl and dhoss.
Split between application instance and request context to improve reusability
Refactor how configuration loading is done. Currently it requires the full application to be loaded, which makes it impossible to use the normal configuration tools in, for example, scripts that are supposed to spin up an application.
Catalyst::(Action|Controller)::REST help. This module is very useful but rather unwieldy at times, especially when combined with ::DispatchType::Chained. Would be nice to see a sane API come of it that allows either a transparent layer for REST API calls or a cleanly injectable API.
use #moose-dev on irc.perl.org to discuss ideas with the prospective mentors, like Sartak, t0m, and rafl
Make perl's overloading introspectable and modifiable using the meta object protocol. Prior art for this exists in MooseX::Role::WithOverloading, which could be ported to use the meta api for overloading, once it exists.
Work on moving parts of the meta object protocol from perl- to c-space to improve Moose performance during both compile- and runtime. A prototype for this already exists in the Moose-XS branch.
Work on metaclass serialisation in MooseX-Antlers. This also has a big potential for making Moose faster, by not having to compute or even load metaclasses most of the time.
Improve MooseX::Declare and MooseX::Method::Signatures. Performance could be greatly improved by adding the possibility to inline type constraint checks to Moose and MooseX::Types::Structured. There's also many missing features and minor bugs and edge cases that need to be addressed. Get in touch with #moose-dev for the details.
Improve Moose Exception handling by moving to a real exception framework. Prior work on this has been started several times so please get in touch with #moose-dev to pick up where they left off.
use #kiokudb on irc.perl.org for discussion
- Implement an asyncronous interface
- Improve performance
- Pick anything from http://github.com/nothingmuch/KiokuDB/blob/master/TODO
use #plack on irc.perl.org for discussion
- Build a middleware that implements Edge Side Includes (ESI). That involves both a parser+interpreter for the ESI language, as well as a caching middleware. Prior art for the caching part of the problem already exists at http://github.com/rafl/plack-middleware-cache/
use #mojo on irc.perl.org to discuss ideas with the author sri or other people out there
- Performance tuning the http/websocket implementation.
- Adding tests for things going wrong and adding nice error messages.
- Improving the reference documentation with small tutorials similar to Mojo::Template and Mojo::IOLoop.
(Suggested mentor: Rocco Caputo, possibly others, and the communities involved are very helpful.)
Reflex is a modern reactive library for Perl. It uses POE for asynchronous eventiness and Moose for a de facto standard OO.
- The project needs more hands to work out the design and work on the implementation. A lot of this work might be incidental development as part of a larger project.
- Check out the project roadmap for inspiration.
- Use #reflex on irc.perl.org #reflex to discuss ideas with developers and the community.
Refactor POE::Loop into a stand-alone, sessionless callback API that Reflex and other projects can use directly.
- Something along the lines of
on_input($handle, \&do_something)would be nice. Reflex and other projects would benefit greatly.
- Use #poe on irc.perl.org to discuss ideas with developers and the community.
- Something along the lines of
SDL bindings for POE. POE developers have been approached to integrate SDL's main loop with POE. We could use a dedicated pair of hands for that. Find us in irc.perl.org #poe.
- Project List: A well-written goldmine of info for possible BioPerl projects.
Enhance (fix?)so that it can properly display Arabic (right-to-left, with character joining and shaping)
Statistics::RI - create a DBI-like interface to R as a replacement for Statistics::R
CPAN/OS package interaction
Improve the existing Qt4 bindings at http://code.google.com/p/perlqt4/ and make them releaseable.
Update Symbian Perl, and possibly provide interfaces to Symbian OS features (download movies) - http://sourceforge.net/projects/symbianperl/
We created a page with a number of project ideas on our own wiki. Please see them here
These are projects that require a solid understanding of Perl and the other technologies mentioned, and a commitment to seeing them through. Each has a dedicated mentor to provide guidance and support to one or more students working to complete the project.
Full text searching. Either via Solr (Mentor: Alex Krohn) or tsearch2 (Mentor: David Wheeler). Preferably, both would be implemented.
More AJAXification of the Bricolage UI: useful keyboard shortcuts, integrated spell-check, and the like. The sky’s the limit on the ideas that could be applied here (Mentor: Matt Rolf)
Document conversion: enable story creation by uploading a specific document type, e.g.: Open Office document, Word document, etc. (Mentor: Alex Krohn & Phillip Smith)
Add a REST interface / API to Bricolage (Mentor: David Wheeler)
Modernize/Simplify the Bricolage install process via a Module::Build-based installer. (Mentor: David Wheeler)
Modify version storage to store deltas instead of complete copies. (Mentor: David Wheeler)
Port Bricolage from mod_perl to Plack/PSGI
Addition of event-triggered callbacks (Mentor: David Wheeler)
Improvements to Bricolage's SOAP interface with the objective of providing access to objects, contributors, and more search parameters. (Mentor: Greg Heo)
Creation of an API "mover" or action to allow Bricolage to more easily publish to other systems that have Web / REST APIs. (Mentor: Phillip Smith)
Port Bricolage to SQLite and Firebird. (Mentor: David Wheeler)
possible projects for Dancer:
- local::lib support, so a complete application could be packaged with all the dependancies
- redesign the way we handle multiple Dancer applications inside a single app.psgi
- streaming support (there is already an issue and some discussions about this feature
- rewrite dancer's script to provide an API for plugins to extends the default behavior
possible mentors: franck, sawyer
Use #perl6 on irc.freenode.org to discuss ideas.
sprintf routines are well known from C, and Perl 6 has them too. But there are several factors which makes it unfeasible to just use the C implementation in the long run. For example Perl 6's
Inttype supports arbitrarily sized integers, which C doesn't. Also a formatter like
%d needs to coerce to
Int, and how that works is very specific to Perl 6.
So, a student could write a custom implementation of
sprintf that is specific to Perl 6's needs, along with tests for them.
The routine can be written in pure Perl 6, and preferably in a way so that it can be used by Rakudo and Niecza, the two main Perl 6 compilers.
Possible mentors: Moritz Lenz ("moritz" on freenode), Carl Mäsak ("masak" on freenode).
Rakudo now has a sufficiently strong and extensible mechanism for calling C functions that it's feasible to implement bindings to various relational databases. Mysql, Postgres and SQLite are high on our wish list.
MiniDBI already provides some infrastructure, and a partially working mysql backend. It probably has suffered from some bit rot, but not too much.
An interested student could clean up MiniDBI and bring several backends into a usable state. This would be a huge benefit to the whole Perl 6 ecosystem. Bonus points for wiring up some C# backends to work with niecza.
Most of the code would be written in Perl 6, with some bits of C hacking being probably required.
Possible mentors: Jonathan Worthington (jnthn), Moritz Lenz (moritz)
Make a binding from Perl 6 to an XML parsing library. Make it possible to call out to the library, and to have it return with a data structure representing the parsed XML.
One possible possibility here is to have the returned data structure be in its native C form, i.e. not necessarily wrapped in Perl 6 objects. Making use of jnthn's work on representations, it would still be possible to interact with the data structure, treating it as real Perl 6 objects with attributes, methods etc. This would create a best-of-two-worlds situation, giving us the speed of C and the convenience of Perl 6.
Currently there is just a small set of Perl::Critic policies. This set should be enhanced. Therefor one can add new policies.
This involves to study the OTRS code and define rules of "how to program in OTRS style".
The results of the package analysis should be shown on the website.
Suggested Mentor: Renée Bäcker
The CMDB allows currently no overall view of alls CIs and relations you may know from a network plan. It would be nice having this implemented in OTRS ITSM. For this purpose existing tools like graphviz.org ma be used.
Suggested Mentor: Renée Bäcker
Currently it's very risky to interrupt one's work in OTRS. E-Mails not sent are easily getting lost because there's no option to save them. Therefore it needs an option to set emails to draft:
In AgentTicketCompose - next to the "send" button, there's another button "draft". The new article is stored in the data base as if it was sent, just marked as a draft. Possible states for the ticket are: new, open, pending.
New articles (like notes or other emails) can be added to the ticket as usual. The new articles are stacked behind the draft in correct order.
Drafts not sent are accessible through the navigation bar, like locked or watched tickets.
A saved draft can either be deleted (which simply removes the entry from the db) or sent. The later case deletes the 'draft' maker in the data base and resets the time stamps to current, so the former draft becomes a standard email article at the current position in the ticket.
Optional: Every queue gets access right options called 'supervise' and 'trainee' f.e.. Trainees cannot but set emails to draft. Supervisors can access and send draft tickets of all agents. This would be a really helpful feature to train new agents.
Suggested Mentor: Renée Bäcker
Use #perlrdf on irc.perl.org to discuss ideas.
- Implement the Linked Data API using RDF::Trine and friends.
- Bridging more high-performance triple-stores.
- Optimizations in RDF::Query.
- Joining OWL::DirectSemantics with FaCT++
- Use existing CPAN modules to create a comprehensive Linked Data server with derefenceable 303-URIs, CORS, dumps, SPARQL endpoint, WebID, sitemap, voiD, etc. It should also support caching and be deployable in a high-volume video search environment. The community is come pretty far on this, so it may be solved before the summer, but if not, it'll be great if someone picks it up.
- A Dependency Injection container - alternative to Bread::Board. Check all the design possibilities. Maybe a more lightweight approach, or something with scopes?
(Suggested Mentor - Maybe Stevan? He should know what alternative design paths he did not follow when writing B:B).
- Category: Translation
- Difficulty: Easy
- Duration: 2 hours to 2 days
- Mentor: firstname.lastname@example.org
OpenWebMail translation is handled through PO files. PO files are very easy to work with by using the POEdit software. By following our simple instructions anyone can create a translation, or update an existing translation with very little technical know-how.
- Category: User Interface
- Difficulty: Medium
- Duration: 4 days
- Mentor: email@example.com
We're always interested in new icon sets. You can start with the example iconset and change the icons in a paint program like Adobe Photoshop to make your own set. Adaptations of existing open source iconsets are also welcome. Images in the iconsets can be jpg, gif, or png files. You can visit our test installation to see how and where the icons are used in the interface.
- Category: User Interface
- Difficulty: Hard
- Duration: 5 days
- Mentor: firstname.lastname@example.org
Our system now supports complete separation of logic and presentation, so our layouts need updating. Our HTML is still using table based layouts. A student familiar with HTML can take our table based classic layout set with HTML::Template markup and create a new div based layout. Try one or several different areas of our interface, such as the calendar or the webdisk.
The student working on this project will be provided with an area where they can upload their layout for testing.
This is a summary of ideas that are being discussed on the PDL GSoC wiki page. Interested students should join the PDL developers mailing list. Some of these ideas require only Perl coding skills. Others require using PDL::PP (a C-like extension language for PDL), while others may require writing code in C.
- Expand and enhance PDL's help database API
- Design and implement PDL::Expt
- PDL equivalent of Matlab's signal processing toolkit
- Full 64 bit support
- Make PDL threadsafe
- Update PDL's FFTW bindings to FFTW3 (currently FFTW2)
- Expand PDL's GSL bindings to full coverage
- Add memory mapping support for Windows (currently only works for Linux and Mac)
- Python/Numpy + Perl/PDL
- Add more data reading/writing formats
- Ongoing work on PDL's new 2D plotting library (PDL::Graphics::Prima)
- Create PDL Bindings to the OpenCV juicer library
Quellelettre [masticating juicer reviews] juicer reviews masticating juicer reviews Twin gear juicer reviews centrifugal juicer best citrus juicer super angel 5500 review Omega 8006 review Omega vrt350hd review Breville Masticating Juicer Juicer Blender Combo Best Stainless Steel Juicer
Showing changes from previous revision.