[GRASS-dev] [grass-code I][444] v.in.ogr: false optional 'dsn' and 'output'

GRASS GIS GRASS GIS developer
1

code I item #444, was opened at 2007-07-10 12:36
Status: Open
Priority: 3
Submitted By: Maciej Sieczka (msieczka)
Assigned to: Nobody (None)
Summary: v.in.ogr: false optional 'dsn' and 'output'
Issue type: module bug
Issue status: None
GRASS version: CVS HEAD
GRASS component: vector
Operating system: all
Operating system version:
GRASS CVS checkout date, if applies (YYMMDD): 070710

Initial Comment:
v.in.ogr advertises the 'dsn' and 'output' as optional in 6.3 CVS:

GRASS 6.3.cvs (spearfish60):~ > v.in.ogr help 2>&1 | grep Usage -A1
Usage:
v.in.ogr [-lfcztoew] [dsn=string] [output=name]

(see the brackets around options dsn and output; their presence is interpreted as "optional" by the autogenerated tcl/tk GUI)

In current CVS GRASS 6.2 these options are required:

GRASS 6.2.2cvs (spearfish60):~ > v.in.ogr help 2>&1 | grep Usage -A1
Usage:
v.in.ogr [-lfcztoe] dsn=string output=name [layer=string[,string,...]]

(no brackets around options dsn and output)

And they should be required for sure:

$ v.in.ogr -l dsn=.
Data source contains 11 layers:
cieki, drogi, laka, las, park, rowy, sciezki, waly, woda, zabudowa, zarosla

$ v.in.ogr out=something
ERROR: Required parameter <dsn> not set

$ v.in.ogr dsn=.
ERROR: Required parameter <output> not set

$ v.in.ogr dsn=cieki.shp
ERROR: Required parameter <output> not set

Maciek

----------------------------------------------------------------------

You can respond by visiting:
http://wald.intevation.org/tracker/?func=detail&atid=204&aid=444&group_id=21

2

After doing some more testing (QGIS and GRASS on Linux,
GRASS native w/o QGIS from http://qgis.org/uploadfiles/testbuilds/),
I still think that possible pipe blocking is the hottest lead so far.

There are some comments (maybe written by Radim Blazek?) in start.c
which suggest the same:

    /* I have seen problems with pipes on NT 5.1 probably related
     * to buffer size (psize, originaly 512 bytes).
     * But I am not sure, some problems were fixed by bigger
     * buffer but others remain.
     * Simple test which failed on NT 5.1 worked on NT 5.2
     * But there are probably other factors.

I would like to change the pipes in lib/db/dbmi_client/start.c to
nonblocking I/O. If those hints are right, then this should fix the
problem, I guess.
However, as always with Windows, things are more frustrating then they
should be.

I have been digging into Win32 internals and it seems that you cannot
open anonymous pipes (which is what start.c does) in nonblocking mode
on Win32 (on Linux you can use fctl for this):

  http://en.wikipedia.org/wiki/Anonymous_pipe

What puzzles me is this comment in start.c:

   /* More info about pipes from MSDN:
       - Anonymous pipes are implemented using a named pipe
         with a unique name.

So there must be a way to open pipes "p1" and "p2" in nonblocking mode!?
If not: is there a way to switch to a named pipe for the DBMI driver?

If there are any Windows hackers here that would like to give it a try
but don't want to invest the time setting up a compile and test
environment: let me know and I'll upload the complete toolset and
sample data.

Thanks for any help,

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

3

Benjamin Ducke wrote:

After doing some more testing (QGIS and GRASS on Linux,
GRASS native w/o QGIS from http://qgis.org/uploadfiles/testbuilds/),
I still think that possible pipe blocking is the hottest lead so far.

There are some comments (maybe written by Radim Blazek?) in start.c
which suggest the same:

    /* I have seen problems with pipes on NT 5.1 probably related
     * to buffer size (psize, originaly 512 bytes).
     * But I am not sure, some problems were fixed by bigger
     * buffer but others remain.
     * Simple test which failed on NT 5.1 worked on NT 5.2
     * But there are probably other factors.

I would like to change the pipes in lib/db/dbmi_client/start.c to
nonblocking I/O. If those hints are right, then this should fix the
problem, I guess.

Unlikely. The XDR library uses ANSI stdio (fread/fwrite), which
(AFAICT) never return short counts. Even if you make the underlying
pipes non-blocking, fread/fwrite are going to block until they have
read/written all of the data.

--
Glynn Clements <glynn@gclements.plus.com>

4

http://wald.intevation.org/tracker/?func=detail&atid=204&aid=444&group_id=21

code I item #444, was opened at 2007-07-10 12:36
Submitted By: Maciej Sieczka (msieczka)
Summary: v.in.ogr: false optional 'dsn' and 'output'

..

v.in.ogr advertises the 'dsn' and 'output' as optional in 6.3 CVS:

GRASS 6.3.cvs (spearfish60):~ > v.in.ogr help 2>&1 | grep Usage -A1
Usage:
v.in.ogr [-lfcztoew] [dsn=string] [output=name]

(see the brackets around options dsn and output; their presence is
interpreted as "optional" by the autogenerated tcl/tk GUI)

this is so you can use the -l and -f flags without supplying dummy
values to dsn= and output=. I don't know what the correct answer is, but
that was the logic behind the change, AFAIU.

Hamish