Running Grants (2008-X)

No updates.

No updates.

Vadim update: Today I've sent a patch to the parrot development list, which is the first portion of work, and I hope to do the remaining work on the grant within current week, including (and especially) within 20th and 21th december, so I am planning to finish it before December, 22.

Andrew canceled his grant for lack of Act developers support.

About this grant Vadim commented that: The entire grant will be completed within January 2009.

Ingy promised this grant completion for Christmas. We are almost there!

  • "Michael Schwern - Test::Builder 2


No updates from Grantee.

Alan reports:I was able to fix another bug and fix some mistakes in the code: #12493: Can't add new files to archives which contain files named 0,1,2,3,4,5,6,7,8,9 with no extension. Also, I was able to fix a bug: #25726: extractMembers failing across fork on Windows. I think I have been able to fix atleast 5 or 6 bugs so far and I was able to make a .zip file parser which can be used for identifying buggy areas. So, the overall progress seems good.

Daniel sent a new and complete report:
There was very little actual code work done, but there were several important conceptual issues that were addressed: 1) We realized how to implement the integration of regular C code with the SMOP runloop. We're going to use libpcl (Portable Coroutine Library) to implement the "SMOP PCL Coro Interpreter", which will yeld the coroutine at the moment the C code tries to callback to SMOP, and return to the execution when the SMOP code finishes. Basically, the "Polymorphic Eval" feature of SMOP is now showing its value. What probably is not so obvious about it, is that this is how we're going to support current XS code in the SMOPP5 integration. 2) After much debate, we finally have some specs on Iterators, this issue has been around for a long time, since much of the Perl 6 language requires runtimes, because of the amount of lazyness Perl 6 supports. The suprising news, to me, is that Larry had relaxed the policy on the synopsis editing and allowed me to start the DRAFT for "S07 - Iterators and Lazyness". With the help from Tim Nelson, we have now a start on how that should work. This is specially important to SMOP, because in SMOP everything must be handled in terms of API. And in that sense, a sketch on how the map operator would work is now at As a side comment, I'd like to answer to some questions from Leon Timmermans at our last update: The keyword "knowhow" specifies a Pure Prototype (without delegation). The idea is that the keyword itself specifies who implements it, for instance, the keyword "class" is always implemented by "ClassHOW", while the keyword "knowhow" is always implemented by "PurePrototypeHOW" (in mildew, that is). This is how you could, for instance, provide a keyword "controller" that would be implemented by Catalyst::Controller. The ".^!methods" syntax refers to the REPR(esentation) API which, in the case of SMOP, refers to the actual object storage. The REPR API is SMOP specific (at least for now), and that's why its use is restricted to the "knowhow ClassHOW" implementation, and avoided in other places.

This grant is completely finished, and the sekrit (well, at least one of them) from Adam was already published here: The grant should be closed during the next days. I hope!!


Post a comment

If you have an OpenId URL, you can enter it here to post comments on this site.


This page contains a single entry from the blog posted on December 18, 2008.

Many more entries can be found on the main index page or by looking through the archives.

Powered by