I was assuming from observing behaviour, and clearly wrongly, that a library was being used to do the equivalent of an ‘eval’ of the formula given a set of variable values to work from. If this isn’t the case, then you already have the code to know, for a given object the objects that it depends upon, and also the usages of any object. I don’t want to step on anyone’s toes, and i’m Java/Javascript rather than C++, so can’t help with the code base, but I could extract from my work the set of rules. On a related note, if I’m wrong about it being eval-like, then surely you could allow Line_A_B to work for any two points that are already defined?
2 Likes
This nice phrase meets exactly my feelings …
Yours truly, the traditional nerd in service
1 Like
Not sure what a “library” has to do with it? Qt treats libraries in 2 ways - static, where the code is complied and linked IN the app binary OR dynamic, where the code is compiled and a dll is created, which is linked at run time. You can do it either way with same code, and in end makes no operational difference. Dll’s are usually used where the author does not wish to release the source code.
That being said… the bulk of the Seamly apps are libraries. Specific to the formulas, RT ported the MuParser math parser to Qt… thus QMuParser. For whatever reason, it’s built as a dll?
Now for a rough flow outline:
Load pattern from XML to a QDomDocument in memory. Parse Increments. Parse Draw Elements (AKA draft blocks). Within each Draw element parse each child tool element in sequential order followed by the detail ( pattern piece) elements.
As each tool is parsed, each formula is 1st translated. Then the formula is evaluated. 1st to see if any variables (increments, measurements, other tool variables) or math tokens exist, if not it’s just a number - no calculation required - return number. If there are tokens then the formula is Eval()'d, where the variables are replaced with their value. Then the formula is math parsed via QMuParser, and the final calc returned.
Since each tool is built sequentially, only the tool variables (line length / angle, etc) that were created BEFORE are available to be Eval()'d. THAT’S why future tool variables are NOT yet available to use in tools created before hand - they’re not in the data container yet.
I should note that as each tool is created, for each other parent tool it references, it calls that tool’s IncrementReferens(parentId), which increments it’s use counter by 1, and if that tool is deleted it calls the DecrementReferens(patentId) of each parent. So if you go to delete a tool where it’s use count > 0, you can’t delete it, until all child tools are deleted.
Editing a tool’s formula in a dialog or the Properties Editor that changes geometry will probably trigger a reparse of the pattern via the same evaluation of the formulas.
That’s it in a nutshell.
The language used was not a big issue for me since I’ve learned dozens of languages over 45+ years (including Java), it was easy to pick up the bulk of the syntax of C++ in a couple weeks. It’s the learning the Qt api that takes a long time… not to mention reading through piles of poorly styled code.
3 Likes
Wo wir, die wir ausschließlich Muster erstellen immer gerne helfen.
1 Like
Oh, as a trained scientist you for sure are able to learn develop programs to help out a little bit, always aware of the needs of those who use those programs? 
(Which reminds me that I wanted to have a look into translations but need to date up my system first and somehow, there are some clothes that still want to be sewn … - why is it that there isn’t any more time now??)
1 Like
Clearly a case of too much fabric & so (sew) little time.
1 Like
@Douglas thanks for the detailed explanation.
When the variables are replaced, is this done by the formula asking for a value for a token (e.g. Line_A1_B1), or is the code trying search & replace on the known derived values, replacing them with their values? If the former, it would presumably be easy to support any Line_X_Y value? you would parse Line_A1_B1 into a request for the distance between A1 and B1. (Assuming A1 and B1 are already defined). The fact that it sometimes fails leads me to think that the code must be trying to search/replace known values (and this might be contributing to why a large pattern slows down noticeably).
(I did C++ at uni, but that was >30 years ago now!)
3 Likes
Sounds right 
So, getting back to sewing to get that fabric out of the way
2 Likes
I’ll have to take a closer look at the parser code to see exactly what it’s doing.
1 Like
That would be interesting. Would it help if I create a little .val file that demonstrates the issue?
3 Likes
Can’t hurt. Even if we can’t solve the “future” tool issue, I’d be happy if we can at least improve the performance speed… or as the case is to reduce the amount of parsing.
BTW… in fixing a parser related issue I took my 1st real dive into some of the parser code - more stuff to unravel. Since RT more or less ported the code as it, it’s another coding style to comprehend. 
2 Likes
@moniaqua, I would be willing to help out. In half a year from now I will retire and that will probably give me enough time. I have no experience at all with C++ or Qt, that does not help. I’ll see when we are there.
4 Likes
Here is a very simple .val, created on my-pattern.cloud that causes Seamly2D to barf on loading. The points A1 and A3 have been defined, before the arc, but the Line_A1_A3 is not available as the radius and it throws up the fix-formula dialog.
My inference is that the token Line_A1_A3 is not being split into its component parts to identify that this is a request for the distance between those points, but rather the known line lengths A1_A2 and A2_A3 are available, but A1_A3 is not.
Line length test 2 rev1 20230114164312.val (873 Bytes)
3 Likes
Hmmm, I see that there is no line A1_A3, only A2_A3.
That’s what they’re examining. Whereas RT programmed Seamly2D to need a specific tool to particularly tell Seamly2D to allow the distance between two points to be called, @MrDoo scripted the patterncloud to only need the two points in order to call a measurement between two points.
Would it be possible/easy enough to rejigger Seamly2D to work like the patterncloud in this situation? Hopefully that .val helps @Douglas see.
Is it a good idea?
- It would reduce the need for time-travel, especially for those just starting out.
- Would it eliminate the need to remember the direction of the line?
- But it would also make the list of lines from the formula wizard inordinately long, even compared to the present situation.
& now I think I understand that part of the discussion better.
2 Likes
@Pneumarian thats right.
In point 3 above, the list of lines would no longer be necessary. You’d simply select any two points (that are already defined).
3 Likes
Hee-hee, thank you for explaining, @Pneumarian.
& @MrDoo… Wow! Sounds like a very good idea. Thank you.
1 Like
@MrDoo Ich habe die Datei aufgemacht und konnte auf die Linien A1_A3 und A2_A3 zurückgreifen.
1 Like