Opened 14 years ago

Closed 13 years ago

#691 closed defect (fixed)

test_wkt_in_multipoint cunit test failing on mingw

Reported by: robe Owned by: pramsey
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: mingw Cc:

Description

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)

Change History (14)

comment:1 by pramsey, 14 years ago

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);

comment:2 by robe, 14 years ago

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)

comment:3 by mcayland, 14 years ago

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…

comment:4 by robe, 14 years ago

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)

comment:5 by pramsey, 14 years ago

What does 1.5 say to the same question?

comment:6 by robe, 14 years ago

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)

comment:7 by pramsey, 14 years ago

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

comment:8 by robe, 14 years ago

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

comment:9 by pramsey, 14 years ago

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).

comment:10 by robe, 14 years ago

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.

comment:11 by robe, 14 years ago

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.

comment:12 by robe, 14 years ago

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 (I) 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).

comment:13 by robe, 14 years ago

Keywords: mingw added
Summary: test_wkt_in_multipoint cunit test failngtest_wkt_in_multipoint cunit test failing on mingw

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.

comment:14 by robe, 13 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.