On Mon, 21 Jan 2002, Brent Dax wrote:
>
> If the problem is backtracking, can't you just use the (?>)
> no-backtracking syntax?
>
Didn't think of that. I'm a bit concerned at the large warning
signs attached to it in perlre.pod, though.
Simon
Simon Glover:
# Right: the real cause of the second bug is similar to what I
# thought it
# was - when it sees a float, the regex engine first checks to
# see if it
# is an integer by trying the substitution:
#
# s/^(-?\d+)(?!\.)//
#
# The problem is that when, say, 1.0 gets fed to thi
Right: the real cause of the second bug is similar to what I thought it
was - when it sees a float, the regex engine first checks to see if it
is an integer by trying the substitution:
s/^(-?\d+)(?!\.)//
The problem is that when, say, 1.0 gets fed to this, and fails
to match, th
On Mon, 21 Jan 2002, Simon Glover wrote:
> The other bug is a misplaced ? in the regex checking for integers.
> This makes the match non-greedy, so 1.0 (for example) gets
> split up into 1000 (which matches the regex) and 0.0 (which matches
> as a float the next time around the loop). T
Enclosed patch fixes a couple of bugs in the optimizer. The first was
that the parser wasn't correctly recognising register names - it needs
to check for these _before_ checking for labels, or else they're
incorrectly identified as labels. Strangely, this wasn't causing
any problems with t
Since PMCs are done, languages should start to come out again. Every good code
generator needs a backend, and here's a first stab at an optimizer for Parrot:
http://216.254.0.2/~jgoff/Files/optimizer.perl
It takes a file of Parrot code post-macro-expansion, although it's internally just a
modu
