Grant Proposal: RPerl User Documentation

15 Comments

We have received the following grant application "RPerl User Documentation". Please leave feedback in the comments field by September 27th, 2015. If your comment does not appear in 24 hours, contact me at tpf-grants-secretary at perl-foundation.org. As we have four proposals on RPerl this time, please use this entry if your comment is about RPerl in general and not specific to each RPerl proposal.


RPerl User Documentation

  • Name:

    Will Braswell

  • Amount Requested:

    USD 800

Synopsis

RPerl v1.1 has been released with a working N-body benchmark, as promised. Thanks to RPerl, we are now able to run N-body at the speed of C++, which was claimed by many in the Perl community to be impossible. This grant proposal is to create an RPerl user tutorial.

Benefits to the Perl Community

The number one request and obvious need at this time is quality RPerl user documentation, to help new RPerl users learn how to write fast software. I am bombarded with a constant, daily stream of requests for this to be done.

Deliverables

Deliverables for this grant proposal are:

  1. A description of the RPerl grammar and what constitutes valid RPerl syntax
  2. Documented RPerl solutions to problems in chapters 1 - 6 of Learning Perl
  3. Web-based presentation of deliverables 1 and 2 on the rperl.org website

Project Details

I've already written basic POD for command-line usage of RPerl: https://metacpan.org/pod/distribution/RPerl/script/rperl

I've already written some of the code for the solutions to Learning Perl: https://github.com/wbraswell/rperl/tree/master/lib/RPerl/Learning

Exercises in Learning Perl which are not supported by RPerl will be omitted.

I've already got a place-holder section of the website ready for docs: http://rperl.org/use_rperl.html

I've already got the RPerl v1.1 grammar done and working, it just needs docs: https://github.com/wbraswell/rperl/blob/master/lib/RPerl/Grammar.eyp

Inch-stones

1a. Describe Eyapp EBNF grammar format and Grammar.eyp file sections
1b. Describe lexical token types
1c. Describe operator precedence and associativity
1d. Describe all grammar rules and productions
1e. Provide examples of valid code

2a. Complete source code of solutions to chapters 1 - 6
2b. Describe how to arrive at each solution

3a. Create POD versions of deliverables 1 and 2
3b. Use POD::Tree::HTML or similar to generate HTML
3c. Integrate HTML into rperl.org web framework

Project Schedule

I will begin work immediately upon granting.

I expect work to take approximately 30 to 60 days.

Completeness Criteria

I will release a new version of RPerl to CPAN with the new documentation.

I will release a new version of the RPerl website with the new documentation.

Bio

I am the creator and lead developer of RPerl.

I've spent the last 32 months working on RPerl without the support of TPF.

I would like that to change now.

15 Comments

This grant request is a must do!

I've been reading up on RPerl for some days now, and mailing with Will Braswell, mostly about the documentation and examples. Last YAPC::NA in Salt lake City, I got a demo of what he was doing. It looks impressive, and I think it has potential for both Perl 5 and Perl 6. I think this proposal is a nice one and I hope TPF will fulfill this grant.

Will is a brilliant developer. Not only do his RPerl projects deserve support for the potential they offer those who need performance enhancement, but he is extremely knowledgeable in all things Perl and does a lot for the Perl community including me. Though I have yet to ask I hope he involves me in his documentation efforts, it may be a way for me to begin to give back, I am looking for this kind of opportunity.

vote for!

Better docs will bring more people to RPerl and potentially attract more to Perl in general. I vote for this.

RPerl is one person, just one person. Deliverables for something as complicated as RPerl are hard to define. When is RPerl done? The architect and the coder are the same person. The specification and design can be changed prematurely, just to finish a task sooner since a grant is involved. Documentation can be easily measured and debated as to its quality and completeness. However, the code behind RPerl is difficult to objectively rate for anyone but Mr Braswell. Thus I, one anonymous voice in the crowd, say that this docs grant is the best one of the three submitted by Mr Braswell.

Many thanks to everyone for showing TPF there is a Perl community mandate to fund RPerl now!

I set each of the RPerl grant proposal dollar amounts as low as possible, so TPF may feel comfortable with awarding all requested funds this quarter.

If TPF follows the community's clearly-established vote to approve multiple RPerl grants, then it is likely I will choose to work on this particular grant first in chronological order.

I have received a few questions about the relationship between these TPF grant proposals and the currently-live Kickstarter campaign. I wrote a response to Karen Etheridge here, pasted below for your convenience:

The TPF grant requests are different than the Kickstarter.

Specifically, there are 3 places that may be confusing:

1. Operators
The Kickstarter page states it will be used to implement "Different Operators Than TPF Grant Proposal If Approved". There are tons of operators in Perl 5, more than enough to fill a dozen grant requests. No double-dipping (paid twice for one job) occurs.

2. Benchmarks
The Kickstarter page states it will be used to implement a "Different Benchmark Than TPF Grant Proposal If Approved". There are about 15 benchmark algorithms listed on the Alioth website, again more than enough for a dozen grant requests. No double-dipping occurs.

3. Medium-Magic Support
If we reach $75K on Kickstarter, then I will be personally funded to work on the many different aspects of supporting medium-magic code. One sub-component of this would be the medium-magic grammar, as described in the TPF grant proposal by Paul Bennett. It is very, very unlikely we will reach $75K this round on Kickstarter, but even if we do then that money would go to me, whereas the TPF money would go to Paul Bennett, so you would have 2 guys working in cooperation to complete the software instead of just 1. No double-dipping occurs.

https://www.reddit.com/r/perl/comments/3er9u2/anyone_got_opinions_about_rperl_i_cant_tell_if/
Are these issues still outstanding? Shouldn't they be fixed first? No regex? No auto-vivification?

Anon, to answer your questions:

Are these issues still outstanding? Shouldn't they be fixed first?

That reddit thread was created not long after RPerl v1.0 was first released on CPAN, we are now currently at RPerl v1.1 which fixes a number of the installation and usage issues.

On an operating system with decent Perl support (such as Ubuntu), you can install RPerl by simply typing the command `cpan RPerl`.

You can see all the various bug fixes since v1.0 hit CPAN:
Changelog
Commits

No regex? No auto-vivification?

RPerl v1.x has always been clearly advertised as supporting a low-magic subset of Perl 5.

RPerl is similar in name and principle to RPython (Restricted Python) and NQP (Not Quite Perl 6).

RPerl must start somewhere, and that somewhere is by-necessity the low-magic restricted subset of Perl 5 which we currently support with RPerl v1.1 on CPAN.

Interested in initial support for medium-magic code? Paul Bennet and I are already in the planning stages.

Interested in initial support for regular expressions? Help us raise $30K for RPerl v2.1 to be developed.

Then isnt RPerl fast just because it can do far less things? How will it benefit Perl 5/6 users? Why don't u patch 5/6?

Anonymous, to address your questions...

Then isnt RPerl fast just because it can do far less things?

I already answered this question:

RPerl must start somewhere, and that somewhere is by-necessity the low-magic restricted subset of Perl 5 which we currently support with RPerl v1.1 on CPAN.

Interested in initial support for medium-magic code? Paul Bennet and I are already in the planning stages.

Interested in initial support for regular expressions? Help us raise $30K for RPerl v2.1 to be developed.

So again, RPerl v1.x is limited in functionality, future versions of RPerl will expand the functionality.

How will it benefit Perl 5/6 users?

If you like to write code using Perl 5, and you want that code to run fast, then RPerl will benefit you by both saving you a tremendous amount of effort, and by running super fast. Perl 6 users will benefit from future versions of RPerl.

Why don't u patch 5/6?

As stated previously:

RPerl is similar in name and principle to RPython (Restricted Python) and NQP (Not Quite Perl 6).

Both RPython and NQP were built to facilitate the (re)writing of their parent language for speed and maintainability. RPerl will be used for this purpose in relation to it's first parent language, Perl 5. After all of Perl 5 has been upgraded ("patched") to work with RPerl, then we can move on to address Perl 6.

...

Does that satisfactorily answer your questions?

I know it's after the comment period, but I just realized this: A very useful document would be an RPerlification case study. Start with Some::Beloved::Module, factor out Some::Beloved::Module::LowMagic for RPerl consumption, and show your work so that other module authors can feel encouraged and learn the ropes.

Bonus publicity if the module's maintainer is willing to make your version official. "Yeah, everyone uses this, and RPerl sped it way up. Like XS, but without the eldritch horror."

Why don't u patch 5/6?
Because it will be instantly rejected by Rik and his cabal which are way too conservative to ever let in something this disruptive.

I would like to add that this opinion was raised by one of the committee members.

The author seems to think that Perl has a big problem with runtime performance, and that this is holding back adoption. I don't see it. And Perl does quite well on the Alioth benchmarks already. It beats Ruby and Python 3 at most of them and ties PHP.

There might be some use for this in number-crunching applications, although PDL is probably a more obvious choice. There are a number of projects like this for Python and they don't seem to get any use outside of scientific and big data work, but it would be nice to have one of our own if it was reliable and well-documented.

Leave a comment

About TPF

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

About this Entry

This page contains a single entry by Makoto Nozaki published on September 19, 2015 11:00 PM.

Community Heroes: Liz and Wendy was the previous entry in this blog.

Grant Proposal: RPerl Alioth Benchmarks, Part 2 is the next entry in this blog.

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

Pages

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