Re: Re: Namespaces Redux
On Fri, Jun 30, 2006 at 10:50:58PM -0700, Matt Diephouse wrote: Chip Salzenberg [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote: Tcl uses C .namespace [''] to refer to the root namespace (correctly, I think) and I can't think of any language that would want to differentiate between the two. All you need to disprove this speculation is one counterexample, and the counterexample doesn't even have to exist yet. Fair enough. But one question remains: how do you tell IMCC that you want to be in the root HLL namespace? C .namespace [] is a parse error. No answer for you yet. Bug report on that one, please; at first blush I think the solution is that .namespace without parameters should be the root, or that some pseudo-HLL, perhaps the default parrot one, should have the root namespace as its HLL namespace. Also, is there any reason we can't/shouldn't add find_global variants that lookup globals in HLL's? Right now we have find_global_p_p_s. Adding find_global_p_s_p_s would let me reach into Tcl's private very easily instead of having to crawl the namespaces myself. It's three steps rather than one, but it's not crawling, and it's already in the pdd, mostly: .local pmc tcl tcl = compreg tcl .local pmc ns ns = tcl.'get_namespace'(['Foo';'Bar']) I'm cheating a little here because I'm showing you an example with a key (which the docs don't specifically allow) rather than an array (which they do allow), but the point is to demonstrate compiler.get_namespace(). This doesn't work for *private* namespaces -- only public ones. ParTcl currently uses a macro to crawl its private namespaces, which AFAIK is the *only* way to access the helper subs it has in private namespaces. Oh. Well, if tcl is looking up its _own_ private namespace, and if I understand what you mean by private namespace (that's not a standard Parrot term of art), and (IIRC) Tcl namespaces are untyped, then you can take advantage of the untyped interface which accepts (or should accept!) a multi-dimensional key: .local pmc private_ns private_ns = get_namespace '_tcl' ... .local private_foo_bar private_foo_bar = private_ns['Foo';'Bar'] -- Chip Salzenberg [EMAIL PROTECTED]
[perl #39674] There's no way to specify the root HLL namespace
# New Ticket Created by Matt Diephouse # Please include the string: [perl #39674] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39674 There''s no way to say that you want the root HLL namespace -- and there needs to be. .namespace [] and .namespace are both parse errors. .namespace [''] specifies the '' namespace (which is different). -- Matt Diephouse
[perl #39671] [PATCH]#38469: [BUG] -O1 branch optimization
# New Ticket Created by Vishal Soni
# Please include the string: [perl #39671]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39671
This transaction appears to have no contentThis patch fixes the branch reorganization failing for tail recursion.
Previously.
---
$ ./parrot -Oc ack.pir 3
Ack(3, 3) = 61
$ /parrot -Oc1 ack.pir 3
maximum recursion depth exceeded (According to Leo)
But on Linux I was getting a segfault.
After
--
$ ./parrot -Oc ./examples/shootout/ack.pir 3
Ack(3, 3) = 61
$ ./parrot -Oc1 ./examples/shootout/ack.pir 3
Ack(3, 3) = 61
Thanks,
Vishal
Index: CREDITS
===
--- CREDITS (revision 13046)
+++ CREDITS (working copy)
@@ -470,3 +470,7 @@
N: Norman Nunley
D: Shaving a Ponie
E: [EMAIL PROTECTED]
+
+N: Vishal Soni
+E: [EMAIL PROTECTED]
+D: Bug fixes in IMCC
Index: compilers/imcc/optimizer.c
===
--- compilers/imcc/optimizer.c (revision 13046)
+++ compilers/imcc/optimizer.c (working copy)
@@ -932,7 +932,7 @@
}
/* this was screwing up multi-block loops... */
-if (end != ins) {
+if (end != ins ins-next !=NULL ) {
ins-next-prev = end;
start-prev-next = end-next;
if (end-next)
--
Thanks,
Vishal
Index: CREDITS
===
--- CREDITS (revision 13046)
+++ CREDITS (working copy)
@@ -470,3 +470,7 @@
N: Norman Nunley
D: Shaving a Ponie
E: [EMAIL PROTECTED]
+
+N: Vishal Soni
+E: [EMAIL PROTECTED]
+D: Bug fixes in IMCC
Index: compilers/imcc/optimizer.c
===
--- compilers/imcc/optimizer.c (revision 13046)
+++ compilers/imcc/optimizer.c (working copy)
@@ -932,7 +932,7 @@
}
/* this was screwing up multi-block loops... */
-if (end != ins) {
+if (end != ins ins-next !=NULL ) {
ins-next-prev = end;
start-prev-next = end-next;
if (end-next)
[svn:parrot-pdd] r13083 - in trunk: . docs/pdds
Author: chromatic
Date: Fri Jun 30 21:13:22 2006
New Revision: 13083
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
[EMAIL PROTECTED]: chromatic | 2006-06-30 21:13:10 -0700
Fixed POD formatting errors causing test failures.
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podFri Jun 30 21:13:22 2006
@@ -40,6 +40,8 @@
These are the opcodes relevant to exceptions and exception handlers:
+=over
+
=item B push_eh ILABEL {{FIXME - Not Available Yet}}
=item B push_eh ICONTINUATION
Re: [svn:perl6-synopsis] r9727 - doc/trunk/design/syn
On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +In particular, these forms disable the lookahead for an adverbial argument, +so while + +q:n($foo) + +will misinterpret C$foo as the C:n argument, + +qn(stuff) + +has the advantage of misinterpreting it as the argument to the Cqn() +function instead. C:) + +But parens are special that way. Other bracketing characters are special +only if they can be mistaken for adverbial arguments, so + +qn[stuff] + +is fine, while + +q:n[stuff] + +is not. Basically, just don't use parens for quote delimiters, and always +put a space after your adverbs. Why q:n[stuff] is not fine? Shouldn't that pass [stuff] to adverb n? Also, in what way are parens special? Doesn't qn(stuff) and qn[stuff] both mean same thing? And both q:n(stuff) and q:n[stuff] pass something to adverb n. (First passes stuff, second passes [stuff]) -- Markus Laire
pdd23: closure vs. continuation
From: Chip Salzenberg [EMAIL PROTECTED] Date: Fri, 30 Jun 2006 22:11:39 -0500 . . . Allison, if you give me the OK, I'll recast pdd23 in the alternative way I had in mind, where: * exception handlers are closures, * the closures are called _inside_ the dynamic scope where the throw occurred, * a closure returning without executing Ccaught implies I didn't handle it, try the next handler, therefore obviating the rethrow opcode. PS: caught will perhaps be better renamed handled. -- Chip Salzenberg [EMAIL PROTECTED] I'm still trying to catch up, but IMHO, this is all to the good. -- Bob
test of get_namespace opcode vs. arrays
On Sat, Jul 01, 2006 at 12:22:56AM -0700, [EMAIL PROTECTED] wrote: Another FAILING namespace test: $P0 = new .ResizableStringArray $P0[0] = '' $P1 = get_namespace $P0 I think I (or the pdd) may have been misunderstood: The get_namespace opcode currently accepts keys (and strings). The compiler.'get_namespace'() method accepts arrays. So unless I've missed something in the purpose of your test, it's testing behavior that Parrot isn't trying to provide. -- Chip Salzenberg [EMAIL PROTECTED]
Welcome to parrot-porters
Since Parrot's mission is far bigger (and, in some ways, far smaller :-)) than Perl 6, and I like the idea that the project advertise itself truthfully, so as not to turn away those who aren't interested in Perl: at my request Robert has set up the alias [EMAIL PROTECTED] - perl6-internals@perl.org as a first step that will eventually lead to the list itself being renamed. The old p6i address will always work too. Share Enjoy! -- Chip Salzenberg [EMAIL PROTECTED]
Re: Welcome to parrot-porters
Here at the tail end of the Hackathon, Patrick suggests that while p6i is no longer descriptive, it does have the advantage of abbreviating to a nify token (i.e. p6i). So what, he asks, should be the abbreviation for parrot-porters? Seems to me that common usage will settle out for itself -- there are things too small even for a detail maven like myself to dictate. So it's obviously a sign of detailitis gone awry for me to mention p^2, or refer to the more pedestrian p-p as a safer alternative. Boy, I'm glad I don't concern myself with such minutiae. PS: Yes I really am coding this morning too. :-P -- Chip Salzenberg [EMAIL PROTECTED]
Java's Scripting Framework information
At Chip's YAPC talk, I mentioned that Java would soon be adding support directly to the language for scripting languages in their Java 6 or 1.6 release. Finding actual Sun documentation on the framework has been a little tough, but here's a sampling of a few articles that have been written just to see how things compare. It still seems that Java is still very much in control, but, as the JSR title says, this is really about the web and embedding other languages into JSP. Build your own scripting language for Java - http://www.javaworld.com/javaworld/jw-04-2006/jw-0424-scripting.html The Mustang Meets the Rhino: Scripting in Java 6 - http://www.onjava.com/pub/a/onjava/2006/04/26/mustang-meets-rhino-java-se-6-scripting.html JSR 223: Scripting for the Java Platform - http://www.jcp.org/en/jsr/detail?id=223 Steve Peters [EMAIL PROTECTED]
Re: test of get_namespace opcode vs. arrays
Chip Salzenberg [EMAIL PROTECTED] wrote: On Sat, Jul 01, 2006 at 12:22:56AM -0700, [EMAIL PROTECTED] wrote: Another FAILING namespace test: $P0 = new .ResizableStringArray $P0[0] = '' $P1 = get_namespace $P0 I think I (or the pdd) may have been misunderstood: The get_namespace opcode currently accepts keys (and strings). The compiler.'get_namespace'() method accepts arrays. So unless I've missed something in the purpose of your test, it's testing behavior that Parrot isn't trying to provide. At the top of the pdd: - Add a get_namespace opcode (that takes an --array-- or a multidimensional hash index) A bit further down: =item $P0 = get_namespace $P1 =item $P0 = get_namespace Get the namespace $P1 (an --array-- of names or a multidimensional hash index) or the current namespace. To get the Foo::Bar namespace, one would use this: $P0 = split ::, Foo::Bar $P1 = get_namespace $P0 It's definitely in the pdd; even the example here uses arrays (not too surprising, since I wrote it. ;-). Arrays are the easiest way to be able to get a namespace at runtime... which translates to the easiest way for Tcl to use namespaces. -- matt diephouse http://matt.diephouse.com
Re: pdd23: closure vs. continuation
Chip Salzenberg wrote: Allison, if you give me the OK, I'll recast pdd23 in the alternative way I had in mind, where: * exception handlers are closures, * the closures are called _inside_ the dynamic scope where the throw occurred, * a closure returning without executing Ccaught implies I didn't handle it, try the next handler, therefore obviating the rethrow opcode. Thumbs up. PS: caught will perhaps be better renamed handled. Agreed. Allison
[svn:parrot-pdd] r13092 - trunk/docs/pdds
Author: chip
Date: Sat Jul 1 11:26:02 2006
New Revision: 13092
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
* Exception handlers are now closures (or just plain subroutines),
not continuations.
* Eliminate the Crethrow opcode, as the handler returning is enough
of a clue that the next handler should be called.
(This change is at Allison Patrick's request, and in accord with Audrey's
not requesting otherwise. :-))
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 1 11:26:02 2006
@@ -42,26 +42,29 @@
=over
-=item B push_eh ILABEL {{FIXME - Not Available Yet}}
+=item B push_eh ISUB_LABEL
-=item B push_eh ICONTINUATION
+=item B push_eh IINVOCABLE_PMC
-The Cpush_eh opcode pushes a continuation onto the exception handler stack.
+Push an invocable PMC -- usually a closure or, in rarer cases, a subroutine --
+onto the exception handler stack.
-If a ILABEL is provided, Parrot automatically performs the equivalent of a
-Cnewcontinuation operation on the given label, and pushes the resulting
-continuation.
-
-{{FIXME - there is no newcontinuation opcode ... yet! In the meantime, you
-have to create the continuations the old-fashioned way.}}
+If a ISUB_LABEL is provided, Parrot automatically performs the equivalent of
+a Cnewclosure operation on the given subroutine, and pushes the resulting
+closure.
When an exception is thrown, Parrot walks up the stack of active exception
-handlers, invoking each one in turn. (See Crethrow and Ccaught.)
+handlers, invoking each one in turn, but still in the dynamic context of the
+exception (i.e. the call stack is Inot unwound first). See below for more
+detail.
=item B pop_eh
-The Cpop_eh opcode removes the most recently pushed exception handler from
-the control stack.
+Pop the most recently pushed exception handler off the control stack.
+
+{{ TODO: should we provide a pop_eh $P0 variant returning the address, since
+it's easy and somebody might find it useful? Or is it more important to
+provide generic control stack introspection? Probably the latter. }}
=item B throw IEXCEPTION
@@ -87,14 +90,15 @@
continuation at the next opcode. Active exception handlers (if any) will be
invoked with IEXCEPTION and the given continuation as parameters.
-Exception handlers can resume execution immediately after this opcode by
-executing the Ccaught opcode, and then invoking the given continuation.
-
-{{TODO: May the continuation be invoked with values, or in other words, can
-throwcc return a value?}}
-
-Except for the taking of a continuation which is passed to exception handlers,
-Cthrowcc is just like Cthrow.
+Except for its taking of a continuation which is then passed to exception
+handlers, Cthrowcc is just like Cthrow. This opcode is useful for
+exceptions that are more like warnings or notices than errors.
+
+Exception handlers can resume execution immediately after the Cthrowcc
+opcode by executing the Ccaught opcode, and then invoking the given
+continuation which they receive as a paremter. That continuation must be
+invoked with no parameters; in other words, Cthrowcc may Inot return a
+value.
=item Bdie [ IMESSAGE ]
@@ -119,17 +123,12 @@
as a status to its embedded environment, or when running standalone,
to execute the C function Cexit(IEXITCODE).
-=item B rethrow
-
-While handling an exception, stop execution and move on to the next exception
-handler, if any. This opcode is an exception handler's way of telling Parrot
-that it cannot handle the exception.
-
=item B caught
-While handling an exception, tell Parrot that the exception has been handled
-and should be removed from the stack of active exceptions. This opcode is an
-exception handler's way of telling Parrot that it has handled the exception.
+While handling an exception, tell Parrot that the exception has been caught
+(handled) and should be removed from the stack of active exceptions. This
+opcode is an exception handler's way of telling Parrot that it has handled the
+exception.
=back
@@ -146,20 +145,22 @@
containing pointer to exception handler block
and exception PMC
(and possibly a continuation)
- invoke the handler's continuation
+ invoke the handler
+(note: this is still in the thrower's dynamic context)
-=item Crethrow
+=item if the handler returns normally:
find the exception handling in progress record
find the next exception handler
if found,
- invoke its continuation
- else if there is a continuation in the Exception Record (from Cthrowcc),
- invoke it (i.e. resume execution)
+ invoke it
+ else if there is a continuation in the Exception Record
+(because the throwing opcode was Cthrowcc),
+ invoke the ER's continuation (i.e. resume
[svn:parrot-pdd] r13093 - trunk/docs/pdds
Author: chip Date: Sat Jul 1 11:26:44 2006 New Revision: 13093 Modified: trunk/docs/pdds/pdd23_exceptions.pod Log: oops, restore namespace on exception class in example code Modified: trunk/docs/pdds/pdd23_exceptions.pod == --- trunk/docs/pdds/pdd23_exceptions.pod(original) +++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 1 11:26:44 2006 @@ -356,8 +356,8 @@ $P0 = new String $P0 = something bad happened - $P1 = new ['exception'], $P0 # create new exception object - throw $P1 # throw it + $P1 = new ['parrot';'exception'], $P0 # create new exception object + throw $P1 # throw it Exceptions are designed to work with the Parrot calling conventions. Since the return addresses of Cbsr subroutine calls and exception
[svn:parrot-pdd] r13094 - trunk/docs/pdds
Author: chip
Date: Sat Jul 1 11:30:02 2006
New Revision: 13094
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
rename 'caught' opcode to 'handled' for obscure reasons
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 1 11:30:02 2006
@@ -95,12 +95,12 @@
exceptions that are more like warnings or notices than errors.
Exception handlers can resume execution immediately after the Cthrowcc
-opcode by executing the Ccaught opcode, and then invoking the given
+opcode by executing the Chandled opcode, and then invoking the given
continuation which they receive as a paremter. That continuation must be
invoked with no parameters; in other words, Cthrowcc may Inot return a
value.
-=item Bdie [ IMESSAGE ]
+=item B die [ IMESSAGE ]
The Cdie opcode throws an exception of type Cexception;death with a
payload of IMESSAGE. If IMESSAGE is a string register, the exception
@@ -109,26 +109,25 @@
{{ TODO: What is the default when no IMESSAGE is given? }}
-If this exception is not caught, it results in Parrot returning an error
+If this exception is not handled, it results in Parrot returning an error
indication and the stringification of IMESSAGE to its embedding environment.
When running standalone, this means writing the stringification of IMESSAGE
to the standard error and executing the standard C function Cexit(1).
-=item Bexit [ IEXITCODE ]
+=item B exit [ IEXITCODE ]
Throw an exception of type Cexception;exit with a payload of IEXITCODE,
which defaults to zero, as an Integer PMC.
-If not caught, this exception results in Parrot returning IEXITCODE
+If not handled, this exception results in Parrot returning IEXITCODE
as a status to its embedded environment, or when running standalone,
to execute the C function Cexit(IEXITCODE).
-=item B caught
+=item B handled
-While handling an exception, tell Parrot that the exception has been caught
-(handled) and should be removed from the stack of active exceptions. This
-opcode is an exception handler's way of telling Parrot that it has handled the
-exception.
+While handling an exception, tell Parrot that the exception has been handled
+and should be removed from the stack of active exceptions. This opcode is an
+exception handler's way of telling Parrot that it has handled the exception.
=back
@@ -160,7 +159,7 @@
else,
terminate program a la Cdie
-=item Ccaught opcode
+=item Chandled opcode
pop and destroy Exception Record
Onward Upward: New Assignments
YAPC is, among other things, a wonderful opportunity to meet and talk face-to-face about things that concern us. This YAPC, one topic was how to get Parrot development on track to make it the VM we all believe it can be. One outcome of these discussions is a bit of a personnel shuffle, to wit: I'm pleased to announce that Allison Randal is taking over as architect of Parrot, and I'm being promoted to pumpking. Allison, of course, needs no introduction; as architect, she will flesh out the vision of a virtual machine for dynamic languages, that's been her primary interest from the beginning. I, on the other hand, am very happy to be diving back into the code where I've learned I'm the happiest. Writing specs and writing code are similar; but when you're done with code, there's a go button, and lights flash and wheels turn. It's the best toy set in the world. :-) So, to me, this is a promotion. Both Allison and I thank Leo for his service as pumpking. He's done a yeoman's job getting parrot releases regular and stable. We're very pleased that Leo is staying on to continue improving parrot internals. Now that I'm going to carry the release cycle burden, he'll have more opportunity to respond to language implementors' issues, making Parrot better for all. Onward upward! *Squawk*! -- Chip Salzenberg [EMAIL PROTECTED]
[svn:perl6-synopsis] r9732 - doc/trunk/design/syn
Author: larry Date: Sat Jul 1 12:20:14 2006 New Revision: 9732 Modified: doc/trunk/design/syn/S05.pod Log: Deconfusing match state and state vars from Bruce Gray++. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podSat Jul 1 12:20:14 2006 @@ -14,18 +14,18 @@ Maintainer: Patrick Michaud [EMAIL PROTECTED] and Larry Wall [EMAIL PROTECTED] Date: 24 Jun 2002 - Last Modified: 30 June 2006 + Last Modified: 1 July 2006 Number: 5 - Version: 27 + Version: 28 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them Iregex because they haven't been regular expressions for a long time. When referring to their use in a grammar, the term Irule is preferred. -=head1 New match state and capture variables +=head1 New match result and capture variables -The underlying match state object is now available as the C$/ +The underlying match result object is now available as the C$/ variable, which is implicitly lexically scoped. All access to the current (or most recent) match is through this variable, even when it doesn't look like it. The individual capture variables (such as C$0,
Re: test of get_namespace opcode vs. arrays
On Sat, Jul 01, 2006 at 10:56:26AM -0700, Matt Diephouse wrote: At the top of the pdd: - Add a get_namespace opcode (that takes an --array-- or a multidimensional hash index) [...] =item $P0 = get_namespace $P1 Get the namespace $P1 (an --array-- of names or [...] Gee, you're right, there it is, and strangely enough, the code already supports this idiom [leo++]. I've just gone through the doc and made it more consistent on that point. The actual bug you've found seems unrelated to the use of the array of strings (vs. a key), as substituting the key version: $P0 = get_namespace [''] still fails. Debugging in progress. -- Chip Salzenberg [EMAIL PROTECTED]
[svn:parrot-pdd] r13097 - trunk/docs/pdds
Author: chip Date: Sat Jul 1 12:27:31 2006 New Revision: 13097 Modified: trunk/docs/pdds/pdd21_namespaces.pod Log: Consistently describe namespace identifiers accepted by namespace opcodes as either key constants or string arrays, since both of those work in all cases (or should :-)). Modified: trunk/docs/pdds/pdd21_namespaces.pod == --- trunk/docs/pdds/pdd21_namespaces.pod(original) +++ trunk/docs/pdds/pdd21_namespaces.podSat Jul 1 12:27:31 2006 @@ -18,8 +18,8 @@ =item - Namespaces should be hierarchical -=item - Add a get_namespace opcode (that takes an array or a multidimensional -hash index) +=item - The get_namespace opcode takes a multidimensional hash key or an array +of name strings =item - Namespaces follow the semantics of the HLL in which they're defined @@ -236,8 +236,8 @@ (that's Perl 5 syntax), then get_name() on that namespace returns an array of perl5, Some, Module. -NOTE: Due to aliasing, this value may be wrong, even if nobody's been playing -around with it. +NOTE: Due to aliasing, this value may be wrong -- i.e. it may disagree with +the namespace name with which you found the namespace in the first place. =back @@ -307,40 +307,46 @@ =item add_namespace $P0, $P1 -Add the namespace PMC $P1 as the namespace $P0 (an array of names or a -multidimensional hash index). +Add the namespace PMC $P1 under the name denoted by $P0 (an array of names or +a multidimensional hash index). =item del_namespace $P0 Delete the namespace $P0 (an array of names or a multidimensional hash index). -=item $P0 = find_global $P1, $S0 - -=item $P0 = find_global $S0 +=item $P0 = get_namespace -Find $P0 as the variable $S0 in the current namespace. or in $P1, relative -to the HLL root namespace. +Set $P0 to the current namespace (i.e. the namespace of the currently +executing subroutine). =item $P0 = get_namespace $P1 -=item $P0 = get_namespace +Get the namespace denoted by C$P1 (an array of names or a multidimensional +hash index) and store it in C$P0. -Get the namespace $P1 (an array of names or a multidimensional hash index) or -the current namespace. To get the Foo::Bar namespace, one would use this: +Thus, to get the Foo::Bar namespace, if the name is known at compile time, +one could use this opcode: - $P0 = split ::, Foo::Bar - $P1 = get_namespace $P0 + $P0 = get_namespace [Foo; Bar] -or this: +or, if the name is not known at compile time, this idiom: + + $P1 = split ::, Foo::Bar + $P0 = get_namespace $P1 + +=item $P0 = find_global $P1, $S0 + +=item $P0 = find_global $S0 - $P1 = get_namespace [Foo; Bar] +Find $P0 as the variable $S0 in the current namespace. or in $P1 (an array of +names or a multidimensional hash index), relative to the HLL root namespace. =item store_global $P1, $S0, $P0 =item store_global $S0, $P0 -Store $P0 as the variable $S0 in the current namespace, or in $P1, relative -to the HLL root namespace. +Store $P0 as the variable $S0 in the current namespace, or in $P1 (an array of +names or a multidimensional hash index), relative to the HLL root namespace. =back
[svn:perl6-synopsis] r9731 - doc/trunk/design/syn
Author: larry
Date: Sat Jul 1 12:13:49 2006
New Revision: 9731
Modified:
doc/trunk/design/syn/S03.pod
Log:
Revisions from Bruce Gray++.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Jul 1 12:13:49 2006
@@ -12,14 +12,17 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 30 Jun 2006
+ Last Modified: 1 Jul 2006
Number: 3
- Version: 43
+ Version: 44
=head1 Changes to existing operators
Several operators have been given new names to increase clarity and better
-Huffman-code the language, while others have changed precedence.
+Huffman-code the language, while others have changed precedence. (If an
+operator is not mentioned in this Synopsis, assume that it remains the
+same as in Perl 5. And if that doesn't make sense, assume this document
+is faulty. :)
=over
@@ -379,14 +382,16 @@
so C^Moose is short for CMoose.meta. It still kinda means what
is this thing's domain in an abstract sort of way.
-=item * The C... prefix operator is the
-yada, yada, yada operator, which is used as the body in function
-prototypes. It complains bitterly (by calling Cfail) if it is
-ever executed. Variant C??? calls Cwarn, and C!!! calls Cdie.
-The argument is optional, but if provided, is passed onto the Cwarn,
-Cfail, or Cdie. Otherwise the system will make up a message for
-you based on the context. We can't be responsible for what it might
-say.
+=item * The C... operator is the yada, yada, yada list operator,
+which is used as the body in function prototypes. It complains
+bitterly (by calling Cfail) if it is ever executed. Variant C???
+calls Cwarn, and C!!! calls Cdie. The argument is optional,
+but if provided, is passed onto the Cfail, Cwarn, or Cdie.
+Otherwise the system will make up a message for you based on the
+context, indicating that you tried to execute something that is
+stubbed out. (This message differs from what Cfail, Cwarn, and
+Cdie would say by default, since the latter operators typically point
+out bad data or programming rather than just an incomplete design.)
=item * In addition to the ordinary C. method invocation, there are
variants C.*, C.?, and C.+ to control how multiple related methods
@@ -809,9 +814,9 @@
=head1 Junctive operators
-C|, C, and C^ are no longer bitwise operators (see L/Operator
-Renaming) but now serve a much higher cause: they are now the
-junction constructors.
+C|, C, and C^ are no longer bitwise operators (see
+L/Changes to existing operators) but now serve a much higher cause:
+they are now the junction constructors.
A junction is a single value that is equivalent to multiple values. They
thread through operations, returning another junction representing the
@@ -892,8 +897,9 @@
state $foo # persistent lexical (cloned with closures)
constant $foo # lexically scoped compile-time constant
-Variable declarators such as Cmy now take a CSignature as their
-argument. The parentheses around the signature may be omitted for a
+Variable declarators such as Cmy now take a Isignature as their
+argument. (The syntax of function signatures is described more fully in S06.)
+The parentheses around the signature may be omitted for a
simple declaration that declares a single variable, along with its
associated type and traits. Parentheses must always be used when
declaring multiple parameters:
@@ -902,17 +908,30 @@
my ($b, $c); # okay
my $b, $c; # wrong: Use of undeclared variable: $c
-The syntax for a CSignature when one isn't expected is:
+[XXX the following probably belongs in S06.]
+The syntax for constructing a CSignature object when the parser isn't already
+expecting one is:
:(Dog $a, [EMAIL PROTECTED])
-The colon (and sometimes the parens) may be omitted within declarators
-where a signature is expected, for instance in the formal list of a loop
-block:
+This might be used like this:
+
+my $sig = :(Dog $a, [EMAIL PROTECTED]);
+
+Signatures are expected after declarators such as Cmy, Csub, Cmethod,
+Crule, etc. In such declarators the colon may be omitted. But it's
+also legal to use it:
+
+my :($b, $c); # okay
+sub foo :($a,$b) {...} # okay
+
+The C - pointy sub token also introduces a signature, but
+in this case you must omit both the colon and the parens. For instance,
+if you're defining the loop variable of a loop block:
for @dogpound - Dog $fido { ... }
-If a CSignature is assigned to (whether declared or colon form), the
+If a signature is assigned to (whether declared or colon form), the
signature is converted to a list of lvalue variables and the ordinary
rules of assignment apply, except that the evaluation of the right
side and the assignment happens at time determined by the declarator.
@@ -924,10 +943,10 @@
TAP::Harness
Those of you who were/are at the YAPC Hackathon might know, I've begun work on what started as Test::Harness 3 and is now TAP::Harness. This is brand new, ground up rewrite of the idea of a harness for TAP sources (a foo.t file is a TAP source). Its being designed to be extendable to handle all the things we'd like to do with Test::Harness over the last few years without having to worry about backwards compat. The design is currently a pile of sticky notes attached to my laptop and a little bit of code. chromatic, Andy, Adam Kennedy, Helen Cook and myself have been working on it here at the YAPC hackathon. I will post up a sketch of that design a bit later, I have to go get a plane shortly. For now, here's a PFAQ (Preemptive FAQ). * Why call it TAP::Harness? TAP focuses it on the fact that this is about the Test Anywhere Protocol, not just Perl's testing stuff. By not putting it in the Test:: namespace I hope to draw a stronger line between the responsibilities of things like Test::More (your test program) and TAP::Harness (the thing which runs and interprets your test program). Harness is a link with its forerunner, Test::Harness. * What about Test::Harness? Test::Harness remains its own thing. At some point in the future Test::Harness will likely be gutted and turned into a thin wrapper around TAP::Harness. I'm not caring about this right now. * Is it going to use Test::Harness::Straps? No. I will be stealing lots of code from Straps, but I will not be using Straps. Straps has too many design flaws. It tries to do too many parts of the TAP processing. It also doesn't do all the TAP processing leaving the Straps user to do some of that. And the callback system doesn't work very well. * Should I continue to work on Test::Harness? Yes. While I am optimistic, I make no promises as to when TAP::Harness is going to be stable. So keep working on Test::Harness, keep using Test::Harness::Straps. * Will TAP::Harness go into the core? Probably at some point. I don't care right now. * Will I be able to do X with TAP::Harness? The goal is to encompass the largest set of X. Another goal is to have the extender be able to focus on the display aspects and not the TAP parsing. Right now the use cases I have in mind include things such as parallelized test runs, fancy GUI and HTML outputs (for example, TAP::Model::HTMLMatrix), multiple, non-Perl TAP sources (ex. contact a URL and get the TAP from that; run HTML through a validator which produces TAP; run a C program which spits out TAP), enhanced TAP output (ex. colors; levels of verbosity), and the ability to smoothly handle TAP extensions. * Will TAP::Harness include X extension to TAP? No. TAP::Harness is using the current TAP spec from Test::Harness::TAP. Extending TAP is another problem. * Will I be able to test X (HTML, PHP, Javascript, Monkeys...) with TAP::Harness? Yes. You will be able to write new TAP source plugins for whatever you want. As long as it winds up producing a stream of TAP at the end. * Where's the code? svn.schwern.org. There's not a whole lot there yet. * How can I help? Provide use cases, what would you want to do with Test::Harness if you could? What are you doing with Straps? What features do other testing systems (JUnit, for example) have that you'd like to see in Perl? Once I post the design, pick it to pieces.
Re: TAP::Harness
This might seem like an odd question but will it be tightly tied to TAP or will it be possible to use another protocol or an extension to TAP? F On 01/07/06, Michael G Schwern [EMAIL PROTECTED] wrote: Those of you who were/are at the YAPC Hackathon might know, I've begun work on what started as Test::Harness 3 and is now TAP::Harness. This is brand new, ground up rewrite of the idea of a harness for TAP sources (a foo.t file is a TAP source). Its being designed to be extendable to handle all the things we'd like to do with Test::Harness over the last few years without having to worry about backwards compat. The design is currently a pile of sticky notes attached to my laptop and a little bit of code. chromatic, Andy, Adam Kennedy, Helen Cook and myself have been working on it here at the YAPC hackathon. I will post up a sketch of that design a bit later, I have to go get a plane shortly. For now, here's a PFAQ (Preemptive FAQ). * Why call it TAP::Harness? TAP focuses it on the fact that this is about the Test Anywhere Protocol, not just Perl's testing stuff. By not putting it in the Test:: namespace I hope to draw a stronger line between the responsibilities of things like Test::More (your test program) and TAP::Harness (the thing which runs and interprets your test program). Harness is a link with its forerunner, Test::Harness. * What about Test::Harness? Test::Harness remains its own thing. At some point in the future Test::Harness will likely be gutted and turned into a thin wrapper around TAP::Harness. I'm not caring about this right now. * Is it going to use Test::Harness::Straps? No. I will be stealing lots of code from Straps, but I will not be using Straps. Straps has too many design flaws. It tries to do too many parts of the TAP processing. It also doesn't do all the TAP processing leaving the Straps user to do some of that. And the callback system doesn't work very well. * Should I continue to work on Test::Harness? Yes. While I am optimistic, I make no promises as to when TAP::Harness is going to be stable. So keep working on Test::Harness, keep using Test::Harness::Straps. * Will TAP::Harness go into the core? Probably at some point. I don't care right now. * Will I be able to do X with TAP::Harness? The goal is to encompass the largest set of X. Another goal is to have the extender be able to focus on the display aspects and not the TAP parsing. Right now the use cases I have in mind include things such as parallelized test runs, fancy GUI and HTML outputs (for example, TAP::Model::HTMLMatrix), multiple, non-Perl TAP sources (ex. contact a URL and get the TAP from that; run HTML through a validator which produces TAP; run a C program which spits out TAP), enhanced TAP output (ex. colors; levels of verbosity), and the ability to smoothly handle TAP extensions. * Will TAP::Harness include X extension to TAP? No. TAP::Harness is using the current TAP spec from Test::Harness::TAP. Extending TAP is another problem. * Will I be able to test X (HTML, PHP, Javascript, Monkeys...) with TAP::Harness? Yes. You will be able to write new TAP source plugins for whatever you want. As long as it winds up producing a stream of TAP at the end. * Where's the code? svn.schwern.org. There's not a whole lot there yet. * How can I help? Provide use cases, what would you want to do with Test::Harness if you could? What are you doing with Straps? What features do other testing systems (JUnit, for example) have that you'd like to see in Perl? Once I post the design, pick it to pieces.
Re: TAP::Harness
On Sat, Jul 01, 2006 at 08:45:02PM +0100, Fergal Daly wrote: This might seem like an odd question but will it be tightly tied to TAP or will it be possible to use another protocol or an extension to TAP? Pluggable testing protocols, perhaps. They would need to follow some similar ground rules, though. Steve Peters [EMAIL PROTECTED]
[svn:parrot-pdd] r13098 - trunk/docs/pdds
Author: chip Date: Sat Jul 1 13:00:41 2006 New Revision: 13098 Modified: trunk/docs/pdds/pdd21_namespaces.pod Log: Specify new compiler methods, compiler.'parse_name'(), which allows parsing foreign language names using the foreign language's rules. (per Allison) [Tests Welcome] Modified: trunk/docs/pdds/pdd21_namespaces.pod == --- trunk/docs/pdds/pdd21_namespaces.pod(original) +++ trunk/docs/pdds/pdd21_namespaces.podSat Jul 1 13:00:41 2006 @@ -247,11 +247,20 @@ =over 4 +=item $P0 = parse_name($S0) + +Parse the name in $S0 using the rules specific to the given compiler, and +return an array of individual name elements. + +For example, a Java compiler would turn 'a.b.c' to ['a','b','c'], while a Perl +compiler would turn 'a::b::c' into the same result. Meanwhile, due to Perl's +sigil rules, '$a::b::c' would become ['a','b','$c']. + =item get_namespace($P0) -Ask this compiler to find its namespace named by the elements of the array in -$P0. Returns namespace PMC on success and null PMC on failure. Note that a -null PMC or an empty array requests the HLL's base namespace. +Ask this compiler to find its namespace which is named by the elements of the +array in $P0. Returns namespace PMC on success and null PMC on failure. Note +that a null PMC or an empty array requests the HLL's base namespace. This method allows other HLLs to know one name (the HLL) and then work with that HLL's modules without having to know the name it chose for its namespace
Re: TAP::Harness
On Jul 1, 2006, at 2:45 PM, Fergal Daly wrote: This might seem like an odd question but will it be tightly tied to TAP or will it be possible to use another protocol or an extension to TAP? Yes. It is about TAP. That's why it's TAP::Harness. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP::Harness
On Sat, Jul 01, 2006 at 02:36:37PM -0500, Michael G Schwern wrote: Right now the use cases I have in mind include things such as parallelized test runs, fancy GUI and HTML outputs (for example, Provide use cases, what would you want to do with Test::Harness if you could? What are you doing with Straps? What features do other Use case: Parallel test runs I'd like to be able to specify parallel test runs. Specifically, I'd like to be able to send tests as a set of groups, with instructions on how the tests are to be parallelised. I already have a prototype, hacked from Test::Harness. 1: Send tests as groups 2: Tests within a group run in series (in traditional order) 3: Groups run in parallel 4: have sync points. All groups before a sync point must complete before any groups after a sync point can start. This let me run many of the core tests in parallel, but still allowed the tests that need to run in order to run in order. This level of control let me run the core tests as follows: t/base/*.t one by one (each test is its own group, sync point between each group) t/comp/*.t t/cmd/*.t t/run/*.t t/io/*.t t/op/*.t tests in each directory in sequence, but the 5 directories in parallel wait for all these to finish t/uni/*.t, all tests in ext and lib tests in a the same directory ran in series. All directories could run in parallel With this I can max out a multi CPU (or multi core) box. (Or at least stand a fighting chance, although tests in t/op/*.t in the core need some issues fixing before they can run in parallel with each other. I suspect that their names for temporary files are unimaginative and therefore clash) I've got the code for a select driven event loop that can run all this, if that's helpful. Nicholas Clark
Re: TAP::Harness
On 01/07/06, Andy Lester [EMAIL PROTECTED] wrote: On Jul 1, 2006, at 2:45 PM, Fergal Daly wrote: This might seem like an odd question but will it be tightly tied to TAP or will it be possible to use another protocol or an extension to TAP? Yes. It is about TAP. That's why it's TAP::Harness. I'm none the wiser. So I'll just remark that, if possible, it would be nice if the protocol was pluggable, F xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:perl6-synopsis] r9727 - doc/trunk/design/syn
On Sat, Jul 01, 2006 at 03:31:52PM +0300, Markus Laire wrote: : On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: : +In particular, these forms disable the lookahead for an adverbial : argument, : +so while : + : +q:n($foo) : + : +will misinterpret C$foo as the C:n argument, : + : +qn(stuff) : + : +has the advantage of misinterpreting it as the argument to the Cqn() : +function instead. C:) : + : +But parens are special that way. Other bracketing characters are special : +only if they can be mistaken for adverbial arguments, so : + : +qn[stuff] : + : +is fine, while : + : +q:n[stuff] : + : +is not. Basically, just don't use parens for quote delimiters, and always : +put a space after your adverbs. : : Why q:n[stuff] is not fine? Shouldn't that pass [stuff] to adverb n? That's what it does. But it's not fine if you expected [...] to delimit the quoted string instead. : Also, in what way are parens special? : Doesn't qn(stuff) and qn[stuff] both mean same thing? Nope, qn(stuff) is always a function call. q(foo) is always a function call, not a quote. : And both q:n(stuff) and q:n[stuff] pass something to adverb n. (First : passes stuff, second passes [stuff]) That is correct. My intent with the quote declarator however is that there be an implicit space after it, so the n on the end of qn no longer functions as an adverb, at least in terms of looking for a subsequent argument. I will attempt to clarify the distinction between quotes and ordinary macros. Thanks. Larry
Re: Re: test of get_namespace opcode vs. arrays
Chip Salzenberg [EMAIL PROTECTED] wrote: The actual bug you've found seems unrelated to the use of the array of strings (vs. a key), as substituting the key version: $P0 = get_namespace [''] still fails. Debugging in progress. It looks like IMCC treats C .namespace [''] as the root HLL namespace (and not as the namespace '' inside of that). So that's where the bug really lies. mini:~/Projects/parrot mdiep$ cat test.pir .namespace [''] .sub main :main $P0 = get_namespace $P0 = $P0.'name'() $S0 = join ::, $P0 print $S0 print \n end .end mini:~/Projects/parrot mdiep$ parrot test.pir parrot mini:~/Projects/parrot mdiep$ -- matt diephouse http://matt.diephouse.com
Re: Re: test of get_namespace opcode vs. arrays
On Sat, Jul 01, 2006 at 01:30:40PM -0700, Matt Diephouse wrote: Chip Salzenberg [EMAIL PROTECTED] wrote: The actual bug you've found seems unrelated to the use of the array of strings (vs. a key), as substituting the key version: $P0 = get_namespace [''] still fails. Debugging in progress. It looks like IMCC treats C .namespace [''] as the root HLL namespace (and not as the namespace '' inside of that). So that's where the bug really lies. I've rooted out that bug, but then discovered there's no way left to designate the root HLL namespace, so I've invented .namespace # no key to mean the HLL root. Now it's a matter of making the tests all work (again). :-) -- Chip Salzenberg [EMAIL PROTECTED]
[svn:perl6-synopsis] r9733 - doc/trunk/design/syn
Author: larry
Date: Sat Jul 1 13:55:09 2006
New Revision: 9733
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S06.pod
Log:
Clarification of differences between quote and macro declarations, Markus++.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podSat Jul 1 13:55:09 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 10 Aug 2004
- Last Modified: 30 Jun 2006
+ Last Modified: 1 July 2006
Number: 2
- Version: 47
+ Version: 48
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -1361,8 +1361,8 @@
quote qTO = 'qq:x:w:to';# qq:x:w:to//
quote circumfix:❰ ❱ = q:code { .quoteharder }; # or some such...
-In particular, these forms disable the lookahead for an adverbial argument,
-so while
+In particular, all these forms disable the lookahead for an adverbial argument,
+as if there were a space after the keyword. So although
q:n($foo)
@@ -1373,23 +1373,42 @@
has the advantage of misinterpreting it as the argument to the Cqn()
function instead. C:)
-But parens are special that way. Other bracketing characters are special
-only if they can be mistaken for adverbial arguments, so
+But parens are special that way. (Even Cq() is assumed to be a
+function call rather than a quote.) Other bracketing characters are
+special only if they can be mistaken for adverbial arguments, so
qn[stuff]
-is fine, while
+is fine, and means
+
+q:n /stuff/
+
+while
q:n[stuff]
-is not. Basically, just don't use parens for quote delimiters, and always
-put a space after your adverbs.
+is not so fine, if the user intended stuff to be the string rather
+than an argument to C:n. Basically, you'll be fine if you just
+never use parens for quote delimiters, and always put a space after
+your adverbs.
If this is all too much of a hardship, you can define your own quote
-adverbs and operators as standard macros.
-All the uppercase adverbs are reserved for
-user-defined quotes. All of Unicode above Latin-1 is reserved for
-user-defined quotes.
+adverbs and operators as standard macros. The main difference is that,
+unlike
+
+quote qn = 'q:n';
+
+declaring something like
+
+macro qn { 'q:n' }
+
+does Inot disable the subsequent search for an argument to C:n. To
+get the equivalent, you need to add a space:
+
+macro qn { 'q:n ' }
+
+All the uppercase adverbs are reserved for user-defined quotes.
+All Unicode delimiters above Latin-1 are reserved for user-defined quotes.
=item *
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSat Jul 1 13:55:09 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 21 Mar 2003
- Last Modified: 30 June 2006
+ Last Modified: 1 July 2006
Number: 6
- Version: 38
+ Version: 39
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -2156,10 +2156,13 @@
the user. Syntax trees are also better in general because they are
reversible, so things like syntax highlighters can get back to the
original language and know which parts of the derived program come
-from which parts of the user's view of the program.
+from which parts of the user's view of the program. Nevertheless,
+it's difficult to return a syntax tree for an unbalanced construct,
+and in such cases a textual macro may be a clearer expression of the
+evil thing you're trying to do.
If you call a macro at runtime, the result of the macro is automatically
-evaluated again, so the two calls below prints the same thing:
+evaluated again, so the two calls below print the same thing:
macro f { '1 + 1' }
say f();# compile-time call to f
@@ -2261,7 +2264,9 @@
else.) Of course, the macro definition as a whole can expect
whatever it likes afterwards, according to its syntactic category.
(Generally, a term expects a following postfix or infix operator,
-and an operator expects a following term or prefix operator.)
+and an operator expects a following term or prefix operator. This
+does not matter for textual macros, however, since the reparse of
+the text determines subsequent expectations.)
Quasiquotes default to hygienic lexical scoping, just like closures.
The visibility of lexical variables is limited to the q:code expression
Re: TAP::Harness
On Saturday 01 July 2006 22:36, Michael G Schwern wrote: Those of you who were/are at the YAPC Hackathon might know, I've begun work on what started as Test::Harness 3 and is now TAP::Harness. This is brand new, ground up rewrite of the idea of a harness for TAP sources (a foo.t file is a TAP source). Its being designed to be extendable to handle all the things we'd like to do with Test::Harness over the last few years without having to worry about backwards compat. . . . * Will I be able to do X with TAP::Harness? The goal is to encompass the largest set of X. Another goal is to have the extender be able to focus on the display aspects and not the TAP parsing. Right now the use cases I have in mind include things such as parallelized test runs, fancy GUI and HTML outputs (for example, TAP::Model::HTMLMatrix), multiple, non-Perl TAP sources (ex. contact a URL and get the TAP from that; run HTML through a validator which produces TAP; run a C program which spits out TAP), enhanced TAP output (ex. colors; levels of verbosity), and the ability to smoothly handle TAP extensions. I can't readily think of other stuff now. One thing I'm wondering about is whether you are going to code all of this into TAP::Harness from scratch. Plus, I've also been planning similar things for Test::Run too, (and already started implementing to some extent) and I'd hate to see some duplicate effort. As some of the people who may know I like to start from an existing codebase when I can. This may be due to a bit of hacker's superstition as backed up by: http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html (Not to mention Things you should never do part 1 and Rub a dub dub by Joel Spolsky).[1] Now, I started Test::Run so it will be an incompatible Test::Harness-like module, only more modular, object oriented, pluginnable, etc. I found the Test::Harness code to be somewhat lacking in some respects, but believed (due to my superstition) that I can bang on it until it exceeds its current limitations. I hope the Test::Harness maintainers can understand that I had no intentions of fragmenting, but rather as a way to create a better harness. Test::Run still has many issues, but I think that it will still be easier to start from it than from an empty code. I didn't make a stable release of Test::Run yet, and would not recommend people to depend on its API being stable, so everybody's who's interested can go there and even break the API (as long as he also fixes the tests.) Refactoring and extension of existing code is much more brainless than starting to work on a brand-new codebase, and is more rewarding. Please do not consider this email as an attack against your attempt to write code or fix what's broken with Test::Harness. I don't mind having some competition. However, I'm trying to see whether there is some way we can consolidate our efforts. The most up-to-date Test-Run code is here: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/ I don't mind giving Subversion access to the repository to anyone who registers in http://developer.berlios.de/ and is either a CPAN contributor, or has sent me one patch for me to commit. With Adam Kennedy's permission, I can also move the files to his Subversion repository, where everyone with a PAUSE ID can commit to. A lightning talk I gave at two occassions (OSDC::Israel::2006 and an Israel.pm meeting) can be found here: http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/ * Will TAP::Harness include X extension to TAP? No. TAP::Harness is using the current TAP spec from Test::Harness::TAP. Extending TAP is another problem. It may be a good idea to have a parser that outputs an events' stream and an analyzer that reads and analyzes the events. Then we can have a different protocol than TAP. Regards, Shlomi Fish [1] - Another module which I did not write from scratch is HTML::Widgets::NavMenu. I was looking for alternatives on CPAN, found 3, and chose HTML::Widget::SideBar by Yosef Meller (a fellow Israel.PM-er). http://search.cpan.org/dist/HTML-Widget-SideBar/ Overtime I had to patch the module, subclass it and write some glue around it. Eventually, I wrote my tree-generation logic for generating a site map, and ported the rest of my code to it, leaving my module with none of Meller's original code. Would it have been easier to re-write everything from scratch? I can't tell for sure, but in any case, it was less intimidating to start from scratch. ESR has other stories like that. - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: TAP::Harness
On Saturday 01 July 2006 14:24, Shlomi Fish wrote: I'd hate to see some duplicate effort. Test::Run has really curious licensing; I'm not interested in redistributing that code under all of those licenses. -- c
Re: TAP::Harness
Please look at Test::TAP::Model and the horrrible hooks it goes through to make things work. I'd love to have a SAX like event-handler model for TAP through TAP::Harness so that I can construct Test::TAP::Model objects in a cleaner way (without the parser-is-the-model and all that mess). -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpcMgQCUTVKz.pgp Description: PGP signature
Re: Re: Re: test of get_namespace opcode vs. arrays
Chip Salzenberg [EMAIL PROTECTED] wrote: I've rooted out that bug, but then discovered there's no way left to designate the root HLL namespace, so I've invented .namespace # no key to mean the HLL root. That resolves the other ticket I opened yesterday (good). But I'd prefer to have C .namespace [] so that we could also have the matching C find_global [], 'foo' . Otherwise find_global becomes a two step operation for finding globals in the root HLL namespace. Oh, and I've committed some more failing tests. :-) -- matt diephouse http://matt.diephouse.com
S04
I picked this up at the YAPC and made some markups on it. Apologies that it is not in a diff format, but that's going to come with practice. I got stuck on some of the intended behaviors and prohibited behaviors of the 'goto' function. For the purpose of clarity would it be useful to provide a series of specific test cases (in perl 5) to identify what it does today and what (if anything) it will do differently? Thank you, Tom Allison
Re: TAP::Harness
On 7/1/06, Yuval Kogman [EMAIL PROTECTED] wrote: Please look at Test::TAP::Model and the horrrible hooks it goes through to make things work. I'd love to have a SAX like event-handler model for TAP through TAP::Harness so that I can construct Test::TAP::Model objects in a cleaner way (without the parser-is-the-model and all that mess). Yes, it is SAXy. You have Adam to thank for that. As my flight is delayed I'll try to make a stab at posting up the basic design.
Re: TAP::Harness
On 7/1/06, Steve Peters [EMAIL PROTECTED] wrote: On Sat, Jul 01, 2006 at 08:45:02PM +0100, Fergal Daly wrote: This might seem like an odd question but will it be tightly tied to TAP or will it be possible to use another protocol or an extension to TAP? Pluggable testing protocols, perhaps. They would need to follow some similar ground rules, though. Non TAP protocols are not a design goal. However, making it flexible enough to handle future versions of TAP, whatever they may be, may make it flexible enough to handle completely different protocols. Of course, lord knows what those protocols may be. There are at least two approaches I could think of that fit the existing design. One is to replace the tokenizer. The other is to create a TAP source which converts from your protocol into TAP. The latter is probably easiest and smoothest.
pdd21 vs. find_global
Darn, find_global has collided with pdd21. Currently find_global is prepared to accept a key or a namespace, and distinguishing namespaces from arrays is starting to get just a little too polymorphic for an opcode. I'm thinking that between get_namespace and the untyped namespace interface, find_global is obsolete. Where you would say $P0 = find_global key_or_array, 'foo' you change to $P99 = get_namespace key_or_array $P0 = $P99['foo'] which also incidentally encourages(!) compilers to cache namespace pointers. -- Chip Salzenberg [EMAIL PROTECTED]
Re: TAP::Harness
On Saturday 01 July 2006 14:52, Michael G Schwern wrote: There are at least two approaches I could think of that fit the existing design. One is to replace the tokenizer. The other is to create a TAP source which converts from your protocol into TAP. The latter is probably easiest and smoothest. How about writing to TAP's event model? Is that #3? -- c
Re: TAP::Harness
On 7/1/06, Shlomi Fish [EMAIL PROTECTED] wrote: One thing I'm wondering about is whether you are going to code all of this into TAP::Harness from scratch. I believe I mentioned, I intend to steal lots of code from Test::Harness and Straps. Steal in the cut paste sense. I have already adapted much of Straps-analyze_line as well as copied Point and Results wholesale. Folks might cringle at the cut paste, but I do not TAP::Harness to have any dependencies upon Test::Harness. Plus, I've also been planning similar things for Test::Run too, (and already started implementing to some extent) I glanced at Test::Run today and had two initial observations. 1) Your licensing is possibly incompatible. You're using a mix of MIT X11, BSD and Artistic. I'm not familiar with the former two. I can't use anything not licensed Perl style. For one, it will not be able to enter the core. 2) I think your model does not perform a clean enough break with Test::Harness compared to what I'm planning. I realize this claim is vapor until I post the design. PS You might want to fix your copyright notices. I thank you for retaining our copyright for our portions of the code you took from Test::Harness but we do not have copyright over Test::Run::Obj, for example. IANAL so I don't know what should be there, but it probably shouldn't just be me and Andy. I'd hate to see some duplicate effort. Sometimes you have to make a clean break with the past. The code in Test::Harness was started almost 20 years ago. That's right, t/TEST in Perl 1 became Test::Harness. Its designed along procedural lines and we've been trying to slowly morph it into a more flexible model over the years and still haven't succeeded. Its not a large or complex module, it should not take this long. Further, I think the duplication is healthy. Part of the problem with Test::Harness is its the only game in town. Its the only thing which can parse TAP. Its very bad for a protocol to have only one implementation. The monolithic and inflexible nature of Test::Harness has held back Perl testing in the last few years. Having more than one TAP harness implementation will be healthy. I'm starting over. You're free to do whatever you want. Please do not consider this email as an attack against your attempt to write code or fix what's broken with Test::Harness. I don't mind having some competition. However, I'm trying to see whether there is some way we can consolidate our efforts. Licencing issues mentioned above prevent any code sharing, but I'll look at your lightning talk and see what ideas I can steal.
TAP extension proposal: test groups
The PITA / TestBuilder2 BOF at YAPC whacked up this TAP extension. Test groups in TAP. There are several use-cases here. 1. I want to name a group of tests rather than the individuals. 2. I don't want to have to count up the total number of tests in my file but I do want the protection of the plan. I'd like to be able to say I'm going to run 5 tests. I'm going to run 4 more tests. Now 8 more. 3. The spew to STDERR from my code when it does something wrong cannot be associated with a single test. But if I had a test grouping I could associate it with that group. Here's what we came up with. 1..10 ..4 - name for this group ok 1 ok 2 ok 3 ok 4 ..2 - I will call this group Bruce ok 5 ok 6 ..4 ok 7 ok 8 ok 9 ok 10 Pros: * Its backwards compatible. The ..# lines are currently considered junk and ignored. * Its pretty readable. * It solves #1 * Combined with 'no_plan' it solves #2. ..2 ok 1 ok 2 ..3 ok 3 ok 4 ok 5 1..5 * It solves #3. 1..5 ..3 ok 1 Oh god, the hurting oh dear, oh god at Foo.pm line 23 not ok 2 # Failed test ... # got : this # expected: that ok 3 ..2 ok 4 ok 5 Cons?
Re: TAP::Harness
On 7/1/06, Yuval Kogman [EMAIL PROTECTED] wrote: Another issue we had at work when I was abusing TAP for our C++ UT framework was that we needed more levels of nesting (TAP only supports streams and test cases - I was handling many test cases in the same stream, for nested modules... I faked files on certain markers, and used simple name mangling for the nestedness). This is actually probably off topic, since TAP revisions are not explicitly asked for... Too bad I missed talking to you at the hackathon - if I had only thought about this we could have talked in meat-space. This sounds like the test group problem. Its known and we put together a TAP extension at the BOF. I'll post that separately.
Re: TAP::Harness
On Sat, Jul 01, 2006 at 16:59:24 -0500, Michael G Schwern wrote: Yes, it is SAXy. You have Adam to thank for that. As my flight is delayed I'll try to make a stab at posting up the basic design. Another issue we had at work when I was abusing TAP for our C++ UT framework was that we needed more levels of nesting (TAP only supports streams and test cases - I was handling many test cases in the same stream, for nested modules... I faked files on certain markers, and used simple name mangling for the nestedness). This is actually probably off topic, since TAP revisions are not explicitly asked for... Too bad I missed talking to you at the hackathon - if I had only thought about this we could have talked in meat-space. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpJMbWwaOVFC.pgp Description: PGP signature
[svn:parrot-pdd] r13096 - trunk/docs/pdds
Author: nicholas Date: Sat Jul 1 12:24:40 2006 New Revision: 13096 Modified: trunk/docs/pdds/pdd23_exceptions.pod Log: Fix two typos. Modified: trunk/docs/pdds/pdd23_exceptions.pod == --- trunk/docs/pdds/pdd23_exceptions.pod(original) +++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 1 12:24:40 2006 @@ -32,7 +32,7 @@ (A digression on terminology: In a system analysis sense, the word exception usually refers to the exceptional event that requires out-of-band handling. However, in Parrot, exception also refers to the object that holds all the -information describing hte exceptional condition: the nature of the exception, +information describing the exceptional condition: the nature of the exception, the error message describing it, and other ancillary information. The specific type (class) of an exception object indicates its category.) @@ -96,7 +96,7 @@ Exception handlers can resume execution immediately after the Cthrowcc opcode by executing the Chandled opcode, and then invoking the given -continuation which they receive as a paremter. That continuation must be +continuation which they receive as a parameter. That continuation must be invoked with no parameters; in other words, Cthrowcc may Inot return a value.
Re: [BUG] parrot 0.4.5: Configure.pl: tru64
Leopold Toetsch wrote: On Jun 29, 2006, at 18:48, Jarkko Hietaniemi wrote: Any way to add verbosity to e.g. see which commands are being run? perl Configure.pl --verbose-step=snprintf ... Testing snprintf...cc -std -D_INTRINSICS -fprm d -ieee -I/p/include -DLANGUAGE_C -pthread -D_XOPEN_SOURCE=500 -I./include -c test.c cxx -expect_unresolved '*' -O4 -msym -std -L/p/lib test.o -o test -lm -lutil -lpthread -laio -lrt -lgmp -lreadline ./test resolve_symbols: loader error: dlopen: libreadline.so.4: symbol tgetnum unresolved step auto::snprintf died during execution: Can't run the snprintf testing program: at config/auto/snprintf.pm line 33. cxx is the Tru64 C++ compiler. (1) I don't know all those -libraries are being listed, the test program certainly doesn't need them... yes, the linker should know to ignore them as unused... but: (2) This is not Linux so that -lgmp and -lreadline are not standard but have been compiled and installed by the sysadmins (not admin) and: (3) They most definitely have not been compiled with cxx, but most probably with gcc. And I have no idea whether the libreadline.so actually works, since I haven't lately tried to compile anything with it. In non-Linux systems one cannot always assume installed GNU stuff works and/or is uptodate... Therefore, I am not surprised by the runtime linker getting cranky when the ./test is being run. (I have no idea who tries to call tgetnum, certainly not test.c.) If I remove the -lreadline from the cxx line, the ./test works fine giving: borken snprintf: n = 1 as expected. I don't know how to start fixing this. leo
Re: TAP extension proposal: test groups
It looks like it's only one level of nesting. Any reason not to go the whole hog with something like ..1 OK 1 ..2 ...1 OK 2 OK 3 ...2 OK 4 ..3 OK5 F On 01/07/06, Michael G Schwern [EMAIL PROTECTED] wrote: The PITA / TestBuilder2 BOF at YAPC whacked up this TAP extension. Test groups in TAP. There are several use-cases here. 1. I want to name a group of tests rather than the individuals. 2. I don't want to have to count up the total number of tests in my file but I do want the protection of the plan. I'd like to be able to say I'm going to run 5 tests. I'm going to run 4 more tests. Now 8 more. 3. The spew to STDERR from my code when it does something wrong cannot be associated with a single test. But if I had a test grouping I could associate it with that group. Here's what we came up with. 1..10 ..4 - name for this group ok 1 ok 2 ok 3 ok 4 ..2 - I will call this group Bruce ok 5 ok 6 ..4 ok 7 ok 8 ok 9 ok 10 Pros: * Its backwards compatible. The ..# lines are currently considered junk and ignored. * Its pretty readable. * It solves #1 * Combined with 'no_plan' it solves #2. ..2 ok 1 ok 2 ..3 ok 3 ok 4 ok 5 1..5 * It solves #3. 1..5 ..3 ok 1 Oh god, the hurting oh dear, oh god at Foo.pm line 23 not ok 2 # Failed test ... # got : this # expected: that ok 3 ..2 ok 4 ok 5 Cons?
Re: pdd21 vs. find_global
Chip Salzenberg wrote: Darn, find_global has collided with pdd21. Currently find_global is prepared to accept a key or a namespace, and distinguishing namespaces from arrays is starting to get just a little too polymorphic for an opcode. I'm thinking that between get_namespace and the untyped namespace interface, find_global is obsolete. Where you would say $P0 = find_global key_or_array, 'foo' you change to $P99 = get_namespace key_or_array $P0 = $P99['foo'] which also incidentally encourages(!) compilers to cache namespace pointers. I'm more inclined to say find_global just shouldn't accept a namespace PMC as an argument. I really don't want to eliminate the form that pulls a variable from the currently selected namespace: $P0 = find_global 'foo' (The namespace is already cached for you, so it doesn't make sense to retrieve it and cache it manually.) And if you keep the one-argument form, it makes sense to keep the two-argument form. (Though, there's likely a better name for it than 'find_global'. Like, 'find_symbol', or 'get_symbol'.) Any changes to find_global should also apply to store_global, since they're a matched pair. Allison
Re: Onward Upward: New Assignments
On Jul 1, 2006, at 1:40 PM, Chip Salzenberg wrote: One outcome of these discussions is a bit of a personnel shuffle SNIP I've taken the liberty of assigning all the PDD tickets in RT to Allison, and the two upcoming release tickets to Chip. I've also updated http://dev.perl.org/perl6/people.html Congratulations to all three of you on your respective promotions. ^_^ -- Will Coke Coleda [EMAIL PROTECTED]
Re: TAP extension proposal: test groups
On Saturday 01 July 2006 16:46, Fergal Daly wrote: It looks like it's only one level of nesting. Any reason not to go the whole hog with something like ..1 OK 1 ..2 ...1 OK 2 OK 3 ...2 OK 4 ..3 OK5 No one has provided an actual use case for it yet. YAGNI. -- c
Re: TAP extension proposal: test groups
On Sat, Jul 01, 2006 at 21:37:48 -0700, chromatic wrote: No one has provided an actual use case for it yet. YAGNI. *cough* I did. See the TAP::Harness thread... We had UT fixtures with subsections at work, which were further grouped by class, but all emitted in the same stream. That was very hacky to make work. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpdvFvErE3pF.pgp Description: PGP signature
