Re: r31789 -[S32] DateTime immutable, leap seconds validation
Hi, Am Freitag, den 23.07.2010, 11:50 +0100 schrieb Nicholas Clark: On Thu, Jul 22, 2010 at 11:54:10PM +0200, pugs-comm...@feather.perl6.nl wrote: It shouldn't be too hard to write a Perl 5 script, to be run as part of Rakudo's build process, that automatically updates the leap-second table in tai-utc.pm. Dogfood failure. That should be a Perl 6 script. Been there, done that :) See http://trac.parrot.org/parrot/ticket/619 Yes, really, I'm serious about this, and the importance of this. Whilst Perl 5 isn't self-hosting, it builds a perl interpreter as early as possible and uses that for the rest of the build system. This a: makes it easier for more end users to be able to fix things that hurt them, increasing the pool of potential core contributors b: ensures that the core contributors are end uses of the language they maintain I think one weakness of Parrot is that it uses almost no Parrot-based language in its own build system. You need to know Perl 5 or C to be useful to the Parrot core. And if you gain your fun by working on the Parrot core, you actually stop being a Parrot user, and hence experiencing what they experience. Have a look at nqp-rx + kakapo + plumage + proto/PLS for some examples where you can help without any C or Perl 5 knowledge: http://gitorious.org/parrot-plumage http://gitorious.net/kakapo/kakapo http://github.com/masak/proto/tree/pls And not to forget, the growing list of Perl 6 modules, where help is of course always highly welcome: http://modules.perl6.org/ Have fun, Raphael.
Re: You never have privacy from your children in Perl 6
Am Dienstag, den 23.03.2010, 20:06 +0100 schrieb Moritz Lenz: Carl Mäsak wrote: Carl (), Moritz (): masak um, so 'protected' is when the deriving classes can see the attribute? jonalv yup masak that's what 'private' means in Perl 6. That's wrong. Perl 6's private is like Java's private - subclasses can't see it. It's just Rakudo being leaky at the moment, not a fallacy of the Perl 6 language. (Yes, we have failing tests for this; no, we don't run them at the moment). That is indeed reassuring. Thank you. ...So, how come Perl 6 doesn't have a 'protected' access level? :) In Perl 6, you can use private attributes in submethods, so protected is not so badly needed. Exactly for the reasons you brought up against 'protected' as a default: in encourages people to inherit from a class just to bypass some of the public API. Apropos: I found the chapter about class declarator enlightening: http://www.dlugosz.com/Perl6/web/class-declarators.html (If some parts are not up-to-date, I would be happy to ear it.) Cheers, Moritz Ciao, Raphael.
Re: How does List.map: { .say } work?
Am Montag, den 02.11.2009, 14:33 -0500 schrieb Solomon Foster:
On Mon, Nov 2, 2009 at 2:03 PM, Solomon Foster colo...@gmail.com wrote:
On Mon, Nov 2, 2009 at 10:21 AM, Carl Mäsak cma...@gmail.com wrote:
Solomon (), Moritz ():
the current spec doesn't allow immutable containers to call .map with a
block that implicitly uses $_ as an implicit parameter.
Here's why:
S06 says
The C$_ variable functions as a placeholder in a block without any
other placeholders or signature. Any bare block without placeholders
really has a parameter like this:
- $_ is rw = OUTER::$_ { .mumble }
So $_ is marked as rw, which is checked at binding time.
Now lists are immutable, meaning that you can't bind a list item rw, so
even if the block doesn't try to modify $_, calling the { .say } block
fails.
(Note that 'for' has the same problem)
How should that be resolved? Should a temporary variable be created that
can be changed, without any effect? or should it fail() on detecting a
modification? Somehow this approach seems very backward to me...
Is there a reason $_ is readonly isn't a possible solution?
For one thing, then you couldn't do this:
my @a = 1, 2, 3;
for @a {
++$_;
}
I meant, make it readonly if the container being iterated over is
readonly. We're working hard to make the language prefer immutable
things, it seems very odd to short circuit that in a key area like
this...
(Though personally, I would prefer it if map was readonly by default
on all containers.)
Or Larry could just find an elegant way to do it. Yay!
FYI: Larry already found that correcting the Spec was the most elegant
solution ;)
Author: lwall
Date: 2009-11-02 17:31:00 +0100 (Mon, 02 Nov 2009)
New Revision: 28973
Modified:
docs/Perl6/Spec/S06-routines.pod
Log:
[S06] correct $_ placeholder binding from rw to ref, moritz++
Re: Aliasing methods in CPAN roles
Am Montag, den 19.10.2009, 16:43 -0700 schrieb Jon Lang: Raphael Descamps wrote: I personally don't understand why we don't have a exclude and alias operator in Perl 6 but I have not read all the synopses and don't have an overview. I don't think that it's explicitly spelled out anywhere; but the reason is fairly straightforward: exclude and alias would break the interface. You're of course right! It's clearly explained in Apocalypse 12 (Conflict Resolution): A role without implementation degenerates to an interface. I don't know why but I didn't realised before that not implementing exclude and alias was in fact an important design decision: I have probably read to much traits papers and not enough Apocalyses ;) On one side you lose flexibility to resolve some composition conflicts but the fact that a role also define a contract is of course a big win, particulary for a language like perl 6 supporting optional statical typing. The traits paper only focus on dynamic typing. It also explain why perl 6 as a so strong support for delegation, as it is the proposed way to solve composition conflicts. It's time to read Apacalyse 12 again as I am now able to anderstand it :)
Re: Aliasing methods in CPAN roles
Am Freitag, den 16.10.2009, 10:54 +0400 schrieb Richard Hainsworth: Arising out of Freezing Roles is a related question. Suppose I download a module from CPAN with a role I want to use, but it introduces a method that I want that is in conflict with an existing method (say one taken from another CPAN module). How should the method be aliased to prevent it from causing a conflict at class composition time? I personally don't anderstand why we don't have a exclude and alias operator in Perl 6 but I have not read all the synopses and don't have an overview. In the thread Re: YAPC::EU and Perl 6 Roles in last july I already said the following: ---snipp--- The brilliant idea with traits is that it bring back the control to the class consuming the trait and conflicts have to be solved explicitly. The traits paper propose 3 different operators to solve such conflicts: overriding, excluding or aliasing. I definitively think that perl 6 roles should also have an excluding operator because I think that *every* composition conflicts arrising should be solvable by the class comsuming the role. ---snapp--- As a side note, Johnatan give us a example about how to make an alias with user defined traits, but it doesn't help here because a trait is bound to a definition: http://use.perl.org/~JonathanWorthington/journal/39504 My anderstanding is also that that kind of aliasing as defined with a trait is deep: If you alias a recursive method, the call will be done to the aliased one (or am I wrong?). In the original traits paper the aliasing is not deep: to respect the flattening property, the semantic of the role must not change, so aliasing a recursive method will call the original method. It's a known theoretical weakness of the traits paper and freezing roles try to solve this problem. Finally, the interaction between module and role is also interesting and it's not clear to me how Perl 6 solve it: I send a question this August to the mailinglist but sadly had no reply, see Perl 6 modules and classboxes?: ---snipp--- As Perl 6 will be supporting multiple versions installed of the same module and also support import with lexical scoping, I was asking myself if it was possible to combine some of the interresting properties of classboxes like local rebinding, flattening property and the idea that import takes precedence over inheritance. I am absolutly not sure if it fit to the Perl 6 module concept as a whole, but I will be happy to read your comments and what you think about it. A few pointers: classboxes+traits introduction: http://scg.unibe.ch/archive/papers/Berg05dTraitsClassbox.pdf For an in depth description, you can also read the Ph.D. thesis: http://scg.unibe.ch/archive/phd/bergel-phd.pdf To develop the classbox concept, the autors also introduced a module calculus, which also help to describe the difference existing beetween different modules systems: (such a module calculus can also help to better anderstand the interaction beetween different languages): http://scg.unibe.ch/archive/papers/Berg05cModuleDiversity.pdf ---snapp--- Raphael
Re: Cobra Ioke Programming Languages
Also any thoughts on implementing Perl 6 on LLVM? Well, the planning is already under way... Parrot want to eventually use LLVM as one of the possible backend: http://wknight8111.blogspot.com/2009/09/first-steps-on-jit-overhaul.html At the moment, it is targeted for the 2.6 release: https://trac.parrot.org/parrot/report/14 Bye, Raphael.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
Am Mittwoch, den 16.09.2009, 10:30 +0200 schrieb François Perrad: 2009/9/16 Carl Mäsak cma...@gmail.com: Tim (), Raphael (): Some XML related stuff: XML parser: http://github.com/fperrad/xml/ No Perl6. Only Parrot PCT. Yes, I know. But your XML grammar is Perl 6 syntax anyway ;) If you want pure Perl6, here is an other small example: http://github.com/krunen/xml But as it stand now, it's more a stub. It show that PGE is now mature enouth to start hacking on an XML Grammar close to the W3C Spec. Raphael. François Perrad Tree manipulation: http://github.com/wayland/Tree/tree/master Thanks. Any reason they're not known to proto? The latter I wasn't really aware of. It's now added to the list, and wayland has been given a proto commit bit. The former, while apparently a nice effort, doesn't contain any Perl 6 code as far as I can see. // Carl
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
Am Dienstag, den 15.09.2009, 16:46 +0200 schrieb Carl Mäsak: Tim (), Carl (), Tim (): I'd be grateful for feedback on any of the slides, but I'm especially interested in updates for: page 73 - Perl 6 implementations I've added Mildew, with links, to the SMOP line anything I should add / change / remove? What's the status of KindaPerl6? I think Elf could very well be added to those. page 77 - quantity of code writen in Perl 6 are there any other significant perl6 codebases? Again, Elf is a nice, large example. :) Got a url? (I've not been keeping up with perl6 as much as I'd like) This one here seems a good introduction: http://perl.net.au/wiki/Elf. Depending on what you mean by significant, I'd also like to direct your attention towards SVG::Plot, proto, Gamebase, CSV, Druid, Form, HTTP::Daemon, Perl6::SQLite and Web.pm. All of those can be downloaded via proto. I'd really appreciate a list of significant perl6 projects, with a few words of description of each, that I could put on a slide. (Similar to the Many gems on CPAN ... on page 18.) The goal being to give a sense that there are significant projects being implemented in perl6. The list I gave above was my subjective, somewhat hasty traversal of projects.list, filtering on what I consider significant (meaning that people use it today or it holds some promise). Here's the same list, with a one-sentence (also subjective) description of each project: Some XML related stuff: XML parser: http://github.com/fperrad/xml/ Tree manipulation: http://github.com/wayland/Tree/tree/master SVG::Plot Draw bar charts, line charts and pie charts in SVG. proto Install Perl 6 projects, painlessly. Gamebase Create games with animated 2D sprites. CSV Read .csv files. Druid Play a connection game which grows upwards. Form Format text nicely à la Exigesis 7. HTTP::Daemon Make a web server. Perl6::SQLite Interact with an SQLite database. Web.pm Create web applications with powerful tools. It's entirely possible that I've forgotten some important module above, so don't hesitate to pipe up if one comes to mind. // Carl Raphael.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
A few other interesting metrics could be for example:
* Work done on the Specification (Synopses):
svn log docs/Perl6/Spec/
* TimToady hacking ;)
svn log src/perl6/
svn log src/perl6/STD.pm
* Work done on the Official Testsuite:
svn log t/spec/
* Work done on the Testsuite:
svn log t/
(It's interresting to compare it with the developement of the
specification as the correlation are obvious and it also show the Pugs
contribution)
Please note that the parrot commit curve seems to have slow down a
little lately...
It's because the parrot HLL languages have left the nest :)
page 80 - graph of parrot commits and releases
I don't have a url for that graph. Do you?
Is it maintained? Can anyone update it for me?
In the Pugs Repository there is the 4 years old util/svnlog2graph.pl,
but beware because it is buggy and not delivering correct results:
(the dayify function and developers counting are both buggy...)
On the old wiki there is a somewhat newer Version of this file as
attachment but it has the same bugs:
http://www.perlfoundation.org/parrot/index.cgi?search_term=svnlog2graph.plaction=search
An other old file delivering some statistik is parrot_dev_stat.pl:
http://www.perlfoundation.org/parrot/index.cgi?search_term=parrot_dev_stat.plaction=search
(The parrot repository have moved but otherwise it seems to works, I
don't know if the results delivered are accurate)
Here a proposed fix for the version of svnlog2graph.pl found in the pugs
repository:
Index: util/svnlog2graph.pl
===
--- util/svnlog2graph.pl(Revision 28206)
+++ util/svnlog2graph.pl(Arbeitskopie)
@@ -1,7 +1,7 @@
#!/usr/bin/perl
# Creates a statistic of Pugs' development.
-# Usage: svn log | util/svnlog2graph.pl /tmp/graph.png --or
-#svn log /tmp/log; util/svnlog2graph /tmp/log
/tmp/graph.png
+# Usage: LANG=C svn log | util/svnlog2graph.pl /tmp/graph.png --or
+#LANG=C svn log /tmp/log; util/svnlog2graph /tmp/log
/tmp/graph.png
use warnings;
use strict;
@@ -23,10 +23,12 @@
INFO
# Read the logfile
-while() {
+my @lines = reverse ;
+foreach my $line (@lines) {
+#while() {
# Only process headlines
- next unless m/^r/ and m/lines?$/ and m/\|/;
- my ($dev, $date) = (split / \| /)[1, 2];
+ next unless $line =~ m/^r/ and $line =~ m/lines?$/ and $line =~
m/\|/;
+ my ($dev, $date) = (split / \| /, $line)[1, 2];
$date =~ s/ [+-]\d+ \(.*$//;
# Example: $date is now 2005-02-06 17:52:06
@@ -36,10 +38,6 @@
$num_commits++;
}
-# $commits[0] should be first commit, not last
-...@commits= reverse @commits;
-...@developers = reverse @developers;
-
# Collect commits in days
# E.g. $commits_till_day[42] = 1500 (1500 commits from day 1 to day 42)
my @commits_till_day = dayify(@commits);
@@ -52,17 +50,22 @@
# Create the graph.
my $graph = GD::Graph::lines-new(500, 350);
$graph-set(
- title= Pugs development,
+ title= Perl 6 development,
x_label = Days,
- y_label = Commits/Developers,
- x_label_skip = 10,
- y_max_value = (int(@commits / 500) + 1) * 500,
+ two_axes = 1,
+ use_axis = [1,2],
+ y1_label = Commits,
+ y2_label = Developers,
+ x_label_skip = 365,
+ logo = misc/camelia.jpg,
+ logo_resize = 0.1,
+ logo_position = UL,
) or die $graph-error;
my @data = (
[ 0...@commits_till_day ], # Day#
[ 0, @commits_till_day ], # Commits
- [ 0, map { 50 * $_ } @devs_till_day ], # Developers (scaled)
+ [ 0, @devs_till_day ], # Developers
);
my $gd = $graph-plot(\...@data) or die $graph-error;
@@ -80,9 +83,8 @@
if($cur_day != $#till_day) {
push @till_day, $till_day[-1] || 0
while $#till_day $cur_day;
-} else {
- $till_day[-1]++;
}
+$till_day[-1]++;
}
return @till_day;
Perl 6 modules and classboxes?
Hi, In the last few months, I tried to anderstand better Roles aka statefull traits, so I read differents traits papers about it. From the same research group, I also read about classboxes and found the concept interresting, particulary when combined with traits (roles). Please note that I am not a computer science guy, so I anderstand more or less the concepts but not the mathematical formal description. I tried to read the Synopse S11 and how modules will be working in Perl 6: to be honest I still not really anderstand it :) As Perl 6 will be supporting multiple versions installed of the same module and also support import with lexical scoping, I was asking myself if it was possible to combine some of the interresting properties of classboxes like local rebinding, flattening property and the idea that import takes precedence over inheritance. I am absolutly not sure if it fit to the Perl 6 module concept as a whole, but I will be happy to read your comments and what you think about it. A few pointers: classboxes+traits introduction: http://scg.unibe.ch/archive/papers/Berg05dTraitsClassbox.pdf For an in depth description, you can also read the Ph.D. thesis: http://scg.unibe.ch/archive/phd/bergel-phd.pdf To develop the classbox concept, the autors also introduced a module calculus, which also help to describe the difference existing beetween different modules systems: (such a module calculus can also help to better anderstand the interaction beetween different languages): http://scg.unibe.ch/archive/papers/Berg05cModuleDiversity.pdf I will be on Holiday for the next 3 weeks and will probably be offline most of the time, so don't take a no reply for indifference. I know that it's not a good idea to propose something like that and disappear immediatly, but a saw that S11 was on a heavily rework phase and that it is now or never to open my mouth :) Raphael.
Re: Perl 6 modules and classboxes?
I tried to read the Synopse S11 and how modules will be working in Perl 6: to be honest I still not really anderstand it :) What may help me is to know where Perl 6 modules are to be placed in the module taxonomy used in the module calculus paper below. To develop the classbox concept, the autors also introduced a module calculus, which also help to describe the difference existing beetween different modules systems: (such a module calculus can also help to better anderstand the interaction beetween different languages): http://scg.unibe.ch/archive/papers/Berg05cModuleDiversity.pdf Raphael.
Re: xml grammar
Am Montag, den 03.08.2009, 11:04 +1000 schrieb Timothy S. Nelson: On Fri, 31 Jul 2009, Raphael Descamps wrote: Hi, I have seen that wayland76 was playing with an XML Grammar on #perl6, so I think that it was maybe the time to send what I already have done. Raphael: I don't say any of this to discourage you, Don't worry, you don't :) I'm happy to see that there is already different implementations available. In fact it's not surprising because the most blokers bugs and missing features of PGE have been solved. but to present alternatives to the list. I knew that Francois was working on it, but last time that I checked it, nothing was released. http://github.com/krunen/xml/tree/master http://github.com/wayland/Tree/tree/master http://gist.github.com/161467 Another version is at http://github.com/fperrad/xml/ So thanks for the pointers, I will have a look at the different implementations. Raphael
xml grammar
Hi, I have seen that wayland76 was playing with an XML Grammar on #perl6, so I think that it was maybe the time to send what I already have done. Maybe it should be a perl6.user posting, but as there is actualy no working xml library available for perl 6 and it is a good test for how it feel to write a grammar with the actual specification, I post it here. I simply started with the pseudo XML grammar from Moritz on his blog and found myself reading the whole XML specification. I am definitively not a XML specialist and have no experience with sax or libxml and simply wanted to learn more about the perl 6 grammar syntax and features to be able to anderstand STD.pm. It's only a grammar for now without actions because a ran out of tuits. It is using only tokens and no rules because at the time the overriding of ws was not working properly. But hey, it (mostly) works and is a good examle of what you can do today with a perl 6 :) Feel free to propose better way to do it :) xml.pl Description: Perl program Grammar.pm Description: Perl program
Re: YAPC::EU and Perl 6 Roles
Am Freitag, den 10.07.2009, 17:06 -0700 schrieb Jon Lang:
How about this: in role composition, mandate causes methods to take
precedence over other methods with which they would normally conflict,
and to conflict with methods that would normally take precedence over
them.
I really dislike this because it is contrary to the original idea of the
stateless traits as defined in the original paper from Nathanael
Schärli.
The main reason why traits have been introduced was to solve the
problems inherent to mixins. In mixins the main problem is that the
class using the mixin is not able to control the composition (which is
simply done sequencially) and that lend to fragile hierarchies.
The brilliant idea with traits is that it bring back the control to
the class consuming the trait and conflicts have to be solved
explicitly. The traits paper propose 3 different operators to solve such
conflicts: overriding, excluding or aliasing.
I definitively think that perl 6 roles should also have an excluding
operator because I think that *every* composition conflicts arrising
should be solvable by the class comsuming the role.
What you propose here is a step behind: you reintroduce the problem
existing with mixins by bringing back precedence rules in the way
composition is made.
So far, I have only seen reference to the original paper decribing the
stateless traits. As roles are an implementation of stateful traits,
maybe we should start to point to the paper formalising it:
http://scg.unibe.ch/archive/papers/Berg07eStatefulTraits.pdf
So:
role R1 { mandate method foo { ... } }
role R2 { method foo { ... } }
class C does R1 does R2 { ... }
Normally, the compiler would complain of a conflict between R1 and R2;
but because R1::foo is mandated, it wins out.
role R { mandate method foo { ... } }
class C does R { method foo { ... } }
Normally, C::foo would take precedence over R::foo; but because R::foo
is mandated, the compiler complains of a conflict between C and R.
When two methods have the mandate keyword, they are compared to each
other as if neither had the keyword.
role R { mandate method foo { ... } }
class C does R { mandate method foo { ... } }
Since both R::foo and C::foo are mandated, C::foo supersedes R::foo.
Applying the mandate keyword to a role is shorthand for applying it
to all of its methods.
mandate role R {
method foo { ... }
method bar { ... }
method baz { ... }
}
is the same as:
role R {
mandate method foo { ... }
mandate method bar { ... }
mandate method baz { ... }
}
This behavior can be overridden by the suggest keyword:
mandate role R {
suggest method foo { ... }
method bar { ... }
method baz { ... }
}
is the same as:
role R {
method foo { ... }
mandate method bar { ... }
mandate method baz { ... }
}
That is, every method is either mandated or suggested, and suggested
by default. Mandating a role changes the default for its methods, or
you could explicitly suggest the role. The latter possibility would
allow for a pragma that changes the role's default importance from
suggested to mandated.
Ovid's distinction between interface and unit of behavior could be
managed by this distinction: suggest role R is primarily intended as
an interface, with behavior being a suggestion only and implicitly
overriden by the class; mandate role R is primarily intended as a
unit of behavior, and overriding its behavior requires that you
explicitly supersede it. In Ovid's programs, he might start by saying
use mandate, so that roles operate as units of behavior by default,
and can be declared as interfaces by saying suggest role instead of
role. Or maybe the pragma declares interface as a synonym for
suggest role. (I'd be more comfortable with this if I could think
of a comparable synonym for mandate role; at that point, you could
do away with the pragma - use role, suggest role, or interface
to mean interface, and use mandate role or ??? to mean unit of
behavior.)
At this point, you can strengthen the importance of a method (raising
it from a suggestion to a mandate); but you cannot weaken it. Thus,
interfaces can be composed into units of behavior; but not vice versa:
attempting to do so would result in a unit of behavior. I think that
the converse _should_ be possible; but I'm not quite sure how it might
be done.
