Read this article on Rakudo.Party

Every year since 2009, the Perl 6 community publishes a Perl 6 advent calendar, in the form of blog posts on perl6advent.wordpress.com.

To keep up this great tradition, we need 24 blog posts, and volunteers who write them. If you want to contribute a blog post about anything related to Perl 6, please add your name (and potentially also a topic already) to the schedule, and if you don't yet have a login on the advent blog, please tell Zoffix or someone on #perl6 IRC chat your email address so that they can send you an invitation to Wordpress for the site.

Perl 6 advent blog posts should be finished the day before they are due, and published on midnight (UTC) of the due date as publishing date.

If you have any questions, or want to discuss blog post ideas, please join on the #perl6 IRC channel on irc.freenode.org.

Read this article on Rakudo.Party

Today's is a milestone of sorts: it's 100 days before the first scheduled Rakudo Perl 6 compiler release that will occur after this year's festival of Diwali. As some know, Diwali is also the code name for the next major release of the Perl 6 language, version 6.d, which means there's a high chance that in about 100 days you'll be able to install and use that.

I figured, I'd write a update on the subject.

When?

The oft-asked questions is when is 6.d going to be released. The plan is to have the 6.d specification good and ready to release on this year's Diwali, which is November 6–7.

About 10 days later the Rakudo compiler will be released (compiler-only, not the Rakudo Star), with 6.d language enabled by default. That is, you'll no longer need to use use v6.d.PREVIEW pragma to get 6.d features, and if you wish to get old, 6.c behaviour you'll need to use an explicit use v6.c pragma.

However, there's a ton of work to do and the work is largely done by volunteers, so we have no compunction about delaying the release of any of the deliverables indefinitely, if the need arises.

What?

The 6.d major version of the Perl 6 programming language includes over 3,400 new commits in its specification. The vast majority of these are clarifications to 6.c spec. In other words, most of these define previously undefined behaviour, rather than specify entirely new features.

Many of the clarifications and new features do not conflict with the 6.c specification. If you're using the Rakudo compiler, you are likely already reaping some of the benefits of the 6.d language, as such things do not require explicit use v6.d.PREVIEW pragma.

Those who've seen the 6.d Teasers frequently ask for the full list of 6.d changes. That list does not yet exist, as the spec is still in the process of being reviewed. The changelog will be available some time in October. You may have seen the 6.d prep repo, but that just contains guiding info for coredevs and isn't descriptive of the actual 6.d content.

The aforementioned ton of work includes:

• Still have to review about 2,100 spec commits
• Still have ~95% of ChangeLog to write
• Still have to implement, 7 TODO features, costing 110 hours
• Still have 0.3 policies to write (a draft already exists, but needs polishing)
• Review and spec of any new features that were implemented in Rakudo but were not specced in the language
• Marketing stuff regarding creation of marketing name alias for the language

The Future

Going forward for future language releases, I foresee us doing a point release every 6 months, and 6.e being released 2 or 3 years after 6.d. The previously 6.d-blocking Issue R#1289 still blocks a number of language changes, and all the 6.d changes blocked by that Issue were pushed to later language versions. So, if that Issue is resolved, that will likely be a reason to cut a language release soon thereafter.

Conclusion

The prep work for next major release of the Perl 6 Programming Language version 6.d (Diwali) is in a high gear. There's lots of work to do. Will likely release spec on November 7th, with compiler release following step and being released about 2 weeks after that. The list of changes will be ready in October and does not currently exist in any user-consumable form.

Let the hype begin \o/

-Ofun

Read this article on Rakudo.Party

As some of you already may have known from occasional tweets and mentions in the Weekly, we have a perl6/marketing repo that contains some flyers and brochures for Perl 6.

With one of the Perl 6 coredevs making a living as a Multi-Media Designer, the repo has seen a steady stream of new pieces designed, when inspiration strikes, or when someone makes a request. There are now several pieces available, but GitHub isn't the greatest interface for this sort of stuff.

Introducing marketing.perl6.org

To make it easier to see what we have available, we made a front-end for our marketing repo, that lets you browse all of the assets. It's hosted at marketing.perl6.org

The Assets

Under the thumbnail of each asset, there are a few buttons that show you which formats are available for download. The last two buttons are the GitHub button and the pencil button. The former will lead you to GitHub to the folder that particular asset is at, where you can download any files that aren't shown on the front end (e.g. the source files). The latter will lead you to the New Issue page on the marketing repo, with title/ID of the piece pre-filled. This is in case you'd like to request different format, size, or some other changes for that piece.

Each piece has an ID number (a Unix timestamp, e.g 1516098660). If you want to refer to some piece, try to include its ID, as that's the easiest way for the designer to know what piece you're talking about.

INB4, the Camelia logo variants are so numerous because the rules allow for her colours to be changed. Personally, I prefer transparent wings, as they're easier on my retinas than the default logo.

Keep in mind, you can request new pieces as well. Just file a new Issue in the marketing repo, describing the content that you want, including the sizes/colour restrictions, and our volunteers will hook you up.

The Prints

While files themselves are easy to make for free, the same isn't the case for hard copies. We (the volunteers handling the marketing repo) can't print any hardcopies for you. Unless you are able to use a local printing company and pay out of your own pocket, your best bet would be to contact The Perl Foundation and ask them if they can sponsor the prints. I know they made prints of the Introducing Perl 6 brochure for a conference in the past.

Licenses

The assets shown in the marketing web app are licensed under Creative Commons Attribution 4.0 International License. The Camelia logo is copyright by Larry Wall. Some of the pieces use purchased stock, which may have licenses that limit super-large print runs (50,000+ copies). Check the files in the repo or contact Zoffix if you have an unusual usecase for the materials and wish to clarify the licensing.

The source files (InDesign/PhotoShop/Adobe Illustrator) themselves can be modified freely, under the terms of Creative Commons Attribution 4.0 International License. Any images/fonts/other assets used by those source files might have additional licensing restrictions, which will usually be noted in the directory for that asset.

Conclusion

Going out for some tech meetup? Print out a few pieces from our marketing web app, hand them out, share the Perl 6 love!

-Ofun

Read this article on Rakudo.Party

Last week I gave a "Intro Into Perl 6 Regexes and Grammars" talk at the Toronto Perl Mongers, whom I thank for letting me speak.

For google hangout that is usually set up, we got to use the fancy equipment provided by the company that was letting us use their space. Unfortunately, it's currently unclear if the hangout was recorded and if there would be a video of the talk.

So, I figured I'd make a screencast of the talk. You won't get some of the discussions that occurred during the meeting, but the content of the talk itself is pretty much identical.

You can view the slides at https://tpm-regex.perl6.party/ and the screencast of the talk is on YouTube:

Read this article on Rakudo.Party

Last week I gave a "Faster Perl 6 Programs" talk at the Toronto Perl Mongers, whom I thank for letting me speak.

For google hangout that is usually set up, we got to use the fancy equipment provided by the company that was letting us use their space. Unfortunately, it's currently unclear if the hangout was recorded and if there would be a video of the talk.

So, I figured I'd make a screencast of the talk. You won't get some of the discussions that occurred during the meeting, but the content of the talk itself is pretty much identical.

You can view the slides at https://tpm-perf.perl6.party/ and the screencast of the talk is on YouTube:

Read this article on Rakudo.Party

Today, I came across a reddit post from a couple months back, from a rather irate person claiming themselves to be possibly the only person to never receive any credit for their work on Perl 6.

I was aware that person committed at least one commit and knowing the contributors list is generated automagically with a script, I thought to myself "Well, that's clear and provable bullshit." And I went to prove it.

Moar No More

I looked up the commit I knew about, looked at the release announcement for the release it went into and… that person was indeed missing! It was the 2017.02 release, which I released. So what was going on? Did I have an alter-ego that shamelessly erased random people from the contrib list without my having any memory of it?!

First, a brief intro on how the contrib script works: it uses git to look up commits in checkouts of 5 repos: Rakudo, NQP, MoarVM, Docs, and Roast. Until December 2016 the script just used the day of the release as last release, which was later switched to using the timestamp on the Rakudo's tag. The script gathers all the contributors from commits, crunches the names through the names map in CREDITS files in the repos, and it spits out the names ordered by the number of commits made, largest first.

I set out to figure out why a person was missing from the release announcement. After digging through commits, CREDITS files, and tracing the code in the contributor generating script, I found out that in September 2016, I introduced a bug into the contributors script. After some refactoring I accidentally left out MoarVM repository from the list of repos the script searches, so all the contributors to the MoarVM since September 2016 were missing! Since many of them also contribute to the other 4 repos, it was harder to spot that something was wrong.

I filed the problem as R#2024 and left it at that for the time being.

Missing More

I started working on the problem and implemented a new feature in the contributors script that lets you look up contributors for past releases. Neat! So let's try it out for some release before my bug was made, shall we?

I ran the contrib script for 2016.08 relase and then ran another script that diffed the names from that output against what is on the release announcement. The output was:

Announcement has these extra names: David Warring
Contrib script has these extra names: Arne Skjærholt, Bart Wiegmans

The announcement had an extra name and was missing two. The way the contrib script figures out when one release ends and another starts is iffy, especially so in the past. There's a gap of about a day where contributors can slip through: e.g. release manager runs the release at 2PM, someone commits at 3PM, and that commit didn't make it into this release and will be included in the next, or might even be missed entirely.

So that was one problem I noticed. Is that where the difference for 2016.08 release names list comes from? Let's try the earliest post-The-Christmas release: 2016.01-RC1

Announcement has these extra names: Andy Weidenbaum, Lloyd Fournier, skids
Contrib script has these extra names: A. Sinan Unur, Aleks-Daniel Jakimenko-Aleksejev,
Brad Gilbert, Brian S. Julin, Brock Wilcox, Bruce Gray, Carl Masak,
Christian Bartolomäus, Christopher Bottoms, Claudio Ramirez, Dale Evans,
Dave Olszewski, David Brunton, Fritz Zaucker, Jake Russo, James ( Jeremy )
Carman, Jeffrey Goff, Jim Davis, John Gabriele, LLFourn, Marcel Timmerman,
Martin Dørum Nygaard, Neil Shadrach, Salvador Ortiz, Shlomi Fish, Siavash
Askari Nasr, Stéphane Payrard, Sylvain Colinet, Wenzel P. P. Peppmeyer,
Zoffix Znet, fireartist, sylvarant, vinc17fr

That's huge! One name stood out to me in that list—and it isn't my own—it was that same person from reddit who was complaining that they don't get credit. They got left out twice: in 2016.01 and again in 2017.02. No wonder they're pissed off, but I wish they would've said something in 2016.01, so we'd've fixed the Missing Persons issues back then instead of now.

The 2016.02 release has a bunch of missing names as well. I can surmise the cause of the issue is a previously fixed mis-implementation of the contributors script where it'd be quiet if some of the repo checkouts were missing. Neither I (until that point), nor earlier release managers had all of at the right locations the script was expecting, so it's possible that's how some repos were missed.

At the time, I assumed only the docs repo was missing and we credited missing Docs contributors in the 2016.08 announcement. However, now I realize that other release managers likely had different directory setups and thus missed different sets of people.

The Future

Thus, we have identified four issues with the way contributor's script is or has been generating the list of contributors:

• Relying on the time when the release manager runs the contributor script, potentially creating a gap of unrecorded contributions between the time the script is run and the time the next run of contrib script considers as "last release"
• Relying on release manager's setup of directories/repos. Even after a previous fix in this area, we're still relying on the release manager to have up-to-date checkouts of repos
• Missing contributors from entire repositories due to unnoticed bug in the code
• What happens with commits made at the time of past release in a branch that is merged at the time of the next release? Do they get lost?

I'm taking the lazy way out and leaving it to the current release managers to resolve these problems. I filed R#2028 with the list of issues and have full trust the solution that will be implemented will be suitable :)

The Found

And now, of course, the list of previously unsung heros who made Perl 6 better in the past two and a half years, in alphabetical order. I've also added them to our past release announcements.

It's possible this list includes the missing-found from 2016.08 announcement as well as people who were not logged in the CREDITS file in the past but are now, but I figure it's better to list them twice than none at all.

If you still believe we're missing someone, let us know so the problem can be fixed.

2016.01/2016.01-RC1

A. Sinan Unur, Aleks-Daniel Jakimenko-Aleksejev, Brad Gilbert, Brian S. Julin, Brock Wilcox, Bruce Gray, Carl Masak, Christian Bartolomäus, Christopher Bottoms, Claudio Ramirez, Dale Evans, Daniel Perrett, Dave Olszewski, David Brunton, Fritz Zaucker, Jake Russo, James ( Jeremy ) Carman, Jeffrey Goff, Jim Davis, John Gabriele, LLFourn, Marcel Timmerman, Martin Dørum Nygaard, Neil Shadrach, Salvador Ortiz, Shlomi Fish, Siavash Askari Nasr, Stéphane Payrard, Sylvain Colinet, Wenzel P. P. Peppmeyer, Zoffix Znet, fireartist, raiph, sylvarant, vinc17fr

2016.02

Bart Wiegmans, Brian S. Julin, Brock Wilcox, Daniel Perrett, David Brunton, Eric de Hont, Fritz Zaucker, Marcel Timmerman, Nat, Pepe Schwarz, Robert Newbould, Shlomi Fish, Simon Ruderich, Steve Mynott, Wenzel P. P. Peppmeyer, gotoexit, raiph, sylvarant

2016.03

Ahmad M. Zawawi, Aleks-Daniel Jakimenko-Aleksejev, Bahtiar kalkin- Gadimov, Bart Wiegmans, Brian S. Julin, Brock Wilcox, Claudio Ramirez, Emeric54, Eric de Hont, Jake Russo, John Gabriele, LLFourn, Mathieu Gagnon, Paul Cochrane, Siavash Askari Nasr, Zoffix Znet, jjatria, okaoka, sylvarant

2016.04

Brian S. Julin, Brock Wilcox, Christopher Bottoms, David H. Adler, Donald Hunter, Emeric54, Itsuki Toyota, Jan-Olof Hendig, John Gabriele, Mathieu Gagnon, Nick Logan, Simon Ruderich, Tom Browder, Wenzel P. P. Peppmeyer, Zoffix Znet

2016.05

Aleks-Daniel Jakimenko-Aleksejev, Brian Duggan, Brian S. Julin, Brock Wilcox, Christopher Bottoms, Clifton Wood, Coleoid, Dabrien 'Dabe' Murphy, Itsuki Toyota, Jan-Olof Hendig, Jason Cole, John Gabriele, Mathieu Gagnon, Philippe Bruhat (BooK), Siavash Askari Nasr, Sterling Hanenkamp, Steve Mynott, Tadeusz “tadzik” Sośnierz, VZ, Wenzel P. P. Peppmeyer, Will Coleda

2016.06

(contrib script missing repos issue is fixed around this point, so the number of missing persons drops. Remaining ones are likely the ones that fell into the gap between releases; particularly MoarVM and docs contributors)

Itsuki Toyota, Matthew Wilson, Will Coleda, parabolize

2016.07

Bart Wiegmans, Brian S. Julin, Daniel Perrett, David Warring, Dominique Dumont, Itsuki Toyota, thundergnat

2016.08

Arne Skjærholt, Bart Wiegmans

2016.09

(missing MoarVM bug is introed at this point; we start to see the missing MoarVM devs who mostly work on MoarVM and not other repos. Also a bunch of docs people who likely fell into the gap between releases)

Alexey Melezhik, Bart Wiegmans, Paul Cochrane

2016.10

Brent Laabs, Jimmy Zhuo, Steve Mynott

2016.11

Bart Wiegmans, Itsuki Toyota, Jimmy Zhuo, Mark Rushing

2016.12

Bart Wiegmans, Jimmy Zhuo, LemonBoy, Nic Q, Reini Urban, Tobias Leich, ab5tract

2017.01

Antonio Quinonez, Jimmy Zhuo, M. Faiz Zakwan Zamzuri

2017.02

A. Sinan Unur, Bart Wiegmans, Benny Siegert, Jeff Linahan, Jimmy Zhuo, Lucas Buchala, M. Faiz Zakwan Zamzuri

2017.03

Jonathan Scott Duff, Lucas Buchala, Moritz Lenz

2017.04

Bart Wiegmans, eater

2017.05

Bart Wiegmans, Paweł Murias

2017.06

Bart Wiegmans, Jimmy Zhuo, Oleksii Varianyk, Paweł Murias, Robert Lemmen, gerd

2017.07

Bart Wiegmans, Douglas Schrag, Gerd Pokorra, Lucas Buchala, Paweł Murias, gerd

2017.08

Bart Wiegmans, Dagfinn Ilmari Mannsåker, Douglas L. Schrag, Jimmy Zhuo, Mario, Mark Montague, Nadim Khemir, Paul Smith, Paweł Murias, Philippe Bruhat (BooK), Ronald Schmidt, Steve Mynott, Sylvain Colinet, rafaelschipiura, ven

2017.09

Bart Wiegmans, Dan Zwell, Itsuki Toyota, Jan-Olof Hendig, Jimmy Zhuo, Mario, Paweł Murias, Rafael Schipiura, Skarsnik, Will Coleda, smls

2017.10

Bart Wiegmans, Jimmy Zhuo, Joel, Julien Simonet, Justin DeVuyst, M, Mario, Martin Ryan, Moritz Lenz, Patrick Sebastian Zimmermann, Paweł Murias, bitrauser, coypoop, eater, mryan, smls

2017.11

Bart Wiegmans, Jimmy Zhuo, Martin Barth, Patrick Zimmermann, Paweł Murias

2017.12

Bart Wiegmans, Paweł Murias, Stefan Seifert, brian d foy

2018.01

Bart Wiegmans, Daniel Dehennin, Paweł Murias, Stefan Seifert, Will Coleda

2018.02

Bart Wiegmans, Daniel Green, Paweł Murias, cygx, wukgdu

2018.03

Bart Wiegmans

2018.04

Bart Wiegmans, Paweł Murias, cc, gerd

2018.05

Antonio, Bart Wiegmans, elenamerelo

2018.06

Bart Wiegmans, JJ Merelo

Conclusion

So this was quite a fun investigation and hopefully all the missing people have been found and this is the last missing-found persons list we compile.

The most important lesson, however, is: report problems as soon as you find them. We could've fixed this at the start of 2016, and those who knew they were left out could've saved two years of being upset about it.

-Ofun

Read this article on Rakudo.Party

The Perl 6 programming language had a turbulent birth. It was announced in the summer of 2000 and the first stable language release shipped out only 2 years ago, on Christmas, 2015. A lot has happened during that decade and a half, yet the details are hard to piece together.

After my recent facelift to rakudo.org, I'm working on a (second) facelift to perl6.org website.

Part of the work involves bringing all the Perl 6 deliverables under one umbrella, so the user isn't thrown around multiple websites, trying to find what to install. At the same time, we want to strengthen the distinction between Perl 6 the language and the compilers that implement it, as well as encourage more implementors to give it a go at implementing a Perl 6 programming language compiler.

The Perl 6 Programming Language Museum will be part of that effort and along with interesting tidbits of Perl 6 history, it'll showcase past implementation attempts that may no longer be in active development today. Since I don't know much about what happened before I came to the language sometime in 2015, I need your help in collecting those tidbits.

Larry Wall at FOSDEM 2015, photo by Klapi

In my mind's eye, I'm imagining a few pages on perl6.org; something in the same vein as Computer History Museum's pages—pictures, years, and info, and potentially links to code repositories. Depending on the content we collect, it's possible there will be a digital PDF version of the Museum that can also be printed and handed out at events, if desired.

I'm looking for:

• Descriptions of interesting/significant events (like the mug throwing incident).
• Descriptions of interesting/significant implementations of Perl 6 or influential Perl 6 projects. Having links to repos/tarballs of their code is a plus.
• Samples of interesting/significant email threads or chat logs.
• Pictures of interesting/significant objects (first sight at plush Camelias?).
• Pictures of interesting/significant humans (a filled out model release form is required).
• Anything else that's Museum worthy.

If you have any of these items, please submit them to the appropriate year directory in the Perl 6 Museum Items repository. If you're a member of Perl 6 GitHub org, you should already have a commit bit to that repo. Otherwise, submit your items via a pull request.

Let's build something cool and interesting for the people using Perl 6 a hundred years from now to look at and remember!

If you have any questions or need help, talk to a human on our IRC chat.

-OFun

Read this article on Rakudo.Party

Recently, I came across a somewhat-frantic comment on StackOverflow that describes a 2017.01 change to the type of return value of .sort:

"you just can't be sure what ~~ returns" Ouch. […] .list the result of a sort is presumably an appropriate work around. But, still, ouch. I don't know of a blog post or whatever that explains how P6 approaches changes to the language; and to roast; and to Rakudo. Perhaps someone will write one that also explains how this aspect of 2017.01 was conceived, considered and applied; what was right about the change; what was wrong; etc.

Today, I decided to answer that call to write a blog post and reply to all of the questions posed in the comment, as well as explain how it's possible that such an "ouch" change made it in.

On Versioning

The '6' in Perl 6 is just part of the name. The language version itself is encoded by a sequential letter, which is also the starting letter of a codename for that release. For example, the current stable language version is 6.c "Christmas". The next language release will be 6.d with one of the proposed codenames being "Diwali". The version after that will be 6.e, then 6.f, and so on.

If you've used Perl 6 sometime between 2015 and 2018, you likely used the "Rakudo" compiler, which is often packaged as "Rakudo Star" distribution and is versioned with the year and the month of the release, e.g. release 2017.01.

In some languages, like Perl 6's sister language Perl 5, what the compiler does is what the language itself is. Bugs aside, if the latest (2017.09) Perl 5 compiler gives 4 for 2+2, then that's the definition of what 2+2 is in the Perl 5 language.

In Perl 6, however, how a compiler (e.g. "Rakudo") behaves or what it implements does not define the Perl 6 language. The Perl 6 language specification does. The specification consists of a test suite of about 155,000 tests and anything that passes that test suite can call itself a "Perl 6 compiler".

It's to this specification version 6.c "Christmas" refers. It was released on December 25, 2015 and at the time of this writing, it's the first and only release of a stable language spec. Aside from a few error corrections, there were no changes to that specification… The latest version of Rakudo still passes every single test—it's a release requirement.

On Changes

Ardent Perl 6 users would likely recall that there have been many changes in the Rakudo compiler since Christmas 2015. Including the "ouch" change referenced by that StackOverflow comment. If the specification did not change and core devs are not allowed to make changes that break 6.c specification, how is it possible that the return type of .sort could have changed?

The reason is—and I hope the other core devs will forgive me for my choice of imagery—the specification is full of holes!

It doesn't (yet) cover every imaginable use and combination of features. What happens when you try to print a Junction of strings? As far as 6.c version of Perl 6 language is concerned, that's undefined behaviour. What object do you get if you call .Numeric on an Rat type object rather than an instance? Undefined behaviour. What about the return value of .sort? You'll get sorted values in an Iterable type, but whether that type is a Seq or a List is not specified by the 6.c specification.

This is how 2017.01 version of Rakudo managed to change the return type of .sort, despite being a compliant implementation of the 6.c language—the spec was not precise about what Iterable type .sort must return; both Seq and List are Iterable, thus both conform to the spec. (It's worth noting that since 2017.01 we implemented an extended testing framework that also guides our decisions on whether we actually allow changes that don't violate the spec).

In my personal opinion, the 6.c spec is overly sparse in places, which is why we saw a number of large changes in 2016 and early 2017, including the "ouch" change the commenter on StackOverlow referred to. But… it won't stay that way forever.

The Future of the Spec

At the time of this writing, there have been 3,129 commits to the spec, since 6.c language release. These are the proposals for the 6.d language specification. While some of these commits address new features, a lot of them close those holes the 6.c spec contains. The main goal is not to write a "whole new spec" but to refine and clarify the previous version.

Thus, when 6.d is released, it'll look something like this:

A few more slices of new features, but largely the same thing. Still some holes (undefined behaviour) in it, but a lot less than in 6.c language. It now defines that printing a Junction will thread it; that calling .Numeric on a Numeric type object gives a numeric equivalent of zero of that type and a warning; and that the .sort's Iterable return type is a Seq, not a List.

As more uses of combinations original designers haven't thought of come around, even more holes will be covered in future language versions.

Breaking Things

The cheese metaphor covers refinements to the specification, but there's another set of changes the core developers sometimes have to make: changes that violate previous versions of the specification. For 6.d language, the list of such changes is available in our 6.d-prep repository (some of the listed changes don't violate 6.c spec, but still have significant impact so we pushed them to the next language version).

This may seem to be a contradiction: didn't I say earlier that passing 6.c specification is part of the compiler's release requirements? The key to resolving that contradiction lies in ability to request different language versions in different comp units (e.g. in different modules) that are used by the same program.

A single compiler can support multiple language versions. Specifying use v6.c pragma loads 6.c language. Specifying use v6.d (currently available as use v6.d.PREVIEW) loads 6.d language. Not specifying anything loads the newest version the compiler supports.

One of the changes between 6.c and 6.d languages is that await no longer blocks the thread in 6.d. We can observe this change using a single small script that loads two modules. The code between the two modules is the same, except they request different language versions:

# file ./C.pm6
use v6.c;
sub await-c is export {
    await ^10 .map: {
        start await ^5 .map: { start await Promise.in: 1 }
    }
    say "6.c version took $(now - ENTER now) secs";
}

# file ./D.pm6
use v6.d.PREVIEW;
sub await-d is export {
    await ^10 .map: {
        start await ^5 .map: { start await Promise.in: 1 }
    }
    say "6.d version took $(now - ENTER now) secs";
}

# $ perl6 -I. -MC -MD -e 'await-c; await-d'
# 6.c version took 2.05268528 secs
# 6.d version took 1.038609 secs

When we run the program, we see that no-longer blocked threads let 6.d version complete a lot faster (in fact, if you bump the loop numbers by a factor, 6.d would still complete, while 6.c would deadlock).

So this is the Perl 6 mechanism that lets the core developers make breaking changes without breaking user's programs. There are some limitations to it (e.g. methods on classes)—so for some things there still will be standard deprecation procedures. We also try to limit the number of such spec-breaking changes, to reduce the maintenance burden and impact on users who don't want to lock their code down to some older version. Thus, don't worry about getting some weird new language on the next language release—the differences will be minimal.

Who Decides?

This all brings us to one of the questions posed by that StackOverflow user: how do language changes get conceived, considered, and applied—in short: who decides what the behaviour is to be like? What is the process?

As far as conception goes, many of the current ideas are based on seeing what our users need. Some proposals come directly from users; others get inspired as more elegant solutions to problems users showed they were trying to solve. Some of the changes proposed for 6.d language were informed by problematic areas of currently-implemented features that weren't foreseen during original implementation.

When it comes to implementation, the scope of the feature and core developer's expertise with the given area of the codebase generally drive the process. With the "ouch" change, the expert in the area of Iterables deemed Seq to be a superior type for .sort to return, due to its non-caching behaviour as well as its ease of degenerating into a caching List.

Some changes get opened as an Issue on the bugtracker first, to notify other devs of the impending change. Large changes usually get a proposed design written down first. The proposal is shared with the core devs and feedback is gathered before the proposal is actually implemented. The implementation of significant things is also merged far away from the date of the next release, to let the bleeding-edge users find any potential problems in the work.

Geth, our IRC bot, announces all commits in our development IRC channel. Most of the core devs backlog that channel, so any of the potentially problematic commits—even if one of the devs goes ahead and commits the change—get discussed and at times reverted.

The Perl 6 pumpking (Jonathan Worthington) and the BDFL (Larry Wall) are available to provide feedback on controversial, questionable, or large changes being proposed. They also have the veto power on any changes. Our messaging bot helps us request feedback from them, even if they're currently not in the chat.

When it comes to errata to previous specifications, unless the test to be changed is "obviously wrong", the decision on whether the errata can be applied is delegated to the Release Manager (AlexDaniel), and informed by the pumpking/BDFL, if required.

The Future

The current process is a bit loose in places. A test that's "obviously wrong" to one person might have some valid reasons behind it to someone else. This is why the TODO for 6.d release lists several documents to be written that will refine the procedures for various types of changes.

It won't be on the scale of PEP, but simply something more concrete for the core devs to refer to, when performing changes that have some impact on the users. It's a balancing act between organization and procedure and letting through a consistent flow of contributions.

And if breaking changes have to be made, an alert will be pushed to the the P6lert service for users of Perl 6 to get informed of them in advance.

Conclusion

Today, we gleaned an insight into how Perl 6 core devs introduce changes to the compiler and the language.

The language specification and the compiler's behaviour are separate entities. The 6.c language specification has places of unspecified behaviour, which is how changes that have large impact on the users slipped through in the past.

The extended testing framework as well as specification clarifications offered by 6.d language proposal tests that refine the specification and close the holes with undefined behaviour reduce unforeseen impact on the users.

The core dev team informs their decisions based on user's feedback and the way the language is used by the community. Large changes get written up as proposals and the pumking/BDFL offer advise on anything controversial.

In the future, more refined practices for how changes are made will be defined, as we work on making upgrade experience more predictable and non-breaking for our users. The P6lert service helps that goal and is already available today.

Hope this answers all the questions :)

Read this article on Rakudo.Party

Development of Rakudo Perl 6 is quite fast-paced, with hundreds of commits made each month to its five core repositories. Users undoubtedly feel some impact from those commits: bug fixes may break code that relied on them, backend changes may have unforeseen impact on the user code, new useful features may be implemented that users would want to know about.

In the past, for things with very large impact, we made blog posts, but there are lots of small things that fly under the radar, unless you actively pay a lot of attention to Rakudo Perl 6's core development.

To help all of our users to be aware of important issues, we're announcing introduction of P6lert service: tweet-sized alerts from Perl 6 Core Developers.

The Goods

The P6lert service primarily consists of alerts.perl6.org website, but with it come a variety of ways to receive alerts posted on it:

• All alerts are automatically tweeted by unmonitored @p6lert Twitter account; all tweets include #p6lert hashtag
• There is an RSS feed you can subscribe to
• The site offers an API, which you can use in Perl 6 via WWW::P6lert module.
• Command line p6lert script gets you access to alerts from command line and can even be integrated into compiler upgrade scripts.
• An embeddable HTML Widget can show alerts on your blog or any other useful place.

The Content

While we'll make adjustments as we move forward, I foresee most of the non-critical alerts will largely include things that are: (a) more important than simply hoping users-who-care will read about it in the ChangeLog; (b) not as important to warrant a notification blog post.

As a rule-of-thumb, if you picture a user who added p6lert script to their compiler upgrade procedure, the alerts the script will show will inform that user on everything they need to know to perform that upgrade safely.

The alerts are also deliberately length-limited to be easy to process and fast to digest. As they're posted via an IRC bot, the poster has at most about 400 characters to work with.

Each alert has an affects field for it, giving additional info what the alert applies to. I think it'll often be empty, as alerts affecting latest compiler versions imply they affect whatever latest release is at the time alert was posted.

The alerts have a severity rating: low, normal, and high indicating how important an alert is. Along with those, come two out-of-band ratings: info and critical. Info alerts will usually be something the users don't need to act upon, while critical alerts will often simply contain a link to a blog post that details a critical issue.

Of the top of my head, here are some real-life examples from the past and how I'd rate their severity on the P6lert service:

• info - Telemetry implementation. This was a fairly large implementation of a feature in the core and some users may be interested in it. At the same time, they don't have to act on this alert. Rakudo and Rakudo Star release may also be info alert material.
• low - implementation of output buffering on IO handles. Once that was implemented, we noticed some minor fallout in code that assumed lack of buffering. A low-severity alert could notify users about this.
• normal - A real-life normal-severity alert is already posted on the site. During 6.d spec pre-release review, the Str.parse-names method was placed under deprecation and its functionality was moved to live under Str.uniparse. While this method always existed as a 6.d-proposal, it's known to us that some users already use it and an alert will help them ensure their code keeps working past 6.e language release.
• high - a while ago, .subst was briefly made to die if it couldn't write to $/; same as some methods already do. Upon examination of ecosystem fallout, this change was reverted, pending further review. However, were it to stay, a high-severity alert would be in order.
• critical - when we finished work on lexical require, conditional loading of modules many users used was silently failing and the users needed to change their code to correct reliance on the old, buggy behavour. We issued a blog post with upgrade instructions. A critical alert would be a link to this blog post.

That's my vision for host the system will be used, but it'll evolve to suit our needs as more core devs and more of our users start using it. The core dev docs for the system along with code for all the pieces is available in perl6/alerts repo.

Conclusion

As part of improving using user experience, Perl 6 core devs now offer alerts.perl6.org service that will list important information about latest developments in the land of Perl 6. There are numerous ways to consume those alerts, such as an RSS or Tweeter feeds, a command line utility, and an easy-to-use API.

The alerts will come in 5 different severity ratings, indicating their importance. We'll continue to improve the system to best suit our users' needs.

If you have any questions or feedback, you can always talk to the core devs on #perl6-dev IRC chat.

-Ofun

Read this article on Rakudo.Party

If you've been following Rakudo's development since first language release on Christmas, 2015, you might've heard of numerous people working to bring CPAN support to Rakudo Perl 6.

Good news! It's finally here in usable form and you should start using it!

Let's talk about all the moving parts and how to upload your dists to CPAN.

The Moving Parts and Status Report

All of the heavy lifting has been done awhile back, during Perl Toolchain Summit and other times. I wasn't present for it to know the details, but to catch up you could join #perl6-toolchain chat and talk to humans or read the channel log. PAUSE/CPAN support for Perl 6 dists was implemented and zef module installer was trained to check for CPAN dists as well as our GitHub/GitLab-based ecosystem (called "p6c").

The only bit that was left missing is a front-end to browse available CPAN dists. There is a team who wished to take metacpan.org's codebase and modify it for Rakudo dists. I'm told that project is currently "stalled but not dead".

That's unfortunate, however, earlier this week, modules.perl6.org was taught to handle CPAN dists, so—hooray!—we finally have some sort of a front-end for CPAN dists. If you only want to see CPAN dists in search results, you can use from:cpan search qualifier (just like you can use from:github and from:gitlab ones).

GitHub/GitLab dists URLs still direct to repos, but CPAN dists have a file browser that lets you see what files are up in the dist. The file browser also renders README.md/README.markdown markdown readme files.

The viewer doesn't have all the bells and whistles of metacpan.org and doesn't (yet) render POD6, but it's certainly useable. The person who implemented this viewer will be busy preparing 6.d language release in the near future and won't have the time to make additional improvements to the CPAN dist viewer. So… you're invited to contribute and make it better!

Why Upload to CPAN

CPAN has many mirrors ensuring module installation is not affected whenever GitHub (a single website) has issues. The uploaded dists are also immutable and stay there forever (barring special deletion requests, even deleted dists remain available on BackPAN). This means people are more likely to trust these dists for use in their larger projects that need dependable dependencies. Lastly… it's what the cool kids use!

How to Upload to CPAN

Here's the process for how you can get your dists to CPAN. If these dists are currently listed in our p6c ecosystem, both p6c and CPAN versions will appear on modules.perl6.org, and you're encouraged to remove the p6c version. Some of the described tools are brand-new and others are brand-old, created before Rakudo existed, so treat this guide as part information and part invitation to improve the tools.

Step 1: Get a PAUSE account

PAUSE stands for "The [Perl programming] Authors Upload Server", it's located at pause.perl.org, and it's a site you use to upload dists to CPAN.

Go to request PAUSE account page and subscribe for an account. The "desired ID" field is for your PAUSE ID, and it's currently used as "author" field on modules.perl6.org. For example, mine is ZOFFIX.

I had my account for over a decade, so my memory is a bit fuzzy, but I think you'll need to wait for a human to approve and create your account—it's not instantaneous.

Step 2: Make a Dist Archive

You can manually create a tarball or a zip archive. I don't have all the details on which files you're supposed to have in them; you can take a look at other CPAN dists to see what they're doing or…

Use App::Mi6 module! It's possible you were already using it to create dists, in which case you're in luck, as you can just run mi6 dist to make a dist archive.

I rolled my dists by hand and wrote all the docs in README.md, so when I gave mi6 dist a whirl, it replaced my README.md with emptiness because I wasn't using any POD6—something (currently) to watch out for.

Step 3: Upload Your Dist

The first option is to upload manually: log into pause.perl.org, then go to Upload a file to CPAN, be sure to select Perl6 in the select input and then upload either via an uploaded file or a URL.

The second option is to use App::Mi6's mi6 upload command.

Shortly after the upload, you'll get an email about whether your upload succeeded (you can also see emails on nntp.perl.org). Make sure you have a META6.json file in your dist and that the dist version you're uploading is higher than the currently uploaded version. Those are the most common upload errors.

Step 4: Relax and Wait

If you're on IRC, in about 10 minutes after your upload, our buggable robot will announce it:

<buggable> New CPAN upload: Number-Denominate-1.001001.tar.gz by ZOFFIX
    https://www.cpan.org/authors/id/Z/ZO/ZOFFIX/Perl6/Number-Denominate-1.001001.tar.gz

In about 2 hours, the dist will also appear on modules.perl6.org. Its updater is started in a cron job on 20th and 40th minute of the hour (unless a job is already running) and it takes about 2 hours to finish each run.

Step 5: Celebrate with the Appropriate Amount of Fun

That's about it to the process. I foresee more tools will be created in the future to make the process even easier than it is today. If you have any questions or issues, just talk to a human or a robot on our #perl6 IRC channel.

Conclusion

CPAN support for Rakudo Perl 6 dists is now usably here. You're encouraged to upload your dists to CPAN, to grow a more dependable ecosystem. You're also invited to improve and create tooling that manages and displays CPAN uploads.

-Ofun