On Mon, 2008-01-14 at 17:47 +0000, a r wrote:
> On Jan 13, 2008 6:33 PM, Peter Clifton <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, 2008-01-13 at 03:30 +0000, Peter Clifton wrote:
> >
> > > > Program received signal SIGSEGV, Segmentation fault.
> > >
> > > The backtrace there is the same as I get eventually under gdb. I'll have
> > > a dig back in the history with git and see how far back the bug is
> > > reproducible.
> >
> > I have a fix for this, but won't push it immediately until I've had some
> > free time to really dig in and make sure its correct.
>
> Can you post it to me? I want to look into consolidation and net
> movement code and fix it a bit.
Of course...
diff --git a/gschem/src/o_net.c b/gschem/src/o_net.c
index 7adca6b..d388d13 100644
--- a/gschem/src/o_net.c
+++ b/gschem/src/o_net.c
@@ -460,6 +460,10 @@ int o_net_end(GSCHEM_TOPLEVEL *w_current, int x, int y)
toplevel->page_current->object_tail,
OBJ_NET, color, x2, y2, x3, y3);
+#warning HACK, OR RIGHT FIX?
+ g_list_free(other_objects);
+ other_objects = NULL;
+
/* conn stuff */
/* LEAK CHECK 2 */
other_objects = s_conn_return_others(other_objects,
I honestly haven't had time to check the implications of this though..,
so I'd appreciate it if no one pushes the "fix" yet.
> Returning to my patch, you've probably noticed that it is iterating
> over all the schematics components (including symbol contents). This
> is going to be inefficient for large schematics. Is there any function
> that takes (x, y) coordinates, an object type and returns all the
> objects of that type overlapping the specified point?
No, but it could be a good one to write.. it could be refactored out of
the "find" code.
Specifically, a few cases which might be useful to have API for..
Find objects which are _completely_ within a rectangle,
Find objects which have _any_ point within a rectangle,
Find which objects _contain_ a given x, y point.
Currently we don't have any spatial data-structure to make this fast and
efficient. I need to write something like that for the cairo rendering
support though.
There is no harm (only benefits!) in refactoring out the current
inefficient code in gschem, and for this patch, into some functions.
> If so, it would
> be fairly straightforward to modify my patch to make use of it. And,
> once a spatial index is developed, it would be easy replace the
> function with one that uses the index instead of going through all the
> objects.
As you say.. when we get r-tree (or some other spatial data-structure)
support, the savings can be gained immediately.
This is something I'm keen to do once 1.4.0 is out the door, and 1.5.0
development starts. I got paused on it though, as much of the cairo work
can be done without it.. and I wasn't sure yet if I could / should
re-use PCB's implementation, or base it on API similar to GTree.
Unfortunately, GTree is just balanced binary trees.. it doesn't provide
a generic tree management we can extend.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
