Markus Neteler wrote:
Hi Markus,
On Sun, Feb 22, 2009 at 1:56 PM, Markus Metz
wrote:
This segfault in the rtree lib doesn't happen often, and I don't
know if I should submit that patch also to develbranch_6 and
releasebranch_6_4. For now I have submitted to trunk only.
I'd suggest
Hi Markus,
On Sun, Feb 22, 2009 at 1:56 PM, Markus Metz
wrote:
> This segfault in the rtree lib doesn't happen often, and I don't
> know if I should submit that patch also to develbranch_6 and
> releasebranch_6_4. For now I have submitted to trunk only.
I'd suggest to also submit it to develbra
Glynn Clements wrote:
Markus Metz wrote:
It seems to work, at least I got past the segfault when breaking
polygons, but I still have to check spatial index dumps.
diff spidx.dump.orig spidx.dump.patched >spidx.diff
gives me an empty spidx.diff, patched spatial index is identical to
Markus Metz wrote:
> > It seems to work, at least I got past the segfault when breaking
> > polygons, but I still have to check spatial index dumps.
>
> diff spidx.dump.orig spidx.dump.patched >spidx.diff
> gives me an empty spidx.diff, patched spatial index is identical to
> original spatial
On 21/02/09 10:09, Markus Metz wrote:
Markus Metz wrote:
Markus Metz wrote:
It seems to work, at least I got past the segfault when breaking
polygons, but I still have to check spatial index dumps.
diff spidx.dump.orig spidx.dump.patched >spidx.diff
gives me an empty spidx.diff, patched spat
Markus Metz wrote:
Markus Metz wrote:
It seems to work, at least I got past the segfault when breaking
polygons, but I still have to check spatial index dumps.
diff spidx.dump.orig spidx.dump.patched >spidx.diff
gives me an empty spidx.diff, patched spatial index is identical to
original spa
Markus Metz wrote:
It seems to work, at least I got past the segfault when breaking
polygons, but I still have to check spatial index dumps.
diff spidx.dump.orig spidx.dump.patched >spidx.diff
gives me an empty spidx.diff, patched spatial index is identical to
original spatial index
Waiting
Sorry for the cut'n paste error.
Markus Metz wrote:
[...]
compatibility wrapper:
int RTreeDeleteRect(struct Rect *R, int Tid, struct Node **Root, int
Level)
{
assert(level == 0); /* I like that, external callers should never ever
delete an internal rectangle */
return RTreeDeleteRect1(R, (s
Glynn Clements wrote:
[...]
External callers aren't a problem, as they only ever call
RTreeInsertRect() with level == 0. It's only when RTreeDeleteRect()
uses it to re-insert internal nodes that the truncation can arise.
I'm pretty sure that this caused the segfault.
BTW, external callers
Markus Metz wrote:
> >> That thing branch[i].child is a pointer to the next node in the tree, if
> >> I understand the code correctly.
> >>
> >
> > It's either a pointer to the child or, at the lowest level (where
> > there are no children), an integer ("tid").
>
> Hmmm. What when RTreeIns
Glynn Clements wrote:
Markus Metz wrote:
That thing branch[i].child is a pointer to the next node in the tree, if
I understand the code correctly.
It's either a pointer to the child or, at the lowest level (where
there are no children), an integer ("tid").
Hmmm. What when RTreeIns
Markus Metz wrote:
> >> I understand the concept of RTrees better than this code, but I suspect
> >> that at line 119, line number is used as memory address for a pointer
> >> and at line 285, the memory address of a pointer is used as line number.
> >> Can you developer cracks confirm that?
>
Glynn Clements wrote:
Markus Metz wrote:
I suspect the bugs in rtree to be in index.c at line 119
b.child = (struct Node *)tid;
b.child is a pointer to the next node in the RTree. tid is the line
number for which a new bounding box will be inserted in the RTree. This
is a cast from intege
Markus Metz wrote:
> I suspect the bugs in rtree to be in index.c at line 119
> b.child = (struct Node *)tid;
> b.child is a pointer to the next node in the RTree. tid is the line
> number for which a new bounding box will be inserted in the RTree. This
> is a cast from integer to pointer, givi
Moritz Lennert wrote:
On 15/02/09 11:14, Markus Metz wrote:
Can you developer cracks confirm that?
I am not in this category at all... So, sorry, but this will have to
be between Glynn and you.
OK, let's hope for Glynn's comments.
What should I do now? Submit a patch to trac or commit to
On 15/02/09 11:14, Markus Metz wrote:
Can you developer cracks confirm that?
I am not in this category at all... So, sorry, but this will have to be
between Glynn and you.
What should I do now? Submit a patch to trac or commit to trunk or leave
it open for discussion?
I don't think anyon
Moritz Lennert wrote:
On 11/02/09 12:54, Markus Metz wrote:
Maybe I should rather try to fix bugs than to add new features...
here are my two top candidates:
- "Keep topology and spatial index in file instead of in memory" in
the vector ToDo. The fact that it is in memory makes simple vec
Glynn wrote:
> If you want to track symbol definitons and references, look
> at tools/sql.sh.
suggestion: we rename that script to be "build_sql_library_tree.sh" or so.
"sql.sh" is a rather uninformative name given GRASS's many SQL abilities.
Hamish
_
Glynn Clements wrote:
Markus Metz wrote:
The dglib is still a mystery to me. I don't even know what modules use
it. The other vector libs don't use it, that I'm relatively sure of.
The vector library (libgrass_vect, aka lib/vector/Vlib) uses it
(graph.c, net.c), as does v.generalize
Markus Metz wrote:
> The dglib is still a mystery to me. I don't even know what modules use
> it. The other vector libs don't use it, that I'm relatively sure of.
The vector library (libgrass_vect, aka lib/vector/Vlib) uses it
(graph.c, net.c), as does v.generalize.
If you want to track symbol
Glynn Clements wrote:
One relatively recent change that may cause a slow-down is that the
display library no longer tries to automatically simplify vectors
(reduce consecutive short line segments with a single segment). This
could have a significant impact when viewing detailed vectors at low
Moritz Lennert wrote:
On 11/02/09 12:54, Markus Metz wrote:
IMHO LFS support for vector libs is not necessarily good, currently.
In order to manipulate large vectors, a very fast CPU, fast hard
drives and lots of RAM is needed, or a lot of patience, because it
can take days or weeks to run mo
Markus Metz wrote:
> >> BTW, display of grass7 with cairo appears to be half the speed of
> >> grass65, I think it was faster last week (can't remember the revision).
> >> Not sure if this justifies a complaint.
> >>
> >
> > Almost everything related to display has changed between 6.x and
On 11/02/09 12:54, Markus Metz wrote:
IMHO LFS support for vector libs is not necessarily good, currently. In
order to manipulate large vectors, a very fast CPU, fast hard drives and
lots of RAM is needed, or a lot of patience, because it can take days or
weeks to run modules with large vectors
Glynn Clements wrote:
Markus Metz wrote:
BTW, display of grass7 with cairo appears to be half the speed of
grass65, I think it was faster last week (can't remember the revision).
Not sure if this justifies a complaint.
Almost everything related to display has changed between 6.x and
Markus Metz wrote:
> BTW, display of grass7 with cairo appears to be half the speed of
> grass65, I think it was faster last week (can't remember the revision).
> Not sure if this justifies a complaint.
Almost everything related to display has changed between 6.x and 7.0.
One relatively recen
Glynn Clements wrote:
Right. The files are always written big-endian, so the high word will
always be first in the file.
I'm not so sure about that, why is byte order stored in the topo header?
Byte order for writing out is determined just before writing topo/cidx.
Okay; maybe
Markus Metz wrote:
> >> I got confused by this endian-ness and confused low/high word with
> >> first/second word. With the current code, the low word would be the
> >> second word when doing 2 32bit reads on a 64bit sized buffer,
> >> independent on a endian-ness mismatch. In this case, the l
Glynn Clements wrote:
I have added G_fseek() and G_ftell() to 7.0 in r35818.
:-)
I got confused by this endian-ness and confused low/high word with
first/second word. With the current code, the low word would be the
second word when doing 2 32bit reads on a 64bit sized buffer,
independ
Markus Metz wrote:
> I have
> read "The issues" and understand the problem, but some sort of
> implementation of G_fseek and G_ftell is needed, otherwise modules and
> libraries need a workaround like the iostream library is doing now.
> Instead of having many (potentially different) workarou
Glynn Clements wrote:
Markus Metz wrote:
I like the point of Ivan that off_t is the native type for file offsets.
Could G_fseek then use fseeko whenever fseeko is available (ditto for
ftello)?
Well, that's the general idea. The only advantage of fseek/ftell is
that they are always av
Markus Metz wrote:
> >> Do I understand right that fseeko and ftello are only needed on 32-bit
> >> systems that want D_FILE_OFFSET_BITS=64? fseek e.g. returns long which
> >> is on my 64bit Linux 64bit, I guess that's why I can write coor files >
> >> 2GB with the current vector libs.
> >>
Glynn Clements wrote:
Markus Metz wrote:
Do I understand right that fseeko and ftello are only needed on 32-bit
systems that want D_FILE_OFFSET_BITS=64? fseek e.g. returns long which
is on my 64bit Linux 64bit, I guess that's why I can write coor files >
2GB with the current vector libs.
Markus Metz wrote:
> Do I understand right that fseeko and ftello are only needed on 32-bit
> systems that want D_FILE_OFFSET_BITS=64? fseek e.g. returns long which
> is on my 64bit Linux 64bit, I guess that's why I can write coor files >
> 2GB with the current vector libs.
Yes. There's no po
Glynn Clements wrote:
lseek() always uses off_t. Originally it used long (hence the name
"l"seek), but that's ancient history; you won't find such a system
outside of a museum.
_FILE_OFFSET_BITS determines whether off_t is 32 or 64 bits. If it's
64 bits, many of the POSIX I/O functions (open, r
Markus Metz wrote:
> What about off_t lseek(int fd, off_t offset, int whence) ?
> From the GNU C library: "The lseek function is the
> underlying primitive for the fseek, fseeko, ftell, ftello and rewind
> functions [...]" lseek is used in libgis and several modules, I didn't
> see something l
Glynn Clements wrote:
Markus Metz wrote:
[...]
How about
extern off_t G_ftell(FILE *fp)
{
#ifdef HAVE_LARGEFILES
return (ftello(fp);
#else
return (ftell(fp);
#endif
}
Yep, other than the extraneous open parenthesis (2 open, 1 close).
Oops, my sloppy writin
Markus Metz wrote:
> >> 3) solve the fseek/fseeko and ftell/ftello problem. Get inspiration from
> >> libgis and LFS-safe modules? Or as suggested in the grass wiki on LFS, add
> >> extern off_t G_ftell(FILE *fp);
> >> extern int G_fseek(FILE *stream, off_t offset, int whence);
> >> for global u
Glynn Clements wrote:
Markus Metz wrote:
I think I understand. So according to the grass wiki the steps to enable
large file support would be
1) add
ifneq ($(USE_LARGEFILES),)
EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64
endif
to all relevant Makefiles
Yes. Although this should probably
Markus Metz wrote:
> I think I understand. So according to the grass wiki the steps to enable
> large file support would be
>
> 1) add
> ifneq ($(USE_LARGEFILES),)
> EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64
> endif
>
> to all relevant Makefiles
Yes. Although this should probably come after 2 and
I tried to understand the grass wiki on Large File Support, sorry for
being a bit late with that!
Glynn Clements wrote:
Markus Metz wrote:
If the coor file size stored in the topo file is indeed needed to
properly process the coor file, the respective variables must be
something else than
Markus Metz wrote:
> If the coor file size stored in the topo file is indeed needed to
> properly process the coor file, the respective variables must be
> something else than long in order to support coor files larger than 2
> GB, maybe long long? Same for all intermediate variables in the ve
While I looked into possibilities to optimize v.in.ogr I noticed that
grass does not support coor files larger than 2 GB. With topological
information stored in that file, and often many dead lines wasting
space, the coor file can easily exceed 2 GB nowadays. While v.in.ogr was
cleaning one p
43 matches
Mail list logo
