As per my grant conditions, here is a report for the August period.
I was mostly busy with other stuff this month, so didn't get to put in many hours on the grant.
Over the first 25 weeks I have now averaged about 15 hours per week, less than the nominal 20. I have used up approx 73% of the hours allocated to the grant.
Report for period 2010/08/01 to 2010/08/31 inclusive
Summary
Effort (HH::MM):
4:26 diagnosing bugs
5:35 fixing bugs
1:00 reviewing other people's bug fixes
0:00 reviewing ticket histories
6:45 review the ticket queue (triage)
-----
17:46 Total
Numbers of tickets closed:
1 tickets closed that have been worked on
0 tickets closed related to bugs that have been fixed
0 tickets closed that were reviewed but not worked on (triage)
-----
1 Total
Short Detail
]]>5:35 [perl #58530] Bus error with constant + overload + stash manipulation + bless ]
4:26 [perl #76872] perl debugger not working in taint mode
1:00 [perl #77352] Memory leaks in threaded Perl (cloning PVGVs and PL_my_cxt_list)
6:45 [TRIAGE]
Past month I've been to YAPC::EU where I spoke about part of my project. I also used it to discuss some of the Windows related issues I ran into with others and they have helped me getting clear what's the problem. I haven't quite fixed it yet though. I also worked on refactoring and expanding the documentation, and fixed some bugreports (though one still open). I wanted to be finished with both points by September 1st, but due to some unexpected school obligations I haven't been able to do so. I've set myself a new deadline for October 1st.]]>
I would like to thank everyone who provided feedback on this proposal.
]]>Yet Another Society d/b/a The Perl Foundation
340 S LEMON AVE #6055
WALNUT, CA 91789
UNITED STATES
I would like to thank everyone who provided feedback on this proposal.
]]>As per my grant conditions, here is a report for the July period.
This month was mainly spent on providing a general fix for the weak backreferences in stashes globs and CVs. This means that in general there are likely to be less crashes when doing odd things with stashes and globs.
Over the first 21 weeks I have now averaged about 17 hours per week, slightly less than the nominal 20. I have used up approx 70% of the hours allocated to the grant.
Report for period 2010/07/01 to 2010/07/31 inclusive
Summary
Effort (HH::MM):
7:40 diagnosing bugs
62:45 fixing bugs
0:00 reviewing other people's bug fixes
0:00 reviewing ticket histories
5:20 review the ticket queue (triage)
-----
75:45 Total
Numbers of tickets closed:
3 tickets closed that have been worked on
0 tickets closed related to bugs that have been fixed
0 tickets closed that were reviewed but not worked on (triage)
-----
3 Total
Short Detail
]]>54:40 [perl #58530] Bus error with constant + overload + stash manipulation + bless ]
8:05 [perl #75716] overload removes tainting
2:40 [perl #76540] panic: free from wrong pool when using a constant in a print statement
5:00 [perl #76716] Hash assignment can zap weak references to the hash
5:20 [TRIAGE]
Solomon Foster writes:
Introduction
While I worked on this grant, Rakudo has matured into a capable compiler ready to go out into the world as Rakudo Star. The work done under this grant ensures it will have a solid implementation of the S32 Numeric specification. And, as is usually the case when part of the Perl 6 specification is implemented for the first time, my experiences doing so have led to improvements and clarifications.
Deliverables Status
All deliverables have been achieved, and some additional work completed as well.
D1. The Numeric role is now in place as the root of all number types in Rakudo. Furthermore, the Numeric spec has been modified to include casting methods, the trigonometric base conversion methods, and a tentative approach to allow Numeric types that do not know of each other to be sorted together.
D2. The Real role is also in place. All of the built-in numeric types other than Complex now do Real. In addition to cleaning up the Real spec a bit, I introduced the Bridge casting method to make it very easy to write a new Real type which is fully interoperable with any other properly-coded Real type.
D3. Int, Rat, and Num now do the Real role in Rakudo. So far this seems to work very well, particularly because Int and Rat have many of their methods provided by Real.
D4. Complex is now a Numeric type composed of two Reals. Again, this is a good fit, a testament to the solid fundamental design of this area of the spec.
D5. The trig functionality is now implemented in Num and Complex, with Cool forwarding trig methods to the Numeric cast of their arguments, and Real forwarding them to the Bridge cast. In practice, this means that any Real type other than Num automatically gets its trig functionality by delegation to Num, though the Bridge approach allows implementations to select a different type to handle this.
D6. I added the real-bridge.t test file to the spectests to test that an arbitrary new Real type will easily fit properly into the existing scheme. I didn't add a Numeric-specific test file, as fewer tests were required there and they seemed to blend naturally into existing test files.
D7. With approximately 15,000 tests deleted or added, by far the biggest test changes were to the trig tests. I overhauled them to cover more usage cases while using far fewer actual test cases. In the process I found several trig bugs and fixed them.
In addition to this, I fixed the long-broken handling of long numeric constants with decimal points in Rakudo, as it turned out to be a major impediment to revising the trig tests. Though the resulting patch needs to be refactored, it represents a major improvement in an area users are likely to encounter.
Dissemination
I have written fourteen blog posts on the Numeric work, as well as remaining active on the #perl6 channel. I was also part of the Perl 6 contingent at YAPC::NA.
Conclusions
This grant has advanced the state of the art in Rakudo, both in terms of the numerics classes themselves and in terms of the bugs turned up and fixed in the general implementation of roles. It has improved the specification and the test suite. In addition, both the Numeric and Real roles are implemented in almost pure Perl 6, meaning that they should be usable with only minor tweaks in any sufficiently advanced Perl 6 implementation. I feel this work has been a solid success.
]]>Naim Shafiev, Zahatski Aliaksandr
[hidden email] [hidden email]
2000 $
Perl6 has reached development stage when on it is possible to program. The release of the version "Rakudo Star" for developers confirms it. At the given stage of development of language, it is important that the information on it was as it is possible is accessible to programmers, and also that who is interested in new technologies.
The permit preliminary on use of materials perl6-book [1] is obtained. However we plan to include own materials and working out examples in the book.
Also the book is opened for all Russian-speaking authors writing about perl6.
]]> Benefits to the Perl CommunityThe given book will help to expand a circle of programmers developing perl6. And it will help to approach the official version perl6. The book also will help to popularise perl6. News round working out of the book will draw attention of developers to this language.
Naim Shafiev Zahatski Aliaksandr 11 CHAPTERS (from [1])
The project page settles down to the address [2]. Repository is open and hosted at github[3]. Main format of chapters is Perldoc Pod ( Perl6 Pod) [4]. The book is accessible in two formats : pdf and html [2]
All material in book is licensed under a CC-by-nc-sa license: <http://creativecommons.org/licenses/by-nc-sa/2.5/> (attribution, noncommercial, share-alike),
We split our project in 11 parts.About the 5 days to each chapter.
We plan 2 month for work. We just start at 15 august.Complete date is 15 october
We plan to extend the book together with Rakudo Star, make available for download from most perl6 comunity projects, released to CPAN and make available as public repository.
Zahatski Aliaksandr
I'm citisen of Belarus.
I have been using Perl since 1997, member of Minsk.pm, Moscow.pm. Maintance ports of rakudo/parrot on FreeBSD (rakudoport.sourceforge.net). Implement perl6 pod in perl5 ([4])
Naim Shafiev
I'm 22 years old.Live in Moscow. Member of Moscow.pm. I use Perl since 2001,in diffent sections. My cpan page ([5]) For additional information you can ask from google/yahoo/what_you_want ;)
1. http://github.com/perl6/book 2. Project site http://zag.ru/perl6-book/ 3. Repository: http://github.com/zag/ru-perl6-book 4. Perl6::Pod http://search.cpan.org/dist/Perl6-Pod/ 5. http://search.cpan.org/~naim/
]]>Ricardo Filipo
[hidden email]
US$ 3.000
A realy killer CMS. So simple! So usefull!
use YAC;
my $web = new YAC;
$web->run();
# go to web!
A CMS (Content Management System) can be a web tool used in some internet business to help and administer media publication. As a market lider let's consider Drupal, a php based CMS, reference product used by everywere, a key tool in Obama's USA president campaign. The Drupal's grow in users (designers and coders) and contributed addons bring up to community a lot of php programmer's work and all market demmand for their code.
The media produced by CMS needs to integrate with other system like CRMs and ERPs or other enterprise legacy. The CMS's oportunity to programmers became from integration tools like a plugin system and addon facilities. It's the Drupal's case. That minimalistic simplicity is the strongest value. Programmers can hook systems in the CMS and final users can plug in at the website instantly.
The secret: The designer (or anybody) can do functional web without the coder. A CMS needs a simple and clear user interface. But the core integration to other systems where the coder works need to be simple too. Final result: Productivity.
In the Java, Python, Ruby or Asp world we will find similar tools like Typo, OpenCms, Django and Plone. Some simple, others powefull.
At perl tools we consider MovableType. Our work will not compete directly with MovableType as it integrates in Catalyst's control level as our implementation and plugin basis. The YAC's paradigma differ in our simplicity and minimalistic goal. Will be ok to one begin in YAC and integrates MovableType anytime.
The Catalyst Project need a extensible, basic CMS Design Pattern with the eyes in the final user and the hooks that a programmer can play. A CMS more simple than Drupal and with the power of CPAN and Catalyst.
We will consider cpan tools like Reaction, Mojo and Dancer.
http://en.wikipedia.org/wiki/Content_management_system http://en.wikipedia.org/wiki/List_of_content_management_systems http://www.movabletype.org http://search.cpan.org/~okko/Catalyst-Controller-MovableType-0.003/ http://en.wikipedia.org/wiki/OpenCms http://en.wikipedia.org/wiki/Drupal http://en.wikipedia.org/wiki/Plone_(software) http://en.wikipedia.org/wiki/Typo_(software) http://search.cpan.org/dist/Reaction/ http://search.cpan.org/dist/Mojolicious/ http://search.cpan.org/dist/Dancer/
* A so basic CMS Design Pattern on Catalyst with some helpers, tools and simple layout.
* Ajax user interface to some Catalyst core functions.
* CPAN module as the first implementation.
YAC will be a basic CMS Design Pattern with a simple user interface. No need to learn perl to play the YAC but a monger will play so well.
A CMS needs, at least, to create, edit and publish content and to link that content as web address (urls) to navigation or command menus and links. A good addon is a theme manager. The access to the CMS and this features need to be defined at Access Control List. The stronguest feature in the UI will be a simple plugin system integrated at cpan level.
The idea, as the first implementation, will be an extensible and basic ajax structure around jquery from Catalyst. Consider Catalyst::View::Component::jQuery.
As simple as an CMS can be, YAC will implement a simple user interface around Catalyst helpers, open hooks and plugins. This open design will encourage YAC's contributions grow.
The most important pattern to be done will be an open user interface paradigma. The idea about web interfaces can't neglect Ajax and the HTML 5 protocol.
Media Player
Image slide and carroussel
Dialogs and some jqueryUI things
Access Control List Auth
HTML WYSIWYG content editor
Acces to Catalyst and Plugins hooks at WYSIWYG content editor level
Image, media and file upload at WYSIWYG content editor level
Virtual file manager at WYSIWYG content editor level
Plugin System, Catalyst compatible
Hooks to some Catalyst helpers: create View, create Model, create Control
The project will begin at august 01 and end with the YAC's first module uploaded to cpan.
Define main concepts like public target and user perfil.
. Perl modules dependencies . Ajax basic framework
. Implement the first tests . Refine requirements . Design first UI tests
. Fish some feedback from monks and end users . Define some goals for next iteration
Implements all needs and issues from feedbacks. It will be the first simple but functional prototype.
. Perl work . Ajax structure
. Do tests . Do perl and ajax code . Design UI
. Fish some feedback from monks and end users . Define the next iteration in this phase
After the early alpha tests, maybe at 2010 november, we will take a Beta software without erros but the beta users need to feedback us about your needs.
. Perl work . Ajax work
. Do tests . Do perl and ajax code . Design and improve UI
. Fish some feedback from monks and end users . Define the final iteration in this phase
Do some analises over feedback to define the project future.
. Perl work . Ajax work . Do tests . Debug perl and ajax code . Redesign and improve UI
. Fish some feedback from monks and end users . Define next grant or projects future
6 months. Begin at august 1.
The first goal is to define the CMS Design Pattern concept.
A basic module will be released to CPAN with an example implementation.
Ricardo Filipo [hidden email]
See Lattes:
http://lattes.cnpq.br/0218483015859875
Experience about user interfaces, marketing, arts and perl.
]]>Jonathan "Duke" Leto.
[hidden email]
$1500
Currently the Parrot [0] Embedding subsystem is under-tested and under-documented. This grant proposes to add documentation for all public Embed/Extend API functions, write tests to increase the code coverage statistics for the Embed/Extend API to at least 95%, and update the Parrot Developer Docs (PDDs) [1] where errors or omissions are found. Any bugs found on the way that cannot be easily fixed will be reported on the Parrot Trac bug-tracker with test cases.
]]> Benefits to the Perl CommunityThere are many projects that will benefit from a completely documentated and thoroughly tested Parrot Embed Subsystem. Rakudo Perl 6 [2] is built on Parrot, so people who want to embed Rakudo Perl 6 in any other application will benefit. Blizkost is a bridge between Perl 5 and Parrot, and embeds both, so will greatly benefit from good documentation and tests. PL/Parrot [3] is a project that aims to embed Parrot in the PostgreSQL database [4]. Because Parrot is embedded in PostgreSQL, any language that runs on Parrot then can easily be embedded. PL/Perl6 is part of the PL/Parrot project, which loads Rakudo Perl 6 bytecode and therefore embeds a Perl 6 interpreter inside of PostgreSQL, for use in writed stored procedures. All of these projects will grealy benefit from complete documentation, as well any any future applications that want to embed or extend Parrot.
According to the code coverage stats [5] for Embed Extend API in Parrot Subversion revision 48100, the code coverage of src/embed.c is 65.2%, src/extend.c is 71.2% and src/extend_vtable.c is 5.3%. All of these will be raised to at least 95% by writing the appropriate tests.
The embed API documentation in docs/embed.pod [6] contains many parts which are missing documentation, such as the "Lexicals", "Type Signatures" and "Constants" sections. This will be filled with the appropriate documenation as it works currently.
A blog post will also be made on a blog syndicated by Perlsphere, describing how the grant proceeded, lessons learned, bugs found, a summary of tests written and links to the new documentation.
Currently only about 5 of over 180 functions in src/extend_vtable.c have test coverage. This will likely require around 50 tests fully cover each function, but this number can vary depending on the size of a test. The majority of these tests are simply calling a variety of VTABLE functions on PMCs, so each test has roughly the same structure. These tests will be added to t/src/extend_vtable.t (a new test file) and written in Perl 5.
The test coverage for src/embed.c and src/extend.c is much higher, so fewer tests will be required, but these tests will be more complicated due to the necessity of testing corner cases. Much of the uncovered code in src/embed.c relates to dealing packfiles and bytecode, error handling with I/O and using non-default runcores. These tests will be added to t/src/embed.t and t/src/extend.t, respectively, and written in Perl 5.
The documentation part of this grant should be straight-forward, but anything that needs to be clarified will be put to the parrot-dev mailing list.
The first inch-stone will be updating docs/embed.pod to contain the "Lexicals", "Type Signatures" and "Constants" sections. This should take one to two weeks.
The next two inch-stones will be to raise extend_vtable.c to 50% and then 95% coverage. This splits the work roughly in half, and I expect each to take roughly 2 weeks.
The tests for embed.c are fewer but will be trickier, so I expect to have two inch-stones, one for 80% coverage and the other for 95% coverage, and I expect each to take about 2-3 weeks.
The last inch-stone will be the easiest: writing and publishing the blog post. I expect this to take about a day.
I expect to be able to work about 5-10 hours per week, starting in October, so it does not conflict with Google Summer of Code. I expect that at this pace, this grant will take about 2-3 months to finish, taking into account that I may not work as much around the holidays.
Since this work will not change any features, it can be committed directly to Parrot SVN trunk incrementally. When the code coverage statistics have all reached >= 95%, the missing sections of documentation have been written and the blog post has been published, this grant will be considered complete.
I've hacked on Parrot Virtual Machine ever since I attended a Parrot Hackathon in 2008. I started off hacking on the Perl 6 test suite, after getting a commit bit from Larry at the hackathon due to my interest in fixing some bugs and adding tests relating to math functions and complex numbers. This quickly led me to bugs in Parrot, and I have mostly been writing tests and fixing bugs for the Parrot test suite ever since. I have converted large partions of the test suite from Perl 5 to PIR, as well as implementing parts of Test::More and a TAP Parser in PIR. I am also the organization administrator for The Perl Foundation/Parrot Foundation in Google Summer of Code 2010, as well as a mentor for Parrot on RTEMS [7].
I also hack on a project called PL/Parrot, which embeds Parrot and Rakudo Perl 6 into the PostgreSQL database. It is one of the first projects to embed Parrot in other applications, the others being mod_parrot and Blizkost. I believe it is the first project to embed Rakudo Perl 6. In the course of hacking on PL/Parrot, I have written tests for the Parrot embedd/extend API and fixed documentation, as well as contributing patches and tests for Rakudo.
Since I am a Parrot Core Developer, I can commit directly to Parrot trunk, which is the best scenario, since everyone will benefit incrementally from better code coverage and documentation.
As for other credentials, I have a Masters in Mathematics from University of Central Florida and have published various papers on differential equations, as well as being a coauthor of the Google Summer of Code Mentor Manual [8].
[1] http://docs.parrot.org/parrot/latest/html/pdds.html
[5] http://tapir2.ro.vutbr.cz/cover/cover-results/
[6] http://docs.parrot.org/parrot/devel/html/docs/embed.pod.html
[7] http://rtems.org
]]>Jozef Kutej
[hidden email]
$3000
The aim of the project would be to create automatic CPAN distribution to Debian deb packaging system. Then use it to autopackage and backport at least 50% of the CPAN distributions resulting in a Debian repository with multiple thousand Perl related packages.
]]> Benefits to the Perl CommunityDebian+Ubuntu operating systems are very popular among Perl developers. According to a http://perlide.org/poll201004/ - used by %37 percent. The Debian packaging proved over the time to be a consistent and a clean way to install software to the OS. Having CPAN distributions packaged as Debian packages would create a way to cleanly install, reinstall and uninstall Perl modules. Taking care of file conflicts and the records of which files comes from which source improving the deployment quality and maintainability.
One quite important advantage of another layer above the CPAN is the ability to apply custom patches in a well controlled and defined way.
Finish dh-make-pm (the Debian::Apt::PM manpage) and package at least 50% (10k) of CPAN distributions.
Create and maintain Debian repository for this packages + provide hosting for it for at least 1 year.
I'm already working on and experimenting with automated Debian packaging for couple of months already. The task is not easy. The biggest problem of CPAN is that there is no way how to declare non-CPAN dependencies like shared libraries, so it has to be done manually. Another problem is the CPAN module version to CPAN distribution version (that mostly match but not always) and then the Debian package to CPAN distribution mapping. This is needed to declare minimum package version when setting up dependencies. Another minor problem is that not all requires and build_requires are listed, which is not so common thanks to CPAN testers. Sometimes the CPAN distribution are not libraries but applications. And sometimes the distributions lack the META.yml file that makes the packager life harder.
I would like to build the automates system on top of the work of Debian-Perl group. The most of the most important CPAN distributions are already packaged and needs to be just backported for the stable distribution.
Just note: Autopackaged ≠ maintained.
Yes and no.
Currently Debian squeezy (testing) has 2000+ Perl related packages. That is ~10% of all CPAN distributions. The numbers, both CPAN and Debian are growing. But for Debian the amount is limited as the packages index files needs to be loaded and processed on different machines with often limited resources. In this regard it makes sense to create a special repository dedicated just for Perl.
Second reason why no, is that the Debian developers work on testing/unstable release. Stable is stable thanks to not upgrading, just doing security bug fixing. For a Perl world having 2-3 years old CPAN distributions can be acceptable in some cases but for most cases when a Perl product is actively developed no.
As I mentioned earlier another layer above CPAN allows more flexibility that Linux distribution maintainers need in order to work with "foreign" software. That means adding custom patches, tweaking and customizing. Distribution packaging also keed track of the installed files and of course the package names and versions. Installing, upgrading, downgrading, removing is a part of the system. It is also easy to find from which package the installed file is coming from. Or lookup a specific file in a package indexes. Packaging also makes sure that no two packages overwrites the same file.
dpkg-scanpmpackages can index Perl modules in a Debian repository.
apt-pm or the Debian::Apt::PM manpage can use them to look up minimal package
version for a given required module version. dh-make-pm will build
a package and recursively all the packages that are needed for it.
Ex. - dh-make-pm --cpan Geo::KML. If also apply local patches using the CPAN::Patches manpage.
Debian-Perl group patches and dependencies are extracted using cpan-patches-update-from-debian.
Current status of setting up the build system is here:
http://github.com/jozef/Debian-Apt-PM/blob/master/lib/Debian/Apt/PM/SettingUpBuildSystem.pod
Backport 1600+ modules that are maintained by Debian-Perl group for Debian Lenny (stable)
Note my plan is to have 1:1 relation CPAN distribution to Debian package, while original Debian has a couple of bundles to minimize the repository packages index sizes.
Continue with some CPAN author sample (ex. http://jozef.kutej.net/2010/07/cpan-authors-sample.html) and package their modules.
try to go beyond 10k packages
Set-up repository that can handle so many Debian packages
Create a repository web site with a detailed how-to reproduce so that anyone can easily build Debian packages for his/her internal purposes.
File bugs when build dependencies are missing.
Improve the CPAN::Patches manpage example set by collecting patches from RT to allow some unmaintained but still useful modules pass their tests and be packaged.
The project should be finish by the end of this year. Having funding from TPF will allow me to work starting from October 10-20h a week on it.
The grant can be simply evaluated by counting the number of packages in a repository. Installing them to a Debian Lenny machine.
José Castro Bruno Martins
[hidden email] [hidden email]
USD $ 2.500 (half for each of us)
Perlbal!
"It processes hundreds of millions of requests a day just for LiveJournal, Vox and TypePad and dozens of other "Web 2.0" applications."
It works great as a load balancer, wonderfully as a reverse proxy, marvellously as a web server.
If you know how to use it.
Perlbal lacks the documentation for even the simplest of tasks. Beginners can't possibly be expected to install and configure it by themselves, let alone write a plugin or accomplish some heavier task. At least not without losing some sanity.
However, all of these tasks are in fact easy ones.
But again, if you know how to do them.
This proposal aims at documenting several aspects of Perlbal and making several lives easier.
]]> Benefits to the Perl CommunityGrab a great Perl load balancing tool and make it usable to a broader audience.
Documentation detailing:
Installation
CookBook:
Using Perlbal as a reverse proxy
Using Perlbal as a load balancer
Using Perlbal as a web server
Managing and configuring Perlbal on-the-fly
Writing Plugins
Perlbal's Architecture at a glance
The resulting document should make non-Perlbal users able to install, configure and even write a Perlbal plugin without having to read Perlbal's code and/or bang their heads against a desk in the middle of the night.
This documentation will be written in POD, so it can be distributed along with the code. This will also allow for a quick conversion to Wiki format, so that the project page on Google Code can show the documentation on the web.
We already got in touch with Alan Kasindorf (Dormando), one of Perlbal's main developers/committers/release managers, who told us "That'd be great."
Alan pointed out the desire to write documentation for Perlbal and also the lack of time on his behalf.
We'll keep in touch with Alan to make sure the resulting documentation is in conformity to what would be expected.
The project should take us 8 weeks, so we decided to detail some of the steps.
Also note that unless the Grant Committee advises us not to, we're keen on putting the documentation on a public github project from day one. It should also be noted that we intend on receiving the grant money even if other people start contributing to the project and aid us.
As soon as a chapter is completed, we can put it on Perlbal's homepage.
We'll be installing Perlbal in a machine with barely anything on it (yes, we've done all these things before; several times).
We'll be documenting the process: all the steps, dependencies, requirements, problems we encounter and other possible problems we can think of.
This week should end with a document detailing everything a user needs to know to install Perlbal for the first time ever.
Now we'll configure Perlbal as a Load Balancer.
Once again, we're going to be documenting all the steps taken.
The week should end with a document describing how Perlbal works as a Load Balancer, how to set it up, and containing examples for a few different setups.
More of the same.
More documentation, detailing all one needs to know to set up Perlbal as a Reverse Proxy or a Web Server, complete with a few recipes.
During this week we'll be detailing how to check perlbal's status and how to configure it without restarting it.
We'll be writing a couple of plugins.
The process will be documented and this should result in a document that will render any reader able to write their own plugin.
We'll also list the existing plugins out there, try some of them and describe how to use them.
We'll be looking (once again) at Perlbal's architecture in order to detail it briefly to the curious user.
During this week we'll also be revising all the documentation written so far. That includes spell checking, grammar checking, content and recipes.
Since our plan comprises 8 weeks, we're expecting it to take us 10.
It may look odd to an outsider, but we both have very demanding jobs where occasionally situations occur that require our attention after hours. That will leave us with very little time for this project and will end up delaying things.
It could also happen that we finish the project in 8 weeks, but our experience tells us we're better off with antecipating one rough week over the course of each month.
We'll still be aiming at the 8 weeks schedule, though, and doing our best to reach that target.
We can begin work on September 27th (this would make the end date December 6th).
There will be documentation.
This should be readable, easy to understand, and contain instructions and examples on the following subjects:
Installation
CookBook:
Using Perlbal as a reverse proxy
Using Perlbal as a load balancer
Using Perlbal as a web server
Managing and configuring Perlbal on-the-fly
Writing Plugins
Perlbal's Architecture at a glance
We understand how readibility and ease of understanding are very subjective concepts, but this is a documentation project, so we feel those should be the criteria.
We considered having the completeness of the project being evaluated by having the documentation figure on Perlbal's wiki or source code, but since we know that other people have their own lives too we'd prefer a) not to depend on anyone else to have the grant being considered successful and b) not to thrust that responsibility on someone who has no responsibility towards the grant.
We're two Perl developers based in Lisbon. We work at SAPO - Portugal's largest web portal - where we make use of Perlbal in several projects.
We've both used Perlbal and wrote plugins for it (Bruno has managed to release one of them to CPAN).
We both have code on CPAN:
http://search.cpan.org/~cog/
http://search.cpan.org/~bsm/
We're both regulars at Perl events:
http://conferences.yapceurope.org/ye2010/user/154
http://conferences.yapceurope.org/ye2010/user/215
And, most important of all, we have both suffered at the hands of Perlbal, and wish no one else to have to suffer too.
Project homepage - http://www.danga.com/perlbal/
Source code - http://code.google.com/p/perlbal/
Wikipedia page - http://en.wikipedia.org/wiki/Perlbal
Perlbal stuff on CPAN - http://search.cpan.org/search?m=all&q=perlbal&s=1&n=50
]]>