Also enableRotation is off for this path and this code should not be getting called at all.
If set enableRotation to A(x) I do get what looks like a correct face mill path that I would expect without rotation but still get the div zero.
I think I've found the trigger for this bug. In this file the stock top Z is at -2 , ie the stock is smaller than the modelled part. This is not normally expected however this should be possible. There may be some assumption in the code.
It certainly should not be setting enableRotation on a traditional 2.5D facing op.
So that bug was just an indentation issue , LOL. That is one of the most insane aspects of python, where the entire structure of a program can be changed by a missing or incorrect indentation. This often makes it very hard to work out where the real cause of the syntax error is.
It seems this wacko feature has no reason to exist apart from just being done to be different. They were trying make a new language so had to play at Bill Gates and change stuff for the sake of it.
My favourite for this remains Algol-68 where all blocks had their own terminator keywords if .... fi ; while .... wend; etc. a great idea. A stack of closing curly brackets is not much help in C either.
Anyway, thanks for the quick fix. I'll make a local correction until it filters through. Hopefully Travis folks will do less of the identity politics and fix the software.
<class 'ZeroDivisionError'>: float division by zero
The super class of ZeroDivisionError is ArithmeticError. This exception raised when the second argument of a division or modulo operation is zero. In Mathematics, when a number is divided by a zero, the result is an infinite number. It is impossible to write an Infinite number physically. Python interpreter throws “ZeroDivisionError: division by zero” error if the result is infinite number. While implementing any program logic and there is division operation make sure always handle ArithmeticError or ZeroDivisionError so that program will not terminate.