January 2015 Archives

The Grants Committee has concluded the voting of the January round.

Proposal in this round

Voting Results


Definition of the score is found in 3.2 of the rules.


While it is always difficult to make decision on grant proposals, this was a particularly tough one. We understand this is a serious project with good amount of interest from the community including multiple code committers.

The main reason that led us to the negative conclusion is as follows: there are already plenty of web frameworks and CMSes. It is not a bad thing to have another one but we will not be able to fund this "another one" which may or may not attract new users given there are just too many choices. For this specific area with high competition, we tend to spend money on marketing, promotion or tutorial of software which is completed, established and/or adopted. Otherwise on initiative to solve a specific problem.

We hope the success of Ado.

Next round

The next round is in March. You can submit proposals now.

Deadlines Approaching!

No Comments

As you prepare for this year's YAPC::NA be sure to take advantage of the early bird rates being offered by Little America Hotel in Salt Lake City! Reserve your room(s) prior to March 1st 2015 and receive a nightly discount.

After March 1st, rates will go up $20/room/night. So be sure to book today. The reservation link can be found at yapcna.org/yn2015/location.html.


Don't forget that submissions for your YAPC::NA::2015 talks are due before midnight (23:59 EST) on March 1st 2015. Please submit your proposal by visiting yapcna.org/yn2015/newtalk.

Tony Cook writes:

Approximately 38 tickets were reviewed, and 10 patches were applied.

[perl #121337] is interesting in the number of things that were wrong with the first test in t/op/utf8cache.t.

This was reported by Daniel Dragan where op/utfcache.t was producing a an error message, but was still passing:

  '-' is not recognized as an internal or external command, operable program or batch file.
  ok 1
  ok 2 - quadratic pos

This turned out to be a problem from when the test was originally written in 2009 - it uses C< open CHILD, '-|' > which doesn't work on Win32.

It was further muddled when the code was converted to use test.pl instead of manual TAP output in 2011. Previously the code would attempt to load Devel::Peek, but the modified code only checked $Config{extensions}, so the module wasn't available to produce the test output.

Finally, the test included no description, and the test performed was obscure enough that it was difficult to tell what it was testing for. The original commit message is fairly obscure.

(and post-finally, I missed committing a change to use and allow a skip count for skip_without_dynamic_extension(), covered later by Jarkko.)

I spent a lot of time on [perl #108276] this month, which was originally reported by Danial Dragan in 2012 as a deep recursion bug in Perl_scalarvoid().

Others followed up with attempted reproducers which revealed different deep recursion bugs, including a suggested fix, with the last activity in July 2014.

I spent some time cleaning up the suggsted fix and extending it to two of the other reported recursion issues.

In June this year, Dave Mitchell added -DPERL_OP_PARENT as a build option for perl, adding a mechanism for finding the parent of a given op. Dave suggested after I posted my patches that once that's the default, most of our recursive tree-walking would become trivially fixable.

I made a first attempt to fix this, but unfortunately found some more recent changes had broken -DPERL_OP_PARENT builds, which I tracked down and fixed.

I then produced a patch to use the new PERL_OP_PARENT links for the simplest of the recursion cases, finalize_op().

I also spent some time trying to apply this to op_free(), but haven't been able to produce a working build yet.

Dave Mitchell writes:

I spent most of my time last month making the stderr of the perl build and test process less noisy, and for blead to build, test, and be stderr-clean under ASan -fsanitize=undefined.

Quite a few of the fixes are on cpan/ code, so I haven't pushed those to blead, but rather to the branches davem/cpan-warn and davem/cpan-undef. and I've opened tickets / sent notifications to the relevant CPAN authors (although the ticketing actually took place in Jan).

Prior to this work,

(Configure && make) 2>/tmp/errs

gave 700+ lines of output. With the stuff I've applied to blead, plus the extra commits in the davem/cpan-warn branch, this reduces to 29 lines, which are all generated by CPAN modules and are for which I don't have the domain expertise to fix (I've raised tickets for those too).

With a further bunch of commits to blead, plus the commits in davem/cpan-undef,

clang -fsanitize=undefined

produces no extra test failures or output stderr on my system with clang 3.4. (I tried it with 3.6, and there is new noise which I haven't addressed yet).

All of the above just applies to Linux with gcc or clang with default-ish build options; I'm sure other platforms and compilers still give plenty of noise.


2:04 Forking with large data structures heisenbug
0:45 [perl #123390] Bleadperl v5.21.6-336-gfedf30e breaks TOKUHIROM/B-Tap-0.14.tar.gz
0:38 [perl #123399] Segmentation failed on calling method of undef with use warnings FATAL => 'all'
0:15 create Porting/bench.pl
1:16 diagnose newly-failing locale tests
25:09 fix clang -fsanitize=undefined failures
2:50 miscellaneous stuff
15:53 process p5p mailbox
28:49 reduce amount of stderr stuff in build/test
1:50 stop test suite leaving droppings in /tmp

79:29 Total (HH::MM)

As of 2014/12/31: since the beginning of the grant:

63.4 weeks
883.3 total hours
13.9 average hours per week

There are 317 hours left on the grant

Yes, it's January. But we found that Toby did provide a blog post on 2014-12-31 detailing some work on his book, with some new committed material.

Looking forward to continued progress in 2015. MAJ

The Grants Committee has received one grant proposal for the January round. Before the Committee members vote, we would like to solicit feedback from the Perl community on the proposal.

Review the proposal below and please comment here by January 25th, 2015. The Committee members will start the voting process following that and the conclusion will be announced by January 31st.

Ado - a rapid active commotion (framework for web-projects on Mojolicious)

  • Name:

    Krasimir Berov

  • Amount Requested:

    USD 4500


Ado is a light on dependencies application and framework for web projects based on Mojolicious. With this project Ado will provide an easy to start with Content Management System that can scale from a personal blog to an ERP, CRM or any custom application for managing the enterprise, by just adding plugins (modules).

PHP has plenty of CMSs which are easy to install and run on cheap shared hosts. This is an almost empty niche in the Perl world. We do not have popular, easy to install by beginners, CMS. Ado aims to fill this gap.

Benefits to the Perl Community

Ado is already on CPAN. It consists of an application class (the core), several modules (controllers, model classes, plugins) and templates. Ado::Plugin::Vest is also on CPAN. For a Perl developer CPAN-like systems are the preferred way of managing dependencies and reusing code. Ado is Stratopan, CPAN::Site, etc. ready. But PHP developers and/or beginners expect to download a package, unpack it and have a running themeable site (e.g. Drupal, Joomla, WordPress ...).

  • In my private projects I almost always stumble upon clients which want (or they think they want) Just a Site With Several Pages ASAP. Then it turns out they want to be able to edit the pages, post some news, make a catalog of the products/services they offer. We end up with installing some of the popular CMSs on a cheap shared hosting provider. Then the customer decides she needs some custom functionality. I end up writing custom modules or modifying existing ones for the respective CMS in PHP.

    This project will allow many Perl developers to do the same in Perl. Much more pleasure and fun! Let us enter the Cheap Sites For The Small Business niche. Start small, quickly and easily and grow with your customer (staying with Perl)!

  • Several modules which will be put together with the core application in a package for easy installation of a CMS which will just work (Getting started in 5 minutes). The modules (plugins) will be available on CPAN too so an advanced developer/site-owner can install just the core and add whatever he/she needs later. Ado follows the Mojo principle of loosely coupled components, still it will provide a ready-to-use beginner's' package.

  • Make it easier for beginners to start digging and adding their own custom modules or just modifying the installed system. They will immediately see the results of their changes in an otherwise complex and enterprise-ready system.
  • A wider audience will be given easier access to the world of (modern but simple (no magic)) Perl 5. Later when they feel more familiar with how the things work together, they will start using CPAN to distribute their Ado plugins and find more modules on CPAN.
  • Users (and developers) of Ado will get more familiar with Mojolicious which in turn will make Mojolicious more popular, which in turn will make Perl 5 more popular.
  • The project is valuable also for more advanced audience as it provides a framework for rapid application development on top of Mojolicious for full featured and complex MVC applications.
  • One of the purposes of the Mojo project was to enable Perl developers to build their own frameworks. Ado is such a framework. It can be a good example, a trigger for other such frameworks to appear. It will ease starting of new custom projects based on and around it (and Mojolicious).
  • Ado already serves as a more complex example application built on top of Mojolicious. People report they use it by copying and pasting snippets of code in their own Mojo apps :). But Ado can be used the proper way - by extending it and by using Mojolicious and Ado plugins.
  • Ado::Build extends Module::Build. It is a more advanced example on how Module::Build can be used to implement flexible installations of Perl applications and complex build and deployment scenarios.
  • Ado uses Test::Perl::Critic to restrict the TIMTOWTDI symptom and impose a unified coding style. When a complex system is implemented, there should be an agreement on ways to do things. We use a slightly relaxed mode of the "harsh" severity. With the usage of new actions like ./Build perltidy in Module::Build and restricting the ways the code is written (Test::Perl::Critic), we show a good example of how big, enterprise-ready applications can be build using Perl by many developers around the world, working together.
  • In the documentation and on the demo site it will be clearly stated that the project is sponsored by the Perl Foundation. Users and developers will be encouraged to express their gratitude by donating back to the Perl Foundation if they want to support this and other future projects.


Installation package (tarball/zip).

The package will consist of preinstalled Ado with several plugins and prerequisites (Pure Perl only) which can be just unpacked in a DocumentRoot folder of an Apache 2 with mod_fcgid/mod_cgi shared host or run using hypnotoad.

Task::Ado::Site - All modules required to run a site based on Ado.

This module will be available on CPAN. It will only depend on modules needed to run a minimal Ado site. It will be used to prepare the "preinstalled" package (see above). It will also serve as an example of making other Task::Ado::Xyz bundles. This will be the preferred method to start a site directly from CPAN.

Ado::Plugin::Admin - system (site) administration user interface.

This plugin will provide user interface and API that will be used by Ado plugins. It will consist of a left(top) panel in which the plugins will add links (menu items) to their routes and a main area. The default content for the main area will be a dashboard with short description of every installed plugin (provided by the plugin). This plugin will also provide REST API so the user interface can be completely separated from the implementation. Route: {route => '/ado', to=> 'ado-default#index'}.

The plugin will be uploaded to CPAN. Task::Ado::Site will depend on it and it will be included in the "Installation package". Existing Ado::Control::Ado::Default will be moved to this plugin.

Ado::Control::Ado::Users - Manage users

There is already a stub implementation of this controller. It will provide CRUD implementation with REST API and templates. Ado::Model::Users is already implemented and covered with tests. This functionality will be moved to Ado::Plugin::Admin.

Ado::Plugin::Site -Render and manage pages

This plugin will consist of CRUD implementation with REST API and templates for managing pages in the admin area and corresponding implementation for rendering pages in the site area. The plugin will be uploaded to CPAN. Task::Ado::Site will depend on it and it will be included in the "Installation package".

The initial code will be generated using Ado::Command::generate::adoplugin.

Ado::Plugin::Signup - local user registration

Ado already provides Ado::Plugin::Auth. Currently we support sign-in via Google, Facebook and locally. Ado::Plugin::Signup will allow a user to register locally. The plugin will be uploaded to CPAN. Task::Ado::Site will depend on it and it will be included in the "Installation package".

The initial code will be generated using Ado::Command::generate::adoplugin.

Ado::Plugin::I18n - Internationalization and localization for Ado

This module is already implemented and part of Ado (core). Implement loading of translation entries from the database and CRUD interface (UI and REST) for managing translation entries in the admin area.

Ado::Plugin::Vest - Messaging services for an Ado system!

Ado::Plugin::Vest is already on CPAN. It implements a (not too) naive messaging service for any web-application based on Ado. It can be used as a chat between two users, as commenting widget under articles, for showing system messages etc. Currently a HTTP based chat application is being implemented as a proof of concept. Private messaging services are becoming a mandatory feature for the enterprise.

As part of this project I will add a group chat functionality (rooms).

Ado::Plugin::Blog - a blog for your site

Ado::Plugin::Blog is not yet implemented. It will consist of frontend functionality for rendering articles in the site area and an administration part (CRUD) for managing articles.

The initial code will be generated using Ado::Command::generate::adoplugin.


...and update the existing already code and documentation. This involves removing unused templates and code, reviewing and improving existing code and documentation. This task will continue throughout the project.

Project Details

Ado is a framework for web projects based on Mojolicious, written in the Perl programming language. Its development was started in November 2013 as a rewrite of a previous project (MYDLjE) based on Mojolicious 1.9x. MYDLjE was too monolithic. It was not possible to start with minimum features, disable some of them and re-enable them only if needed. Ado is much more modular and flexible than MYDLjE and its name is not an acronym :).

Ado is a typical well structured, MVC Mojolicious application. It comes with default configuration and a model layer, plugged in by Mojolicious::Plugin::DSC. An SQLite database is bundled in the distribution at etc/ado.sqlite to get started quickly.

Ado provides additional plugins and commands, which promote RAD, good practices, and team-work when starting new projects. The default Ado page uses Semantic UI CSS and JavaScript framework via Mojolicious::Plugin::SemanticUI and is a good place to get acquainted with the system.

Ado is already on CPAN, where you can find detailed description. Currently supported installation methods are also described in the documentation.

Ado plugins system is a super-set of the Mojolicious one. The most important feature of Ado plugins is that they can use their own configuration files (separation of concerns). More details can be found in the documentation.

The framework is fully functional (for sure there are bugs). It was presented at YAPC::Europe 2014. Here are the video and presentation - https://www.youtube.com/watch?v=8kBOxd6DQsM, http://www.slideshare.net/kberov/ado-yapceu2014. The code is well covered with tests. My target test coverage will be 85% in total.

This project is about making the "application" part of the framework and delivering a ready-to-use application much like popular CMSs. Everything implemented so far is done by the author (me) with the help of some friends from time to time. The development progress can be tracked on Github.


Below is once again the project divided by tasks. Each task consists of one or more inch-stones. When all listed tasks are done, the project can be considered completed. In the course of the project some tasks may require to be done simultaneously. The order of the tasks matters. All these will be tracked in Github as issues of the respective repositories. Writing tests and overall QA are not explicitly mentioned but are assumed.Targeted test coverage of the code is 85% in total. Each module will have Test::Perl::Critic tests (example). Each task is considered done when the respective module is uploaded to CPAN and there are no test failures reported from http://cpantesters.org.

Ado::Plugin::Admin - system (site) administration user interface.

This task is a prerequisite for most of the other tasks and for any future plugins that will provide any UI in the administration area.

  • Create https://github.com/kberov/Ado-Plugin-Admin repository;
  • Generate the initial code;
  • Implement the initial API that will be used by other plugins to display UI in the admin area;
  • Implement the REST API so the default UI can be totally replaced by a client side application (AngularJS, EmberJS, GTK+ etc);
  • Implement the templates and default client-side UI. The UI will be completely usable, based on Semantic UI;
  • Implement Ado::Control::Ado::Users and UI.

Ado::Plugin::Site - Render and manage pages

The completion of this task can be considered an important milestone. With this plugin one will be able to create a basic site.

  • Create https://github.com/kberov/Ado-Plugin-Site repository;
  • Generate the initial code;
  • Implement the controllers, model classes and REST API both for the admin and site areas so the default UI can be totally replaced by a client side application (AngularJS, EmberJS, GTK+ etc);
  • Implement the templates and default client-side UI for the admin area. The UI will be completely usable, based on Semantic UI;
  • Create some pages: Home, About us, Mission

Ado::Plugin::Signup - local user registration

Generally this plugin will be used less as we already provide "Sign in" via popular social platforms with Ado::Plugin::Auth which uses Mojolicious::Plugin::Oauth2.

  • Design the workflow;

    1. User enters "email", "login_name","first_name","last_name" and submits the form; 2. User receives a temporary password via email; 3. User changes his/her password. In this case HTTPS connection is mandatory...

  • Implement REST API and UI templates for the process.

  • Ado::Model::Users is already implemented but still may require some enhancements or fixes.

Ado::Plugin::I18n - Internationalization and localization for Ado

  • Implement the controllers, model classes and REST API for the admin for managing translation entries stored in the database. This way the UI for an Ado based site can be easily localized into many languages by non-programmers. The default UI can be totally replaced by a client-side application (AngularJS, EmberJS, GTK+ etc);
  • Implement the templates and default client-side UI for the admin area. The UI will be completely usable, based on Semantic UI;

Ado::Plugin::Vest - Messaging services for an Ado system!

Combined with the OAuth2 authentication support in Ado this plugin can be a good foundation for a community or intranet site. Any Google+ or Facebook user can authenticate and use it for instant messaging.

This task is to add group chat functionality.

  • Implement the actions (REST API) for creating a new group (room).
  • Implement the actions (REST API) for adding users("friends") to the group.
  • Implement the templates and default client-side UI under /vest/* route. The UI will be completely usable, based on Semantic UI;

Ado::Plugin::Blog - a blog for your site

Completion of this task will be the second important mile-stone. With it we practically can react quickly to 90% of customer requests.

  • Create https://github.com/kberov/Mojolicious-Plugin-TinyMCE repository;
  • Implement Mojolicious::Plugin::TinyMCE which will provide a helper: Rich Text Editing functionality for textareas;
  • Integrate Tiny MCE; Experiment and decide if to embed the Tiny MCE code into Mojolicious::Plugin::TinyMCE.
  • Create https://github.com/kberov/Ado-Plugin-Blog repository;
  • Generate the initial code;
  • Implement the controllers, model classes and REST API both for the admin and site areas so the default UI can be totally replaced by a client side application (AngularJS, EmberJS, GTK+ etc);
  • Implement the templates and default client-side UI for the admin area . The UI will be completely usable, based on Semantic UI;
  • Add "Comments" functionality using Ado::Plugin::Vest REST API;
  • Create an article: "How to write articles?"

Task::Ado::Site - All modules required to run a site based on Ado.

  • Create https://github.com/kberov/Task-Ado-Site repository;
  • Prepare the module, Identify and list the dependencies.
  • Experiment with it and prepare the Installation Package.
  • Research and find the best way to automate the generation of the Installation Package and uploading to Github.
  • Create Github page for Ado and add a download link to the latest package;
  • Add a "Getting Started " page (tutorial) for beginners and non Perl developers.

Cleanups, fixes and improvements to Ado...

As already mentioned this task is continuous and consists mainly of small changes in the Ado distribution it self. It will continue during the whole project.

Project Schedule

Each task should take up to one month as I work full time and I can spend up to 16 hours per week. Some tasks may go simultaneously or overlap (e.g. Admin and Site plugins). As they are divided in inch-stones they are still easily tracked. The common time of this project is estimated to up to 6-7 months. I can start immediately. In fact I will jut continue with the natural evolution of Ado.

I count on the community for feedback, proposals and why not code if they feel they have something better in mind during implementation. See Ado::Manual::Contributing

Completeness Criteria

As mentioned already in the Inch-stones section, all modules will be released to CPAN. The code should be covered with tests 85% or more. The Installation package, produced by Task::Ado::Site, will be available for download from the Github page of the project. A demo site will be available for manual verification of the promised features.


I am self-taught, pro-Perl-y thinking software developer, engineer and author with over 13 years of experience in creating applications for the web with database back-end. Learning from the real life and always with an eye in the tech-books. Well aware and picky about everyday emerging buzzwords. Able to recognize new technologies which come to stay.

My specialties are : Perl, Web, SQL, JavaScript, Linux, web-applications, Web-Crawlers/Spiders, I18N/L10N, CMS, on-line payments... I contributed to some CPAN modules (https://metacpan.org/search?q=BEROV) and in different ways to several bigger open source projects like TWiki, Contao and most recently Atom.

I am Bulgrarian currently living and working in Prague, the Czech Republic.

Here are updates of the running grants.

We thank the sponsors for making the grant program possible.

Interested in doing some Perl work under the grant program? CFP for the January round is currently open.

EDIT: Modern OO Programming in Perl (Book) was added on Jan 18, 2015.

Act Voyager ---- long story

No Comments

Happy New Year from outer space...

since the last report a lot has happened on our journey with Act-Voyager... So, let me try to write down the episode of this saga...

In the months leading to the Act-hackathon there where two things being worked on...

Firstly, there is now a 'Act-out-of-the-Box' that makes it super easy to start hacking on Act (current version). With three simple commands, any developer can be up and running and start writing their own bits.

    curl -Os https://raw.githubusercontent.com/Act-Voyager/Act-out-of-the-box/master/Vagrantfile
    vagrant up
    vagrant ssh

And then, point your favourite browser to: http://localhost:8080/voyager to see a very bare Act-instance.

What it will need to work, is of course VirtualBox and Vagrant. It will download a Vagrant base image from my company server, which is preconfigured with Apache, mod_perl, PostgreSQL and the dependencies of Act. Thanks to many contributions of others it is workable and is something that needs updates as the Act-Voyager moves on... one of them, is including DBIx::Class as a core dependency in the Act-out-of-the-Box base image.

And secondly, I started working (and finished) the DBIx::Class Schema for Act. During the London Perl Workshop, I spend quite some time with 'SysPete' who gave a lot of advice on what to do with the DBIx::Class Schema for Act. There is soo much possible and nice to do with DBIx::Class, but for Act-Voyager it was advised to just stick to what was needed... a nice sugar-coated schema (using DBIx::Class::Candy) and documented attributes to explain what the purpose of each is. DBIx::Class::Schema::Loader does do POD in a excessive technical manner. Ribasushi had to convince me that it was better to remove verbose defaults, which enhance readability for experienced users.

The schema has already been proven to be usable in some branches of the Act Voyager project...

Which brings me to the star-map of the Act-Voyager project... "a Journey through the Universe" where we explore new galaxies and make small adjustments to the plans as we go... with one goal, a Next Generation Act, extensible and fun to hack on.

The original plan needed some adjustments... and it will need more whilst traveling along the stars. I am very fortunate to have a Grant-Manager that understands that development of the Next Generation Act is a project that needs flexibility. She does agree on the new plan below, which already had some adjustments since the Hackathon in Lyon.

  1. Orientation and fundamentals ( 1.000 USD ) FINISHED, needs continuos updates
    • Make Act 'hackable; with "Act-out-of-the-Box"
    • DBIx::Class schema
  2. Port Core Act to DBIx::Class schema ( 1.000 USD )
    • Make Act::Object sub-classes into proxies for DBIx::Class::Result classes
    • They have the same attributes and methods as the original ones
    • Retaining the tests that currently exists
  3. Dancer2 implementation ( 1.500 USD )
    • move mod_perl handlers to Dancer2 routes
    • have Dancer2 routes fill in the original template
  4. RESTapi ( 1.000 USD )
    • define all useful resources
    • write the POST, GET, PUT and DELETE methods (and more)
    • test, test and test
    • write documentation
  5. Theme Based Templates ( 1.500 USD )
    • Find a proper frontend framework (Foundation)
    • Define Layouts
    • Define Pages
    • Redo the entire ACT with new templates and themes
    • Decide which SASS variable will be editable
    • Run several default Themes and Colorschemes
    • Write a admin/theme-selector

The next two milestones, porting Core Act and building a Dancer2 implementation, are the steps that will ensure that all the old conferences (and the current) can be viewed and visited by bots once the Jurassic Apache and mod_perl implementation are shut down. For these legacy instances it will be sufficient that the pages can be rendered and no changes in the schedule or attendees have to be made. Therefore not all the handlers need to be moved to Dancer2. These routes gather information from the database and are used to fill the variables for TemplateToolkit. Those templates do not need to be changed and thus we can keep the websites backward compatible. Using Act::Legacy::Objects as proxies to the DBIx::Class::Schema for Act gives the flexibility to change the underlying database structure, without breaking the code that handles the original Act::Objects.

And somewhere along the line, there should come a tool that can read the 175 .INI files, the httpd.conf and possibly write them back as well. Those files contain valuable information not stored in the database, but are actually the 'root' objects for DBIx::Class::Schema. Most objects are related to an instance of a conference, but since there are no Conference tables yet, there can not be any relationships to select talks given during a specific conference, or list all attendees.

And then, of course we had a wonderful hackathon, full of action, fun and drama and produced some really cool prototypes that actually might work "in production". Unfortunately BooK and I had not fully prepared the hackathon, and there was no real clear path of direction. For a moment I even was worried about the crew members of the Act-Voyager. But you can't expect things to go very smooth when there are such great minds together that have their own backgrounds, their own experiences ... and yet have to get to the point that they were honourable people that were willing to work on Act, despite the differences.

There were made several patches to Act, Act-out-of-the-Box, done some design at the RESTapi side and some great ideas about how to move forward. Enough 'materials' to work with for the next couple of weeks and get to the next galaxy-stop, the Port of Act Core to DBIx::Schema.

Many thanks for all that support for this project, those who support this financially, but also those crew-members I consider my friends. People that encourage me to continue this exploration and voyage, that will lead us to a Next Generation Act! Thanks for all that came to Lyon (where my MacBook was stolen from the hotel room - and thanks for the generous help to buy a new one while waiting for the insurance). Special thanks for BooK who helped clearing the mess after the mutiny on the command-deck - and Liz who made sure I kept my head focused on this community project.

it's going to be a very exciting Act 2015!

Theo van Hoesel

Happy New Year!

The Grants Committee is accepting grant proposals all the time. We evaluate them every two months and another evaluation period has come.

If you have an idea for doing some Perl work that will benefit the Perl community, consider sending a grant application. The application deadline for this round is 23:59 January 14th UTC. We will publish the received applications, get community feedback and conclude the acceptance by January 30th.

The format will be the same as the previous rounds in 2014.

To apply, please read How to Write a Proposal. Rules of Operation will also help you understand how the grant process works.

We will confirm the receipt of application within 24 hours.

If you have further questions, please comment here. If your comment does not show up here within 24 hours, the chances are that the spam filter did something bad. Get in touch with me at tpf-grants-secretary at perl-foundation.org.

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

About this Archive

This page is an archive of entries from January 2015 listed from newest to oldest.

December 2014 is the previous archive.

February 2015 is the next archive.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2