Two division signs in an EXPRESSION lead to issues

Danmo is correct. Argh...

Without reading the flex documentation there are a couple of possible solutions although none are particularly appealing. One would be to lose the // delimiter for regex in the expression context. We already have the =~ operator so we could simply use that to know when to interpret a string as an expression. The other idea would be to track the most recent operator so that // mean regex only if proceeded by a =~. That adds complexity to the tokenizing. You'd have to make sure to initialize the last operator variable correctly etc... which could get messy. The problem with the first idea is that it would break backwards compatability but would simplify the code.

Thoughts?

Steve

I'd have a preference for keeping the // syntax if we can, not only for backwards compatibility, but also for expression readability.

i.e. this

   EXPRESSION ([name] =~ /regex_here/)

is much more intuitive than this

   EXPRESSION ([name] =~ 'regex_here')

Is the parser sequential or does it have the concept of priority of tokens? Could we make it so that if the division are enclosed inside brackets like this

   EXPRESSION (3>(2/1) and (2/2)<6)

then the divisions are parsed as single entities before the // are processed as a regex?

Actually I think I can set a lexer state so that // means regex only after first seeing =~. Otherwise /'s would be seeing as division operators. Trying that now...

Steve

Fixed in both the 5.0 branch (r7421) and the dev branch (r7420). Closing...

Steve

Thanks Steve!

I should note that I tested Paul's test expressions and a bunch of others using the "testexpr" program. I didn't actually try it in a drawing context. Paul, might be nice to quick run your test case and confirm the fix.

Steve

Steve,

You should also update the lexer output in the trunk and the stable branch to avoid the current build issues. See the buildbot for more details.

Tamas

I plan to, just not from my Mac.

Steve

FYI I have committed new maplexer.c generated with Flex 2.5.31 on Linux in branch 5-0 (r7422) and trunk (r7423).

Thanks Dan!