Dedicated Spreadsheet Workbench Maintainer/Devs needed

[ezzieyguywuf]

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.

[ezzieyguywuf]

posted a note on bug report 3391 trying to get some more info on how to reproduce the issue.

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?

[vocx]

...
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?

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.

I mean, what sort of functionality is provided by the Spreadsheet workbench itself? It's only a collection of rows and columns. The inner behavior of the cells is the important stuff, which is the handling of expressions.

By the way, I'm surprised all those issues that you mention weren't identified by realthunder. Maybe you should ping him to clarify whether he has already looked into them. Realthunder may already have another branch that solves many of these problems. In particular, I think he already integrated a lot of changes to his own fork with Assembly3, so that expressions could use essentially Python 3 syntax. If I understand correctly, he didn't push many of these changes with LinkMerge because he considered these changes too radical and subject to security issues. See Expression and Spreadsheet (not in LinkMerge).

[ezzieyguywuf]

it seemed to me that the Spreadsheet workbench is essentially just an interface to the expression parser,

Yes, I have come to the same conclusion after digging through these bugs and the code.

I mean, what sort of functionality is provided by the Spreadsheet workbench itself? It's only a collection of rows and columns. The inner behavior of the cells is the important stuff, which is the handling of expressions.

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.

By the way, I'm surprised all those issues that you mention weren't identified by realthunder

ping

@realthunder, can you comment on vocx's message above?

[realthunder]

3696 also seems to be a duplicate of the "Expression can't contain space" error. I've revived an old thread

This is not a bug in expression parser. It is by design.

You probably already know this, but there are two types of 'names' with FreeCAD objects (DocumentObject and Document itself). There is this no space, ascii only, immutable internal names for every object, and there is also the user changeable, everything goes, 'label' for each. Label is what you see in the tree view, and you can find the internal name by checking the status bar (left bottom corner of the main window) when mouse over a tree item. Sometimes the label and internal name are the same, which maybe the source of some confusion.

In expression, you can refer to label using quote, something like <<object label>>.Length, or with document label, <<document label>>#<<object label>>.Length. You can also refer by internal name without the quote. In 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. But that only works for labels without space, obviously. And it is only provided for user convenience, not for coding.

I haven't look into the problem yet. But it is most likely a bug in sketch, where it didn't use quote when trying to refer by label.

@realthunder, can you comment on vocx's message above?

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.

[Zolko]

In 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'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>>.

[adrianinsaval]

In 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'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>>.

Partially agree, the feature can be very handy actually, maybe instead of automatically adding << >> it could be shown as a suggestion just like autocompletion?

[realthunder]

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.

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.

[Kunda1]

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 bug )
and we've categorized the other bugs as well. I haven't made time yet to test some of the bugs you've tackled and need testing. I hope to soon. Just want to let you know your effort is very appreciated and thanks for stepping-up

[ezzieyguywuf]

Sorry for my delays in response

No worries. I heard something about a freecad motto somewhere...

phpbb is not so mobile friendly

It's not, but I've had relative success using it.

(and I lost my replies)

Dang!

your effort is very appreciated and thanks for stepping-up

Right on sibling! (I've found it tenuous assuming others' genders online, so I'll stick with "sibling" over "brother" or "sister")

I'm glad my work is appreciated though I worry a bit, as I haven't written a lick of code yet to improve the spreadsheet workbench (or expression parser)!!!!