Extrude work (2)

Made the Extrude work with clicks, fixed the problem that the Extrude remained set when changing to another tool, fixed the problem that the drawn Extrude was disappearing, made several other small fixes and code improvement (like reducing the number of function calls). Changed also the extrude drawing: the realtime drawing is made as a temporary shape used only for displaying and when the extrusion is finished the final shape is saved in the data tree for storage and undo reference.

Tomorrow will continue with fixing the other tools (zoom, rotate, pan) in parallel with working at making Extrude from the face of Extrude. There are also some crashes that need to be solved.

Extrude work

Reviewed the Extrude, ExtrudeFunction, ExtrudeDependency, FacePickerPlane classes.

Improved the FacePickerPlane code so that it doesn't inform the user about the selected plane at every mouse move. It informs only when a new plane is selected. The highlighting disappears when the mouse goes out of the selected plane. Didn't solve the flickering caused by the change to Neutral Point to Local Context, studied and understood the problem will find a solution later.

Will continue with making an Extrude on the face of another Extrude.

Iteration 0.0.10

The tasks proposed for the Iteration 0.0.10 that will close on May 10:

- review the code written at the Data Tree and at the 3D drawing,estimated to take 2-3 hours (task already finished),
- make the Extrude work (some of the subtasks: improve the face picker, the drawn Extrude disappears - needs to be solved, make the Extrude work with clicks instead of drags, Extrude remains active when changing to another tool, enable extruding the face of an extrude, don't register the intermediary Extrude shapes in the Data Tree until it is finished), task estimated to take 3-4 days of work,
- make the Fillet work (Fillet should be drawn using a fixed radius that will be changed from the Property dialog, solve the Fillet bugs from the Property dialog), task estimated to take 2 days,
- cancel the current selected action and switch to ActionNone using the Cancel button, estimated to take 0.5 hours,
- Implement test codes at the Sketcher (make tests for 2D shapes, test 2D drawing, try to test the edit mode), task estimated to take 6 hours,
- Add functionality to draw a 2d rectangle in the 3d space, estimated to take 1 day.

Code review, prepare new iteration

Worked at reviewing the DataTree code: looked at Dependencies, Interpreters, their usage in drawing operations.

Started studying the data tree visualization and the implementation of Extrude. Will continue with working at making the Extrude work with clicks, add the possibility to extrude the faces of another extrude, solve some the current bugs related to Extrude (the Extrude doesn't disable properly after choosing another tool, the Extrude drawing needs improvements, the tree list is not updated properly).

Made a list with the tasks to be implemented in the iteration that started yesterday (Iteration 0.0.10). Tomorrow, after more refining will post the tasks with their estimation.

Environment issues detector

Do you remember the Bug Reporter Application?

It was extended to check right now the runtime of NaroCAD is good or not.

NaroCAD have mostly three problems which are related to not be able to start:
- it does not have .Net 3.5 (SP1) installed. This is rarely happen as who read on blog or look on source code see that is related with .NET or with C# have already installed. If you use Windows 7 Beta, you will have it also installed. So no problems so far.
- it does not download OpenCascade, the 3D CAD framework written in C++ that is used for modelling and visualization by NaroCAD. NaroCAD is built on top of OpenCascade.
- it does not have Visual C++ 2008 Redistributable Runtime SP1 on your machine.

Using the Microsoft way about how to detect if Visual C++ Runtime is or is not installed seems to fail at least on my machine. So I check that either the MS way to verify the runtime. If it fails, it tries back to check a Visual C++ Express install (that installs by itself the Runtime without reporting as such). Also, you can run NaroCAD by copying all OpenCascade dlls without installing it, which brings that NaroCAD will fail to detect the OpenCascade installation.

Because this detection appears to not be infallible in real life (does anyone have another solutions?) you will have an ignore button. You will also have a checkbox that say: "Don't show next time this dialog" but users will do it by themselves. (doesn't appear in the screenshot but it will exist in the end)

Undo/Redo works on the refactored tree format

NaroCAD has a working Undo/Redo document interface. To keep all things’ memory efficient, the undo/redo algorithm keeps only the diff (the difference between two states).

A bit problematic in the implementation was the twist that the tree storage was keeping raw pointers which made computing a diff between two points impossible to be done. So the AttributeInterpreters code has right now serialize/deserialize methods. The serialization code is greatly simplified for both read/write.

This fix initially was done using TDD (presented two days before) so not only the Undo/Redo works, but also the OCAF is tested like tree implementation, diff computation and updates.

There is for now not implemented serialization of only one AttributeInterpreter (to be more precise: the reference node) which I will finish very soon (tomorrow!?). Also, there is a complete XML serialization of document representation. I would like to complete a XML deserialization code (means loading/open the file to create a scene).

Note: From Thursday I will be away for vacation for 12 days. If I finish loading/saving file till Monday I will return to complete the Extrude which stands in buggy selection mechanism (if bxtrx will not do it for me ;) )

Finished the edit mode

Finished the edit mode flow at the Sketcher. After the shapes are drawn, if the "Selection cursor" icon is chosen, when clicking on a shape it enters in edit mode which allows the user to change the shape by dragging its markers. Added also code that updates the Solver magic points after shapes are modified.

Will continue with making a test framework for the visual functionality and in parallel will also verify the Sketcher functionality. The ellipse in edit mode needs improvements as it crashes when radius is close to 0. Will also have to think how the tree view will be updated with the newly created 2d shapes and which from their 3d properties will be displayed.

Test Driven Development, how to?

In software there are a lot of methodologies but really few reduce greatly the time of development or simplify it.

Most programmers probably know, but even if you don't know, is good to notice: great bulk of time in development of a software is bug fixing and maintainance. They can take from 55% in most lucky projects, to around 95%. The development time in bug fixing relies mostly on how much you invest in them also. So, having 95% of time means that this software product focuses on bug fixing greatly. Consider, for example, a real-time device programming or an air traffic control software. The platform needs to be stable in years or having minimal downtime.

In desktop programming around 75% of time is bug fixing. Why does software spend between two thirds to three quarters doing bug fixing instead adding features? Developers are humans and they can keep only some ideas in parallel, but they have to focus to memory management, performance, writing useful codes, interaction between components, specifications, etc. This will overwhelm really easy even the best developer.

Test Driven Development (TDD) is a software methodology created to reduce the time of staying in bug fixing. The best qualities of it are:

- detect bugs as early as possible
- have at least for your batteries of tests in place of their inputs, to provide the expected output
- make the code to feedback developer before a QA or in a much worse way, a user to notice.

What is the best way to do TDD?

- because it is test driven, you should write tests first, before your code. Or if the code exists, make tests to reflect the interface (without knowing the implementation is better).
- makes your tests pass with minimal code
- refactors your code to be as good as you want but doesn't break the tests

NaroCAD uses nUnit framework to do unit tests which are small programs that define a battery of tests.

Here is a test that checks in NaroCAD if one document has a right working Undo function:

using System;
using NUnit.Framework;
using TreeData.AttributeInterpreter;
using TreeData.NaroData;

namespace NaroTestSuite.TreeData
{
[TestFixture]
public class UndoRedoTests
{
[Test]
public void UndoAppliedEmpty()
{
DefaultInterpreters.Setup();
Document doc = new Document();
Assert.AreEqual(0, doc.Root.Interpreters.Count);
doc.Transact();
doc.Root.Update<IntegerInterpreter>().Value = 2;
Assert.AreEqual(1, doc.Root.Interpreters.Count);
doc.Commit();
Assert.AreEqual(1, doc.Root.Interpreters.Count,);
doc.Undo();
Assert.AreEqual(0, doc.Root.Interpreters.Count,);
}
}
}

How to easily write a test in NaroCAD codebase?
Check the feature you want to make working.

Define your expectancies (or assertions). Here are the normal expectations for a class that store a document in a doc.Root tree data.

- a newly created document is an empty one and an empty document will have no attributes (or interpreters)
- after I will try to save the status of the document (after a "transact") the document should not change the attribute count

- after I will add an integer attribute the attribute count should increase with 1
- after I do an Undo, the document will decrease to original document count, so it will be zero.

Also, making tests first will make a very important thing for developer, it will give to it concrete cases how the tested classes are used and this will mean a real feedback. Also, using a tested class and if the specified have the tests passed will mean that the problem is from another part of application or how the developer relationate with the class. This will remove a lot of assumptions about what breaks and why.

A great thing also is that tests are often much smaller than the entire application. So debugging it will reduce to debugging of the latest usage of the document, is not the entire NaroCAD that may not work with Undo function.

How about regression testing?
Regression Testing (RT) is almost the same as TDD but when application crashes (for instance to an user), there is a test written "to not happen again". RT has some downsides:

- the developer (or QA) who writes the test can get the application architecture. This may mean that we can create a test to pass our code, instead our code to pass our tests

- in development time, there are no tests to check if a component is working (excluding the developer will debug the program again and again)
Should you use RT? Yes, definetly! RT appears in ways that application you have never expected to crash or to run, does so, and where you don't want it. Also, the user bugs are great to be tracked. A flawed component will most probably crash again. There is a QA 80/20 theory which says: 80% of errors are in 20% of code. TDD will say that for your cases your code will work correctly. But still there are your tests, which may not reflect the real life cases.

As in our example: who creates a single document to store only one integer in it?

Shape edit mode (2)

Succeeded to make the edit mode flow work at the Sketcher. The shapes can be selected, edited and after that, unselected. It remained to solve one bug: the last shape drawn is not editable. For example if there are three lines drawn the first two can be edited the last can't. Another improvement that needs to be added is that after one shape is modified the Solver needs to be informed about the new position of the magic points.
Worked also at improving the ellipse drawing. The drawing goes realtime, many of the bugs/crashes were removed.

Will continue working at finishing the edit mode and after that will start making some test code for it.

Bug hunting (part 2)

- I had make Naro to not crash on ellipse (basic code) to close the bug I had do to test the bug submitter. bxtrx starts a lot of things after like doing real time... but is better for him to say them!
- Undo/Redo is a big non working component. The cause of it is that we had to make a tradeoff between performance and stored data. For this, the attributes attached to a node were not written as serialize data. As a side effect it brokes the undo/redo algorithm. Reviewing the node data, I found that was a bit over-engineer because it was wanted to get everything in a node and the code will be a bit simplified also.

So I prioritize higher the undo/redo bugs (and the things underneath) because I will have soon a break and I don't want to let things broken. Also, solving the bugs of Undo/Redo will mean that NaroCAD may be able to dump the scene to a file and from it to restore the whole scene.

The selection bug in Extrude is postponed because it is needed a new feature or a new design. As is right now there was some assumption on extrude, and they were that the shape is selected is a face. But you may want to select a face from a shape and there is no dirrect representation to it. A solution is to define a new shape that is generated from an older shape and a face index (to locate the face will be on extrude).

As it is related with the OCAF tree underneath, I moved to Undo/Redo which is the same infrastructure, to be bullet-proof and after that will be sure that we can work on Extrude to close the selection bug.

Shape edit mode

Still working at implementing the edit mode at the Sketcher. The code is mainly finished but there are problems to be fixed at the usage flow. There is also an old bug that needs to be solved: the last shape drawn is not editable.

Bug hunting...

There are some bug fixed in the last time:
- glitch free rotate and action for rotate asks mouse-down to perform it
- extrude works in 1 click to pick the face and you can drop
- after extrude the current extrude is selected in tree and in properties view for easy change

The current extrude have some issues not because of extrude code but because of selection code bugs. I will work to track them down.
All other 3D actions that change the scene will be selected in tree that expose the shape to you, after you create them for making your usage easier.

United pipe for plane and 3d point picking

Eventually the Line in 3D is defined in two clicks and not by three. First click will pick both the plane is drawn to and the point in 3D. The second will be drawn on the same plane. This was done by unifying two pipes in one picking plane and 3D point. Also, it gets notification when to stop the plane searching and also it can get reset.

This can make things easier in 3D to pick the center on a shape without any other user intervention. as is natural that it is intended to make the work on that face.

So in the past there was a graph that Line3D require 2 inputs: a PlanePicking and a Mouse3D coordinate. The downside was that Line3D was need to manage the relations. Unifying them in one common pipe makes the code a bit more clearer and also the Line3D skip managing the relations and to help managing both. The PlanePicking can be queried to get the plane you are in... so it may make things in the same way as having individual PlanePicking and Mouse3D.

Also, it makes possible to not make a bit of order of events housekeeping as the pipe will make clean what means the click (only a 3D coordinate for the plane under the mouse).

Reporting crashes automatically... (part II)

After some string conversions and after a lot of workarounds NaroCAD crash application will give as a bug report the application log. In the past the description text appear to end with invalid characters. This issue is also fixed.

Here is an working reported bug:
https://sourceforge.net/tracker/?func=detail&aid=2771029&group_id=198020&atid=963798

The most important remaining event changes are also logged:
- mouse clicks (mouse up and down)
- the shape generation code
- action changed (switching between draw line, zoom, etc.) making it easy to read the events that makes the crash to happen

For saving time and space, the log is compressed to zip. Also, after submitting the log file, the log is deleted so it will not give wrong guidance for the person that reads the log.

Note: if you are an user and you want to test NaroCAD, you should run NaroStarter which manages the start application, submit crash reporting and restart application for you. If you are a developer you should run NaroCAD application to be able to attach the debugger to the right application.

I will try today to complete the last bits of the line in 3D to work with the pipe attached to it.

Reporting crashes automatically...

NaroCAD can have multiple causes of crashing like invalid inputs, external code (C++ OpenCascade code).

To make error reporting better, it was considered to make an automatically reporting application which would be user friendly and easy to be used.

The decision was that application should be outside the NaroCAD application because some crashes (mostly in OpenCascade part) will bring down .NET virtual machine. Also some crashes may be external (like not enough disk space, or your machine was going to shut down and there is no proper code to handle this, etc.).


The reporting application tries to get as much information about crash as possible. Some data are still not checked, like: not enough disk space, etc. Also, the internal logging of NaroCAD is archived easier to be sent. The bug reports are created automatically to SourceForge NaroCAD page with almost no user intervention.

A submitted bug can be found here.

This reporting tool will also offer the possibility to restart NaroCAD if the user wants that.

Special thanks to my twin brother about making the web code working and for coding this part much easier.

Edit mode

Worked at porting the edit mode code at the Sketcher. Succeeded to make the edit mode work for one selected shape. Will continue with making it work properly (2-3 more hours estimated to finish the task) and after that will start checking the usability use case document and make all the cases work properly.

Tasks for this week

The tasks proposed to be finished on this week are:

- make an automatic bug reporting mechanism and also improve the user activity logging so that proper reports are generated, progress 50%,
- refine and finalize the code to implement the use case document that specifies how the application is used (this task also includes enabling the edit mode for the drawn shapes at least at the Sketcher), progress 50-70%,
- start making unit testing, prepare an OpenCascade like environment where the tests will run, progress 20-30%,
- at 3D line drawing finish making the unified pipe used for drawing the line, progress 50%.

Stabilizing work

Added logging to the Sketcher and 3D drawing so that all the mouse generated events are logged; useful for investigating crashing situations.
Implemented at the Sketcher drawing a filtering mechanism that detects coincident points. This solved some of the crashes that were appearing due to clicks on the same spot.
Solved the magic point drawing flickering. Now the magic points are drawn properly.

Will continue with enabling the edit mode at the Sketcher and also start making unit tests.

Magic points

Enabled for the Sketcher the detection and display of magic points. The magic points drawing needs further improvements as it flickers due to too much redrawing. Will continue with finishing the magic point drawing and enabling the edit mode. In parallel will add a logging mechanism to start detecting and fixing the crashes that appear during drawing.

FXCop experiences

What is FxCop? FxCop is a static analysis tool, written by Microsoft to inspect if some classes of mistakes may behave wrong in your application. They use IL intermediate assembly code representation and report regardless of .NET language.

Most of principles are really right to follow like: if you setup a default to a variable to zero in one class, you will get notified by FxCop that is not needed.

What went wrong:
Polluting the warning box with a lot of errors that do not really fit, like:
- a namespace has too few classes in it, so unify it with other namespaces. Namespace is an important issue of C# as it cleans the language and naming. C# IDE-s, like Visual C#, SharpDevelop and MonoDevelop, creates namespaces based on the project root namespace and on your folders. So for cleaning reasons you may keep some classes out of context in other folders. I had no idea if I had a class namely Feature which creates some OpenCascade shapes (like Fillet and Extrude) to unify namespace with other classes
- using NaroCAD complains about CAD that is not properly spelled. If you look to XmlDocument is clear why: CAD contains only capitals . Changing in NaroCad makes it complain that you probably have hungarian notation. I had changed to Naro, and I remain with this error: Correct the spelling of 'Naro' in namespace name 'Naro.PartModeling.Modifiers'. (CA1704). My question is: how should everything be spelled?

- Circular errors: Set methods are purposed to be made as properties (seems to fit natural as properties have get and set "methods"). Making a write-only property it will complain that you did not make it a read property

This makes the whole replacement and warning to be a hunt around errors you want to fix and try to ignore the errors which are really not there.

Anyway, the most important small design problems are now fixed. It touches almost every file of the project, excluding to make NaroCad build on signed assemblies, which imparts pretty random behavior and not using internationalization (a stronger complaint of FxCop), which in case of using it makes it impossible to find resources and to complain that all other assemblies are impossible to be loaded cause they are not marked with NeutralCulture attribute. (see here some details)

This was reported by Gendarme (I had used it for the most important errors at least) and the message was: Parent use the old not notation, try to change in Parenot.

Gendarme reports more errors, but the good thing is: every error has a confidence degree. Another good thing is that it found similar methods and warns you against copy/paste programming.
The bad thing is the same of FxCop problem: it really throws you a lot of problems (with a good degree with Confidence: Low) that are not there.

Which should you use? If you use Visual C# Express, use Gendarme, because FxCop is not integrated with C# Express, and Gendarme's output is good enough (a web page made by categories). If you use SharpDevelop, use FxCop as is an integrated part of error reporting, so most warnings can be located with one click. Visual Studio 2008 professional has FxCop included in it, so you will have to check your project "metrics" to see its problems.

Considering that most (important) small issues are fixed, I will go back to Naro... CAD to fix other logic issues and bug fixes.

Spatial lines...

Does it look as a satellite? The Line in 3D works right now like follows: pick the plane you want and after that you work on it. So is easy to create in future shapes on faces. I will track down the bugs and try to see if there are any other issues.

Geometric solver at the Sketcher

Finished integrating the solver and magic point drawing in the newly ported Sketcher code, stabilized the ported 2d actions to work properly. Remained to enable also the edit mode.

Plane picking works, but the actions related did not...

Plane picking seems working, but the action that works from it did not work as well. There are still some issues I am going to address like: plane picking should freeze after first click. It should do but it does not. Till today in afternoon the plane picking works really bad as it does remove the faces, but with help of bxtrx again, it works!

The code is there, but fixes are still pending.

Hopefully I will fix it very soon all line3D action to work regardless of plane picking and to port other actions.

After that I am gonna focus to the new iteration tasks. If I will not have a very clean plan for next iteration I will increase the quality of NaroCAD code by fixing the most important issues found by FxCop or Mono's Gendarme.

Closed Iteration 0.0.9

On the current iteration implemented the following tasks:

- unified the 2d and 3d actions and refactored the code to use pipes and filters,
- finished rebuilding the tree view logic to display references as child nodes,
- finished applying on the tree view the model tree changes,
- finished propagating tree modifications (parametric modeling for the new data tree),
- ported Action2D to work with multi click instead of dragging, also ported the code to pipes and filters,
- partially ported Action3D to work with multi click instead of dragging, task implemented 50%,
- extracted 2D actions drawing code to work in 3D (ex: drawing a line in 3D), task implemented 70%,
- added code that displays magic geometry calculated by a solver,
- stabilized code, solved bugs at the document model,
- added code that allows editing the drawn shape, after porting to pipes and filters there is more work needed to be done to enable this functionality, task made 50%,

Among the tasks that will be scheduled for the next iteration are:
- finish drawing 2d shapes in the 3d space,
- improve the extrude,
- finish action 3d with multi click,
- finish the edit mode at the Sketcher,
- make the geometric solver to work with the data tree.

Sketcher actions porting

Finished porting the Sketche actions, started uploading the code on SVN. Will continue with stabilizing the code and make everything work properly.

Planes, and problems

It seem for me much easy to refactor the code than to work with OpenCascade.

I had felt a bit blocked till yesterday when I've clean up the use cases of 3D plane picking and to see dependencies. Drawing in 3D was done in past considering one single plane (like drawing Line3D it will happen in XOY for now only). The code wants to be more dynamically but still was some small issues like: when to stop picking a plane in a sequence of multi clicks. So when an action will not need the plane to change, it will notify the controller. The controller will be responsible to not change after that the plane. The solution is both elegant and simple and was done with help of bxtrx, so kudos for him!

Stay tuned for see how it works!

Sketcher actions porting

Unified most of the Sketcher actions to use pipes and filters, moved the common files into the interface library. Still working at modifying the Sketcher controller to use these actions and after that will have to stabilize the code. Hope to finish it in half a day of work.

Sketcher actions

Worked at porting half of the 2d actions to the pipes and filters concept. Estimating that in one more day of work the Sketcher related tasks will be finished and after that will continue with helping stabilize the code.