As it looks like we are going to solve this problem at some point in time, I am going to prepare a PR with the basis that makes Windows Travis fail when tests fail, so that you can try with a PR. If you point me to your branch I can check that out and rebase my changes on that - I can tag my PR to ...

Also - do you know of a way to reproduce, force the issue on a Linux system? I'm going by code inspection which is typically error prone (I might miss one or two rogue imports).

'turns out that some of those files are a bit of a rats nest. PathUtils includes the gui because it is trying to find a job for an object - and if none presents itself (or more than one) - we ask the user for clarification. Problem is this utility function is currently use by almost all operations. ...

AlfredoC wrote: ↑

Wed May 22, 2019 3:10 pm

The problem is in the "PathSetupSheet"
Delete the default value for StepDownExpression and save it.
Now you can edit the step down value

Please follow chrisb's advice. Alternatively you can setup a template for your jobs with your own preferences.

abdullah wrote: ↑

Wed May 22, 2019 4:42 pm

Basically, some Python code within PathScripts that the cmd tests import include FreeCADGui code, which should not be the case.

Right - I would consider this a bug - I'll check it out tonight.

Ok, now I'm confused about two things, the first is a real newbie question. Do you distinguish "fix your shape" from re-doing the last operation with better parameter choices to get your shape, and if so, how? That depends on the algorithm and where and when it broke doing what. Sometimes changing ...

PaulG wrote: ↑

Tue May 21, 2019 9:34 pm

Do you think of it as normal to return an object like this that is not valid, and not throw an exception?

if you wanted to fix your shape this is the kind of behaviour you want - so, yes, I do think this is normal/the better approach than just throwing an exception.

scholli wrote: ↑

Sun May 19, 2019 11:27 am

When I try to create a pocket operation the basemodel jumps out of it's position (even kind of random as it seems)

Yes, this is currently broken - it happens whenever one repositions or rotates the base model. Unfortunately the fix is not straight forward and will probably take a bit.

for a clean build make sure to also clear ccache (in case you use it) and delete all *.pyc files - I've had problems with stale compiled python files before.

About the "mess", we need someone to champion the windows deployment/installation procedure for OCL. I don't use/have Windows so I wouldn't know where and how to start. I probably can't even install FC on Windows. This is something I'd like to help Zach work on for his Google Summer of Code project...