PR #4752 Topological Naming

Post here if you have re-based and finalised code to integrate into master, which was discussed, agreed to and tested in other forums. You can also submit your PR directly on github.
C_h_o_p_i_n
Posts: 194
Joined: Fri Apr 26, 2019 3:14 pm

Re: PR #4752 Topological Naming

Post by C_h_o_p_i_n »

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
User avatar
Pauvres_honteux
Posts: 728
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: PR #4752 Topological Naming

Post by Pauvres_honteux »

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

PartDesign_RealThunder_Body_translate_vs_radius_connection_1.png
PartDesign_RealThunder_Body_translate_vs_radius_connection_1.png (49.85 KiB) Viewed 6177 times
PartDesign_RealThunder_Body_translate_vs_radius_connection_2.png
PartDesign_RealThunder_Body_translate_vs_radius_connection_2.png (45.21 KiB) Viewed 6177 times
realthunder
Veteran
Posts: 2167
Joined: Tue Jan 03, 2017 10:55 am

Re: PR #4752 Topological Naming

Post by realthunder »

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
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.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Veteran
Posts: 2167
Joined: Tue Jan 03, 2017 10:55 am

Re: PR #4752 Topological Naming

Post by realthunder »

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.
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.
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.
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.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
obelisk79
Posts: 395
Joined: Thu Sep 24, 2020 9:01 pm

Re: PR #4752 Topological Naming

Post by obelisk79 »

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.
User avatar
jhaand
Posts: 44
Joined: Thu Apr 01, 2021 12:22 pm
Location: Venlo, The Netherlands
Contact:

Re: PR #4752 Topological Naming

Post by jhaand »

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?
User avatar
Kunda1
Veteran
Posts: 12997
Joined: Thu Jan 05, 2017 9:03 pm

Re: PR #4752 Topological Naming

Post by Kunda1 »

jhaand wrote: Sat Feb 05, 2022 11:54 am 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?
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:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
bleber
Posts: 134
Joined: Thu Jun 30, 2016 5:12 pm

Re: PR #4752 Topological Naming

Post by bleber »

I'm a user not programer..

+1

I like to test i not like to compile.
User avatar
jhaand
Posts: 44
Joined: Thu Apr 01, 2021 12:22 pm
Location: Venlo, The Netherlands
Contact:

Re: PR #4752 Topological Naming

Post by jhaand »

Kunda1 wrote: Sat Feb 05, 2022 9:19 pm
jhaand wrote: Sat Feb 05, 2022 11:54 am 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?
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
I come from an EE and testing background and have been running Linux since 1996.
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.
User avatar
Kunda1
Veteran
Posts: 12997
Joined: Thu Jan 05, 2017 9:03 pm

Re: PR #4752 Topological Naming

Post by Kunda1 »

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?
https://en.wikipedia.org/wiki/FreeCAD
https://en.wikipedia.org/wiki/FreeCAD
Screenshot_20220206_074837.png (112.64 KiB) Viewed 2366 times
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:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
Post Reply