Re: [svn:parrot] r24414 - trunk/t/tools/ops2pmutils
On Tuesday 01 January 2008 09:00:36 [EMAIL PROTECTED] wrote: > Modified: >trunk/t/tools/ops2pmutils/08-sort_ops.t > > Log: > Commenting out TODO block around test for experimental.ops. Test has been > steadily passing for > 1 month. Why comment it out? We can revert this checkin if necessary (or rewrite the three lines). -- c
[svn:perl6-synopsis] r14477 - doc/trunk/design/syn
Author: larry Date: Tue Jan 1 17:01:32 2008 New Revision: 14477 Modified: doc/trunk/design/syn/S02.pod Log: Clarification of off-the-end semantics of KeySet and KeyBag requested by Limbic~Region++. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podTue Jan 1 17:01:32 2008 @@ -14,7 +14,7 @@ Date: 10 Aug 2004 Last Modified: 1 Jan 2008 Number: 2 - Version: 122 + Version: 123 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -896,7 +896,9 @@ If you use the C interface and increment an element of a C its value becomes true (creating the element if it doesn't exist already). If you decrement the element it becomes false and -is automatically deleted. When not used as a C (that is, +is automatically deleted. Decrementing a non-existing value results +in a C value. Incrementing an existing value results in C. +When not used as a C (that is, when used as an C or list or C object) a C behaves as a C of its keys. (Since the only possible value of a C is the C value, it need not be represented in @@ -906,7 +908,8 @@ use the C interface and increment an element of a C its value is increased by one (creating the element if it doesn't exist already). If you decrement the element the value is decreased by one; -if the value goes to 0 the element is automatically deleted. When not +if the value goes to 0 the element is automatically deleted. An attempt +to decrement a non-existing value results in a C value. When not used as a C (that is, when used as an C or list or C object) a C behaves as a C of its keys, with each key replicated the number of times specified by its corresponding value.
New wiki page: RFP Parrot needs better smoke reports
Following up on today's Parrotsketch discussion, I have begun a wiki page whose purpose is to develop a specification for an improved smoke testing setup for Parrot. http://www.perlfoundation.org/parrot/index.cgi?rfp_parrot_needs_better_smoke_reports I invite you to: -- correct any factual errors in what I've written so far -- fill in sections which are marked 'TK'. Let's see if this enables us to develop a plan more quickly or effectively than back-and-forth on the mailing list. Once we have a completed first draft of a specification, we'll open up an RT. (At least, that's my suggestion.) Thank you very much. kid51
Re: [perl #49224] [BUG] Repeated problems with 'svn commit'
James, I've been seeing this problem off and on for over a month. As you've noticed, it's rather intermittent, however, when the problem occurs it persists for up to couple of hours. I've also seen that this is platform independent, and so guessed that the problem existed at the server end (maybe server load?). Unfortunately, I've got nothing consistent enough to be able to pinpoint where the issue is. Paul On 30/12/2007, James Keenan via RT <[EMAIL PROTECTED]> wrote: > On Sun Dec 30 10:01:18 2007, rgrjr wrote: > > > > > Come to think of it, I did three commits each on Monday and Tuesday, and > > must have seen it then (either or both days). > > > > -- Bob > > > > > Perhaps not; the problem is intermittent. But yesterday I was getting > it on about 1/3 of all my commits. >
Re: Another deadlock on Mac OS 10.5.1
On 31/12/2007, James E Keenan <[EMAIL PROTECTED]> wrote: > Andy Armstrong wrote: > > Sorry if I've missed something recent that means that this is expected > > behaviour but r24318 is hanging during make test on Mac OS 10.5.1 / Intel. > > > > The test log and pictures of the process probe are here: > > > > http://hexten.net/junk/20071230-193600/ > > > > I also have a few test failures on Ubuntu PPC: > > > > Test Summary Report > > --- > > t/configure/115-auto_warnings-01.t (Wstat: 0 Tests: 4 Failed: 0) > > TODO passed: 4 > > t/src/intlist.t(Wstat: 0 Tests: 4 Failed: 0) > > TODO passed: 1-4 > > t/src/io.t (Wstat: 0 Tests: 20 Failed: 0) > > TODO passed: 16-17, 19 > > These are the same TODO-ed out tests that are failing most everywhere. > In the case of the failure in 115-auto_warnings-01.t, I think the > problem is mostly a defect in the construction of the test. When ptc > gets back, I hope to speak with him about it. It's not a major concern. I've unfortunately got no time to work on Parrot atm, but wish I did... Life outside of Parrot has become rather full. I'll be back at some stage, I just don't know when. > > t/examples/shootout.t (Wstat: 2560 Tests: 20 > > Ah! The shootout! Our old nemesis. Join the crowd; google the list > archives. It almost never passes on Darwin and there's an old-ish > ticket about it failing on Gentoo Linux. But it seems to pass on Debian. I have a vague feeling that the Gentoo ticket is from me, and I also have a vague feeling that the Gentoo shootout tests are all working atm (can't test that atm though...) I'm really impressed with the activity on Parrot atm; it's great to see :-) Happy New Year everyone! Paul
Re: Testing asynchronous code
> In the concurrency work I'm about to check in, I have some tests that > fail intermittently because they test for something like: > > But, as we add more asynchronous code, and more asynchronous tests, we'll > need to do more thinking on our strategies for testing asynchronous code. > Would always sorting the expected and actual output to the same order solve the problem? (It sounds like one of those "so obvious I've clearly missed something" situations.) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: am I doing something wrong - hanoi example with 0.5.1 parrot release
--- Aaron Trevena <[EMAIL PROTECTED]> wrote: > running the example at > http://svn.pugscode.org/pugs/examples/algorithms/hanoi.pl > > parrot ~/downloads/parrot-0.5.1/languages/perl6/perl6.pbc hanoi.pl > > I get.. > > Null PMC access in isa() > current instr.: 'parrot;Perl6Object;make_proto' pc 55 > (src/gen_builtins.pir:76) > called from Sub 'parrot;Bool;onload' pc 378 > (src/gen_builtins.pir:308) > called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown > file):-1) > > Am I doing something wrong? This line? my $ndisks := @*ARGS[0] // 3; I was rather under the impression that perl6 does not yet implement @*ARGS. Unfortunately, I not only cannot recall where I read that, I don't know where to look to verify that. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Multiline comments in Perl6
I love this list. I wish I had more of value to contribute. =o]
But for those of you who don't want to read a long blather, this is
mostly opinion, hopefully sans soapbox. Feel free to skip to the end.
> What's with the sudden influx of people swooping in at the
> last minute and attacking design decisions that were made, with much
> angst and public debate, over the span of months and years? It's not
> like @Larry are doing things based on whim; if they were, Perl6 would
> have been done 2+ years ago.
I agree 100%. In fact, I've been guilty of this myself, but the point
is valid...and I think the was a nice touch. Still, we do want
to keep polling the user base, if hopefully with a minimum of spam. As
long as we don't lose the forum under a deluge of whining and
me-too-isms, I think it's good to get the occasional, abbreviated
re-airing of old issues. For example, I missed this one the first dozen
times through
I don't like having to think about whitespace so much, but I'll get
used to that. Virtually every language uses significant whitespace, and
though P6 seems to be more saturated with *relevant* whitespace issues,
as a rule of thumb I have been bluntly impressed with what the @Larry
have been accomplishing. I'll learn, I'll deal, and I'll be happy for
the toys they let me buy with those quirks, lol
But for my meager $.02 in the matter
http://perl6.org/doc/design/syn/S02.html still says:
"Intra-line comments will not be supported in standard Perl"
I obviously missed something again here. Could someone clue me in?
Isn't that what this thread is talking about with #{...}?
I assume it's a module-based construct, like most everything else?
Line comments and POD are fine, but I have (on occasion) missed being
able to use embedded comments. I'm glad they'll be available now, but I
doubt I'd add a use() to get them most of the time -- just personal
preference; I'd rather save the line of code, lol. I don't personally
even mind having to deal with the whitespace rule, though it does feel
pretty wierd to me.
I think the bracketing construct is a cool concept. Start with a
hashmark and follow it with a bracketing construct, and it comments
everything in the bracket but I have to say just for the
accumulation of weight on the issue that it's going to really take some
time for me to get used to thinking of comments as ending with just a
bracket, especially since I'll have to trace back to the matching
structure to make sure it's the right bracket.
Syntactically, I know @Larry's a lot smarter than I am, so I defer, but
could we start thinking now, as a community, in terms of standards for
this? I mean, correct me if I'm wrong, but didn't most of us follow the
general convention of making filehandle names capitalized in P5? Perl
didn't care, but it's a courtesy we observed for ourselves and the
inheritors of our code. Of course, I usually used a scratchpad variable
instead.
So I'll probably tend to use some standard set of brackets and "flag"
characters just for my own benefit. On that note, I do have a couple of
actual questions. =o)
Is there any restriction of the whitespace *inside* the comment?
And is / a valid bracketer? Is there any problem with something like:
@x = #/* here's an embedded comment */ 1..99;
or should I stick to things like
$x = #<-- comment --> 1;
$x = #{ comment #} 1;
$x = #( comment +) 1;
$x = #[ comment =o] 1;
Or will any of these not work?
I suppose there's always #{/* foo */}
Or when all else fails, just move the comment to a line of it's own, or
a block of POD. ;o]
Thanks for your patience and your input,
Paul
--- "Mark J. Reed" <[EMAIL PROTECTED]> wrote:
> Whitespace is significant in many places. Even in some of the
> corners of Perl 5. Perl 6 has a different set of rules, and it
> will take some getting used to, but the rules are designed to
> let you do things as naturally as possible.
> This, for instance, works fine:
>
> my @values =
> # (1,2,3) # older values, don't use
> (4,5,6);
>
> If I were suddenly granted the magical ability to impose my will upon
> the design of Perl 6 and change anything I wanted, the multi-line
> comments leading-whitespace exception would not make the top 5.
>
> What's with the sudden influx of people swooping in at the
> last minute and attacking design decisions that were made, with much
> angst and public debate, over the span of months and years? It's not
> like @Larry are doing things based on whim; if they were, Perl6 would
> have been done 2+ years ago.
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: Testing asynchronous code
On Dec 31, 2007, at 11:57 AM, chromatic wrote: On Monday 31 December 2007 05:50:47 Allison Randal wrote: In the concurrency work I'm about to check in, I have some tests that fail intermittently because they test for something like: 1 alarm1 2 alarm2 3 alarm3 alarm1 alarm3 4 alarm3 alarm3 alarm3 5 done. When the actual output is something like: 1 2 alarm1 3 alarm2 4 alarm3 alarm1 5 alarm3 done. alarm3 alarm3 alarm3 Everything that should happen is happening, just not in the expected order, or even in a consistent order from one test run to the next. It's asynchronous code, so there isn't any guaranteed order. It sounds like the tests shouldn't print but instead set flag variables and then something at the end can check those flags and then report success or failure. Would it be useful to pipe the output through sort and then check for an exact string match? Josh
Re: am I doing something wrong - hanoi example with 0.5.1 parrot release
On Jan 2, 2008 2:54 AM, Ovid <[EMAIL PROTECTED]> wrote: > --- Aaron Trevena <[EMAIL PROTECTED]> wrote: > > > running the example at > > http://svn.pugscode.org/pugs/examples/algorithms/hanoi.pl > > > > parrot ~/downloads/parrot-0.5.1/languages/perl6/perl6.pbc hanoi.pl > > > > I get.. > > > > Null PMC access in isa() > > current instr.: 'parrot;Perl6Object;make_proto' pc 55 > > (src/gen_builtins.pir:76) > > called from Sub 'parrot;Bool;onload' pc 378 > > (src/gen_builtins.pir:308) > > called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown > > file):-1) > > > > Am I doing something wrong? > > This line? > > my $ndisks := @*ARGS[0] // 3; > > I was rather under the impression that perl6 does not yet implement > @*ARGS. Unfortunately, I not only cannot recall where I read that, I > don't know where to look to verify that. > > Cheers, > Ovid > @*ARGS and infix:// have been implemented in perl6 thanks to patrick, so hanoi.pl works with the svn head in parrot repo. ~jerry
Re: S03 - Str autodecrement
On Tue, Jan 01, 2008 at 04:26:29PM -0600, Patrick R. Michaud wrote: : I'm working on S03 tests, and S03 says: : : Perl 6 also supports Str decrement with similar semantics, : simply by running the cycles the other direction. However, : leftmost characters are never removed, and the decrement : fails when you reach a string like "aaa" or "000". : : Is this "fails" as in "throws an Exception", "mutates into an : undef / Failure / Exception object", or something else entirely? In the context of normal Perl expressions, "fails" should always be read as "returns a Failure object". Which, of course, is immediately fatal under "use fatal". Otherwise it's lazily fatal. In fact, the places in the spec that say "returns a Failure object" should probably be rewritten to say "fails" to keep people from thinking that it means something other than "fails". Larry
Re: [perl #49224] [BUG] Repeated problems with 'svn commit'
On Wed, Jan 02, 2008 at 09:58:21AM +0100, Paul Cochrane wrote: > I've been seeing this problem off and on for over a month. As you've > noticed, it's rather intermittent, however, when the problem occurs it > persists for up to couple of hours. I've also seen that this is > platform independent, and so guessed that the problem existed at the > server end (maybe server load?). Unfortunately, I've got nothing > consistent enough to be able to pinpoint where the issue is. I agree with Paul that that it's probably something on the server end. But I don't know what it is. Whenever it happens, I just do an 'svn up' immediately after the "failed" commit and everything seems to be okay. Pm
[perl #49262] [CAGE]: Rename Parrot::Configure::Step and Parrot::Configure::Step::Base
No problems evident from smoke tests, so I'm resolving this ticket.
Re: Multiline comments in Perl6
Paul Hodges wrote:
> http://perl6.org/doc/design/syn/S02.html still says:
> "Intra-line comments will not be supported in standard Perl"
This is wrong, since S02 also defines intra-line comments, under
"Whitespace and Comments". It calls them 'embedded comments'. You
don't need a 'use' statement.
> Is there any restriction of the whitespace *inside* the comment?
Not from my reading of it, no.
> And is / a valid bracketer?
No. The valid bracketers are defined under "Lexical Conventions" - in
layman's terms, bracketing characters are matching pairs of
characters: so '(' and ')' are bracketing characters, but '/' is not.
Likewise, the matches are based on individual characters, so if you
use "<--" at the start of a bracketed segment, only the "<" counts as
a bracketing character.
> or should I stick to things like
>
>$x = #<-- comment --> 1;
>$x = #{ comment #} 1;
>$x = #( comment +) 1;
>$x = #[ comment =o] 1;
>
> Or will any of these not work?
All four of those work as written.
In addition, S06 demonstrates how you can use macros to create custom
embedded comments:
macro circumfix:«» ($text) is parsed / .*? / { "" }
--
Jonathan "Dataweaver" Lang
[svn:perl6-synopsis] r14478 - doc/trunk/design/syn
Author: larry
Date: Wed Jan 2 11:30:16 2008
New Revision: 14478
Modified:
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S06.pod
Log:
Rationalize migration strategy from Perl 5 to Perl 6 using transitional p5=>
operator
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Jan 2 11:30:16 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 31 Dec 2007
+ Last Modified: 2 Jan 2008
Number: 3
- Version: 125
+ Version: 126
=head1 Overview
@@ -48,7 +48,7 @@
Conditional ?? !! ff fff
Item assignment = := ::= => += -= **= xx= .=
Loose unary true not
-Comma operator ,
+Comma operator , p5=>
List infix Z minmax X X~X X*X XeqvX
List prefix = : print push say die map substr ... [+] [*] any $ @
Loose and and andthen
@@ -1346,6 +1346,28 @@
Unlike in Perl 5, comma operator never returns the last value. (In item
context it returns a list instead.)
+=item *
+
+C<< infix:«p5=>» >>, the Perl 5 fatarrow
+
+This operator, which behaves exactly like the Perl 5 fatarrow in being
+equivalent to a comma, is purely for easier migration from Perl 5
+to Perl 6. It is not intended for use by programmers in fresh code;
+it is for use by the p5-to-p6 translator to preserve Perl 5 argument
+passing semantics without losing the intent of the notation.
+
+This operator is purposefully ugly and easy to search for. Note that,
+since the operator is equivalent to a comma, arguments come in as
+positional pairs rather than named arguments. Hence, if you have
+a Perl 5 sub that manually handles named argument processing by
+assigning to a hash, it will continue to work. If, however, you edit
+the C<< p5=> >> operator in an argument list to Perl 6's C<< => >>
+operator, it becomes a real named argument, so you must also change
+the called sub to handle real named args, since the named pair will no
+longer come in via C<@_>. You can either name your formal parameters
+explicitly if there is an explicit signature, or pull them out of C<%_>
+rather than C<@_> if there is no explicit signature.
+
=back
=head2 List infix precedence
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Jan 2 11:30:16 2008
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 21 Mar 2003
- Last Modified: 26 Oct 2007
+ Last Modified: 2 Jan 2008
Number: 6
- Version: 90
+ Version: 91
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -124,18 +124,37 @@
sub foo {...}
-Arguments implicitly come in via the C<@_> array, but they are C
-aliases to actual arguments:
+This is equivalent to
-sub say { print qq{"@_[]"\n}; } # args appear in @_
+sub foo ([EMAIL PROTECTED], *%_) {...}
-sub cap { $_ = uc $_ for @_ } # Error: elements of @_ are read-only
+Positional arguments implicitly come in via the C<@_> array, but
+unlike in Perl 5 they are C aliases to actual arguments:
-If you need to modify the elements of C<@_>, declare the array explicitly
-with the C trait:
+sub say { print qq{"@_[]"\n}; } # args appear in @_
-sub swap ([EMAIL PROTECTED] is rw) { @_[0,1] = @_[1,0] }
+sub cap { $_ = uc $_ for @_ } # Error: elements of @_ are read-only
+Also unlike in Perl 5, Perl 6 has true named arguments, which come in
+via C<%_> instead of C<@_>. (To construct pseudo-named arguments that
+come in via C<@_> as in Perl 5, the p5-to-p6 translator will use the ugly
+C<< p5=> >> operator instead of Perl 6's C<< => >> Pair constructor.)
+
+If you need to modify the elements of C<@_> or C<%_>, declare the
+array or hash explicitly with the C trait:
+
+sub swap ([EMAIL PROTECTED] is rw, *%_ is rw) { @_[0,1] = @_[1,0];
%_ = "Q:S"; }
+
+Note: the "rw" container trait is automatically distributed to the
+individual elements by the the slurpy star even though there's no
+actual array or hash passed in. More precisely, the slurpy star
+means the declared formal parameter is I considered readonly; only
+its elements are. See L below.
+
+Note also that if the sub's block contains placeholder variables (such
+as C<$^foo>), it is considered to have a formal signature already, so
+no implicit bindings to C<@_> or C<%_> are assumed (nor is an explicit
+signature allowed.) So in that case, this section does not apply.
=head2 Blocks
Re: Testing asynchronous code
what about "joining" threads, and comparing the output at those points? For async IO, a join is more or less implemented by a "wait" operation, no? (or the parrot equivalent for that). just a thought. kjs On Dec 31, 2007 8:57 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Monday 31 December 2007 05:50:47 Allison Randal wrote: > > > In the concurrency work I'm about to check in, I have some tests that > > fail intermittently because they test for something like: > > > > 1 > > alarm1 > > 2 > > alarm2 > > 3 > > alarm3 > > alarm1 > > alarm3 > > 4 > > alarm3 > > alarm3 > > alarm3 > > 5 > > done. > > > > When the actual output is something like: > > > > 1 > > 2 > > alarm1 > > 3 > > alarm2 > > 4 > > alarm3 > > alarm1 > > 5 > > alarm3 > > done. > > alarm3 > > alarm3 > > alarm3 > > > > Everything that should happen is happening, just not in the expected > > order, or even in a consistent order from one test run to the next. It's > > asynchronous code, so there isn't any guaranteed order. > > It sounds like the tests shouldn't print but instead set flag variables > and > then something at the end can check those flags and then report success or > failure. > > -- c >
Re: [perl #49238] [PATCH] pbc_to_exe compile failure on Win32 / MSVC9
On Wednesday 02 January 2008 05:40:35 Cosimo Streppone via RT wrote: > Thanks for the building process explanation. > After your changes (r24437) I still have problems building perl6.exe. > I'm trying to use `nmake perl6'. Two problems here: > > 1) The `int8_t' define doesn't work for me. Seems like `signed__int8' > is also undefined. > 2) There's a small typo in gen/makefiles/root.in > > The attached diff corrects wfm, even if 1) is resolved > using `unsigned char', which is ignorant, I think. I'm a little concerned that the #define doesn't fix up MSVC for you. particle, any suggestions here? (He wrote that code for a similar issue.) You're right about the typo fix though, so I'll apply the patch if we can figure out how to fix both issues at once. I fear using unsigned char directly because of platforms where it isn't exactly eight bits long. Sometimes you can tell I'm too paranoid to be a brilliant C hacker. -- c
Current status on Solaris 8/SPARC
After fixing various minor little things, here's where I stand on Solaris 8/SPARC after the recent changes. I have not identified any particular common theme. Do these ring any bells? Failed TestStat Wstat Total Fail List of Failed --- t/configure/115-auto_warnings-02.t7 179222 14 16-22 t/configure/115-auto_warnings-03.t7 179222 14 16-22 t/configure/115-auto_warnings-04.t7 179222 14 16-22 t/configure/115-auto_warnings-05.t8 204823 16 16-23 t/configure/115-auto_warnings-06.t8 204823 16 16-23 t/configure/115-auto_warnings-07.t9 230424 18 16-24 t/configure/146-auto_snprintf-01.t 13 332830 26 18-30 t/examples/library.t 1 256 41 3 t/examples/shootout.t 6 1536206 3-4 7 11-12 18 t/examples/tutorial.t 1 256351 18 t/library/pcre.t 1 256 11 1 t/op/globals.t2 512 92 2 7 t/op/string.t 2 512 1602 71 73 t/op/trans.t 1 256221 14 t/pmc/coroutine.t 4 1024114 3-6 t/pmc/nci.t 61 1561665 61 3-59 61-63 65 t/pmc/threads.t 7 1792207 2-3 5 10 12 15-16 t/pmc/timer.t 2 512 62 7-8 t/src/hash.t 1 256111 6 t/src/list.t 1 256 21 1 t/stm/basic_mt.t 4 1024 44 1-4 t/stm/runtime.t 2 512 52 2-3 (7 subtests UNEXPECTEDLY SUCCEEDED), 15 tests and 619 subtests skipped. Failed 22/535 test scripts. 151/10540 subtests failed. -- Andy Dougherty [EMAIL PROTECTED]
[perl #49292] Make perl6 support -h
# New Ticket Created by Andy Lester # Please include the string: [perl #49292] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=49292 > The -h should provide a list of help. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
[perl #49294] Make perl6 support -v
# New Ticket Created by Andy Lester # Please include the string: [perl #49294] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=49294 > perl6 -v should provide a version statement. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
[perl #49296] Make perl6 support -e
# New Ticket Created by Andy Lester # Please include the string: [perl #49296] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=49296 > perl6 -e"say 'hello world'" should work. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
SVK bootstrap dump for parrot
http://www.parrotcode.org/source.html claims the last dump was done in Aug 2006. Would someone be willing to update that dump? I'm going to be on a train tomorrow for 6 hours and would like to be able to do some work on parrot with version control. Zev
[perl #47393] t/configure/107-inter_progs-*.t all fail
With the application of patches in r24102 (Dec 19) and r24294 (Dec 30), the issues raised by Andy Dougherty have been addressed. He reports all tests are passing. As I have done with other configuration step classes, I have refactored as much code as possible out of runstep() and placed it in other subroutines which I test explicitly. We no longer directly test the cc_build and cc_run called within test_compiler(), but we test all around them, which is good enough. Closing ticket.
Re: am I doing something wrong - hanoi example with 0.5.1 parrot release
--- Ovid <[EMAIL PROTECTED]> wrote: > This line? > > my $ndisks := @*ARGS[0] // 3; > > I was rather under the impression that perl6 does not yet implement > @*ARGS. Unfortunately, I not only cannot recall where I read that, I > don't know where to look to verify that. Er, just to make me feel like a complete idiot ... I was perusing the parrotsketch IRC logs and for the JAN 1 log (http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200801/irclog.parrotsketch.20080101) I see the following: * added a 'make perl6' target to generate a standalone executable with pbc_to_ex e * added @*ARGS support, so hanoi.pl now runs Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: S03 - Str autodecrement
On Wed, Jan 02, 2008 at 08:52:09AM -0800, Larry Wall wrote:
> On Tue, Jan 01, 2008 at 04:26:29PM -0600, Patrick R. Michaud wrote:
> : I'm working on S03 tests, and S03 says:
> :
> : Perl 6 also supports Str decrement with similar semantics,
> : simply by running the cycles the other direction. However,
> : leftmost characters are never removed, and the decrement
> : fails when you reach a string like "aaa" or "000".
> :
> : Is this "fails" as in "throws an Exception", "mutates into an
> : undef / Failure / Exception object", or something else entirely?
>
> In the context of normal Perl expressions, "fails" should always be
> read as "returns a Failure object". Which, of course, is immediately
> fatal under "use fatal". Otherwise it's lazily fatal.
Ah, you answered my followup question ("Is this meaning of 'fails'
fairly consistent?"). Excellent.
Howeven, "returns a Failure object" in this context (autodecrement)
still seems a bit ambiguous, because the return values of autoincrement
and autodecrement are often ignored, as in:
my $s = 'A00';
$s--;
say $s;
So, what happens in the above? Does $s become a Failure object?
Does autodecrement recognize that it's in void context and thus
becomes immediately fatal?
> In fact, the places in the spec that say "returns a Failure object"
> should probably be rewritten to say "fails" to keep people from
> thinking that it means something other than "fails".
Agreed -- I'll fix them as I find them (or point them out if I'm uncertain).
Thanks again!
Pm
Re: Multiline comments in Perl6
I've been putting a fair amount of thought into this. Here's what
I've come up with:
Perl 6 has several instances where whitespace is required or forbidden
in order to better facilitate "Do What I Mean" programming: for
instance, by having the presence or absence of whitespace before curly
braces affect their meaning, you're allowed to omit the parentheses
around the parameters of the various control structures: e.g., 'if $x
{ ... }' is now valid, whereas in Perl 5 you would have had to say 'if
($x) { ... }'. Likewise, the same technique lets you provide an
unambiguous distinction between an infix operator and a postfix
operator (IIRC). So it isn't much of a stretch to require the use of
whitespace in order to distinguish between a standard "line comment"
and an embedded comment.
Except that that isn't what Perl 6 is doing. All that it does is to
say "there's this one case where there's some ambiguity between line
comments and embedded comments; it's up to the programmer to remove
the ambiguity, through whatever means he sees fit." In many ways,
this is the opposite of the above cases, and is more akin to how role
composition must be explicitly disambiguated by the programmer,
instead of having the compiler take a best guess.
I must admit: as nice as it is to be able to create an embedded
comment by wrapping the actual comment in brackets, the existence of
that one point of ambiguity is troubling.
--
What I like about the current embedded comments:
1. They're short. You need a single leading character (the '#'),
followed by content wrapped in as little as a pair of bracketing
characters. That's three characters in addition to the content
itself.
2. They're flexible. By going with user-specified bracketing
characters, the programmer can choose an intuitive "closing sequence"
that won't conflict with content that he's commenting out.
Of the two features, the second one is the more important one.
Likewise, the central most important feature concerning line comments
is that you can initiate them using a single character, allowing you
to reliably comment out a set of lines through a straightforward - and
short - sequence of keystrokes.
The problem arises from the fact that embedded comments start with the
same character that line comments start with. This means that the
second character is the one that gets used to distinguish between line
comments and embedded comments, which at best interferes with the main
benefit of line comments described above, and at worst leads to an
extra round of debugging as the programmer is forced to go through and
add whitespace (or other characters) to disambiguate the two.
--
The solution, then, would be to change embedded comments so that
they're initiated by something that doesn't begin with a '#'.
Ideally, you'd still use a single character (plus the brackets) to
define an embedded comment. Unfortunately, I'm pretty sure that we've
got a severe shortage of such characters available for use. Assume,
then, that a two-character initializer is going to be needed, and that
the first character cannot be a '#'.
--
I'm leery about making the first character be a '=', as there's the
potential for conflict with POD sections. IIRC, there's a (currently
unspoken?) design goal involving POD sections that says that any line
beginning with a '=' ought to be able to be stripped out of the
program without affecting the code. Those with more familiarity with
POD design philosophy can please speak up?
OTOH, it might be possible that '=#[ ... ]' could be used to add
versatility to the POD syntax. Consider the possibility of saying
that '=#[blah blah blah]' at the start of a line is equivalent to
'=blah blah blah', except that the POD header ends at the ']' instead
of the first '\n'. This could be used to wrap a POD header over
several lines, and/or to put the first line of POD content on the same
line as a short POD header. So:
=#[for comment
] text
foo;
would be equivalent to:
=for comment
text
foo;
...or not; this could lead to the same sort of trouble that we
currently have with line comments vs. embedded comments. If we were
to go this route, I'd be inclined to say that '=#[ ... ]' isn't just
an embedded comment; it's an "embedded POD header". This removes all
ambiguity regarding what it is, at the expense of forcing the POD
Parser to look at more than just the first character of each line to
determine whether or not it's meaningful. The expense may be too
great. At the very least, it opens up a whole new can of worms.
--
OK; so let's assume a two-character sequence prior to the opening
bracket of an embedded comment, with the first character being
something other than '#' or '='. It's perfectly acceptable (and,
IMHO, desirable) for the second character to be a '#'.
How about '~#', meaning something along the lines of "string-like
comment"? The idea is that the syntax that follows this would conform
closely to that of string literal
Re: expected test failures in t/pmc, t/run, and t/stm
Allison Randal wrote: Thanks all for the reports. I see two common trouble spots in hellgrind and the test output. One is a possible race condition if two threads add tasks to the concurrency scheduler at exactly the same moment. The other is the fact that PCC uses globals in the interpreter to store invocation information, so code for a particular interpreter (event handlers, callbacks, etc) must always be executed within that interpreter's runloop. Both are addressed by PDD 25, so I'll work on implementing those pieces. (The current implementation is partial, enough to support PDD 24.) I've just checked in the next stage of development on PDD 25. Each interpreter/thread has its own scheduler, and invocation of things like callbacks happen within the interpreter's runloop. This resolves all concurrency-related failures except the old intermittent t/stm failures. Next, I'll implement message passing between schedulers from PDD 25, which will solve the t/stm failures. Allison
Re: [svn:parrot] r24439 - in trunk/languages/perl6: . config/makefiles
On Wednesday 02 January 2008 08:39:51 [EMAIL PROTECTED] wrote: > Modified: >trunk/languages/perl6/ (props changed) >trunk/languages/perl6/config/makefiles/root.in > > Log: > [perl6] > - add suffixe .exe on Win32 I'm not sure about this change. None of our other Makefile targets have file extensions, and if this stays, we have to say "run make perl6 if you're on a Unixy platform and make perl6.exe if you're not". As far as I know, pbc_to_exe generates file with the appropriate suffix, or not. If that doesn't work, it seems like that's where any fixes should go. -- c
Sequential bias in S04 (and Perl6 in general)
I was reading Synopsis 4 with regards to multi core programming. It
seems to be infused with a bias towards non-parallel models of
computation. Concurrently appears to be an add-on feature -- whereas we
should have a mindset that explicit sequential constraints are the
add-on feature.
Two statements that are missing from S04 (feel free to change the names)
are C; and a form of C that tests/executes multiple
C clauses in arbitrary order (without needing the sequential
C statement).
forall @a -> $x { ... }
runs the code block on each element of @a (no defined order). If @a is a
lazy generator then generation of values is concurrent with running the
code block on those generated values).
forall @a -> $x : sequential { ... }
forces an additional sequential constraint on the execution, such that
the Nth element of @a is not obtained until the code block has executed
for the (N-1)th. C is an alias for this constrained variant. C
implies this sequential constraint to avoid surprising legacy (perl5)
programmers.
Similarly, C, C, C, C, ... should all
accept this ":sequential" adverb to force them to iterate their lists
sequentially -- and should otherwise iterate in arbitrary/concurrent order.
given $x :all { ... }
would run the code blocks of all C statements (in the C
block) which smart-match true against $x. The ":sequential" adverb would
be used to constrain execution of the C blocks to run in the order
they appear in the source code. (it would be good if the current
C could be thought of as using a ":first" modifier, which runs
the code block of the lexically first C clause that evaluates to
true -- but which potentially tests multiple C clauses in
parallel. Unfortunately the current language definition is much too
sequential for this viewpoint)
I'm not too concerned about the exact details: my point is that we
should be fully aware of the fact that perl6 will be released into a
multicore (some people use the term many-core for devices with hundreds
of cores) world, and that exploitation of these parallel resources
should be the default (easy) behavior. We shouldn't have a "concurrency"
synopsis (we don't -- but we do have Spec/concurrency.pod). Instead, we
should have "sequential.pod" that defines how to impose additional
sequential constraints (e.g. ":atomic", ":sequential") on top of the
those inferred from data dependencies.
Even "threads" should actually be viewed as an explicit sequential
construct, and not as a construct for parallelization. The default
(easy) way of coding should exploit the available compute resources.
Telling the execution engine how to map the computation onto N
sequential resources is a constraint (optimization) that reduces
parallelism.
I'm not asking anyone to implement any concurrency beyond what is
currently planned for perl 6.0.0: I ask only for the language definition
to avoid making unnecessary guarantees of sequential behavior.
"sequential" is a perfectly reasonably interpretation of
"arbitrary/concurrent" ordering.
I'd be happy to go through and scrub the docs, if there was consensus
that it would be correct to do so. Unfortunately, doing so would
probably increase the future brittleness of the test suite -- because
existing tests may assume sequential behaviors, and it's difficult to
test for robustness against arbitrary ordering without actually
implementing arbitrary ordering.
Dave.
Re: Current status on Solaris 8/SPARC
Andy Dougherty wrote: After fixing various minor little things, here's where I stand on Solaris 8/SPARC after the recent changes. I have not identified any particular common theme. Do these ring any bells? Failed TestStat Wstat Total Fail List of Failed --- t/configure/115-auto_warnings-02.t7 179222 14 16-22 t/configure/115-auto_warnings-03.t7 179222 14 16-22 t/configure/115-auto_warnings-04.t7 179222 14 16-22 t/configure/115-auto_warnings-05.t8 204823 16 16-23 t/configure/115-auto_warnings-06.t8 204823 16 16-23 t/configure/115-auto_warnings-07.t9 230424 18 16-24 t/configure/146-auto_snprintf-01.t 13 332830 26 18-30 Could you open an RT ticket for these -- or perhaps one for auto::warnings and one for aut::snprintf? I will then re-work the tests, as I have a general idea of the problem. What also would be helpful: (1) Output of prove -v on these. (2) How did you configure? I.e., which (of your many!) perls did you use? which command-line options? any interactive configuration? Thank you very much.
Re: Testing asynchronous code
From: "Klaas-Jan Stol" <[EMAIL PROTECTED]> Date: Wed, 2 Jan 2008 16:16:26 +0100 what about "joining" threads, and comparing the output at those points? For async IO, a join is more or less implemented by a "wait" operation, no? (or the parrot equivalent for that). just a thought. kjs Is it acceptable for each line to be a unit? If so, then each thread could be written to use a distinct tag, and the output comparator can insist on the order only within lines with the same tag. For example: T1:1 T2:alarm1 T1:2 T2:alarm2 T1:3 T3:alarm3 T2:alarm1 T4:alarm3 . . . Of course, each line would need to be printed atomically, e.g. by constructing it as a string first. -- Bob
Re: Multiline comments in Perl6
Jonathan Lang wrote: > How about '~#', meaning something along the lines of "string-like > comment"? The idea is that the syntax that follows this would conform > closely to that of string literals (i.e., quotes). We might even > consider loosening the restrictions on delimiter characters, allowing > the full versatility of quoting delimiters, since there'd no longer be > any danger of confusing this with a line comment. So: For the record: if this gets implemented as I'm describing above, I will personally restrict myself to using bracketing characters as the delimiters. Non-bracketing delimiters have issues that, as a programmer, I don't want to have to deal with: e.g., if I were to use '~#/ ... /' to comment out a block of code, I'd have to be very sure that said code doesn't do any division. This is still a problem with brackets, but less so - especially with the ability to double up (or more) on the brackets. E.g., '~#[[ ... ]]' pretty much guarantees that I'll comment out exactly what I want to comment out on the first try. Oh, and I just realized: '~#( ... )' looks a bit like an ascii-graphics thought bubble, as used in old text-based MUXs. If '~#' gets nixed, perhaps 'oO' would be a viable alternative? $x = oO(here's a comment) 5; -- Jonathan "Dataweaver" Lang
Re: [perl #49296] Make perl6 support -e
On Tue, Jan 01, 2008 at 11:15:57PM -0800, Andy Lester wrote: > # http://rt.perl.org/rt3/Ticket/Display.html?id=49296 > > > perl6 -e"say 'hello world'" should work. Oddly(?), the question of standard options to Perl 6 implementations also came up in today's Perl 6 design meeting. I believe Larry said he would spend some time thinking about it and come up with some standards (I'm guessing it'll become Synopsis 19). I would expect -e to continue to be supported, however. I'm also thinking that perhaps -e, -v, and -h are common enough that they could be implemented by default in the base PCT::HLLCompiler object. (Individual language implementations could of course override the default.) Thanks! Pm
Re: [perl #49292] Make perl6 support -h
On Tue, Jan 01, 2008 at 11:15:07PM -0800, Andy Lester wrote: > # http://rt.perl.org/rt3/Ticket/Display.html?id=49292 > > The -h should provide a list of help. See also the comments about Perl 6 standard command line options in RT#49296. Pm
[perl #43269] [BUG] setline is tied to PIR source
On Wed Jun 20 16:23:40 2007, pmichaud wrote: > On Thu, Jun 21, 2007 at 12:08:33AM +0100, Jonathan Worthington wrote: > > Patrick R.Michaud (via RT) wrote: > > >The 'setline' opcode doesn't do what I expect it to do, which > > >is to associate runtime errors with lines in HLL source. > > > > Currently HLL debug info stuff is spec'd, but not implemented. Well, OK, > > the storage of it in bytecode is spec'd, the exact PIR syntax for it > > isn't. So there are two tasks: implement the underlying storage model > > for this and sort out some PIR syntax for it. > > > > How important/blocking is this to you? I can direct some tuits this way > > in the near future if you're needing it. > > Well, it's not too big a block for me personally. But for > many other people who are now starting to work on testing > the perl6 compiler or building the compiler itself, it's > hugely frustrating (and I can understand that). > ... > Personally, unless fixing this is very easy/straightforward I'd > _much_ prefer to see some of the pdd15 items completed first. Now that the pdd15 items are completed, and we're getting a lot more people programming in HLLs on Parrot (NQP, perl6, more coming), it would be good to have this soon if possible. Or, if it's not likely to appear soon, then PCT should start looking into a workaround of some sort. Thanks! Pm
Re: [perl #49294] Make perl6 support -v
On Tue, Jan 01, 2008 at 11:15:34PM -0800, Andy Lester wrote: > # New Ticket Created by Andy Lester > # Please include the string: [perl #49294] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=49294 > > > perl6 -v should provide a version statement. See also the comments about Perl 6 standard options in RT#49296. Pm
