Monday, March 16, 2009

Started iteration 0.0.9

The tasks scheduled for the current iteration are:

- Rebuild the tree view logic to display references as child nodes, estimated 6 hours,
- Apply on the tree view the model tree changes, estimated 3 hours,
- Propagate tree modifications (parametric modeling for the new data tree), estimated, 1 day,
- Extrude improvements, estimated 2 hours,
- Port Action2D to work with multi click instead of dragging, 1.5 days,
- Port Action3D to work with multi click instead of dragging, 1.5 days,
- Extract 2D actions drawing code to work in 3D (ex: drawing a line in 3D), estimated 4 days,
- Make the geometry solver to work with the data tree, store solver attributes on the data tree, estimated 3 days,
- Add code that displays magic geometry, estimated 1.5 days.

On the iteration will be made also code refactoring, bug fixing and documentation update.


ytjun said...


I know that OCC6.3 have memory leak problem.

Do you have solution or plan of the problem?

Thank you~

bxtrx said...


After we will have a functional version of Naro for sure we will start patching OpenCascade. If we will be lucky maybe until that moment OCC will release an improved version.

Best regards,

ciplogic said...


I think that OpenCascade in itself is not so leaky. The biggest reason for leaks in OpenCascade is the Handler_[class] structure, which is a reference counted smartpointer. This makes that circular references to not be disposable, and is not a problem of Opencascade per se but is a problem of C++ usage.
We cannot pretend for a such big project as OpenCascade to not have leaks at all. All non garbage collected languages have a potential problem with leaks.
My personal note is: if we use C# references and we avoid Handle_ classes usage, we will keep the leaks low. If we find a functionality that always leaks in OCC, we will try to avoid it, or if is not possible, we will use it, and submit a patch to OCC to be fixed in the next version. (as Mihai said)