I suspect it may be some weirdness with the way that $_ is being handled in
smartmatching, then.
I think there's a slight difference between
$tmpl ~~ /regex/
and
$tmpl ~~ m/regex/
The first one does the equivalent of /regex/.ACCEPTS($tmpl), which ends up
matching $tmpl directly against the regex and returning the resulting Match
object.
The second one temporarily assigns $tmpl into $_, then m/regex/ does an
immediate match against underscore to produce a Match object, which then has
.ACCEPTS($tmpl) called on it (which returns the Match object).
I don't know exactly what is happening when !~~ is used with m/.../ -- i.e.,
when $_ is being assigned, what is happening to the Match object, and where
negation is taking place. It would be interesting to know if the following
fails for you also:
if not $tmpl ~~ m/\.txt$/ { ... }
Pm
On Tue, Dec 30, 2014 at 09:29:39AM +0200, Gabor Szabo wrote:
> No. If I remove the leading m from the regex, then the bug is gone.
> Gabor
>
> On Tue, Dec 30, 2014 at 9:19 AM, Patrick R. Michaud <pmich...@pobox.com>
> wrote:
>
> > Out of curiosity, is the bug still present if you use /\.txt$/ instead of
> > m/\.txt$/ ?
> >
> > At the moment it looks like a Rakudo bug to me, but I haven't been able to
> > golf it further to be certain.
> >
> > Pm
> >
> > On Tue, Dec 30, 2014 at 09:11:52AM +0200, Gabor Szabo wrote:
> > > Just to follow-up:
> > > The problem appears in
> > >
> > https://github.com/szabgab/Perl6-Maven/commit/4346c96d63e97def55e789bbeebdbdaebe8b0b33
> > >
> > > After that I have replaced the regex match with
> > >
> > > if substr($tmpl, *-4) ne '.txt' {
> > >
> > > that works correctly, but I'd still like to understand if the bug was in
> > my
> > > code, or if this is some Rakudo issue?
> > >
> > > Gabor
> > >
> > >
> >
