bug was that uiPupMenuSaveOver(...) could run the WM API call function which freed the operator, within the low level invoke function which kept using the freed memory.
Changed uiPupMenuSaveOver(...) to only show a popup so the caller needs to check if the file exists and should be immediately written (which was done everywhere except for blend saving anyway).
* added note that operators invoke/exec funcs cant call WM_operator_call(...) on themselves, ends up using freed memory.
* added BLI_is_file(path), checks the file exists and isnt a directory.
- some merges added lines in multiple times
- removed some NULL checks that were only in bmesh
- enable cycles by default (was disabled because it used not to work)
- make formatting match
I've written a convenient function that returns the sibling of a node in the
red-black tree implementation originally implemented by Joshua Leung.
I want to use this get_sibling() function in the future to implement the missing
removal function of the red-black tree implementation.
For now the get_sibling() function just simplifies the get_uncle() function.
Just like the rest of the red-black tree implementation this diff is based on
Wikipedia: http://en.wikipedia.org/wiki/Red%E2%80%93black_tree#Removal
There were some issues with PBVH which prevented working it for meshes without faces.
Discussed with Brecht, for benefits of dynamic-topology-sculpting and so better to
make PBVH survive such things.
Added some extra NULL-pointer checks for this.
from Andrew Hale (trumanblending), with some edits to use these in mathutils.Vector added.
Added Functions:
- dot_vn_vn - Dot product of two arrays
- normalize_vn_vn - Normalize an array and store the result in a second array
- normalize_vn - Normalize an array inplace
Renamed Functions:
Some functions have been renamed to make them consistent with the naming conventions used by fixed length array functions.
- fill_vni to fill_vn_i
- fill_vn to fill_vn_fl
Bring back some old scanfill code to handle tesselating polys with some zero-length edges. This code used to cause #4544 but I haven't been able to recreate that now, so I'm going to revive the old code and if #4544 does come back, we'll have to fix it some other way I guess (or come up with a better solution for zero-length edges in polys).
- use NULL rather then 0 for pointers
- use static functions where possible
- add own includes to ensure func's and their declarations don't get out of sync.
