Merging of my Link branch

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
realthunder
Posts: 1188
Joined: Tue Jan 03, 2017 10:55 am

Merging of my Link branch

Postby realthunder » Sat Jun 30, 2018 12:34 pm

Hello everyone. I am starting this thread for a discussion of the possibility to merge upstream with my Link branch https://github.com/realthunder/FreeCAD/tree/LinkStage3.

Pre-built images can be downloaded at https://github.com/realthunder/FreeCAD_ ... 3/releases

Design and implementation of Link can be found at https://github.com/realthunder/FreeCAD_ ... /wiki/Link

Summary of core API changes https://github.com/realthunder/FreeCAD_ ... re-Changes

Topological naming documents
https://github.com/realthunder/FreeCAD_ ... cal-Naming
https://github.com/realthunder/FreeCAD_ ... -Algorithm

The total amount of change is huge. But as you can see from the summary of core changes, most of them are inter-related, and should be fully backward compatible with existing code, C++ and Python.

wmayer wrote: ping
Try Assembly3 (latest version 0.10.2) along 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
looo
Posts: 2894
Joined: Mon Nov 11, 2013 5:29 pm

Re: Merging of my Link branch

Postby looo » Sat Jun 30, 2018 6:02 pm

finally :)

Maybe you can create a PR directly so we can see what is missing. I tried to build with py3 and there are some things not working yet:

Code: Select all

../src/App/LinkBaseExtensionPyImp.cpp: In function ‘bool getProperty(PropTmpMap&, const PropInfoMap&, const PropMap&, PyObject*, PyObject*)’:
../src/App/LinkBaseExtensionPyImp.cpp:50:27: error: ‘PyString_Check’ was not declared in this scope
     if(!PyString_Check(key)) {
                           ^
../src/App/LinkBaseExtensionPyImp.cpp:54:47: error: ‘PyString_AsString’ was not declared in this scope
     const char *keyStr = PyString_AsString(key);
                                               ^
../src/App/LinkBaseExtensionPyImp.cpp:66:33: error: ‘PyString_Check’ was not declared in this scope
         if(!PyString_Check(value)) {

for python3 you should use unicode here (PyUnicodeCheck, PyUnicode_AsUtf8String, PyUnicode_AsUTF8). So either use unicode for py2 and py3 or use something like this:

Code: Select all

#if PY_MAJOR_VERSION < 3
PyString_Check
#else PY_MAJOR_VERSION < 3
PyUnicodeCheck
#endif PY_MAJOR_VERSION < 3
edit: I think I have corrected most of them. I will send a PR.
please help with my conda-packaging efforts: https://liberapay.com/looooo/
looo
Posts: 2894
Joined: Mon Nov 11, 2013 5:29 pm

Re: Merging of my Link branch

Postby looo » Sat Jun 30, 2018 8:31 pm

With some py3-fixes I was able to build your branch. FreeCAD-tests are working, some basic stuff I need is also working :D . I couldn't test the assembly3 module because I have no solvespace and no pysolvespace. I looked at building solvespace but the dependencies makes me not want to do so. Better to wait for the sympy/scipy solver.
please help with my conda-packaging efforts: https://liberapay.com/looooo/
User avatar
DeepSOIC
Posts: 7015
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Merging of my Link branch

Postby DeepSOIC » Sat Jun 30, 2018 8:34 pm

I had a quick read of the core changes, thanks for writing them out! About half of it I didn't understand :oops: .

A few questions.
DocumentObject
A new property, Visibility, has been added to make it possible to set and get visibility status of an object in App namespace. This makes it possible to determine the children visibilities in some group object without loading GUI, for example, to generate a compound shape representation of a group.
Does toggling visibility of an object change the App-domain visibility property? If so, what ends up being touched? How does FC determine that a recompute is necessary to update the example compound?

I don't quite like the approach. An independent property would be better, IMO. Something like "Enabled", and a checkbox to show up next to the object in tree. Even better, this "enabling" should be stored in tree parent somehow, so that if say a shpere participates in two regular Part Compounds, one could tick it out of one of the compounds but not the other.

...
User avatar
DeepSOIC
Posts: 7015
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Merging of my Link branch

Postby DeepSOIC » Sat Jun 30, 2018 8:37 pm

next question:
The two-pass recomputation works like this. The first pass proceed as normal. After its done, any object that is still touched will be marked with a newly added ObjectStatus::Recompute2 flag. The second pass will then be launched. Those objects that need dependency inversion shall check its dependent objects for this flag, and do not touch them if found. If there are still objects touched after the second pass, an error message will be printed.
In the above SketchExport example, the parent SketchObject will update all its children SketchExport in its execute() function in the first recomputation pass. Since all children (i.e. dependent) objects are recomputed before its parent. Those SketchExport object will still be touched after the first pass, and will be marked with Recompute2 in the second pass. SketchObject will then skip updating its children and complete the second pass without any problem.
I haven't tried your SketchExport thing (shame on me!), but I feel like second pass of recompute is not at all needed. SketchExport object should just have a link property to Sketch, and update itself after the sketch has been solved... I have a feeling that if I try this feature, I will instantly understand. But from a more passive reader's perspective, the use case doesn't justify second pass. Is the second pass needed for assembly3?
realthunder
Posts: 1188
Joined: Tue Jan 03, 2017 10:55 am

Re: Merging of my Link branch

Postby realthunder » Sat Jun 30, 2018 11:00 pm

DeepSOIC wrote:
Sat Jun 30, 2018 8:34 pm
Does toggling visibility of an object change the App-domain visibility property? If so, what ends up being touched? How does FC determine that a recompute is necessary to update the example compound?
For backward compatibility reason, 'Visibility' in App has 'Output' status bit set by default, which makes it behave the same as Gui 'Visibility', i.e., do not touch object when changed. You can change that behavior by calling obj.setPropertyStatus('Visibility', '-Output'), after which the object will be touched when toggling visibility. And yes, the Gui 'Visibility' and App 'Visibility' are synchronized. Extra logic can be implemented in parent object, in case it uses its children object's 'Visibility' property for building compound, for example to automatically change the property status of the newly added child. I didn't implement that in App::Part, because I think it is better to store the visibility information of the children directly inside parent, instead of using children object's global visibility information. LinkGroup has 'VisibilityList' property for that purpose.
DeepSOIC wrote:
Sat Jun 30, 2018 8:37 pm
I have a feeling that if I try this feature, I will instantly understand. But from a more passive reader's perspective, the use case doesn't justify second pass. Is the second pass needed for assembly3?
Because for better organization purpose and easy editing, all SketchExport are grouped under its parent Sketch object, by using a PropertyLinkList, which causes the dependency inversion.

There is another solution to this problem now. I later added a Hidden link scope, which hides its dependency information from the core. It should now be possible to change PropertyLinkList in Sketch to PropertyLinkListHidden, and add a normal PropertyLinkSub to SketchExport, which will be a better solution. I implemented hidden scope later, and decide to leave the sketch export unchanged as an example of two pass recompute, in case it is needed in other use case.
Try Assembly3 (latest version 0.10.2) along 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
Posts: 1188
Joined: Tue Jan 03, 2017 10:55 am

Re: Merging of my Link branch

Postby realthunder » Sat Jun 30, 2018 11:09 pm

looo wrote:
Sat Jun 30, 2018 8:31 pm
With some py3-fixes I was able to build your branch
Thanks, and please submit a PR to my branch. I am expecting problems with py3, because, well, I have never tried it. I figure that instead of digging into something unfamiliar, it is better to leave it to the experts, like you guys.

I couldn't test the assembly3 module because I have no solvespace and no pysolvespace. I looked at building solvespace but the dependencies makes me not want to do so. Better to wait for the sympy/scipy solver.
The merge discussion here does not concern assembly3 and solvespace, at least not in a direct way, but sympy solver has a long way to go to be practically usable.
Try Assembly3 (latest version 0.10.2) along 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
triplus
Posts: 8706
Joined: Mon Dec 12, 2011 4:45 pm

Re: Merging of my Link branch

Postby triplus » Sun Jul 01, 2018 7:55 pm

I don't know about the rest (things like topo naming and plethora of other features you explored and added to the branch). But you have my vote for the Links functionality to be included in FreeCAD 0.18.
User avatar
fosselius
Posts: 344
Joined: Sat Apr 23, 2016 10:03 am

Re: Merging of my Link branch

Postby fosselius » Tue Jul 10, 2018 7:03 am

Any progress? Would hate to see this fade away like realthunders previous merge/push attempts.
Jee-Bee
Posts: 1957
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Merging of my Link branch

Postby Jee-Bee » Tue Jul 10, 2018 9:47 am

It's a pity that the core developers don't react on the post over here...
I can imagine that @wmayer and @yorik are quite busy.
Even if they start looking today it takes at least weeks before merging since it is a huge change.

Don't know if it is possible to split the hole branch up in 3 or 4 steps. so not everything change in one moment...