2010 Grant Proposal: Perl Compiler

Category: Grants

Comments (9)

Seriously WANT!

Pay the man...

If PHP can do it, so should Perl.

I'm all for improving the Perl compiler, but this grant request is kind of confusing. Are the deliverables really stretched out over the next two years? Why?

Given the small amount being requested, I'd prefer too see this narrowed down to a smaller set of inchstones that can be achieved in the near future.

PHP without string eval() (and other restrictions) can "do it"...

I'm guessing they're stretched out over two years only because the requester can envision his work that far ahead (and this labor of love is only a moonlighting endeavor, not fulltime $dayjob). It seems the requester wants the compensation as a psychological motivation from TPF's public backing/approval of his work, and not necessarily as something to offset/recover the actual opportunity cost of choosing to work on B::.

I should clarify that I am all for funding work on this project in general, I just don't think this grant is clear in what the funding is for.

Good idea. It would get Perl a formal commitment from Reini, more optimization and testing, fewer bugs, etc. Some concrete deliverables would strengthen the application. How about a goal like successfully compiling and running a good portion of a list of important Perl modules and applications?

perlcc has long been broken and it's awesome that someone's working on it. The fee Reini is asking for is obviously just a token amount. I don't think it's unreasonable that he doesn't give a detailed project schedule as long as it's understood that he simply continue doing the good work that he has been doing already.

To clarify the unusual time frame again:

I already stopped busy compiler development until next november. I rather concentrate on writing the jitter and rely on others reporting bugs.
Most of the deliverables are already in svn, e.g. but cutting down the testsuite, testing core and the top100 modules. But there are still 2-3 major bugs lurking, which need a good amount of full concentration > 2 days per bug.
And a lot of documentation is missing, so that others can understand it and help.

I wrote:
2010: Find and fix all remaining bugs. I suspect there are still 5-6 major ones.
2010: Faster testsuite. Now: 8 min user - 40min author - 2 days all perls + plats.
Until March 2011: CC type and sub optimisations

$1000 for fixing those until March 2011 seems fair to me.

Matthew Wilson: Our perl compiled eval works fine, in contrast to php. No issue for us. I fixed major eval issues after writing this proposal while visiting Frozen Perl 2010 in Minneapolis.

Martin Berends: I have now 4% failures on the top100 cpan modules on a good platform, but a lot of weird failures on the core testsuite. Unimplemented magic mostly, and failing xs stub and dl_init(). Bigger applications are expected to work end of this year. With workarounds even now.

I uploaded B-C-1.30 at March 6, 2011 with most of goals fulfilled in my little developer point of view.

See http://cpansearch.perl.org/src/RURBAN/B-C-1.31/Changes
full 5.14 support, full dynaload support, fixed half of the outstanding bugs.

But unfortunately the ability to dynaload modules caused some new code paths and bugs which I'm currently exploring.
CPAN Testers is red because I was overly optimistic.

Also darwin and MULTIPLICITY was not covered.
And the symbol walker needs to be rewritten, to improve dependency detection for the masses.

Sign in to add comment