Recently in Grants Category

The previous round got no proposals and we seriously need one. It doesn't have to be a huge Perl project. Do you have anything in mind you want to spend a few weekends to work to help the Perl community?

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 July 17th UTC. We will publish the received applications, get community feedback and conclude acceptance by July 31st.

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

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 or contact me at tpf-grants-secretary at perl-foundation.org.

Dave Mitchell has requested an extension of $20,000 for his Maintaining the Perl 5 Core grant. This will allow him to dedicate another 400 hours to this work. During this grant he sent weekly reports to the p5p mailing list as well as providing monthly summary reports that have been published on this blog, the most recent of which are linked below:

Report for Month 19
Report for Month 17 and 18
Report for Month 16

Before we make a decision on this extension we would like to have a period of community consultation that will last for one week. Please leave feedback in the comments or if you prefer send email with your comments to karen at perlfoundation.org.

If successful this extension will be funded from the Perl 5 Core Maintenance Fund.

Tony Cook writes:

Approximately 40 tickets were reviewed or worked on, and 4 patches were applied.

This month blead allowed patches only for blockers, so there won't many patches applied to blead.

I spent much of my time working on blockers, both trying to solve them in blead, or to report issues to CPAN maintainers whose modules were broken.

Act Voyager Report

No Comments

The Act - Voyager project has not come to a halt, although it has been a bit silent. My apologies for those who had been waiting last month for the report.

Life has taken some turns, in my favour, and thanks to Rick Deller from Eligo, I got a nice job at Broadbean technologies in London - and yes, moved from my lovely little hometown to the Perl capital of the United Kingdom, and met some great people at work or during the London pm activities.

The few hours left, I kept pushing forward the project, little by little. And I am very happy with the direction it is going and below I will try to explain what has happend with the basics of the REST-api. But before that, I think I should mention that the Act-Voyager project will leave behind the legacy system. It has served the community for more than a decade and during that time changes have been made to fulfil the needs organisers had. But in that process some decisions also have led to not such nice solutions. Things will need to change and a nice REST-api should come from the drawing-board...

REST api's deal with resources, indicated by an URL... the new structure will be:

https://example.com/yapc_na/2015/...

The first level (which I called a syndicate) functions as a kind of aggregate for the events organised under that 'authority'... in this example... the 2015 edition of the YAPC-NA. In the future I would love to see it happen that we could use it also for the monthly pm-meetings, like

https://example.com/amsterdam-x/2015_12/...

So, in the future, the api will simply deliver the news about YAPC-NA at the resource:

https://example.com/yapc_na/news

and if you only want the news for the 2016 edition

https://example.com/yapc_na/2016

The design is slightly deviant from other URL patterns, normally it would be more tedious: https://example.com/syndicate/yapc_na/edition/2016/news or the other approach would be using tons of filters.

Another important thing in designing a REST-api is the decoupling between the REST resource representations and that actual data-store. In other words, the Act-Voyager REST resources are not being a 1 to 1 translation of the legacy-tables, but will be composed from different tables. At a few occasions in Cluj, Amsterdam-X, German Perlworkshop, I gave a presentation about multi-lingual REST api's and did address the decoupling and how a REST api should use a abstraction layer which does all the hard work - not your Dancer2 app.

Add on top of that the fact that Act has a 'rights' table that holds the information for a conference and a user and what rights he / she has, and it becomes obvious that it was not going to be a simple Dancer2 dispatch app. For the authentication I modified some previous work I did for a plugin: Dancer2::Plugin::HTTP::Auth::Extensible.

Bolting all things together, I came up with a REST::api::Handler... one that can do only very simple tasks... dispatch the work to the REST::api::Objects, REST::api::Collections or REST::api::DataStore. Now, instead of having all these different methods in one huge module, I put them in smaller modules, Moo::Roles to be more specific. And each of these roles will be applied to the Handler object, based on the context... a ResourceRoot and a ClientUser.

inside Dancer2, it looks just like:

post '/news' http_require_task 'insert_news' => sub { http_handler->insert_news(...) };

And the handler knows if and on what level to dispatch the request to the REST api datastore.

I personally think, Act Voyager is going to have a save journey now

NB: for the brave... check it out on Github

Theo van Hoesel

Re: Call For Grant Proposals (May 2015 Round)

We have not got grant proposals. We are extending the deadline until the end of May.

If you need ideas, rjbs's article is still relevant apart from the Gist one.

If you have any questions, let us know at tpf-grants-secretary at perl-foundation.org.

Dave Mitchell writes:

I spent the month mainly fixing issues that were 5.22 blockers.

Summary

2:18 [perl #120950] Apparent failure to localize %^H
2:13 [perl #123619] Bleadperl v5.21.6-89-gd648ffc breaks autobox
4:33 [perl #123737] S_no_op: Assertion `s >= oldbp' failed
1:25 [perl #123954] Perl_pp_substcont: Assertion failed
1:21 [perl #123976] [Win32] Unable to build 64-bit blead using gcc-4.8.2
1:21 [perl #124207] Perl_ck_stringify: Assertion `!((((kid)->op_sibling) ?
10:57 [perl #124216] Perl_sv_clear: Assertion
0:37 [perl #124368] Perl_sv_2pv_flags: Assertion ....
2:09 [perl #124385] null ptr deref -> Perl_cv_forget_slab (pad.c:500)
0:20 fix t/uni.parser.t under EBCDIC
10:02 more op_siblings stuff
7:27 process p5p mailbox
5:10 review 5.22 blocker issues
5:34 setjmp corruption with recent clang
3:36 valgrind error in re_op_compile()

59:03 Total (HH::MM)

Tony Cook writes:

Approximately 25 tickets were reviewed or worked on, and 2 patches were applied.

This was a short month since my old grant ran out, and a new grant started.

[perl #123788] was interesting to me because is illustrated how perl tracks which globs (or package) a given @ISA is present in - and how that was broken in this case.

Each @ISA has isa magic. If the @ISA is only present in a single GV, then mg_obj for the magic is a pointer to that GV, if there are multiple GVs then mg_obj is an AV (not an RV pointing to an AV) of GVs. In neither case are the references counted in the GV's reference count.

In the case of the bug, the magic wasn't being updated when the @ISA was removed from the GV, and the GV was then deleted, leaving a dangling pointer in the mg_obj of the @ISA's isa magic. Later when the SV head of the GV was re-used for a PV SV and the original @ISA was modified perl would crash attempting to use it as a GV.

About TPF

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

Recent Comments

  • Leo Lapworth: No brainer... yes please read more
  • Arthur T. Murray: Somebody could request a grant to use http://ai.neocities.org/AiSteps.html with Unicode read more
  • perlpilot: +1 Bart's got a good track record and the requisite read more
  • Tobias Leich: +1 read more
  • Coke: +1 here. Bart's previous experience with moarVM's JIT and ongoing read more
  • Jonathan Worthington: Bart did a great job last summer working on the read more
  • Anonymous: Bart seems to be exactly the person to handle this read more
  • JimmyZ: +1, JIT is also a very much key feature which read more
  • Bart Wiegmans: Nine raised a concern on the #perl6 channel whether the read more
  • moritz: +1 Bart has done great work on MoarVM in the read more

About this Archive

This page is an archive of recent entries in the Grants category.

Conferences is the previous category.

GSoC is the next category.

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 4.38