Moritz Lennert wrote:
> > Will have to debug some more...
>
> Have gotten a bit further. It seems that the problem is in
> lib/db/dbmi_base/xdr.c with the readn function, when executing the
> function read at line 40.
>
> Glynn, any hints for futher debugging ?
Ick. It might be a protocol is
On 07/02/08 11:58, Moritz Lennert wrote:
Will have to debug some more...
Have gotten a bit further. It seems that the problem is in
lib/db/dbmi_base/xdr.c with the readn function, when executing the
function read at line 40.
Glynn, any hints for futher debugging ?
Moritz
___
On 07/02/08 15:32, Michael Barton wrote:
Thanks Moritz.
I see now that it is even more complicated than I thought. A different
issue on Windows than on a Mac. The good news is that it seems to work
OK with a good file.
Yes, but on GNU/Linux it works very well even with the "bad" file.
Morit
Thanks Moritz.
I see now that it is even more complicated than I thought. A
different issue on Windows than on a Mac. The good news is that it
seems to work OK with a good file.
Michael
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of
Michael Barton wrote:
> > If the string is parsed by the shell, it needs to be quoted, otherwise
> > it doesn't.
> >
> >> Given these tests and what Glynn said (subsequent post), it seems
> >> safest to always quote or escape the | character in v.in.ascii. In
> >> this regard, is there a problem
On 05/02/08 17:17, Michael Barton wrote:
On Feb 5, 2008, at 8:48 AM, Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs correctly
with the default values (i.e. '|' as seperator) or doesn't.
No
> Michael:
> > As an aside, the | character seems like an odd default separator
> > for data fields in GRASS. I suppose it's a holdover from the
> > ancient past. But the fact that this is also has meaning as a pipe
> > seems to make it a risky separator in general. What about switching
> > this to
On 06/02/08 19:03, Glynn Clements wrote:
Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs correctly
with the default values (i.e. '|' as seperator) or doesn't.
Not in the case of my Mac gui crash
Moritz Lennert wrote:
> >> I would rather guess that depending on how the command line was
> >> formulated, i.e. where the fs=| is placed, the command runs correctly
> >> with the default values (i.e. '|' as seperator) or doesn't.
> >>
> >
> > Not in the case of my Mac gui crash. Exact same co
On Feb 6, 2008, at 10:41 AM, Glynn Clements wrote:
Michael Barton wrote:
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields
between records AND use the '|' separator, I have trouble on my
Mac.
However, if I fix the fil
Michael Barton wrote:
> >> It looks like the '|' is partly to blame, but not entirely.
> >> If I use the original file with missmatched numbers of fields
> >> between records AND use the '|' separator, I have trouble on my Mac.
> >> However, if I fix the file so that all records have the same
On 05/02/08 17:17, Michael Barton wrote:
On Feb 5, 2008, at 8:48 AM, Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs correctly
with the default values (i.e. '|' as seperator) or doesn't.
No
On Feb 5, 2008 4:08 PM, Michael Barton <[EMAIL PROTECTED]> wrote:
>
> On Feb 5, 2008, at 5:44 AM, Moritz Lennert wrote:
>
> > On 05/02/08 06:00, Michael Barton wrote:
> >> Hi Helena,
> >> It looks like the '|' is partly to blame, but not entirely.
> >> If I use the original file with missmatched nu
On Feb 5, 2008, at 8:48 AM, Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs
correctly with the default values (i.e. '|' as seperator) or doesn't.
Not in the case of my Mac gui crash. Exact
On 05/02/08 16:08, Michael Barton wrote:
On Feb 5, 2008, at 5:44 AM, Moritz Lennert wrote:
On 05/02/08 06:00, Michael Barton wrote:
Hi Helena,
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields between
records AND use the
On Feb 5, 2008, at 5:44 AM, Moritz Lennert wrote:
On 05/02/08 06:00, Michael Barton wrote:
Hi Helena,
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields
between records AND use the '|' separator, I have trouble on my Mac.
Helena Mitasova wrote:
> I did few more experiments (with a different file, but still
> generated by GRASS - this time using v.out.ascii)
> and it indeed looks like the fs=| is responsible
> for the truly erratic behavior - I think that without quotes it is
> represented as
> pipe(?) so dependi
On 05/02/08 06:00, Michael Barton wrote:
Hi Helena,
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields between
records AND use the '|' separator, I have trouble on my Mac.
However, if I fix the file so that all records ha
Hi Helena,
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields between
records AND use the '|' separator, I have trouble on my Mac.
However, if I fix the file so that all records have the same number
of fields (keeping '
I did few more experiments (with a different file, but still
generated by GRASS - this time using v.out.ascii)
and it indeed looks like the fs=| is responsible
for the truly erratic behavior - I think that without quotes it is
represented as
pipe(?) so depending on where you put it you get diff
I just emailed you the response - it is the fs=|
try to skip it to see what happens. It does not seem to have anything
with the data in the file
Helena
Helena Mitasova
Associate Professor
Department of Marine, Earth
and Atmospheric Sciences
1125 Jordan Hall, Campus Box 8208
North Carolina St
Yet additional information.
The file is messy because not all records have the same number of
fields. Here is an example of 2 records.
628658.81149001|226880.93032087|9|-|-
636555.15570527|224580.64987627|10|125.6878585815||4|Managed
Herbaceous Cover
In fact these *should* be
628
Michael,
my Mac definitely does not like fs=|
it imports it correctly without it (as it i the default separator)
or when it is "|"
Helena
g.region rast=elevation
v.in.ascii schools_el_lu.txt output=schools_lutest format=point
fs=| skip=0 x=1 y=2 z=0 cat=3
Scanning input for column types ...
On Feb 4, 2008, at 9:45 PM, Michael Barton wrote:
On Feb 4, 2008, at 7:23 PM, Hamish wrote:
Michael Barton wrote:
I've run into a problem running v.in.ascii for WinGRASS importing an
ASCII points file. Sometimes it works OK. Other times, it causes a
Windows dbf.exe error but still gets the
On Feb 4, 2008, at 7:23 PM, Hamish wrote:
Michael Barton wrote:
I've run into a problem running v.in.ascii for WinGRASS importing an
ASCII points file. Sometimes it works OK. Other times, it causes a
Windows dbf.exe error but still gets the job done. In most cases, it
causes a dbf.exe error a
Michael Barton wrote:
> I've run into a problem running v.in.ascii for WinGRASS importing an
> ASCII points file. Sometimes it works OK. Other times, it causes a
> Windows dbf.exe error but still gets the job done. In most cases, it
> causes a dbf.exe error and only imports the first point--wit
I've run into a problem running v.in.ascii for WinGRASS importing an
ASCII points file. Sometimes it works OK. Other times, it causes a
Windows dbf.exe error but still gets the job done. In most cases, it
causes a dbf.exe error and only imports the first point--with a coor
error.
Here are
27 matches
Mail list logo
