[svn:perl6-synopsis] r10488 - doc/trunk/design/syn
Author: audreyt Date: Wed Jul 26 23:53:09 2006 New Revision: 10488 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S06.pod Log: * S02 and S06: Markus Laire noted that "piping" shouldn't exist anymore without "pipe operators". Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podWed Jul 26 23:53:09 2006 @@ -572,7 +572,7 @@ be a multidimension form of C<*> when that makes sense. The C<***> variant serves as the insertion point of a list of feeds. -That insertion point may be targeted by piping to C<*>. See S06. +That insertion point may be targeted by sending a feed into C<*>. See S06. Other uses for C<*> will doubtless suggest themselves over time. These can be given meaning via the MMD system, if not the compiler. In general Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podWed Jul 26 23:53:09 2006 @@ -872,8 +872,8 @@ foo() ==> say ***, " is what I meant"; bar() ==> ***.baz(); -Piping to the C<*> "whatever" term is considered a feed to the lexically -following C<***> term: +Sending a feed into the C<*> "whatever" term is considered to extend +the lexically following C<***> term: 0..* ==> *; 'a'..* ==> *;
[svn:perl6-synopsis] r10487 - doc/trunk/design/syn
Author: audreyt
Date: Wed Jul 26 23:52:24 2006
New Revision: 10487
Modified:
doc/trunk/design/syn/S04.pod
Log:
* S04: Typo fixes form agentzh++, with help from cjeris++
and other kind persons on #perl6.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Jul 26 23:52:24 2006
@@ -23,7 +23,7 @@
Every block is a closure. (That is, in the abstract, they're all
anonymous subroutines that take a snapshot of their lexical scope.)
-How any block is invoked and how its results are used is a matter of
+How a block is invoked and how its results are used is a matter of
context, but closures all work the same on the inside.
Blocks are delimited by curlies, or by the beginning and end of the
@@ -41,7 +41,7 @@
A bare closure without placeholder arguments that uses C<$_>
(either explicitly or implicitly) is treated as though C<$_> were a
-a formal parameter:
+formal parameter:
$func = { print if $_ }; # Same as: $func = -> $_ { print if $_ };
$func("printme");
@@ -473,7 +473,7 @@
cases.) Here "abnormal" means any transfer of control outward that
is not just falling off the end of a block. A C,
for example, is considered a form of abnormal control flow, since it
-can jump out of multiple levels of closure to the end of the scope
+can jump out of multiple levels of closures to the end of the scope
of the current subroutine definition. Loop commands like C
are abnormal, but looping because you hit the end of the block is not.
The implicit break of a C block is abnormal.
@@ -507,7 +507,7 @@
leave <== :foo:bar:baz(1) if $leaving;
-or going the other way::
+or going the other way:
$leaving and :foo:bar:baz(1) ==> leave;
@@ -521,7 +521,7 @@
scope of that loop, and if that call mentions the outer loop's label,
then that outer loop is the one that must be controlled. (This search
of lexical scopes is limited to the current "official" subroutine.)
-If there is no such lexically scoped outer loop in current subroutine.
+If there is no such lexically scoped outer loop in the current subroutine.
Then a fallback search is made outward through the dynamic scopes in
the same way Perl 5 does. (The difference between Perl 5 and Perl 6
in this respect arises only because Perl 5 didn't have user-defined
@@ -568,7 +568,7 @@
of parameters. (Initialization of ordinary variables does not
count--presumably the presence of a label will prevent code-movement
optimizations past the label.) So, for instance, it's always possible
-to goto into the next case of a C or into either the "then"
+to C into the next case of a C or into either the "then"
or "else" branch of a conditional. You may not go into a C
or a C, though, because that would bypass a formal parameter
binding (not to mention list generation in the case of C).
@@ -580,7 +580,7 @@
As in Perl 5, many built-in functions simply return undef when you ask
for a value out of range, or the function fails somehow. Perl 6 has
-C objects, which refers to an unthrown C object in
+C objects, any of which refers to an unthrown C object in
C<$!> and knows whether it has been handled or not.
If you test a C for C<.valid>, C<.defined> or C<.true>, it causes
@@ -594,11 +594,11 @@
default argument.
At scope exit, C<$!> discards all handled exceptions from itself, then performs
-a GC check for all remaining (unhandled) exceptions. If all of them are still
-alive (e.g. by becoming part of the return value), then they are appended to
-C<< CALLER::<$!> >>. Otherwise, it calls C to throw those exceptions
-as a single new exception, which may then be caught with a C block in
-the current (or caller's) scope.
+a garbage-collection check for all remaining (unhandled) exceptions. If all of
+them are still alive (e.g. by becoming part of the return value), then they are
+appended to C<< CALLER::<$!> >>. Otherwise, it calls C to throw those
+exceptions as a single new exception, which may then be caught with a C
+block in the current (or caller's) scope.
You can cause built-ins to automatically throw exceptions on failure using
@@ -672,13 +672,13 @@
All of these trait blocks can see any previously declared lexical
variables, even if those variables have not been elaborated yet when
-the closure is invoked. (In which case the variables evaluate to an
+the closure is invoked (in which case the variables evaluate to an
undefined value.)
Note: Apocalypse 4 confused the notions of C/C with
C/C.
These are now separate notions. C and C are used only for
their side effects. C and C must return boolean values that are
-evaluated according to the usual Design by Contract rules. (Plus,
+evaluated according to the usual Design by Contract (DBC) rules. (Plus,
if you use C/C in a class block, they only execute when the
class block is executed, but C/C i
Re: [perl #39973] Memory Allocation Error (PackFile Related?)
On Wednesday 26 July 2006 00:02, chromatic wrote: > With a fresh checkout, I'm seeing a weird error: That is, with a fresh checkout and a patch that doesn't match what my previous test case did, I'm seeing a weird error. This is noise; the bug can go away. I'll file a new bug with the real error. -- c
Partial fix to make closures invoke actions
I've been toying with this patch for a week now, because I'm not sure
whether I should apply it. I think it's a step forward, but it doesn't
solve the whole problem, and might be premature.
What it does:
1. Defines Parrot_rewind_stack as a stub for a more general
implementation of stack rewinding.
2. Changes Continuation:invoke to use it. This makes closure
invocation run all actions in leaving contexts (a bug I would like to
see fixed).
3. Fixes two test cases in t/pmc/exception.t that appear to expect
actions to be thrown away when calling a closure. (Are these just
oversights, or does someone actually need the current behavior?)
4. Removes $TODO from another t/pmc/exception.t case that now
works.
5. Adds three cases to t/pmc/continuation.t, one showing that the
change works (probably redundant wrt the previous case, now that I think
of it), and two more showing its limitations.
Problems:
1. It doesn't invoke the actions in the right dynamic environment.
This is largely because "the current dynamic environment" is tied into
"the currently-executing sub", rather than being stored in the
interpreter and captured by continuations. But fixing that is a much
larger job, which (I assume) we are not yet ready to tackle.
2. Parrot_rewind_stack uses stack_height, which makes it linear in
the current stack depth, rather than linear in the number of entries
that must be traversed. This could be fixed with a bit more effort, but
is only a matter of efficiency.
Possible actions:
1. Apply now, and worry about doing it right when rewinding is
better defined.
2. Punt until then.
3. Start working on a more comprehensive fix.
Opinions?
-- Bob Rogers
http://rgrjr.dyndns.org/
Diffs between last version checked in and current workfile(s):
Index: include/parrot/sub.h
===
--- include/parrot/sub.h(revision 13593)
+++ include/parrot/sub.h(working copy)
@@ -151,6 +151,8 @@
PMC* Parrot_find_pad(Interp*, STRING *lex_name, parrot_context_t *);
PMC* parrot_new_closure(Interp*, PMC*);
+void Parrot_rewind_stack(Interp*, struct Stack_Chunk *, struct Stack_Chunk *);
+
#endif /* PARROT_SUB_H_GUARD */
/*
Index: src/sub.c
===
--- src/sub.c (revision 13593)
+++ src/sub.c (working copy)
@@ -481,8 +481,65 @@
#endif
return clos_pmc;
}
+
/*
+=item C
+
+Given a C control stack entry and a C control stack entry, "rewind"
+the stack by popping from C until a common entry is reached.
+
+[This is a stub for implementing stack rewinding semantics -- when we have a
+better idea of what we want. -- rgr, 22-Jul-06.]
+
+=cut
+
+*/
+
+void
+Parrot_rewind_stack(Interp* interpreter,
+ struct Stack_Chunk *from,
+ struct Stack_Chunk *to)
+{
+size_t from_height = stack_height(interpreter, from);
+size_t to_height = stack_height(interpreter, to);
+
+/* Reduce the 'from' stack while it is greater than the 'to' stack. */
+while (from_height > to_height) {
+ /*
+* this automagically runs all pushed action handlers during pop - see
+* the cleanup stuff in stack_pop.
+*/
+ (void)stack_pop(interpreter, &from, NULL, NO_STACK_ENTRY_TYPE);
+ from_height--;
+}
+
+/* Reduce both stack heights in parallel. */
+if (from_height && from != to) {
+/* This is either a coroutine, or somebody is using a closure to do a
+ coroutine-like transfer of control into the middle of a
+ computation. */
+struct Stack_Chunk *below_to = to;
+while (from_height && from != below_to) {
+(void)stack_pop(interpreter, &from, NULL, NO_STACK_ENTRY_TYPE);
+/*
+ * We don't want to stack_pop below_to, because that would call any
+ * actions it may have prematurely. So we reach under the hood to
+ * unwind it quietly.
+ */
+below_to = below_to->prev;
+from_height--;
+}
+}
+
+/* [at this point, we should go back up the "to" stack from below_to..to,
+ but the semantics of upward motion are still being defined. -- rgr,
+ 26-Jul-06.] */
+}
+
+/*
+
=back
=head1 SEE ALSO
Index: src/pmc/continuation.pmc
===
--- src/pmc/continuation.pmc(revision 13593)
+++ src/pmc/continuation.pmc(working copy)
@@ -246,10 +246,13 @@
Parrot_full_sub_name(INTERP, sub));
}
caller_ctx = CONTEXT(INTERP->ctx);
+ctx = cc->to_ctx;
+Parrot_rewind_stack(INTERP, caller_ctx->control_stack,
+ ctx->control_stack);
/*
* set context
*/
-CONTEXT(INTERP->ctx)
[svn:parrot-pdd] r13593 - in trunk: . docs/pdds/clip
From: [EMAIL PROTECTED]
Date: Wed, 26 Jul 2006 14:44:41 -0700 (PDT)
Author: allison
Date: Wed Jul 26 14:44:40 2006
New Revision: 13593
. . .
Modified: trunk/docs/pdds/clip/pdd15_objects.pod
==
--- trunk/docs/pdds/clip/pdd15_objects.pod (original)
+++ trunk/docs/pdds/clip/pdd15_objects.pod Wed Jul 26 14:44:40 2006
@@ -212,6 +212,13 @@
-- the offsets of a class' attributes will change from child class to child
class)
+{{ NOTE: one feature I'd like to have is some way to access a list of
+the object's attributes. The particular use I have in mind is dumping
+the attributes of an object a la Data::Dumper. It abuses the notion
+of 'opaque object', so I could be persuaded it's not a good idea. On the
+other hand, it could be an introspective capability offered by Parrot
+but not directly exposed in the HLLs. }}
+
ParrotClass PMCs also have the "I am a class" flag set on them.
IMHO, introspection capability is *always* a good idea. Opaque objects
are nice, but the usefulness of opacity is situational; you wouldn't
want your objects to be opaque to debugging tools, for example.
-- Bob Rogers
http://rgrjr.dyndns.org/
[svn:parrot-pdd] r13593 - in trunk: . docs/pdds/clip
Author: allison
Date: Wed Jul 26 14:44:40 2006
New Revision: 13593
Modified:
trunk/docs/pdds/clip/pdd01_overview.pod
trunk/docs/pdds/clip/pdd04_datatypes.pod
trunk/docs/pdds/clip/pdd05_opfunc.pod
trunk/docs/pdds/clip/pdd06_pasm.pod
trunk/docs/pdds/clip/pdd09_gc.pod
trunk/docs/pdds/clip/pdd12_assembly.pod
trunk/docs/pdds/clip/pdd14_bignum.pod
trunk/docs/pdds/clip/pdd15_objects.pod
trunk/docs/pdds/clip/pdd16_native_call.pod
trunk/docs/pdds/clip/pdd17_basic_types.pod
trunk/docs/pdds/clip/pdd18_security.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
A series of short notes on the PDDs from a one-pass review.
Modified: trunk/docs/pdds/clip/pdd01_overview.pod
==
--- trunk/docs/pdds/clip/pdd01_overview.pod (original)
+++ trunk/docs/pdds/clip/pdd01_overview.pod Wed Jul 26 14:44:40 2006
@@ -9,6 +9,8 @@
This PDD provides a high-level overview of the Parrot system.
+{{ NOTE: this needs to be more of an overall architecture plan. }}
+
=head1 DESCRIPTION
=head2 Major components
Modified: trunk/docs/pdds/clip/pdd04_datatypes.pod
==
--- trunk/docs/pdds/clip/pdd04_datatypes.pod(original)
+++ trunk/docs/pdds/clip/pdd04_datatypes.podWed Jul 26 14:44:40 2006
@@ -9,6 +9,9 @@
This PDD describes Parrot's internal data types.
+{{ NOTE: this is a good overview, but we need more complete
+specifications of the behavior of the datatypes. }}
+
=head1 DESCRIPTION
This PDD details the basic datatypes that the Parrot core knows how to deal
Modified: trunk/docs/pdds/clip/pdd05_opfunc.pod
==
--- trunk/docs/pdds/clip/pdd05_opfunc.pod (original)
+++ trunk/docs/pdds/clip/pdd05_opfunc.pod Wed Jul 26 14:44:40 2006
@@ -10,6 +10,9 @@
This PDD specifies how the opcode functions should behave and how they are
called by the Parrot interpreter.
+{{ NOTE: this PDD is only loosely connected to the current state of
+Parrot. }}
+
=head1 DESCRIPTION
The opcode functions are the workhorse of the Parrot engine. They control
Modified: trunk/docs/pdds/clip/pdd06_pasm.pod
==
--- trunk/docs/pdds/clip/pdd06_pasm.pod (original)
+++ trunk/docs/pdds/clip/pdd06_pasm.pod Wed Jul 26 14:44:40 2006
@@ -16,6 +16,10 @@
for those people who may need to generate bytecode directly, rather than
indirectly via the perl (or any other) language.
+{{ NOTE: out-of-date and incomplete. It seems that it would be more
+useful as a specification of the format of PASM than as a comprehensive
+listing of all opcodes. }}
+
=head1 IMPLEMENTATION
Parrot opcodes take the format of:
@@ -46,18 +50,18 @@
All assembly opcodes contain only ASCII lowercase letters, digits, and the
underscore.
-Upper case names are reserved for assembler directives.
+Upper case names are reserved for assembler directives. {{ NOTE: no
+longer true. }}
Labels all end with a colon. They may have ASCII letters, numbers, and
underscores in them. Labels that begin with a dollar sign (the only valid spot
in a label a dollar sign can appear) are private to the subroutine they appear
in.
-Namespaces are noted with the NAMESPACE directive. It takes a single parameter,
-the name of the namespace. Multilevel namespaces are supported, and the
-namespaces should be double-colon separated.
+Namespaces are noted with the C<.namespace> directive. It takes a single
parameter,
+the name of the namespace, in the form of a multi-dimensional key.
-Subroutine names are noted with the SUB directive. It takes a single parameter,
+Subroutine names are noted with the C<.sub> directive. It takes a single
parameter,
the name of the subroutine, which is added to the namespace's symbol table. Sub
names may be any valid Unicode alphanumeric character and the underscore.
Modified: trunk/docs/pdds/clip/pdd09_gc.pod
==
--- trunk/docs/pdds/clip/pdd09_gc.pod (original)
+++ trunk/docs/pdds/clip/pdd09_gc.pod Wed Jul 26 14:44:40 2006
@@ -35,7 +35,7 @@
Starting from the root set (Parrot registers, stacks, internal structures) all
reachable objects (and objects reachable from these) are marked being alive.
-Ojbects not reached are considered being dead and get collected by a sweep
+Objects not reached are considered dead and get collected by a sweep
through the objects arenas.
=item Copying collection
@@ -102,7 +102,7 @@
Variable-sized memory like string memory gets collected, when the associated
header isn't found to be alive during DOD. While a copying collection could
-basically[1] be done at any time, its inefficient to copy buffers of objects
+basically[1] be done at any time, it's inefficien
Re: [perl #38887] Result of INFINITY or NAN stringification is platform dependent
On 7/26/06, Ron Blaschke <[EMAIL PROTECTED]> wrote: I'm looking into this issue and would like to ask for some advice. I have added the following platform dependent functions. int Parrot_math_isnan(double) int Parrot_math_finite(double) On Win32 the implementation is simple because the IEEE recommended functions _finite and _isnan are supported. I'm thinking about adding a test for these functions and use them. But what should happen if they are not there? Then I changed Parrot_sprintf_format in spf_render.c to use Parrot_math_isnan and Parrot_math_finite to render "NaN", "-inf" and "inf" directly. Is this a good way to solve this? There is no platform independent way to produce "NaN" or "Inf", so IMHO, you did it the only way it can be done. That being said, you can optimize by looking at the bits. Wikipedia explains IEEE-754 http://en.wikipedia.org/wiki/IEEE_754 First, you have to be aware if the machine is big or little-endian, second, look at the exponent bits, if they are all set, this is not a normal number (either +Inf, -Inf, or NaN, depending on mantissa and sign bit). Unless you're targeting non-ieee-754 systems like the VAX (an old computer), this is garanteed to be portable. I wouldn't bother with any platform specific functions, as they are all different. Just look at the bits. (gcc uses isnan, isinfinite, ... but I think you have to compile with the -c99 flag and solaris does it a little different, etc). I recently did something similar in PDL. If "looking at the bits" is not helpful, I can give you a little more detail (hint "struct union"). If you really don't want to look at the bits, I notice that gcc does have an "isnormal()" function you can use, but again you have the portability issues. Personally, I'd like to see the "i" in "inf" capitolized or the "N"s in "NaN" lower case. I like capital I for Inf. Good luck, Here's a sample (which should make its way into some tests): >type test.pir .sub main # -INF set N0, 0.0 ln N1, N0 print N1 print "\n" # +INF abs N2, N1 print N2 print "\n" # NaN set N3, -1.0 sqrt N4, N3 print N4 print "\n" .end # trunk >parrot test.pir -1.#INF00 1.#INF00 -1.#IND00 # local >parrot test.pir -inf inf NaN Thanks, Ron -- Bill Coffman ~~~_\\\|/ ~~~-(@ @) =oOO=(_)==OOo===
[perl #38887] Result of INFINITY or NAN stringification is platform dependent
I'm looking into this issue and would like to ask for some advice. I have added the following platform dependent functions. int Parrot_math_isnan(double) int Parrot_math_finite(double) On Win32 the implementation is simple because the IEEE recommended functions _finite and _isnan are supported. I'm thinking about adding a test for these functions and use them. But what should happen if they are not there? Then I changed Parrot_sprintf_format in spf_render.c to use Parrot_math_isnan and Parrot_math_finite to render "NaN", "-inf" and "inf" directly. Is this a good way to solve this? Here's a sample (which should make its way into some tests): >type test.pir .sub main # -INF set N0, 0.0 ln N1, N0 print N1 print "\n" # +INF abs N2, N1 print N2 print "\n" # NaN set N3, -1.0 sqrt N4, N3 print N4 print "\n" .end # trunk >parrot test.pir -1.#INF00 1.#INF00 -1.#IND00 # local >parrot test.pir -inf inf NaN Thanks, Ron
[perl #39979] [TODO] Tcl - More tests for [expr]
# New Ticket Created by Matt Diephouse # Please include the string: [perl #39979] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=39979 > The following aspects of [expr] still need tests: - Unary operators with string operands (numeric and otherwise) - % tests with floats -- Matt Diephouse
[patch] typos in S04
This is a patch for S04. Special thanks go to cjeris++ and other kind
persons on #perl6 for reviewing this.
Cheers,
Agent
Index: D:/projects/Perl6-Syn/S04.pod
===
--- D:/projects/Perl6-Syn/S04.pod (revision 10479)
+++ D:/projects/Perl6-Syn/S04.pod (working copy)
@@ -23,7 +23,7 @@
Every block is a closure. (That is, in the abstract, they're all
anonymous subroutines that take a snapshot of their lexical scope.)
-How any block is invoked and how its results are used is a matter of
+How a block is invoked and how its results are used are matters of
context, but closures all work the same on the inside.
Blocks are delimited by curlies, or by the beginning and end of the
@@ -41,7 +41,7 @@
A bare closure without placeholder arguments that uses C<$_>
(either explicitly or implicitly) is treated as though C<$_> were a
-a formal parameter:
+formal parameter:
$func = { print if $_ }; # Same as: $func = -> $_ { print if $_ };
$func("printme");
@@ -473,7 +473,7 @@
cases.) Here "abnormal" means any transfer of control outward that
is not just falling off the end of a block. A C,
for example, is considered a form of abnormal control flow, since it
-can jump out of multiple levels of closure to the end of the scope
+can jump out of multiple levels of closures to the end of the scope
of the current subroutine definition. Loop commands like C
are abnormal, but looping because you hit the end of the block is not.
The implicit break of a C block is abnormal.
@@ -507,7 +507,7 @@
leave <== :foo:bar:baz(1) if $leaving;
-or going the other way::
+or going the other way:
$leaving and :foo:bar:baz(1) ==> leave;
@@ -521,7 +521,7 @@
scope of that loop, and if that call mentions the outer loop's label,
then that outer loop is the one that must be controlled. (This search
of lexical scopes is limited to the current "official" subroutine.)
-If there is no such lexically scoped outer loop in current subroutine.
+If there is no such lexically scoped outer loop in the current subroutine.
Then a fallback search is made outward through the dynamic scopes in
the same way Perl 5 does. (The difference between Perl 5 and Perl 6
in this respect arises only because Perl 5 didn't have user-defined
@@ -568,7 +568,7 @@
of parameters. (Initialization of ordinary variables does not
count--presumably the presence of a label will prevent code-movement
optimizations past the label.) So, for instance, it's always possible
-to goto into the next case of a C or into either the "then"
+to C into the next case of a C or into either the "then"
or "else" branch of a conditional. You may not go into a C
or a C, though, because that would bypass a formal parameter
binding (not to mention list generation in the case of C).
@@ -580,7 +580,7 @@
As in Perl 5, many built-in functions simply return undef when you ask
for a value out of range, or the function fails somehow. Perl 6 has
-C objects, which refers to an unthrown C object in
+C objects, any of which refers to an unthrown C object in
C<$!> and knows whether it has been handled or not.
If you test a C for C<.valid>, C<.defined> or C<.true>, it causes
@@ -594,7 +594,7 @@
default argument.
At scope exit, C<$!> discards all handled exceptions from itself, then performs
-a GC check for all remaining (unhandled) exceptions. If all of them are still
+a GC (Garbage Collection) check for all remaining (unhandled)
exceptions. If all of them are still
alive (e.g. by becoming part of the return value), then they are appended to
C<< CALLER::<$!> >>. Otherwise, it calls C to throw those exceptions
as a single new exception, which may then be caught with a C block in
@@ -672,13 +672,13 @@
All of these trait blocks can see any previously declared lexical
variables, even if those variables have not been elaborated yet when
-the closure is invoked. (In which case the variables evaluate to an
-undefined value.)
+the closure is invoked (in which case the variables evaluate to an
+undefined value).
Note: Apocalypse 4 confused the notions of C/C with
C/C.
These are now separate notions. C and C are used only for
their side effects. C and C must return boolean values that are
-evaluated according to the usual Design by Contract rules. (Plus,
+evaluated according to the usual Design by Contract (DBC) rules. (Plus,
if you use C/C in a class block, they only execute when the
class block is executed, but C/C in a class block are evaluated
around every method in the class.)
@@ -718,7 +718,7 @@
opening brace. You I parenthesize the expression if there is
a bare block or pointy block that would be misinterpreted as the statement's
block. This is regardless of whether a term or operator is expected where
-the block occurs. (A block inside brackets, or used as as
+the block occurs. (A block inside brackets, or used as a
postcircumfix is fine, though.) Any block with whitespace
in front of it will b
Re: [svn:perl6-synopsis] r10477 - doc/trunk/design/syn
Modified: doc/trunk/design/syn/S06.pod -Note that all such pipes (and indeed all lazy argument lists) supply +Note that all such feed (and indeed all lazy argument lists) supply s/feed/feeds/ -Piping to the C<*> "whatever" term is considered a pipe to the lexically +Piping to the C<*> "whatever" term is considered a feed to the lexically "Piping" should probably be changed to something else. -- Markus Laire
Re: [CAGE] Request for header file renaming
On 7/26/06, luca regini <[EMAIL PROTECTED]> wrote: Is it possible to rename the ../include/parrot/string.h file in something else like ../include/parrot/parrot_string.h ? I see only 2 dependencies for this file in parrot.h and register.h so this shouldn't be a big issue. I am asking this because the string.h collides with the file of the same name found in the standard C library and this collision causes some issues with SPLINT. SPLINT processes headers differently if they have the same name of some Standard C header. Renaming parrot/string.h would simplify considerably setting up a useful SPLINT target. Thanks, Luca sure, it's possible. could you submit a patch that you made sure allows parrot to compile and pass the test suite? ~jerry
Re: [CAGE] Request for header file renaming
Also Splint halts when "malloc-trace.c" is processed, since it includes "malloc-trace.h" which does not exist anywhere in the trunk. On another note, as anyone played with Rats or Flawfinder? Regards, João On 7/26/06, luca regini <[EMAIL PROTECTED]> wrote: > Is it possible to rename the > ../include/parrot/string.h file in something else like > ../include/parrot/parrot_string.h ? I see only 2 > dependencies for this file in parrot.h and register.h > so this shouldn't be a big issue. I am asking this > because the string.h collides with the file of the > same name found in the standard C library and this > collision causes some issues with SPLINT. SPLINT > processes headers differently if they have the same > name of some Standard C header. Renaming > parrot/string.h would simplify considerably setting up > a useful SPLINT target. > Thanks, > Luca > > > Chiacchiera con i tuoi amici in tempo reale! > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com >
Re: [CAGE] Request for header file renaming
On Wed, Jul 26, 2006 at 05:24:24PM +0200, luca regini ([EMAIL PROTECTED]) wrote: > name of some Standard C header. Renaming > parrot/string.h would simplify considerably setting up > a useful SPLINT target. Thanks for starting the splint target, luca. I doubt there would be any problem, but I'll wait to hear from others before making a change. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
[CAGE] Request for header file renaming
Is it possible to rename the ../include/parrot/string.h file in something else like ../include/parrot/parrot_string.h ? I see only 2 dependencies for this file in parrot.h and register.h so this shouldn't be a big issue. I am asking this because the string.h collides with the file of the same name found in the standard C library and this collision causes some issues with SPLINT. SPLINT processes headers differently if they have the same name of some Standard C header. Renaming parrot/string.h would simplify considerably setting up a useful SPLINT target. Thanks, Luca Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
[svn:perl6-synopsis] r10478 - doc/trunk/design/syn
Author: audreyt
Date: Wed Jul 26 07:21:13 2006
New Revision: 10478
Modified:
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
Log:
* S04, S06: "Pointy sub" and "Pointy block" was used
interchangeably in the text, but as uri++ pointed out,
it was very confusing as we also say that "return" escapes
from subs but not blocks.
Hence, rename all mention of "pointy sub" to "pointy block".
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Jul 26 07:21:13 2006
@@ -14,7 +14,7 @@
Date: 19 Aug 2004
Last Modified: 26 July 2006
Number: 4
- Version: 30
+ Version: 31
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -488,7 +488,7 @@
A C always exits from the lexically surrounding sub
or method definition (that is, from a function officially declared
-with the C, C, or C keywords). Pointy subs
+with the C, C, or C keywords). Pointy blocks
and bare closures are transparent to C. If you pass a closure
object outside of its official "sub" scope, it is illegal to
return from it. You may only leave the closure block itself with C
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Jul 26 07:21:13 2006
@@ -15,7 +15,7 @@
Date: 21 Mar 2003
Last Modified: 26 July 2006
Number: 6
- Version: 41
+ Version: 42
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -132,13 +132,13 @@
it is considered the final element of that list unless followed immediately
by a comma or comma surrogate.
-=head2 "Pointy subs"
+=head2 "Pointy blocks"
Semantically the arrow operator C<< -> >> is almost a synonym for
the anonymous C keyword, except that the parameter list of a
-pointy sub does not require parentheses, and a pointy sub may not be
-given traits. Syntactically a pointy sub is parsed exactly like a
-bare block.
+pointy block does not require parentheses, and a pointy block may not be
+given traits. Syntactically, a pointy block is parsed exactly like a
+bare block:
my $sq = -> $val { $val**2 };
say $sq(10); # 100
@@ -149,7 +149,7 @@
}
It also behaves like a block with respect to control exceptions. If you
-C from within a pointy sub, it will return from the innermost
+C from within a pointy block, it will return from the innermost
enclosing C or C, not the block itself. It is referenced
by C<&?BLOCK>, not C<&?ROUTINE>.
[svn:perl6-synopsis] r10477 - doc/trunk/design/syn
Author: audreyt
Date: Wed Jul 26 07:17:16 2006
New Revision: 10477
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S09.pod
Log:
* S02, S04, S06, S09: Chase the terminology change of
"pipe operator" => "feed operator" and rename all menitons
of pipes in the text. Sometimes a pipe is just a feed...
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Jul 26 07:17:16 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 19 July 2006
+ Last Modified: 26 July 2006
Number: 2
- Version: 55
+ Version: 56
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -571,7 +571,7 @@
A variant of C<*> is the C<**> term. It is generally understood to
be a multidimension form of C<*> when that makes sense.
-The C<***> variant serves as the insertion point of a list of pipes.
+The C<***> variant serves as the insertion point of a list of feeds.
That insertion point may be targeted by piping to C<*>. See S06.
Other uses for C<*> will doubtless suggest themselves over time. These
@@ -734,7 +734,7 @@
constants), the eventual value may well be unknown. All we know is
that we have the promise to make the bits of it immutable as they become known.
-C objects may contain multiple unresolved iterators such as pipes
+C objects may contain multiple unresolved iterators such as feeds
or slices. How these are resolved depends on what they are eventually
bound to. Some bindings are sensitive to multiple dimensions while
others are not.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Jul 26 07:17:16 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 21 July 2006
+ Last Modified: 26 July 2006
Number: 4
- Version: 29
+ Version: 30
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -503,7 +503,7 @@
The innermost block matching the selection criteria will be exited.
The return value, if any, must be passed as a list. To return pairs
-as part of the value, you can use a pipe:
+as part of the value, you can use a feed operator:
leave <== :foo:bar:baz(1) if $leaving;
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Jul 26 07:17:16 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 21 Mar 2003
- Last Modified: 16 July 2006
+ Last Modified: 26 July 2006
Number: 6
- Version: 40
+ Version: 41
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -804,10 +804,10 @@
bar;# $args === \(1,2,3)
bar(); # $args === \()
-=head2 Pipe operators
+=head2 Feed operators
The variadic list of a subroutine call can be passed in separately
-from the normal argument list, by using either of the "pipe" operators:
+from the normal argument list, by using either of the I operators:
C<< <== >> or C<< ==> >>.
Each operator expects to find a call to a variadic receiver on its
@@ -819,19 +819,20 @@
It binds the (potentially lazy) list from the blunt end to the slurpy
parameter(s) of the receiver on the sharp end. In the case of a receiver
-that is a variadic function, the pipe is received as part of its slurpy list.
+that is a variadic function, the feed is received as part of its slurpy list.
So both of the calls above are equivalent to:
grep { $_ % 2 }, @data;
-Note that all such pipes (and indeed all lazy argument lists) supply
+Note that all such feed (and indeed all lazy argument lists) supply
an implicit promise that the code producing the lists may execute
-in parallel with the code receiving the lists. (Pipes, hyperops,
+in parallel with the code receiving the lists. (Feeds, hyperops,
and junctions all have this promise of parallelizability in common,
but differ in interface. Code which violates these promises is
erroneous, and will produce undefined results when parallelized.)
-In particular, a pipeline may not begin and end with the same array.
-(You may, however, assign to an array that is used within a pipeline
+
+In particular, a chain of feeds may not begin and end with the same array.
+(You may, however, assign to an array that is used within a chain
on the right side of the assignment, since list assignment will clear
and copy as necessary to make it work.) That is, this doesn't work:
[perl #39973] Memory Allocation Error (PackFile Related?)
# New Ticket Created by chromatic # Please include the string: [perl #39973] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=39973 > With a fresh checkout, I'm seeing a weird error: (gdb) run Starting program: /home/chromatic/dev/parrot/parrot [Thread debugging using libthread_db enabled] [New Thread 805414656 (LWP 8662)] Parrot VM: PANIC: Out of mem! C file src/memory.c, line 95 Parrot file (not available), line (not available) We highly suggest you notify the Parrot team if you have not been working on Parrot. Use parrotbug (located in parrot's root directory) or send an e-mail to [EMAIL PROTECTED] Include the entire text of this error message and the text of the script that generated the error. If you've made any modifications to Parrot, please describe them as well. Version : 0.4.5-devel Configured : Tue Jul 25 16:55:45 2006 Architecture: ppc-linux JIT Capable : Yes Interp Flags: (no interpreter) Exceptions : (missing from core) Dumping Core... Program received signal SIGQUIT, Quit. [Switching to Thread 805414656 (LWP 8662)] 0x0fc26fbc in raise () from /lib/libpthread.so.0 (gdb) bt #0 0x0fc26fbc in raise () from /lib/libpthread.so.0 #1 0x0fe053c8 in do_panic (interpreter=Cannot access memory at address 0xb ) at exceptions.c:125 #2 0x0fe1053c in mem__internal_allocate_zeroed (size=1684366396, file=0xff93790 "src/resources.c", line=63) at memory.c:95 #3 0x0feca1a8 in alloc_new_block (interpreter=0x1001a068, size=1684366372, pool=0x1001aa20, why=0xff937dc "compact failed") at resources.c:62 #4 0x0feca448 in mem_allocate (interpreter=0x1001a068, size=1684366372, pool=0x1001aa20) at resources.c:168 #5 0x0fecb36c in Parrot_allocate_string (interpreter=0x1001a068, str=0x10156f00, size=1684366368) at resources.c:712 #6 0x0fe1cbdc in string_make_direct (interpreter=0x1001a068, buffer=0x10008a9c, len=1684366368, encoding=0x1003ac70, charset=0x1003d620, flags=0) at string.c:612 #7 0x0fe1cab0 in string_make (interpreter=0x1001a068, buffer=0x10008a9c, len=1684366368, charset_name=0xff8bf1c "ascii", flags=0) at string.c:577 #8 0x0fec9b34 in PF_fetch_string (interp=0x1001a068, pf=0x101912d8, cursor=0x1017d5b4) at pf_items.c:524 #9 0x0fe270a4 in shift_opcode_string (interpreter=0x1001a068, io=0x101912c8) at pmc_freeze.c:532 It looks like an invalid opcode read. I think this has come up before; I am on a big-endian arch (PPC). It's so bad I can't even build anymore. -- c
