For bug report 2467, I've posted a request for an example file or procedure to reproduce the problem.
according to this post, it seems like bug report 3926 has been resolved.
Moving on to the next one.
Looking at realthunder's work on the expression parser, it seemed to me that the Spreadsheet workbench is essentially just an interface to the expression parser, that is, a specific place to work with expressions. So, they are basically the same thing. Core changes: Expression and spreadsheet.ezzieyguywuf wrote: ↑Tue Dec 03, 2019 4:30 am...
In general, it appears that all these issues/bugs labeled as "Spreadsheet module" issues are really "Expression parser" issues. Perhaps I should change the scope of my assignment and start working on improvements to the expression parser?
Yes, I have come to the same conclusion after digging through these bugs and the code.
Yes, this is true. However, hopefully you can understand my confusion - until a few days ago, I had zero experience with the Spreadsheet workbench. I saw a "call to arms" to help improve some bugs specifically in this workbench, and I wanted to be sure that I kept my scope contained only to Spreadsheet, as there are undoubtedly numerous corners of the FreeCAD code base that could use small bug fixes/improvements/etc.
@realthunder, can you comment on vocx's message above?realthunder wrote:ping
This is not a bug in expression parser. It is by design.ezzieyguywuf wrote: ↑Tue Dec 03, 2019 3:10 am3696 also seems to be a duplicate of the "Expression can't contain space" error. I've revived an old thread
I didn't merge the python3 syntax part for security reason, but I did include lots of fixes and improvements. I haven't checked against bug list, though.ezzieyguywuf wrote: ↑Tue Dec 03, 2019 6:02 pm@realthunder, can you comment on vocx's message above?
I'm — obviously — a big fan of the ExpressionEngine, but I'm not sure I find this automagic thing very good: it's confusing and error prone, I had some trouble to debug an expression because of this. I think that the parser should parse, but not make decisions, and if there is a problem because the user has confounded Name and Label then it's better that the user fixes this rather than the parser doing some internal magic and the user finds himself with an expression he didn't actually enter. And which may or may-not work, so you can get seemingly random behaviour depending on what parts and documents where open at the time the expression was entered and parsed.realthunder wrote: ↑Wed Dec 04, 2019 2:02 amIn addition, when there is no quote, the expression parser will also check for label if it can't find the object by internal name. If it finds one, spreadsheet/expression engine will insert the quote automatically.
Partially agree, the feature can be very handy actually, maybe instead of automatically adding << >> it could be shown as a suggestion just like autocompletion?Zolko wrote: ↑Wed Dec 04, 2019 8:46 amI'm — obviously — a big fan of the ExpressionEngine, but I'm not sure I find this automagic thing very good: it's confusing and error prone, I had some trouble to debug an expression because of this. I think that the parser should parse, but not make decisions, and if there is a problem because the user has confounded Name and Label then it's better that the user fixes this rather than the parser doing some internal magic and the user finds himself with an expression he didn't actually enter. And which may or may-not work, so you can get seemingly random behaviour depending on what parts and documents where open at the time the expression was entered and parsed.realthunder wrote: ↑Wed Dec 04, 2019 2:02 amIn addition, when there is no quote, the expression parser will also check for label if it can't find the object by internal name. If it finds one, spreadsheet/expression engine will insert the quote automatically.
I'd vote to remove this automatic replacement of Label and Name, especially if it doesn't work in all situations (space in <<Label>>). The ExpressionEngine is anyway a power-user feature, and a power user can a should know the difference between Name and <<Label>>.
The auto insertion of quote is my addition. The auto search for label and internal name is the old parser behavior (actually the implementation is inside App::ObjectIdentifier), and there are a few other 'auto' feature in the old parser that cause more nasty ambiguities. I did my best to remove those ambiguities without breaking backward compatibility. I don't think auto inserting quote will cause problems you mentioned. But if you do find some, please post with example, I'll see how to fix it.Zolko wrote: ↑Wed Dec 04, 2019 8:46 amI'm — obviously — a big fan of the ExpressionEngine, but I'm not sure I find this automagic thing very good: it's confusing and error prone, I had some trouble to debug an expression because of this. I think that the parser should parse, but not make decisions, and if there is a problem because the user has confounded Name and Label then it's better that the user fixes this rather than the parser doing some internal magic and the user finds himself with an expression he didn't actually enter. And which may or may-not work, so you can get seemingly random behaviour depending on what parts and documents where open at the time the expression was entered and parsed.
I'd vote to remove this automatic replacement of Label and Name, especially if it doesn't work in all situations (space in <<Label>>). The ExpressionEngine is anyway a power-user feature, and a power user can a should know the difference between Name and <<Label>>.
Sorry for my delays in response. I tried to respond a few times on mobile and phpbb is not so mobile friendly (and I lost my replies). In summary, thank you for digging in to this topic. Your efforts so far have pushed the needle quite far...we know that several tickets are all related to a design feature (not a bugezzieyguywuf wrote:
No worries. I heard something about a freecad motto somewhere...
It's not, but I've had relative success using it.
Dang!