<html>
<head>
</head>
<body>This was an evening of regression.<br />
I have to go to bed so I will just write some notes about the walls I ran into with head first.<br />
<br />
don't think anything means problem for release, but is more of my installation problems and things like that.<br />
<br />
I succeeded compiling postgresql 9 on the other box. <br />
<br />
Regina, I saw in configure output when configuring postgresql that it wasn't happy about the Perl version. It wanted a newer version. Can that be the reason that it didn't set the ${PERL} global. Your hack seems to work for me to but can it affect something else if the version is to low?<br />
<br />
Anyway, I gave up to compile against postrgesql 9.0 earlier so I thought I should do some testing against 8.4 to at least success with something.<br />
<br />
So I just compiled 1.5.2rc1 against an old postgresql84 server that I have compiled earlier.<br />
<br />
But on that one I get the error:<br />
<br />
could not load library "c:/pg84/lib/postgresql/postgis-1.5.dll" unknown error 126<br />
<br />
it puts "postgresql" into the path. Why? do you have that problem Regina?<br />
<br />
Ok, I also wanted to see more about the regression failure in ubuntu 32bit so I compiled svn branch for 1.5 and I get the same failure. instead of LINESTRING(0 0, 0 0) I get some very small numbers on the coordinates the like 6e-15<br />
<br />
<br />
I thought I should just put ST_SnapToGrid into it to round it a little<br />
but since st_shortestline returns a zero-length linestring when inputed geometries intersect<br />
st_snaptogrid then removes one of the vertexes from the linestring and returns nothing.<br />
<br />
like:<br />
select st_snaptogrid('LINESTRING(1 2, 1 2)'::geometry, 0.1)<br />
<br />
So we don't get a parse error or an empty geometry, but... nothing<br />
<br />
Maybe empty geometry would be better?<br />
<br />
Anyway that makes st_shortestline not working very well with st_snaptogrid<br />
Can anyone come with a better answer from st_shortestline when the two geometries intersect than a zero-length linestring in any of the intersecting points?<br />
<br />
On other words I have spent an evening in front of monitors without doing anything at all<br />
<br />
I give up for now. <br />
Tell me if it is anything of above that worries and should be investigated before release then I will try to get more information on that.<br />
<br />
/Nicklas<br />
<br />
<br />
2010-09-22 Nicklas Avén wrote:<br />
<br />
Regina
>
<div align="left"> </div>
>
<div align="left">My problem was already when compiling postgresql 9.0</div>
>
<div align="left">I guess I have something outdated. I will try again now and maybe get back if I don't figure out what the error-messege is about.</div>
>
<div align="left"> </div>
>
<div align="left">everybody</div>
>
<div align="left"> </div>
>
<div align="left">I know I have had some regression tests failiurs on measures the other week. It is one of those small differences and it only shows for me on a ubuntu 32bit installation. On windows (on the same machine as ubuntu 32 bit) and ubuntu 64bit on another box, it passes.</div>
>
<div align="left"> </div>
>
<div align="left">Is someone getting running the regression tests on linux 32 bit with sucess on measures?</div>
>
<div align="left"> </div>
>
<div align="left">One thing that is a little interesting about it is that the installations that passes regression tests is the same installations that gives the fenomena in #503.</div>
>
<div align="left"> </div>
>
<div align="left">So the installations passing the regreesion tests are the same installations as rounds the answer of area to closest multiple of 0.001953125</div>
>
<div align="left"> </div>
>
<div align="left">I just wanted to mention it if it can be a clue for someone smart about #503</div>
>
<div align="left"> </div>
>
<div align="left">/Nicklas<br />
><br />
>
2010-09-22 Paragon Corporation wrote:<br />
><br />
><br />
>
>Nicklas,<br />
>
><br />
>
>> I will try to do some testing this evening. I tried yesterday on windows<br />
>
>but had problems with compiling postgresql 9.0I don't remember the error<br />
>
>message now. I will try on another > box. Regina has there been any special<br />
>
>things compiling 9.0 in mingw for you? I have not updated anything (have<br />
>
>just been glad it has worked :-) )so maybe I should just reinstall <br />
>
>> mingw and everything. /Nicklas <br />
>
><br />
>
><br />
>
>We do use some hacks to compile against PostgreSQL 9.0 on windows that we<br />
>
>don't need to do for prior versions.<br />
>
><br />
>
>That's why I said -- maybe the issues I have on Windows are not really a<br />
>
>good measure of what others will experience and someone needs to test on<br />
>
>Linux or Mac.<br />
>
><br />
>
> 1) can't get it to install without this:<br />
>
>sed 's,$(PERL),perl,g'
postgis/Makefile2<br />
>
>mv postgis/Makefile2 postgis/Makefile<br />
>
><br />
>
>Which I documented in the PostGIS 1.5 section of<br />
>
><br />
>
>trac.osgeo.org/postgis/wiki/UsersWikiWinCompile<br />
>
><br />
>
><br />
>
>2) For some reason we can't do a make check against the MingW build of<br />
>
>PostgreSQL 9.0. It always gives this error<br />
>
><br />
>
>createdb: could not connect to database postgres: FATAL: parameter "port"<br />
>
>cannot be changed without restarting the server<br />
>
><br />
>
>(could be because we have so many versions of PostgreSQL, but the other<br />
>
>versions of PostgreSQL don't have this issue)<br />
>
><br />
>
>So to get around this mess -- after make install on MingW, our script copies<br />
>
>the files to our Windows PostgreSQL 9.0 install and then does the <br />
>
><br />
>
>make check<br />
>
><br />
>
>For the others -- make check against the mingW builds works fine and all<br />
>
>checks for 8.3 and 8.4 against mingW builds pass with flying colors.<br />
>
><br />
>
><br />
>
>-- Mark to answer your question about the diffs in the PostgreSQL 9.0 --<br />
>
>they look like below - so it seems to me that the PostgreSQL 9.0 (and it<br />
>
>could be some default sent in the Windows build just providing the count<br />
>
>of records (more information) than what the regress is expecting.<br />
>
><br />
>
>*** wmsservers_expected Tue Nov 17 12:23:16 2009<br />
>
>--- /tmp/pgis_reg_124/test_46_out Mon Sep 20 08:54:34 2010<br />
>
>***************<br />
>
>*** 1,6 ****<br />
>
> Starting up MapServer/Geoserver tests...<br />
>
> Setting up the data table...<br />
>
>! SELECT<br />
>
> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index<br />
>
>"wmstest_pkey" for table "wmstest"<br />
>
> ALTER TABLE<br />
>
> Running Geoserver 2.0 NG tests...<br />
>
>--- 1,6 ----<br />
>
> Starting up MapServer/Geoserver tests...<br />
>
> Setting up the data table...<br />
>
>! SELECT 2343<br />
>
> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index<br />
>
>"wmstest_pkey" for table "wmstest"<br />
>
> ALTER TABLE<br />
>
> Running Geoserver 2.0 NG tests...<br />
>
><br />
>
><br />
>
>*** tickets_expected Mon Feb 8 14:19:23 2010<br />
>
>--- /tmp/pgis_reg_124/test_47_out Mon Sep 20 08:54:36 2010<br />
>
>***************<br />
>
>*** 45,51 ****<br />
>
> #210b|<br />
>
> #213|17<br />
>
> #234|COMPOUNDCURVE((0 0,1 1))<br />
>
>! SELECT<br />
>
> #241|0<br />
>
> #254|010700000000000000<br />
>
> #259|<br />
>
>--- 45,51 ----<br />
>
> #210b|<br />
>
> #213|17<br />
>
> #234|COMPOUNDCURVE((0 0,1 1))<br />
>
>! SELECT 1<br />
>
> #241|0<br />
>
> #254|010700000000000000<br />
>
> #259|<br />
>
><br />
>
><br />
>
>Thanks,<br />
>
>Regina<br />
>
><br />
>
><br />
>
>----------------<br />
>
><br />
>
><br />
>
><br />
>
>><br />
>
>>> Remember that because postgis_comments.sql has extra dependencies for the<br />
>
>>documentation build that it needs to be installed from the documentation<br />
>
>>Makefile. This is now under PGXS control too, so all you need to do is:<br />
>
>><br />
>
>>> cd doc/<br />
>
>>> make comments-install<br />
>
>><br />
>
>>> ...and you're golden.<br />
>
>><br />
>
>>For this then we probably should put a note somewhere in the docs that if<br />
>
>>they aren't doing a make install of comments, then the comments will have<br />
>
>to<br />
>
>>be manually copied.<br />
>
>><br />
>
>>The point why we package the postgis_comments.sql in the tar is so that<br />
>
>>people don't need the extra xsltproc dependency and don't need to run the<br />
>
>>step you describe above. So yah I know the step above works but that is not<br />
>
>>the point.<br />
>
>><br />
>
>>I'll have to get back to you other issue as I don't have my difffs around.<br />
>
>><br />
>
>>All I recall is the output was something like<br />
>
>><br />
>
>>SELECT 3456<br />
>
>><br />
>
>>And the regress just had<br />
>
>><br />
>
>><br />
>
>>SELECT<br />
>
>><br />
>
>><br />
>
>>But lets see what others say. We are on windows so who cares since things<br />
>
>>don't quite work the same for us anyway.<br />
>
>><br />
>
>>Thanks,<br />
>
>>Regina<br />
>
>><br />
>
>><br />
>
><br />
>
><br />
>
>_______________________________________________<br />
>
>postgis-devel mailing list<br />
>
>postgis-devel@postgis.refractions.net<br />
>
>postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>
><br />
>
> </div>
</body>
</html>