test_wkt_in_multipoint cunit test failing on mingw

[robe]

I'm not sure how long this has been failing — I think since your big load of changes.

Should all cunit tests be passing?

Getting failure on

Test: test_wkt_in_multipoint ... FAILED
    1. cu_in_wkt.c:145  - CU_ASSERT_STRING_EQUAL(r,s)

[pramsey]

Hooray, platform dependent formatting differences. I might just comment it out.

 s = "MULTIPOINT(-1 -2 -3,5.4 6.6 7.77,-5.4 -6.6 -7.77,1000000 1e-06 -1000000,-1.3e-06 -1.4e-05 0)";
 r = cu_wkt_in(s, WKT_EXTENDED);

See what you get on the SQL terminal with this

 select st_asewkt('MULTIPOINT(-1 -2 -3,5.4 6.6 7.77,-5.4 -6.6 -7.77,1000000 1e-06 -1000000,-1.3e-06 -1.4e-05 0)'::geometry);

[robe]

I get:

MULTIPOINT(-1 -2 -3,5.4 6.6 7.77,-5.4 -6.6 -7.77,1000000 1e-006 -1000000,-1.3e-006 -1.4e-005 0)

[mcayland]

postgis20=# select version();

version

---

PostgreSQL 8.3.7 on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2

(1 row) postgis20=# select st_asewkt('MULTIPOINT(-1 -2 -3,5.4 6.6 7.77,-5.4 -6.6 -7.77,1000000 1e-06 -1000000,-1.3e-06 -1.4e-05 0)'::geometry);

st_asewkt

---

MULTIPOINT(-1 -2 -3,5.4 6.6 7.77,-5.4 -6.6 -7.77,1000000 1e-06 -1000000,-1.3e-06 -1.4e-05 0)

(1 row)

Hmmm I see issues with leading zeros in the exponent…

[robe]

Not that the PostgreSQL matters since this is a cunit test, but in case

I was running on Windows 7 32-bit PostgreSQL 9.0 when I got this answer:

MULTIPOINT(-1 -2 -3,5.4 6.6 7.77,-5.4 -6.6 -7.77,1000000 1e-006 -1000000, -1.3e-006 -1.4e-005 0)

[pramsey]

What does 1.5 say to the same question?

[robe]

Looks the same:

MULTIPOINT(-1 -2 -3,5.4 6.6 7.77,-5.4 -6.6 -7.77,1000000 1e-006 -1000000,-1.3e-006 -1.4e-005 0)

[pramsey]

Weird, it's a modified version of this regression test… is the original stable for you?

http://trac.osgeo.org/postgis/browser/trunk/regress/regress.sql#L67

[robe]

Yes 1.5 branch and 1.5.2 stable all cunit tests pass (note: all the postgresql .sql tests pass in PostGIS 2.0 and in 1.5.2), can't test on 1.5 branch at the moment because I always download the sql regress tests from the tar ball (or have to do a dos2unix) since svn the regress tests the line breaks are always screwed up on half of the tests so half of them don't pass though (hmm some do) and interestingly from overwriting from tar ball they always pass.

How do these things get half-way screwed up in svn but come out fine in tar?

Output from 1.5 branch cunit

--Run Summary: Type      Total     Ran  Passed  Failed
               suites        4       4     n/a       0
               tests        43      43      43       0
               asserts     633     633     633       0

[pramsey]

You misunderstand. That WKT is not in the 1.5 unit tests. It only got added to the 2.0 unit tests a week ago. But it *is* part of the SQL regression tests, longstanding, in a slightly altered form (no leading zero in the exponent).

[robe]

Well 1.5.2 works okay (all the .sql including regress pass) - did you add that before or after 1.5.2 release?. 1.5.3 regress is failing but it could be because of the line break issue because whole thing is filled with ^{M so will have to get back to you on that.}

2.0 having trouble at the moment getting the sql tests to run its just coughing up screen junk. I thought last time I was successfull all passed, but I could have been mistaken and missed a line.

[robe]

I'll have to double-check on which box I was testing on. I'm getting different cunit failures on this particular one but not sure if its because of your recent changes or differences in the boxes. I'll put in a separate ticket.

[robe]

Okay I tested 1.5.3 svn branch as well as PostGIS 2.0 trunk and for regress its coming back as successful (after I resave the regress_expected file with Unix line breaks).

I'm not sure why its not picking up that subtle difference in answers, but its evidentally not since what is listed in regress_expected is not what I'm seeing in PgAdmin or psql client. I thought maybe it was the psql client, but I tried various psql windows and mingw clients from ddfferent versions of PostgreSQL and get the same -006, -005 in the answers.

On a side note — is there anything we can do about those sql tests with the line breaks. Half of them fail for me because they are showing as windows line breaks and so I always have to resave them as unix line breaks before they are successful.

It seems to be whenever you change the files. Is it something about SVN or the way the files are being saved. This time around overwritting with the generated tar did not help (only the postgis-1.5.2 tar seems formatted right).

[robe]

Paul, On closer inspection of our PostgreSQL regress, I see why now mingW PostgreSQL regress tests pass and fails your CUnit test. Looks like there are explicit sed calls in the PostgreSQL version handle these e variations:

| sed 's/[eE]\([+-]\)0\{1,\}\([0-9]\{1,\}\)/e\1\2/g' \

When you get tired of doing your civic duties and want a healthy fat free coding break — maybe you can take a look at this. (or perhaps someone else can look into this)

It's a bit of a pain because everytime I test it halts at CUnit and then I have to manually call the PostgreSQL regress and other tests to continue regression testing.

[robe]

I'm not sure what this is about anymore, but my cunit tests are all passing.