[GRASSLIST:6674] Re: Overriding awk locales

[Hamish]

> > > some points. These points are in a file, and I have used awk
> > > '{printf "%16.6f|%16.6f|%16.6f\n", $1,$2,$3}' to generate my
> > > files. However,
> > just try:
> > 
> > awk '{printf"%16.6f|%16.6f|%16.6f\n", $1,$2,$3}' | sed 's/\,/\./g'

v.in.garmin has the same problem. using sed or tr to swap ,. doesn't
work well if you have multiple columns, some with real commas.

others sorted this out, run 
 export LC_ALL=C
first to make awk print "." for decimal places.


> As I mentioned on my previous e-mail, that is exactly what I did.
> Which works. BUT, on my machine, v.in.ascii scans the whole file first
> (8.3M records!) and then starts importing it. The memory v.in.ascii
> uses starts to mount up, until around 3.7M records have been read in.
> At around this point, the kernel kills v.in.ascii due to excessive
> memory usage (I use Linux).
> 
> The v.in.ascii line is:
> v.in.ascii -zt output=<lala> fs="|" x=1 y=2 z=3 cols="x double
> precision, y double precision, z double precision"
> 
> I know that if you use a dbf table, the memory usage grows (see
> <http://www.intevation.de/rt/webrt?serial_num=2903&display=History>).
> I use 6.0.0-1 (DebianGIS packages). Anyone got any ideas on what to do
> or how I can provide extra debugging information for people to have a
> look at?

forgot to close that bug, now done.

I think some minor memory leaks remain; 1.15 million uses about 430mb or
so RAM. May have to import in chunks.


[time passes]
> Regarding my previous message, and while trawling through the
> developers list, I have found that the memory consumption issue in
> GRASS 6.0 seems to have been fixed (see
> http://grass.itc.it/pipermail/grass5/2005-March/017834.html).

Yes, already fixed in the CVS version.


> How can I incorporate the changes into 6.0.0?

You'll need to recompile the 6.1-CVS snapshot from source. I can provide
instructions for doing this on Debian if you require.



Hamish