[GRASS5] Re: v.out.e00

[Eric G. Miller]

On Mon, 17 Dec 2001 10:29:00 +0100, Markus Neteler <neteler at itc.it> wrote:

> Hi Gordon,
> 
> (I cc this to "grass5" to get the other informed)
> 
> On Fri, Dec 14, 2001 at 12:14:30PM -0700, gordon.haverland at gov.ab.ca wrote:
> > 
> > Hello Markus,
> >   Well, I've been working on v.out.e00 for about a week now, and I think I
> > need a day or so to think about things.
> > 
> >   Yes, there are some bugs in the existing code.  In fact, I am pretty
> > sure that the code submitted never ran on any architecture (let alone this
> > Intel Linux machine). However, there is something else going on with the
> > code that I am having problems tracking down.
> > 
> >   In the code before the "calculation" of the Universe polygon, is a
> > branch of code which builds the doubly linked list which is searched to
> > build the polygon and also has: if( map.Link[i].left < 0 ) {
> >   map.Link[i].left = 1;
> > } else {
> >   map.Link[i].left += 1;
> > }
> > and similar for right.  I've tried 4 or 5 variations on writing that chunk
> > of code dealing with the renumbering of map.Link[i].(right|left) now.  If
> > I put fprintf(stderr,"...") statements before and after that code, I get
> > the similar result as if I have no fprintf()s there.  That is, the if left
> > is less than 0, that left is multiplied by -1. Sometimes right gets set to
> > 1 and sometimes it is left alone.  However, if I put fprintf()s between
> > the right and left chunks of code, now it renumbers left and right
> > correctly.  Which seems to me to be a compiler bug. However, it may be a
> > problem with the vector library, because almost every line read from a
> > grass vector file comes out with lines which consist of a single node
> > pointing to itself (N1 almost always equals N2).

  I'm not sure how v.out.e00 is written, but if you're talking about negative
numbers for area edge lines, then it means the line should be traversed in
reverse order.  I'm not sure what you mean about each line having a single
node.  That might be the case if your reading areas via Vect_get_area_points(),
but that is probably not the correct way to construct an E00 file, since
edges will get duplicated.

> > It would be a LOT easier to follow what is going on, if I could do this
> > debugging inside emacs with gdb, instead of using a zillion fprintf
> > statements.  Do you know how I can arrange to run GRASS binaries inside
> > GDB?  Do I have to compile all of grass with
> > -ggdb?
> > 
> > Have a great weekend!
> > Gordon Haverland
> 
> Please have a look at
> documents/debugging.txt
> in the source code. It tells you how to debug with GDB. I assume that
> you have been trying to debug
> $GISBASE/bin/module
> which is only a hard-link to front-end. The real binary which is
> happily accepted by a debugger lives in
> $GISBASE/etc/bin/cmd/module
> 
> Of course "-g" is required (and no "-s").

If documents/debugging.txt doesn't help, let me know... The trick is to
compile the module without the "-s" flag and probably without any
optimizations as well.  Then run the debugger from a terminal where a
GRASS session is running (to get the environment).  Works fine...

-- 
Eric G. Miller <egm2 at jps.net>