PR #4752 Topological Naming

[Kunda1]

No one is reporting issues. Is it time to rebase and merge ?

[user1234]

Just said, i am not a developer (too old to learn the "new" C++), but i can test things when i have time and know the module/workbench. If realthunder rebasing it, i can test the FEM workbench (the VTK9.0.1 support was shortly implemented after the PR). But he main question is if the PR is still alive. He (realthunder) added a few days ago something in the PR.

Greetings
user1234

[wsteffe]

Is it time to rebase and merge

I would also think so. As time passes new commits are done and the rebasing becomes more complex.

[Kunda1]

So here's the thing, it's not encouraging to see - at least on the surface - so little commentary and participation regarding this patch. I don't know if discussions are occurring in private or off forum... Hanging out on the forum and GitHub for the past several years in this context the lack of external activity is perhaps indicating a trend where these patches may just rot. Maybe I'm just feeling anxious and biased because I really would love to see toponaming implemented like we all do.

Thankfully the development cycle has slowed down a bit since release so these series of patches that RT's made aren't becoming as obsolete as fast.

I'd like to know how the core devs are experiencing the code at the moment. Is there any feedback besides what's been given previously, you have to offer? This PR still seems pretty big, would it be worth simplifying even further? How much time has been spent reviewing the code so far?At this point is it also worth running code reviewing third-party software on the specific PR's? If you could update us that would be extremely encouraging.

Anyway what I'm going to do next is offer a proposal that I've mentioned previously. IMHO We create a separate branch off of master, call it toponaming, merge the first PR,build it in conda cross-platform, serve the builds from GitHub. This gives those of us who want to help test but have slow laptops and can't always compile FC from source with every code change being merged. More of us can then test. What do you think RT, since you've successfully done this with your LS3/A3 branch, could we do the same here?

[Pauvres_honteux]

... so little commentary and participation regarding this patch.

This may be part of the explanation:

The current PR only introduced the framework. No actual modeling code uses the framework yet. So there isn't much you can test. There will be at least three more follow up PRs...

I don't know, but I get a feeling that maybe the testing should be targeted at the programming crew?

[Kunda1]

This may be part of the explanation:

The current PR only introduced the framework. No actual modeling code uses the framework yet. So there isn't much you can test. There will be at least three more follow up PRs...

I don't know, but I get a feeling that maybe the testing should be targeted at the programming crew?

RT, how do you suggest testing should happen?

[realthunder]

RT, how do you suggest testing should happen?

Not entirely sure either. As the current PR contains code that has very limited impact to existing code, I guess just rely on the unit test?

[user1234]

A Test with

Code: Select all

FreeCAD -t 0

OK. But there are some warnings and errors, but they (mostly) seems intention. Also

Code: Select all

FreeCAD -t UnitTests

says OK with no errors or warnings.

Tested with:

Code: Select all

OS: Debian GNU/Linux 11 (bullseye) (X-Cinnamon/lightdm-xsession)
Word size of FreeCAD: 64-bit
Version: 0.20.24783 (Git)
Build type: Debug
Branch: TopoNaming
Hash: 9e7f78ba3839050d5a7375bd7ce8dac49a49feaa
Python version: 3.9.2
Qt version: 5.15.2
Coin version: 4.0.0
OCC version: 7.5.1
Locale: English/United States (en_US)

and C++17 and without FEM because i have vtk9.0.1.

Greetings
user1234

[onekk]

So here's the thing, it's not encouraging to see - at least on the surface - so little commentary and participation regarding this patch. I don't know if discussions are occurring in private or off forum... Hanging out on the forum and GitHub for the past several years in this context the lack of external activity is perhaps indicating a trend where these patches may just rot. Maybe I'm just feeling anxious and biased because I really would love to see toponaming implemented like we all do.

It is not strange that there is no discussion.

Until "the integration" is finished, there is no real impact on the daily use of FreeCAD.

Many people are searching a way to do things, like finding a Face and store a reference for this face, (maybe it's name), and then reuse the same object even if the original object has been fused with another object.

If I have guessed right "toponaming issue" is done to solve such things of problems.

I know that a gradual integration is a good thing, as this PR will impact in a "deep way" on some "core part" of FreeCAD, but things are "exoteric" at least from a normal user point of view.

I want to be able to find a face, of a cube or a solid and then refer to this face maybe to make it a reference point to rotate the object maybe to connect it with another object, maybe not using an Assembly workbench, but using simply scripting. (I'm guessing a possible usage)

Until things are not implemented, I can't test anything, from what I could catch from the discussion the PR is a "initial effort for integrating" a more articulate way to name things, and that names are consistent across trasformation (fusion, cut, fillet and so on).

I could argue if the name is generated correctly, but even having read realthunder documentation, I've only a vague idea of things, and take in account that from what I've realized the issue is arising not when using the GUI (that the most of user use), but only when using Macro or Script.

Final words

Implement things and then we could discuss on some "real cases", to find maybe "corner cases" that generate problems, in "real life" models, with the dev version of FreeCAD, not the realthunder variant.

Regards

Carlo D.

[Kunda1]

It is not strange that there is no discussion.

I disagree just because in the past before code has been implemented it's been discussed. RT split toponaming into several PRs (is intending to) so the logic behind that is usually discussed. Also analysis of code structure, logic behind why code was written to this or that specific file directory, analysis in regards to system resources, do's and don'ts...all of this gets discussed.

Until "the integration" is finished, there is no real impact on the daily use of FreeCAD.

If we're planning to do this, then we need to acknowledge there are at least 100 files touched in this first (of several) PRs. After implementation in to the master branch like this suggestion will mean a lot of changes introduced to the master. That may be a lot to revert or debug once in master. Why not make an official separate toponaming branch on GitHub in that case (as I've discussed above)?