Patrick:
Allison:
Patrick:
Allison:
c:
Allison:
c:
Allison:
Jerry:
c:
Jerry:
Larry:
$*DEFIN, $*DEFOUT, $*DEFERR symbols which emulated Perl 5's old IO select states$*IN, $*OUT, $*ERRYOU_ARE_HEREtighter and looser precedence generators only produced precedence levels that were close to one that existsc:
betweenLarry:
Instance and Durationc:
Larry:
c:
Larry:
.. operator in square bracketsif() as a function callCALLER:: or CONTEXT::term symbols, as well as prefix, infix, and postfixc:
Jerry:
Setting work this weekSetting?Setting?OUTER::Setting?Larry:
CORE:: and so forthJerry:
-n, could I close the handle in CORE::?Larry:
$*ARGV equivalentJerry:
Setting I'm currently in?Settings I have loaded?Larry:
CORE:: has a namec:
Larry:
Jerry:
Patrick:
Jerry:
Patrick:
Allison:
Patrick:
Setting code now, and features written in Perl 6, we're closer to finishing one of my milestonesJerry:
Allison:
Jerry:
Allison:
doc or libPatrick:
Allison:
Jerry:
Allison:
Larry:
A::B, it added A as a subpackage$! as a parameterdo/while or do/until it now complainsif or one of the keywords as if it's a function, it tells you what the problem is without saying "I don't recognize that function name"1.. to get an indefinite range:: to signify an anonymous package name or typeis without ambiguityMain package; combined it with the GLOBAL packageGLOBAL namespacePatrick:
Larry:
PROCESS namespace, not the GLOBAL namespace.Whatever on most normal operators builds a closure of one argument*.method do the same thing*.prime in a grep for example.prime in the curlieswhens and ~~ so you have to say *.foo to call a methodPatrick:
Setting codeSetting codeAllison:
Patrick:
Allison:
Patrick:
Allison:
c:
Nicholas:
c:
Jerry:
c:
Allison:
Patrick:
c:
Nicholas:
c:
Nicholas:
package; with no namespaceLarry:
Patrick:
Jerry:
Patrick:
Allison:
Patrick:
Larry:
Patrick:
Larry:
Allison:
c:
Allison:
Patrick:
Jerry:
c:
Jerry:
c:
Allison:
c:
Nicholas:
Jerry:
c:
Jerry:
c:
Patrick:
my ($, $, $, $four) = 1..4;
my ($one, $two, *@) = 1..4;
To only assign some things. Note that *@ is just the slurpy array * - it's a
signature (and in fact you would now be able to write *@ in a signature on a sub
too).say "a".."c" Z "?", "a".."b"
Gave the wrong output and reported it. bacek sent in a patch. Mortiz wrote a test.
Which just left me to review and apply the patch and untodo the test. Teamwork for
the win.Additionally, I tracked down where the perl6 executable often crashes with a double free or got into an infinite loop on exit (it was a problem that only showed when using the executable, and not when using the bytecode file on Parrot - not because the problem wasn't there, but because Parrot didn't bother to reclaim the memory on exit so it never ran the cleanup code that exploded). I wrote a patch which sucked, but prevented the double frees. I showed it on #parrot, at which point pmichaud - now knowing where in Parrot the problem lay - churned out a much smaller patch that was more correct and more efficient. It's in, we bumped up the recommended Parrot version for Rakudo and I closed some tickets about segfaults.
So, thanks to Vienna.pm for sponsoring Rakudo Day this week. There won't be one next week, since I'll be taking some vacation. This weekend is the Belgian Perl Workshop, and the weekend after is the Ukrainian Perl Workshop, so I'm going to spend a bit of time in each of those countries between them, relaxing and enjoying the sights, the beer and the food. And of course, very much looking forward to seeing folks and talking about Perl 6 and Rakudo at the workshops too!
]]>+ and * twigils* twigilPatrick:
parrot perl6.pbc — is confusing for folkspbc_to_exe took an inordinately long time to do its workJerry:
-E to include an environment variablesplit/comb update quite right yetc:
Nicholas:
Jerry:
Nicholas:
Jerry:
Patrick:
c:
Patrick:
Jerry:
Patrick:
After Patrick told me The Plan that he'd worked out for this, I dug in to doing the grunt work. The first task was to split the compilation into two steps: first, compile the core of Rakudo, then use that to compile the Perl 6 prelude, then bundle the two together to get the final Perl 6 compiler. It turned out that this step was fairly easy. We'd done plenty of work leading up to this to provide features that would make it possible, so within a couple of hours I had the changes to make this work comitted. The first two Perl 6 methods in the prelude were .perl and .ACCEPTS on the class Whatever - easy, for sure, but enough to prove the concept.
I thought things were looking good - but then it all came to a screeching halt when I discovered that because of the way we were building things, we were ending up with duplicates of some things that were supposed to be unique per compilation unit. Happily, Patrick jumped on the PCT changes required to fix this one up while I had dinner and did some shopping, and when I was back from all of that I was able to continue porting a few more things over to Perl 6. It's a start, but of course there's a long way to go yet. Help is very welcome - I really do hope this will help more people to get involved with Rakudo, since now you don't have to learn PIR to write built-ins!
As well as working on the setting, I dealt with a few RT tickets, to pull our queue back under the 250 mark that it had sneaked above again.
Thanks to Vienna.pm for funding my work on Rakudo today.
]]>Allison:
Jerry:
Larry:
!= isn't a separate token! metaoperator[], the same form as reduce operators&[] now refers to the infix function itself-n and -p loops put a scope around the scope of your filePERL is the outermost setting as well as LANG for the sublanguage the file is actually parsed in (such as from -n or -p)R operatorX operator lost its second X to work the sameZ for a zip with operationWill:
Patrick:
c:
Patrick:
c:
Nicholas:
Patrick:
Nicholas:
c:
Anyway, here's a list of the things that got fixed.
class A {
has $.x;
method nothing { $.x == 0 }
method large { $.x > 100 }
};
for 0,100,200 -> $x {
say "Considering $x";
given A.new(:$x) {
when .nothing { say "nothing" }
when .large { say "large" }
}
}
Output:Considering 0
nothing
Considering 100
Considering 200
largeI have also reviewed quite a lot of tickets, and closed quite a few that related to issue that had now been fixed (either as a side-effect of fixing other tickets, or thanks to ongoing development). Between the fixes on this Rakudo Day and the one earlier in the week (along of course with the input and help of others) we have gone from over 270 tickets on Wednesday morning to 245 tickets now. So while we've some way from the more manageable size of queue that I'd like - one that I can review fairly quickly and mostly keep in my head - we're some steps closer. :-) Thanks very much to Vienna.pm for funding this work.
]]>The first bug I fixed today was one related to proto-object definedness. They are meant to be undefined, something which I accidentally broke in dispatcher changes a while back and that, oddly, was untested. So I fixed that and added tests to make sure we don't regress on it again.
Next up was a more subtle one.
class A {
has $.b;
};
while shift [A.new( :b(0) )] -> $a {
say $a.b;
my $x = $a.clone( :b($a.b + 1) );
say $a.b;
last;
}
Clearly, the output should have been two zeroes, but it was giving zero and one - the original object was being modified. The cause was that we were getting some (internal) reference chains, and clone was only dereferencing one level, so we didn't properly clone the object after all. I ripped out the custom dereference code and put in a call to !DEREF, which does the Right Thing. So now clone is shorter and also fixed, at least in this aspect. I added something very much like the above as a test case.
In fact, we have some wider issues with clone in Rakudo. We can directly call Parrot's clone v-table method on things, but since it doesn't know about ObjectRef chains, that doesn't always work out so well. This example:
sub foo($a) { say $a .. 5 }
foo(5)
Gave a warning and no output before I fixed it; the fix was making postfix:<++> (and I did postfix:<--> while I was at it) call .clone() rather than directly using Parrot's clone v-table. I found that this fix also fixed one of our integration tests.
I then moved onto some work to incorporate various bits of STD.pm error checking to make things that should die at parse time do so. Therefore, the following, all of which actually parsed and did weird things at runtime, no longer do so:
my DoesNotExist $x;
regex Foo {}; # Empty regex not allowed
regex Foo = { bar }; # Should barf on the = sign, now we do
Dealing with these allowed to to resolve a few RT tickets.
I then moved onto a couple of tickets about grammars. One of them reported a hang instead of an error message if you invoked .parse on a grammar that had no TOP rule. I corrected that, and also implemented .parsefile, which slurps the passed filename and invokes the TOP rule of the grammar on that. Since pmichaud++ had already done .parse, that was pretty trivial. I added some tests for both methods, including one covering the hang, to the spectests too.
We've been getting readonly variables right for a while mostly, but we still didn't catch modifications through ++ and --. I put in a fix for that, and then realized that some tests for <-> (the lambda that makes things rw by default) were now failing, since they had worked "by accident" before rather than through <-> being implemented. So I implemented that also, and - after pmichaud++ pointed out a corner case - tweaked it to handle those and added more tests.
There were a couple of bug reports relating to optional parameters which had type constraints. When the parameter was not passed, they failed the type check. One was about positional parameters, another about named. Happily, there was a single fix that dealt with both cases. I unfudged a few existing tests for the positional optional typed case, and wrote some for the named case since I didn't find any existing spectests for that.
We've been adding lots of compile-time detection of bad stuff of late. One that was missing was checking that if you "is also" a class that doesn't exist, it should complain. So I fixed that and added a test.
Throughout the day, I've also closed up a few other tickets that were already dealt with, but hadn't been closed. So, a busy day. Thanks go to Vienna.pm for funding all of this. Happy hacking, and keep those bug reports coming in! :-)
]]>First, I'd like to thank Vienna.pm. After funding a great deal of my Rakudo hacking last year, they have kindly agreed to continue the arrangement into this year, which is funding me a day a week. I expect that due to attending workshops there will be some weeks I miss and others that I will do two days, but it should come out to a day a week on average. So, a big thanks to Vienna.pm! I plan to use some of the initial days to go through RT and try to cut down the number of tickets there, most of which are bug reports. It will be a nice complement to my Hague Grant, which is mostly focused on feature development (though implementing those has of course been closing existing tickets, and I've been doing other bits on RT tickets too - but having time I can dedicate to fixes and improving the quality of Rakudo in a wider sense is great).
I am writing this from Sophia in Bulgaria, where I've been attending the first Bulgarian Perl Workshop. It's been a wonderful time for many reasons - not least because of the hospitality of the Bulgarians I have met during my time here. Marian has been especially wonderful, taking me out the day after the conference to see the beautiful mountains and a stunning monastery. I enjoyed speaking too - the room was full and there were lots of good questions, which always makes it much more fun and helps me feel that people are getting it. So, to all who organized the conference and to all those I met and talked with - thanks for making this a great time.
My Hague Grant is going well. In the world of parametric roles, I've done a range of enhancements to make sure you can use type parameters as types in the places you'd expect, and written more tests, plus have done some minor fixes that were needed to let us have roles parameterized on parameterized roles, so you will be able to build nested typed data structures. I also implemented the "of" keyword, and made roles pun to classes if you tried to instantiate them. This actually puts me well ahead of schedule so far as parametric roles go. My remaining work for during February mostly consists of using it to make typed arrays and hashes work. I plan to implement these directly in Perl 6 so far as I can, with some bits of inline PIR here and there. They won't be usable until we have the Perl 6 prelude, but that is high on pmichaud++'s schedule to work on too, so I hope we'll have that before February is out.
The other big-ticket item I've now done is junction auto-threading. For now, we still have the custom code in place to thread operators, and auto-threading for built-in functions and methods does not yet work, but again once we get the Perl 6 prelude in place they will also Just Work based upon what I've already done and the custom code can go away. I've done various tests to make sure auto-threading with multis works out nicely, that we auto-thread over the invocant during method calls (to methods not defined in Junction). I will write a more detailed post on junction auto-threading shortly.
I've done a few other bits, too. The handles trait verb will now accept pairs, a class or role name, a regex or the Whatever *. (In fact, the rule is that it's just a smartmatch with the method name as the topic, so regex and * fall out of the same code, and I'm sure folks will come up with other delightful things to write there). I am missing the s/// variant, since we don't parse that yet in Rakudo and I'm not quite sure yet how to do it. But otherwise, that's the handles work about done too, I think.
I also did some improvements to let us write nested classes, though there's some way to go on that. Further, declaring a proto makes all subs of the same name not marked multi be multis, and this works for upgrading methods to multi-methods too when composing roles if there is a proto in the class (in fact, composing roles that had multis in them before didn't work properly, since a Parrot addition was needed; I did that as part of this work, and added Parrot tests for it as well as then doing the Rakudo bits on top). Finally, I've added redeclaration of types detection at compile time, plus a better error if you try do inherit from a non-existent class or do a non-existent role.
So, quite a list of things that have got done, which is nice. :-) And lightens the load a bit for me in February, so I'm optimistic that I am going to be able to complete my Hague grant on schedule. Well, hopefully I didn't just jinx it...
]]>Larry:
Allison:
make htmlWill:
Patrick:
Jerry:
c:
Jerry:
inf or INFInf?Larry:
Patrick:
Larry:
Patrick:
Infinf, do we get zero or infinity?Larry:
Larry:
Patrick:
Allison:
Patrick:
Jerry:
Allison:
make install-related codec:
Patrick:
Larry:
for loopPatrick:
Allison:
Larry:
.contains method, that was standing in for the .exists modifier on hash lookups in a hash.Patrick:
Allison:
Patrick:
Allison:
Patrick:
Will:
Nicholas:
Richard:
Nicholas:
Richard:
Jesse:
Patrick:
Jesse:
Allison:
Jesse:
Allison:
Jesse:
Richard:
Jesse:
Larry:
Richard:
Jesse:
Patrick:
Allison:
Patrick:
Jesse:
Allison:
Jesse:
Missing a discussion on Nicholas: Patrick: Larry: Larry: Patrick: Larry: Patrick: Larry: Patrick: Larry: Patrick: Larry: Patrick: Larry: Patrick: Larry: Will: Patrick: Larry: Patrick: Will: Larry: Jerry: Patrick: Larry: Patrick: Larry: Jerry: Larry: Patrick: Larry: Patrick: Larry: Jerry: Patrick: Larry: Jerry: Larry: Patrick: Larry: Patrick: Larry: Patrick: Larry: Jerry: Larry: Jerry: Larry: Jerry: Larry: Jesse:.trim and gilding the lily.
.trim is not a Perl 5 built in
.perl means.
.perl a sub?
.perl and subs was "Do we have to do that?"
.*?, as opposed to greedy, which would be .* behavior
? qualifier lazy
-n and -p
rn had one of those
]]>
Larry:
Jerry:
c:
Patrick:
:lang option to eval, where you can run a language other than Perl which Parrot understandsJesse:
Patrick:
Jerry:
eval right now and not usePatrick:
Jesse:
Patrick:
Jerry:
Patrick:
Allison:
Jesse:
Allison:
In Perl 6, roles can take parameters. Roles exist to enable greater re-use of code than we could get through having plain old classes, and by allowing them to be parameterized we open the door to even more re-use. Taking a simple example, imagine we wanted to factor out a "greet" method into a role, which takes somebody's name and greets them. We want to parameterize it on the greeting.
role Greet[Str $greeting] {
method greet() { say "$greeting!"; }
}
class EnglishMan does Greet["Hello"] { }
class Slovak does Greet["Ahoj"] { }
class Lolcat does Greet["OH HAI"] { }
EnglishMan.new.greet(); # Hello
Slovak.new.greet(); # Ahoj
Lolcat.new.greet(); # OH HAI
Similarly, we could do a role for requests.
role Request[Str $statement] {
method request($object) { say "$statement $object?"; }
}
class EnglishMan does Request["Please can I have a"] { }
class Slovak does Request["Prosim si"] { }
class Lolcat does Request["I CAN HAZ"] { }
EnglishMan.new.request("yorkshire pudding");
Slovak.new.request("borovicka");
Lolcat.new.request("CHEEZEBURGER");
Sadly, the Slovak output sucks here. Borovicka is the nominative form of the word, and we need to decline it into the accusative case. But some languages don't care about that, and we don't want to have to make them all supply a transform. Thankfully, you can write many roles with the same short name, and a different signature, and multi-dispatch will pick the right one for you. So we write something to produce the accusative case in Slovak and pass it in. Here's the new code.
role Request[Str $statement] {
method request($object) { say "$statement $object?"; }
}
role Request[Str $statement, &transform] {
method request($object) {
say "$statement " ~ transform($object) ~ "?";
}
}
module Language::Slovak {
sub accusative($nom) {
# ...and before some smartass points it out, I know
# I'm missing some of the masculine animate declension...
return $nom.subst(/a$/, 'u');
}
}
class EnglishMan does Request["Please can I have a"] { }
class Slovak does Request["Prosim si", &Language::Slovak::accusative] { }
class Lolcat does Request["I CAN HAZ"] { }
EnglishMan.new.request("yorkshire pudding");
Slovak.new.request("borovicka");
Lolcat.new.request("CHEEZEBURGER");
Which means we can now properly order our borovicka in Slovakia, which is awesome. Until you do it in a loop and find the Headache['very bad'] role got mixed into yourself overnight, anyway...
I'll post more on the other bits I'm working on, or have worked on, soon. But parametric roles are the biggy. I'm not at all finished with them yet, but all of the code examples I gave here today now work. :-)
]]>By "infrastructure" I'm primarily referring to the following items:
Currently these things are spread in many different locations with different tools, and while I don't believe it's necessary for them completely unified, we should at least aim to reduce the overall complexity of what we do have so that we can better serve those who are interested (or are yet to become interested) in Rakudo Perl. In fact, it may be that in many cases we'll keep what we have now, but at least it'll be a confirmed decision instead of simply going along with what we've had in the past.
Also, I'm sure it will be easy and tempting to address larger issues about Perl 6 as a whole (as opposed to just "Rakudo"). I'm not at all opposed to seeing that larger discussion take place, but for my purposes I'll be tending to focus on Rakudo's immediate needs.
Here's my off-the-cuff inventory of where things are in Rakudo today and where things might head. It's entirely possible that my description below misunderstands or misrepresents reality in some areas -- but I'm dedicating this week to resolving that. Indeed, that's the primary purpose of this message, to help us all clear up confusion surrounding Rakudo (and Perl 6).
Source code repository
This is the immediate issue at hand, because we need to move Rakudo out of the Parrot repository so that it can cleanly move to its new home at parrot.org. Currently Rakudo Perl lives at http://svn.perl.org/parrot/trunk/languages/perl6/ , while the spectest suite (on which development/testing depends) lives at http://svn.pugscode.org/pugs/t/spec/ .
Many people have strongly suggested that we switch to using "git" as our version control system. At the moment I'm neither strongly in favor of nor strongly opposed to switching version control systems, but we have to recognize that at least two of Rakudo's "dependencies" (Parrot and the spectest suite) are using Subversion and are likely to remain that way for a while. We don't want to require non-developers to install a lot of different source code control systems simply to run and test the latest incarnation of Rakudo Perl.
I have a lot more comments on source code management for Rakudo Perl, but to keep to the "overview" nature of this post I'll save the rest for a longer post. Feel free to start submitting your opinions, however!
Web site / blog / wiki
Currently Rakudo really does not have a dedicated website providing basic information about it. There is the http://rakudo.org/ site, but it's currently more of a blog than a true web site. For example, someone visiting rakudo.org would not be able to easily find out how to download and run Rakudo Perl.
Here's what we do have at the moment (as best as I can recall):
Also, for the record, I currently own the "rakudoperl.org" and "rakudoperl.com" domains, so if we want to do something somehow separate from any of the existing domains cited above, we can use those domains, and I may have (or be able to acquire) additional server resources to support it.
Issue tracking
Currently issue tracking for Rakudo is being done using RT at http://rt.perl.org/ (the same RT instance that does Perl 5 bug tracking). In the past I've stated that Rakudo bugs will continue to use this tracker, and I'm still planning for that to be the case, but in recent weeks I've encountered a number of times were rt.perl.org was too slow/unreachable to be an effective tool. I'm not (yet?) advocating that we switch to a different issue tracker, but since we're looking at the whole of infrastructure items I did want to leave the possibility open for discussion.
Mailing list
Currently Rakudo's primary mailing list is <perl6-compiler@perl.org>. I see no major reason to change anything here, as it works well and is a good companion to the other "official" Perl 6 mailing lists.
----------
Throughout all of this, I'm looking at things from a very practical perspective -- i.e., what can we achieve with the resources currently at our disposal. It's also important to consider the needs of the various audiences -- not only the Rakudo developers, but also people who want to experiment with Rakudo and those who want to start building applications for it. So, we need to keep in mind the many perspectives on the issue as we go through the discussion.
Also, I'm expecting that some of the decisions I eventually make may disappoint some; apologies in advance, but such is the nature of decisions.
With that background in place, I'll now (with great trepidation) open the discussion for others to comment and/or make suggestions of what they'd like to see changed about the way we currently manage Rakudo Perl.
Thanks in advance,
Pm
]]>