This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
GopherAtl's profile picture

[unbug...?!] issue with string.gmatch?

Started by GopherAtl, 27 February 2013 - 11:37 PM
GopherAtl #1
Posted 28 February 2013 - 12:37 AM
:edit: tagged unbug, as bubba pointed out the new behavior in 1.5 is consistent with what other lua interpreters say, including the ones on codepad.org and lua.org, so apparently 1.5 doesn't introduce a bug it couldn't possibly have introduced, it fixes a bug that it couldn't possibly have fixed. Which is still strange, and gonna continue to bother me, but isn't something dan or cloudy need to worry about unless they're just obsessed with the mystery of it.

noticed today a program I was working on earlier this month was not working anymore, on digging through to figure out why I discovered there's been a change in the behavior of string.gmatch between 1.481 and 1.5 (present from early 1.5 pre-releases through the current beta)

can be demonstrated by entering this at a lua prompt:

for e in ("a/b"):gmatch("^([^/]+)/?") do print(e) end
This should, and prior to 1.5, did, output

a
b

in 1.5+, it outputs…nothing.

string.match seems unaffected, just string.gmatch.

Very odd, not clear why this would have started happening, but it has.
Bubba #2
Posted 28 February 2013 - 01:22 AM
You have a leading ^ in front of the match string which stops anything from being printed.

This works fine for me:

for e in ("a/b"):gmatch("([^/]+)/?") do print(e) end
GopherAtl #3
Posted 28 February 2013 - 01:34 AM
the leading ^ forces it to start from the beginning of the string, or for subsequent iterations, the point right after the previous match. Without it, it will skip over non-matching bits and carry on matching later.
Cloudy #4
Posted 28 February 2013 - 01:38 AM
There hasn't been a change in behavior at all. We have changed nothing which could affect this.
Bubba #5
Posted 28 February 2013 - 02:01 AM
the leading ^ forces it to start from the beginning of the string, or for subsequent iterations, the point right after the previous match. Without it, it will skip over non-matching bits and carry on matching later.

Ah yes just looked it up. Hadn't ever seen that before. -snip- You said it did work before? Curious. I just tried this in a regular Lua environment and it didn't work for me.
GopherAtl #6
Posted 28 February 2013 - 12:21 PM
cloudy: believe me, I understand what you're saying, but precisely because of the incomprehensibility of it, I triple-checked that I wasn't imagining it before I posted it here. That line works in 1.481, and does not work in 1.5. I No idea how or why.

bubba: … really? it ought to work. :tries on codepad: w..t..f… ok, apparently this wasn't supposed to work in the first place, but it did in 1.4… I just tested it yet again, and took screenshots this time for proof…

1.4…

1.5…



anyway, since it seems this does not work in normal lua, apparently it was a bug in 1.4 that got fixed somehow, rather than one introduced in 1.5.. >.< I blame luaj.
cant_delete_account #7
Posted 28 February 2013 - 01:09 PM
That picture isn't 1.5, it's 1.51..
(the wire and wired modem in the hotbar)
GopherAtl #8
Posted 28 February 2013 - 01:27 PM
I tested in 1.5pr4, 1.5, and 1.51pr3, same behavior in all of them.