[GRASS-dev] erratic behavior of v.in.ascii with WinGRASS

[Michael Barton]

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 Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>



On Feb 7, 2008, at 3:58 AM, Moritz Lennert wrote:

> 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.
>>>
>> Not in the case of my Mac gui crash. Exact same command argument  
>> order (in gui):
>> fs=|   + different number of fields in different records (i.e.,  
>> data file format bad) = crash TclTk
>> fs=|   + same number of fields in all records (i.e., data file  
>> format good) = OK
>> fs="|" + different number of fields in different records (i.e.,  
>> data file format bad) = OK
>> fs=,   + different number of fields in different records (i.e.,  
>> data file format bad) = OK
>> Windows may be a different story, however. I haven't had a chance  
>> to check that.
>
> On Windows (in GUI),
>
> > fs=|   + different number of fields in different records (i.e., data
> > file format bad)
>
> provokes a dbf error, but that does not crash the GUI. v.in.ascii  
> keeps running, though, and I have to kill it. I get exactly the  
> same behaviour at the command line.
>
> Using the "good" file format everything works.
> Sometimes (but not systematically) the GUI then crashes if I kill  
> the v.in.ascii process and then run the command again with the  
> "good" file format.
>
> So, at least in windows, the '|' field separator is not the  
> problem. It is the fact that there is something keeping v.in.ascii  
> from dealing with different line lengths. It does give the right  
> diagnostics, though, i.e.
>
> Maximum input row length: 89
> Maximum number of columns: 7
> Minimum number of columns: 5
>
> but this is printed to the Output window only after I kill the  
> v.in.ascii process.
>
> Will have to debug some more...
>
> Moritz