Planet Perl Six

Carl Masak: Week 10 of Web.pm -- Genshi, Grampa and some docs

Fri, 03 Jul 2009 21:19:10 +0000

Happy Cat sez, "I gots a plan. Momz wantz booze, she getz booze. Fill teh bukkitz with waterz." And teh doodz fillded dem full.

He sed to teh doodz, "Teyk som waters to teh party dood." Tehy didz it. Teh party dood was liek, "Tihs iz teh booze! I lieks tihs booze! Where didz tihs come?" (Teh doodz who broughted teh booze knowd.) Teh party dood wentz to teh pplz gettin hitchded and sed, "WTF!? Most doodz gives teh gud booze first, and tehn crappy booze when pplz iz too drunk to care. But tihs booze pwns!"

Happy Cat didded this, teh first of hiz signz, in Cana inz Galilee, and revealded hiz Pwnage; and Happy Cat's doodz beleved in him. — John 2:7-11

Today I've had some fairly good progress with Hitomi, the XML templater. Using the draft grammar moritz++ helped me build, I created a class that takes an XML document and translates it to a stream of events. This makes about half of the tests that I ported from Genshi last time pass; the other half of that test file concern tag soup input — I think I'll punt that one for now, and go for the lower hanging fruit: the classes Template and MarkupTemplate. With those, it should be possible to actually, you know, do some templating.

I'm getting more and more familiar with the original Python code, and starting to have some significant respect for the Genshi code base. It's simply a very well-thought-out piece of software. I can see why people like it. The project doesn't seem terribly active, unfortunately, so sometimes questions from me and others go unanswered on the #python-genshi IRC channel.

Is Hitomi a good name? jnthn++ pointed out today that it sounded very similar to "hit on me", and I find myself constantly writing either "Hitmo" or "Himoti". Then again, I kinda like that it means (or so I've read) "doubly beautiful", and I don't have a better suggestion at the moment.

Another thing that has been going on in the past week is that viklund++ said, almost in passing, that it'd be nice to have an XPath engine for Match objects. I thought it was a great idea, and incubated the project "Grampa" (short for "grammar paths") on github. I've since made some good progress on it, and it's already slightly useful. Not to mention that I've learned a few new things about XPath and EBNF that I didn't know before. pmichaud++ helped me with some questions on the latter.

How does that tie into Web.pm? Well, it turns out that at least two of the subprojects of Web.pm would benefit from XPath searches: Hitomi, and Happle (our Hpricot clone). This suggests that Grampa should really be a Match front-end to an XPath query back-end, so that the back-end can then be reused in other projects. I've been implementing Grampa with this in mind.

Finally, since it's nearing the end of my original part of the grant, I've taken a fresh look at doc/PLAN and refined it a little. No major course corrections were needed, which feels comforting. I'll probably write some more about the status of the subprojects in next week's blog post.

Another thing I plan to do in the coming week is start on my Web.pm talk for YAPC::EU. I thought I'd write the talk in Perl 6 Pod, and then do various conversions to end up with a PDF. Since most of the toolchain for doing that doesn't exist yet, I thought I'd better start now. 哈哈

I wish to thank The Perl Foundation for sponsoring the Web.pm effort.

chromatic: How to Count (Parrot Style)

Fri, 03 Jul 2009 09:11:54 +0000

Parrot releases are harder to count because of their prolific release cycle.

Brian Wisti, In Which Brian Whinges About The Perl 5 Release Schedule

This is a trivial nitpick (read the rest of the article! It's very good!), but Parrot releases are very, very easy to count. The same goes for Rakudo releases.

The other day someone asked what Parrot might look like in a hundred years. I laughed and thought, "What would its version number be?" Then I realized that I can predict its version number in 100 years. Parrot 101.6 will be out, with Parrot 101.7 on the way.

For all of the lofty talk about "stability" and "maturity" and "predictability" which results in Perl 5 not getting released, the fact that I can predict the release date and version number of a piece of software one hundred years in the future says something about the stability, maturity, predictability, and reliability of a very different kind of development process.

(Oh, and Alias -- I can crash several so-called stable releases of Perl 5 with a one-liner the same way you crashed Parrot in December 2008 with a short program. If you want to make the argument that the 30 stable monthly releases of Parrot in a row don't actually exist because they had bugs, the two so-called stable releases of Perl 5 from the same time period don't exist either. Ontological debates are easy to lose.)

Herbert Breunung: come to where real action is.

Fri, 03 Jul 2009 00:35:30 +0000

since my first post at this blog 2 weeks ago, Appendix A is now twice as long (454 entries). Today i completed regex modifier, aiming now toward control chars and escape sequences. But not only the numbers improved, also quality improved much. There are now also more pointer to similar terms, tags when commands kept same since p5, etc. But I still need your help. So please have a look at these wiki pages and edit them if you have the feeling you can improve them.

chromatic: Perl 6 Design Minutes for 27 May 2009

Thu, 02 Jul 2009 23:03:51 +0000

The Perl 6 design team met by phone on 27 May 2009. Larry, Allison, Patrick, Jerry, and chromatic attended.

Larry:

changed the time function to return a Rat
thinking about the traits that have been bothering Jonathan and others
have some changes to check into the spec when I'm happy with them
thinking about the primitives we use to define use
breaks down into load and import
thinking of establishing compile-time keywords for both concepts
intended so that I can import from anything acting like a module -- an inlined role, for example
otherwise trying to keep up with the flow of IRC

Allison:

working on the Parrot book
changed its focus to a small, 100-page PIR book from a monolithic Parrot book
the intent is to get something out for YAPC and OSCON
will send out a draft for review
will merge my changes into the repo later this week

Patrick:

released Rakudo #17 last week
was easy again
875 more tests since #16, so we pass 68% of the spectest suite
finished implementing the root_new opcode in Parrot
cleans up a lot of the PMCProxy issues from moving Rakudo to its own HLL
gained half of the speed we lost from the migration
we'll get more back as we update more places that need it
NQP never expected anything like that
I have to rework some it and PCT
haven't quite figured out how to do that
refactoring use and import in Rakudo
the current implementation doesn't work
will hopefully match with what Larry's putting in the spec
it seems like the logical way to do things
updated Rakudo's ROADMAP in docs/ROADMAP
gives us an idea of dependencies and next tasks
may also help people understand what blocks features they want

Jerry:

the bonding period has ended for GSoC
time for students to start coding
everyone on the Perl 6 and Parrot projects is ready

fixed some memory leaks in Parrot and Rakudo
there are still some in Rakudo, but the web examples should be able to live longer
did more profiling
think NFG is important for Parrot in the near term
have some documentation to write
have been editing the Parrot book

Patrick:

how's the command line for Rakudo coming?

Jerry:

I expect to get back to that

Patrick:

the "parens build captures" decision surprised me
what's the rationale?
I really liked "parens mean grouping"
maybe I haven't reconfigured my worldview yet, but it feels messy

Larry:

when used in an argument list, it has the same effect as a capture

Patrick:

it even works when they're used as a term

Larry:

they still mean that you have to look at what you're binding to and decide
am I binding this to a scalar or to an array?
(1, 2, 3) bound to an array...

Patrick:

I'm going to have to think about that
the zip operator in slice context....
is this three or one positional arguments? zip($a,$b,$c)
how many positional arguments are in this case? zip($a,$b,$c;$d)

Larry:

one slice
you wouldn't want to write that

Patrick:

what in the arg list distinguishes the use of the semicolon versus the comma
inside of an argument list we have to recognize a variety of syntactic things
comma, semicolon, colon, array or hash sigil, named parameters
seems like captures need more information than just positional
they need to store metadata about positional arguments
I like the syntactic stuff showing up in the argument list
but I don't want to handle them in three different ways

Larry:

I'll have to think about that

Patrick:

haven't figured out how to deal with slice context either

Larry:

might say that the presence of a semicolon implies the presence of other parens
the comma implies...
that might be more consistent binding for a top-level list

Patrick:

I half expected that answer
I can see the semicolon as just a lower precedence grouping operator

Larry:

otherwise you have a semicolon that's just not there in every other argument list

Patrick:

assuming that, the other commas form an argument list through the infix semicolon
an array in there means Capture of Capture of Capture
we were about to refactor List and Array in Rakudo anyway
the question is "Do we really have a List type now?"
Rakudo assumes that

Larry:

if we can unify args list with List, that's probably healthy

Patrick:

I'd really like that
that makes things a lot cleaner
infix comma and infix semis now just create arglists

Larry:

or Lists
if you define List as "something that has out of band metadata"

Patrick:

any more decisions that you can make about that will help our implementation
I probably won't get around to that this week

Larry:

we make syntactic distinctions
we know that this is an arg list
we treat pairs as named arguments
we don't do that if we know it's not an argument list
it stays positional
that's the only distinction between an arg list and a List
purely syntactic

Patrick:

to summarize
zip($a, $b, $c) has three positional arguments
zip($a, $b, $c; $d) has two, the first of which is itself a list/capture

Moritz Lenz (Perl 6): Strings and Buffers

Thu, 02 Jul 2009 16:08:13 +0000

Subtitled "The Zen of not messing up your strings".

Handling non-ASCII strings in Perl 5 is a real pain, because there are no real separate types for binary data and text strings. Mostly the operation provides a context of either binary or string processing, but function like length don't, so the answer is dependent on internal representations about wich the programmer should never care.

In the Perl 6 language design we decided not to repeat that mistake. Since Strings are objects like everything else, it's easy to invent new types. So in essence we have two types relevant for our discussion, Str and Buf.

Str

A Str is notionally a sequence of characters, or a text string. There's no character encoding attached to it, and while it is surely stored in a specific encoding scheme internally, it's nothing that programmer cares about.

A Str co-exists on two (at least) two levels, on codepoint and grapheme level. A codepoint is everything that the Unicode consortium has assigned a number and a name, like U+0065 LATIN SMALL LETTER E or U+0300 COMBINING GRAVE ACCENT. A grapheme is either a codepoint or a sequence of codepoints that are visually represented together, for example the two codepoints mentioned before would be printed as a single grapheme è.

The default level is grapheme, because that's closest to how humans usually think of characters and text. Specific operations can override the default abstraction level, or it can be adjusted by pragmas like use codes;.

Buf

Of course you can also handle binary data in Perl 6. Such data is stored in objects of type Buf. Notionally a Buf is a list of integers of a fixed size. It has subtypes for common sizes buf8 is a sequence of unsigned bytes, buf16 and buf32 store unsigned 16 and 23 bit integers.

When you communicate with anything outside of Perl 6, you'll need Buf objects for that, because files and terminals only understand byte streams, not character streams.

There are also a different kind of Bufs which enforce a specific encoding, for example utf8 can only hold byte sequences which can be interpreted as UTF-8. They are not strictly necessary, but provide a nice, convenient interface for some operations.

Conversion

Conversion between Str and Buf is called encoding, the other way round is called decoding. For example "møøse" is a Str, and "møøse".encode('Latin-1') returns a Buf, more specifically a buf8.

On the other hand if you read some bytes from a socket and want to treat the result as a text string, you decode it: my $str = $buf.decode('UTF-16LE').

Mixing a Str and Buf that doesn't know about its own encoding in an operation like concatenation or comparison throws an exception, because those are the conditions where most Perl 5 programs mess up strings beyond all repair.

IO

If you read the above, maybe you think that printing a Str to standard output is an error because the string doesn't know its encoding, so it can't represented as a byte stream. That's only half the truth; the output handle can also have knowledge about its own encoding.

When you open a file, you can either specify that it's opened as a binary file, or you specify an encoding. In the former case reading from the handle returns Bufs, in the latter Strs.

For the sake of convenience a pseudo encoding called Unicode exists. (Yes, we know that Unicode defines a character repertoire, not a character encoding). If there's a byte order mark (short BOM) at the start of the stream, it is used to determine the encoding. If not, a very simple autodetection is used: If the file is obviously UTF-16LE, UTF-16BE or UTF-32 (detectable by the position of the zero bytes when encoding ASCII characters) then the detected encoding is used, otherwise as a fallback UTF-8 is used. This autodetection scheme is the default.

Conclusions

We learned from the experience that cramming too many different semantics into a single data type is harmful. So now byte streams and text streams have different data types, and a clean interface for converting back and forth.

The specification is not set in stone so far, and no compiler implements the Buf type yet, but it is already planned for Rakudo.

Since this is an important topic to me I will continue to nag the implementors and language designers about it, and write tests to ensure a solid implementation.

Gabor Szabo: Why am I writing Padre?

Thu, 02 Jul 2009 09:24:31 +0000

It is probably not that interesting for most of the people but I have my excuses. What is more interesting - at least to me - is why others are involved.

After all there were already more than 40 people who made some contribution to Padre.

So I asked them to start writing down why are they involved. Some of them have already added themselves to the developers page and we started a separate page for translators though that one is new and has no been filled yet.

So why do I write Padre?

There is a short explanation on that page but let me bore you with a longer one here.

I have been teaching Perl 5 for almost 10 years now. Both beginner level and advanced courses. In the beginner courses the majority of the people use Windows with about 20-30 percent using Linux. Most of the Windows users use Notepad++ or a similar editor. Some of them can configure their editor to run the perl script right from the editor, others don't even know how to enable syntax highlighting for Perl 5. Some of the people on Windows don't know what the command line is but even those who know how to open the command prompt are either afraid of it or just dislike it.

Mind you these are not stupid people or anything like that. Some of them have many years of hardware design behind them. They are just used to some kind of IDEs.

Others might use Linux/Unix but many not by choice. In many cases the company they are working for gives them telnet access to an oldish Unix machine and tell them to code in Perl. They hardly know vi, they don't know how to configure syntax highlighting and they don't know how to install any other editor.

I have been using vim for many years and I can testify that it is a superb editor. Emacs is similary strong but I have not used it since university. The problem with both of them is that they are totally different from the editors most people are used to and their learning curve is long and steep. It takes several months or even years to become familiar with them. Most of the people don't want to invest that energy and I certainly don't have the time for that in a 4 days long Perl 5 course.

So I usually tell them to use whatever they are familiar with. I think I never had a student who picked Eclipse or Emacs. There were a few using vi/vim but most of the people used Notepad++ or a similar Windows based editor.

I don't think my students are too different from the average people learning and using Perl. Most of them will never write a full blown web application. Heck most of them won't have a need for object oriented coding as they write only 100-200 line long scripts in Perl.

They never get really familiar with Perl and they will always have to deal with strange code written by others. With all the other tasks they are required to do in their primary language or tool they will keep wondering what is $_ when they see it and will be surprised when they don't.

They will wonder what is the relationship between $_ and $_[0].

So my first objective was to provide a simple Notepad++ like editor with strong support for beginners or people with relatively little experience with Perl.

For example I'd like to make sure that Padre users will be able to highlight $_, press F1 and get an explanation. In case they highlight $_ from a $_[0] expression Padre should be clever enough to point this out and give an explanation on @_ and @_[0].

I knew it is a big task though I did not think it is soo big. In any case I knew I cannot handle this alone, especially as I am not such a good programmer. So from the very beginning I tried to make it interesting, accessible to experienced Perl 5 developers and in turn they made it fun and hackable.

Unfortunatelly most of the experienced Perl developers are also hard-core vim or emacs users and it is nearly impossible to move them away from their editor. Luckily there were a few who got interested by the idea of having a lot of control over their editor and that made the difference between a failing one man project to a project with a lot of potential.

Then at one point came the idea to integrate Parrot and Rakudo and try to provide a platform for Perl 6 development as well. With the awesome work of Ahmad M. Zawawi Padre has a lot to offer to anyone who wants to write Perl 6 code. With some more work we'll be able to integrate Parrot even better and then Padre will be able to handle any language running on top of Parrot.

While there are still lots of problems with Padre and installation can still be difficult it already more or less has the same power as Notepad++ on both Windows and Linux and probably on Mac too and it has some extra features that even vim people started to steal.

Patrick Michaud: Rakudo day: operators in setting and lots of RT bugfixes

Wed, 01 Jul 2009 04:08:20 +0000

At the beginning of June the Vienna.pm organization generously committed to funding me for 1-day-per-week of Rakudo effort, but because of the Rakudo release, Parrot Virtual Machine Workshop, YAPC::NA, and a short vacation, today is the first day that I had available to really dedicate to the task. In fact, to catch things up a bit I plan to do another Rakudo day tomorrow or Thursday.

Here's what I accomplished for today's Vienna.pm-funded Rakudo day.

The biggest task I tackled for the Rakudo day was to be able to write operators in the setting (Perl 6) instead of PIR (RT #66826). In fact, I had actually done most of this last week during the YAPC::NA hackathon day, but interruptions then and a few annoying Parrot bugs kept me from marking the task as completely accomplished then. What this means is that we can now begin defining operators directly in Perl 6 code (perhaps with some inlined PIR), which moritz++ has already been exercising for infix:<...>, infix:<eqv>, and a few other operators. Over the next few weeks I expect we'll move even more operators out of PIR and into the setting.

The rest of today's Rakudo day was spent reviewing and cleaning up the RT queue; it had grown to over 400 tickets but by the end of the day Jonathan and I have shrunk it back down to 387. I think we collectively closed about 16 tickets today, and I responded with requests for clarification or updates on several more. Here are some of the highlights:

RT #66060 noted a problem that the .uc method would fail on some strings where .lc worked. I tracked this down to a Parrot issue in its handling of Unicode strings when ICU wasn't present, and refactored the code to be a bit more robust there.

RT #66640 noted that the minmax operator wasn't implemented, so after some discussion about what it should do I added it to the setting (using the operator features mentioned above).

In RT #66624, the exception message coming back from not finding a substring within a string was particularly misleading; I adjusted .substr to provide a more useful error message.

For RT #66928 .WHAT would not work on some subs like &infix:<+>; this was because some of the builtin operators are still using Parrot's MultiSub PMC instead of the Perl6MultiSub PMC, and those didn't have a mapping to the type object. Eventually all of the operators will become Perl6MultiSub; in the meantime I set Parrot MultiSub PMCs to map to the Multi() type objects in the same manner that other Parrot PMC classes are mapped to Perl 6 types.

RT #66818 noted a problem with unwanted flattening of %*VM in a for statement; this was because the contents of %*VM were incorrectly bound to the Hash directly instead of going through a non-flattening reference (Perl6Scalar). Eventually I expect %*VM to be initialized in the setting, though, which will provide a more robust and direct solution to this problem.

In RT #66840 it was discovered that precedence errors in the ternary operator would cause Rakudo to issue an error message and exit completely, instead of throwing a catchable exception. I tracked this down to PGE's OPTable handling of the ternary operator, it was actually using "exit" when the error occurred (probably because it came from before Parrot's exception model was firmly in place). This was changed to throw an exception instead; the actual exception message needs a bit of work but I expect that will come from the much larger PGE refactoring that will be done as part of the Hague grant.

Lastly, today I spent a good bit of time discussing Rakudo and Parrot build/install issues with Allison, and I think we have basic agreement on the changes we'll be making in order to get those working. Hopefully we can get all of that done in time for the July release.

So, that's my first Vienna.pm Rakudo day -- lots of little pestering bug fixes, and a key bit of infrastructure to fully enable writing the builtin operators in Perl 6. Later this week I plan to do a long-needed refactor of container handling in Rakudo, and maybe to get a more complete implementation of BEGIN blocks (which we massively cheat on at the moment).

Thanks again to Vienna.pm for sponsoring this work.

Jonathan Worthington: Lots of little improvements

Tue, 30 Jun 2009 21:09:56 +0000

I'm back from a nice break in Italy and have been digging back in to Perl 6 stuff again. Today I've been doing a Vienna.pm-funded Rakudo day, and here's what I got up to.

First off, I went for a look through our RT queue. We now have over 400 tickets that are either new or open. While on the one hand that means we've a lot of work to do, it's also a sign that people, more and more, are playing with and exercising Rakudo. In just browsing through it, I found a bunch of things I could work on and hopefully resolve fairly easily during the day, and also another bunch of things that were already resolved. Just spotting the latter allowed me to mark 3 tickets resolved.

A couple of the things I worked on related to subtyping. Of note, the standard grammar accepted:

subset Foo of Int;

Without requiring a where clause. Rakudo now also accepts this, and our parsing is a little closer to STD.pm too (we parse traits on subtypes, but we don't do anything with them just yet). Next, I got Rakudo to support a neater syntax for declaring anonymous subtypes in signatures. If you just want to match a specific value, you can write the value in the signature, and that's it. For example, here is yet another way to do factorial (a recursive version).

multi factorial(0) { 1 } multi factorial(Int $n) { $n * factorial($n - 1) } say factorial(5); # 120

A signature :(0) is equivalent to :(Int $ where 0). This means that it will sort in the candidate list with Int. More generally, any literal value in where will get a nominal type based on the .WHAT of the value and have the value made into an anonymous subtype, so the signature :("tava") is just like :(Str $ where "tava"). I added some tests for all of this too.

Lyle++ had sent in a patch a while back for $*CWD and chdir. I took a look at these today. The $*CWD one looked pretty good, so I applied that with just a minor tweak. The chdir one needed some more attention and fixing up first, but I got that applied and extended the tests to better exercise it. Then I got both test files added to spectest.data. So now chdir and $*CWD are both functional. Here's some play with them in the REPL.

> my $fh = open("spectest.data", :r); Unable to open filehandle from path 'spectest.data' in Main (:1) > say $*CWD; C:\Consulting\parrot\trunk\languages\rakudo > chdir "t"; > say $*CWD; C:\Consulting\parrot\trunk\languages\rakudo\t > my $fh = open("spectest.data", :r); >

We had a couple of tickets relating to the interaction of //= and state variables. A little investigation, some discussion on #parrot and a fix later, I was able to unfudge tests and mark those resolved. A small inheritance bug was a similar story.

Finally, in preparation to improve type check failure error reporting and resolve at least one ticket in that area, I factored all type check error generation out to one routine, which we now call consistently. That means errors that previously missed out mentioning the expected and received types now do so, and the other issues I can fix - on some future Rakudo day - in one place, and everywhere that reports such errors will benefit.

In the course of the day, I also discovered a couple of other tickets that I had opened up to investigate at the start of the day were also already-fixed issues, so I made sure we had proper test coverage and got them closed up.

So, a pretty productive day. Thanks to Vienna.pm for funding!

Herbert Breunung: starting to crosslink

Mon, 29 Jun 2009 02:06:44 +0000

After fixing some markup jitter in the german version of perl6tutorial (which Su-Shee found), I added new sections in Appendix B: (sigils and regex metachar). Thanks to Larry I know now that "|" is not a sigil (of the capture context) because it reduces informations.

But the real reason I post here: Appendix A and B now get more connection. From the start I added to each term in the index the name of its syntax category. Now i started to turn these addon info into links, which point to the according table in Appendix B. Its no real crosslink yet because I don't links back into appendix A. Most probably I will link from there into the, yet to be translated chapter(tablet 3-9), where links Appendix A too. Different to FOSWiki i can set everywhere invisible anchors in the document. So maybe there will be maybe chrosslinking.

While struggling with the limits of the different wiki markups, im happy that november wiki targets the MediaWiki syntax which works well in most cases, even with operator and special char laden languages like perl. (FOSWiki and Socialtext does not very well, you can't even have italic text in links in socialtext)

Still the structure evolves, but since the tablets get more substance, I hear it more often that u4x, grok and other docs will have it easier to build content, because the have in parts just to reformat stuff from the tablets.

P.S. a postscriptum to my last post: a colon is also used when converting numbers to a different base and as jump label suffix. Always indicating a relation in different context.

Carl Masak: Reading up on MVC, part 1: Ruby on Rails

Fri, 26 Jun 2009 20:11:31 +0000

Hello, don't mind me. I'm just going through a few MVC frameworks to see how they differ and how they're alike. I need the knowhow to create an MVC for Web.pm. Right now, my plan is to examine Rails, Catalyst, Django and Jifty. I'll write down my impressions of each of the in some kind of list, for future reference. Basically the only way you'd want to read this is if you want to laugh at how little I know about MVC frameworks.

Here's the list I got from watching this screencast:

Man, the Ruby folks sure can make a beatuiful screencast!
Rails uses scaffolding. I've heard not all people like scaffolding, but it does look kinda convenient to my untrained eye.
Partial templates are called, logically, "partials". They bind smartly with variable names somehow.
Different output formats are really easy to add. XML, JSON, Atom...
A blog is a really nice example for an MVC framework screencast, because it's just a list of posts, each with a list of comments.
Rails can add authentication through before_filter.
Hm, clearly the strength of Rails comes largely through the keywords it introduces. Wonder if it uses monkey typing for that?
Rails has Routes! Maybe this is my chance to finally understand ihrd++'s Routes, which I never really grokked.
Controllers do things like index, show, new, update and delete. Probably related to CRUD somehow.
That 'debugger' trick is fantastic! One of those features which you feel can't be just hot air.
AJAX is fairly well integrated, though I'll be danged if I understand exactly how. Looks like magic to me.
Did I hear that right? "rjs is just a way to generate JavaScript using Ruby." Wow.
There's graceful fallback from JS to non-JS.
There's built-in automated testing.
The console seems like the debugger again, but without the breakpoint. Yes, I can see how that might be very useful.
Never once do they explicitly say 'the database' in the screencast. They say the word 'database-agnostic' once, and 'table' and 'column' a few times, but most of the time it's just 'model', 'view', 'controller'. Seems like the abstraction is largely intact.

Um. Well, in summary, that cool-aid sure seems to have an effect on me. I'll leave the comments open so that you people can tell me how Rails, despite all appearances, is really bad for your teeth and leaves skid marks on your puppy.

Next up: Catalyst.

Herbert Breunung: squeezing Regex Modifier in the Table

Fri, 26 Jun 2009 01:56:35 +0000

Yes its me again.

Please have a look at the newly made regex modifier table. The special variable list above is now also almost in its final shape.

But secondly and more important: the current state of the TPF-Wiki-frontpage looks lousy to me. I cleaned up some of the disorder in documentation related stuff, but before I do a major revamp, I would like to know your opinion. So please post me. My plan is to move a lot of the content from the front page to separate pages for each topic, and then link to them all from the front page. The TPF-Wiki is and should be for us - the Perl folks, a brewing pot for ideas. The easy and sane guide through the Perl 6-world we do in the November-Wiki. Nevertheless it should look good. Please reply to this use.perl post. Thank you very much.

Herbert Breunung: Natural Elegance

Wed, 24 Jun 2009 23:26:24 +0000

I like the elegance, consistency and similarity with natural language of Perl 6. E.g. the colon, with which we express a relation. Cups in the basket: 5.

And indeed a pair as a data type, which describes a simple relation, you declare in Perl 6 :key(value). Also hashes (which are build with pairs), named parameters in signatures (which too descibe a relation between a name(ID) and a value) autogenerated named parameter (have colon as twigil) use the colon. And not only the reuse of pairs everywhere as quote or regex adverbs or filetest operators, also in macro defenitions, if you specify what you like to create with this macro (because unlike LISP there is more than lists and brackets), you write macro category: { ... }. Again colons are used almost like in text. and you have it again when you use objects with a special syntax that doesnt look in that way. feed $author: 'cake and herbal tee'; is nothing else then $author.feed('cake and herbal tee'); All that you can understand intuitively and behind all that are very very few rules. So yes Perl 6 is complex, but only where we adress complexity of life. And to be practical was always the goal of Perl.

thanks jesse++ for adding me.

Moritz Lenz (Perl 6): Trying to implement new operators - failed

Mon, 22 Jun 2009 05:33:09 +0000

This isn't a success story - it's only almost a success story.

On perlmonks.org we had a Golf challenge (ie writing code in as little characters as possible): write an implementation of the Euclidian algorithm in Perl 6.

I proposed a solution which I liked very much, but which didn't work in Rakudo yet, because it used the series operator infix:<...> (yes, three literal dots) which isn't yet implemented in Rakudo. D'oh!.

I like Perl 6 discussions on Perlmonks, but every solution that shows a NYI-feature encourages the "Perl 6 is vapor-ware" thoughts and comments. So I decided to make it work, and decided to JFDI and implement the missing operator.

In general implementing a new operator in Rakudo is not much harder than implementing a function: all you have to do more is to add it to src/parser/grammar-oper.pg including precedence and associativity (both of which can be found in the spec.

For quite a while now built-in functions and methods can be written in Perl 6 now, so I also decided to write the new operator in Perl 6. Since lazy lists aren't implemented yet, I decided not to care about the lazy version, and did the eager version instead. This is what my code looked like:

multi sub infix:<...> (@lhs, Code $generator) {
    my $c = $generator.count;
    if $c > @lhs {
        fail 'the closure wants more parameters than given on the LHS';
    }
    my @result = @lhs;
    my @r;
    # XXX work around http://rt.perl.org/rt3/Ticket/Display.html?id=66824
    # this is a bit ugly.. since @a[1..1] returns a single item and not 
    # an array, |@result[$one-item-range] throws the error
    # "argument doesn't array"
    while @r = $generator(|@(@result[*-$c..*-1])) {
        @result.push: @r;
    }
    return @result;
}

This works... partly. It works only in the file it is defined in, not if it's defined in the setting library.

So to summarize: I have an implementation ready, but due to Rakudo bugs it can't go into mainstream Rakudo right now. JFDI, partly failed.

Carl Masak: Asking #perl about Modern Perl

Sun, 21 Jun 2009 15:38:28 +0000

This is my first Perl 5 post ever. 哈哈

<masak> while I'm here, I'd like to talk about Modern Perl. <masak> in y'all's opinion, what are the modules a Modern Perl 5 user should be aware of? <masak> I'm thinking of things like Moose, List::Util, maybe Catalyst... <claes> it all depends on what the task is <lucs> masak: 5.10 in general maybe <claes> using warnings, strict and perhaps indirect pragmas <masak> I think things that we take for granted as good time-savers all qualify. <masak> so maybe stuff like Getopt::Long too. <claes> personaly I don't use Moose because I haven't had any use for it yet <masak> for me as a Perl 6 user, it's not that difficult to see the use for Moose. <masak> I saw a blog post recently that said that Moose even helped the blogger document things more succinctly. <masak> that is, even when he wasn't using Moose, he was using habits gained from it to write better documentation. <Hinrik> Perl::Critic, definitely <claes> Devel::NYTProf <Hinrik> some of the eventy things (AnyEvent, Coro, POE) too, if that's what your app requires <Hinrik> and the various Test::* modules, of course <masak> Hinrik: which ones, more exactly? <Hinrik> Test::More usually works for me, along with some other specialized ones depending on the typo of app <Hinrik> e.g. Test::Script to test if scripts compile <Hinrik> masak: oh, and Devel::Cover is also quite helpful in determining test coverage <cfedde> see also Modern::Perl <cfedde> I think that the standard template will become 'use Modern::Perl; use Moose'

Feel the need to add something to the list? The comments are open.

Herbert Breunung: p6tut complete, November rising

Sat, 20 Jun 2009 22:56:34 +0000

As I finalized the proofreading for the 8th part, my german Perl 6 Turorial is now complete, online and next month also printed.

In november we completed the first 2 chunks (FAQ and Implementations) of content and i filed several bugs and issues (TPF P6 wiki is in parts beyond repair). Looks we can make i reallly usable wiki out of it. Masak and Viklund worked hard to fix the newlina at the end-bug, the UTF-bug, made a preview and cancel button work and some other stuff. but my filed wishlist is long, internal links with different label, flags with spaces in it as in Perl 6, table of content, means to make unformated and indended text and so on.

The Perl Tablets are also improved dayly, more than 60 new items in both languages in Appendix A but that you hardly notice if you don't see history. But now p6tut is complete we translate more text chapters.

Daniel Carrera: Embedding Parrot in Perl 6

Sat, 20 Jun 2009 00:50:08 +0000

One of the interesting things about Rakudo is that you can embed Parrot assembly code (PIR to be exact) into Perl 6 code. With this you can optimize critical parts of the code and you can expose additional Parrot features to Perl 6. Let’s start with a hello-world example:

Q:PIR {
	say "Hello world"
};

Though it is not obvious right now, the stuff inside the Q:PIR { ... }; is parrot code.

Parameters

Of course, embedded Parrot code would be pretty useless if you couldn’t send parameters in and get results out. Here is a simple Parrot routine that takes two parameters, adds then and returns the result:

sub ($a,$a) = (3,4);
sub $result = Q:PIR {
	# Input.
	$P0 = find_lex '$a'
	$P1 = find_lex '$b'

	# Compute the sum.
	$I0 = $P0
	$I1 = $P1
	$I2 = $I0 + $I1

	# Return it.
	%r = box $I2
};
say $result;

Yes, that’s quite verbose. PIR is not much higher level than an assembly language. The $P0, $P1, … are Parrot registers. The $P* registers hold Parrot objects, and the $I* registers hold integers. A more interesting example would be a factorial function:

sub factorial(Int $n where {$n >= 0}) {
	return 1 if $n == 0;
	return Q:PIR {
		# Define variables.
		.local int ans, n

		# Input.
		$P0 = find_lex '$n'
		n = $P0

		# Compute the answer.
		ans = 1
		LOOP:
			ans *= n
			n -= 1
			if n > 1 goto LOOP

		# Return it.
		%r = box ans
	};
}
say "5! = " ~ factorial(5);

Exposing Parrot libraries to Perl

A specially neat feature of embedded Parrot is that you can expose Parrot libraries to Perl. For example, Parrot comes with support for the MD5 digest function, which itself comes from the OpenSSL library:

sub md5(Str $text) {
	my $binary = Q:PIR {
		.local string text
		.local pmc digest

		# Input.
		$P0 = find_lex '$text'
		text = $P0

		# Load digest library.
		$P1 = loadlib 'digest_group'
		digest = new 'MD5'

		# Calculate the digest.
		digest.'Init'()
		digest.'Update'(text)
		$S0 = digest.'Final'()

		%r = box $S0
	};
	# Convert to hex.
	return join '', map {sprintf '%02x', (ord $^a)}, $binary.comb;
}
say md5("The quick brown fox jumps over the lazy dog");

The resulting library is of course much simpler and runs much faster than anything we could code in pure Perl. And this will run wherever Rakudo is available, without the need for a separate compilation step.

Carl Masak: 3D, baby!

Fri, 19 Jun 2009 21:20:13 +0000

Last night I had one of those rapid prototyping sprints where everything goes just right. I wanted to scout the terrain for drawing a 3D Druid board using SVG.

The result is this. Yup, Perl 6 did that, with a little help from me.

It was very pleasing to see this image grow step by step. I literally started with a grey rectangle. Then I programmatically massaged the coordinates, adding projections, translations, scalings and rotations until I had what I wanted. Here's the code.

I still feel two things are missing.

Real perspective. Because I currently project the 3D coordinates flatly onto the canvas, the result is isometric perspective. For some reason I don't like that — to me, the furthermost corner looks like it's sloping upwards from the plane of the board. I think I'd be happy with this kind of perspective, so I'll try that next. I was offline today, and had a couple of minutes to sit down and do the (really simple) math. I'm glad to see Wikipedia agrees with what I got. 哈哈 [Update: Fixed, see comment.]
Non-cheating with the piece order. I cheat right now in the sense that I placed the pieces in an order which looks good when drawn. The moves in a real game will not abide by such a restriction. I've already realized that I can draw all the horizontal surfaces in a separate pass, and don't need to sort those. I keep wondering whether I need to sort all the vertical surfaces separately, or whether it's enough to sort the pieces. Also, I'm thinking there might be nice, fast ways to determine that a surface will be completely covered by other surfaces, and can be thrown away. (Apart from the very simple case with the three surfaces on the back of each piece. I know about that one already.) [Update: Fixed, see comment.]

Anyway, I've been wanting to do this for a long time, and I'm glad that when I finally sat down to do it, not only was the result quite satisfactory, but also the process of getting there. It's 2009, and I'm using Perl 6 to rapid-prototype 3D board games. Cool!

Patrick Michaud: Rakudo Perl 6 development release #18 ("Pittsburgh")

Fri, 19 Jun 2009 05:17:59 +0000

On behalf of the Rakudo development team, I'm pleased to announce the June 2009 development release of Rakudo Perl #18 "Pittsburgh". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine. The tarball for the June 2009 release is available from http://github.com/rakudo/rakudo/downloads .

Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo .

Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. This release is named "Pittsburgh", which is the host for YAPC|10 (YAPC::NA 2009) and the Parrot Virtual Machine Workshop. Pittsburgh.pm has also sponsored hackathons for Rakudo Perl as part of the 2008 Pittsburgh Perl Workshop.

In this release of Rakudo Perl, we've focused our efforts on refactoring many of Rakudo's internals; these refactors improve performance, bring us closer to the Perl 6 specification, operate more cleanly with Parrot, and provide a stronger foundation for features to be implemented in the near future. Some of the specific major changes and improvements in this release include:

Rakudo is now passing 11,536 spectests, an increase of 194 passing tests since the May 2009 release. With this release Rakudo is now passing 68% of the available spectest suite.
Method dispatch has been substantially refactored; the new dispatcher is significantly faster and follows the Perl 6 specification more closely.
Object initialization via the BUILD and CREATE (sub)methods is substantially improved.
All return values are now type checked (previously only explicit 'return' statements would perform type checking).
String handling is significantly improved: fewer Unicode-related bugs exist, and parsing speed is greatly improved for some programs containing characters in the Latin-1 set.
The IO .lines and .get methods now follow the specification more closely.
User-defined operators now also receive some of their associated meta variants.
The 'is export' trait has been improved; more builtin functions and methods can be written in Perl 6 instead of PIR.
Many Parrot changes have improved performance and reduced overall memory leaks (although there's still much more improvement needed).

The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compiler@perl.org mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#19) is scheduled for July 23, 2009. A list of the other planned release dates and codenames for 2009 is available in the "docs/release_guide.pod" file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month.

Have fun!

References:
[1] Parrot, http://parrot.org/
[2] YAPC|10 http://yapc10.org/yn2009/
[3] Parrot Virtual Machine Workshop, http://yapc10.org/yn2009/talk/2045
[4] Pittsburgh Perl Workshop, http://pghpw.org/ppw2008/

Herbert Breunung: Pandemonium

Fri, 19 Jun 2009 00:17:07 +0000

The Perl tablets are a beast. I spend hours without much visible progress. Just details here and there, translating fore and back, understanding Perl 6, hacking around weak wiki syntax that don't get well along with a programming languages that uses all characters available.

Maybe the single achievement is to have alle the quoting ops right in appendix A and B.

Moritz Lenz (Perl 6): The first Perl 6 module on CPAN

Thu, 18 Jun 2009 06:46:38 +0000

About a month ago we had a discussion about distributing Perl 6 modules, again. This time I also looked at cpan6.org and mailed Mark Overmeer about his progress and visions.

The discussion moved to the perl6-language mailing list, and I went to vacations. When I came back roughly three weeks later, there were nearly hundred messages on that subject in five different threads, and so far I didn't feel like reading it all. (Additionally my mail server went down during that time, so I didn't even have them in my mailbox).

So instead of discussing things, I started to do something: I added meta data files to my Perl 6 JSON parser and uploaded it to CPAN. I think that's the first Perl 6 module on CPAN, discounting some modules included in distributions like pugs and v6.pm.

Since the documentation is in Perl 6 Pod, search.cpan.org doesn't display it properly. So my next steps will be to find out whom I can prod to implement Perl 6 Pod rendering and indexing, or if I have to do that myself (and if yes, on which code base).

In parallel I'll try to get the proto hackers to install from tarballs, or write that myself too. In the end I'd want Perl 5 and Perl 6 modules to coexist on CPAN, presumably with the option to select packages implemented in either language for searching.

chromatic: Perl 6 Design Minutes for 20 May 2009

Thu, 18 Jun 2009 02:08:58 +0000

The Perl 6 design team met by phone on 20 May 2009. Larry, Allison, Patrick, Jerry, Nicholas, and chromatic attended.

Larry:

trying to delegate some of my spec writing
if someone has something that needs to change and that person understands the design principles, someone can go ahead
Moritz respecced each to make it a conjectural junction
other people are working on the NFG specification
I haven't seen any changes committed on that yet
thinking about how importation works
particularly with inlined modules
expect that there will be an import declarator implied by use but usable explicitly
if you say import with an inline module or role declaration, it'll perform the export
which won't happen by default
thinking about how that declaration works at the moment
instead of trait_auxiliary and trait_verb, which fill the same syntactic category, we have trait_mod
they all occur in the same spot
you're always looking for them both simultaneously
the hander routines are now all upperclass autocalled, like other handlers
IS or TRAIT_IS or APPLY_IS, or some such
still thinking about namespaces for typeless traits not based on classes
perhaps rw or readonly traits aren't types
they need to be in a namespace somewhere
maybe just a syntactic category
added the use of ampersand variables on method calls to STD, .&foo
you can already say $.foo, call a code reference as if it were a method
& is also a code reference; ought to be allowed there too
Jonathan was playing with ampersand attributes, .&!foo
the rudimentary POD parser now complains if you don't have a matching =end for your =begin, except in the case of =begin END
if you put a default onto a named parameter, parser assumed it to be a positional parameter
gave a bogus error message
I fixed that
another interesting grammar tweak
defining an infix:<< >> and then a signature
if you leave a space out between the name and the signature parentheses, it would misparse
French angles ambiguously hyper parentheses there
I didn't want to require the space there
it's nice that you can write the declaration as if it a were call with the parens
if you're going to hyperoperate on parentheses, you have to use the dot form
>>( is now specifically not a hyperoperator within interpolation
>>.( is
that seems to be pretty DWIMmy
everything else is cage cleaning and hanging out

Patrick:

did not write any posts
will fix that first
mostly worked with others to make these happen
Tene and I ported Rakudo to run in its own HLL namespace instead of Parrot's
caused a 40-50% slowdown in execution time
we know the cause and have a fix before tomorrow's Rakudo release
I'll compare Rakudo's speed to before the switch
want to credit chromatic for any performance optimizations

I have a 6.5% improvement for all function calls

Patrick:

we have better error reporting now
can point to the point in your code with the error, rather than some point in generated PIR code
added the ability to define custom operators in Rakudo
infix, prefix, postfix
in select cases also circumfix
we can move even more parts of the builtins to Perl 6 as a Setting
exposed a few other places we need cleanup
Jonathan is working on those
added a variable to PCT which gives the compiler the names of the files it's compiling
improved error reporting there
added an inline PIR construct to NQP to match Rakudo's
added the qx// quoting term
can now run shell commands and capture the output into a variable
answering questions online and taking care of other little things
preparing for tomorrow's release
though it may occur very late tonight

Allison:

mainly release prep this week
lots of ticket review and patch application
submitted an article to Linux Magazine, "Why Parrot is Important"
more high-level than a tutorial
continuing to work on the book
a good week for high-level design discussions
seems like that happens when I have more time to be on IRC

Nicholas:

an update on smart-match
Paul Fenwick gave the position of a Perl trainer
the design decision of not being able to overload the left side of the smart match bothered him
there's more discussion there

optimizing Parrot and Rakudo
finding bottlenecks
fixing many of them
editing the Parrot book
doing a little more design work on nanoparrot

Nicholas:

how far off are you from letting other people release Rakudo?

Patrick:

the instructions are in the repository
they're straightforward
I could turn it over to Jonathan or Jerry or any number of people with ease
they could just do it
it's basically a Makefile target
you do some prep work, run the target, then upload the tarball to the right places
I stole liberally from how Parrot does things
I can hand it off any time I get tired of making them

Nicholas:

so the bus number is low

Jerry:

any plans to turn it over soon?

Patrick:

if other folks think it's important, I can do that
I could pick someone at YAPC::NA to do it
the release day is the Hackathon day there
we could just walk a few people through it that day
even if they don't upload the tarball and push the tag
we'll target that for the June release, even if no one else releases an official release

Jerry:

I've been trying to get the Parrot release bus number above 10
we're close, which is a great place to be

Patrick:

that was evident, as yesterday's release manager couldn't make it, and Mark Glines picked it up

Jerry:

and it was his first release

Herbert Breunung: overview over perl 6 documentation

Thu, 18 Jun 2009 00:03:41 +0000

I reformated and enriched a bit this overview, please let me know if anything is missing there.

Gabor Szabo: Perl 5 to Perl 6 - Arrays

Wed, 17 Jun 2009 11:50:25 +0000

Abstract

Continuing the Perl 6 Tricks and Treats newsletter to help people switch from Perl 5 to Perl 6. Looking at arrays.

For the full article visit Perl 5 to Perl 6 - Arrays

Carl Masak: Week 9 of Web.pm -- encodings, and a deep dive into Genshi

Wed, 17 Jun 2009 11:50:15 +0000

Den all IRS d00dz an bad kittehs coem to hear Jebus. An Fariseez sez "LOL Jebus etz wit bad kittehs! Him sux!'

Jebus sez, "WTF? If lolcat had hundrd sheeps an won gits losted, doan him leev naintee nain sheeps an go luk fr losted won? Den him find it an iz liek 'w00t!' An dem him coem hoem, trow partee cuz him finded losted sheep. Srsly! Ceiling Cat moar happi wen a bad kitteh being maed lolcat den bowt naintee nain gud kittehs." — Luke 15:1-7

I'm working mostly on Hitomi, a Perl 6 port of the Python templating engine Genshi. In the past week, I decided to dive into Genshi, looking at how data flows from the template to the finished result. I now have a pretty good understanding of this, so I thought I'd expand a bit on it here.

Genshi's fundamental data structure is called Stream, and it looks very much like a sequence of SAX events to me: open-tag, close-tag, text, processing-instruction, etc. Different transformations are then applied to a stream to yield the final result. A transformation could be something like "remove all <script> elements" or "shorten all posts that are longer than 400 characters". A stream modified in-place, but combine with a transformation to produce a new stream. The nice thing is that the actual templating is also expressed as a series of this kind of transformations. But the Genshi user can easily provide her own transformation on top of the standard ones.

I like this model very much. It feels extremely clean and extensible. I decided to port as much as I can to Hitomi. My short-term goal is to make things round-trip using the streams, and to that effect, I've ported a test file with 89 tests from Genshi to Perl 6.

It's still not totally clear to me how text is converted to a stream and then back. I can easily picture how a stream event knows how to serialize itself back into text, so the mystery on that side isn't very great; it's just that I haven't found the actual Python code for it yet. On the stream generation side, the data flow disappears into a Python-Expat library. Delegating XML parsing to a third party also seems like an exceedingly good idea to me.

Can we do the same thing — delegate to Expat, or some other suitable library — in Hitomi? I think so, and the Parrot documentation seems hopeful. I'd very much like to get that working. But in the short run, I'm pondering whether it might not be easier to make a small, throwaway XML parser out of the bits and pieces we developed as prototypes. I could make it a separate class and call it Impostor, to make sure we remember to remove it later.

Another issue I ran into is one of encoding. viklund++ has been doing heroic work in the past week making November handle UTF-8 correctly. The reason this is heroic is that Rakudo doesn't have a model for string encodings yet. The information has to be forced out of Rakudo against its will, and I've heard viklund mutter darkly about hacks and workarounds lately... It all culminated in a good discussion on #perl6 last night, and pmichaud++ promised to make a preliminary implementation of .encode (for Str) and .decode (for Buf), if we just sat down and wrote some tests to show what we expected these to do.

Looking forward a bit; I think there's a good chance we'll have something usable with Hitomi before my original grant period is over. After that, it might be a good idea to start looking at the port of Ruby's Hpricot (for manipulating and searching HTML documents), and to start digging into the MVC quagmire. I still expect to do some preliminary MVC investigations before that, though.

I wish to thank The Perl Foundation for sponsoring the Web.pm effort.

Carl Masak: No update today

Tue, 16 Jun 2009 22:43:56 +0000

Just writing in to say that I'm too tired to blog today about the progress today, due to all the progress today.

Tomorrow I'll put together a summary of the last "week" of Web.pm. Who knows, I might even be coherent by then.

In the meantime, for those of you who bothered to read all three paragraphs of a post called "No update today", here's what I currently have as my desktop background. I just can't stop analyzing that picture, it's mesmerizing.

chromatic: Perl 6 Design Minutes for 13 May 2009

Tue, 16 Jun 2009 20:14:44 +0000

The Perl 6 design team met by phone on 13 May 2009. Larry, Allison, Patrick, Jerry, Will, Nicholas, and chromatic attended.

Larry:

continuing to think about how braided languages work
implementing the notion in the STD parser
the notion of how you switch between these languages
now called slangs
thinking about how macros work in embedded lexical scopes
if you define a role which contains a trait auxiliary definition
label it is export
how does it export?
to which lexical scope?
when you do the role or what?
no defined way of exporting to outer
that's a problem in some tests
with augment slang, we have a way of embedding grammar modifications inline
when do ordinary macros embedded in subscopes desugar to that sort of thing?
%*LANG now holds the whole language braid
the $*PARSER variable is just the MAIN element of that
I backed off some of the errors in the STD parser to just warnings
don't really handle module and role long names yet
you get bogus "can't augment" warnings now
it thinks something isn't there that should be there and vice versa
fixed a test where STD needs to parse =for; now it does
added the slang declarator so that we could augment them
a twigil indicates a current slang subset of the current braid
fixed a bug to recognize the invocant marker after an unspace
that was a longest-token match problem
the message I added about a missing block gobbled by a function is now two separate messages
one talks about the function which needs parens
the other talks about the missing block
they point to two different areas as a matter of clarity
I'm really enjoying adding clever error messages

Patrick:

Rakudo now passes 11,200+ tests
up by 70 tests since yesterday
a couple of hundred in the past week
mostly doing little bug fixes and refactors
typically, I'll start to add a feature and find some code which doesn't look right
then I add the feature
slurpy arrays and hashes weren't added properly to subs
always added automatically regardless of the type of Block
I cleaned that up
also cleaned up lots of parameter handling in the code
that made actions.pm 100 lines shorter, and I removed three duplicate subroutines

that also speeds up startup

Patrick:

every time we do that it helps
found a bug dealing with Unicode characters in grammars
prevented us from properly parsing French quotes as an angle delimiter
working on adding operator parsing to Rakudo today
define your own custom operators
refer to them using canonical names
expect to have that done today
they won't be lexically scoped
I'll work on fixing that, when we get more to lexical scopes and language braids
continuing to consider protoregexes and LTM in PGE
probably will implement contextual variables in NQP and Rakudo

Allison:

we'll have packages in Ubuntu soon
just a straight sync of the Debian packages
no reason to make Ubuntu-specific packages, if that works
working on editing the book
working on the calling conventions branch
writing a Parrot article

Jerry:

GSoC mentors and students seem to be bonding in their bonding period
set up parrot.org to accept donations from individuals
there's a sidebar link under the Foundation heading
and we received our first donation!
thank you, Bradley Kuhn
we'll work on placement and prominence
think I'll give a keynote at YAPC::NA, following Larry

Larry:

if you pay me enough, I'll run over

Patrick:

if you don't pay him, I suspect he'll run over
you are what stands between everybody and lunch

Will:

added some regression tests
made some stuff work in Perl 5.8.8, so we don't have to upgrade our dependency
wrote a script to summarize our old branches
convinced people to delete a bunch of old branches
hopefully we can weed them out
TPF's grant committee votes this week on the current crop of proposals
one of them is for Perl 6
if you have any comments, please post on that
Partcl is still dead
blocking on the ability to build a language from an installed Parrot
we've made some progress on that
there are still things that do not work
most of them have tickets

Patrick:

Rakudo's blocking on the same thing
Tene is working on getting Rakudo to run in its own HLL
he's blocking on the HLL load_library problem
I'll have him post to the list and give an update on the ticket

Nicholas:

Rafael has merged his smart-match branch back into blead
he tried to make smart-matches match ranges
it won't work for various reasons
precedence is the wrong way around for one
$foo ~~ [ 1, 2, [ 3 .. 5 ] ] won't work either
Perl 5 ranges aren't lazy
smart-match can't interrogate Range objects lazily
that's why we can't emulate everything from Perl 6
we don't have the low-level infrastructure to do it all
even if we had that infrastructure, there are parsing issues
I don't see that coming in a hurry
if someone implements lazy ranges, maybe someone can add them to smart-match
giving the enjoyment people derive from implementing such things, I'll be surprised if anyone does that

added some optimizations
heading toward the "not really worth doing" kind
fixed some bugs
including a Unicode parsing bug with named parameters and arguments in IMCC

Nicholas:

did you write about the abolition of unary equals, Patrick?

Patrick:

not yet
I feel badly about that
I need to catch up
there are so many interesting problems to work on
writing is not as interesting as working on code

Gabor Szabo: Perl 5 to Perl 6 - Scalars

Tue, 16 Jun 2009 18:04:56 +0000

Abstract

The first entry of the Perl 6 Tricks and Treats newsletter in our quest to switch from Perl 5 to Perl 6. Looking at the scalars.

For the full article visit Perl 5 to Perl 6 - Scalars

perl6.announce: Parrot 1.3.0 "Andean Swift" released by Andrew Whitworth

Tue, 16 Jun 2009 15:25:54 +0000

On behalf of the Parrot team, I'm proud to announce Parrot 1.3.0
"Andean Swift." Parrot (http://parrot.org/) is a virtual machine aimed
at running all dynamic languages.

Parrot 1.3.0 is available on Parrot's FTP site, or follow the
download instructions at http://parrot.org/download. 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 1.3.0 News:
- Core
+ Optimized parts of the IO system
+ Fixed inheritance hierarchy of FileHandle and Socket PMC types
+ Fixed leaks involving subroutines and Parrot_Context
+ Cleaned up and refactored GC internals, including fixes and optimizations
+ Optimized PMC class manipulations to use type numbers instead of
string names
+ Fixed problems involving hashval calculations in strings
+ Removed unnecessary MULTI dispatches in built-in PMCs
+ Fixed memory leaks involving PMCs that were not properly destroyed
+ Fixed creation of PMCProxy PMCs in correct namespaces
+ Added preliminary Pipe support
+ Fixed cloning of Object PMCs
+ Added root_new opcode
+ Added initial versions of Packfile PMCs with read/write capabilities
- Compilers
+ Fixed several memory leaks in IMCC
+ Updated PCT to use root_new opcode
+ Added support for keyword "self" in NQP
- Documentation
+ Improved and expanded /docs/book
+ Updated project documentation
+ Defined 'experimental' status and procedures in DEPRECATED.pod
- Miscellaneous
+ Cleaned code and improved code-level documentation
+ Various bugfixes, code cleanups, and coding standard fixes
+ Added an experimental compiler library to help use PIR libraries from HLLs
+ Updated OpenGL library and examples to support experimental HLL import

Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 21 July 2009.

Enjoy!

--Andrew Whitworth

Herbert Breunung: hello world

Tue, 16 Jun 2009 09:53:09 +0000

Hello, this my (sir_lichtkind) second account here to separate the perl 6 related things a bit. Ans since i maintain the module Perl6::Doc this name fits somehow. So may I could be please added to planet perl 6. So what did happen so newsworthy.

Firstly mberends++ and I translated all 5 perl tablet appendices. Especially Appendix B, a sort of perl 6 cheat sheet, becomes valuable since, these tables are scattered around many synopses and the synopses now contain the tests, which is good for implementers, and lang brains but not for newcomer. so lets get ready the Perl tablets soon, even without TPF funding.

The second thing are my perl 6 tutorial i wrote in last 2 years for $foo. It is now online (in german), but i started also this to translate, help always welcome.

All good things are three. I became november user and started to add content to make some sort of newbefriendly intro into perl 6 worl and projects. Its very early but promising and i found some bugs and quirks, filed feate wishes, so november is now almost usable.

So now you may ask why try to do all at once. No there is much more i currently do in life but honestly all these projects benefit from each other and they simply need to be done.

chromatic: Perl 6 Design Minutes for 06 May 2009

Tue, 16 Jun 2009 01:38:38 +0000

The Perl 6 design team met by phone on 06 May 2009. Larry, Allison, Patrick, Nicholas, and chromatic attended.

Larry:

refactored my phone
refactored various functions
comb now defaults to matching single characters
a words method now does what comb used to do
did some work on pick
looked at most of the functions in containers to see whether they out to return a List or a Capture which returns an Item
depends on whether the function would ever be used to pull a single thing out
whether people expected it to do the right thing as an Item
pick is one of those functions
worked on the semantics of has
the initializer semantics; the syntax hasn't changed
worked on the relationship between multiple has if you have multiple attributes
straightened out a mismatch between prefix parsing specification and implementation
turned the term "protoobject" into "type object"
thinking about the notion of braided languages
Perl isn't a single language
also a regexp language, a quoting language, a quasi-quoting language
they hand off to each other
they have to keep track of each other; I call that a "braid"
how you override one language in another
how do you handle regexp language changes from regular Perl, when you're not in the regexp language at the time?
thinking about how to get the derivations to work correctly
when you parse a regexp or a quote
now instead of starting at a language like q, it starts at the current q-ish language in your braid
in support of that, I implemented temporization of context variables in gimme5
used to temporize current braids to a lexical scope
added a block after try in parsing
it uses that rather than parsing the block as the first argument of a list operator
likewise the other statement prefix operators
added the auxiliary hides trait
the \c notation for characters allows any radix of integer inside the list
the \c, \o, and \x notations all parse consistently now
enums are parsed more correctly
they don't give bogus duplicate warnings
if you declare a lexical symbol with :: in it, assumes you're referring to a subpackage of the current lexical scope
means something different from a symbol intended to scan outward
along with the notion of braided languages and derivability, derived languages can add more parser variables ($?foo) with a virtual function for lookup
avoids clobbering the core definitions
worked on role parameters
they're now in the role's pad, like normal signature parameters
started playing with the YOU_ARE_HERE stub used to define the effective insertion location of your code into a Setting
determining which lexical pad to dump as the Setting's context for use by other compilation units
did a lot of work on error messsages
some of my ||s suppressed panic messages
more useful error message on the null pattern (//)
gives a better message if you slurp your control block in the preceding expression

Patrick:

had a lot of discussions online
not as much coding as I like
seem to be answering questions for others
quite a bit of work on Rakudo internals refactoring
that'll make it easier to switch it over to be its own HLL in Parrot
moved things around
made a single constant definition we can change when we move it over to its own HLL
also moved all of the Parrot HLL mangling into its own source code files
easy for us to manage there
fixed some bugs
talked with Jonathan about refactoring the P6object implementation
used in Rakudo and PCT for Perl 6 object-like behaviors
he's working on that refactoring now
found and fixed a couple of bugs handling implicit slurpy positionals
made Rakudo's standard IO handles default to UTF-8 encoding
gives people behavior more like they expect
working on changes to the Array and List implementation
currently List inherits from ResizablePMCArray
we'll change that to contain it
that should clean up a lot of behavior
Rakudo passed the 11,000 spectest mark as of two days ago

Allison:

spent some time on ticket, milestone, and roadmap maintenance
helping other people start or continue their tasks
launched the install PDD out of draft
it doesn't address every question, but I cleaned out all of the inaccuracies
fits our current plan
probably needs more expansion when we figure out the source of some of our problems building Rakudo and Partcl
the general problem is that we've built all of our languages from the build tree, never and installed Parrot

I've been explaning Perl 6 roles on my new weblog
lots of feedback
still lots of explaining to do
also been profiling Parrot and Rakudo startup
Parrot's a lot faster now (cotto and bacek's work on vtable init helped immensely)
Rakudo's getting faster, but it has a ways to go
will keep working on that, but the progress has been decent with little investment
discussed exception handling with Allison
came up with a preliminary design to handle the interior runloop exit there
just syntax to hide tricky semantics

Patrick:

when dealing with exceptions, handlers, and returns for subroutines
it'd be nice to force a return from a subroutine higher up in the caller chain
akin to Perl 6's leave semantics
trying to do that without throwing an exception....
if we do it with exceptions requires every block to have a handler

Allison:

invoke the return continuation several levels back?

Patrick:

is that easily doable at this point

Allison:

we have all of the ability for that, but no syntax for it

Patrick:

I don't necessarily need syntax for it
the natural approach is to find the appropriate caller
I need to do that anyway
then ask for its ReturnContinuation
then invoke that with the values I want to return to its caller

makes sense to me

Patrick:

that may exist in PIR syntax like that anyway
if the easy invoke doesn't work, use some combination of set_returns

Allison:

not sure if we have in PIR right now the way to ask the caller for its return continuation
you can do it from C
we can add something which does that

Patrick:

if I ask for a Sub's current context
I could write a method on a sub to do that
it'll be easier and nicer when our contexts are PMCs
as an intermediate case, that would be it
related to that, this might be there too
is there a way for a Sub to register behavior to execute just before it exits

Allison:

are those like the LEAVE hooks in Perl 6?
we have a place to store them now
we don't right now have a way of flagging a particular handler to execute at block scope exit
would it make sense to call that an event?

Patrick:

it might
before saying what we do and don't have
one piece of this is that there's still a push_action opcode

Allison:

it never worked
we're removing it
the global stack never synchronized with continuations
it dummied up to work, but it doesn't have the automatic stack cleanup behavior

Patrick:

the other possibility is the presence of ONEXIT or LEAVE hooks on Subs in Parrot

Allison:

do you want all Subs to have that
or at runtime would you want to attach a handler to that sub?

Patrick:

it might be nice to have that at compile time
I suspect it'll end up being an attached block

Allison:

can we tie that cleanly with other execution pieces?
NEXT and LAST etc

Patrick:

the biggest difference with LEAVE is that it's not exception-based
Larry thinks of it as natural to a block
PCT models the rest as exceptional

Allison:

it sounds like a handler to store in the local handler list
mark it so that it's clearly not an exception
we have handler flags -- exception, event, etc
we add to the execution code for Subs
as it returns or ends, it checks to see if there was a handler
invokes it if so

Patrick:

sounds good to me
it's come up if you're thinking about these issues anyway

Nicholas:

how useful is MAD that's in Perl 5 blead still?

Larry:

I don't know
it may turn out to be very important
depends on how possible it is to write a decent Perl 5 parser in Perl 6
where decent is a very peculiar definition meaning "indecent"
this is unknown
for interleaving Perl 5 and Perl 6 on various VMs, some VMs will use a Perl 5 compiler written in Perl 6
that may not be a solution as nice as using the real Perl 5 parser which knows its own idiosyncracies

sometimes it does

Larry:

that's the point
I'd hate to have to have to hack it up again
that was a lot of work

Nicholas:

it seems to suffer slow bitrot
no one seems to try to keep it up to date
when people change the parser, they don't change it
the question is if people still use it

Larry:

the vision is still to have a Perl 5 to Perl 6 translator
that's been on hold until we have a viable target to translate to
the demand for that will re-arise at some point
if it bitrots, it bitrots
that doesn't bother me as much as if people felt like ripping it out
the way to unbitrot it was roundtripping the test suite and fixing any problems
we'd just go back to doing that again until everything was reannotated the way it needs to be
the standard for when you know you're storing enough information is being able to reproduce it

is there a test target to handle that?

Larry:

I used special scripts to do that
didn't expect other people to maintain that
it's MAD for a reason
nobody's tried to write a Perl 5 parser in Perl 6 yet
it's theoretically possible

Patrick:

depending how much fidelity you need for the actual Perl 5, you can get a pretty good way

Larry:

considering how much effort has gone into PPI, you can get a PPI-like result
that only takes you so far though

Patrick:

maybe a GSoC project next year would be for someone to start hacking something together with PPI
it'd be a worthwhile project

Larry:

we already have a Perl 5 to Perl 6 translator based on the state of MAD

Daniel Carrera: Perl 6 and the Josephus problem

Fri, 12 Jun 2009 15:35:31 +0000

The Josephus problem in Perl 6, Python and Ruby

In today’s post, I would like to compare the OOP syntax of Perl 6, Python and Ruby. To this effect, I decided to show you an implementation of the Josephus problem in each language. Wikipedia describes the Josephus problem:

There are people standing in a circle waiting to be executed. After the first man is executed, certain number of people are skipped and one man is executed. Then again, people are skipped and a man is executed. The elimination proceeds around the circle (which is becoming smaller and smaller as the executed people are removed), until only the last man remains, who is given freedom. The task is to choose the place in the initial circle so that you survive (are the last one remaining).

The problem is named after Flavius Josephus, a Jewish historian living in the 1st century. As the legend goes, he and his 40 comrade soldiers were trapped in a cave, surrounded by Romans. They chose suicide over capture and decided that they would form a circle and start killing themselves using a step of three. As Josephus did not want to die, he was able to find the safe place, and stayed alive.

Acknowledgement

The idea to use the Josephus problem to compare these languages is not my own. The idea comes from danvk.org who used it to compare Perl 5, Python and Ruby. I have copied his Python and Ruby code and I added the Perl 6 code of my own.

A quick note

I have tried to normalize the code as much as possible, so that you can get a better impression of the OOP syntax in each language. I will not benchmark the code, and I will keep my commentary to a minimum. The idea is that you see the OOP syntax of each language, with minimum influence from me.

Writing the class

Perl 6 (tested with Rakudo)

class Person {
	# $. means "public", "is rw" means it is writable.
	has ($.position, $.succ is rw);
	has $.alive is rw = True;

	# Stringify
	method Str() {
		"Person $.position, " ~ ($.alive ?? "alive" !! "dead")
	}
	# Create a linked chain of people.
	method createChain($n) {
		return self unless $n > 0;
		$.succ = Person.new(position => $.position + 1);
		$.succ.createChain($n-1);
	}
	# Kill every nth person. Stop killing if I'm the last one.
	method kill($pos is rw, $n, $remaining is rw) {
		return $.succ.kill($pos, $n, $remaining) if !$.alive;
		return self if $remaining == 1;

		if $pos == $n {
			$.alive = False;
			$pos = 0;
			$remaining -= 1;
		}
		$.succ.kill($pos+1,$n, $remaining);
	}
}

Python (tested with 2.5.2)

class Person:
	# Initialize
	def __init__(self,pos):
		self.position = pos
		self.alive = True

	# Stringify
	def __str__(self):
		status = "alive" if self.alive else "dead"
		return "Person #%d, %s" % (self.position, status)

	# Create a linked chain of people.
	def createChain(self,n):
		if n > 0:
			self.succ = Person(self.position+1)
			return self.succ.createChain(n-1)
		else:
			return self

	# Kill every nth person. Stop killing if I'm the last one.
	def kill(self,pos,n,remaining):
		if not self.alive:
			return self.succ.kill(pos,n,remaining)
		if remaining == 1:
			return self
		if pos == n:
			self.alive = False
			pos = 0
			remaining -= 1
		return self.succ.kill(pos+1,n,remaining)

Ruby (tested with 1.8.7)

class Person
	# Accessor and mutator methods
	attr_reader :position, :succ, :alive
	attr_writer :position, :succ, :alive

	# Initialize
	def initialize(pos)
		@position = pos
		@alive = true
	end
	# Stringify
	def to_s
		"Person \##@position, #{@alive ? 'alive' : 'dead'}"
	end
	# Create a linked chain of people.
	def createChain(n)
		return self unless n > 0
		@succ = Person.new(@position + 1)
		@succ.createChain(n-1)
	end
	# Kill every nth person. Stop killing if I'm the last one.
	def kill(pos,n,remaining)
		return @succ.kill(pos,n,remaining) if !@alive
		return self if (remaining == 1)

		if pos == n
			@alive = false
			pos = 0
			remaining -= 1
		end
		@succ.kill(pos+1,n,remaining)
	end
end

Comments

All three classes are straight forward, and almost exactly the same size. Perl 6 is a bit shorter, but the differences are insignificant:

	Perl 6	Python	Ruby
Lines of code*	23	25	27
Characters*	546	578	549

* Not including comments.

Note: A reader mentioned that a better way to do Ruby is to replace “attr_reader” and “attr_writer” by a single “attr_accessor”. With this change, Ruby is the shortest by character count.

There are things I could have done to make each language shorter, but my goal was to make each code sample clear and legible. Besides, you shouldn’t pick a language because you can save 3 lines of code. It makes more sense to see if you like the syntax and the over-all “feel” of the language, and that is a much more personal decision.

On a personal note, I don’t like the Python syntax as much… passing “self” explicitly, double underscores… it feels a bit hackish, but that’s just me. In turn, I like the Ruby and Perl 6 syntax. I can’t decide which I like better. Both look very clean and very clear.

Using the classes

Finally, this is how you would use these classes:

Perl 6

my $orig = 40;
my $nth = 3;

my $first = Person.new(position => 1);
my $last = $first.createChain($orig-1);
$last.succ = $first;

my $winner = $first.kill(1,$nth,$orig);
say "Winner: ", $winner;

Python

orig = 40
nth = 3

first = Person(1)
last = first.createChain(orig-1)
last.succ = first

winner = first.kill(1,nth,orig)
print "Winner: ", winner

Ruby

orig = 40
nth = 3

first = Person.new(1)
last  = first.createChain(orig-1)
last.succ = first

winner = first.kill(1,nth,orig)
puts "Winner: " + winner.to_s