Re: [svn:perl6-synopsis] r14491 - doc/trunk/design/syn
On Thu, Jan 17, 2008 at 01:18:32PM -0800, [EMAIL PROTECTED] wrote: > +contents. Non-container types define truthiness much as Perl 5 does. Except -0.0 ? (Which is a bit of a problem in Perl 5 - if the internals think that it's a number, it's false. If it manages to get stringified, it now is true) Nicholas Clark
[perl #50056] [BUG] "Undefined symbols" on OS X
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote: > > Does C_LIBS have -lreadline included? > > Allison > Here's how 'libs' evolves over the course of configuration on my ibook. Tracing evolution of libs ... init::manifest => init::defaults => -lgdbm -ldbm -ldl -lm -lc init::install => -lgdbm -ldbm -ldl -lm -lc init::miniparrot => -lgdbm -ldbm -ldl -lm -lc init::hints => -lgdbm -ldbm -lm -lc init::headers => -lgdbm -ldbm -lm -lc inter::progs => -lm inter::make => -lm inter::lex => -lm inter::yacc => -lm auto::gcc => -lm auto::backtrace => -lm auto::fink => -lm auto::msvc => -lm auto::attributes => -lm auto::warnings => -lm init::optimize => -lm inter::shlibs => -lm inter::libparrot => -lm inter::charset => -lm inter::encoding => -lm inter::types => -lm auto::ops => -lm auto::pmc => -lm auto::alignptrs => -lm auto::headers => -lm auto::sizes => -lm auto::byteorder => -lm auto::va_ptr => -lm auto::pack => -lm auto::format => -lm auto::isreg => -lm auto::arch => -lm auto::jit => -lm auto::cpu => -lm auto::funcptr => -lm auto::cgoto => -lm auto::inline => -lm auto::gc => -lm auto::memalign => -lm auto::signal => -lm auto::socklen_t => -lm auto::env => -lm auto::aio => -lm auto::gmp => -lm -lgmp auto::readline => -lm -lgmp auto::gdbm => -lm -lgmp auto::snprintf => -lm -lgmp auto::perldoc => -lm -lgmp auto::python => -lm -lgmp auto::m4 => -lm -lgmp auto::ctags => -lm -lgmp auto::revision => -lm -lgmp gen::icu => -lm -lgmp gen::config_h => -lm -lgmp gen::core_pmcs => -lm -lgmp gen::parrot_include => -lm -lgmp gen::languages => -lm -lgmp gen::makefiles => -lm -lgmp gen::platform => -lm -lgmp gen::config_pm => -lm -lgmp
[perl #50056] [BUG] "Undefined symbols" on OS X
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote: > > Does C_LIBS have -lreadline included? > No, it does not. C_LIBS = -lm -lgmp Which is not surprising. If you recall, the result set by auto::readline in the spewing case was 'no'. So with your patch readline is not being found. (BTW: Are you okay with RT 50390?)
Syntax explainer, phase 2: planning
About half a year ago I posted my idea of a program that explains Perl 6
syntax:
http://www.nntp.perl.org/group/perl.perl6.users/2007/07/msg621.html
Differing from my first post I know think that the best idea is to
really parse a Perl 6 program with a fully fledged parser, and emit some
kind of markup language that contains annotations that explains the
semantic for each token.
Now you all know the story: "nothing but perl can parse Perl", and of
course I'm lazy, so I'd like to reuse an existing parser.
The most appealing idea so far is to use rakudo's grammar for
experimenting, and later on STD.pm for the "real thing".
The simplest option is to use a grammar, and write a different action
class for it (the one who's methods are executed when {*} action stubs
are found in the grammar), and instead of returning a syntax tree, I
just return a data structure that contains the position, a description
of the token, and the actual text.
That works fine - until the grammar is changed. So I need to execute
BEGIN blocks, which implies that I need the "normal" parse tree as well.
D'oh.
Do you have any idea how I may circumvent the problem?
I had some thoughts, but none appear to be a good solution:
* build two trees, one normal AST for the BEGIN block evaluation, and
one parse tree for the markup output.
* subclass the normal action class, and annotate the AST with enough
information, and as a second stop, after all BEGIN block were executed,
filter out the interesting information.
* parse the BEGIN blocks with the normal grammar and action class, and
the rest with the modified action class that emits the markup.
Actually I have no idea if any of these could work. Any thoughts?
A second problem is that the information should be accessible for
perldoc. Since the documentation synopsis is indefinitely pending, I
don't really want to rely on perldoc syntax, especially because the data
has to be accessible from the action class.
This could be circumvented by another abstraction layer (for example a
text based DB that contains uniq token names and the description, and
that DB could be used both by the action class and to emit some perldoc).
Are there better ideas, perhaps even some that don't introduce more
layers? ;-)
Any comments are welcome.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
[perl #50398] [PDD17PMC] [Tcl] METHOD, morph, assign...
# New Ticket Created by Will Coleda
# Please include the string: [perl #50398]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50398 >
The recent PCCMETHOD -> METHOD update in the pdd17pmc branch breaks
tcl, since there is a lone METHOD there.
The following naive patch fixes up the syntax...
Index: src/pmc/tclstring.pmc
===
--- src/pmc/tclstring.pmc (revision 25358)
+++ src/pmc/tclstring.pmc (working copy)
@@ -19,7 +19,7 @@
mapsString
{
-METHOD PMC* get_list(STRING* str) {
+METHOD get_list(STRING* str) {
PMC* retval = pmc_new(INTERP, pmc_type(INTERP, string_from_literal(IN
TERP, "TclList")));
INTVAL pos = -1; /* we're going to increment before we use it... */
INTVAL len;
@@ -27,7 +27,9 @@
PMC* P0;
STRING* S0;
-if (! str) return SELF;
+if (! str) {
+ PCCRETURN(PMC *SELF);
+}
/*
* RT#48166 This prevents a segfault; retval gets claimed before it
* it is used below without this register. This shouldn't happen
@@ -166,7 +168,7 @@
done:
Parrot_unregister_pmc(INTERP, retval);
-return retval;
+PCCRETURN(PMC *retval);
}
}
But then fails at runtime:
% ../../parrot tcl.pbc
unable to assign self to this type
current instr.: '__list' pc 25992 (languages/tcl/runtime/conversions.pir:27)
called from Sub '&proc' pc 19294 (languages/tcl/runtime/builtin/proc.pir:106)
called from Sub '_anon' pc 44 (EVAL_4:18)
called from Sub '__load_stdlib' pc 56134 (runtime/tcllib.pir:291)
called from Sub '_main' pc 3 (src/tclsh.pir:36)
Tracing the assign on that line in conversions.pir gives:
25994 assign P0, P1P0=Undef=PMC(0x2f1c398)
P1=TclList=PMC(0x2f1ae7c)
unable to assign self to this type
So, it looks like the get_list call worked (based on the type of P1
and earlier PIR in that file), but that the real issue here is that
assign isn't working.
--
Will "Coke" Coleda
[perl #50400] [BUG] segfault in pdd17pmc branch
# New Ticket Created by Jerry Gay # Please include the string: [perl #50400] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50400 > C:\usr\bin\perl-5.8.8\bin\perl.exe -e "" >PGE\builtins_gen.pir ..\..\parrot.exe -o PGE.pbc --output-pbc PGE.pir ..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir --output=PGE\builtins_gen.pir PGE\builtins.pg NMAKE : fatal error U1077: '..\..\parrot.exe' : return code '0xc005' Stop. NMAKE : fatal error U1077: 'C:\usr\bin\perl-5.8.8\bin\perl.exe' : return code '0x2' Stop. i prefer my COWs unexploded: msvcr80.dll!memcpy(unsigned char * dst=0x1001c301, unsigned char * src=0x, unsigned long count=5) Line 233Asm > libparrot.dll!Parrot_unmake_COW(parrot_interp_t * interp=0x033d11b8, parrot_string_t * s=0x03c53c08) Line 103 + 0x17 bytes C libparrot.dll!string_downcase_inplace(parrot_interp_t * interp=0x033d11b8, parrot_string_t * s=0x03c53c08) Line 2572 + 0xd bytes C libparrot.dll!string_downcase(parrot_interp_t * interp=0x033d11b8, const parrot_string_t * s=0x03c53c58) Line 2548 + 0xd bytesC libparrot.dll!Parrot_downcase_s_s(long * cur_opcode=0x03c3e674, parrot_interp_t * interp=0x033d11b8) Line 449 + 0x19 bytes C libparrot.dll!runops_slow_core(parrot_interp_t * interp=0x033d11b8, long * pc=0x03c3e674) Line 212 + 0x18 bytesC libparrot.dll!runops_int(parrot_interp_t * interp=0x033d11b8, unsigned int offset=22) Line 876 + 0xb bytes C libparrot.dll!runops(parrot_interp_t * interp=0x033d11b8, unsigned int offs=22) Line 104 + 0xd bytes C libparrot.dll!runops_args(parrot_interp_t * interp=0x033d11b8, PMC * sub=0x03bb3900, PMC * obj=0x032db1e0, parrot_string_t * meth_unused=0x, const char * sig=0x102cc884, char * ap=0x0017fe70) Line 230 + 0xd bytesC libparrot.dll!Parrot_runops_fromc_args(parrot_interp_t * interp=0x033d11b8, PMC * sub=0x03bb3900, const char * sig=0x102cc884, ...) Line 299 + 0x1d bytes C libparrot.dll!run_sub(parrot_interp_t * interp=0x033d11b8, PMC * sub_pmc=0x03bb3900) Line 483 + 0x12 bytes C libparrot.dll!do_1_sub_pragma(parrot_interp_t * interp=0x033d11b8, PMC * sub_pmc=0x03bb3900, int action=1) Line 573 + 0xd bytes C libparrot.dll!do_sub_pragmas(parrot_interp_t * interp=0x033d11b8, PackFile_ByteCode * self=0x03bd1090, int action=1, PMC * eval_pmc=0x) Line 707 + 0x11 bytes C libparrot.dll!PackFile_fixup_subs(parrot_interp_t * interp=0x033d11b8, pbc_action_enum_t what=PBC_MAIN, PMC * eval=0x) Line 3738 + 0x18 bytesC libparrot.dll!imcc_run_pbc(parrot_interp_t * interp=0x033d11b8, int obj_file=0, const char * output_file=0x, int argc=3, const char * * argv=0x033d2ef4) Line 791 + 0xd bytes C libparrot.dll!imcc_run(parrot_interp_t * interp=0x033d11b8, const char * sourcefile=0x033d2f2c, int argc=3, const char * * argv=0x033d2ef4) Line 1076 + 0x19 bytesC parrot.exe!main(int argc=3, const char * * argv=0x033d2ef4) Line 56 + 0x15 bytesC parrot.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!760719f1() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!77e0d109() ~jerry
[perl #50402] pb compiling a parrot got from svk on a Leopard MacBook
# New Ticket Created by Stephane Payrard # Please include the string: [perl #50402] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50402 > Doing a perl Configure.pl after a make realclean, I get : Recording configuration data for later retrieval...value for 'revision' in config/gen/config_pm/myconfig.in is undef at lib/Parrot/Configure/Compiler.pm line 392, <$in> line 1. This leads to many compilation errors down the make road. -- cognominal stef
Re: Syntax explainer, phase 2: planning
On Wed, Jan 30, 2008 at 04:08:04PM +0100, Moritz Lenz wrote:
: About half a year ago I posted my idea of a program that explains Perl 6
: syntax:
:
: http://www.nntp.perl.org/group/perl.perl6.users/2007/07/msg621.html
:
: Differing from my first post I know think that the best idea is to
: really parse a Perl 6 program with a fully fledged parser, and emit some
: kind of markup language that contains annotations that explains the
: semantic for each token.
:
: Now you all know the story: "nothing but perl can parse Perl", and of
: course I'm lazy, so I'd like to reuse an existing parser.
:
: The most appealing idea so far is to use rakudo's grammar for
: experimenting, and later on STD.pm for the "real thing".
:
: The simplest option is to use a grammar, and write a different action
: class for it (the one who's methods are executed when {*} action stubs
: are found in the grammar), and instead of returning a syntax tree, I
: just return a data structure that contains the position, a description
: of the token, and the actual text.
:
: That works fine - until the grammar is changed. So I need to execute
: BEGIN blocks, which implies that I need the "normal" parse tree as well.
: D'oh.
Let me correct an oversimplification here. Most grammar changes
will *not* be done by BEGIN blocks. BEGIN blocks (like eval) are a
tool of last resort; they're only there for when it's impossible to
achieve what you want by ordinary means. Perl 6 is very much about
providing more ordinary means for things that used to have to be done
by BEGIN or eval.
Instead, grammar changes will be done by using a module that derives
a grammar from STD. The derived grammar will be defined the same way
the original grammar is, so there is no change of the basic underlying
rules here. If you find a sane way of dealing with STD you should be
able to deal with its derivatives just as easily. Unlike BEGIN blocks,
grammar warping modules come with names and versions and authorities,
so when you warp your language by calling "use", you are doing so in
a controlled fashion, and your new language can still be deterministic,
and produce a well-behaved AST.
: Do you have any idea how I may circumvent the problem?
:
: I had some thoughts, but none appear to be a good solution:
: * build two trees, one normal AST for the BEGIN block evaluation, and
: one parse tree for the markup output.
: * subclass the normal action class, and annotate the AST with enough
: information, and as a second stop, after all BEGIN block were executed,
: filter out the interesting information.
: * parse the BEGIN blocks with the normal grammar and action class, and
: the rest with the modified action class that emits the markup.
:
: Actually I have no idea if any of these could work. Any thoughts?
>From my MAD experiences, I'd say the only guaranteed correct way is to
annotate the existing AST, and to make sure that the standard grammar
mechanism has all the hooks you need to do that. The big evil in the
Perl 5 parser is that it was continually forgetting things. It does
this by lying to itself about what it saw. Or in more moderate terms
"replace this AST with that AST". So when you talk about trying to
maintain a separate AST, I shudder with horror. It's impossible.
So never replace. Always augment and annotate. It will save your
sanity, and stop the flame wars about forcing people to program in
the One True Language. Perl 6 is not about that. It's about being a
metalanguage in which you can express many languages, and doing so in
a sufficiently controlled fashion that we always know what language
any given lexical scope is expressed in. And if we truly know what
language we're parsing at any moment, we can do everything PPI does
without much extra work, and without enforcing arbitrary linguistic
restrictions.
If the current {*} hack is insufficiently powerful for you to
annotate the AST correctly, then we need to negotiate a better hack. :)
: A second problem is that the information should be accessible for
: perldoc. Since the documentation synopsis is indefinitely pending, I
: don't really want to rely on perldoc syntax, especially because the data
: has to be accessible from the action class.
: This could be circumvented by another abstraction layer (for example a
: text based DB that contains uniq token names and the description, and
: that DB could be used both by the action class and to emit some perldoc).
: Are there better ideas, perhaps even some that don't introduce more
: layers? ;-)
:
: Any comments are welcome.
This seems to me to primarily be a naming problem, and the AST gives
you the naming path to get to any particular node. The main thing
you want is some way of naming the top of the AST from within a CHECK
block (or from anywhere else you need to access the structure of the
program from). Possibly this is a part of the %=FOO set of variables,
and we have $=AST or some such to go along with the %=POD variables.
Anywa
Re: Syntax explainer, phase 2: planning
Larry Wall wrote:
> On Wed, Jan 30, 2008 at 04:08:04PM +0100, Moritz Lenz wrote:
> : About half a year ago I posted my idea of a program that explains Perl 6
> : syntax:
> :
> : http://www.nntp.perl.org/group/perl.perl6.users/2007/07/msg621.html
> :
> : Differing from my first post I know think that the best idea is to
> : really parse a Perl 6 program with a fully fledged parser, and emit some
> : kind of markup language that contains annotations that explains the
> : semantic for each token.
> :
> : Now you all know the story: "nothing but perl can parse Perl", and of
> : course I'm lazy, so I'd like to reuse an existing parser.
> :
> : The most appealing idea so far is to use rakudo's grammar for
> : experimenting, and later on STD.pm for the "real thing".
> :
> : The simplest option is to use a grammar, and write a different action
> : class for it (the one who's methods are executed when {*} action stubs
> : are found in the grammar), and instead of returning a syntax tree, I
> : just return a data structure that contains the position, a description
> : of the token, and the actual text.
> :
> : That works fine - until the grammar is changed. So I need to execute
> : BEGIN blocks, which implies that I need the "normal" parse tree as well.
> : D'oh.
>
> Let me correct an oversimplification here. Most grammar changes
> will *not* be done by BEGIN blocks. BEGIN blocks (like eval) are a
> tool of last resort; they're only there for when it's impossible to
> achieve what you want by ordinary means. Perl 6 is very much about
> providing more ordinary means for things that used to have to be done
> by BEGIN or eval.
correction accepted.
I should replace "BEGIN blocks" by "anything that happens at compile time".
> Instead, grammar changes will be done by using a module that derives
> a grammar from STD. The derived grammar will be defined the same way
> the original grammar is, so there is no change of the basic underlying
> rules here. If you find a sane way of dealing with STD you should be
> able to deal with its derivatives just as easily. Unlike BEGIN blocks,
> grammar warping modules come with names and versions and authorities,
> so when you warp your language by calling "use", you are doing so in
> a controlled fashion, and your new language can still be deterministic,
> and produce a well-behaved AST.
... and ideally derived grammars will come with additional documentation
that overrides the STD.pm annotations. Sounds like a plan.
> : Do you have any idea how I may circumvent the problem?
> :
> : I had some thoughts, but none appear to be a good solution:
> : * build two trees, one normal AST for the BEGIN block evaluation, and
> : one parse tree for the markup output.
> : * subclass the normal action class, and annotate the AST with enough
> : information, and as a second stop, after all BEGIN block were executed,
> : filter out the interesting information.
> : * parse the BEGIN blocks with the normal grammar and action class, and
> : the rest with the modified action class that emits the markup.
> :
> : Actually I have no idea if any of these could work. Any thoughts?
>
> From my MAD experiences, I'd say the only guaranteed correct way is to
> annotate the existing AST, and to make sure that the standard grammar
> mechanism has all the hooks you need to do that.
Ok, then I'll do that.
Question to the rakudo hackers: are the hooks there yet?
Start position and end position of the token + token name + key would be
enough, or start postion + a uniq key should work as well.
> The big evil in the
> Perl 5 parser is that it was continually forgetting things. It does
> this by lying to itself about what it saw. Or in more moderate terms
> "replace this AST with that AST". So when you talk about trying to
> maintain a separate AST, I shudder with horror. It's impossible.
> So never replace. Always augment and annotate. It will save your
> sanity, and stop the flame wars about forcing people to program in
> the One True Language. Perl 6 is not about that. It's about being a
> metalanguage in which you can express many languages, and doing so in
> a sufficiently controlled fashion that we always know what language
> any given lexical scope is expressed in. And if we truly know what
> language we're parsing at any moment, we can do everything PPI does
> without much extra work, and without enforcing arbitrary linguistic
> restrictions.
>
> If the current {*} hack is insufficiently powerful for you to
> annotate the AST correctly, then we need to negotiate a better hack. :)
I think the {*} hack can be made sufficiently powerful, but it requires
additional work, for example currently you can't know from looking at $/
which token/regex/rule it comes from.
You can work around it by adding that information in every action
method, but that's boring work and no fun.
Maybe a modifier :trace could annotate that automatically?
> : A second problem is that the information should b
Re: Syntax explainer, phase 2: planning
Moritz Lenz wrote:
> I just ran
> ../../parrot perl6.pbc --target=past t/01-sanity/02-counter.t
> and it seems that I'm able to reconstruct the basic structure (I can
> identify operators and variables and their position in the source code,
> for example), but for example it stores variables this way:
>
> PMC 'PAST::Var' {
> => "$counter"
> => "Undef"
> => "$counter"
> => 192
> }
>
> That's probably all you need for the compiler, but it doesn't go into
> the details, for example that '$counter' is made of a sigil and an
> identifier.
> Is it overkill for a normal compilation to keep that information? Or
> could we add that?
> Or is such a detail level overkill even for a syntax explainer?
Uhm, forget that part;-)
particle++ told me to try --target=parse instead, and that's pretty much
verbose and all I should ever need ;-)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
[perl #50402] pb compiling a parrot got from svk on a Leopard MacBook
On Wed Jan 30 07:26:13 2008, cognominal wrote: > Doing a perl Configure.pl after a make realclean, I get : > > Recording configuration data for later retrieval...value for > 'revision' in config/gen/config_pm/myconfig.in is undef at > lib/Parrot/Configure/Compiler.pm line 392, <$in> line 1. > Can you run, then post the output of, the following: make realclean svk update perl Configure.pl --verbose-step=61 Thank you very much. kid51
[perl #50402] pb compiling a parrot got from svk on a Leopard MacBook
Or, better still: make realclean svk update perl Configure.pl --verbose-step=61 --test
[svn:perl6-synopsis] r14497 - doc/trunk/design/syn
Author: larry Date: Wed Jan 30 10:56:27 2008 New Revision: 14497 Modified: doc/trunk/design/syn/S05.pod Log: At suggestion of monomorph++, clarified that token termination via derives from || semantics Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podWed Jan 30 10:56:27 2008 @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and Larry Wall <[EMAIL PROTECTED]> Date: 24 Jun 2002 - Last Modified: 17 Jan 2008 + Last Modified: 30 Jan 2008 Number: 5 - Version: 71 + Version: 72 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them I rather than "regular @@ -1991,14 +1991,17 @@ =item * -Any part of the regex or rule that I match whitespace, -including whitespace implicitly matched via C<:sigspace>. (However, -token declarations are specifically allowed to recognize whitespace -within a token.) +Any sequential control flow operator such as C<||> or C<&&>. =item * -Any sequential control flow operator such as C<||> or C<&&>. +As a consequence of the previous point, and because the standard +grammar's C<< >> rule defines whitespace using C<||>, the +longest token is also terminated by any part of the regex or rule +that I match whitespace using that rule, including whitespace +implicitly matched via C<:sigspace>. (However, token declarations are +specifically allowed to recognize whitespace within a token by using +such lower-level primitives as C<\h+> or other character classes.) =back
Re: Syntax explainer, phase 2: planning
On Jan 30, 2008 10:36 AM, Moritz Lenz <[EMAIL PROTECTED]> wrote:
>
> Larry Wall wrote:
> > On Wed, Jan 30, 2008 at 04:08:04PM +0100, Moritz Lenz wrote:
> > : Do you have any idea how I may circumvent the problem?
> > :
> > : I had some thoughts, but none appear to be a good solution:
> > : * build two trees, one normal AST for the BEGIN block evaluation, and
> > : one parse tree for the markup output.
> > : * subclass the normal action class, and annotate the AST with enough
> > : information, and as a second stop, after all BEGIN block were executed,
> > : filter out the interesting information.
> > : * parse the BEGIN blocks with the normal grammar and action class, and
> > : the rest with the modified action class that emits the markup.
> > :
> > : Actually I have no idea if any of these could work. Any thoughts?
> >
> > From my MAD experiences, I'd say the only guaranteed correct way is to
> > annotate the existing AST, and to make sure that the standard grammar
> > mechanism has all the hooks you need to do that.
>
> Ok, then I'll do that.
>
> Question to the rakudo hackers: are the hooks there yet?
> Start position and end position of the token + token name + key would be
> enough, or start postion + a uniq key should work as well.
>
well, you may have to dive into PIR to get at it, but it's all there.
for example, see the ws and afterws rules in the rakudo perl 6 grammar
file.
> > The big evil in the
> > Perl 5 parser is that it was continually forgetting things. It does
> > this by lying to itself about what it saw. Or in more moderate terms
> > "replace this AST with that AST". So when you talk about trying to
> > maintain a separate AST, I shudder with horror. It's impossible.
> > So never replace. Always augment and annotate. It will save your
> > sanity, and stop the flame wars about forcing people to program in
> > the One True Language. Perl 6 is not about that. It's about being a
> > metalanguage in which you can express many languages, and doing so in
> > a sufficiently controlled fashion that we always know what language
> > any given lexical scope is expressed in. And if we truly know what
> > language we're parsing at any moment, we can do everything PPI does
> > without much extra work, and without enforcing arbitrary linguistic
> > restrictions.
> >
> > If the current {*} hack is insufficiently powerful for you to
> > annotate the AST correctly, then we need to negotiate a better hack. :)
>
> I think the {*} hack can be made sufficiently powerful, but it requires
> additional work, for example currently you can't know from looking at $/
> which token/regex/rule it comes from.
> You can work around it by adding that information in every action
> method, but that's boring work and no fun.
> Maybe a modifier :trace could annotate that automatically?
>
yes, pge is missing the ability to know the name of the rule it's
currently inside. i'd like it because it'd make debugging and error
message generation easier, so it's on my list of things to implement,
but it's not there yet. i suppose a TODO ticket in RT couldn't
hurt
> > : A second problem is that the information should be accessible for
> > : perldoc. Since the documentation synopsis is indefinitely pending, I
> > : don't really want to rely on perldoc syntax, especially because the data
> > : has to be accessible from the action class.
> > : This could be circumvented by another abstraction layer (for example a
> > : text based DB that contains uniq token names and the description, and
> > : that DB could be used both by the action class and to emit some perldoc).
> > : Are there better ideas, perhaps even some that don't introduce more
> > : layers? ;-)
> > :
> > : Any comments are welcome.
> >
> > This seems to me to primarily be a naming problem, and the AST gives
> > you the naming path to get to any particular node.
>
> Not in the detail level that I want, no. At least not in the general case.
>
> You can't know from the AST if something was matched by or by
> , and any closure can make() $/ something completely different.
> And (<.foo>) leaves no trace that could be used to identify the matching
> regex.
>
> I don't know if that's a problem in reality, or just an academic one.
>
> I just ran
> ../../parrot perl6.pbc --target=past t/01-sanity/02-counter.t
> and it seems that I'm able to reconstruct the basic structure (I can
> identify operators and variables and their position in the source code,
> for example), but for example it stores variables this way:
>
> PMC 'PAST::Var' {
> => "$counter"
> => "Undef"
> => "$counter"
> => 192
> }
>
> That's probably all you need for the compiler, but it doesn't go into
> the details, for example that '$counter' is made of a sigil and an
> identifier.
> Is it overkill for a normal compilation to keep that information? Or
> could we add that?
> Or is such a detail level overkill even for a syntax explainer?
>
your problem here is too much abstraction
Re: [perl #50220] patch implementing get_string for rakudo junctions
Hi, I've taken time to look over the patch properly now. I said it would be good as I patch for the .perl method and that I'd apply it with the name change, but it actually needs a little more than that. Basically, rather than just joining the values, you need to loop over them and call .perl on each of them too, then join those (or easier, just contatentate them onto res). If you could do that and rename it 'perl', then I think it'd be right. Thanks, and sorry for not catching that first time around! Jonathan
Re: Syntax explainer, phase 2: planning
On Wed, Jan 30, 2008 at 07:47:18PM +0100, Moritz Lenz wrote: : particle++ told me to try --target=parse instead, and that's pretty much : verbose and all I should ever need ;-) Hmm, yes, but *only* if that switch merely augments information without destroying information, and doesn't otherwise change how things are actually parsed. Otherwise we're back to the separate-but-equal fallacy. Larry
[perl #50408] Test suite litters $TMPDIR
# New Ticket Created by Andy Dougherty # Please include the string: [perl #50408] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50408 > I happened to look in $TMPDIR today. The directory had *hundreds* of odd files and directories. Poking around a bit, I deduced that parrot's 'make test' is mostly to blame. At least some of the files were put there by t/configure/044-slurp_file.t I haven't figured out what's creating the other things yet. One directory appears to contain a complete copy of MANIFEST. Other directories contain lib/Parrot/Config.pm, lib/Parrot/Revision.pm, and DEVELOPING. Still other directories are empty, but their timestamps match up with directories left behind by parrot. Anyway, I lost quite a bit of time cleaning out all those files and directories. Parrot's test files should clean up after themselves. -- Andy Dougherty [EMAIL PROTECTED]
[perl #50408] Test suite litters $TMPDIR
On Wed Jan 30 11:48:41 2008, doughera wrote: > I happened to look in $TMPDIR today. The directory had *hundreds* of odd > files and directories. Poking around a bit, I deduced that parrot's 'make > test' is mostly to blame. At least some of the files were put there by > > t/configure/044-slurp_file.t > > I haven't figured out what's creating the other things yet. One > directory appears to contain a complete copy of MANIFEST. > Other directories contain lib/Parrot/Config.pm, lib/Parrot/Revision.pm, > and DEVELOPING. Still other directories are empty, but their timestamps > match up with directories left behind by parrot. > > Anyway, I lost quite a bit of time cleaning out all those files and > directories. Parrot's test files should clean up after themselves. > Big overlap of RT #37358. Merging tickets.
Re: [RT#48260] Documentation missing]
Attached are patches to embed.c and runops_cores.c The embed.c patch also includes an attempt to clarify another comment. (It's not obvious that the code is doing all that the comment claims, but I didn't investigate that.) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.comIndex: src/embed.c === --- src/embed.c (revision 25166) +++ src/embed.c (working copy) @@ -117,13 +117,15 @@ =item C -Sets a flag in the interpreter specified by C, any of -C, or C to enable profiling, and -bounds checking respectively or C, C, or -C to disable thread communication and variable sharing, -disable variable sharing but enable thread communication, or to enable variable -sharing. +Sets on any of the following flags, specified by C, in the interpreter: +FlagEffect +C enable bounds checking +C enable profiling, +Cdisable variable sharing and thread communication +Cdisable variable sharing but enable thread communication +Cenable variable sharing. + =cut */ @@ -765,7 +767,10 @@ =item C -RT#48260: Not yet documented!!! +Search the fixup table for a PMC matching the argument. +On a match, set up the appropriate context +If no match, set up a dummy PMC entry +In either case, return a pointer to the PMC =cut Index: src/runops_cores.c === --- src/runops_cores.c (revision 25166) +++ src/runops_cores.c (working copy) @@ -110,7 +110,8 @@ =item C -RT#48260: Not yet documented!!! +Runs the Parrot operations starting at C until there are no more +operations, using the tracing interpreter. =cut
[perl #37358] [CAGE] Tests - cleanup use of temp files
On Wed Jan 30 11:48:41 2008, doughera wrote: > > I haven't figured out what's creating the other things yet. One > directory appears to contain a complete copy of MANIFEST. > Other directories contain lib/Parrot/Config.pm, lib/Parrot/Revision.pm, > and DEVELOPING. Still other directories are empty, but their timestamps > match up with directories left behind by parrot. > Some of the files you mention are created by tests that I wrote. I will look into fixing the problem. However, I have to take vacation days over the next few weeks, so I may not be able to get to them until the second half of February.
[perl #50414] [PDD17PMC] lua METHOD conversion snag
# New Ticket Created by Will Coleda # Please include the string: [perl #50414] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50414 > Attempted to convert lua to use the new METHOD syntax. Went fairly well, despite having to convert things like: return func(parm); to PMC *retval; ... retval = func(parm); PCCRETURN(PMC *retval); ... One sticking point is that after converting all the METHODS to use the new syntax, they can't be invoked from C in the same fashion that they used to be.* What's the proper method for invoking this from inside a PMC (hoping for simpler syntax)? or in straight C? (the problem points are in the the luanumber's MMD section). *The clue, btw, was that when we transform the syntax and then compile, we get errors about using the value from the return of a void function (which turns out to be one of the methods.). petdance++ -- Will "Coke" Coleda
Re: [perl #50414] [PDD17PMC] lua METHOD conversion snag
On Wednesday 30 January 2008 14:11:32 Will Coleda wrote: > What's the proper method for invoking this from inside a PMC (hoping > for simpler syntax)? or in straight C? (the problem points are in the > the luanumber's MMD section). Parrot_PCCINVOKE, or just PCCINVOKE. -- c
Re: [perl #50398] [PDD17PMC] [Tcl] METHOD, morph, assign...
On Jan 30, 2008 10:11 AM, via RT Will Coleda <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Will Coleda > # Please include the string: [perl #50398] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=50398 > > > > > The recent PCCMETHOD -> METHOD update in the pdd17pmc branch breaks > tcl, since there is a lone METHOD there. > > The following naive patch fixes up the syntax... Patch applied in pdd17pmc branch. > But then fails at runtime: Haven't figured this out, though. -- Will "Coke" Coleda
[perl #48260] [TODO] [C] Write function documentation
More C function documentation (src/runops_cores.c, src/embed.c) contributed by Alan Rocker committed in r25372.
Re: [perl #50414] [PDD17PMC] lua METHOD conversion snag
On Jan 30, 2008 5:19 PM, chromatic via RT <[EMAIL PROTECTED]> wrote: > > On Wednesday 30 January 2008 14:11:32 Will Coleda wrote: > > > What's the proper method for invoking this from inside a PMC (hoping > > for simpler syntax)? or in straight C? (the problem points are in the > > the luanumber's MMD section). > > Parrot_PCCINVOKE, or just PCCINVOKE. > > -- c Oh, you mean the thing that's listed in docs/dev/pccmethods.pod ? Whoops. -- Will "Coke" Coleda
Re: [perl #50414] [PDD17PMC] lua METHOD conversion snag
On Wednesday 30 January 2008 16:25:28 Will Coleda wrote: > Oh, you mean the thing that's listed in docs/dev/pccmethods.pod ? I have to read that just about every time I use it too. As I most recently read it on Saturday, it was fresh in my mind. Otherwise I'd have been almost as confused as you! -- c
[perl #50298] [PATCH] Fix the glibc backtrace() configuration test
No one commented unfavorably on this patch, so I suspect that the only way we're really going to find out if it's okay is to apply it to trunk and see if it breaks any smokes. Applied in r25376.
Re: [svn:parrot] r25374 - in trunk/t: manifest steps
On Wednesday 30 January 2008 16:35:59 [EMAIL PROTECTED] wrote:
> Author: jkeenan
> Date: Wed Jan 30 16:35:59 2008
> New Revision: 25374
>
> Modified:
>trunk/t/manifest/02-regenerate_file.t
>trunk/t/manifest/03-regenerate_skip.t
>trunk/t/steps/init_headers-01.t
>trunk/t/steps/init_manifest-02.t
>
> Log:
> Delete copies of MANIFEST in tempdirs after testing.
> Modified: trunk/t/manifest/02-regenerate_file.t
>
> --- trunk/t/manifest/02-regenerate_file.t (original)
> +++ trunk/t/manifest/02-regenerate_file.t Wed Jan 30 16:35:59 2008
> @@ -40,6 +40,7 @@
> ok( !$need_for_file, "No need to regenerate $f" );
> chdir $cwd
> or croak "Unable to change back from temporary directory after
> testing";
> +unlink qq{$tdir/$f} or croak "Unable to delete file from
> tempdir"; }
I can't find anything in PBP that says "Despite the qq{} quoting form being
almost as horrifically ugly as slicing a hash reference, use it and pray your
sanity rolls are all 17+." Why mix string delimiters on the same line?
(Ironically, PBP p. 51 suggests that the second string on that line needs
single quotes.)
That concatenation of paths probably ought to use File::Spec as well, if
portability is important.
Of course, File::Temp (already in use) can create a temporary directory and
and clean it up when the program ends... when used exactly as this test file
already does, in which case I don't understand the purpose of this patch at
all.
-- c
[perl #37358] [CAGE] Tests - cleanup use of temp files
I have identified a relatively few instances in the tests I have written where I used tempfile() without UNLINK =>1 or tempdir() without CLEANUP => 1. I have fixed those situations. I have then done make realclean, perl Configure.pl --test and checked to see whether any files were created under /tmp during the past 5 minutes. None were created. There may, of course, be files run during make test that I didn't write that have these problems. But I think I've caught my cases. kid51
Re: [perl #50408] Test suite litters $TMPDIR
> One directory appears to contain a complete copy of MANIFEST. Other directories contain lib/Parrot/Config.pm, lib/Parrot/Revision.pm, I think those may come from the post-configure revision tests - they use File::Tmp (er, sorry, no source here) and now have a 'remove' flag set but if they fail, not sure it cleans them. I ran into those the other day (on linux) and meant to poke further. a
Re: [RT#48260] Documentation missing]
Attached patch to pmc.c -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.comIndex: src/pmc.c === --- src/pmc.c (revision 25371) +++ src/pmc.c (working copy) @@ -472,7 +472,9 @@ =item C -RT#48260: Not yet documented!!! +Create a class object for this interpreter +Takes an interpreter name and type as arguments +Returns a pointer to the class object =cut
Re: [perl #50398] [PDD17PMC] [Tcl] METHOD, morph, assign...
On Wednesday 30 January 2008 07:11:32 Will Coleda wrote:
> The recent PCCMETHOD -> METHOD update in the pdd17pmc branch breaks
> tcl, since there is a lone METHOD there.
> But then fails at runtime:
>
> % ../../parrot tcl.pbc
>
> unable to assign self to this type
> current instr.: '__list' pc 25992
> (languages/tcl/runtime/conversions.pir:27) called from Sub '&proc' pc 19294
> (languages/tcl/runtime/builtin/proc.pir:106) called from Sub '_anon' pc 44
> (EVAL_4:18)
> called from Sub '__load_stdlib' pc 56134 (runtime/tcllib.pir:291)
> called from Sub '_main' pc 3 (src/tclsh.pir:36)
>
> Tracing the assign on that line in conversions.pir gives:
>
> 25994 assign P0, P1P0=Undef=PMC(0x2f1c398)
> P1=TclList=PMC(0x2f1ae7c)
> unable to assign self to this type
>
> So, it looks like the get_list call worked (based on the type of P1
> and earlier PIR in that file), but that the real issue here is that
> assign isn't working.
Does this patch fix things for you?
-- c
Index: languages/tcl/runtime/builtin/dict.pir
===
--- languages/tcl/runtime/builtin/dict.pir (revision 25377)
+++ languages/tcl/runtime/builtin/dict.pir (working copy)
@@ -107,7 +107,7 @@
$S1 = shift argv
$S2 = value
$S2 .= $S1
- morph value, .Undef
+ value = new 'TclString'
assign value, $S2
goto loop
loop_done:
Index: languages/tcl/src/pmc/tclarray.pmc
===
--- languages/tcl/src/pmc/tclarray.pmc (revision 25377)
+++ languages/tcl/src/pmc/tclarray.pmc (working copy)
@@ -30,11 +30,11 @@
pmclass TclArray
need_ext
dynpmc
-extends Hash
-doeshash
-group tcl_group
-hll Tcl
-mapsHash
+extends Hash
+provides hash
+grouptcl_group
+hll Tcl
+maps Hash
{
/*
Index: languages/tcl/src/pmc/tcldict.pmc
===
--- languages/tcl/src/pmc/tcldict.pmc (revision 25377)
+++ languages/tcl/src/pmc/tcldict.pmc (working copy)
@@ -30,11 +30,11 @@
pmclass TclDict
need_ext
dynpmc
-extends Hash
-doeshash
-group tcl_group
-hll Tcl
-mapsHash
+extends Hash
+provides hash
+grouptcl_group
+hll Tcl
+maps Hash
{
/*
Index: languages/tcl/src/pmc/tclfloat.pmc
===
--- languages/tcl/src/pmc/tclfloat.pmc (revision 25377)
+++ languages/tcl/src/pmc/tclfloat.pmc (working copy)
@@ -15,11 +15,11 @@
pmclass TclFloat
dynpmc
-extends TclObject
-extends Float
-doesfloat
-group tcl_group
-hll Tcl
+extends TclObject
+extends Float
+provides float
+grouptcl_group
+hll Tcl
mapsFloat
{
Index: languages/tcl/src/pmc/tclstring.pmc
===
--- languages/tcl/src/pmc/tclstring.pmc (revision 25377)
+++ languages/tcl/src/pmc/tclstring.pmc (working copy)
@@ -12,11 +12,11 @@
pmclass TclString
dynpmc
-extends String
-doesstring
-group tcl_group
-hll Tcl
-mapsString
+extends String
+provides string
+grouptcl_group
+hll Tcl
+maps String
{
METHOD get_list(STRING* str) {
Index: languages/tcl/src/pmc/tclint.pmc
===
--- languages/tcl/src/pmc/tclint.pmc (revision 25377)
+++ languages/tcl/src/pmc/tclint.pmc (working copy)
@@ -13,12 +13,12 @@
pmclass TclInt
dynpmc
-extends TclObject
-extends Integer
-doesinteger
-group tcl_group
-hll Tcl
-mapsInteger
+extends TclObject
+extends Integer
+provides integer
+grouptcl_group
+hll Tcl
+maps Integer
{
void assign_pmc(PMC* value) {
Index: languages/tcl/src/pmc/tcllist.pmc
===
--- languages/tcl/src/pmc/tcllist.pmc (revision 25377)
+++ languages/tcl/src/pmc/tcllist.pmc (working copy)
@@ -26,7 +26,7 @@
dynpmc
need_ext
extends ResizablePMCArray
-doesarray
+providesarray
group tcl_group
hll Tcl
mapsArray
Re: [perl #50056] [BUG] "Undefined symbols" on OS X
James Keenan via RT wrote: On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote: Does C_LIBS have -lreadline included? No, it does not. C_LIBS = -lm -lgmp Which is not surprising. If you recall, the result set by auto::readline in the spewing case was 'no'. So with your patch readline is not being found. I suspect the reason it's not finding readline is because -lreadline isn't specified in the test compile. OS X (and especially dynamic_lookup) is more strict about only searching for symbols from libraries explicitly included. Try manually adding -lreadline to the test compile in auto::readline and see what happens. (BTW: Are you okay with RT 50390?) Looks good. Thanks! Allison
[perl #50390] [BUG]: Parrot::Configure::Step::Methods::_handle_darwin_for_fink adding superfluous flags
Resolved. Patch applied in r23581.
[perl #50056] [BUG] "Undefined symbols" on OS X
On Wed Jan 30 18:36:27 2008, [EMAIL PROTECTED] wrote:
>
> Try manually adding -lreadline to the test compile in auto::readline and
> see what happens.
>
This is what I did:
Index: config/auto/readline.pm
===
--- config/auto/readline.pm (revision 25380)
+++ config/auto/readline.pm (working copy)
@@ -57,6 +57,9 @@
# this code into a Parrot::Configure::Step::Methods method analogous to
# _handle_darwin_for_fink().
$self->_handle_darwin_for_macports($conf, $osname,
q{readline/readline.h});
+if ( $osname =~ /darwin/i ) {
+$conf->data->add( ' ', libs => '-lreadline' );
+}
$conf->cc_gen('config/auto/readline/readline.in');
my $has_readline = 0;
... and this is what I got:
Determining if your platform supports readline...dyld: lazy symbol
binding failed: Symbol not found: _rl_get_keymap
Referenced from: /Users/jimk/work/parrot/./test
Expected in: dynamic lookup
dyld: Symbol not found: _rl_get_keymap
Referenced from: /Users/jimk/work/parrot/./test
Expected in: dynamic lookup
...no.
kid51
