Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

masak (6289)

masak
  (email not shown publicly)
http://masak.org/carl

Been programming Perl since 2001. Found Perl 6 somewhere around 2004, and fell in love. Now developing November (a Perl 6 wiki), Druid (a Perl 6 board game), pls (a Perl 6 project installer), GGE (a regex engine), and Yapsi (a Perl 6 implementation). Heavy user of and irregular committer to Rakudo.

Journal of masak (6289)

Monday June 07, 2010
05:03 PM

This Week's Contribution to Perl 6 Week 6

This Week's Contribution to Perl 6 Week 6: help improve the sidebars in the book

(Update 2010-06-10: Two days, and already two submissions! I continue to be amazed by the willingness of people to contribute to these weekly challenges. Somehow, the noosphere generosity so prevalent in the open-source world feels much more magical when it's coming from lurkers. Thank you!)

For this week's contribution to Perl 6, we ask you to wield some LaTeX skills in order to improve the appearance of the book some of us are writing.

(Introduction to this series of challenges)

Background

Have a look at page 23 in the book. There's a "sidebar" there, but it doesn't go on the side of the page, and it isn't especially aesthetically pleasing.

Help us make it better!

Submission

Please send your submission to the perl6-compiler@perl.org mailing list, and set me (cmasak@gmail.com) as CC, because the mailing list sometimes has a large delay.

If you have any questions, please ask the mailing list, me or (preferred) on our IRC channel, #perl6.

The best/most extensible/most complete/prettiest/whatever submission will make it into the next release of the book.

Saturday June 05, 2010
08:03 AM

Week 2 of GSoC work on Buf -- the power of Swedish beer

Last week's summary was short out of choice; this week's is short out of necessity. I'm traveling a bit, and my access to the net isn't the best.

  • Changed the spec to contain only an array constructor for Buf, and removed the slury-array constructor.
  • The Parrot people are discussing a long-term solution for the conversion between strings and bytes. They are (rightly) worried about exposing the wrong bits, and want things to be right.
  • For the short term, jnthn++ hacked together a Parrot type called ByteView in my branch. I tried it, and it was almost enough for encoding a string. The whole thing is clearly doeable.

Where does Swedish beer enter into it? Well, jnthn's example string was "öl", the Swedish word for "beer". So the Buf implementation is definitely helped along by Swedish beer. 哈哈

Tuesday June 01, 2010
04:45 PM

Yapsi 2010.06 Released!

It is with a mien of amusement that I want to announce, on behalf of the whole Yapsi development team, the June 2010 release of Yapsi, a Perl 6 compiler written in Perl 6.

You can get it here.

Yapsi is implemented in Perl 6. It thus requires a Perl 6 implementation to build and run. We recommend the 'alpha' branch of Rakudo for this purpose.

Yapsi releases are 'official and complete', shown here by a circular argument: clearly an official thing like Yapsi must be complete, and Synopsis 1 states that anything complete is official. QED. Yapsi passes 100% of its test suite.

Instructions for getting Yapsi up and running:

  1. Make sure you have a built Rakudo alpha in your $PATH as 'alpha'.
  2. Download Yapsi from github.
  3. ...
  4. Profit!

The third (optional) step consists of running 'make' in the Yapsi directory. This will precompile Yapsi, making startup times much more bearable.

The big news since last month is that Yapsi now has a logotype. It's a picture of a Möbius band, to symbolize self-loopiness, recursion and twisted ideas.

Yapsi consists of a compiler and a runtime. The program is compiled down into an instruction code called SIC, which doesn't stand for anything [sic]. All SIC listings start with a versioning line saying e.g. "This is SIC v2010.06". At this point during Yapsi development, we provide no guarantees about backwards compatibility whatsoever. Expect breakage between monthly releases.

An overarching goal for making a Perl 6 compiler-and-runtime is to use it as a server for various other projects, which will hook in at different steps:

  1. A time-traveling debugger (tardis), which will hook into the runtime.
  2. A coverage tool (lid), which will also hook into the runtime.
  3. A syntax checker (sigmund), which will use output from the parser.

Another overarching goal is to optimize for fun while learning about parsers, compilers, and runtimes. We wish you the appropriate amount of fun!

Monday May 31, 2010
10:44 AM

GGE now runs fine on Rakudo master

After admitting that I had a problem, I decided that perhaps it would be good to take one single application and just beat it into submission, making it run on Rakudo master.

I chose GGE. That was a mistake, but perhaps a positive one.

GGE is big, and has many tests, 750 of them. Running through them all takes almost 40 minutes. (The first "G" in GGE stands for "Glacial".) I keep thinking of GGE is "the biggest Perl 6 application out there", even though it's probably not that big, just fairly complex and well-tested. The mistake was attacking GGE first, and not something smaller.

The way the mistake might turn out to be a positive one is that I'll probably feel that converting other applications from alpha to master is relatively painless. 哈哈

Here's a summary of things to think about, if you're planning to port your Perl 6 application from alpha to master:

Improvements

  • Rakudo master has better interpolation of things like "@lol[]". I found a lot of cases where I "cheated" and used symbols which weren't magical in alpha, but which are now. Beware.
  • is also is now augment, and requires use MONKEY_TYPING;.
  • If you had put subs in your class, chances are you'll need to our them now.
  • Rakudo master is stricter about not changing the contents of readonly containers, such as arrays and hashes. You'll get a slap on the fingers if you did this.
  • undef is gone. You probably meant Nil or Any or something.
  • If you were using postcircumfix:<( )>, remember that Rakudo master now requires the parameter list to consist of just a single Capture parameter. In practice, that means another layer of parentheses compared to alpha.
  • break in when blocks is now called succeed (and continue is called proceed)

Regressions

  • Named enums work in master, but they're not really up to spec yet. If you used them as sets of constant, things might still work. If you used methods like .name and .pick, you'll need to work around for the time being. (And re-read the spec.)
  • The <-> syntax for pointy blocks is no longer implemented.
  • Backslash escapes don't work in character classes.
  • Str.trans doesn't work.
  • handles doesn't work.
  • Using an optional hash parameter with is copy semantics? Well, it won't work. Sorry.
  • Str.subst works, but using $_ in a closure in its second argument doesn't.
  • Sometimes you have to clone closures using pir::clone, or they won't close properly around their surrounding environments.
  • "\e" doesn't work at the moment. Use "\c[27]" or "\x[1b]".
  • If you were general before and wrote List rather than Array because, well, it's shorter and more inclusive... that won't work now. Array no longer subclasses List.
  • There are some situations when you might wind up with double [] in arrays.
  • There's something wrong with list assignment and hashes.

It took two months of leisurely refactoring and debugging to bring GGE through the needle's eye. But I must confess that it was pretty sweet to subsequently rid it of all of alpha's workarounds. Clearly a net win.

Friday May 28, 2010
09:29 AM

Week 1 of GSoC work on Buf -- not a chocolate cake recipe

No-one likes to trawl through long grant progress reports that read like a recipe for chocolate cake, but without the chocolate cake. So I'll be mercifully brief.

By the plan I'm supposed to work on constructors and indexing now, but I gravitated towards the Str.encode and Buf.decode stuff because that's where I left off last time I worked on this. There's still plenty of time next week to do the constructors and indexing.

Not used to writing a report this small. But I think I like it. 哈哈

(What, this thing? Yes, it so happens it's a chocolate cake. No, you can't have any. Get your own.)

Friday May 21, 2010
09:24 AM

The trip to Moscow and the DevConf talk (iambic pentameter)

My trip to Moscow was a pleasant one,
The city has a certain feel I like.
The metro is so big and full of win!
And so too was the room at my hotel.

My talk was well-received and fun to give,
on Yapsi, Tardis, Sigmund and Perl 6.
sharifulin++ for speedy help
with setting up his laptop for my talk.

The guys at Moscow.pm made me feel
at home in Moscow, and enjoy my stay.
I only wish my Russian wasn't crap.
Incentive to learn more of it, I guess.

At Airport Sheremetyevo they said
"departure is tomorrow, not today".
'Pro tip': when booking, check an extra time
that chosen dates are actually correct.

I tried to write iambicly above... That Shakespeare guy was pretty good, it seems! I'm not, so my attempts don't even rhyme. But maybe some commenters' comments will...?

Sunday May 09, 2010
10:03 AM

The tests Rakudo doesn't run

Just a short note.

After an enlightening discussion with mberends a couple of days ago, I became curious about how many spectests Rakudo doesn't run.

So I wrote a short script which takes a list of all spectest .t files, a list of all the files mentioned in Rakudo's t/spectest.data (including the commented-out ones), and did hash subtraction on them.

By the way, a common Perl 5 idiom in this situation is difficult to do in Rakudo, because some blocks are still erroneously parsed as hashes:

$ perl6
> my @array; my %hash = map { $_ => 1 }, @array;
No candidates found to invoke
> say { $_ => 1 }.WHAT
Hash()

Working around this, I arrived at the number 185. That's out of a total of 722. Here's the whole list.

Not too surprisingly, upon showing this list to #perl6, I was quickly informed (by the ever-knowledgeable moritz++) that there's already a Rakudo tool script which processes exactly this list of tests, and prints the much more useful subset of files with at least one test passing, thus being eligible for inclusion into t/spectest.data.

I hope to be able to explore the spectest suite further, in my copious spare time. My long-term goal is to create alluring SVG graphs over the tests currently passing in Rakudo master, Rakudo alpha, and Pugs.

Sunday May 02, 2010
09:09 AM

Perl 6: the Frankenstein's monster of operators

By this point, a stray comment on an earlier blog post of mine has snowballed into a real discussion, so let's hoist it up here for everyone to see. It's a friendly discussion full of smilies, between two people with different viewpoints. Get the popcorn; I'll provide the quotes.

The commentator, nilsonsfj, is a Perl 5 programmer who 'just didn't bother following up on Perl 6 anymore after the Unicode ops and the whole "periodic table of operators" thing.' I guess that description applies to quite a few Perl 5 programmers out there; Perl 6 just isn't relevant to them in its present state.

I reply:

You should take a look at the new table from last year, if you haven't yet. It's gorgeous. Also — and I bet you know this — neither Perl 5 or Perl 6 is meant to be taken in all at once, and the periodic table sort of goes against that and says "Boo! Operators!" and scares everyone giddy with all the horrible richness. Perl isn't a first language, it's more of a last language. ☺

Also, after you've recovered from the Unicode thing, you'll be pleased to know that all of the ops in that table are all quite ASCII-friendly. Wreaking havoc with Unicode operators is left as an exercise for module authors. ☺

nilsonsfj goes ahead and looks, and comes back replying:

Well, I just looked at the new periodic table and if by "gorgeous" you meant "scary", I agree with you. ☺

(Boo! Operators!)

I reply with:

In the interests of mutual understanding, I tried to look at the periodic table, and tried to instill a measure of fear in myself. The closest I got was "huh, that's quite a lot of them, isn't it?".

I think one of the big dividing points between the Perl languages on the one hand and other programming languages on the other, is that Perl embraces complexity — often quite fearlessly. Language designers are known to talk about minimalism and orthogonality. Perl, in contrast, seems to take as a starting point that the world, including the programming world, is complex and messy and non-orthogonal and full of redundancy and can be seen in different ways by different people.

Perl 5 has quite a lot of operators. I haven't counted them, and wouldn't really know where to start if I were to try. I'm sure Perl 6 has more, maybe even twice as many. (Again, by some half-defined measure.) I think I don't think "scary" when I look at the table because most of these operators are familiar to me now, and I see the rationale for them. (Yes, duh.) Also, many of them I don't normally consider operators, either because they're too infrastructural (like the comma or the different dotty method calls) or too abstract (like 'does' or most of the alphabetic list operators) to be real operators.

With the rest of them, they're either new (which one would expect from a new language or even an upgrade), or they're instances of one Perl 5 operator that has exploded into a couple of Perl 6 operators because Perl 6 often takes a more strict view to keeping different things distinct and relies less on value context than does Perl 5. The shift/and/or/negate operators prefixed by plus or tilde or question mark are an example of this; I briefly give the rationale for why I like this change in blog post from a while back. I should add that I don't use those particular operators on a day-to-day basis, because of their quite specific and close-to-the-metal nature. (That's also a dimension not visible in the Table; some operators are uncommon in practice.)

Much of the complexity is actually hidden and folded in by the presence of the metaoperators. Of course, the mere concept of a metaoperator and the sudden ability to create a fitting operator on the spot (along with the parser technology required to make that work) are, by rights, scary in an objective sense. But it's one of the things that grows on you. And I haven't seen people abuse it either; just because there are metaoperators available, people don't suddenly go crazy and produce unmaintainable code. Rather, it helps turn a for loop here and there into a one-liner.

I came in at around 2004, and I've seen many of these operators mature and take shape. So I guess I'm biased by having seen the rationale for most changes, from Perl 5 through the Apocalypses and Synopses up until today. I agree with most of them. I still don't quite understand how we ended up with eight flip-flop operators, but I haven't really used them yet, so I'll reserve judgment on that point. Maybe they'll be handy in a perl6 -ne context or something.

Perl 6 is an 'operator-oriented' language. In fact, operators are described in the spec as being subroutines and methods with funny syntax. (I'm paraphrasing here.) In that sense, the whole discussion dissolves into a larger discussion on which subroutines and methods we want to keep in the Perl 6 core, and which one of those should manifest as operators.

Perl 5 and Perl 6 tend to favor a good operator in many cases where other languages would reach for a subroutine or method. That's fine. If you don't like it that way, we won't tell you to take your umbrella and go somewhere else, we'll tell you to show us how you would have it look, and your solution can even get its own life as a module or a spec change or a community best practice. It's happened many times before, and it'll happen many more times. As a result, we end up with a language covering one enormous sweet spot, looking like Frankenstein's monster and being quite proud of it. Because, as someone once said, it's the magic that counts.

Saturday May 01, 2010
04:47 PM

Yapsi 2010.05 Released!

It is with undue sprightliness that I want to announce, on behalf of the Yapsi development team, the May 2010 release of Yapsi, a Perl 6 compiler written in Perl 6.

You can get it here.

Yapsi is implemented in Perl 6. It thus requires a Perl 6 implementation to build and run. We recommend the 'alpha' branch of Rakudo for this purpose.

Yapsi is an 'official and complete' Perl 6 release. It's official because we have little labels with the word 'official' on them that we glue to each download that takes off from github. (That much gluing takes a lot of work, but we think of it as a community service.) It's complete in the sense that all of the things it implements, it does. With gusto.

Instructions for getting Yapsi up and running:

  1. Make sure you have a built Rakudo alpha in your $PATH as 'alpha'.
  2. Download Yapsi from here.
  3. ...
  4. Profit!

The third (optional) step consists of running 'make' in the Yapsi directory. This will precompile Yapsi, making startup times much more bearable.

The big change since last month is that Yapsi now does immediate blocks.

$ export PERL6LIB=`pwd`/lib

$ ./yapsi -e 'my $a = 42; { my $a = 7; say $a }; say $a'
7
42

For other changes, see the doc/ChangeLog file.

This release, as opposed to the last one, contains hidden bugs. We encourage you to help us find them; if not for the fame and glory, than at least for the Schadenfreude.

Yapsi consists of a compiler and a runtime. The program is compiled down into an instruction code, which can be stored and executed weeks, years or even days [sic] later. If you want, you can execute the same piece of SIC several times over. All SIC listings start with a versioning line saying e.g. "This is SIC v2010.05". At this point during Yapsi development, we provide no guarantees about backwards compatibility whatsoever. Expect breakage between monthly releases.

An overarching goal for making a Perl 6 compiler-and-runtime is to use it as a server for various other projects, which will hook in at different steps:

  • A time-traveling debugger (tardis), which will hook into the runtime.
  • A coverage tool (lid), which will also hook into the runtime.
  • A syntax checker (sigmund), which will use output from the parser.

Another overarching goal is to optimize for fun while learning about parsers, compilers, and runtimes. We wish you the appropriate amount of fun!

Thursday April 29, 2010
10:01 AM

GSoC, contextuals, and intolerance (three posts in one)

This is three thirds of a post. The three parts will simply have to combine into one big mechbot in order to pass as a whole post.

I'm a GSoC 2010 student

I sent in a proposal, and it got accepted. Yay!

Use contextuals for "process data", not attributes

Sometimes you both want do subdivide methods into small manageable parts, all the while keeping some sort of data between them. Most people reach for the instance attributes to do this, since these shared between all the methods of one object.

But this can also be done with contextuals, as is now done in Yapsi. This keeps the lifetime of the variables as short as possible, and keeps the objects light-weight. And it still works with inheritance.

I like how Perl 6 allows me to mix OO and contextuals this way. And I really like that it works in Rakudo already.

The mechanics of intolerance

I've blogged before about how #perl6 is a small, friendly community which turns even flame wars into interesting discussions and which works on being kind and open. We've had a bit of troll activity since I wrote those posts, as well as a few borderline trolls.

The other day I treated someone with undue impatience. The whole episode ended well, and I've apologised. In short, what looked like nagging questioning may simply have been someone's slightly different means of communicating.

Mean and evil acts are often committed by people convinced that they're actually doing good. mst++ writes about the reasons for being harsh, and I thought this was one of those times when that was called for. It wasn't.

It taught me to look out for situations when I might be mistaking variations in personality and communication skills for truly annoying behaviour. In many ways, that's a refreshing reminder: a really open community requires that we recognize that everyone doesn't operate exactly the same as we do. That sounds terribly clichéd, I know; but forgetting it is also far too easy.