Re: Dallas.p6m
On Mar 19, 2009, at 2:35 PM, Andy Lester wrote: I love love LOVE starting to get people together to talk about Perl 6. It's a crucial step in letting people know that Perl 6 is real. However, starting social groups that say they are specifically about Perl 6 makes me uncomfortable. I think it would be better to call it Dallas.pm and just talk about Perl 6 in the meeting announcements. The key is that we don't want people to think they must choose one or the other. Technologically, Perl 5 and Perl 6 are very different, but culturally, they're very similar. Keeping Perl 5 and Perl 6 groups together also means that we will increase cross-pollination of Perl 6 onto the Perl 5 people. At Madison.pm, I give a 5-minute Perl 6 update each month. It's easy to collect material because Rakudo and Parrot each release monthly, so I can always just rehash the release announcements. I've found that the Perl 5 users are quite interested (and occasionally amazed). Chris
Re: $?OS change
On Mar 2, 2009, at 12:04 AM, Timothy S. Nelson wrote: Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $* counterparts). I'd like to recommend that we eliminate $?OS, and replace it with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts? I disagree. User-space code cares much more deeply about the operating system than the kernel, largely thanks to libc or the equivalent. For example, BSD systems can be built on a number of different kernels. Mac OS X is in principle FreeBSD on Mach, but there are a huge number differences from "plain" FreeBSD that have nothing to do with Mach. Instead, it would be even more useful to represent $?OS.family, $? OS.version.major, $?OS.version.minor, etc. Linux distros often support switching kernel versions out from under the OS. % uname -mprsv Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 i386 Chris
Re: Comparing inexact values (was "Re: Temporal changes")
On Feb 23, 2009, at 11:16 PM, Larry Wall wrote:
if $x ~~ $y ± $epsilon {...}
where infix:<±> turns the single value into a range for the
smartmatch.
That's very cool. However, my first impression is that "$y ±
$epsilon" maps more naturally to "any($y-$epsilon, $y+$epsilon)" than
to a range.
Chris
$*DEFOUT vs. $*OUT
Smack me down if this has already been discussed to death, please... S16 (and now S28) say that $*DEFOUT, $*DEFIN and $*DEFERR are what most programs should use instead of $*OUT, $*IN and $*ERR. That seems anti-huffman to me, and I'll bet many programmers will use $*OUT when they should be using $*DEFOUT because the former is shorter and more obvious. Perhaps instead the default handles should be $*OUT, $*IN and $*ERR while the standard handles should be $*STDOUT, $*STDIN and $*STDERR? Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Feb 22, 2009, at 12:39 AM, Brandon S. Allbery KF8NH wrote: On 2009 Feb 20, at 14:36, Chris Dolan wrote: UTC: TAI with an offset, as corrected for the actual revolution of the Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in every day (86399, 86400, or 86401 seconds). Yes, just as I said: a constant offset between each of the proposed Read again; a leap second was added at the end of last year, that's not exactly "constant". You missed the trivial point I was trying to make: the number of seconds between January 1, 1970 UTC (aka time_t epoch) and January 1, 2000 TAI *epochs* is a constant. I did not claim that the time systems differed by a constant. An epoch is an instant in time from which other times are measured, so you can measure UTC time flowing from a TAI epoch and vice versa. Astronomers do this all the time to avoid the complexity that the Earth's rotation precesses, so the time to orbit the Sun once it not exactly the same as a solar year. Astrometric coordinates are thus claimed relative to an epoch, say B1950 or J2000, and can be easily transformed between epochs. Nevertheless, Larry has closed the issue declaring that Perl 6 will use TAI, and I'm cool with that. With just 30-odd lossy exceptions in the last 40 years, we can translate between TAI and time_t as needed. When the OSes catch up and stop using time_t, it will be a glorious day. ... unless we decide to use Stardates instead. Floating point time would be cooler. :-) Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
> Considering time scales, there are three that significantly > interrelate, and no matter what Perl 6 uses internally, it needs to be > able to convert to and from these: > > TAI: continuous count of time using SI seconds as measured by atomic > clocks, 60 seconds in every minute, 60 minutes in every hour, 24 hours > in every day. > > UTC: TAI with an offset, as corrected for the actual revolution of the > Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 > minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in > every day (86399, 86400, or 86401 seconds). > > time_t: the value you get by taking the UTC time since Jan 1, 1970 at > midnight and converting to a simple count of seconds, pretending there > have been no leap seconds along the way. > > Right now as I type this it is 17:13:38 UTC. That's 17:14:12 in TAI > (which is 34 seconds ahead of UTC until the next leap second). The > corresponding time_t value is 1,235,150,018, but there have actually > been 1,235,150,042 seconds since the UNIX epoch. Yes, just as I said: a constant offset between each of the proposed epochs. But my point remains: from the user's point of view it doesn't matter which epoch you choose to use behind the scenes, so you might as well pick the one that's easiest on the software (time_t) and leave the transformations to the libraries. Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote: On Thu, 19 Feb 2009, Larry Wall wrote: Well, leaving that rant aside, I'm still tempted to say that times in Perl 6 are TAI seconds since 2000. Standard TAI would work too. I've wondered sometimes about the idea of having a dual/moving epoch. By this, I mean that you have eg. two Ints, one which represents the years since 1AD or whatever, and the other of which represents the number of seconds from the beginning of that year. I'm sure many of you can see the advantages and disadvantages of that scheme better than I can, but I thought I'd throw it out there so you can all see whether or not you like it. I don't see the advantage of either of those. TAI 2000 is just UTC 1970 plus a constant offset. 1AD is just UTC 1970 minus a bigger constant offset. Sure, those are slightly easier epochs for a human (ignoring the Julian/Gregorian shift), but not any easier for a computer. UTC 1970 has the big advantage that it is already the underlying value returned by most operating systems and many date/ time libraries, so there's no extra additive operation to perform if that's what you want. A much more important issue is the use of integer seconds. Milliseconds is a much more useful precision for humans and micro- or nanoseconds is a better precision for machines. I think Time::HiRes with a better API as a builtin would be a big win. Aside: I just learned the other day that Java's Thread.sleep(long millis, int nanos) method just rounds the nanos to the nearest millis and invokes Thread.sleep(long millis). I guess that's a forward looking API for when the OS really can timeslice that small, but it's a little silly today. http://krugle.org/kse/entfiles/jdk/sun.com/jdk-1.5/j2se/src/share/ classes/java/lang/Thread.java#246 Maybe Perl 6 should be really forward looking and include a time dilation factor so it can be the first language designed from the ground up for interstellar travelers who want to use a non-inertial reference. Or GPS? :-) Chris
Re: r25325 - docs/Perl6/Spec
On Feb 13, 2009, at 11:50 PM, Larry Wall wrote: On Fri, Feb 13, 2009 at 11:34:03PM -0600, Chris Dolan wrote: Argh! I submitted a patch implementing $?PROGRAM in Rakudo literally 5 minutes before you sent this... http://rt.perl.org/rt3/Ticket/Display.html?id=63228 Indeed, why do you think I fixed the spec? :) But don't worry, we tend to do thing on the basis of forgiveness rather than permission, so I'm glad you did that or I wouldn't have noticed the $?PROGRAM problem. (The reason it can't be $?PROGRAM is that the name of the eventual executable program can't necessarily be known at compile time, which $? implies. $? variables have to be constants known at compile time.) Larry Aha! Thanks for clarifying that. However, now S19 and S02-magicals/progname.t disagree on whether PROCESS::<$PROGRAM_NAME> means $^X='/usr/bin/perl' or $0='foo.pl'. S02 suggests $*PERL is $^X. Maybe PROCESS::<$PERL_EXECUTABLE> for $^X? Chris
Re: r25325 - docs/Perl6/Spec
Argh! I submitted a patch implementing $?PROGRAM in Rakudo literally 5 minutes before you sent this... http://rt.perl.org/rt3/Ticket/Display.html?id=63228 Chris On Feb 13, 2009, at 11:21 PM, pugs-comm...@feather.perl6.nl wrote: Author: lwall Date: 2009-02-14 06:21:13 +0100 (Sat, 14 Feb 2009) New Revision: 25325 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] $?PROGRAM makes no sense Modified: docs/Perl6/Spec/S19-commandline.pod === --- docs/Perl6/Spec/S19-commandline.pod 2009-02-14 05:13:04 UTC (rev 25324) +++ docs/Perl6/Spec/S19-commandline.pod 2009-02-14 05:21:13 UTC (rev 25325) @@ -14,8 +14,8 @@ Maintainer: Jerry Gay Date: 12 Dec 2008 - Last Modified: 11 Feb 2009 - Version: 24 + Last Modified: 13 Feb 2009 + Version: 25 This is a draft document. This document describes the command line interface. It has changed extensively from previous versions of Perl in order to increase @@ -67,7 +67,7 @@ and performs the requested actions. It looks something like Fbin/perl6>, F, or F, and is followed by zero or more I. Perl 6 does not do any processing of the I portion of the command -line, but it is made available at run-time in the read-only C<$? PROGRAM> +line, but it is made available at run-time via the C<< PROCESS::< $PROGRAM_NAME> >> variable. Command line I are broken down into I and I.
{*} and actions
1) Will the "{*}" syntax to invoke an external action method from
within a grammar be an official part of the language, or an
implementation hack?
2) If it becomes official, how should people specify the action class/
instance to be used with a grammar?
Currently in Rakudo, I use the following deprecated hack:
my $method := &My::Grammar::TOP;
my $match := $str.$method(:action(My::Grammar::Actions.new));
but I'd greatly prefer something more like
my $grammar = My::Grammar.new(:action(My::Grammar::Actions.new));
my $match = $str ~~ $grammar;
Chris
