PR #4752 Topological Naming
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Posts: 225
- Joined: Fri Apr 26, 2019 3:14 pm
Re: PR #4752 Topological Naming
Hi All, @realthunder,
... wouldn't it be possible that an (graphical) object keeps a "history" of it's (prevoius) names so it can trigger an update of objetcs referencing it by it's previous name in case of "just name-changes" ?
I can imagine, that this might adress the issue pauves_honteux has shown ...
Regards,
Stefan
... wouldn't it be possible that an (graphical) object keeps a "history" of it's (prevoius) names so it can trigger an update of objetcs referencing it by it's previous name in case of "just name-changes" ?
I can imagine, that this might adress the issue pauves_honteux has shown ...
Regards,
Stefan
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Re: PR #4752 Topological Naming
Hmm, this was interesting, if I create the block and cylinder from "primitives" it seams the radius connection (Fillet003) is more stable!
To me this suggests it possibly has something to do with "linking chain length" (number of steps involved)?
To me this suggests it possibly has something to do with "linking chain length" (number of steps involved)?
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: PR #4752 Topological Naming
What's the post you are referring to (where pauves_honteux shows something)? I don't quite get what you mean by 'graphical object'? Oh, it's in the previous page. Silly me. I'll check.C_h_o_p_i_n wrote: ↑Tue Aug 10, 2021 8:41 am Hi All, @realthunder,
... wouldn't it be possible that an (graphical) object keeps a "history" of it's (prevoius) names so it can trigger an update of objetcs referencing it by it's previous name in case of "just name-changes" ?
I can imagine, that this might adress the issue pauves_honteux has shown ...
Regards,
Stefan
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: PR #4752 Topological Naming
There is indeed a problem with saving the history encoded in the topo names. If you open the document and perform a full recompute, the history will be regenerated. And then changing the sketch will less likely cause an error. The model history is broken into pieces and stored in a string table. Each topo name is supposed to reference count those strings in the table, and only those counted will be saved to file. There is a bug in reference counting which causes some strings not get saved. So the next time the file is loaded and perform a recompute due to model change, a new name will be generated, and hence the missing element error. If the model is not changed, or more specifically, if the referenced geometry (the fillet edge in your model) is not changed, then the missing element will be auto corrected and there will only be warning of reference change when doing recompute.Pauvres_honteux wrote: ↑Sun Aug 08, 2021 3:35 pm As a user I would expect the underlying TopoNaming workings to sort out this type of id-change as far as it is possible.
Yes, the workflow can always improve. Right now, what happens is when the user double clicks the error object and entering the edit mode, the algorithm will attempt to infer the changed reference, and show the corrected result to user, in which case the user won't see the red marking of missing element. If the red marking does occur, it means the algorithm can't infer the reference (or there are too many candidates). The preview still retain the original fillet, and moving the mouse over the red marked element will highlight the fillet to help user to manually correct it.If TopoNaming workings fails, it would be preferable if some sort of window pops up showing the old and new intersecting curve asking user if the new one is ok to use instead. With an ok- and preview-button, where the ok-button is preselected. That way the user only needs to confirm by pressing the Enter-key. The recalculation then continues down the tree and the process repeats with minimal effort / fast workflow from user side.
Re: PR #4752 Topological Naming
Without any discussion since August and only bickering recently in the comments on GitHub, I'm wondering if there are any updates regarding the status of this PRs review process.
Thank you to all of the people who work hard on improving FreeCAD, it must often feel like thankless work.
Thank you to all of the people who work hard on improving FreeCAD, it must often feel like thankless work.
Re: PR #4752 Topological Naming
I just saw the talk at FOSDEM with Realthunder. I think this feature needs to get integrated in the forseable future. I also see that the Github PR should be finished and needs more testers. Is there some info available on how we can help with this?
Re: PR #4752 Topological Naming
In the FOSDEM talk, realthunder says that he will simplify the PRs. So we should wait to test the PR.
What we can work on in the meantime is helping @bernd create a type of builder.freecad.org (something like https:;//builder.blender.org) that can build FreeCAD incorporating different PRs. One of the challenges of testing toponaming was that users needed to compile the builds. Lets make it easier for everyone and supply builds to testers who want to test
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: PR #4752 Topological Naming
I'm a user not programer..
+1
I like to test i not like to compile.
+1
I like to test i not like to compile.
Re: PR #4752 Topological Naming
I come from an EE and testing background and have been running Linux since 1996.Kunda1 wrote: ↑Sat Feb 05, 2022 9:19 pmWhat we can work on in the meantime is helping @bernd create a type of builder.freecad.org (something like https:;//builder.blender.org) that can build FreeCAD incorporating different PRs. One of the challenges of testing toponaming was that users needed to compile the builds. Lets make it easier for everyone and supply builds to testers who want to test
While I can read code, but you shouldn't want me to write it. I can compile almost everything if it's necessary.
But for most Windows users, compiling FreeCAD from source will remain a bridge too far.
I like the idea of easily creating a custom build of FreeCAD to test that build on your machine.
But I find it hard to see what's necessary to test and see where the critical areas are. Maybe there should be a bit more coordination on this part, because seems as such a large part. What are the test input/filess to check if it works correctly and the expected result? Something of a test and integration design with simple test cases would make it easier for people to check it on their machine.
I like that Linkstage3 merging will happen in smaller chunks, but it would also be nice if there existed a bigger integration plan. Be it in a blog, a bunch of slides, wiki or a list of GH issues.
It would be great to solve the topological naming problem with FreeCAD 0.20. We wouldn't want to have this pushed even further down the road.
Re: PR #4752 Topological Naming
There are files floating around for testing TPN. Need to find them.
Yes, guidance on how to test experimental builds is important. We should add that as a step that the dev orients testers to test. But there is something to be said about veteran testers/users fiddling around and trying to break workflow.
As for TPN in v0.20, I think it's important to be practical. (Just want to emphasize, I'm not speaking for the devs and this is purely IMHO)
Where are we now?
It's Feb 2022, v0.19 was released March 20, 2021 (we're coming up on 1 year anniversary)
The average release cycle for FC is 1 year...exceptions v0.17, 0.13, 0.7, 0.2
If we try to get TPN in to v0.20 that's another year of delay in order to stabilize the code. TPN code has a high-burnout quotient, basically it sucks to tackle. I think a year is a fair projection.
Another year of delay has repercussions, packagers need to 'hold the line' and keep maintaining/patching 3rd party dependencies. This pushes us farther down the spiral of 'dependency hell'. We have to maintain dependencies for things like Qt5.9 and simultaneously Qt6.2 and higher for the 'rolling release' distros. etc..etc...
For bug triage, another year is hellish because people will still be opening tickets for 0.19 when they've been fixed in v0.20dev This is monotonous, thankless and compassion-fatigue work (I know since I do it myself) because users get upset for putting efforts in to helping find bugs only to be closed for duplicate and superfluous efforts.
On the forum, we will see the same thing as the above. We will get people complaining (there will always be complaining) because they're judging FC by an outdated version.
I say we rally, release v0.20 soon. take aim at TPN in the next version.
Yes, guidance on how to test experimental builds is important. We should add that as a step that the dev orients testers to test. But there is something to be said about veteran testers/users fiddling around and trying to break workflow.
As for TPN in v0.20, I think it's important to be practical. (Just want to emphasize, I'm not speaking for the devs and this is purely IMHO)
Where are we now?
It's Feb 2022, v0.19 was released March 20, 2021 (we're coming up on 1 year anniversary)
The average release cycle for FC is 1 year...exceptions v0.17, 0.13, 0.7, 0.2
If we try to get TPN in to v0.20 that's another year of delay in order to stabilize the code. TPN code has a high-burnout quotient, basically it sucks to tackle. I think a year is a fair projection.
Another year of delay has repercussions, packagers need to 'hold the line' and keep maintaining/patching 3rd party dependencies. This pushes us farther down the spiral of 'dependency hell'. We have to maintain dependencies for things like Qt5.9 and simultaneously Qt6.2 and higher for the 'rolling release' distros. etc..etc...
For bug triage, another year is hellish because people will still be opening tickets for 0.19 when they've been fixed in v0.20dev This is monotonous, thankless and compassion-fatigue work (I know since I do it myself) because users get upset for putting efforts in to helping find bugs only to be closed for duplicate and superfluous efforts.
On the forum, we will see the same thing as the above. We will get people complaining (there will always be complaining) because they're judging FC by an outdated version.
I say we rally, release v0.20 soon. take aim at TPN in the next version.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs