SOLVESPACE -- parametric 2d/3d CAD

(you are viewing a thread; or go back to list of threads)

Coding group swapping (by Rune)
Hi Jonathan, I'm trying to code swapping of groups as a means of inserting a group into the list, but do not quite understand how Request, param and Entities are linked, could you please explain.
My idea is to swap the group id of group n and n+1, prototyped like

INT32 srcGrp = 3, dstGrp = 2,swapGrp=4 ; //Just for prototyping, should be selecable in some way
for (int i = 0; i < SK.request.n; i++){ // Loop Through requests
Request *r = &(SK.request.elem[i]); //Move old elements in destinations to a swap group
if (r->group.v == dstGrp){
r->group.v = swapGrp;
for (int i = 0; i < SK.request.n; i++){ // Loop Through requests
if (r->group.v == srcGrp) // Move source to destination
r->group.v = dstGrp;

} //Hereafter move swap to source group

SS.GenerateAll(0, INT_MAX);

The problem is that GenerateAll remove elements dstGrp, probably because it cannot find the params?

As far as I understand the drawing is consisting of requests which generates elements (right?). Could you please explain a bit about the link between Request and Param & Constraint?
Wed Dec 10 2014, 04:28:07
(no subject) (by Jonathan Westhues)
A Request is the thing that a user draws after choosing, for example, Sketch -> Line Segment. That request will generate one or more Entity objects. For example, that line segment will generate one line segment Entity object, and two point Entity objects. (Other things can generate Entity objects too, for example a parametric step and repeat, or an extrude, or an import.)

An Entity is a geometric thing, like a point, or a line segment, or a circle. An Entity is defined in terms of Param objects, and other Entity objects. For example, a point in 3d may be defined in terms of three Params, or a line segment may be defined in terms of two point-in-2d Entity objects, plus the workplane Entity.

A Param is a real number. The solver can manipulate those real numbers, in order to satisfy user-specified Constraints.

I suspect that to start, your Requests are all getting killed because their associated workplane is that of the original group, which doesn't yet exist because of the reordering. The code for that is in generate.cpp, SolveSpace::PruneRequest.
Wed Dec 10 2014, 05:35:07
(no subject) (by Rune)
Thanks, I thought it was ok because I also swapped the workplane. Got to understand better the workplane thing.
BTW, is there a reason why you don't have a MemFree(elem) before setting elem to NULL in:?

void MoveSelfInto(IdList<T,H> *l) {
(l, this, sizeof(*this));
elemsAllocated = n = 0;
elem = NULL;
Wed Dec 10 2014, 08:50:36
(no subject) (by Jonathan Westhues)
Do you mean around:

void MoveSelfInto(IdList<T,H> *l) {
memcpy(l, this, sizeof(*this));
elemsAllocated = n = 0;
elem = NULL;

? If yes, the copy still points to that memory; so that memory will be (and can be) freed only when the copy is cleared.
Thu Dec 11 2014, 10:11:06
(no subject) (by Rune)
In Clear(void) there is
if(elem) MemFree(elem);

But in void MoveSelfInto(IdList<T,H> *l)
it seems to me that the memory that 'elem' pointed to is left orphaned because I do not see where it gets reclaimed. (Just a thought).
Mon Dec 15 2014, 06:05:05
(no subject) (by Jonathan Westhues)
The copy (l->elem) still points to the memory. If you don't understand, then try adding the free and then running the program under a malloc debugger; you'll find that freed memory is accessed.
Mon Dec 15 2014, 13:38:11
(no subject) (by Rune)
Thanks now I see.
Mon Dec 15 2014, 13:47:52
Post a reply to this comment:
Your Name:
Your Email:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):
© 2008-2018 SolveSpace contributors. Most recent update Nov 22 2018.