[perl #40182] [TODO] Convert PGE::CodeString to .pmc
# New Ticket Created by Will Coleda # Please include the string: [perl #40182] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40182 > <@pmichaud> CodeString is one of those that I think could give a nice performance win if it were written in C instead of PIR :-) -- Will "Coke" Coleda [EMAIL PROTECTED]
Re: === and array-refs
On 8/16/06, David Green wrote: $a=[1, 2, [EMAIL PROTECTED]; $c=[1, 2, [EMAIL PROTECTED]; $d=[1, 2, [EMAIL PROTECTED]; $a =:= $c; #false, different variables $a === $c; #true, same elements make up $a and $c $a eqv $c; #true, same elements therefore same values $a === $d; #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are different refs So $a, $c, and $d may all have the same *value* (or "snapshot", when evaluated all the way down through nesting and references), i.e. they might be eqv, but only $a and $c are === because they have the same contents [unevaluated contents] and $d doesn't. OK, here's the counter-argument to my incessant ranting: In the above example, $a and $c do "look" awfully similar, but suppose we replace the anonymous arrays with named ones: @X1=(1, 2, [EMAIL PROTECTED]); @X2=(1, 2, [EMAIL PROTECTED]); [EMAIL PROTECTED]; [EMAIL PROTECTED]; Now $a clearly does NOT === $b, because @X1 and @X2 are different variables (that just coincidentally happen to share the same contents at the moment). Replacing @X1 and @X2 with their anonymous equivalents shouldn't suddenly change that. [Well, anonymous object could have different rules, I suppose, but it's no longer "obvious" that they should. Strings, for example, do have special treatment to make different string-objects look the same, but strings can't contain other variables, so it's easy to make them act like plain values.] However, it also follows that @X1 !=== @X2. There's no anonymous reference hiding there, so why aren't @X1 and @X2 the same? (Well, they just aren't!) So... probably what I wanted all along is just to compare the contents of an array -- and === just isn't it. Hm. =:= checks for same variable === checks for same object eqv checks for same value except that if the operands aren't objects, === will compare them as values (like eqv). Or rather, if an item is a value (or an object that ought to act like a value), just make sure its SKID (which === uses) compares in an appropriate value-like way. -David
[perl #40179] None Must Die
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #40179] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40179 > The None class serves no useful (portable) purpose and it should be removed, especially from the public interface of Hash. -- Chip Salzenberg <[EMAIL PROTECTED]>
[perl #40178] None Must Die
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #40178] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40178 > The None class serves no useful (portable) purpose and it should be removed, especially from the public interface of Hash. -- Chip Salzenberg <[EMAIL PROTECTED]>
[perl #40171] [TODO] - Can't use an Iterator with a DynLexPad PMC
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40171] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40171 > I don't know how to write a test for this off the top of my head, but Iterator and DynLexPad don't play well together atm. When I tried, I got this error: elements() not implemented in class 'DynLexPad' Is there an easy way to make an arbitrary hash-like PMC (DynLexPad, NameSpace, etc.) play well with iterator? Tcl needs to be able to iterate over the keys to return a list of all the variables in the current procedure/lexpad. (See [info vars]) -- Matt Diephouse
[perl #40158] [TODO] - Can't use an Iterator with a DynLexPad PMC
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40158] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40158 > I don't know how to write a test for this off the top of my head, but Iterator and DynLexPad don't play well together atm. When I tried, I got this error: elements() not implemented in class 'DynLexPad' Is there an easy way to make an arbitrary hash-like PMC (DynLexPad, NameSpace, etc.) play well with iterator? Tcl needs to be able to iterate over the keys to return a list of all the variables in the current procedure/lexpad. (See [info vars]) -- Matt Diephouse
[perl #40156] [TODO] - Can't use an Iterator with a DynLexPad PMC
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40156] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40156 > I don't know how to write a test for this off the top of my head, but Iterator and DynLexPad don't play well together atm. When I tried, I got this error: elements() not implemented in class 'DynLexPad' Is there an easy way to make an arbitrary hash-like PMC (DynLexPad, NameSpace, etc.) play well with iterator? Tcl needs to be able to iterate over the keys to return a list of all the variables in the current procedure/lexpad. (See [info vars]) -- Matt Diephouse
[perl #40153] [CAGE] TEST_PROG
# New Ticket Created by Will Coleda # Please include the string: [perl #40153] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40153 > Anything referring to TEST_PROG should probably be renamed to "parrot" or "executable" based on context. -- Will "Coke" Coleda [EMAIL PROTECTED]
[perl #40151] [TODO] Remove set_pmc vtable method
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40151] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40151 > So sayeth array.pmc: void set_pmc(PMC *other) Currently, an alias to C. Expected to go away soon. Evidently this is for some non-standard definition of "soon", as it's been more than a year AFAICT. This ought to be removed RSN to reduce confusion (which I suffered from this week). -- Matt Diephouse
Re: === and array-refs
On 8/15/06, Darren Duncan wrote: At 2:51 PM -0600 8/15/06, David Green wrote: [...] You are right, but we have both Seq and Array types, so depending which one you use, you want either the === or eqv operators to do what you want. There is no reason that === should say 2 Array are equal; we have eqv for that, or use 2 Seq instead of 2 Array if you want === to return true on the same values. Is Seq vs Array the right distinction here? A Seq is immutable, so I can't change its size, for instance, which is not what I want. I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to [1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case (regardless of Seq vs. Array -- I didn't think it made a difference here). Actually, my previous example which Larry said was correct was: $a=[1, 2, [EMAIL PROTECTED]; $c=[1, 2, [EMAIL PROTECTED]; $d=[1, 2, [EMAIL PROTECTED]; $a =:= $c; #false, different variables $a === $c; #true, same elements make up $a and $c $a eqv $c; #true, same elements therefore same values $a === $d; #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are different refs So $a, $c, and $d may all have the same *value* (or "snapshot", when evaluated all the way down through nesting and references), i.e. they might be eqv, but only $a and $c are === because they have the same contents [unevaluated contents] and $d doesn't. Which is what makes sense to me, but S03 says "[1,2]!===[1,2]". My position is that even if they are different "objects", that difference is fairly useless, and should therefore be hidden (same as it is for objects that are strings). First of all, in Perl 6, there are no separate "arrays" and "array refs"; we simply have the 'Array' type, which is treated as a lump on its own. More generally, there are no "reference" types in Perl 6. I thought there were, just not as conspicuously. There are "captures" anyway, which are supposed to be like P5-refs, and beyond. (However, I admit to being a bit fuzzy on exactly how Signatures and Captures work -- if anyone could write an Exegesis on the subject, I know I'm not the only one who would appreciate it.) [...] The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol afterwards. For a mutable type like an Array, === returns false on 2 containers because it can't guarantee that someone else holding another symbol for either container won't change its content, and so $a or $b could change after we made the === test, without us causing that to happen, and so for mutable types, === only returns true for 2 aliases, because that is the most it can guarantee that they will be the same. So, given mutable types, $a===$b if and only if $a=:=$b? That doesn't sound right, otherwise === seems superfluous. The thing is if $a=[1,2] and $b=[1,2], then arrays or not, nothing can change $a or $b except by changing $a or $b. [Or aliases bound to same, of course.] So there's no reason for $a===$b to be false. (If they look the same, and they act the same, then they're ducks. Er, or something.) (Hoping the 'eternal' stuff hasn't thrown me off and resulted in my completely misinterpreting what you were trying to say.) -David
Re: Dumb doc question...
On 8/17/06, Mark J. Reed <[EMAIL PROTECTED]> wrote: Where can I find a pod2html that groks the p6 version of POD? I want to format my fresh-from-svn copies of the doc... If you mean the POD files of perl 6 synopses, then pod2html only lacks the support for the "=encoding" directive. On my (Win32) machine, there's a build.bat to generate HTML from all the synopses. It looks like this: call podhtm -s Active.css *.pod grep -P "text/html; charset=gb2312" *.html | subs "gb2312" "UTF-8" del *.tmp where podhtm is a wrapper around a pod2html and subs is a text substitution utility written by myself. And there're also an online HTML version of the Perl 6 Spec: http://dev.perl.org/perl6/doc/synopsis.html This version automatically updates from the SVN repository every few hours. Hope these help. Agent
[svn:perl6-synopsis] r11065 - doc/trunk/design/syn
Author: larry Date: Wed Aug 16 20:39:30 2006 New Revision: 11065 Modified: doc/trunk/design/syn/S03.pod Log: Removed contentious "Trinary". Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podWed Aug 16 20:39:30 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 11 Aug 2006 + Last Modified: 16 Aug 2006 Number: 3 - Version: 55 + Version: 56 =head1 Changes to Perl 5 operators @@ -87,7 +87,7 @@ an C is evaluated only once. (To call a block repeatedly, use a C instead.) -=item * Trinary C becomes C. It is a syntax error to use an +=item * The C conditional operator becomes C. It is a syntax error to use an operator in the middle that binds looser in precedence, such as C<=>. =item * C gets a synonym: C< < ... > >, and an interpolating
typo fix: trinary -> ternary
In Perl6/Spec/Operator.pod "Trinary" should be "Ternary". Mark
Re: NEXT and the general loop statement
On Wed, Aug 16, 2006 at 08:21:29PM -0400, Joe Gottman wrote:
: Is a NEXT clause called before or after the update portion of a general loop
: statement? For instance, consider the following code:
:
:
:
: loop $n = 0; $n < 5; ++$n {
:
: NEXT {print $n;}
:
: }
:
:
:
: Is the output 01234 or 12345?
I'd say 01234 on the theory that the 3-arg loop is really saying:
$n = 0;
while $n < 5 {
NEXT { ++$n }
NEXT { print $n }
}
and also on the theory that block exiting blocks always run in reverse order.
Larry
NEXT and the general loop statement
Is a NEXT clause called before or after the update portion of a general loop
statement? For instance, consider the following code:
loop $n = 0; $n < 5; ++$n {
NEXT {print $n;}
}
Is the output 01234 or 12345?
Joe Gottman
Re: === and array-refs
Larry Wall schreef:
> Dr.Ruud:
>> Comparing strings in Perl5, using NFKD:
>>
>> perl5 -MUnicode::Normalize -we '
>> ($\, $,) = ("\n", "\t") ;
>> $x = qq{Henry IV} ;
>> $y = qq{Henry \x{2163}} ;
>> print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
>> # $x = NFKD $x ;
>> $y = NFKD $y ;
>> print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
>> '
>> Wide character in print at -e line 5.
>>8 7 0
>> 8 8 1
>>
>>
>> How will the Str type do this?
>
> That'd just be:
>
> eqv($x, $y, :(NFKD $^s))
>
> [...]
Thanks. Is it also possible to define an NKFD_Str type so that you can
code C<$x === $y>, and the NKFD-stuff is done because of the type's
.SKID? (Can a "type" have a (type-wide) .SKID?)
--
Affijn, Ruud
"Gewoon is een tijger."
[svn:parrot-pdd] r14139 - trunk/docs/pdds
Author: creiss
Date: Wed Aug 16 09:48:09 2006
New Revision: 14139
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
Undo accidental reversion.
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podWed Aug 16 09:48:09 2006
@@ -60,9 +60,9 @@
=item B
-Pop the most recently pushed exception handler off the control stack.
+Pop the most recently pushed exception handler off the exception handler stack.
-{{ TODO: Provide control stack introspection. }}
+{{ TODO: Provide exception handler stack introspection. }}
=item B>
@@ -96,13 +96,9 @@
Exception handlers can resume execution immediately after the C
opcode by executing the C opcode, and then invoking the given
continuation which they receive as a parameter. That continuation must be
-invoked with no parameters; in other words, C may I return a
+invoked with no parameters; in other words, C never returns a
value.
-{{ TODO: Resuming immediately after the C opcode isn't quite
-flexible enough. Perl 6, for example, resumes control flow after the end
-of the block in which the exception was thrown. }}
-
=item B ]>
The C opcode throws an exception of type C with a
@@ -110,8 +106,8 @@
payload is a C PMC containing I; if I is a PMC, it
is used directly as the exception payload.
-{{ TODO: What is the default when no I is given? Something like
-"Fatal exception at LINE in FILE." followed by a backtrace. }}
+The default when no I is given is "Fatal exception at LINE in
+FILE." followed by a backtrace.
If this exception is not handled, it results in Parrot returning an error
indication and the stringification of I to its embedding environment.
@@ -143,47 +139,51 @@
=over
=item 1
-Find the topmost exception handler
+Find the topmost exception handler.
=item 2
-Push an exception record somewhere, presumably on the control stack.
-The exception record contains a pointer to an exception handler block
-and an exception PMC (and possibly a continuation)
+Push an exception record somewhere, presumably on the exception handler
+stack. The exception record contains a pointer to an exception handler
+block, an exception PMC, and (optionally) a continuation.
=item 3
Invoke the handler (note: this is still in the thrower's dynamic
-context)
+context).
=back
-If the handler returns normally:
+If the handler returns without calling C:
=over
=item 1
-Find the "exception handling in progress" record
+Find the "exception handling in progress" record.
=item 2
-Find the next exception handler
+Find the next exception handler.
=item 3
-If the handler is found, invoke it
+If the handler is found, invoke it.
+
=item 4
-Or if there is a continuation in the exception record
-(because the throwing opcode was C),
-invoke the ER's continuation (i.e. resume execution)
+If no handler is found, and the exception is non-fatal (such as a
+warning), and there is a continuation in the exception record (because
+the throwing opcode was C), invoke the continuation (resume
+execution). Whether to resume or die when an exception isn't handled is
+determined by the severity of the exception.
=item 5
-Otherwise terminate program a la C
+Otherwise terminate program a la C.
=back
-{{ TODO: this isn't right, another option is a) invoke the handler, b)
-the handler calls handled, and c) invoke the continuation to resume
-because the exception was handled. The question of whether to resume or
-die when an exception is never handled is determined by the severity of
-the exception, not by the simple fact of having a continuation. }}
+When running an embedded Parrot interpreter, the interpreter does not
+immediately terminate on an unhandled exception, it merely returns
+control to the embedding program and stores the unhandled exception so
+that it may be queried by the embedding program. The embedding program
+may choose to handle the exception and continue execution by invoking
+the exception's continuation.
When the C opcode is called:
@@ -191,7 +191,11 @@
=over
=item 1
-Pop and destroy exception record
+Pop and destroy the exception record.
+
+=item 2
+If there was a continuation in the exception record, invoke the
+continuation.
=back
@@ -251,10 +255,6 @@
C method to store that previous exception
as part of the exception object.
-{{ TODO: Should we use properties instead? ANR: I'm not sure what you
-mean by "an exception is a consequence of a previous exception".
-Example? }}
-
=back
=head2 Standard Parrot Exceptions
@@ -285,8 +285,6 @@
=item B
-{{ TODO: How about calling these B? }}
-
Generic base class for miscellaneous domain (input value) errors. Payload is
an array, the first element of which is the operation that failed (e.g. the
opcode name); subsequent elements depend on the value of the first element.
@@ -366,10 +364,23
Re: === and array-refs
On 8/16/06, Charles Bailey wrote: This is where the "eternal" part starts to confuse me (not picking on your wording, but on the semantics). I'll pick on the wording (wording should always be picked on -- not to be pedantic (OK, I like to be pedantic, but that's not the *only* reason!), but because it really is an advantage to develop terminology that's as precise and pretty as possible). Maybe values can be considered "eternal", in some philosophical platonic sense, but variables certainly aren't (eventually your program will reach the end or the sun will explode or something). "Permanent", maybe... What happens if I insert the C<$aa = "Two"> before line 255? In other words, can I rely on P6 to know at line 3 that there's an alias out there by which C<$a> _might_ change without assignment later (i.e. the guarantee that "$a and $b will remain the same unless you assign to one" might be violated)? ...but there's nothing permanent either really, because you can always change any variable you like, later on at line 255. (Unless the variable is a constant, which is not the same thing as being immutable even though those words are fairly synonymous, i.e. yet more confusing terminology.) What we're really talking about is action-at-a-distance: one variable changing its value because *something else* changed -- some other variable that was somehow "contained inside" the first one. Not to be confused with changing some other variable that is really the same variable because they were bound together: $a:=$b. Should I call that two variables (somehow "linked" or bound together)? Or would it be better (easier, less confusing) to call it *one* variable that has two names? (Still nothing to be described as "permanent" here, because I can always unbind them later on, and have $a and $b being two completely separate variables, right?) I find myself tempted to talk in temporal terms to explain the issue, and that's a natural way to frame examples, but the language of examples doesn't seem to be that good for explaining the concepts. Whether stuff may or may not change isn't the point; what it comes down to is referring to a variable itself vs. evaluating it. -David
Re: === and array-refs
On 8/16/06, Dr.Ruud wrote: I also wondered why a "simple" array (for example containing only value type objects) whould not C<===> its copy. But with .SKID that must be easy to handle. That's what I was wondering that started off this thread. I understand (more or less, I think), why it *does* work that way; I'm just not sure why we'd *want* it to work that way. And maybe the answer is that in an ideal world, we wouldn't want it -- but in practice, that simply isn't feasible, so instead we get mutables and immutables and most of the time I'll just use "eqv" and everything will DWIM and it doesn't matter, and on the rare occasions when I really need to do === stuff, I'll just have to cope with it. (Or maybe subclass stuff with my own SKIDs to make it work the way I want, whatever.) That's fine, trade-offs are a fact of life. But nobody's actually said that, so I don't know whether I'm misunderstanding something still, whether I just haven't clearly explained what the heck I mean (or both, always a distinct possibility!). -David
Re: === and array-refs
On Wed, Aug 16, 2006 at 04:25:13PM +0200, Dr.Ruud wrote:
: Comparing strings in Perl5, using NFKD:
:
: perl5 -MUnicode::Normalize -we '
: ($\, $,) = ("\n", "\t") ;
: $x = qq{Henry IV} ;
: $y = qq{Henry \x{2163}} ;
: print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
: # $x = NFKD $x ;
: $y = NFKD $y ;
: print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
: '
: Wide character in print at -e line 5.
:8 7 0
: 8 8 1
:
:
: How will the Str type do this?
That'd just be:
eqv($x, $y, :(NFKD $^s))
or some such, give or take a little notation in the signature to force MMD
to match a Str and coerce to NFKD. This is mentioned in S03 as a subproblem
of the general canonicalization/collation problem. It should be using the
same underlying semantics as
cmp($x, $y, :(NFKD $_))
or
sort :(NFKD $_), @strings;
Larry
[svn:perl6-synopsis] r11047 - doc/trunk/design/syn
Author: larry Date: Wed Aug 16 14:57:15 2006 New Revision: 11047 Modified: doc/trunk/design/syn/S05.pod Log: Clarification of intented use of the word "regex", suggested by dduncan++. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podWed Aug 16 14:57:15 2006 @@ -14,14 +14,19 @@ Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and Larry Wall <[EMAIL PROTECTED]> Date: 24 Jun 2002 - Last Modified: 2 Aug 2006 + Last Modified: 16 Aug 2006 Number: 5 - Version: 31 + Version: 32 This document summarizes Apocalypse 5, which is about the new regex -syntax. We now try to call them I because they haven't been -regular expressions for a long time. When referring to their use in -a grammar, the term I is preferred. +syntax. We now try to call them I rather than "regular +expressions" because they haven't been regular expressions for a +long time, and we think the popular term "regex" is in the process of +becoming a technical term with a precise meaning of: "something you do +pattern matching with, kinda like a regular expression". + +In any case, when referring to recursive patterns within a grammar, +the terms I and I are generally preferred. =head1 New match result and capture variables
Re: [PROPOSED PATCH] Add Parrot::Embed to Repository
On 8/15/06, chromatic <[EMAIL PROTECTED]> wrote: Here's a proposed patch that seems to work okay for me on Linux. It's not great or beautiful, mostly because of the Makefile hackery. It's a starting point though. I suspect Windows might complain. windows indeed complains. not only about missing prereq (ExtUtils::PkgConfig,) but ...and you've got to see this coming... missing pkg-config. i don't know anything about pkg-config, and i don't know anything about Module::Build, so i can't take this beyond the small makefile fix i needed on the last line of the config/gen/makefiles/ext.in (s<>.) ~jerry
Dumb doc question...
...which I would have thought was a faq; maybe I just haven't found the right faq list... Where can I find a pod2html that groks the p6 version of POD? I want to format my fresh-from-svn copies of the doc... -- Mark J. Reed <[EMAIL PROTECTED]>
Re: [PROPOSED PATCH] Add Parrot::Embed to Repository
On 8/16/06, chromatic <[EMAIL PROTECTED]> wrote: On Wednesday 16 August 2006 08:57, jerry gay wrote: > i'll happily test, but i can't apply it, as it seems not to be in the > format my patch util expects. did you use C? i don't see the > familiar "Index: " headers. It's a standard svk diff. That's really weird. Is this any better? my tortoisesvn patch command doesn't like it, either. so i downloaded gnu patch for windows, and that seems to like it better. applied, and rebuilding now. however, i'm currently also recovering from the stm merge, which has uncovered some threading failures on windows. hopefully those will be either hidden from view or resolved shortly, and i'll be able to provide you with some useful feedback. ~jerry
Re: [PROPOSED PATCH] Add Parrot::Embed to Repository
On Wednesday 16 August 2006 08:57, jerry gay wrote:
> i'll happily test, but i can't apply it, as it seems not to be in the
> format my patch util expects. did you use C? i don't see the
> familiar "Index: " headers.
It's a standard svk diff. That's really weird. Is this any better?
-- c
--- MANIFEST (revision 20216)
+++ MANIFEST (local)
@@ -201,6 +201,7 @@
config/gen/makefiles/dynpmc.in []
config/gen/makefiles/dynpmc_pl.in []
config/gen/makefiles/editor.in []
+config/gen/makefiles/ext.in []
config/gen/makefiles/languages.in []
config/gen/makefiles/parrot.pc.in []
config/gen/makefiles/past.in[]
@@ -637,6 +638,15 @@
examples/tge/branch/lib/Branch.pir [main]doc
examples/tge/branch/lib/Leaf.pir[main]doc
examples/tge/branch/transform.pir [main]doc
+ext/Parrot-Embed/t/embed.t [devel]
+ext/Parrot-Embed/t/greet.pir[devel]
+ext/Parrot-Embed/lib/Parrot/Embed.xs[devel]
+ext/Parrot-Embed/lib/Parrot/Embed.pm[devel]
+ext/Parrot-Embed/Changes[devel]
+ext/Parrot-Embed/MANIFEST [devel]
+ext/Parrot-Embed/typemap[devel]
+ext/Parrot-Embed/Build.PL [devel]
+ext/Parrot-Embed/README [devel]
include/parrot/builtin.h[main]include
include/parrot/caches.h [main]include
include/parrot/cclass.h [main]include
--- config/gen/makefiles/root.in (revision 20216)
+++ config/gen/makefiles/root.in (local)
@@ -186,6 +186,7 @@
compilers/tge/Makefile \
compilers/bcg/Makefile \
editor/Makefile \
+ext/Makefile \
languages/Makefile \
languages/amber/Makefile \
languages/APL/Makefile \
--- config/gen/makefiles/ext.in (revision 20216)
+++ config/gen/makefiles/ext.in (local)
@@ -0,0 +1,64 @@
+# $Id: /parrotcode/offline/config/gen/makefiles/languages.in 19764 2006-08-03T18:17:04.907999Z chromatic $
+
+# setup of commands
[EMAIL PROTECTED]@
+PERL = @perl@
+MAKE = @make_c@
+RM_F = @rm_f@
+
+# add new languages here
+# remove obsolete languages here
+EXT = \
+Parrot-Embed
+
+# the default target
+all: $(EXT)
+
+# hard-code these for now
+test: Parrot-Embed
+ - cd Parrot-Embed && $(PERL) Build test
+
+clean: Parrot-Embed
+ - cd Parrot-Embed && $(PERL) Build clean
+
+# This is a listing of all targets, that are meant to be called by users
+help:
+ @echo ""
+ @echo "Following targets are available for the user:"
+ @echo ""
+ @echo " all: Make a lot of language implementations."
+ @echo "This is the default."
+ @echo " test: Unified test suite for a lot of languages."
+ @echo ""
+ @echo " clean:Clean up a lot of languages."
+ @echo ""
+ @echo " help: Print this help message."
+ @echo ""
+ @echo " smoke:Run the test suite and send smoke.html to "
+ @echo "http://smoke.parrotcode.org/";
+ @echo ""
+ @echo " smoke-clean: clean up smoke.html"
+ @echo ""
+ @echo ""
+ @echo "Following languages are available:"
+ @echo " $(LANGUAGES)"
+ @echo "A particular language can be built, tested and cleand up"
+ @echo " make "
+ @echo " make .test"
+ @echo " make .clean"
+ @echo "For the status of individual languages see LANGUAGES.STATUS.pod"
+ @echo ""
+
+clean: \
+Parrot-Embed.clean
+
+#
+# Extension specific targets
+#
+
+# The *.dummy targets are a replacement for the target .PHONY in 'GNU make'
+
+Parrot-Embed : Parrot-Embed.dummy
+
+Parrot-Embed.dummy:
+ - cd ext/Parrot-Embed && $(PERL) Build.PL && $(PERL) Build
--- config/gen/makefiles.pm (revision 20216)
+++ config/gen/makefiles.pm (local)
@@ -117,6 +117,11 @@
replace_slashes => 1
);
genfile(
+'config/gen/makefiles/ext.in' => 'ext/Makefile',
+commentType => '#',
+replace_slashes => 1
+);
+genfile(
'config/gen/makefiles/parrot.pc.in' => 'parrot.pc'
);
--- ext/Parrot-Embed/Build.PL (revision 20216)
+++ ext/Parrot-Embed/Build.PL (local)
@@ -0,0 +1,41 @@
+use strict;
+use warnings;
+
+use Module::Build;
+use ExtUtils::PkgConfig;
+
+my %pkg_info = ExtUtils::PkgConfig->find( 'parrot' );
+
+my $class = Module::Build->subclass(
+ code => <<'END_HERE',
+ use Cwd;
+
+ sub ACTION_build
+ {
+ my $self= shift;
+ my $old_dir = cwd();
+ chdir 't';
+
+ system(qw( parrot -o greet.pbc greet.pir ) ) == 0
+ or die "Cannot compile PBC for test: $?";
+
+
Re: [PROPOSED PATCH] Add Parrot::Embed to Repository
On 8/15/06, chromatic <[EMAIL PROTECTED]> wrote: Here's a proposed patch that seems to work okay for me on Linux. It's not great or beautiful, mostly because of the Makefile hackery. It's a starting point though. I suspect Windows might complain. i'll happily test, but i can't apply it, as it seems not to be in the format my patch util expects. did you use C? i don't see the familiar "Index: " headers. ~jerry
[svn:parrot-pdd] r14131 - in trunk: . config/auto config/auto/cpu config/auto/cpu/i386 config/auto/cpu/ppc config/auto/cpu/sun4 config/gen/makefiles config/init docs/pdds docs/pdds/clip docs/stm examp
Author: creiss Date: Wed Aug 16 08:53:17 2006 New Revision: 14131 Modified: trunk/docs/pdds/clip/pdd10_embedding.pod trunk/docs/pdds/pdd23_exceptions.pod Changes in other areas also in this revision: Added: trunk/config/auto/cpu/ - copied from r14128, /branches/stm/config/auto/cpu/ trunk/config/auto/cpu.pm - copied unchanged from r14128, /branches/stm/config/auto/cpu.pm trunk/config/auto/cpu/i386/ - copied from r14128, /branches/stm/config/auto/cpu/i386/ trunk/config/auto/cpu/i386/auto.pm - copied unchanged from r14128, /branches/stm/config/auto/cpu/i386/auto.pm trunk/config/auto/cpu/i386/test_gcc_cmpxchg.in - copied unchanged from r14128, /branches/stm/config/auto/cpu/i386/test_gcc_cmpxchg.in trunk/config/auto/cpu/ppc/ - copied from r14128, /branches/stm/config/auto/cpu/ppc/ trunk/config/auto/cpu/ppc/auto.pm - copied unchanged from r14128, /branches/stm/config/auto/cpu/ppc/auto.pm trunk/config/auto/cpu/ppc/test_gcc_cmpset.in - copied unchanged from r14128, /branches/stm/config/auto/cpu/ppc/test_gcc_cmpset.in trunk/config/auto/cpu/sun4/ - copied from r14128, /branches/stm/config/auto/cpu/sun4/ trunk/config/auto/cpu/sun4/auto.pm - copied unchanged from r14128, /branches/stm/config/auto/cpu/sun4/auto.pm trunk/config/auto/cpu/sun4/test_atomic.in - copied unchanged from r14128, /branches/stm/config/auto/cpu/sun4/test_atomic.in trunk/docs/stm/ - copied from r14128, /branches/stm/docs/stm/ trunk/docs/stm/atomic.pod - copied unchanged from r14128, /branches/stm/docs/stm/atomic.pod trunk/docs/stm/stm_frontend.pod - copied unchanged from r14128, /branches/stm/docs/stm/stm_frontend.pod trunk/docs/stm/thread-issues.pod - copied unchanged from r14128, /branches/stm/docs/stm/thread-issues.pod trunk/include/parrot/atomic/ - copied from r14128, /branches/stm/include/parrot/atomic/ trunk/include/parrot/atomic.h - copied unchanged from r14128, /branches/stm/include/parrot/atomic.h trunk/include/parrot/atomic/fallback.h - copied unchanged from r14128, /branches/stm/include/parrot/atomic/fallback.h trunk/include/parrot/atomic/gcc_pcc.h - copied unchanged from r14128, /branches/stm/include/parrot/atomic/gcc_pcc.h trunk/include/parrot/atomic/gcc_x86.h - copied unchanged from r14128, /branches/stm/include/parrot/atomic/gcc_x86.h trunk/include/parrot/atomic/sparc.h - copied unchanged from r14128, /branches/stm/include/parrot/atomic/sparc.h trunk/include/parrot/stm/ - copied from r14128, /branches/stm/include/parrot/stm/ trunk/include/parrot/stm/backend.h - copied unchanged from r14128, /branches/stm/include/parrot/stm/backend.h trunk/runtime/parrot/library/STM.pir - copied unchanged from r14128, /branches/stm/runtime/parrot/library/STM.pir trunk/src/atomic/ - copied from r14128, /branches/stm/src/atomic/ trunk/src/atomic/sparc_v9.s - copied unchanged from r14128, /branches/stm/src/atomic/sparc_v9.s trunk/src/dynpmc/rotest.pmc - copied unchanged from r14128, /branches/stm/src/dynpmc/rotest.pmc trunk/src/ops/stm.ops - copied unchanged from r14128, /branches/stm/src/ops/stm.ops trunk/src/pmc/parrotrunningthread.pmc - copied unchanged from r14128, /branches/stm/src/pmc/parrotrunningthread.pmc trunk/src/pmc/stmlog.pmc - copied unchanged from r14128, /branches/stm/src/pmc/stmlog.pmc trunk/src/pmc/stmref.pmc - copied unchanged from r14128, /branches/stm/src/pmc/stmref.pmc trunk/src/pmc/stmvar.pmc - copied unchanged from r14128, /branches/stm/src/pmc/stmvar.pmc trunk/src/stm/ - copied from r14128, /branches/stm/src/stm/ trunk/src/stm/backend.c - copied unchanged from r14128, /branches/stm/src/stm/backend.c trunk/src/stm/stm_internal.h - copied unchanged from r14128, /branches/stm/src/stm/stm_internal.h trunk/src/stm/stm_waitlist.h - copied unchanged from r14128, /branches/stm/src/stm/stm_waitlist.h trunk/src/stm/waitlist.c - copied unchanged from r14128, /branches/stm/src/stm/waitlist.c trunk/t/pmc/ro.t - copied unchanged from r14128, /branches/stm/t/pmc/ro.t trunk/t/src/atomic.t - copied unchanged from r14128, /branches/stm/t/src/atomic.t trunk/t/stm/ - copied from r14128, /branches/stm/t/stm/ trunk/t/stm/basic.t - copied unchanged from r14128, /branches/stm/t/stm/basic.t trunk/t/stm/basic_mt.t - copied unchanged from r14128, /branches/stm/t/stm/basic_mt.t trunk/t/stm/llqueue.t - copied unchanged from r14128, /branches/stm/t/stm/llqueue.t trunk/t/stm/queue.t - copied, changed from r14128, /branches/stm/t/stm/queue.t trunk/t/stm/runtime.t - copied unchanged from r14128, /branches/stm/t/stm/runtime.t Modified: trunk/Configure.pl trunk/MANIFEST trunk/MANIFEST.SKIP trunk/config/gen/makefiles/dynpmc.in trunk/con
Re: === and array-refs
"Markus Laire" schreef:
> Dr.Ruud:
>> Markus Laire:
>>> my $x = 'Just Another';
>>> my $y := $x;
>>> $y = 'Perl Hacker';
>>>
>>> After this, both $x and $y contain the string "Perl Hacker", since
>>> they are really just two different names for the same variable.
>>>
>>
>> So "$x === Sy" stil[l] holds.
>
> Exactly, and because of that $a === $b does NOT hold in my example.
> ($a would be "Two", $b would be "One")
Yes, sorry for my over-compact reply. Where Darren wrote:
The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to either symbol afterwards.
I think he meant something like "to either symbol (or alias)".
But read S03 for an exacter description.
I also wondered why a "simple" array (for example containing only value
type objects) whould not C<===> its copy.
But with .SKID that must be easy to handle.
Comparing strings in Perl5, using NFKD:
perl5 -MUnicode::Normalize -we '
($\, $,) = ("\n", "\t") ;
$x = qq{Henry IV} ;
$y = qq{Henry \x{2163}} ;
print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
# $x = NFKD $x ;
$y = NFKD $y ;
print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
'
Wide character in print at -e line 5.
8 7 0
8 8 1
How will the Str type do this?
--
Affijn, Ruud
"Gewoon is een tijger."
Re: === and array-refs
On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: I'll try saying what I meant differently here: The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol [or other symbols aliased to either] afterwards. The idea is that, the degree to which === examines 2 variables to consider them equal or not is only so far as they are immutable. So if you say "$foo = $bar", and then "$baz === $foo" returns true, then a subsequent assignment to or type-allowed mutation of $bar won't invalidate that $baz === $foo, but an assignment to $foo would. IMHO the text "a subsequent assignment to or" is useless here because I don't think any subsequent assignment to $bar could ever affect $foo, even if they were mutable types: $bar = [1,2]; $foo = $bar; ... $bar = 123; # This doesn't affect $foo Of course, type-allowed mutation of $bar will affect $foo if $bar is mutable type. Still, thanks for clarification - I misunderstood what you meant with "someone else holding another symbol". -- Markus Laire
Re: underscores in the core lib
On 8/10/06, Larry Wall <[EMAIL PROTECTED]> wrote: Yes, it's a design smell. The point of core is to huffman code common things, so something in core with _ should normally either be shorter or out of the core. Would it be adequate to say "think hard about keeping core names concise, but prefer clarity to conciseness when they're mutually exclusive"? Have I just said the same thing you did above? If I need to use core_function_for_enabling_extremely_convenient_unified_process five hundred times a day, how hard is it for me to alias it to coffeecup? (Of course, if everyone thinks coffeecup is the obvious choice, then that's a better candidate for the core name, but if only a subset think coffeecup is valid, then they might choose an alternate Huffman code.) -- Regards, Charles Bailey Lists: bailey _dot_ charles _at_ gmail _dot_ com Other: bailey _at_ newman _dot_ upenn _dot_ edu
Re: === and array-refs
On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: At 11:42 AM +0300 8/16/06, Markus Laire wrote: >On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: >>The difference between === and eqv is that, if you have 2 symbols, $a >>and $b, and $a === $b returns true, then that result is guaranteed to >>be eternal if you don't assign to either symbol afterwards. > >So do you mean that this code > $a = "One"; > $b = "One"; > $aa := $a; > say "Same before" if $a === $b; > $aa = "Two"; > say "Same after" if $a === $b; >would print > Same before > Same after >because here I have "2 symbols, $a and $b, and $a === $b returns true" >and I don't assign to either symbol afterwards - and you seem to be >saying that only with mutable types like Array can you change the >contents via another symbol ($aa here). Thanks for catching that typo. What you are saying with your above example is correct, and I knew about that before, but it slipped my mind when I wrote my explanation before. I'll try saying what I meant differently here: The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol [or other symbols aliased to either] afterwards. This is where the "eternal" part starts to confuse me (not picking on your wording, but on the semantics). For example, suppose I say <0> $a = "One"; <1> $b = "One"; <2> $aa := $a; <3> say "Immutidentical" if $a === $b; As I understand it, I'll see "Immutidentical". If I insert the C<$aa = "Two"> before line 3, then I won't see "Immutidentical". What happens if I insert the C<$aa = "Two"> before line 255? In other words, can I rely on P6 to know at line 3 that there's an alias out there by which C<$a> _might_ change without assignment later (i.e. the guarantee that "$a and $b will remain the same unless you assign to one" might be violated)? What happens if the C<$aa = "Two"> is in an eval-equivalent, so the compiler can't see it before runtime? Does the fact that the alias exists violate the guarantee of immutability, or does the guarantee just mean that at the instant the test is executed, both the contents and container are the same? (If the latter, I'm not sure in what practical situations I'd use it.) If I've -- once again -- totally missed the boat, please be patient. -- Regards, Charles Bailey Lists: bailey _dot_ charles _at_ gmail _dot_ com Other: bailey _at_ newman _dot_ upenn _dot_ edu
Re: === and array-refs
On 8/16/06, Dr.Ruud <[EMAIL PROTECTED]> wrote: "Markus Laire" schreef: > my $x = 'Just Another'; > my $y := $x; > $y = 'Perl Hacker'; > > After this, both $x and $y contain the string "Perl Hacker", since > they are really just two different names for the same variable. > So "$x === Sy" stil holds. Exactly, and because of that $a === $b does NOT hold in my example. ($a would be "Two", $b would be "One") -- Markus Laire
Re: === and array-refs
"Markus Laire" schreef: > my $x = 'Just Another'; > my $y := $x; > $y = 'Perl Hacker'; > > After this, both $x and $y contain the string "Perl Hacker", since > they are really just two different names for the same variable. > So "$x === Sy" stil holds. -- Affijn, Ruud "Gewoon is een tijger."
Re: === and array-refs
At 11:42 AM +0300 8/16/06, Markus Laire wrote: On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol afterwards. So do you mean that this code $a = "One"; $b = "One"; $aa := $a; say "Same before" if $a === $b; $aa = "Two"; say "Same after" if $a === $b; would print Same before Same after because here I have "2 symbols, $a and $b, and $a === $b returns true" and I don't assign to either symbol afterwards - and you seem to be saying that only with mutable types like Array can you change the contents via another symbol ($aa here). Thanks for catching that typo. What you are saying with your above example is correct, and I knew about that before, but it slipped my mind when I wrote my explanation before. I'll try saying what I meant differently here: The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol [or other symbols aliased to either] afterwards. The idea is that, the degree to which === examines 2 variables to consider them equal or not is only so far as they are immutable. So if you say "$foo = $bar", and then "$baz === $foo" returns true, then a subsequent assignment to or type-allowed mutation of $bar won't invalidate that $baz === $foo, but an assignment to $foo would. -- Darren Duncan
Re: === and array-refs
On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: Both the === and eqv operators test the actual values of 2 containers, but that their semantics differ in regards to mutable containers. Given an immutable container/type, such as a number or Str or Seq, both will always return true if the values are the same. With a mutable container, such as an Array, only eqv will return true if the value is the same, and === will return false for 2 containers having the same value. The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol afterwards. For a mutable type like an Array, === returns false on 2 containers because it can't guarantee that someone else holding another symbol for either container won't change its content, and so $a or $b could change after we made the === test, without us causing that to happen, and so for mutable types, === only returns true for 2 aliases, because that is the most it can guarantee that they will be the same. By contrast, eqv does not make the eternal guarantee, and works only on snapshots, so eqv can safely deep-compare mutable types like Arrays, since even if one of them changes afterwards, it doesn't matter, since eqv only guaranteed them equal for that point in time when it executed. So do you mean that this code $a = "One"; $b = "One"; $aa := $a; say "Same before" if $a === $b; $aa = "Two"; say "Same after" if $a === $b; would print Same before Same after because here I have "2 symbols, $a and $b, and $a === $b returns true" and I don't assign to either symbol afterwards - and you seem to be saying that only with mutable types like Array can you change the contents via another symbol ($aa here). But according to S03 this would only print "Same before", because the assigment to $aa would change $a A new form of assignment is present in Perl 6, called binding, used in place of typeglob assignment. It is performed with the := operator. Instead of replacing the value in a container like normal assignment, it replaces the container itself. For instance: my $x = 'Just Another'; my $y := $x; $y = 'Perl Hacker'; After this, both $x and $y contain the string "Perl Hacker", since they are really just two different names for the same variable. -- Markus Laire
