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+
+| '--'
+| '--' \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 #48657] [Bug][Lua] Recent changes broke languages/lua
Patrick R. Michaud wrote: 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. Thumbs up on flexibility and ease-of-use. This is perfect. 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. I suspect these will rarely be used. That little extra bit of complexity is enough to make compiler writers avoid it unless they really need extensive customization. Nice to have it when it's needed, though. 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. Agreed. We're not at a stage of development where we need to provide extensive backward compatibility with old interfaces. addstage, etc. cover the needed feature, so ditch the old interface. 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". That has definite potential. Allison
Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua
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". Pm
Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua
On Saturday 15 December 2007 05:31:00 Bernhard Schmalhofer wrote:
> recent changes have broken Lua.
> From the shared object file for the dynamic ops I got
>undefined symbol: CONST_STRING
> This might be fixable by including an appropriate header file.
> Reverting r23916 in lib/Parrot/Pmc2c/PMCEmitter.pm also works.
>
>
> @@ -635,7 +635,7 @@
> foreach my $dynpmc (@$dyn_mmds) {
> next if $dynpmc eq $classname;
> $cout .= <<"EOC";
> -int my_enum_class_$dynpmc = pmc_type(interp,
> CONST_STRING(interp, "$dynpmc"));
> +int my_enum_class_$dynpmc = pmc_type(interp,
> string_from_literal(interp, "$dynpmc"));
> EOC
> }
Oops. That was me. Go ahead and revert that. After the next release we can
consider something better.
-- c
[perl #48657] [Bug][Lua] Recent changes broke languages/lua
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #48657]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48657 >
Hi,
recent changes have broken Lua.
From the shared object file for the dynamic ops I got
undefined symbol: CONST_STRING
This might be fixable by including an appropriate header file.
Reverting r23916 in lib/Parrot/Pmc2c/PMCEmitter.pm also works.
@@ -635,7 +635,7 @@
foreach my $dynpmc (@$dyn_mmds) {
next if $dynpmc eq $classname;
$cout .= <<"EOC";
-int my_enum_class_$dynpmc = pmc_type(interp,
CONST_STRING(interp, "$dynpmc"));
+int my_enum_class_$dynpmc = pmc_type(interp,
string_from_literal(interp, "$dynpmc"));
EOC
}
The other problem is that the method 'ostgrammar' has been removed from
PCT::HLLCompiler.
IMHO this should be fixed with porting languages/lua from using
'PAST-pm' to using the shiny new
PCT::PAST.
Regards,
Bernhard
Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua
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. Allison
[perl #48657] [Bug][Lua] Recent changes broke languages/lua
On Sat Dec 15 05:30:57 2007, bernhard wrote: > ... > > The other problem is that the method 'ostgrammar' has been removed > from PCT::HLLCompiler. > IMHO this should be fixed with porting languages/lua from using > 'PAST-pm' to using the shiny new > PCT::PAST. 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. Either that or Lua can subclass PCT::HLLCompiler to provide the ostgrammar transformation. Let me know if help is needed for this. Another approach would be to subclass PAST::Compiler to provide the additional Lua-specific transformations that don't exist in the current PAST compiler. This would be interesting and worthwhile in a number of respects, so we could verify that the PAST implementation is indeed extensible to support language-specific needs. Pm
Re: recent changes
在 Feb 9, 2007 5:17 AM 時，Larry Wall 寫到： Questions and feedback welcome, but please don't follow up to this message--start a new thread for a new topic. Bear in mind that this is completely untested code, still fairly buggy and incomplete. Not even pugs can parse it (yet). Note: After some typo fixes and minor workarounds, Pugs now parses it just fine -- the task now is how to run it, and run it _fast_, before we make it part of sanity. :-) Cheers, Audrey
Re: recent changes
I should also point out that I'm excruciatingly grateful for all the prior art in the various Perl 6 parsers that various random geniuses have been working on. In particular: pmichaud++ fglock++ putter++ audreyt++ Their parsers actually work, unlike mine. :) Larry
recent changes
If you folks are wondering what's driving the flurry of recent synopsis changes, it's the Perl 6 grammar written in Perl 6 that I've been working on for the last week, and thinking about for the last month. If you want to peek at the current snapshot, it's at: http://svn.pugscode.org/pugs/src/perl6/Perl-6.0.0-STD.pm Questions and feedback welcome, but please don't follow up to this message--start a new thread for a new topic. Bear in mind that this is completely untested code, still fairly buggy and incomplete. Not even pugs can parse it (yet). Nevertheless, I think it will help ground some of the discussion here to have a real grammar to look at, written in something close to our favorite language. :) If you use vim, the perl6.vim in pugs/util directory will do a semi-decent job of hilighting. Feel free to patch perl6.vim where it doesn't. If you want to work on some part of the grammar, that's fine, but either update frequently with svn or let me know which parts I should leave alone while you work on them. Larry
Re: Total perl6 test failure; are recent changes to IMCC involved?
Leopold Toetsch wrote: Joseph F. Ryan wrote: However, perl6 seems to be breaking. "Seems" meaning that 100% of the tests are failing. This is bad.error (test.warn) of: I did make a little change in imcc.l, but I have no difference in test results. $ make test $ perl6 --test -r both give: Failed TestStat Wstat Total Fail Failed List of Failed --- t/compiler/1.t1 256141 7.14% 14 t/compiler/b.t1 256 61 16.67% 4 2 subtests skipped. Does "make test" in languages/imcc succeed? Seems to. perl t/harness t/imcpasm/opt1.ok t/imcpasm/opt2.ok t/imcpasm/sub..ok t/syn/clashok t/syn/constok t/syn/labels...ok t/syn/namespaceok t/syn/scopeok All tests successful. Files=8, Tests=21, 2 wallclock secs ( 1.63 cusr + 0.81 csys = 2.44 CPU)
Re: Total perl6 test failure; are recent changes to IMCC involved?
Joseph F. Ryan wrote: After a complete cygwin reinstall, I've finally gotten parrot to install and pass 100% tests. Ok, great. However, perl6 seems to be breaking. "Seems" meaning that 100% of the tests are failing. This is bad.error (test.warn) of: last token = [] (error) line 27: parse error Didn't create output asm. I did make a little change in imcc.l, but I have no difference in test results. $ make test $ perl6 --test -r both give: Failed TestStat Wstat Total Fail Failed List of Failed --- t/compiler/1.t1 256141 7.14% 14 t/compiler/b.t1 256 61 16.67% 4 2 subtests skipped. Does "make test" in languages/imcc succeed? Joseph F. Ryan [EMAIL PROTECTED] leo
Total perl6 test failure; are recent changes to IMCC involved?
After a complete cygwin reinstall, I've finally gotten parrot to install and pass 100% tests. Ok, great. However, perl6 seems to be breaking. "Seems" meaning that 100% of the tests are failing. This is bad. I've mananged to trace the error to the imcc phase. The outputted imcc code seems correct (or at least consistant with previous, working versions), but generates an error (test.warn) of: last token = [] (error) line 27: parse error Didn't create output asm. It gets the same error for any set of perl6 generated imcc. In this case, line 27 is: .emit Did anything get changed with this syntax? Joseph F. Ryan [EMAIL PROTECTED]
