Reimplementing constraint solver

[abdullah]

Now I get a new crash, in the destructor of TaskDialog, when I close the sketch:

I pushed a fix for this.

[DeepSOIC]

Now to the gil. This is rather painful, as any use of Py::Object (creation, reassignment, destruction) must happen with GIL engaged, because I assume that changing reference count is a Py API call, and

Non-Python created threads
When threads are created using the dedicated Python APIs (such as the threading module), a thread state is automatically associated to them and the code showed above is therefore correct. However, when threads are created from C (for example by a third-party library with its own thread management), they don’t hold the GIL, nor is there a thread state structure for them.

If you need to call Python code from these threads (often this will be part of a callback API provided by the aforementioned third-party library), you must first register these threads with the interpreter by creating a thread state data structure, then acquiring the GIL, and finally storing their thread state pointer, before you can start using the Python/C API. When you are done, you should reset the thread state pointer, release the GIL, and finally free the thread state data structure.

I think rather than locking the gil in just about every routine of ConstraintSolver, I'd instead place an assert in PyHandle, that will force us to engage gil in event handlers.

[DeepSOIC]

GIL discussion: https://forum.freecadweb.org/viewtopic.php?f=10&t=45076

[abdullah]

If it is relevant, I may try to make an interface to change it from Python.

That would be nice, but if it gets difficult, maybe it's worth having a separate branch with new sketcher code...

Nothing fancy, just to keep you going comfortably:

Code: Select all

Sketcher: Default to GCS and SwitchSolver command

===================================================

This is intended as a temporary facility to switch during runtime solver between GCS and FCS.

How?
ActiveSketch.switchSolver()

It informs in the Console of the activated solver.

I have pushed it to the branch.

[abdullah]

I think rather than locking the gil in just about every routine of ConstraintSolver, I'd instead place an assert in PyHandle, that will force us to engage gil in event handlers.

I was thinking exactly this, but I am not aware of all the implications...

[abdullah]

...

Any recommended way to clear (empty) the parameterStore?

[DeepSOIC]

...

Any recommended way to clear (empty) the parameterStore?

Create a new one. Clearing is not supported, as there may be ParameterRefs that still refer to it.

[abdullah]

...

Any recommended way to clear (empty) the parameterStore?

Create a new one. Clearing is not supported, as there may be ParameterRefs that still refer to it.

Ok. This is what I did locally.

[abdullah]

...

New question related to ParaPoint and ParaShape<ParaPoint>.

I see that a parashape is something like applying a transformation (placement) to a parageometry (correct me if I am wrong).

I am implementing the interface with the coincident constraint, and I have a pair of hparapoints which I would like to feed to the constraint constructor, which takes h(parashape<parapoint>) aka HShape_Points, like this:

Code: Select all

       FCS::G2D::HParaPoint &p1 = Points[pointId1];
        FCS::G2D::HParaPoint &p2 = Points[pointId2];
    
        c.fcsConstr = new FCS::G2D::ConstraintPointCoincident(p1,p2);

This does not work, because of the different types, any advice of how to "cast" or "convert" those hparapoints into HShape_Points?

[DeepSOIC]

It is done like that:

Code: Select all

FCS::G2D::HShape_Point sh = new FCS::G2D::ParaShape<FCS::G2D::ParaPoint>(new FCS::G2D::ParaTransform(), hp);

This is somewhat inconvenient, you are welcome to improve on it. One way to improve is to add a toShape() method to all geometries.

EDIT: it may also be a good idea to create a unity transform as a singleton, so as to not have to create it insane number of times.