error when compile LinkDev

[dulouie]

hi realthunder i want to look at your newested development progress. But a few days ago i get this error.

/src/FreeCADLinkDev/src/Mod/Part/App/PropertyTopoShape.cpp: In member function 'void Part::ShapeHistory::reset(BRepBuilderAPI_MakeShape&, TopAbs_ShapeEnum, const TopoDS_Shape&, const TopoDS_Shape&)':
/src/FreeCADLinkDev/src/Mod/Part/App/PropertyTopoShape.cpp:435:44: error: aggregate 'TopTools_ListIteratorOfListOfShape it' has incomplete type and cannot be defined
         TopTools_ListIteratorOfListOfShape it;
                                            ^~
make[2]: *** [src/Mod/Part/App/CMakeFiles/Part.dir/build.make:1399: src/Mod/Part/App/CMakeFiles/Part.dir/PropertyTopoShape.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1731: src/Mod/Part/App/CMakeFiles/Part.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

i think these include can fix it:
#include <TopTools_ListIteratorOfListOfShape.hxx>

And you are on the right way with asm3 thank you.

[realthunder]

Fixed now. However, be warned that LinkDev is under heavy change these few days. Lots of rebase there. I am taking on the topological naming issue. Still testing now, but expect to release a new version along with asm3 soon.

[dulouie]

Your new 2-pass-recompute is very interesting for me, because a few month ago i tried to change the shapebinder placement. I know you have created a new subshapebinder but it is not exactly what i want.
Look at my old thread what i mean: https://forum.freecadweb.org/viewtopic.php?t=25168

Here are my placement changes: https://github.com/dulouie/FreeCAD/blob/shapebinder/src/Mod/PartDesign/App/ShapeBinder.cpp

Do you think it is now possible to get my shapebinder working without dependency loop?
ps: i'm not a programmer expert but try my best

[realthunder]

I am afraid it is not that useful in your case. In my use case, the parent is actually aware of the dependency inversion. It is the parent who updates the children, which violates the FC dependency order. My patch allows the parent to skip the update in the second pass to avoid infinite loop.

But in your case, the parent is not aware of the inversion. The children has no way to make sure that after it's been recomputed, its parent's placement remains the same. FC always recompute children first, then parent.

I am not sure if I get your intention, but why not create another Body, and bring in the other two bodies with shape binder. With my new shape binder, you can choose whether to follow the other two bodies placement or not.

[realthunder]

There is a possible way around. You'll need to create some kind of private observer (see class DocumentObserver) object to watch the parent's property change. And update your shape binder's placement whenever the parent one changes. Then, my two pass recompute may work for you, assuming the parent's placement is not calculated using its children (it might!).

That being said. I still recommend against what you are doing. Create another parent body should be the way to go.

[dulouie]

Basically i want to reference from one body to another body. Which is not allowed in current FreeCAD. The shapebinder is the helper tool for doing something like that, but it has some disavantages. It don't get the placement of the feature in the reference body in relation to the active body.
I figured out, it is a difference to get a shapebinder from the reference body or a reference feature.
When you get it from the feature, the placement is not relative to you but when you get it from the body, it is relative to you like your subshapebinder. (edit: and the parents group)
The problem is, that the placement is only relative to the origin (0,0,0) and not to the placement of the body that own the shapebinder.

Look here:

My intension was to calculate the placement from the reference body to active body with a codeline like that:

placement = placementActiveBody.inverse() * placementReference;

And then i make the placement of the shapebinder constant. So if the placement from the reference changed, it doesn't matter the shapebinder. It is like a snapshot at the moment when you create the shapebinder. So maybe i have no problems with depency loops and recompute, but I don't know much about it.

To illustrate that, here a next video:

[edit: video works now]

Another idea is to make it not permanent, like the shapebinder from reference body above or your subshapebinder. When the reference placement changed, it has to recompute the children and parents with recompute problems, when i use my methode.
Maybe you understand my intension now, what you think about it?
I think to create another parent body can not solve my problem.

[realthunder]

Yeah, I think my previous understanding of your intention is correct. Let me ask you a question. If you can now add a body directly to another body, can you get what you want without using shape binder?

[dulouie]

Yes i can use a clone to add a body directly to another body, but this is not what i want.
My vision is a similar workflow in FreeCAD like Design-In-Context on Onshape.
https://www.onshape.com/videos/design-in-context
Get sketch references from other body's with correct placement.

[realthunder]

Ah... very nice video! I think we should create a forum thread for this, as some possible future direction of FC.

Back to the topic. You do realize that the 'context' in the video is established in the 'assembly', not any of the individual parts. And that 'assembly' is exactly what I suggested you to create, a 'super' body. But I do realise that current Body do not support in-place editing like what's shown in the video. So, apparently the 'Body' is not the right container for this.

But hey, you are on my branch. Why not try my asm3 workbench. The assembly container there can be used for this purpose. And it supports in-place editing similar to what's shown in the video.

Be warned though, Shapebinder is not the right object to use in this case. You should use datum object. This is kind of chicken and egg situation. And I am sure OnShape does similar thing. Here is the workflow. Suppose you have two roughly designed bodies. You put them in the assembly and constraint their positions. In order to further refine, say body A, in context of body B's placement in the assembly. You can create datum object in body A that has the same placement of body B's geometry element in the assembly context. And you can continue your model refinement. The datum creation command needs modification to support that. I'll soon add a patch for you to test.

The reason to use datum object instead of shape binder is because datum object is detached from the other object. When your model involve, its constraining element in the assembly may change. So its context may change, too. If you use shape binder to bring in the context, it is a cyclic dependency right there.

What happens in the end is that, when you bring in more context, and your model continues to involve, you will gradually change your assembly's constraining element to those very datum object you created. That's optional, of course, but a good assembly practice nevertheless. Can you see the chicken and egg analogy here?

your bodies existing geometry element -> assembly constraining element -> datum object in context -> body geometry element changes due to refinement -> change assembly constraining element to those datum objects.

[dulouie]

I'm happy to hear you are also interested in this. Sure on my try to change shapebinder placement i forgot the 'super' body or assembly container. These makes sense and all other what you are say. With my limited freecadcode experience i used the shapebinder but datum objects makes more sense.
We can hack this together and i can't wait to test your next patch:)

btw: Some time ago i ask you about saso's proposal about to remove the local coordinatesystem from the body. Maybe this is relevant to in-context-design. All body's inherit the CS from the parent assembly. Is this relevant? (Edit: Maybe it's better to not touch the body, when i assume the discussion about it. My vision is Partdesign with in-context-editing and your asm3. And all tool interact in a clever way with no redundant tools or containers)

(edit: forum thread: https://forum.freecadweb.org/viewtopic.php?f=8&t=27340)

[realthunder]

Some time ago i ask you about saso's proposal about to remove the local coordinatesystem from the body. Maybe this is relevant to in-context-design

The video you posted is a different use case than what's shown in saso's video. saso's video is about designing one fixed part with multiple bodies. What OnShape video shows is designing a part in the context of its assembly position.

[dulouie]

Well, maybe the same usecase for a assembly object that own the one and only coordinate system. This is just a brainstorming.

[dulouie]

ATM i can't compile LinkStage3 or LinkDev:

/usr/include/c++/8.1.0/bits/stl_tree.h: In instantiation of ‘class std::_Rb_tree<const SMDS_MeshNode*, std::pair<const SMDS_MeshNode* const, const SMDS_MeshNode*>, std::_Select1st<std::pair<const SMDS_MeshNode* const, const SMDS_MeshNode*> >, TIDCompare, std::allocator<std::pair<const SMDS_MeshNode* const, const SMDS_MeshNode*> > >’: /usr/include/c++/8.1.0/bits/stl_map.h:151:17: required from ‘class std::map<const SMDS_MeshNode*, const SMDS_MeshNode*, TIDCompare>’ /home/arne/src/FreeCADLink/src/3rdParty/salomesmesh/inc/StdMeshers_Projection_2D.hxx:68:44: required from here /usr/include/c++/8.1.0/bits/stl_tree.h:452:21: error: static assertion failed: comparison object must be invocable with two arguments of key type static_assert(__is_invocable<_Compare&, const _Key&, const _Key&>{}, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/8.1.0/bits/stl_tree.h: In instantiation of ‘class std::_Rb_tree<const SMDS_MeshNode*, const SMDS_MeshNode*, std::_Identity<const SMDS_MeshNode*>, TIDCompare, std::allocator<const SMDS_MeshNode*> >’: /usr/include/c++/8.1.0/bits/stl_set.h:133:17: required from ‘class std::set<const SMDS_MeshNode*, TIDCompare>’ /home/arne/src/FreeCADLink/src/3rdParty/salomesmesh/inc/SMESH_MesherHelper.hxx:716:24: required from here /usr/include/c++/8.1.0/bits/stl_tree.h:452:21: error: static assertion failed: comparison object must be invocable with two arguments of key type make[2]: *** [src/3rdParty/salomesmesh/CMakeFiles/StdMeshers.dir/build.make:570: src/3rdParty/salomesmesh/CMakeFiles/StdMeshers.dir/src/StdMeshers/StdMeshers_Projection_1D2D.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:468: src/3rdParty/salomesmesh/CMakeFiles/StdMeshers.dir/all] Error 2 make: *** [Makefile:130: all] Error 2
Compiling FreeCAD 0.18 git master works well, so what is my mistake? Can you compile one of your branches?

[realthunder]

Yes, I can compile. The error reported is from a third party library. I didn't touch anything there. Besides, I checked code there, and the error doesn't make sense. Maybe you try a clean build and see.

[dulouie]

the problem is gcc 8.1 and the discussion about it here: https://forum.freecadweb.org/viewtopic.php?t=27399