fidzu : Perl

Brad Fitzpatrick has announced that he is working on bringing Perl to the Google App Engine.

I'm happy to announce that the Google App Engine team has given me permission to talk about a 20% project inside Google to to add Perl support to App Engine. To be clear: I'm not a member of the App Engine team and the App Engine team is not promising to add Perl support. They're just saying that I (along with other Perl hackers here at Google) are now allowed to work on this 20% project of ours out in the open where other Perl hackers can help us out, should you be so inclined.

The architectural changes to make this happen are not insignificant. Check out Brad's post to find out how you can help.

23 Jul 2008 4:47pm GMT

There are many ways you can categorize tests, but there's a basic distinction between developer tests and customer tests. The latter are also known as "acceptance" tests. They're about the customer experience. They're complete, end-to-end integration tests and basically assert if p, then q. Done properly, they are also redundant tests.

We're fortunate because we have an embedded tester on our team. He writes acceptance tests constantly. We've been struggling to manage our test suite effectively and not paying proper attention to his role has been part of the problem because we're losing independent verification.

Consider the following function:

sub pi { 22/7 }

Now that's clearly wrong. Now imagine the test:

is pi(), 22/7, 'pi should be correct';

That's useless because it passes, but it's wrong. Even if, for some reason, 22/7 was an acceptable value of π for you, the test is still wrong because you're using the same method of calculating π. One way of dealing with this is to assert the raw value:

is pi(), 3.14285714285714, 'pi should be correct';

This still might look wrong for this trivial example, but it works when you look at this:

my %recip_of = (
1 => 1,
2 => .5,
4 => .25,
);
while ( my ( $num, $recip ) = each %recip_of ) {
is recip($num), $recip, 'The reciprocal of $num should be correct';
}

Even though the values are hardcoded, you at least have independent verification. That's very important when testing. Merely duplicating your logic means duplicating your bugs.

That's why we've had a problem with our acceptance tests. They verify many of the tests that our code already verifies and are thus redundant, but here's what we've done: acceptance tests fail? Fix the code!

That's wrong. If an acceptance test fails, you absolutely must make sure you have developer tests which replicate the failure. If you don't, write them. Preferably, have completely separate frameworks for developer and acceptance tests (acceptance tests for Web-based systems can use Watir or Selenium). Acceptance tests should mirror the production environment and customer experience as closely as possible and should not be under developer control. Otherwise, you lose independent verification.

We've fallen into the nasty habit of fixing our code once an acceptance test fails. We should be able to just run our developer tests to feel rather confident in the health of our system, but we can't, so we have to rely on the acceptance tests. As a result, this adds 15 minutes to our test run.

If we don't have a corresponding developer test failing for every acceptance test failing, we have a problem. When you run a code coverage report, you should do it separately for developer and acceptance tests. By maintaining independent verification, you increase the chances of finding bugs and you can improve the overall reliability of your code.

23 Jul 2008 2:42pm GMT

I have just read that I was awarded a White Camel.

I guess I am supposed to say how unimportant that is and be super humble about it but frankly I was quite happy to receive it and I'll even be proud. After all, the list of others who have received is short but prestigious.

I was not as surprised as Tatsuhiko Miyagawa was because my nomination was - slightly emerassingly - made public. but there are so many others who probably did much more than I did. It is an honor to recive it.

Actually thinking about the award, I am not sure people know about it or who has received it. I knew about the award only by the annual announcement but I had no idea who received it early or why? I don't think that the award has too much meaning in most of the Perl community, mainly because they hardly know about it. Besides, there are lots of people who are outside the core community who only use perl who have no idea about this.

It's a pity as the award is mostly given for various activities that are related to advocating Perl and the Perl community so I think we should also use the award for the same thing.

So I am thinking what could be done to improve the situation? The obvious thing is that we should have an image of the award that can be placed on websites of the recipients linking to the award itself. Besides that we'll see what could be done to use this as another opportunity to promote Perl.

I would like to take the opportunity and congratulate both Jacinta Richardson and Tatsuhiko Miyagawa for their awards.

23 Jul 2008 11:55am GMT

Artur Bergman discusses Perl on Google's App Engine, while Brad Fitzpatrick announced Perl on App Engine. The important information is that Google will support the project only if the Perl community does most of the hard work. (This position seems reasonable to me; gift horses and all that.)

Read more of this story at use Perl.

23 Jul 2008 10:03am GMT

Artur Bergman discusses Perl on Google's App Engine, while Brad Fitzpatrick announced Perl on App Engine. The important information is that Google will support the project only if the Perl community does most of the hard work. (This position seems reasonable to me; gift horses and all that.)

23 Jul 2008 6:56am GMT

I've put together a video from several members of the Perl community giving the YAPC::EU committee 10 reasons YAPC::EU 2009 should be in Lisbon. These aren't the sort of things that they'll find in the proposal, but I hope they'll consider it when they vote!

Read more of this story at use Perl.

23 Jul 2008 5:04am GMT

jmcada writes "The White Camel Awards for 2008 were just presented at OSCON. This year's winners are Jacinta Richardson, Tatsuhiko Miyagawa, and Gabor Szabo. The winners have all made significant contributions to the Perl community. Congratulations to the winners!"

Read more of this story at use Perl.

23 Jul 2008 1:57am GMT

I've put together a video from several members of the Perl community giving the YAPC::EU committee 10 reasons YAPC::EU 2009 should be in Lisbon. These aren't the sort of things that they'll find in the proposal, but I hope they'll consider it when they vote!

22 Jul 2008 11:34pm GMT

Two unrelated observations regarding translations, with no relation to Perl:

1. I've recently watches a few episodes of Heros, this TV series about normal-people-turned-into-superheros. It features two guys from Japan. In the english version (at least in the one I've seen I think in Bratislava) the speak in Japanese with each other (with english subtitles), and in bad English when they talk to others. Makes perfect sense.
   
   Now, in the german dubbed version, they speak perfect German with each other. When they talk to others, they speak German with a Japanese accent. When others talk among themselves, the others speak perfect German. Yet the other do not understand what the Japanese guys say to each other. Complete nonsens! WTF where the german dubbing people thinking???
   
   It gets even more fun, when in one episode they meet a girl has the superpower to learn very fast. She learns japanese, and speaks japanese with them. Like, actually japanese (with german subtitles). And they answer in japanes, only to fall back to bad german after a few sentences...
2. I've recently read the book Unlundun. It's a nice book with a lot of interesting ideas and funny character names. When I read it I was quite sure that the german translation just has to suck. Eg., you have black windows (space-wraping windows with spidery legs) living in webminster abbey. Or binjas (trash bins with supreme ninja fighting skills).
   
   Last week I bought the german translation (partly for my kids, but also partly to check the translation). It's not as bad as I suspected, but of course has some issues. The binjas were turned into rabjats, which makes absolutly no sense in german. The black windows are called 'finsterfenster' (dark window), which completly looses the reference to spiders (black widow - black window). At least webminster abbey is turned into 'Netzminster Abbey', keeping it's similarity to the Westminster abbey.
   
   But I was dissappointed about the utterlings. When Deeba, a teen from London, is forced to teach Mr. Speaker (every word he says takes on some weird form and lives on as an utterling) new words, she comes up with things like bling and diss, which indeed are newish words. Instead of leaving those words as 'bling' and 'diss' (which thanks to MTV etc are known in german, but maybe not widely) they are translated to 'Klunker' and 'motzen', which might be slang, but defintly not new words (thus destroying the plot, which explicetly asks for new words).
   
   It's strange, because some words (The Armets, and the mighty Klinneract) are left untranslated (sometimes with footnotes to explain their meaning and their mis-pronounciation by Unlunduners (eg 'Clean Air Act' -> 'Klinneract')).
   
   Anyway, I think translating books that play with the language they are written in is one of the hardest jobs around, and basically bound to fail.

22 Jul 2008 8:49pm GMT

We have changed the date of Russian Far East Perl Workshop, moving it one week further. The new date is 26 September, it's Friday.We joined our event to the Coastal Internet-Forum (PRIF-2008), which happens to happen on 22-26th of September, the dates very close to our initial dates of the workshop.We are still a separate event, and after joining to PRIF we gain in having a venue equipped with desktop computers, projector and internet access. And it also potentially can attract more people for the workshop.Thanks to Linux Centre & Linux Format for suggesting to join the event in Vladivostok.

Read more of this story at use Perl.

22 Jul 2008 7:01pm GMT

Oops That namespace is taken. I'll think again. Suggestions welcome.

Quite often I find myself needing a simple check to see if a sub has already been called. This happens all the time and I hate coding this.

use Sub::Called 'already_called', 'not_called';

sub user {
unless (already_called) { # only gets called once
My::Fixtures::Users->load;
}
...
}

sub schema {
if ( not_called ) {
# setup schema
}
else {
return $schema;
}
}

Yeah, it was only five minutes to write and it's a minor, minor nit, but I hopefully won't have to worry about it again. It should be on the CPAN soon.

It checks the package and subroutine to determine if it's been called yet.

It's possibly my most trivial module. Flame away!

22 Jul 2008 12:42pm GMT

trickle 'user-space bandwidth shaper', ie. like nice(1) for network bandwidth (via Danny)

RFC 5218 - What Makes For a Successful Protocol? 'Based on case studies, this document identifies some of the factors influencing success and failure of protocol designs.' (via spicylinks)

21 Jul 2008 10:32am GMT

A common response to "why aren't you testing" is "we have legacy code that's hard to test"? Having been in that situation, I can feel your pain, but you can still test if you think about it. The main thing is to understand how your customer views your code. Consider a typical Web site. They don't see a bunch of global variables, 500 line functions and hard-code HTML 3.2 embedded in said functions. They see a form that they fill in and submit. It's easy. So that's what you test.

my $mech = Test::WWW::Mechanize->new;
$mech->get_ok($login_url, "We should be able to get $login_url");
$mech->submit_form_ok({
form_number => 1,
fields => {
username => $username,
password => $password,
},
}, "... and we should be able to login to our Web site");
$mech->title_is("Welcome to example.com, $fullname");

Congrats. You've just written your first test. You've bypassed all of your worry of globals, 500 line subroutines, embedded HTML, and so on. And you know what? There's a good chance that the above tests have verified a heck of a lot of code.

This doesn't mean that your particular situation is this easy, but if you think hard enough, you can solve this problem. You just need to be creative.

You start writing tests like that and after a while, you can have a pretty comprehensive test suite and start feeling comfortable about refactoring. Fear-driven development becomes a thing of the past.

21 Jul 2008 8:47am GMT

$ git clone git://git.jrock.us/Module-InstallDeps

21 Jul 2008 6:47am GMT

Recently there has been a feeling of growing discontent: how could Ruby - which felt so new and liberating two years ago - get saddled with so much negative baggage, so quickly?

- Pete Forde, We are RubyFringe

Take your pick of the aggressively dismissive attitude toward other approaches, vigorous and self-congratulatory messianic zeal, egocentric and deliberate misunderstanding of the rest of the world of software development, verbose and willful discussion of, despite baffling ignorance of, other programming languages, misunderstanding of MVC and the Active Record pattern, booing Dave Thomas at RailsConf 2007 for questioning why it was necessary to create a "Women of Rails" website featuring pictures of attendees, cheering at RailsConf 2007 when Chad Fowler said "People call us arrogant" when his point is that that's a bad thing, and the baffling fourteen year old boy sensibilities of the Rails Envy commercials, including my personal favorite, comparing the V in MVC to a drunken prom date.

I can understand arrogance from Olympians or research scientists who've just cured cancer. It seems out of place for people writing CRUD applications, even if they're all shiny with rounded corners and Ajax fade ins.

21 Jul 2008 4:48am GMT

autodie 1.99 stable released - codename jarich
I said that I'd get a stable release of autodie out before OSCON. Since OSCON starts in 5 hours, and I intend to use all that time for sleeping, that means it's being released right now.

After 243 commits since project inception, and three and a half months of work, the first stable release of autodie is making its way to the CPAN. This is not marked as a developer release, so you'll be able to install it using the regular CPAN installer, or dh-make-perl, or whatever other tools you prefer to use to manage your modules.

The observant reader will notice this is a 1.99 release, but I've occasionally bandied around the phrase "autodie - It's Fatal 2.0". The 1.99 release is because I expect to get feedback, patches, and bug-swatting done over OSCON, so the hallowed 2.0 version will appear after the 1.99 release has run the gauntlet of being (ab)used by my peers.

That's not to say the 1.99 release isn't good. It's awesome. autodie has already gone through eight dev releases, as well as being used on my own systems. Go and use it.

Note that autodie does overpower (and on some systems, overwrite) the version of Fatal.pm that comes with Perl. Some of the internal interfaces of Fatal have changed to support new functionality. If you've been calling internal Fatal subroutines (ie, things not documented in perldoc Fatal), then you may wish to hold off until the 2.00 release.

The 1.99 release codename is "jarich", after Jacinta "jarich" Richardson, who pretty much gave up an entire week of her time assisting me with talk preparations for OSCON, and doing practically nothing else. Jacinta, you rock.

For those of you at OSCON, I'll be doing a short talk on autodie at the Perl lightning talks, including showing off some of the cool features like building your own language packs and exception systems.

Posted: 21st July 2008.

Tags: autodie Fatal lethal oscon oscon2008 perl

Bookmark:

21 Jul 2008 12:00am GMT

Hi,

The parrot packages with libparrot0 and libparrot-devel,
plus parrot-perl6 and parrot-languages are updated to 0.6.4 for
the Cygwin distribution.

Parrot is a virtual machine designed to efficiently compile and
execute bytecode for interpreted languages.
Parrot is a target for the upcoming Perl 6 and a lot of other
languages.

Canonical homepage:
http://www.parrotcode.org/
The Parrot wiki is at http://www.perlfoundation.org/parrot/

Canonical download:
http://www.parrotcode.org/release/devel

Updates appear timely every month until v1.0 at the end of this year due
to stable funding. 0.6.5 will be released on 19 Aug 2008.

Packaging Details:

* The php implementation is now called pipp.
* /usr/bin/libparrot.dll is now /usr/bin/cygparrot0_6_4.dll
* moved examples and parrot_config from libparrot-devel to parrot
* Added list of local patches to myconfig
[perl #51944] [DOCS] Cygwin Readme
[perl #56544] [PATCH] install_files.pl
[perl #56558] [PATCH] pdb rename to parrot_debugger
[perl #56562] [PATCH] root.in: add cygwin importlib
[perl #56998] [TODO] rename cygwin dll to
cygparrot$MAJOR_$MINOR_$PATCH.dll
[perl #57006] [PATCH] add cygwin opengl config quirks
[perl #57110] [PATCH] ncurses for cygwin
[perl #57112] [PATCH] postgres for cygwin
[perl #57114] [PATCH] urm RealBin issue
* added man1 pages for most binaries
* added vim and emacs support files
* added parrot-json

----

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page. This downloads setup.exe to your
system. Once you've downloaded setup.exe, run it and select "Editors"
or "Text" and then click on the appropriate fields until the above
announced version numbers appear if they are not displayed already.

If your mirror doesn't yet have the latest version of this package after
24 hours, you can either continue to wait for that site to be updated or
you can try to find another mirror.

Please send questions or comments to the Cygwin mailing list at:
cygwin@cygwin.com

If you want to subscribe go to:
http://cygwin.com/ml/cygwin/

I would appreciate if you would use this mailing list rather than
emailing me directly. This includes ideas and comments about the setup
utility or Cygwin in general.

If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

19 Jul 2008 10:11am GMT

Hi,

The 0.6.3 parrot packages with libparrot0 and libparrot-devel,
plus parrot-perl6 and parrot-languages are now available with
the Cygwin distribution.

Parrot is a virtual machine designed to efficiently compile and
execute bytecode for interpreted languages.
Parrot is a target for the upcoming Perl 6 and a lot of other
languages.

.include searchpath:
/usr/runtime/parrot/include (bogus)
/usr/runtime/parrot (bogus)
/usr (bogus)
/usr/lib/parrot/include
/usr/lib/parrot/
.

with the extensions: "" .exe .lnk .exe.lnk .past .past.exe .past.lnk
.past.exe.lnk .pir .pir.exe .pir.lnk .pir.exe.lnk
The .exe and .lnk versions are of course cygwin-magic only.

Runtime requirements:
libparrot0 libreadline6 ncurses libintl8 libicu38 libgmp3 libgdbm4

Optional requirements:
libglut3 pcre xorg-x11-base xorg-x11-bin-dlls libpq5 openssl

Build requirements:
gcc make perl readline libncurses-devel libgmp-devel
libgdbm-devel pcre-devel

Optional build requirements:
libglut-devel libicu-devel openssl-devel

Required CPAN packages:
Test::TAP::HTMLMatrix if you want to run the language smoke tests
with make languages-smoke.
Test::Base for some APL language tests.

Canonical homepage:
http://www.parrotcode.org/
The Parrot wiki is at http://www.perlfoundation.org/parrot/

Canonical download:
http://www.parrotcode.org/release/devel

Updates appear timely every month until v1.0 at the end of this year due
to stable funding. 0.6.4 will be uploaded really soon - tomorrow
hopefully, 0.6.5 will be released on 19 Aug 2008.

Packaging Details:

The php implementation, now called pipp, is here still called plumhead.
This will be pipp from the next release 0.6.4 on.

parrot-languages is going the single package route, contrary to the
fedora split. They have for every single language a seperate package.
Otherwise the package layout is similar to fedora, debian, gentoo and
freebsd.

perl6 is called /usr/bin/perl6.exe, the other languages have a "parrot-"
prefix. There are no perl6 libraries at all included.

pdb is called parrot_pdb, and will be named parrot_debugger in the
future as voted yesterday - you see the packaging is still a bit in flux
:) - disassemble is already called pbc_disassemble.

The SDL library references cygSDL-1-2-0.dll per ffi, which is only in
cygports: http://cygwinports.dotsrc.org/

/usr/bin/libparrot.dll will be /usr/bin/cygparrot0_6_4.dll for the next
version.

There are no man(1) pages yet. This is in work.
----

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page. This downloads setup.exe to your
system. Once you've downloaded setup.exe, run it and select "Editors"
or "Text" and then click on the appropriate fields until the above
announced version numbers appear if they are not displayed already.

If your mirror doesn't yet have the latest version of this package after
24 hours, you can either continue to wait for that site to be updated or
you can try to find another mirror.

Please send questions or comments to the Cygwin mailing list at:
cygwin@cygwin.com

If you want to subscribe go to:
http://cygwin.com/ml/cygwin/

I would appreciate if you would use this mailing list rather than
emailing me directly. This includes ideas and comments about the setup
utility or Cygwin in general.

If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

16 Jul 2008 11:04am GMT

Hi,

on behalf of the Parrot team, I'm proud to announce the release of
Parrot 0.6.4
"St. Vincent Amazon."

Parrot 0.6.4 is available via CPAN, or follow the download
instructions at http://parrotcode.org/source.html. For those who would
like to develop on
Parrot, or help develop Parrot itself, we recommend using Subversion on
the source code repository to get the latest and best Parrot code.

Parrot 0.6.4 News:
- Documentation
+ removed a lot of old information from the FAQ
+ improved function level documentation
- Configuration
+ removed the configuration item 'has_gnu_m4'
+ refactored ICU-detection
- Languages
+ ChitChat
- improved the Smalltalk implementation
+ Pipp
- renamed Plumhead to Pipp
- support for a lot of builtin functions.
- Pipp now uses PHP specific data types.
- converted from PCT with TGE to PCT with NQP actions
- improvements in the PCT variant by using optok parsing
- start of object support
+ pir
- simple assignments work
+ json
- added a PCT-based implementation of JSON parsing
+ lolcode
- improved handling of symbols
- added support for block handling
- added support for globals
+ Lua
- more tests
+ Rakudo
- updated Range implementation
- added enums
- added generic type declarations (::T)
- added runtime mixing of roles with 'does' and 'but'
- added generic type declarations
- fixed handling of implicit lexicals ($_, $!, and $/)
- fixed implicit method calls on $_
- improved complex math builtins, added Complex
- moved many builtins to class Any
- declaration of lists of variables now work
- improved test infrastructure
- 910 additional passing spec tests since last release
- more convergence with STD.pm grammar
- added named 0-ary parsing and ops
- Compilers
+ PCT:
- allowed subroutine and method names to be a PAST tree that
produces the name
- Improved lexical handling
- Tools
+ pbc_disassemble renamed from disassemble
- Implementation
+ allowed .macro_const in PIR
+ added the flag :lexid(...) for subroutines
+ made multiple dispatch work for sub types
+ fixed garbage collection bug related to the metadata attached to a
PMC_EXT structure
+ added a warning when using deprecated opcodes
+ simplified the stacks implementation
+ fixed C++ build
+ improved closure and lexical support
+ improved IMCC register allocator
+ added cache for all runtime-constant strings, reducing memory usage
- Miscellaneous
+ improved OpenGL/GLU/GLUT bindings
+ added a standard profile for Perl::Critic coding standard testing
+ added support for smoke testing with Smolder
+ enabled use of Test::Harness 3.0 if available, but don't require it
for 'make test'
+ added the executable 'parrot_config' to query Parrot configuration


Many thanks to all our contributors for making this possible, and our
sponsors
for supporting this project. Our next scheduled release is August 19th
2008.

Enjoy!

15 Jul 2008 7:51am GMT

Today, we're releasing RT 3.8.0, the first major upgrade to RT in about two years. Over the past two years, we've been working hard to improve RT. We're very proud of RT 3.8 and hope you'll find it a worthy upgrade.

Many, but not all, of the new features you'll find in RT 3.8 are the direct result of work we did for clients. WYSIWYG email composition, GnuPG email signatures and encryption, ticket relationship graphs and email digests are all enhanced versions of features we originally developed as "custom" extensions for clients.

When we haven't been busy improving RT for clients, we've spent much of our time tidying and polishing RT. In the past few months, we've resolved over 540 bugs and feature requests. RT's new visual style, "on-line" dashboards, workflow and performance improvements, along with literally hundreds of bug fixes and performance improvements are the direct result of your patches, bug reports and suggestions over the past few years.

I could easily claim that there are too many new features to list, but the reality is simply that there are more new features I could list than you're willing to read about. If you're interested in the full, sordid history of changes to RT since RT 3.6, you can find the full history in our public subversion repository at svn://svn.bestpractical.com/rt.

What's new in RT 3.8 A new visual style

We've completely overhauled RT's visual style to look a bit more like what you'd expect modern enterprise software to look like. The pleasing blue gradient background and rounded corners will keep you on an even keel when dealing with even the most complex and frustrating issues. (We've also extensively tweaked the fonts, menus and layouts based on feedback from dozens of testers. RT has always been easy for your team to pick up with little or no user training. The usability improvements in RT 3.8 should help keep your team happy and productive. )

Richtext email

RT has been around since before the days of HTML email. We've completely retooled inline RT's email composition system to give your team a "WYSIWYG" composition window for HTML email using FCKEditor. We chose FCKEditor because of its excellent cross-platform support. (It even preserves styles when you copy and paste from your word processor!) When creating, replying to or commenting on tickets, you can now make things bold, italic, red or blue (and do all sorts of other things to your text as well). At the same time, we overhauled how RT displays HTML and multipart email messages to work more like desktop email clients. We've always worked hard to make RT a good email citizen. That's more true now than ever. When sending styled email, RT will always send a plain text equivalent along as well. If you don't need rich text support locally, you can disable it from RT's configuration file.

Email signatures and encryption

Many organizations around the world use RT to manage the information flow of their mission-critical security applications. Pretty Good Privacy (PGP) is the global standard for inter-organization secure email. We've updated RT with comprehensive support for PGP using the Gnu Privacy Guard. RT can now verify PGP signatures on incoming messages, decrypt encrypted messages and sign and encrypt outgoing mail.

User preferences

RT has always been incredibly configurable and flexible. Through version 3.6, however, most of that configurability was in the hands of developers and administrators alone. Starting with version 3.8, we've introduced a new user preference system. For version 3.8.0, we've added the set of preferences we found our users most commonly reaching for, including:

• Ticket history ordering
• Timezone
• Date and time format
• Username format
• Default queue
• Size of message text boxes

Dashboards

With RT, it's easy to customize your home page to show you the saved searches and charts which matter to you on a daily basis. Your RT homepage is your personal dashboard. In RT 3.8, we've made it possible for you to build and save dashboards for particular projects or groups. Dashboards can contain saved searches, saved graphs and ticket relationship charts. You can, of course, keep these dashboards to yourself, but you can also share them with the other members of a group you're in. With just a few clicks, you can schedule daily, weekly or monthly delivery of a dashboard. Here at Best Practical, we used this feature to send daily updates on the progress of the RT 3.8 release to the whole team -- complete with a list of open critical issues and a recap of all the issues resolved in the past day.

Charts of ticket relationships

RT has a rich "relationships" system which lets you link tickets (or just about anything else) together to form larger projects. You can set up "depends on" relationships, "parent child" relationships and simple "refers to" links. It's always been easy to see a single ticket's relationships as a list. Beginning in RT 3.8, you can build clickable diagrams of tickets and all their relationships. With a few clicks, you can customize which ticket attributes are displayed and how the chart will be rendered. You can save charts you build and include them on your homepage or in RT's new dashboards.

Lots more!

• Breeze through upgrades with new upgrade tools
• Subscribe to iCalendar feeds of ticket due dates
• Bookmark frequently-used tickets
• Turn off mail from RT when you go on vacation
• Get your mail from RT as a daily or weekly batch
• Delete historical or spam tickets with RT::Shredder (only as a superuser)
• Set up more configurable business rules with new Scrip Conditions and Actions
• Forward tickets to third-parties from within RT
• Enable and Disable RT extensions with the new Plugins system
• Automatically log out inactive users with rt-clean-sessions
• Run faster with less memory, thanks to numerous performance improvements and bug fixes.

Download RT

You can download RT 3.8.0 at: http://download.bestpractical.com/pub/rt/release/rt-3.8.0.tar.gz
This release of RT has been digitally signed with PGP. You can download the signature file at: http://download.bestpractical.com/pub/rt/release/rt-3.8.0.tar.gz.sig

Commercial Support

We sell commercial support for RT. If your organization uses RT in production, you should consider buying a support contract to help ensure that your RT instance continues to work well. To celebrate the release of RT 3.8, we're offering:

• free upgrade support to new support contract customers.
• a 20% discount on upgrades to RT 3.8 from any previous version of RT.
• a 10% discount on migration to RT 3.8 from any other ticketing or issue tracking system.

To find out more about our support options, please contact us at sales@bestpractical.com.

2008 RT Fall Training

We provide unparalleled instruction in how to get the most out of RT. On October 24, we will be offering an intensive one-day developer and administrator training session taught by the developers who built RT. This is the first training session where we will present new features and changes in RT 3.8.

This comprehensive session will cover:

• New features in RT 3.8
• RT's system architecture
• A guided tour of the RT source code
• Extension mechanisms you can use to customize RT
• How to tie RT into your existing authentication infrastructure
• Building your own tools that talk to the RT backend
• Automating common procedures
• Customizing RT's workflow to match your own
• How to write custom reports based on RT's data

This session will be only be offered in:

San Francisco, CA on Friday, October 24th, 2008

Reservations

The cost of training is $995 per participant. Discounts are available for organizations sending more than one participant and for academic institutions. To reserve your seat, please send mail to training@bestpractical.com with the names and email addresses of all attendees. Register now to reserve your seat! Space is limited.

Private training

Additionally, we offer private training sessions for organizations. If you would like to schedule a private training session, please drop us a line at training@bestpractical.com.

14 Jul 2008 7:57pm GMT

From a comment on rakudo.org:

dstar said:
One thing I'm not clear on -- Rakudo is passing 1100 tests out of how many? IE, where's the goal line?

Well, the "goal line" is by definition a moving target. There's not a hard number we can cite -- even in Perl 5 the size of the test suite constantly changes as new features are added and new bugs are found. There will be a point at which we declare a particular set of tests as being the "official test suite" for Perl 6.0.0, but we're really not close to that point yet. Here's what I can say about the test suite thus far:

The "official test suite" is being built from the test suite that was created for Pugs -- the Pugs test suite has approximately 19,000 tests in it. But, the Pugs suite itself was somewhat disorganized and thus difficult to determine test coverage. It also has many tests that are incorrect, either because the language specification has changed since they were written or because they were incorrect in the original.

Thus, Adrian Kreher (mentored by Moritz Lenz and Jerry Gay) is in the process of conducting a complete review and reorganization of the Pugs test suite into the "official test suite", or what we call the "spectests" (in t/spec/ of the Pugs repository). We estimate that about 5,000 (25%-30%) of the tests in Pugs have been reviewed and migrated into t/spec/. And just because a test appears in t/spec/ doesn't mean it's necessarily correct -- we continue to find places where the test doesn't exactly match the language specification (or the language specification is ambiguous and needs clarification in the test).

Within the 5,000 or so spectests, there's a subset of 75 test files (~1,500 tests) that have been identified as the "spectest regression suite" for Rakudo. These are test files that we expect Rakudo to pass at any given moment in time, such that someone can do "make spectest_regression" and get back "All tests successful." The developers also use this to make sure that any changes to Rakudo don't break existing functionality. Of course, the spectest_regression suite is itself a rapidly moving target as Rakudo acquires more features and as the test suite evolves. For example, at the beginning of June there were 52 files (892 tests) in the spectest regression suite, today (July 1) we have 75 files (1522 tests) in the regression suite.

And beyond all of this have been comments from Larry and others that eventually the official test suite will likely be double or triple the current size of the Pugs suite -- I think I've heard estimates of 40,000-50,000 tests in the suite when we're "finished".

So, return to the original question of "Where's the goal line?", you can see that there's not really a straightforward answer. This is why I haven't been saying things like "passing 1100 out of N tests", because the exact value of N depends on what's being measured to depend on what one considers important, and until more of the official test suite is ready any useful N doesn't really correspond to the "goal line" of a released Perl 6. So, the number I tend to focus on at the moment is the absolute rate of increase in passing tests -- currently it's about 100 new passing tests per week. I expect that trend to continue or improve in the coming months. As long as the number of passing tests is increasing, we're making progress.

An obvious intermediate goal is to have Rakudo passing at least the tests in the Pugs test suite. This depends not only on Rakudo development progress, but also progress in reviewing the Pugs tests and migrating them into t/spec/ . This is also why the Perl 6 developers are constantly inviting and encouraging people to help with building and reviewing the test suite. As mentioned above, only about 25%-30% of the Pugs test suite has made it into t/spec/, and many of those have been simply moved into t/spec/ without significant review or verification against the Synopses. Once we have most of the Pugs test suite migrated to t/spec/ I'll probably start reporting passing tests relative to the size of overall suite. (But I'll also continue reporting the passing rate increase as well.)

Lastly, this is a good place for me to repeat an invitation I made at YAPC::NA: For those who are interested in helping with the test suite but don't know where to start, I suggest "adopting" a particular Perl 6 feature or Synopsis section and saying "I'm going to develop the tests for that feature." This doesn't require learning all of Perl 6, it only requires learning those parts of Perl 6 that are necessary for testing that particular feature. It also gives a sense of ownership for a part of Perl 6, as in "I did that part of the test suite".

I'll undoubtedly add more information about Perl 6 testing in the near future, as it's an area where many hands can help make light work.

Thanks to dstar for asking the question that prompted this post. :-)

Pm

01 Jul 2008 4:41pm GMT

This is the third "monthly" report for my development grant from the Mozilla Foundation and The Perl Foundation. As regular readers will have surmised by now, the definition of "month" has been stretched a bit for a variety of reasons, but as this report and the other reports will show, it's not been a hindrance to our progress.

To review, the primary goals of this grant are:

1. To have a Perl 6 on Parrot implementation that supports commonly-used Perl 6 constructs;
2. Improvements to the Perl 6 test suite;
3. To substantially complete the Parrot Compiler Toolkit, including documentation;
4. Increased community participation in Perl 6 and Parrot development, including development efforts on other languages utilizing Parrot and the Parrot Compiler Toolkit.

It's now clear that the work under this grant has been (or otherwise shortly will be) successful in meeting all of the above goals. As before, in this report I'll highlight the major events and milestones that have been reached since the previous report, and let my other article postings provide increased details.

Progress, April 2008 to June 2008

* Of course, one of the biggest news items is that in May 2008 The Perl Foundation received a $200,000 philanthropic donation from Ian Hague, roughly half of which will be used to support further development of Perl 6 and to build upon the work performed under this grant.

* In addition, Jonathan Worthington received a grant from Vienna.pm to continue his work on developing Rakudo; this grant led to implementations of type checking, multimethod dispatch, regex and grammar support, public and private methods, Ranges, scalar variables, runtime role composition, enums, and a lot more.

* During this period we continued to improve the documentation for the Rakudo (Perl 6 on Parrot) compiler, although more focus in this area is definitely needed. In April we published a list of Rakudo milestones as a basic "road map" to guide continued development. We also generated numerous articles and blog postings that describe the various features of the compiler and how it's all being put together.

* In May we started measuring progress on Rakudo by the number of passing tests from the official test suite. As of June 30, Rakudo Perl is passing 1126 tests from the official test suite, and we're averaging 100 new passing tests per week. I'm hoping this trend will continue.

* To facilitate development Moritz Lenz and Jerry Gay refactored the test harness to provide a "make spectest_regression" target. Now Rakudo developers can verify that changes to the compiler are not breaking any tests that were previously passing. Based on this we're able to to maintain a spectest-progress file, and Moritz created an excellent utility to display the progress as a graph:

http://www.pmichaud.com/perl6/rakudo-tests-2008-06-30.png

* Work on refactoring, improving, and updating the Perl 6 test suite is being handled by Adrian Kreher, Moritz Lenz, and Jerry Gay under a Google Summer of Code grant, along with test contributions and suggestions from many others. We now have a better process in place for reviewing and updating tests; this has enabled progress in other areas to also proceed more rapidly.

* Many of the basic Perl 6 statement types and constructs are now in place -- the primary notable exception being list assignment and lazy list operations. Implementing list assignment properly will require some modifications to the underlying grammar engine -- that work is expected to occur later this summer. Lazy lists and operators are awaiting some improvements to Parrot's exception subsystem (expected in early July).

* The Parrot Compiler Toolkit (PCT) and Not Quite Perl (NQP) tools developed in the first months of this grant continues to demonstrate its power and effectiveness. Most of the HLL translators for Parrot have either adopted or are planning to using PCT/NQP for their underlying code generation. In particular, both the Ruby and PHP implementations (Cardinal and Plumhead) have made significant progress by using the Parrot compiler tools. PCT now has support for basic "return" control exceptions -- other types of control exceptions will be added shortly.

* We continue to gather more active contributors to Parrot and Rakudo Perl. There has been a substantial increase in patch submissions -- so much so that we've held discussions about how we might improve our ability to respond to code contributions more quickly. I've given presentations about the recent improvements at FOSDEM 2008, The Texas Open Source Symposium, DFW Perl Mongers, and YAPC::NA 2008. Each of these presentations have increased participation and enthusiasm about Rakudo Perl and Parrot. More presentations about the project will be made at OSCON 2008 and YAPC::Europe 2008.

* At YAPC::NA 2008 Jim Keenan, Will Coleda, and others on the Parrot team organized a "Perl 6 and Parrot Workshop", in which we helped approximately 20 people download and build Parrot and Rakudo Perl and run through the basic test suite. This has further increased interest in the project; indeed, some of the participants came across some bugs (and filed bug reports and/or patches), and many are planning to hold similar workshops in their local user groups. We plan to repeat the workshop at other venues, including the Pittsburgh Perl Workshop, YAPC::EU, and likely other workshops and user groups.

* All of the "specific tasks" targeted in the end of the last grant report have been achieved.

Where things are headed next

The goal for the next few weeks will be to continue (and perhaps improve) the excellent development momentum achieved during the past couple of months. In particular, we will continue improving the test suite and Rakudo's ability to pass tests from the suite. In addition, as some new Parrot features become available (e.g., improved exception and lexical variable handling) we will be able to take advantage of them in the compilers and compiler toolkits. We will also begin identifying the specific individuals and tasks to be engaged under grants from the Ian Hague donation.

Specific tasks for the remainder of this grant:

• Continue improving the official test suite
• Develop a more complete implementation of Perl 6's exception model
• Implement basic lazy lists and operators
• More refactoring of basic operators, functions, and classes according to recent changes in the language specification
• Allow compiler and builtin library components to be written in Perl 6
• Continue convergence efforts with other Perl 6 implementations
• Write the final grant report, documenting the work performed, quantifying results achieved, and outlining the next phases of development

As things stand today, I expect to publish the final report for this grant sometime around OSCON 2008 (July 2008). Of course, I will continue to post articles at use.perl, rakudo.org, and parrotblog.org.

Thanks for reading!

Pm

01 Jul 2008 4:59am GMT

Just as a heads up, we've discovered that rt.cpan.org has started to send out mail about bugs to CPAN authors who aren't actually maintainers of the distribution.

The bug is the unintended consequence of some work we've been doing to make rt.cpan.org faster and easier to use.

I could claim that it's a cool new feature to help better publicize issues in CPAN distributions, but I can't quite bring myself to lie like that.

We're working on the issue and will get it sorted out as quickly as we possibly can. I'm sorry for the inconvenience.

28 Jun 2008 3:11am GMT

[Rakudo spec regression status: 75 files, 1080 passing tests]

Rakudo Perl is now passing over 1000 tests in the official test suite!

http://www.pmichaud.com/perl6/rakudo-tests-2008-06-27.png

For those who are interested, the history of test results is available in CSV format from http://svn.perl.org/parrot/trunk/languages/perl6/docs/spectest-progress.csv .

Thanks to Jonathan, Moritz, Auzon, bacek, particle, Coke, chromatic, and everyone else who is helping to make this happen!

27 Jun 2008 5:19pm GMT