Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua
Patrick R. Michaud wrote:
On Sat, Dec 15, 2007 at 05:45:56PM +0200, Allison Randal wrote:
Patrick R. Michaud via RT wrote:
Yes, I didn't quite expect anyone to be using PCT::HLLCompiler with
PAST-pm, or supplying their own PAST-POST transformation.
If we need to put the ostgrammar back into the HLLCompiler, we can do
that.
Supplying your own PAST-POST transformation should at least be an
option. HLLCompiler is useful for all HLLs, even ones that don't use
PGE, NQP, PAST, or POST at all in their implementation.
It is possible now. I've been thinking that the way for someone to
supply a custom PAST-POST transformation would be any or all of:
1. Use the addstage(), removestage(), or stages() methods to
change the compiler stage sequence and/or introduce new
or replacement stages for the PAST-POST step.
2. Subclass the PCT::HLLCompiler class to provide a custom
'post' method that calls whatever is desired.
3. Subclass the PAST::Compiler class to provide custom PAST-POST
transformations that might not exist in standard PCT.
Given that this gives us at least three good ways to supply
a custom PAST-POST transformation into PCT::HLLCompiler, I didn't
think we really needed a fourth one that is specific to ostgrammars
and TGE.
I'm also thinking that HLLGrammar may evolve slightly so that
each translator can globally register itself with HLLCompilers as
I know how to transform something of type Foo into another thing
of type Bar. Then an ostgrammar would simply register itself
as another PAST-POST converter, and a HLLCompiler would have some way of
saying use the ostgrammar instead of POST::Compiler.
The monthly release is today.
So in Lua, I reverted the revision 23368 (HLLCompiler -
PCT::HLLCompiler). And Lua works with the old HLLCompiler library.
And I'll try to overload PCT::HLLCompiler for the next release 0.5.2.
But, I've another problem : some failure with languages/lua/t/test_lex.t
The following patch fixes it.
But I don't understand why now I must duplicate the declaration of the
token 'ws' in lua51_testlex.pg grammar ; previously this token was
imported for lua51.pg (the full Lua Grammar).
François.
Pm
Index: languages/lua/src/lua51_testlex.pg
===
--- languages/lua/src/lua51_testlex.pg (revision 24033)
+++ languages/lua/src/lua51_testlex.pg (working copy)
@@ -92,6 +92,13 @@
| \]
}
+token ws {
+[ \s+
+| '--' long_comment
+| '--' \N*
+]*
+}
+
=head1 AUTHOR
Francois Perrad
Index: languages/lua/test_lex.pir
===
--- languages/lua/test_lex.pir (revision 24033)
+++ languages/lua/test_lex.pir (working copy)
@@ -48,8 +48,6 @@
# import Lua::Grammar::* into Lua::TestLex
$P0 = get_hll_global ['Lua::Grammar'], 'string'
set_hll_global ['Lua::TestLex'], 'String', $P0
-$P0 = get_hll_global ['Lua::Grammar'], 'ws'
-set_hll_global ['Lua::TestLex'], 'ws', $P0
$P0 = get_hll_global ['Lua::Grammar'], 'syntaxerror'
set_hll_global ['Lua::TestLex'], 'die', $P0
Re: [perl #48677] [BUG] r23917 led to 'make' failure
On Mon, Dec 17, 2007 at 05:33:51PM -0500, Jeff Horwitz wrote: On Mon, 17 Dec 2007, chromatic wrote: Okay, so memcpy doesn't fix it. That's good to know. How about explicitly putting the destination PMC in a named variable so there's less pointer shuffling and macro madness? memmove fixes it. i submitted a patch, but for some reason it hasn't made it to RT or the list... Do the structures actually overlap, or is this necessary band aid for a subtly broken compiler? Nicholas Clark
Re: [perl #48677] [BUG] r23917 led to 'make' failure
Nicholas Clark wrote: Do the structures actually overlap, or is this necessary band aid for a subtly broken compiler? I think the compiler is to blame. It only happens when compiling the code in the computed goto core. I *suspect* the compiler backs out of a lot of analysis and transforms that it would normally do due to the complexity of analysing code using computed goto, since the problem code compiled just fine outside of the computed goto core without the patch. Jonathan
Test failures on Solaris 9
Hi everyone, these failures probably aren't critical for release, however I thought it best to mention them. Paul System: Solaris 9 cc: Sun C 5.8 2005/10/13 Parrot revision: 24033 t/library/pcre... # Failed test (t/library/pcre.t at line 35) # Exited with error code: 1 # Received: # ok 1 # ok 2 # Null PMC access in invoke() # current instr.: 'parrot;PCRE;compile' pc 118 (/home/cochrane/parrot/runtime/parrot/library/pcre.pir:127) # called from Sub 'main' pc 50 (/home/cochrane/parrot/t/library/pcre_1.pir:37) # # Expected: # ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # t/library/pcre...NOK 1/1# Looks like you failed 1 test of 1. t/stm/basic_mt...ok 2/4 # Failed test (t/stm/basic_mt.t at line 168) # Exited with error code: 134 # Received: # src/stm/backend.c:794: failed assertion 'successp' # Abort # # Expected: # /okay/ # t/stm/basic_mt...NOK 3/4# Looks like you failed 1 test of 4. t/examples/library...ok 2/4Null PMC access in invoke() current instr.: 'parrot;PCRE;compile' pc 118 (library/pcre.pir:127) called from Sub 'parrot;PCRE;main' pc 271 (examples/library/pcre.pir:56) # Failed test (t/examples/library.t at line 67) # got: 'asdf =~ /as/ # ' # expected: 'asdf =~ /as/ # 1 match(es): # as # ' t/examples/library...NOK 3/4# Looks like you failed 1 test of 4.
Test failures on Win32
Hi, I've been doing some testing on Win32 as well, here are my current results: (I'm also still getting the failure I posted earlier with t/examples/tutorial.t, so I've left it out) Paul System: WindowsXP cc: Visual Studio 2005 perl: ActiveState Parrot revision: 24034 t/pmc/scheduler..NOK 1# Failed test (t/pmc/sched uler.t at line 25) # Exited with error code: 255 # Received: # # Expected: # created # 1 # t/pmc/scheduler..NOK 2# Failed test (t/pmc/sched uler.t at line 54) # Exited with error code: 255 # Received: # # Expected: # created # 1 # Caught exception on bad initializer # # Looks like you failed 2 tests of 3. t/pmc/scheduler..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-2 Failed 2/3 tests, 33.33% okay
Re: [perl #48631] [RFE] oo - allow :method to also enter sub in namespace
Patrick R.Michaud (via RT) wrote: This ticket is asking for some convenient mechanism to have a :method be automatically entered as a sub in the namespace. This used to be the situation prior to the pdd15oo merge, and I've come across some instances in perl6 and PGE where this is really needed. We can either provide a flag to :method that means also add the method to the namespace, or we could let :method automatically be placed in the namespace unless another flag (e.g., :anon) is present. I'm trying to decide if the right thing to do is store the method's PMC in both locations, or change the dispatch for the call to look in both locations. So, a little more background: Is the HLL feature you're supporting here the indirect object syntax, where you can make a method call that looks like a subroutine call, with the object (invocant) as the first argument? Is this a general feature that applies to all Perl 6 methods? In many ways, it's more like a multi-sub with a single invocant than it is like a traditional method. A few HLL use examples could help. Allison
Re: [perl #48631] [RFE] oo - allow :method to also enter sub in namespace
On Tue, Dec 18, 2007 at 03:52:39PM +0200, Allison Randal wrote:
Patrick R.Michaud (via RT) wrote:
This ticket is asking for some convenient mechanism to have
a :method be automatically entered as a sub in the namespace.
This used to be the situation prior to the pdd15oo merge,
and I've come across some instances in perl6 and PGE where this
is really needed.
We can either provide a flag to :method that means also add
the method to the namespace, or we could let :method automatically
be placed in the namespace unless another flag (e.g., :anon) is
present.
I'm trying to decide if the right thing to do is store the method's PMC
in both locations, or change the dispatch for the call to look in both
locations.
Of course, in the previous object model I think there was only
one place to look, and find_method did the searching. My initial
reaction is that the right thing to do is to store the method's
PMC in both locations. That way it's still possible to distinguish
a method from a normal sub or other symbol table entry. If
the dispatch always looks in both locations, it might be more
difficult to create a symbol in the namespace that isn't also
treatable as a method.
So, a little more background: Is the HLL feature you're
supporting here the indirect object syntax, where you can make a
method call that looks like a subroutine call, with the object
(invocant) as the first argument?
No, that's not directly the HLL feature I'm after, although that
will also be easier as a result of this. The specific case I've
run into involves regexes and subrule handling in PGE and perl6.
In order for inheritance to work in grammars, it's vital that
regex lookup and invocation be able to work like methods -- i.e.,
invoking abc within a pattern should be able to find the 'abc'
regex in a parent grammar.
However, there are also times that regexes act like subs -- for
instance, consider the following:
module Foo {
rule abc { ... }
rule def { ... abc ... }
...
}
Here 'abc' can't really be a method, because there's not a class
to which it can be added. So, we need to make sure that 'abc'
gets an entry in the 'Foo' namespace somehow. Things become a lot
simpler overall if PGE can simply generate subs that are methods
and automatically appear in the namespace.
The specific case that prompted the ticket is dealing with
anonymous regexes, as in:
$a ~~ / foo \d+ /;
This again generates a regex that isn't a method in a class, and
the only way to look it up is by its internally generated name.
Prior to pdd15oo, PGE could always generate a regex as a simple sub
without a :method flag and receiving any invocant as an explicit
first argument. The regex sub could then be located either via
find_method (to follow inheritance) or by namespace lookup (act as
a simple sub).
After pdd15oo, in order to preserve inheritance PGE switched to
placing :method flags on the subs it generated, and converting
many subcalls to method invocations. But placing :method on
the generated subs also had the effect of removing them from
the namespace, which led to the problems for the non-method
regexes I described above.
It's entirely possible that PGE should have a flag on it that says
generate a regex method versus generate a regex sub, and we
may end up with that anyway. But I can also envision situations
where we'll want to be able to locate methods via namespace entries,
it's much easier to have a compile-time flag to tell imcc to put
a method into a namespace than it is to generate :load :init
instructions to make the mapping. (Or to use PGE's present workaround,
which is to generate a separate :method wrapper around a sub.)
Hope this helps,
Pm
[perl #48118] [PATCH] Replace additional instances of '$/'
I *thought* I had applied this ticket to trunk, but it turns out I had not. Re-running tests now.
[perl #48118] [PATCH] Replace additional instances of '$/'
Applied to trunk in r24041.
Re: [perl #48677] [BUG] r23917 led to 'make' failure
Nicholas Clark wrote: Do the structures actually overlap, or is this necessary band aid for a subtly broken compiler? Jonathan Worthington replied: I think the compiler is to blame. Are we hurling abuse at^H^H^H^H^H^H^H^H informing the GNU folks about the apparent problem? :-)* BTW, I understand it's Perl's 20th. birthday today. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Parrot 0.5.1 Hatachi Released!
-- Lebennin Silver flow the streams from Colos to Erui In the green fields of Lebennin! Tall grows the grass there. In the wind from the Sea The white lilies sway, And the golden bells are shaken of mallos and alfirin In the green fields of Lebennin, In the wind from the Sea! -- On behalf of the Parrot team, I'm proud to announce Parrot 0.5.1 Hatachi. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.5.1 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.5.1 News: - Documentation + PDD19 (PIR) - reflect state on the ground; incorporate old IMCC docs + PDD25 (Concurrency) - launch out of draft + Improve documentation of deprecated parrot features. - Compilers + PCT: Parrot Compiler Toolkit redesigned and updated + NQP: major updates, including support for namespaces, module/class declarations, methods + IMCC: remove .sym as alias for .local. Remove .pcc_ prefix for calling directives (.pcc_begin became .begin_call). + PIRC: creates an AST during the parse. + PGE: more updates to match S05 syntax. - Languages + perl6: re-implemented using PCT and NQP, new object subsystem + abc: re-implemented using PCT and NQP + eclectus: initial implementation + plumhead: add PCT variant + punie: re-implemented using PCT and NQP, extended to handle subroutines Happy 20th Birthday, Perl! + pynie: re-implemented using PCT and NQP + PIR: start conversion to NQP (under construction) - Implementation + new opcodes: 'die', 'addhandler', 'copy' + Initial implementation of Concurrency PDD + Add 'arity' method to Sub and NCI PMCs - Miscellaneous + Bug cleanup + consting, attribute marking, warnings cleanup, memory leaks, GC... + dead code removal (includes some defunct languages) Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! Jonathan
about .namespace ident + .endnamespace : simple scoping.
hi, the .namespace ident + .endnamespace directives are deprecated. this is because initially they were meant to implement scoping, but this didn't work out. We have .lex now to do that. However, simple languages that don't have closures still could use it. In fact, Jako uses it. It's a lightweight (=cheaper than .lex I think?) scope mechanism, which prevents that language implementers must implement it themselves. I'm not an advocate of these directives, in the sense that I'd like to remove or keep them. I don't use them. However, parrot's customers are language implementers (amongst others). Providing infrastructure to do what they want is a bonus for them. So, is the .namespace ident + .endnamespace pair really superfluous, and should they be removed, or might there be some advantage in keeping them? If not, then I'll remove them somewhere in the next few weeks. comments welcome, kjs
[perl #48294] [RFE] oo -- improve Method '...' not found' error
resolved in r24051. ~jerry
Re: about .namespace ident + .endnamespace : simple scoping.
On Dec 18, 2007 2:36 PM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: SNIP Please post this as a reply to RT # 48737 so the ticket related discussion is actually tied to the ticket (and cc the list) Thanks! -- Will Coke Coleda
[svn:parrot-pdd] r24056 - in trunk: . config/gen/makefiles docs docs/pdds/draft docs/stm lib/Parrot lib/Parrot/Pmc2c src src/pmc t/tools/pmc2cutils tools/build tools/dev
Author: coke Date: Tue Dec 18 19:27:11 2007 New Revision: 24056 Modified: trunk/docs/pdds/draft/pdd08_keys.pod Changes in other areas also in this revision: Added: trunk/src/vtable.tbl - copied unchanged from r24055, /trunk/vtable.tbl Removed: trunk/vtable.tbl Modified: trunk/MANIFEST trunk/config/gen/makefiles/root.in trunk/docs/stm/internals.pod trunk/docs/vtables.pod trunk/lib/Parrot/Manifest.pm trunk/lib/Parrot/Pmc2c/Pmc2cMain.pm trunk/lib/Parrot/Vtable.pm trunk/src/pmc/default.pmc trunk/t/tools/pmc2cutils/03-dump_vtable.t trunk/t/tools/pmc2cutils/04-dump_pmc.t trunk/t/tools/pmc2cutils/05-gen_c.t trunk/t/tools/pmc2cutils/06-print_tree.t trunk/tools/build/pmc2c.pl trunk/tools/build/vtable_extend.pl trunk/tools/build/vtable_h.pl trunk/tools/dev/gen_class.pl Log: [CAGE] Resolve ticket #48495 ([CAGE] vtable.tbl is source...) Move vtable.tbl to src/vtable.tbl - update all references to point to the new location. Modified: trunk/docs/pdds/draft/pdd08_keys.pod == --- trunk/docs/pdds/draft/pdd08_keys.pod(original) +++ trunk/docs/pdds/draft/pdd08_keys.podTue Dec 18 19:27:11 2007 @@ -109,7 +109,7 @@ =head2 C_keyed vtable methods So what of these magical C_keyed vtable methods? They are generated when you -add the Ckeyed tag to the appropriate entry in Fvtable.tbl. They are +add the Ckeyed tag to the appropriate entry in Fsrc/vtable.tbl. They are constructed by following Bevery CPMC argument with a second CPMC argument which acts as the key for that argument; the name of the second CPMC argument is formed by adding C_key onto the end of the first CPMC argument.
