[perl #38888] PGE::P5Regexp failures.
Will Coleda
# Please include the string: [perl #38888]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38888 >
Tcl test suite has some failures. At least some of these are due to
the following issue in PGE::P5Regexp :
$ cat foo.tcl
array set a [list a b]
puts [array get a]
$ ../../parrot tcl.pbc foo.tcl Global 'parse_ws_lit' not found
Global 'parse_lit' not found
current instr.: 'PGE::P5Regexp :: __onload' pc 9807 (compilers/pge/
PGE/P5Regexp.pir:14)
called from Sub '_main' pc 487 (src/tclsh.pir:210)
Patrick R. Michaud
> Tcl test suite has some failures. At least some of these are due to
> the following issue in PGE::P5Regexp :
>
> $ cat foo.tcl
> array set a [list a b]
> puts [array get a]
> $ ../../parrot tcl.pbc foo.tcl Global 'parse_ws_lit' not found
> Global 'parse_lit' not found
> current instr.: 'PGE::P5Regexp :: __onload' pc 9807 (compilers/pge/
> PGE/P5Regexp.pir:14)
> called from Sub '_main' pc 487 (src/tclsh.pir:210)
I suspect this must be coming from something deeper in Parrot
(or pbc_merge), and not anything in PGE. (I know that I recently
ran into problems with symbol table errors using pbc_merge when
doing some of the perl 6 compiler stuff, so at the moment I'm
avoiding it.)
To wit, the error(s) are occurring in the "__onload" subroutines
of PIR (automatically called via load_bytecode), and line 14 of
P5Regexp.pir reads
$P0 = find_global "PGE::P5Regexp", "parse_lit"
This looks like a pretty straightforward op to me, especially since
the "parse_lit" function it's looking for is also defined in
the same P5Regexp.pir file (starting at line 52). So, it's
hard to believe that the global would be "not found".
The "Global 'parse_ws_lit' not found" message appears to be
the same thing, except that an exception handler in tclsh.pir
seems to be catching the exception, sending the message to
standard output, and allowing the program to attempt to continue.
At any rate, I suspect pbc_merge is the culprit.
Pm
Jonathan Worthington
issue, I'll probably have a little time in the next few days to investigate.
I've not really had enough time to follow Parrot changes of late to know if
there's anything that happened that was likely to need changes from
pbc_merge; it could just be a bug in there from the beginning, of course.
Thanks,
Jonathan
Patrick R. Michaud
Oops. My apologies -- after looking and thinking about it more,
I now think that pbc_merge might not be the culprit -- or at least
not in the way I thought it might be. I was misreading how tcl
is using pbc_merge.
Going back to Will's original test program that evokes the
error...
$ cat foo.tcl
array set a [list a b]
puts [array get a]
$ ../../parrot tcl.pbc foo.tcl Global 'parse_ws_lit' not found
Global 'parse_lit' not found
current instr.: 'PGE::P5Regexp :: __onload' pc 9807 (compilers/pge/
PGE/P5Regexp.pir:14)
called from Sub '_main' pc 487 (src/tclsh.pir:210)
I'm now thinking that the problem has to be either in load_bytecode
or in the .pbc file itself (PGE.pbc). First, there are two exceptions
occurring -- the first is in PGE::P6Rule and the second is in PGE::P5Regexp.
Both occur as part of those modules' "__onload" subroutines (i.e.,
when the .pbc is loaded).
For the first exception we don't see anything more than
"Global 'parse_ws_lit' not found" because TCL is catching and
handling the exception. The second exception isn't getting caught,
so that's what makes the whole thing look like a PGE::P5Regexp error.
The lines generating the exceptions are:
PGE::P6Rule (line 16):
$P0 = find_global "PGE::P6Rule", "parse_ws_lit"
PGE::P5Regexp (line 14):
$P0 = find_global "PGE::P5Regexp", "parse_lit"
However, since "parse_ws_lit" and "parse_lit" are each defined in the
same file (and namespace) as the "__onload" subs that call them,
it seems unlikely that it's strictly a PGE problem. Put another way,
since these functions are always called when PGE.pbc is loaded
(regardless of which PGE compilers are actually called),
I'd expect to see the problem in more places besides TCL.
Lastly, to really indicate that the problem seems to be in
".pbc" handling somewhere -- try changing line 91 of
languages/tcl/src/templates/tcllib.template from
load_bytecode "Getopt/Obj.pir"
to
load_bytecode "Getopt/Obj.pbc"
As I understand it, this really shouldn't make a fundamental difference.
However, after making this 1-line change and rebuilding TCL, the error
message from foo.tcl becomes:
$ cat foo.tcl
array set a [list a b]
puts [array get a]
$ ../../parrot tcl.pbc foo.tcl
Can't find method '__push_string' for object 'Getopt::Obj'
current instr.: '_main' pc 170 (src/tclsh.pir:123)
$
and the problem has migrated into Getopt::Obj, so I really
suspect a .pbc problem somewhere.
Troubleshooting .pbc is a bit beyond my current Parrot abilities,
so hopefully someone else can look at it and figure out what
is going on.
Pm
Leopold Toetsch
> I'm now thinking that the problem has to be either in load_bytecode
> or in the .pbc file itself (PGE.pbc).
[ ... ]
> Lastly, to really indicate that the problem seems to be in
> ".pbc" handling somewhere -- try changing line 91 of
> languages/tcl/src/templates/tcllib.template from
> load_bytecode "Getopt/Obj.pir"
> to
> load_bytecode "Getopt/Obj.pbc"
[ ... ]
Based on your detailed analysis I was able to create a simple testcase.
load_bytecode with a .pbc didn't set the HLL namespace properly, so that
subs were stored in the wrong namespace.
This is fixed now in r12181.
> Pm
Thanks,
leo