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:
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:
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
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
use #plack on irc.perl.org for discussion
use #mojo on irc.perl.org to discuss ideas with the author sri or other people out there
(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.
Refactor POE::Loop into a stand-alone, sessionless callback API that Reflex and other projects can use directly.
on_input($handle, \&do_something) would be nice. Reflex and other projects would benefit greatly.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.
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)
Medium-sized project are excellent for students with a intermediate understanding of the described technology (AJAX, Perl, Javascript, ASP, SQLlite, Firebird, etc.) and a willingness to learn.
Port Bricolage from mod_perl to Plack/PSGI
Add support for Javascript templating. Other possible templating additions are Mason 2, EmbPerl, XSLT, JSP, ASP.NET, ERb, and Cheetah. If the templating system isn’t written in Perl, you’ll be able to borrow from the work done on PHP Sandwich the project started to allow PHP templating in Bricolage. (Mentor: David Wheeler)
Workspace improvements as described here and here (Mentor: Matt Rolf)
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:
possible mentors: franck, sawyer
Use #perl6 on irc.freenode.org to discuss ideas.
sprintf routineThe printf and 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.
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.
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.
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.
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