Re: Inf and NaN
Bill Coffman wrote:
> NegNan doesn't exist, except as a fluke of the representation (see link for
> how they are represented). A -NaN is the same as a NaN. They both fail
> all
> comparison tests, even NaN == NaN is false (unless your compiler optimizes
> the comparison out). Only difference is the way they are stringified,
> which
> should be "NaN", but stringification of NaN is non-standard. Solaris
> compilers will print "-NaN", but gcc only prints "nan". Microsoft compiler
> prints strange stuff.
I am wondering if this NaN != NaN property could be used for the isnan
and finite tests, like so:
int
Parrot_math_isnan(double x)
{
return x != x;
}
int
Parrot_math_finite(double x)
{
return (!Parrot_math_isnan(x - x));
}
That is, if "x != x" it's a NaN. If x is finite, "x - x" should yield
something close to 0. Otherwise, "Inf - Inf" or "NaN - NaN", it's NaN.
Is this not portable enough? Is it better to look at the bits directly?
Ron
Re: [perl #39997] [PATCH] PGE P5 Test Cleanup
On 7/28/06, jerry gay <[EMAIL PROTECTED]> wrote: thanks for the effort! however, i don't want to apply this patch as it is. 're_tests' was stolen directly from perl5's test suite. the idea is that the test data this file contains is implementation-independent. therefore, if some other crazy person (besides patrick) wants to implement yet another perl5 regex engine, they can use the same test data file, and a harness that is particular to their implementation. so, i think it's best to keep the information as to which tests are todo and which are skip out of the test data file. currently, this information exists in the test harness, 'p5rx.t', as i think this is the best place to capture it. i'm glad to see you've expanded the pge p5 tests to the full 900+ tests in the file, and i'll gladly apply a patch that does this while leaving the 're_tests' file intact. while i'm thinking about it, there should be a better way to reflect todo or skip reason. if you're up for the challenge, it would be nice to be able to say something like my %todo= ( # similar for skip 'not yet implemented' => qw< 5 12 35 500 >, 'broken' => qw< 34 63 11 >, ... ); and have something that decorates the subtests appropriately. that's not a requirement for the resubmission of your existing patch, but an extra request. if it doesn't get done this time around, it will eventually ;) Thanks for the feedback, Jerry. I changed the re_tests to not have TODO and SKIP in the descriptions. I also changed the documentation for p5rx.t to say that @todo_tests and @skip_tests now contain the test numbers along with the reason why a certain test is skipped or todo'ed. I attached the patch. David p5rx.patch Description: Binary data
[CAGE] argument type warning
src/pmc/continuation.pmc: In function 'Parrot_Continuation_invoke': src/pmc/continuation.pmc:239: warning: format '%d' expects type 'int', but argument 4 has type 'INTVAL' -- Will Coleda [EMAIL PROTECTED] 1.650.581.2414
Re: [Proposed PATCH lib/Parrot/Test/Embedded.pm] Use Embedded Interpreter for PIR Tests
Am Dienstag, 1. August 2006 07:20 schrieb chromatic: > Hi all, > > Here's a patch for discussion. Two things come to my mind: 1) why is it creating 2 interpreters? What is the $parent used for? And related: is $interp ever cleaned up by calling Parrot_exit()? 2) This looks a bit bogus (there is no 'V' signature char): my $out_pmc = Parrot::Embed::call_sub( $interp, $sub, 'PV', '' ); my $output = Parrot::Embed::get_string_from_pmc($interp, $out_pmc); It could just be: my $output = Parrot::Embed::call_sub( $interp, $sub, 'Sv'); by returning the STRING* directly. leo
Re: [perl #39997] [PATCH] PGE P5 Test Cleanup
On 7/28/06, jerry gay <[EMAIL PROTECTED]> wrote: On 7/28/06, jerry gay <[EMAIL PROTECTED]> wrote: > thanks for the effort! however, i don't want to apply this patch as it > is. 're_tests' was stolen directly from perl5's test suite. the idea > is that the test data this file contains is > implementation-independent. therefore, if some other crazy person > (besides patrick) wants to implement yet another perl5 regex engine, > they can use the same test data file, and a harness that is particular > to their implementation. > > so, i think it's best to keep the information as to which tests are > todo and which are skip out of the test data file. currently, this > information exists in the test harness, 'p5rx.t', as i think this is > the best place to capture it. i'm glad to see you've expanded the pge > p5 tests to the full 900+ tests in the file, and i'll gladly apply a > patch that does this while leaving the 're_tests' file intact. > i forgot to mention something here... patrick has included the todo / skip markers in the perl6 regex test file, and i don't think they belong there, either. these should be factored out into the harness, as well. i have other plans for those tests, like splitting them up into seperate files, but that's another story. I made another patch for 01-regex.t to move the todo and skip tests out form regex_tests, giving the same documentation as I did for p5rx.t. Hopefully this wasn't too soon of a change, considering: i think the best way for me to document all this is to write up some tickets, so i'll be doing that shortly. Regardless, I'll try to work on the tickets when you post them. David 01-regex.patch Description: Binary data
[perl #40030] [PATCH] compiler/imcc missing dependency
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #40030] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40030 > The trunk wasn't compilling in my machines... After digging into Makefile I found missing depencies linking miniparrot and parrot Here's the patch that solved it server parrot # diffstat imcc_dependency.diff CREDITS |5 + config/gen/makefiles/root.in |2 ++ 2 files changed, 7 insertions(+) -- Will work for bandwidth Index: CREDITS === --- CREDITS (revision 13708) +++ CREDITS (working copy) @@ -410,6 +410,11 @@ N: Ron Blaschke D: Win32 patches +N: R�ben Fonseca +E: [EMAIL PROTECTED] +D: Missing dependency to compiler/imcc +S: Braga, Portugal + N: Sam Ruby D: Pythonic and OO patches Index: config/gen/makefiles/root.in === --- config/gen/makefiles/root.in(revision 13708) +++ config/gen/makefiles/root.in(working copy) @@ -742,6 +742,7 @@ $(MINIPARROT) $(LINK) @[EMAIL PROTECTED]@ $(LINKFLAGS) $(LINK_DYNAMIC) \ $(IMCC_DIR)/main$(O) @rpath_blib@ $(ALL_PARROT_LIBS) \ +$(IMCC_DIR)/imclexer$(O) $(IMCC_DIR)/parser_util$(O) $(IMCC_DIR)/debug$(O) \ $(SRC_DIR)/parrot_config$(O) # # TODO build the real miniparrot @@ -749,6 +750,7 @@ $(MINIPARROT) : $(IMCC_DIR)/main$(O) $(GEN_HEADERS) $(LIBPARROT) \ lib/Parrot/OpLib/core.pm $(SRC_DIR)/null_config$(O) $(LINK) @[EMAIL PROTECTED]@ $(LINKFLAGS) $(IMCC_DIR)/main$(O) \ +$(IMCC_DIR)/imclexer$(O) $(IMCC_DIR)/parser_util$(O) $(IMCC_DIR)/debug$(O) \ @rpath_blib@ $(ALL_PARROT_LIBS) $(SRC_DIR)/null_config$(O) $(INSTALLABLEPARROT) : $(IMCC_DIR)/main$(O) $(GEN_HEADERS) $(LIBPARROT) \
Re: [perl #40030] [PATCH] compiler/imcc missing dependency
Am Montag, 31. Juli 2006 22:38 schrieb [EMAIL PROTECTED]: > > The trunk wasn't compilling in my machines... > > After digging into Makefile I found missing depencies linking > miniparrot and parrot +$(IMCC_DIR)/imclexer$(O) $(IMCC_DIR)/parser_util$(O) $(IMCC_DIR)/debug$(O) This isn't correct either. These object files are already part of libparrot (see also IMCC_O_FILES). There must be some other problem elsewhere. leo
[perl #40033] [CAGE] argument type warning
From: Will Coleda (via RT) <[EMAIL PROTECTED]> Date: Mon, 31 Jul 2006 17:45:00 -0700 # New Ticket Created by Will Coleda # Please include the string: [perl #40033] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40033 > src/pmc/continuation.pmc: In function 'Parrot_Continuation_invoke': src/pmc/continuation.pmc:239: warning: format '%d' expects type 'int', but argument 4 has type 'INTVAL' Oops; sorry. Fixed in r13722. -- Bob Rogers http://rgrjr.dyndns.org/
Re: Inf and NaN
Ron Blaschke wrote on 01/08/2006 08:17:
I am wondering if this NaN != NaN property could be used for the isnan
and finite tests, like so:
int
Parrot_math_isnan(double x)
{
return x != x;
}
int
Parrot_math_finite(double x)
{
return (!Parrot_math_isnan(x - x));
}
That is, if "x != x" it's a NaN. If x is finite, "x - x" should yield
something close to 0. Otherwise, "Inf - Inf" or "NaN - NaN", it's NaN.
'x - x' should always yield precisely 0 -
http://docs.sun.com/source/806-3568/ncg_goldberg.html#929 says "The IEEE
standard uses denormalized numbers, which guarantee [...] x = y <=> x -
y = 0", and later states "x - x = +0 for all x [...] Unless the rounding
mode is round toward -Inf, in which case x - x = -0". (Except when x is
+/-Inf or NaN, when it should give NaN.)
Is this not portable enough? Is it better to look at the bits directly?
It doesn't work nicely with optimisers (or at least with MSVC's).
Parrot_math_isnan seems to be handled correctly, but Parrot_math_finite
has problems:
Using VS2003 /O1, it does compile into a call to Parrot_math_isnan, but
with the argument 0.0 (via 'fldz') rather than calculating x-x.
Using VS2003 /O2, it does:
?Parrot_math_finite@@[EMAIL PROTECTED] PROC NEAR
mov eax, 1
ret 0
?Parrot_math_finite@@[EMAIL PROTECTED] ENDP
Using VS2003 /O2 plus /Op ("improve floating-pt consistency") it does
get the correct answer.
Using VS2005 /O0 to /O2, it does get the correct answer by default. But
adding /fp:fast makes it the same as the VS2003 behaviour. (The
documentation says /fp:precise enables behaviour where "Expression
optimizations that are invalid for special values (NaN, +infinity,
-infinity, +0, -0) will not be allowed. The optimizations x-x => 0, x*0
=> 0, x-0 => x, x+0 => x, and 0-x => -x are all invalid for various
reasons (see IEEE 754 and the C99 standard)", but those optimisations
are allowed under /fp:fast because most people care about speed more
than predictable/correct output.)
It seems like the only way to stay safe is to work around the optimiser,
presumably by testing bits or using library functions or writing
assembly code (e.g. with 'fxam' on x86).
Ron
--
Philip Taylor
[EMAIL PROTECTED]
Patch for S05
Hi, there~
This is my patch to S05. I've got many helps from gaal++,
nothingmuch++, Aankhen``++, and many others on #perl6. :D
It is mostly a story about typos as usual... :=)
Cheers,
Agent
Index: D:/projects/Perl6-Syn/S05.pod
===
--- D:/projects/Perl6-Syn/S05.pod (revision 10535)
+++ D:/projects/Perl6-Syn/S05.pod (working copy)
@@ -94,7 +94,7 @@
m:g:i/\s* (\w*) \s* ,?/;
Every modifier must start with its own colon. The delimiter must be
-separated from the final modifier by whitespace if it would be taken
+separated from the final modifier by whitespace if it would otherwise be taken
as an argument to the preceding modifier (which is true for any
bracketing character).
@@ -199,7 +199,7 @@
match variants are defined for them:
ms/match some words/# same as m:sigspace
-ss/match some words/replace those words/ # same ss s:sigspace
+ss/match some words/replace those words/ # same as s:sigspace
Conjecture: This might become sufficiently idiomatic that C would
be better as a "stuttered" C instead, much as C became idiomatic.
@@ -497,7 +497,7 @@
/ [foo]**{1,3} /
(At least, it fails in the absence of C,
-which is likely to be unimplemented in Perl 6.0.0 anyway).
+which is likely to be unimplemented in Perl 6.0.0 anyway.)
The optimizer will likely optimize away things like C<**{1..*}>
so that the closure is never actually run in that case. But it's
@@ -784,7 +784,7 @@
=item *
-A leading C or Cindicates a code assertion:
+A leading C or C indicates a code assertion:
/ (\d**{1..3}) /
/ (\d**{1..3}) /
@@ -1011,7 +1011,7 @@
The Perl 6 equivalents are:
regex { pattern }# always takes {...} as delimiters
-rx / pattern /# can take (almost any) chars as delimiters
+ rx/ pattern /# can take (almost any) chars as delimiters
You may not use whitespace or alphanumerics for delimiters. Space is
optional unless needed to distinguish from modifier arguments or
@@ -1021,14 +1021,14 @@
rx ( pattern ) # okay
rx( 1,2,3 ) # tries to call rx function
-(This is true of all quotelike constructs in Perl 6.)
+(This is true for all quotelike constructs in Perl 6.)
=item *
-If either form needs modifiers, they go before the opening delimiter:
+If modifiers are needed by either form, they go before the opening delimiter:
$regex = regex :g:s:i { my name is (.*) };
- $regex = rx:g:s:i / my name is (.*) /;# same thing
+ $regex = rx:g:s:i / my name is (.*) /;# same thing
Space is necessary after the final modifier if you use any
bracketing character for the delimiter. (Otherwise it would be taken as
@@ -1050,7 +1050,7 @@
=item *
As the syntax indicates, it is now more closely analogous to a C
-constructor. In fact, that analogy will run I deep in Perl 6.
+constructor. In fact, that analogy runs I deep in Perl 6.
=item *
@@ -1120,10 +1120,10 @@
regex ident { [ : | _: ]: \w+: }
-but rather easier to read. The bare C<*>, C<+> and C quantifiers
+but rather easier to read. The bare C<*>, C<+>, and C quantifiers
never backtrack in a C unless some outer regex has specified a
C<:panic> option that applies. If you want to prevent even that, use
-C<*:>, C<+:> or C to prevent any backtracking into the quantifier.
+C<*:>, C<+:>, or C to prevent any backtracking into the quantifier.
If you want to explicitly backtrack, append either a C or a C<+>
to the quantifier. The C forces minimal matching as usual,
while the C<+> forces greedy matching. The C declarator is
@@ -1248,7 +1248,7 @@
=item *
Attempting to backtrack past a C<< >> causes the complete match
-to fail (like backtracking past a C<< >>. This is because there's
+to fail (like backtracking past a C<< >>). This is because there's
now no preceding text to backtrack into.
=item *
@@ -1272,7 +1272,7 @@
=item *
-...so too you can have anonymous regexes and I regexes (and tokens,
+...so too you can have anonymous regexes and I regexes (as
well as tokens
and rules):
token ident { [|_] \w* }
@@ -1546,7 +1546,7 @@
=item *
Inside a regex, the C<$/> variable holds the current regex's
-incomplete C object (which can be modified via the internal C<$/>.
+incomplete C object (which can be modified via the internal C<$/>).
For example:
$str ~~ / foo # Match 'foo'
@@ -1651,13 +1651,13 @@
=item *
The array elements of the regex's C object (i.e. C<$/>)
-store individual C objects representing the substrings that where
+store individual C objects representing the substrings that were
matched and captured by the first, second, third, etc. I
(i.e. unnested) subpatterns. So these elements can be treated like fully
fledged match results. For example:
if m/ (\d\d\d\d)-(\d\d)-(\d\d) (BCE?|AD|CE)?/ {
- ($yr, $mon, $day) = $/[0..2]
+ ($yr, $mon, $day) = $/[0..2];
$era = "$3" if $3
[perl #40039] [BUG] r13762: compilers/bcg/ fails to build with msvc -- unresolved external symbol
# New Ticket Created by Jerry Gay # Please include the string: [perl #40039] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40039 > parrot builds successfully, but compilers/bcg/ fails. below is the output from nmake. ~jerry D:\usr\local\perl\bin\perl.exe -e "chdir shift @ARGV; system 'nmake', @A RGV; exit $? >> 8;" compilers\bcg Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. D:\usr\local\perl\bin\perl.exe "D:/usr/local/parrot/bug\tools\build\pmc2c.pl" -- dump bcg.pmc D:\usr\local\perl\bin\perl.exe "D:/usr/local/parrot/bug\tools\build\pmc2c.pl" -- c bcg.pmc D:\usr\local\perl\bin\perl.exe "D:/usr/local/parrot/bug\tools\build\pmc2c.pl" -- library bcg_group --c bcg.pmc cl -c -nologo -GF -W3 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DNO_HASH_ SEED -Zi -DHAS_JIT -DI386 -Fobcg.obj -I"D:/usr/local/parrot/bug\include" -I"D:/usr/local/parrot/bug\src\pmc" bcg.c bcg.c cl -c -nologo -GF -W3 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DNO_HASH_ SEED -Zi -DHAS_JIT -DI386 -Folib-bcg_group.obj -I"D:/usr/local/parrot/bu g\include" -I"D:/usr/local/parrot/bug\src\pmc" bcg_group.c bcg_group.c link -nologo -nodefaultlib -debug -dll -out:bcg_group.dll "lib-bcg_group.obj" "b cg.obj" oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.li b advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.l ib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib "D:/usr/loc al/parrot/bug/libparrot.lib" LINK : LNK6004: bcg_group.dll not found or not built by the last incremental lin k; performing full link Creating library bcg_group.lib and object bcg_group.exp bcg.obj : error LNK2019: unresolved external symbol _Parrot_PMC_typenum referenc ed in function _Parrot_BCG_class_init bcg_group.dll : fatal error LNK1120: 1 unresolved externals partial link bcg_group.dll failed (24576) NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'D:\usr\local\perl\bin\perl.exe' : return code '0x2' Stop.
Re: Inf and NaN
Philip Taylor wrote: > Ron Blaschke wrote on 01/08/2006 08:17: >> >> I am wondering if this NaN != NaN property could be used for the isnan >> and finite tests, like so: [snip] >> Is this not portable enough? Is it better to look at the bits directly? [great stuff snipped] > It seems like the only way to stay safe is to work around the optimiser, > presumably by testing bits or using library functions or writing > assembly code (e.g. with 'fxam' on x86). Thanks a lot for sharing your deep insights, Philip. Judging from Bill's and your input it's probably best to look at the bits directly. Too bad, the two lines solution would have been really tempting. Resist the dark side of code one must. ;-) Thanks, Ron
Legacy Dereferencing Syntax Used in S05
Hi, all~~
S05 makes widely use of the syntax @{ $capture } and %{ $capture }
while other synopses remarkably don't.
According to S02, {...} should normall be a closure or a hash
subscript and S02 uses the syntax @( $arrayref ) and %( $hashref )
consistently. Is S05 simply out of sync or is the legacy dereferencing
syntax still valid Perl 6 but not specified explicitly?
BTW, PerlJam on #perl6 also found the uses of @{...} appear vestigial.
Regards,
Agent
Re: Legacy Dereferencing Syntax Used in S05
On Tue, Aug 01, 2006 at 11:17:21PM +0800, Agent Zhang wrote:
: Hi, all~~
:
: S05 makes widely use of the syntax @{ $capture } and %{ $capture }
: while other synopses remarkably don't.
:
: According to S02, {...} should normall be a closure or a hash
: subscript and S02 uses the syntax @( $arrayref ) and %( $hashref )
: consistently. Is S05 simply out of sync or is the legacy dereferencing
: syntax still valid Perl 6 but not specified explicitly?
:
: BTW, PerlJam on #perl6 also found the uses of @{...} appear vestigial.
Yes, it's vestigial. I'll fix it later today when I apply your patch.
(Or most of your patch. I disagree with a few of the fixes...) Thanks!
Larry
Re: [perl #39997] [PATCH] PGE P5 Test Cleanup
On 7/31/06, David Romano <[EMAIL PROTECTED]> wrote: Thanks for the feedback, Jerry. I changed the re_tests to not have TODO and SKIP in the descriptions. I also changed the documentation for p5rx.t to say that @todo_tests and @skip_tests now contain the test numbers along with the reason why a certain test is skipped or todo'ed. I attached the patch. looks great, david! bonus points for adding the todo/skip reasons. applied as r13728. ~jerry
Re: [Proposed PATCH lib/Parrot/Test/Embedded.pm] Use Embedded Interpreter for PIR Tests
On Tuesday 01 August 2006 02:52, Leopold Toetsch wrote: > Two things come to my mind: > 1) why is it creating 2 interpreters? Per my experiments, this worked out the best. That is, if there's an error in the compiled code, reusing an interpreter gave weird answers. I haven't tracked this down in more detail. > What is the $parent used for? It's the parent of the interpreter created in the pir_output_*() functions. Creating new subsequent interpreters without providing $parent gave weird encoding assertion errors. >And related: is $interp ever cleaned up by calling Parrot_exit()? Nope, but I'll put a destructor in Embed::Parrot::Interpreter when I get that far. > 2) This looks a bit bogus (there is no 'V' signature char): > > my $out_pmc = Parrot::Embed::call_sub( $interp, $sub, 'PV', '' ); > my $output = Parrot::Embed::get_string_from_pmc($interp, $out_pmc); > > It could just be: > > my $output = Parrot::Embed::call_sub( $interp, $sub, 'Sv'); > > by returning the STRING* directly. True, but I prefer to use the PMC methods rather than fiddling around converting strings to and from the C format. If this API changes to send and receive char * instead of STRING *, I'll happily use that. -- c
Re: Questions
On Mon, Jul 31, 2006 at 10:30:36PM -0700, chromatic wrote: > * What's the best way to integrate building this module from the main > Makefile? Should it be part of that process? That depends. Are any of the standard regression tests going to require this module? > * Where should the built module go, and how can we make that work in a > cross-platform way? Copying the two (for now) necessary files out of > blib/lib appropriately is probably the right answer. I'd say let Module::Build handle the install. The install process can invoke Module::Build if it's to be part of the default install. > * Parrot::Embed uses Module::Build, mostly because I find EU::MM bletcherous > and hateful. Porting it to EU::MM is pretty easy, but I haven't done it > because it needs a custom step before testing to build a PBC file. Leaving > it as it is makes maintaining it a little easier for me, but it makes M::B a > dependency for building Parrot. That may or may not be an issue, depending > on what Bundle::Parrot pulls in. I'll vote for adding M::B to Bundle::Parrot. -J -- pgp3vjEjBIIGO.pgp Description: PGP signature
Re: Questions
On Tuesday 01 August 2006 12:24, Joshua Hoblitt wrote: > On Mon, Jul 31, 2006 at 10:30:36PM -0700, chromatic wrote: > > * What's the best way to integrate building this module from the main > > Makefile? Should it be part of that process? > That depends. Are any of the standard regression tests going to require > this module? For now, no. I'd like to have the option of running the standard regression tests through it, but it's not stable enough yet. > > * Where should the built module go, and how can we make that work in a > > cross-platform way? Copying the two (for now) necessary files out of > > blib/lib appropriately is probably the right answer. > > I'd say let Module::Build handle the install. The install process can > invoke Module::Build if it's to be part of the default install. How about when just building Parrot but not installing it? I'd also like to run the Parrot::Embed tests as part of the normal Parrot test suite. -- c
Re: Questions
On Tue, Aug 01, 2006 at 12:30:28PM -0700, chromatic wrote: > On Tuesday 01 August 2006 12:24, Joshua Hoblitt wrote: > > I'd say let Module::Build handle the install. The install process can > > invoke Module::Build if it's to be part of the default install. > > How about when just building Parrot but not installing it? > > I'd also like to run the Parrot::Embed tests as part of the normal Parrot > test > suite. I'm guessing that Parrot::Embed won't be the last M::B module that were going to stand to ship with Parrot. It would be nice to solve this issue in a somewhat general way so other packages can more or less be mechanically included for use. If not for installation, at least for runtime. While I'd been hoping that M::B had a public method for changing 'blib' this appears not to be the case (just looking at the pod). If this functionality were added we could have the root makefile invoke each module as `perl Build.PL --blib [buildroot/somedir]`, use that path for runtime testing, and still let M::B handle the packages own installation. I admit this scheme is a little hackish but it avoids having to do a custom setup for each bundled package. Thoughts? -J -- pgpd1yK3Vaurb.pgp Description: PGP signature
[svn:parrot-pdd] r13740 - in trunk: . docs/pdds
Author: allison
Date: Tue Aug 1 13:00:29 2006
New Revision: 13740
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Namespace opcodes now accept arrays to select multidimensional
namespaces again. The namespace object methods for setting/retrieving
namespaces and globals are eliminated as redundant.
Modified: trunk/docs/pdds/pdd21_namespaces.pod
==
--- trunk/docs/pdds/pdd21_namespaces.pod(original)
+++ trunk/docs/pdds/pdd21_namespaces.podTue Aug 1 13:00:29 2006
@@ -18,10 +18,8 @@
=item - Namespaces should be hierarchical
-=item - The get_namespace opcode takes a multidimensional hash key
-
-=item - The get_namespace method on a namespace object takes an array of
-name strings
+=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
@@ -125,58 +123,13 @@
interface>, which allows direct naming in the native style of the namespace's
HLL.
-One part of this interface consists of standard Parrot hash interface,
-with all its keys, values, lookups, deletions, etc. Just treat the
-namespace like a hash. (It probably is one, really, deep down.)
-
-The other part of this interface is a series of methods on the namespace
-object. These parallel the namespace opcodes but instead of taking a
-constant hash key argument to select a multi-level namespace, they
-take an array PMC.
-
-=over 4
-
-=item get_namespace
-
-$P1 = $P2.get_namespace($S3)
-
-Retrieve the namespace $P1 from within the namespace $P2 by a simple
-string name $S3.
-
-$P1 = $P2.get_namespace($P3)
-
-Retrieve the namespace $P1 from within the namespace $P2 by an array of
-names $P3 for a multi-level namespace.
-
-=item set_namespace
-
-$P1.set_namespace($P2, $P3)
-
-Add the namespace $P3 under a name denoted by an array of names $P2
-for a multi-level namespace relative to the namespace $P1.
-
-=item get_global
-
-$P1 = $P2.get_global($S3)
-
-Retrieve a symbol $P1 from the namespace $P2, with the name $S3.
+This interface consists of standard Parrot hash interface, with all its
+keys, values, lookups, deletions, etc. Just treat the namespace like a
+hash. (It probably is one, really, deep down.)
-$P1 = $P2.get_global($P3, $S4)
+The untyped interface also has one method:
-Retrieve a symbol $P1, with the name $S4, from a namespace selected by an
-array $P3 relative to the namespace $P2.
-
-=item set_global
-
-$P1.set_global($S2, $P3)
-
-Store a symbol $P3, in the namespace $P1 with the name $S2.
-
-$P1.set_global($P2, $S3, $P4)
-
-Store a symbol $P4, with the name $S3, in a namespace selected by an
-array $P2 relative to the namespace $P1. If the given namespace does
-not exist it is created.
+=over 4
=item get_name
@@ -370,13 +323,11 @@
=head2 Namespace Opcodes
-Note that all namespace opcodes operate from the local HLL root
-namespace. The namespace opcodes all have 3 variants: one that operates
-from the currently selected namespace (i.e. the namespace of the
-currently executing subroutine), one that operates from the HLL root
-namespace (identified by "hll" in the opcode name), and one that
-operates from the true root namespace (identified by "root" in the
-name).
+The namespace opcodes all have 3 variants: one that operates from the
+currently selected namespace (i.e. the namespace of the currently
+executing subroutine), one that operates from the HLL root namespace
+(identified by "hll" in the opcode name), and one that operates from the
+true root namespace (identified by "root" in the name).
=over 4
@@ -389,6 +340,13 @@
Add the namespace PMC $P1 under the name denoted by a multidimensional
hash key.
+set_namespace $P1, $P2
+set_hll_namespace $P1, $P2
+set_root_namespace $P1, $P2
+
+Add the namespace PMC $P2 under the name denoted by an array of name
+strings $P1.
+
=item del_namespace
{{ NOTE: this opcode has been removed from the spec. The del_namespace
@@ -410,18 +368,41 @@
Retrieve the namespace denoted by a multidimensional hash key and
store it in C<$P1>.
-The opcodes for namespace lookups only accept hash keys. Thus, to get
-the "Foo::Bar" namespace from the top-level of the HLL, if the name was
-known at compile time, you could use this opcode:
+$P1 = get_namespace $P2
+$P1 = get_hll_namespace $P2
+$P1 = get_root_namespace $P2
+
+Retrieve the namespace denoted by the array of names $P2 and store it in
+C<$P1>.
+
+Thus, to get the "Foo::Bar" namespace from the top-level of the HLL if
+the name was known at compile time, you could retrieve the namespace
+with a key:
$P0 = get_hll_namespace ["Foo"; "Bar"]
-If the name was not known at compile time, you would use a method call
-on the namespace object instead:
+If the name was not know
[svn:perl6-synopsis] r10536 - doc/trunk/design/syn
Author: larry
Date: Tue Aug 1 11:57:10 2006
New Revision: 10536
Modified:
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S05.pod
Log:
Fixes suggested by agentzh++.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Aug 1 11:57:10 2006
@@ -12,11 +12,11 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 19 Jul 2006
+ Last Modified: 1 Aug 2006
Number: 3
- Version: 51
+ Version: 52
-=head1 Changes to existing operators
+=head1 Changes to Perl 5 operators
Several operators have been given new names to increase clarity and better
Huffman-code the language, while others have changed precedence. (If an
@@ -26,6 +26,9 @@
=over
+=item * Perl 5's C<${...}>, C<@{...}>, C<%{...}>, etc. dereferencing
+forms are now C<$(...)>, C<@(...)>, C<%(...)>, etc. instead.
+
=item * C<< -> >> becomes C<.>, like the rest of the world uses.
=item * The string concatenation C<.> becomes C<~>. Think of it as
@@ -1442,7 +1445,7 @@
!== !~~ !eq !=:= !=== !eqv etc.
tight and &&
tight or|| ^^ //
-ternary ?? !!
+conditional ?? !!
assignment := ::= =>
(also = with simple lvalues)
+= -= **= xx= .= etc.
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podTue Aug 1 11:57:10 2006
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
- Last Modified: 1 July 2006
+ Last Modified: 1 Aug 2006
Number: 5
- Version: 28
+ Version: 29
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I because they haven't been
@@ -94,7 +94,7 @@
m:g:i/\s* (\w*) \s* ,?/;
Every modifier must start with its own colon. The delimiter must be
-separated from the final modifier by whitespace if it would be taken
+separated from the final modifier by whitespace if it would otherwise be taken
as an argument to the preceding modifier (which is true for any
bracketing character).
@@ -199,7 +199,7 @@
match variants are defined for them:
ms/match some words/ # same as m:sigspace
-ss/match some words/replace those words/ # same ss s:sigspace
+ss/match some words/replace those words/ # same as s:sigspace
Conjecture: This might become sufficiently idiomatic that C would
be better as a "stuttered" C instead, much as C became idiomatic.
@@ -497,7 +497,7 @@
/ [foo]**{1,3} /
(At least, it fails in the absence of C,
-which is likely to be unimplemented in Perl 6.0.0 anyway).
+which is likely to be unimplemented in Perl 6.0.0 anyway.)
The optimizer will likely optimize away things like C<**{1..*}>
so that the closure is never actually run in that case. But it's
@@ -784,7 +784,7 @@
=item *
-A leading C or Cindicates a code assertion:
+A leading C or C indicates a code assertion:
/ (\d**{1..3}) /
/ (\d**{1..3}) /
@@ -1011,7 +1011,7 @@
The Perl 6 equivalents are:
regex { pattern }# always takes {...} as delimiters
-rx / pattern /# can take (almost any) chars as delimiters
+ rx/ pattern /# can take (almost any) chars as delimiters
You may not use whitespace or alphanumerics for delimiters. Space is
optional unless needed to distinguish from modifier arguments or
@@ -1021,14 +1021,14 @@
rx ( pattern ) # okay
rx( 1,2,3 ) # tries to call rx function
-(This is true of all quotelike constructs in Perl 6.)
+(This is true for all quotelike constructs in Perl 6.)
=item *
If either form needs modifiers, they go before the opening delimiter:
$regex = regex :g:s:i { my name is (.*) };
- $regex = rx:g:s:i / my name is (.*) /;# same thing
+ $regex = rx:g:s:i / my name is (.*) /;# same thing
Space is necessary after the final modifier if you use any
bracketing character for the delimiter. (Otherwise it would be taken as
@@ -1050,7 +1050,7 @@
=item *
As the syntax indicates, it is now more closely analogous to a C
-constructor. In fact, that analogy will run I deep in Perl 6.
+constructor. In fact, that analogy runs I deep in Perl 6.
=item *
@@ -1120,10 +1120,10 @@
regex ident { [ : | _: ]: \w+: }
-but rather easier to read. The bare C<*>, C<+> and C quantifiers
+but rather easier to read. The bare C<*>, C<+>, and C quantifiers
never backtrack in a C unless some outer regex has specified a
C<:panic> option that applies. If you want to prevent even that, use
-C<*:>, C<+:> or C to prevent
Initialization and Finalization hooks
I'm trying to implement ruby BEGIN and END blocks.
I can generate the blocks just fine. I just need to generate pir so they
get called at the right time.
BEGIN{} and END {} semantic are described below.
I think that these are general use cases that should be provided by parrot.
Maybe the solution is two stacks of subs in the interpreter structure.
One for initialization and one for finalization which are traversable
and modifiable using opcodes or a specialized pmc.
My take is that he initialization stack gets executed just before :main
and the finalization stack gets executed just before interpreter
termination.
Initialization should occur in the order that compilation units are
loaded and secondarily in the order that BEGIN or initialization blocks
occur within a compilation unit.
Kevin
From
http://www.ruby-doc.org/docs/ruby-doc-bundle/Manual/man-1.4/syntax.html#BEGIN_proc
BEGIN
Examples:
BEGIN {
...
}
Syntax:
BEGIN '{'
expr..
'}'
Registers the initialize routine. The block followed after |BEGIN| is
evaluated before any other statement in that file (or string). If
multiple |BEGIN| blocks are given, they are evaluated in the appearing
order.
The |BEGIN| block introduce new local-variable scope. They don't share
local variables with outer statements.
The |BEGIN| statement can only appear at the toplevel.
END
Examples:
END {
...
}
Syntax:
END '{' expr.. '}'
Registers finalize routine. The block followed after |END| is evaluated
just before the interpreter termination. Unlike |BEGIN|, |END| blocks
shares their local variables, just like blocks.
The |END| statement registers its block only once at the first
execution. If you want to register finalize routines many times, use
at_exit
.
The |END| statement can only appear at the toplevel. Also you cannot
cancel finalize routine registered by |END|.
Re: [perl #39997] [PATCH] PGE P5 Test Cleanup
On 7/31/06, David Romano <[EMAIL PROTECTED]> wrote: I made another patch for 01-regex.t to move the todo and skip tests out form regex_tests, giving the same documentation as I did for p5rx.t. Hopefully this wasn't too soon of a change, considering: On 7/28/06, jerry gay <[EMAIL PROTECTED]> wrote: > i think the best way for me to document all this is to write up some > tickets, so i'll be doing that shortly. Regardless, I'll try to work on the tickets when you post them. again, great work. applied as r13746. i'll get some tickets in soon. ~jerry
Re: [svn:parrot-pdd] r13740 - in trunk: . docs/pdds
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: allison Date: Tue Aug 1 13:00:29 2006 New Revision: 13740 Modified: trunk/docs/pdds/pdd21_namespaces.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Namespace opcodes now accept arrays to select multidimensional namespaces again. The namespace object methods for setting/retrieving namespaces and globals are eliminated as redundant. How does this handle the case where namespaces have a sigil or some other sort of name mangling? Aren't the get/set namespace methods an essential part of the typed interface? -- Matt Diephouse http://matt.diephouse.com
Re: resizablepmcarray, assign.
From: Will Coleda <[EMAIL PROTECTED]> Date: Mon, 31 Jul 2006 20:48:06 -0400 On Jul 31, 2006, at 8:13 PM, Bob Rogers wrote: > > make: *** No rule to make target `runtime/builtin/set.pir', needed > by `runtime/builtins.pir'. Stop. Your timing is impeccable ^_^. Thanks for the MANIFEST fix. Just my luck. No problem. Try upping again, the tcl makefile should be ok. (need to re Configure.pl to regen the makefile in tcl) Great; it works for me now. ... And thank you for your patience. Tcl has had a lot of commits in the past week or so, it's been a tad bumpy. =-) Again, no problem; I know how it feels. ... And in the time it's taken to get this far, we've changed how we're invoking [set] during the compile phase, so we're up to 196 lines (more inlining in :main) Actually, I'm getting 153 lines . . . but I'm afraid I can't follow it, and am out of time to study it. I was hoping something would jump out at me. Sorry . . . -- Bob
Re: Questions
On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:
While I'd been hoping that M::B had a public method for changing
'blib'
this appears not to be the case (just looking at the pod). If this
functionality were added we could have the root makefile invoke each
module as `perl Build.PL --blib [buildroot/somedir]`, use that path
for
runtime testing, and still let M::B handle the packages own
installation. I admit this scheme is a little hackish but it avoids
having to do a custom setup for each bundled package. Thoughts?
That syntax works:
% perl Build.PL --blib=foobar
Checking whether your kit is complete...
Looks good
Checking prerequisites...
Looks good
Creating new 'Build' script for 'FLV-Info' version '0.11'
% ./Build
lib/FLV/File.pm -> foobar/lib/FLV/File.pm
...
% perl -MModule::Build -le'print Module::Build->VERSION'
0.2801
This also works:
my $mb = Module::Build->new(
...
);
$mb->blib('foobar');
$mb->create_build_script;
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Questions
On Tue, Aug 01, 2006 at 10:29:52PM -0500, Chris Dolan wrote:
> On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:
>
> >While I'd been hoping that M::B had a public method for changing
> >'blib'
> >this appears not to be the case (just looking at the pod). If this
> >functionality were added we could have the root makefile invoke each
> >module as `perl Build.PL --blib [buildroot/somedir]`, use that path
> >for
> >runtime testing, and still let M::B handle the packages own
> >installation. I admit this scheme is a little hackish but it avoids
> >having to do a custom setup for each bundled package. Thoughts?
>
> That syntax works:
>
> % perl Build.PL --blib=foobar
> Checking whether your kit is complete...
> Looks good
>
> Checking prerequisites...
> Looks good
>
> Creating new 'Build' script for 'FLV-Info' version '0.11'
> % ./Build
> lib/FLV/File.pm -> foobar/lib/FLV/File.pm
> ...
> % perl -MModule::Build -le'print Module::Build->VERSION'
> 0.2801
>
> This also works:
>
> my $mb = Module::Build->new(
> ...
> );
> $mb->blib('foobar');
> $mb->create_build_script;
Well, I guess that's what I get for reading the documentation instead of
the code. ;)
-J
--
pgpDAZkgeUy6C.pgp
Description: PGP signature
Shared Lib fro Dynamic PMC
Hi, I need to have a shared lib for a Dynamic PMC. The shared lib is generated from my own code. What is a good location to place the shared lib that I generate? Is lib/blib a good location? This is for Byte Code generator. -- Thanks, Vishal
