[GRASS-dev] native WinGRASS and attribute data deadlock, next try

GRASS GRASS developer
,
21

Moritz Lennert wrote:

> +static ssize_t readn(int fd, void *buf, size_t count)
> {
> - xdrstdio_create (xdrs, _send, XDR_ENCODE);
> + ssize_t total = 0;
> +
> + while (total < count)
> + {
> + ssize_t n = read(fd, (char *) buf + total, count - total)

the MINGW compiler complains about a missing ';' at the end here. gcc
under linux doesn't...don't know why.

Because it isn't compiled on Linux:

  #ifdef __MINGW32__
  #define USE_STDIO 0
  #define USE_READN 1
  #else
  #define USE_STDIO 1
  #define USE_READN 0
  #endif

Linux uses stdio, Windows uses readn/writen. I thought that I tested
those functions; obviously not.

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

22

On Mon, October 8, 2007 22:46, Moritz Lennert wrote:

On Sun, October 7, 2007 23:04, Glynn Clements wrote:

Could someone familiar with DBMI and vectors test it out?

Rapid testing in Debian (v.out/in.ogr, v.univar, d.vect.thematic, g.copy)
with dbf, sqlite, postgres does not show any problems. Will test in
windows as soon as I solve the compile problems.

Compile problems in windows are not solved, yet (see other mail), but they
should not interfere with the dbmi issues. Rapid testing in windows also
confirms that everything seems to work fine.

I propose to commit to CVS to allow further testing.

Moritz

23

Moritz Lennert-2 wrote:

On Mon, October 8, 2007 22:46, Moritz Lennert wrote:

On Sun, October 7, 2007 23:04, Glynn Clements wrote:

Could someone familiar with DBMI and vectors test it out?

Rapid testing in Debian (v.out/in.ogr, v.univar, d.vect.thematic, g.copy)
with dbf, sqlite, postgres does not show any problems. Will test in
windows as soon as I solve the compile problems.

Compile problems in windows are not solved, yet (see other mail), but they
should not interfere with the dbmi issues. Rapid testing in windows also
confirms that everything seems to work fine.

I propose to commit to CVS to allow further testing.

This is excellent! And hopefully still comes in time for the upcoming
QGIS release (which tells us that we should get out 6.3.0 to avoid
a moving target for them!).

Markus
--
View this message in context: http://www.nabble.com/Re%3A-native-WinGRASS-and-attribute-data-deadlock%2C-next-try-tf4461552.html#a13199672
Sent from the Grass - Dev mailing list archive at Nabble.com.

24

I finally got my hands on a Win2000 box again and was able to
test the new WinGRASS patches.
I tried to apply Glynn's latest patch to yesterday's CVS but
the 'patch' program told me that it had already been applied.
Thus, I assume the patches are in the current CVS?
Anyway, after compilation (Win2000 SP4 with MingW), I tested
the binaries and everything seemed to work just fine.
Did ca. 20 testruns with v.out.ogr on a shapefile and DBF and
none of them stalled.

Benjamin

Moritz Lennert wrote:

On Mon, October 8, 2007 22:46, Moritz Lennert wrote:

On Sun, October 7, 2007 23:04, Glynn Clements wrote:

Could someone familiar with DBMI and vectors test it out?

Rapid testing in Debian (v.out/in.ogr, v.univar, d.vect.thematic, g.copy)
with dbf, sqlite, postgres does not show any problems. Will test in
windows as soon as I solve the compile problems.

Compile problems in windows are not solved, yet (see other mail), but they
should not interfere with the dbmi issues. Rapid testing in windows also
confirms that everything seems to work fine.

I propose to commit to CVS to allow further testing.

Moritz

25

Benjamin Ducke wrote:

I finally got my hands on a Win2000 box again and was able to
test the new WinGRASS patches.
I tried to apply Glynn's latest patch to yesterday's CVS but
the 'patch' program told me that it had already been applied.
Thus, I assume the patches are in the current CVS?

Yes; the CVS version no longer uses XDR for DBMI communication.

Anyway, after compilation (Win2000 SP4 with MingW), I tested
the binaries and everything seemed to work just fine.
Did ca. 20 testruns with v.out.ogr on a shapefile and DBF and
none of them stalled.

Good to hear.

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