Open GoogleCodeExporter opened 9 years ago
Tests:
1) Rectangle with with 4 CoincidentPointConstraints and save as
“test_1_4CoincidentPointConstraints.heeks”
2) With the same file open add a vertical and horizontal point constraint and
save as “test_2_4CoincidentPointConstraints_2AbsoluteAngleConstraints.heeks”
3) Exit heekscad and restart. Open
“test_2_4CoincidentPointConstraints_2AbsoluteAngleConstraints.heeks” and
save into
“test_3_4CoincidentPointConstraints_2AbsoluteAngleConstraints_resaved.heeks”
4)Exit heekscad and restart. Open
“test_1_4CoincidentPointConstraints.heeks” and save into
“test_4_4CoincidentPointConstraints_resaved.heeks”
Observations:
(Test 1) It appears that test_1_4CoincidentPointConstraints.heeks has saved
constraints correctly
(Test 2) Normal function occurs when “AbsoluteAngleConstraint” is added to
a open file and saved.
(Test 3) The file with 4 AbsoluteAngleConstraint and 4
CoincidantPointConstraint are not read in properly. It appears that the
AbsoluteAngleConstraint have not been read in properly.
I’m observing what appears to be a read file and a write file error. When a
file is opened, observed on the screen it appears that the
AbsoluteAngleConstraint have been lost but the CoincidantPointConstraint have
been read. What is exceeding curious when this file is save 3 of the 4
CoincidantPointConstraint are lost. My theory that on a fresh drawing
everything everything saves correctly but things get weird with and existing
drawing. It appears that there is a read bug and a write bug saving constraints.
(Test 4) In this test a open 4 lines constrained by the endpoints only. On the
screen it appears that everything reads in properly. The endpoints appear
constrained properly. When this datafile is saved 3 of the 4 point constraints
are lost.
Hypothesis:
It seems as if normal function occurs on new data drawing. It appears that
data is saving correctly at this point.
It appears that there are read and write errrors related to constraints on an
existing drawing.
I could be off on this but I looks as there are two error paths:
AbsoluteAngleConstraints are not being read
A counter error? is occuring when data comes from a existing file not all is
being read back.
Original comment by jonastho...@gmail.com
on 11 Sep 2010 at 2:04
Attachments:
Thanks for looking at this. I don't think I will be much help with it, though.
It was written by Jon Pry and he doesn't seem to have been around for quite a
few months. He was going to live in Grenada, last I heard. His gmail account
was hacked into, so don't trust emails that seem to be from him asking for
money!
I was getting an error myself, today, with saving constraints, after I did
"Combine Sketches" on a couple of sketches and tried to save the drawing.
Dan Heeks.
Original comment by danhe...@gmail.com
on 11 Sep 2010 at 4:22
How expensive is it to live in Grenada. Perhaps it's Jon impersonating
himself...
Anyway... I started to single stepping through the file trying to make sense of
what's going on here...
It struck me as weird that a coincident point would have a angle and a length
defined.
Also I manually stripped out my test 2 file with what I perceived as info that
wasn't required just to see what would happen. It seems to make sense to me
after all, For AbsoluteAngleConstraint you only have one object defined in the
constraint.
I got a general segmentation fault.
Original comment by jonastho...@gmail.com
on 11 Sep 2010 at 9:44
Attachments:
Dan,
Since the sketcher works setting the constraints, I tried making the file read
look like the sketcher.
My experiments failed, but I thought perhaps this might spur some ideas.
Anyway... Hear's what I tried to do.
http://www.metalshaperman.com/?p=332
Original comment by jonastho...@gmail.com
on 12 Sep 2010 at 12:47
Jon Pry on the IRC had mentioned that id's where not correct in the file.
I manually fixed that (test_6).. It didn't seem to make a difference loading
that up.
He also said that ">iirc absoluteangleconstraints are children of the line" (I
edited the file (test_7) based on what he said to see if that would load. I get
a segmentation fault when the file is opened up.
Original comment by jonastho...@gmail.com
on 12 Sep 2010 at 7:11
Attachments:
Both of these generated segmentation faults
Original comment by jonastho...@gmail.com
on 12 Sep 2010 at 7:54
Attachments:
Dan,
Jon suggested that I // the following lines (919-922 in HeeksCAD.cpp) the problems goes away:
// where operations are pointing to the same sketch, for example, make sure
that they are not duplicated sketches
for (std::list::iterator itObject = objects.begin(); itObject != objects.end();
itObject++)
{
*itObject = MergeCommonObjects( unique_set, *itObject );
}
Well... it gotten better. It seems that I can set/save horizontal/vertical
constraints now within heekscad but the thing still crashes if I try save a
CoincidantPointConstraint that I have created within heekscad. It seems if I
hardcode the .heeks file from gedit I can get it to load. So the bugs appear
to be in the saving process.
At this point, I'm pursuing my problem by hard-coding my constraints in. Jon
had created a utility function to display the Id's of the individual objects
(http://code.google.com/p/heekscad/source/detail?r=1286 ) but he didn't connect
it up to anything. (I'm trying to figure out how to do that, any suggestions
would be appreciated)
I not sure why Jon didn't commit this fix. He sent out an email:
"I've traced the problem back to mergecommonobjects(). I'm not sure what this
function is supposed to do. Repair bad files? Well, for whatever reason it is
toasting the object layout. Which eventually leads to constraints not being
able to be applied to the tree. Commenting it out solves the problem. "
Apparently, one one ever got back to him on this. I did a little googling and
it seems this bug may have been induced at this point.
http://code.google.com/p/heekscad/source/detail?r=1218 and
http://code.google.com/p/heekscad/source/detail?r=1220
I'm cross posting this issue in R1218 and R1220
Original comment by jonastho...@gmail.com
on 18 Sep 2010 at 2:08
Most problems with constraints saving seems to have stopped with R1289. I"m
still having a problem with Toggle Fixed constraint. A sketch with this
contraint crashes when your trying to save. Still trying to isolate what's
causing that.
Original comment by jonastho...@gmail.com
on 21 Sep 2010 at 2:12
The MergeCommonObjects routine looks for duplicate child objects in the tree of
objects being read in. It was added when we added the ability to have sketch
objects become children of machine operation objects. i.e. A single sketch
could be a child of two or more machine operation objects. When we read these
machine operation objects back in we want all the machine operation objects to
point to the same (shared) sketch objects. The decision as to whether an object
is merged with a pre-existing object is made based on the type/Id pair
Original comment by David.Ni...@gmail.com
on 22 Sep 2010 at 12:34
Can you have another look at this one. I'm hoping that my change to the
Constraints.cpp file fixed the original problem and that my re-introduction of
the MergeCommonObjects() call has not reverted other problems.
Original comment by David.Ni...@gmail.com
on 29 Sep 2010 at 12:34
R1293 re-introduces problems with constraints. I tested on a previously
functioning file. It appears that coincident points constraints loaded, but it
appears that all the horizontal/vertical constraints did not (expect for one)
I was going to post the file, but some it got saved (not sure how that
happened) and I think the constraints are damaged.
Original comment by jonastho...@gmail.com
on 30 Sep 2010 at 12:33
I tried it with a new file and it worked alright for me. I used horozontal,
vertical, perpendicular and coincident constraints. Of the two shapes in the
file, the top one is what I drew manually. The bottom one has had the
constraints added. If it reads in correctly this will be obvious but if it
doesn't I thought it might need some explanation.
Can you post your damaged file anyway? I am curious to look at the data.
Original comment by David.Ni...@gmail.com
on 30 Sep 2010 at 3:45
Attachments:
Attached it the damaged file per your request.
With R1289 I was getting consistent results with what you see posted here.
http://www.metalshaperman.com/?p=343
As a control, I loaded up your file and took a screen shot here.
http://www.metalshaperman.com/?p=396
As you can tell, I'm slowly trying to figure this stuff out.
(I haven't test this yet, prior to R1293 I was getting a crash when I was
trying to save a fixed point constraint. Are you getting that also... My
suspicion is that it's a different critter at work.
If it would be a help, I suppose I can figure out how to roll back to R1289
re-create the contraints, save and repost.
Let me know,
JT.
Original comment by jonastho...@gmail.com
on 1 Oct 2010 at 1:57
Attachments:
I am starting to agree that the MergeCommonObjects() routine is the flaw in the
constraints stuff right now but I am eager to resolve it without removing the
call altogether. We need the MergeCommonObjects() routine if we're going to
share common sketch objects with more than one machining operation object.
When an object is read into memory via the ReadFromXMLElement() methods, it
creates a new copy of the object in memory. eg: 'CFixture *new_object = new
CFixture(.....)'. This is fine if the XML in the data file only refers to this
object (type/id pair) once. If this object is a child of two machine objects
then the ReadFromXMLElement() routine will be called once for each child
resulting in two separate copies of the object in memory. This means that,
where the XML data had two parents both referring to a single child, we now
have separate children for each parent. If we modify one child, the other one
doesn't change. It also means that we have two HeeksObj pointers assigned to
the same ID.
The MergeCommonObjects() routine takes a tree of HeeksObj pointers and keeps a
list of pointers to object it has seen before. If a duplicate child is found
(by type/id pair) then the previously seen pointer is used and the duplicate
pointer is removed.
The constraints are held within a std::vector<HeeksObj *>. The
MergeCommonObjects() routine does not do this pointer removal process for these
lists. Further, as a constraint object is being read into memory, it is
looking up object pointer references from the global pointer cache
(GetIDObject()). This pointer is not being repaired if a duplicate pointer is
returned form the global cache.
I think the fix is to update the various constraint pointer lists when a
duplicate child is detected. I'm just not sure how to do this yet.
The only other option is to revert the way we store graphical objects as
children of machine operation objects. We used to store references to
graphical objects by retaining the type/id pairs but I changed this to pointers
to children instead (i.e. I changed the COp class to be based on ObjList rather
than on HeeksObj).
Sorry to muddy the waters but I think this is where the problem lays. I just
haven't come up with a solution to it yet.
Original comment by David.Ni...@gmail.com
on 2 Oct 2010 at 3:21
I should also have added;
In my ideal world, we would have very clear 'roots' of all HeeksObj pointer
trees. At the moment we keep a global cache of type/id pairs and their
corresponding HeeksObj pointers. i.e. we have one global tree of elements.
This works well if we're just drawing but, if we are importing 'extra' elements
from another HeeksCAD data file then there is confusion between the type/id
pairs already in memory and those that are currently being imported. This is
where the MergeCommonObjects() routine was born. I was trying to detect and
remove duplicate HeeksObj pointers from within the tree of files being read as
opposed to those that are already in memory.
All this would have been easier if we added a static pointer to the root of a
list of HeeksObj pointers. By default they would inherit from whatever parent
created them. It would also, however, allow a separate set of objects to be
held aside from the main set during an import. When they were merged with the
main list, their id values could be adjusted accordingly. It also means that
references to other objects (as is done for both constraints and children of
machine operations), we could look in the 'local' tree for HeeksObj pointer
references rather than a single global tree.
Again, I'm just 'typing out loud' here.
Original comment by David.Ni...@gmail.com
on 2 Oct 2010 at 3:28
Ok... I disabled the call to mergecommonobjects so I was able to save my
ultimate contraints file. This basically would be a pop-up box mounted
diagonally on the fold line of a card.
I have 3 horizontal lines that are meant to be streched to resize the box.
the 4'th is fixed length to have a consistent.
I needed a 45 degree angle, that's what the triangle is all about.
If mergecommonobjects is enabled, it totally hoses up the constraints.
If setfixedpoint is set.. It works as long as I don't save. If I save it
crashes heeks.
@ David on the fixed points ???
@ JonPry and you look at that setfixedpoint constraint.
Original comment by jonastho...@gmail.com
on 2 Oct 2010 at 4:26
Attachments:
The prior file may have been damaged. I had inadvertently dragged a line to
point and then deleted it. The suspicion is that undo/redo is causing some
problems.
The following file was generated with:
mergecommonobjects disabled
//#define USE_UNDO_ENGINE commented out
So far as I can tell it save,loads and performs as intended. This test a lot
of constraints but not all of them. This project didn't utilize any arcs or arc
constraints.
Original comment by jonastho...@gmail.com
on 3 Oct 2010 at 1:16
Attachments:
Ok... I should also mention to document there was a secondary issue with
setfixedpointcontraint.
Jonpry snuffed that critter out with R1303 AngleBoxAllContraints was the first
time that I was able to save/load a fixed point constraint.
Thanks,
Jon
Original comment by jonastho...@gmail.com
on 3 Oct 2010 at 1:26
Jonas,
I forgot to add a comment to this issue. Can you fetch the source and give this a go now? If you're reading a file into Heeks it should work alright now. If you're importing a file into an existing set of data then we're still out of luck.
Ta
David Nicholls
Original comment by David.Ni...@gmail.com
on 5 Oct 2010 at 12:59
Original issue reported on code.google.com by
jonastho...@gmail.com
on 10 Sep 2010 at 12:10