I endorse this grant. The Module::Compiler framework looks good to investigate. Inline:CPP is too hairy and fragile.
While I applaud the goals of rperl, I think the benefits described are aspirational and do not relate to the specific deliverables. Some .t files and Module::Compile integration will not change perceptions of Perl 5 or significant improve performance for the vast majority of Perl 5 users.
Given rperl's existing demonstrated ability to raise community funds and the enthusiasm of its participants, I suspect that the deliverables will happen whether or not the grant is awarded and thus I don't think it's the best use of TPF's scarce resources.
tl;dr - I believe that this grant should be postponed, given the current state of RPerl. No releases have been cut, and the code in the repository does not compile. Even when the build problems are fixed, it does not pass its own tests. Finally the promised RPerl code examples do not exist yet, so it's not possible to form a judgement of how much of speedup RPerl will give, versus how restrictive a language dialect it will be.
The RPerl project promises a lot, but lacks detail on how, meaning that it's really hard to make a judgement on whether it can deliver. The grant states that it's for "the next step of my involvement in RPerl development", which means that it should be assessed as part of a larger roadmap. However, there is no roadmap published anywhere - not in the github repository, not as part of the Kickstarter, and not in the Trello page referenced. So the proposal is not doing itself any favours by making it so hard to get the big picture.
Failing any official roadmap, I'm forced to make the following assessment how what the project is likely to deliver:
From the README
The input to the RPerl compiler is low-magic Perl 5 source code.
You can substitute your favorite framework or library, if you like...the bottom line is that an awesome Ruby implementation that doesn't run any Ruby applications is basically useless. Beware of crowing about your victory over Ruby performance before you can run code people actually care about.
http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby.html
I estimate the project will take between 1 to 2 months. RPerl development is on-going, I am available to start immediately.
There was a Kickstarter for RPerl:
https://www.kickstarter.com/projects/wbraswell/perl-5-optimizing-compiler-rperl-v10/
It successfully raised about $1,000. It has a number of deliverables outstanding and not yet delivered. I feel uneasy at the prospect of backing something that has already received funding but not delivered. Hopefully the Kickstarter deliverables will be delivered soon, and then this could be resubmitted on firmer footing.
I can only echo Nicholas' sentiment. I'm not convinced this is useful, if I want "low magic" for performance reasons C offers me a deal I have more faith in. On top of that, this project hasn't shown to deliver. I have a bad feeling about this project.
Reini, thank you for your well-informed vote of confidence!
Mr. Golden's sentiments are directly contradicted by past TPF grant chairman Dan Wright's comments:
"You should consider submitting a grant request to The Perl Foundation, either under the Perl 5 core grants or the traditional grant program. TPF is always looking for good grant proposals, and if people donate through TPF, it's tax-deductible."
Dan Wright Discussion Thread
I will do my best to reply to each point Mr. Clark has raised.
"tl; dr"
Why is it okay to not read my proposal, but still give a (relatively) scathing review? This seems totally illogical and unacceptable. Furthermore, Mr. Clark's rebuttal is nearly as long as my proposal, which seems to further invalidate the proposal-length-as-prohibitive-factor argument.
"the code in the repository does not compile"
Oh, it definitely compiles, but you're right, we have a serious build issue related to the weird way that Inline, Inline::CPP, and Inline::Filters handle their spaghetti of interdependency checking. I don't fully understand the problem, but I can tell you that bulk88, mst, Reini Urban, Shlomi Fish, and myself are all giving it significant thought. This is in fact the only officially filed bug for RPerl so far:
Github Issue
So far I have had success walking people through the RPerl installation and passing all tests, with a key critical step to overcome this issue being the need to use CPAN to force an install of Inline::Filters, but NOT delete the copy of Filters.pm that ships with RPerl. It is a hack, but until CPAN can be properly updated and Inline::* fixed this is the best we can do.
"there is no roadmap published anywhere"
Well it may not be in the exact format that you like, but we do have a list of all tasks that must be completed for RPerl v1.0 to be released:
Trello Card For RPerl v1.0 Development
I realize this only takes us through RPerl v1.0 and you want more details about future versions of RPerl, all I can say is that we can cross that bridge when we come to it. I've already got a group of several probable next steps in the "To Do" list:
Trello Board For RPerl Development
"This defines a subset of the language that removes most of the features that make Perl useful in the first place. It's effectively turning a dynamic language back into a static language."
Correct. Obviously, in order to gain compile-time optimizations we must utilize compile-time behaviors, which are by definition static rather than dynamic. Initially, RPerl is meant to enable compile-time optimization of static Perl code, and after compilation the optimized static Perl code can be linked back to plain old dynamic Perl code, so you get the best of both worlds and maintain full backward compatibility. This particular point of "you're taking away all the parts of Perl I love!" is hashed and re-hashed ad nauseam by RPerl numerous detractors. The bottom line is this: are you somehow better off WITHOUT the option of optimizing your static Perl code? Why would you NOT want to optimize your static Perl code, especially if it doesn't hurt your dynamic Perl code in any way??? The only answer to these questions is fear, uncertainty and doubt. We all know where FUD leads, and it is not to a place where people can make valid progress without facing undue roadblocks.
"For this, the Alioth benchmarks which were promised by the Kickstarter for 1st February would have been perfect. But they aren't published, nor is any news on progress. How close are these to being ready?"
TPF denied my last grant request. I'm not aware that it was ever even published for comments, certainly not that I was ever informed about. Living off of the $1700 raised on Kickstarter I was able to survive long enough to finish RPerl v1.0 Beta. After the Kickstarter money ran out I was forced to pursue non-RPerl programming work to make ends meet, which has made it prohibitively difficult for me to focus on RPerl as much as is needed for steady progress. Any amount of income from TPF will allow me to focus on RPerl when I otherwise would be unable to do so.
Implementation of the Alioth Shootout Benchmark n-body algorithm as an RPerl application will be relatively straightforward once we have RPerl v1.0 completed. I've faithfully kept my RPerl backers informed about the progress and situation:
RPerl Kickstarter Updates
"It will be possible to choose a different trade-off between flexibility vs speed than Perl 5 makes, but it's not going to be possible to have all of Perl 5 and be substantially faster than it."
Correct. Moving forward with the implementation of RPerl is the only way to flesh out this speed-vs-flexibility issue. We will naturally discover which parts of Perl are too dynamic to achieve any optimization using RPerl, and which parts are good to be compiled.
"For a grant proposal specifically about tests, the existing tests should pass. "
Again, the tests DO pass, if you know what you're doing. Below is a chat log between myself and one of the programmers (A. Canfora) who has been successful in running the RPerl Tests (minus some weird compiler big-integer issues):
Building and testing Inline-Filters-0.12
cp Filters.pod blib/lib/Inline/Filters.pod
cp Filters.pm blib/lib/Inline/Filters.pm
Manifying blib/man3/Inline::Filters.3pm
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
Can't use string ("-I"/home/acanfora/.cpanm/work/13"...) as an ARRAY ref while "strict refs" in use at /home/acanfora/.cpanm/work/1394216528.16942/Inline-Filters-0.12/blib/lib/Inline/Filters.pm line 103.
BEGIN failed--compilation aborted at t/Preprocess.t line 16.
t/Preprocess.t ......
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/1 subtests
I forced the installation of Inline:Filters anyway and went ahead. Then I got following errors from tests:
t/01_depend.t ............ ok
t/02_inline_c.t .......... ok
t/03_inline_cpp.t ........ ok
t/04_type_scalar.t ....... 8/? not ok 23 - TIV09 integer__stringify(-1_234_567_890_000) throws correct exceptionnot ok 34 - TIV29 integer__typetest1(-1_234_567_890_000) throws correct exceptiont/04_type_scalar.t ....... 103/? not ok 116 - TIV09 integer__stringify(-1_234_567_890_000) throws correct exceptionnot ok 127 - TIV29 integer__typetest1(-1_234_567_890_000) throws correct exceptiont/04_type_scalar.t ....... 193/? not ok 206 - TIV09 integer__stringify(-1_234_567_890_000) throws correct exceptionnot ok 217 - TIV29 integer__typetest1(-1_234_567_890_000) throws correct exceptiont/04_type_scalar.t ....... Dubious, test returned 6 (wstat 1536, 0x600)
Failed 6/273 subtests
t/05_type_array.t ........ ok
t/06_type_hash.t ......... ok
t/07_oo_inherit.t ........ skipped: [[[ OBJECT-ORIENTED TESTS DISABLED UNTIL C++ -> PERL NAMESPACE ISSUES ARE FIXED IN INLINE::CPP ]]]
t/08_precompiled_sort.t .. ok
"Right now the code is in no fit state to be evaluated, and it would be insane to approve a grant for such code prior to this being rectified."
I just showed you now to evaluate the code. If you're unable to get it to compile on your own machine, I'm happy to help. If you refuse my assistance, and are unable to get the tests to compile by yourself, then the problem is not with RPerl. What is "insane" is pre-judging such a potentially important project as RPerl without even getting it to run for yourself first.
Mr. Signes,
The outstanding deliverables are RPerl v1.0 and the Alioth n-body algorithm. As stated in my reply to Mr. Clark above, I got as far as I could on the $1700 from Kickstarter, which resulted in the release of RPerl v1.0 Beta.
How, exactly, does it make sense to deny funding to a project that you want to see produce more code? You say you want to see deliverables, but you don't want to see any funding provided to help achieve this goal?
Mr. Timmermans,
RPerl v1.0 Beta has been released, it is a significant step forward in the development of a low-magic Perl compiler, this directly contradicts your claim that RPerl "hasn't shown to deliver".
If you want to write C or XS code, that's fine, good for you. RPerl itself outputs C and XS code, which is specially designed to be linked back into high-magic Perl code. You're simply not going to achieve this in any straightforward or user-friendly way using manual C or XS coding techniques. Show me 1,000 lines of manual C & XS and I'll show you 1 line of RPerl which can be automatically compiled.
What I said was that if the Kickstarter goals were still not delivered, we should wait for them. That's based on the notion that they were still underway, since I didn't see any evidence that they weren't. The undelivered Kickstarter goals are not listed as deliverables on this grant, so it's not the case that we get *those* deliverables by funding *this* grant. The relationship between the two is unclear.
Mr. Signes,
You are correct, the relationship is unclear, thank you for pointing that out.
As with many software development projects, RPerl has encountered unforeseen complexities along the way. The deliverables on this grant proposal are additional RPerl components not conceived of during the time when the Kickstarter project was announced.
Specifically, the grant deliverables are important supporting components which will significantly aid in the progress toward a functional and polished RPerl v1.0 release. Thus, the grant deliverables can bee seen as separate from the Kickstarter goals, yet related to the Kickstarter goals, which is no surprise since it is all related to RPerl one way or another.
I humbly continue to assert the appropriate and positive nature of this RPerl grant proposal, and I hope TPF grant committee will see fit to award the grant for the good of the future of the Perl community.
Perling,
~ Will
I worked with Will to get RPerl running on Win32 so I could evaluate it myself, on what it *currently* does. But his use of many C++11 features, and deep dependence on the latest C++11 additions to libstdc, caused all of my compilers (a number of Visual Cs and GCCs, including Cygwin GCC) to fail. The code formatting style of RPerl in some files in its source code is "unique". While I conceptually agree with the high level design theory of RPerl and the principal of allowing static code without manually writing C. I can't make an opinion on something I can't personally run or effectively criticize. Therefore I don't have an opinion on this grant proposal.
Since I have no technical comments on RPerl, some social steps I suggest would make this look like a better project is if it was released on CPAN, and a number of cpantesters.org machines passed, and there were 2-3 regular committers instead of 1 that could take over if someone gets bused.
<sarcasm>If I get RPerl to compile on my machine, a make test could just print "Just another Perl hacker, its April 1" and RPerl goes down in the records book as the largest JAPH ever written</sarcasm>
Unfortunately, Mr. Dragan (bulk88) is afflicted with a compiler and OS toolchain that is not C++11 ISO standards compliant.
This is definitely not an error or flaw in RPerl.
RPerl works just fine with an ISO-compliant compiler.
> Unfortunately, Mr. Dragan (bulk88) is afflicted with a compiler and OS toolchain that is not C++11 ISO standards compliant.
> This is definitely not an error or flaw in RPerl.
Compilers are only beginning to implement C++11; and I say that as someone who was writing C++11 before it officially came out (May 2010). GCC 4.8 (the latest released version) is the first in years that I haven't accidentally crashed (yet) while using various new features. This is similar to the process C++ went through when C++98 came out AFAIK. Expecting useful implementations of it to be widespread is silly.
> RPerl works just fine with an ISO-compliant compiler.
His environments come with a ISO-compliant enough compilers, just not ISO C++11 ;-)
"Mr. Golden's sentiments are directly contradicted by past TPF grant chairman Dan Wright's comments:"
First, I am not the TPF grants chairman.
Second, I do not agree that Mr. Golden's statement is in contradiction with mine.
Using TPF over a kickstarter-style funding mechanism has three advantages: First, donors can take advantage of tax-deductibility of their contributions. Second, the community as a whole can weigh in on where to put their valuable resources. Third, TPF serves as an oversight organization to verify objectives are met before payment is received.
Therefore, I encouraged Mr. Braswell to take advantage of the existing mechanisms for funding rather than solicit individual donations. He did not heed my advice.
Since the project has already received funding elsewhere, and the opinion of the community appears to be that he has not met the objectives for that funding, I agree with RJBS and Mr. Golden. It would be folly to throw good money after bad. We should wait until all of the kickstarter objectives are accomplished before contemplation further funding.
Mr. Timmermans,
RPerl works fine on my free & open source operating system (Ubuntu) with the pre-installed free & open source compiler (GCC).
Mr. Dragan is experiencing compiler issues because he is choosing to use either outdated and/or proprietary compiler software.
I maintain that this is not in any way a flaw in RPerl. If anything, it simply means that Mr. Dragan needs to upgrade his software.
Thanks,
~ Will
Mr. Wright,
I thought you were the past TPF grants chairman, if I was mistaken then I sincerely apologize.
It is false to say that I did not heed your advice, on Nov 27th I submitted a grant proposal to both yourself and the TPF grants committee. I never heard back from anyone, and assumed I was being snubbed or somehow disrespectfully dismissed. Again, if I was mistaken, my apologies.
If you think that spending money on RPerl is tantamount to "throwing good money after bad" then I respectfully submit that attitude will only serve to hinder progress rather than promote progress.
Also, the rules at the top of this page clearly state "Please leave feedback in the comments field by March 22nd, 2014" - yet here I am several days later still defending RPerl against attacks from people who could not see fit to follow the most basic rules.
Tsk, tsk, TPF. Let's try to follow our own rules, shall we?
Perling,
~ Will the Chill
Mr. Braswell,
Your statements are blatantly false.
On November 27th you and I did have a private conversation via Facebook. At that time I did make it clear to you that I was the Treasurer for TPF and NOT the Grants Chairman. I informed you who the Grants Chairman was and suggested you contacted him.
I also gave you the URLs to the pages on the TPF web site that described the various grants and suggested you look them over.
You informed me that you did not feel qualified to apply for a Perl 5 Core grant because you had never contributed code to the Perl 5 Core. And, you informed me that you did not want to apply for a traditional grant because you had an immediate need for money and did not want to wait for the next round of grant applications.
At no point did you ever submit anything resembling a grant application to me. And, if you had, I would have (again) referred you to the Grants Chairman.
You are correct that it is now past March 22nd. But since you have seen fit to drag my name into this, I felt it was necessary to set the record straight. My original suggestion that you apply for a grant was in no way an endorsement for your grant application. It was an endorsement for the grants program.
Mr. Wright,
Again I apologize for confusing your office, obviously I was mistaken in thinking you were the Grants Chairman when you were in fact the Treasurer. My bad!
I'm surprised that you never received my grant application, I sent it on November 27th as stated, I'll paste the e-mail headers and part of the body below as proof.
Thanks,
~ Will
MIME-Version: 1.0
Date: Wed, 27 Nov 2013 18:59:12 -0600
To: tpf-proposals@ *EDITED*
Cc: "Daniel Wright" dan@ * EDITED *
Subject: Perl 5 Optimizing Compiler, RPerl Grant Request
From: "Will Braswell" wbraswell@ *EDITED*
In-Reply-To: CAHMRfDwA8if8zgES4L8_VuM+P_TbZ8UsX4iW7F4_JjeXdKNKPg@mail.gmail.com
References: 20131127071557.5A07520111@smtp.hushmail.com CABe4FJAODqgLEeOX22eBTJmgeBGgOXXFst+jpy8117AqbZ-TuA@mail.gmail.com 20131127082814.D0AE320111@smtp.hushmail.com CABe4FJCSUDORkznKQS0T20mY9ZPeAW2TY+wDJKM7FLAFj47TeQ@mail.gmail.com 20131127124142.B47B620112@smtp.hushmail.com CAHMRfDwA8if8zgES4L8_VuM+P_TbZ8UsX4iW7F4_JjeXdKNKPg@mail.gmail.com
X-hush-end-of-body-position: 229
Content-Type: multipart/alternative
=head1 Project Title
RPerl
=item Name:
Name of proposer.
Will Braswell
=item Email:
Where we can contact you!
wbraswell@ *EDITED*
=item Amount Requested:
How much is your project worth?
$3,000 (or whatever is the maximum amount allowable)
=back
=head2 Synopsis
A short description.
Whether we want to admit it to ourselves or not, Perl is quite slow at
many kinds of tasks, as shown by the popular Alioth Shootout
Benchmarks:http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody
RPerl is a compiler which converts low-magic Perl 5 source code into
the equivalent Inline::C and Inline::CPP code, which is then compiled
and can be linked back into high-magic Perl 5 code in place of the
original slow pre-compiled pure-Perl. In other words, RPerl can help
the low-magic parts of your program run up to 200x faster, WITHOUT
breaking backward compatibility with existing high-magic Perl 5 and
XS.
...
[[[ THE FULL GRANT APPLICATION GOES ON FROM HERE ]]]
Will,
Grants Committee representative will get in touch with you offline and investigate what happened to your communication with the Grants Committee in November.
Will,
As you may know, the Grants Committee was unable to have CFP in 2013Q4. The most recent rounds were opened on Jan 4th 2013, March 31st 2013, July 1st 2013 and March 1st 2014. The Grants Committee does not accept grant proposals outside the defined window and your request in November was not considered.
In fact, this email address you sent the grant proposal was redirected to a ticketing system which was not monitored outside of the CFP period. So we were unable to respond to you to let you know your request was not considered.
Going forward, to prevent such miscommunication from happening, we will accept proposals on the web form which will be available only during the CFP period. If you have any questions or suggestions, feel free to get in touch with me.