sbettini

in case someone would be still interested, after playing a day with debugger I think that this serious bug now is solved. In order to have a correct evaluation tokAnd and tokOr need to start/end new sub-expressions, so in DialectInterp.cpp you have to remove management from FirstRelational() and SecondRelational() putting this in _Expression(): case tokAnd: ++m_Token; if (! result->Boolean()) return true; // shortcircuit and if (!_Expression(&temp)) return false; *result = *result && temp; return...

in case someone would be still interested, after playing a day with debugger I think that this serious bug now is solved. In order to have a correct evaluation tokAnd and tokOr need to start/end new sub-expressions, so in DialectInterp.cpp you have to remove management from FirstRelational() and SecondRelational() putting this in _Expression(): case tokAnd: ++m_Token; if (! result->Boolean()){ // shortcircuit and *result = false; return true; } if (!_Expression(&temp)) return false; *result = *result...

in case someone would be still interested, after playing a day with debugger I think that this serious bug now is solved. In order to have a correct evaluation tokAnd and tokOr need to start/end new sub-expressions, so in DialectInterp.cpp you have to remove management from FirstRelational() and SecondRelational() putting this in _Expression(): case tokAnd: ++m_Token; if (!_Expression(&temp)) return false; *result = *result && temp; return true; case tokOr: ++m_Token; if (!_Expression(&temp)) return...

I can perfectly understand George, thanks. What a shame be not completely self-sufficient to keep going this wonderful product. I learned C++ playing with your very brilliant source, and was (and still is!) a challenge and a joy. Many thanks again for your work Stefano

Probably posting on TICKET section was not a good idea.... if 1 = 2 and 2 = 3 print true else print false endif --->true (BUG) if (1 = 2) and (2 = 3) print true else print false endif --->false (CORRECT) Unfortunately seem to be a major problem at parser level (_Expression() and descendant tree functions) not so simple to manage, at least for me. The parens workaround is a little annoing and break the elegance of the syntax, could someone check with some old version (pre 1.16) if the problem was...

BUG in parsing boolean expressions (if, while....)

I'm still working on this beautiful software, implementing some of less developed area. Now I would like to work on threading, and I wonder what was the original idea behind the partial work on cvalue. Being the stack and the token pointer unique inside the interpreter a simple statement "do_async" that run the interpret in a new thread could not be enough, I think that the threaded code must have at least his own copy of the current stack... Maybe a complete copy of the current CDialectInterp instance?...

Select from local tables crash server process