[perl #39135] Problem with concat on Match objects

[Patrick R . Michaud]

# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #39135]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39135 >

I've run into the following problem using concat with
Match objects from PGE. The code below performs a match,
then attempts to concatenate a string with the results
of the returned Match object:

$ cat y.pir
.sub main :main
load_bytecode 'PGE.pbc'

$P0 = compreg 'PGE::P6Regex'
$P1 = $P0('.+')
$P2 = $P1('world')

say $P2 # world

$P3 = new .String
$P3 = 'hello '

$P4 = new .String
$P4 = concat $P3, $P2
say $P4 # hello world
.end

$ ./parrot y.pir
world
Null PMC access in clone()
current instr.: 'main' pc 42 (y.pir:14)
$

The returned match object (in $P2) works fine if cast to a
string (see the "say $P2" line above), but for some reason
the concat operation results in a "NULL PMC access" error.

I'm also entering a todo test for the above into t/compilers/pge/02-match.t.

Thanks,

Pm

[Leopold Toetsch]

Patrick R.Michaud (via RT) wrote:

> I've run into the following problem using concat with
> Match objects from PGE. The code below performs a match,
> then attempts to concatenate a string with the results
> of the returned Match object:

There are several problems with the internals of objects derived from
PMCs. The code tries to create a new destinaation according to the src
operands (this is where the failing clone is called). If I turn that
part off, it still wouldn't work, as it calls get_string on the
contained Hash and not on the PGE::Match directly.

A workaround is to implement .sub __concatenate :multi(String,
PGE::Match) and use the n_concat opcode (which creates a new destination
result).

> I'm also entering a todo test for the above into t/compilers/pge/02-match.t.

I've adjusted this test, to use this workaround.

> Thanks,
>
> Pm

leo

[Patrick R. Michaud]

On Mon, May 15, 2006 at 03:29:23AM -0700, Leopold Toetsch via RT wrote:
> Patrick R.Michaud (via RT) wrote:
>
> > I've run into the following problem using concat with
> > Match objects from PGE. The code below performs a match,
> > then attempts to concatenate a string with the results
> > of the returned Match object:
>
> There are several problems with the internals of objects derived from
> PMCs. The code tries to create a new destinaation according to the src
> operands (this is where the failing clone is called).

Why does it try to create a new destination? I would expect this
for n_concat, but not necessarily for concat.

> If I turn that
> part off, it still wouldn't work, as it calls get_string on the
> contained Hash and not on the PGE::Match directly.

This sounds wrong. Lots of subclasses are going to want to be able
to override get_string and have Parrot do the right thing. Do similar
problems exist for get_integer and get_number?

> A workaround is to implement .sub __concatenate :multi(String,
> PGE::Match) and use the n_concat opcode (which creates a new destination
> result).

Presumably this means we also need a .sub __concatenate :multi(PGE::Match,
String) to handle the other order of arguments, yes?

> > I'm also entering a todo test for the above into t/compilers/pge/02-match.t.
>
> I've adjusted this test, to use this workaround.

I think the original test points out a bug that still
needs fixing, but that's your call.

Thanks,

Pm

[Leopold Toetsch]

Am Samstag, 13. Mai 2006 05:36 schrieb Patrick R.Michaud (via RT):
> I've run into the following problem using concat with
> Match objects from PGE.  The code below performs a match,
> then attempts to concatenate a string with the results
> of the returned Match object:

This is now fixed, I've removed the initial test workaround.
leo