How to integrate changes in QuantityParser.y ?

[openBrain]

Hi all,

I'm trying some things in Base/QuantityParser.y to patch/improve some behaviors. However I don't know what is needed so that this changes are took into account when compiling.
More precisely it looks like the changes shall go to Base/QuantityParser.c. I found that this is not done automatically by some CMake rules or so.
Is this latter file generated by some shell commands ? Or shall it be updated manually ?

Thanks

EDIT : typo in filename

[wmayer]

Modifying yacc file is done so rarely so it makes not much sense to add it as a further build dependency. Instead the output file is part of the source repository.

To update the C file:

Code: Select all

bison QuantityParser.y --output=QuantityParser.c

[openBrain]

Modifying yacc file is done so rarely so it makes not much sense to add it as a further build dependency. Instead the output file is part of the source repository.
To update the C file:

Code: Select all

bison QuantityParser.y --output=QuantityParser.c

Many thanks. Could be good to add it in the header as is the 'flex' line in QuantityParser.l

OK, first try is catastrophic. Looks like my ability at this is terrible.
I'll continue searching, but will describe here my findings in case someone skilled read this.

issue #3925
I guess problem comes from this lines. Indeed if the format is 'NEG quantity quantity ', today it is interpreted as '(NEG quantity) + quantity', while it should be either 'NEG (quantity + quantity)' or '(NEG quantity) - quantity' -- I don't know which one is easier to implement --.

issue #4196
As it happens only if unit isn't deleted, I guess it comes from this line. I think that problem is that when calculating the formula, it actually considers that denominator is '0 unit', so it fails due to a division by zero error. Indeed same behavior happens if you enter eg '40' in a field then try to insert a '/' sign between the '4' and the '0' (which is correct in this case). IMO it could be corrected by considering than when a unit is the sole denominator of a formula, it actually weight 1.0*unit.

[wmayer]

I guess problem comes from this lines. Indeed if the format is 'NEG quantity quantity ', today it is interpreted as '(NEG quantity) + quantity', while it should be either 'NEG (quantity + quantity)' or '(NEG quantity) - quantity' -- I don't know which one is easier to implement --.

https://forum.freecadweb.org/viewtopic. ... 01#p372281

[openBrain]

https://forum.freecadweb.org/viewtopic. ... 01#p372281

I actually doubt problem is solved. AFAIK spreadsheet cells are interpreted as expressions but not as formulas (latter handled by QuantityParser).
There was indeed also a bug in expression parser that is solved by @realthunder's PR, but it was different. I think the bug in formulas will still be present after PR is merged. Am I mistaking ?

[wmayer]

Am I mistaking ?

No idea. realthunder claimed it.

[realthunder]

I think ExpressionParser was further developed based on QuantityParser. I just checked the code. QuanittyParser is still used to handle input as 'constant'. The formula, i.e. when you click the 'fx' button in the property editor, is handled by ExpressionParser, same as the one used in Spreadsheet. I'll see if I can make the same change to QuantityParser.

[realthunder]

New commit added to my PR. See the commit message for more details.

QuantityParser is much simpler comparing to ExpressionParser, and has different syntax regarding quantity parsing.

1 / 2 m means (1/2)m in QuantityParser, but 1 / (2m) in ExpressionParser. I think that kind of differences is unavoidable.

BTW, (1/2)m is illegal in ExpressionParser right now. I can make it legal. Anyone think it is useful? For me, typing bracket seems more troublesome than simply 1/2*1m.

[openBrain]

New commit added to my PR. See the commit message for more details.

QuantityParser is much simpler comparing to ExpressionParser, and has different syntax regarding quantity parsing.

1 / 2 m means (1/2)m in QuantityParser, but 1 / (2m) in ExpressionParser. I think that kind of differences is unavoidable.

BTW, (1/2)m is illegal in ExpressionParser right now. I can make it legal. Anyone think it is useful? For me, typing bracket seems more troublesome than simply 1/2*1m.

Actually the true problem now is that when you select a QuantitySpinBox, only the value is selected and not the unit. So if you try to enter a fraction (say 1/4) it will refuse the '/' character. Strangely if you enter '0+1/4' it is accepted. About fractions parsing, I think it's due to imperial system making an high usage of it. So I think it's OK if in QuantityParser 1/2m is (1/2)m while in ExpressionParser 1/2m is 1/(2m). This is some inconsistency but ExpressionParser can be seen as a more "mathematical" tool.

[adrianinsaval]

Consistency in how this things are interpreted would be apreciated, it can be confusing if you have to write things differently in the same program.