| 00:04:13 | rudenstam: | it's always as inspiring to see development in action |
| 01:21:45 | CIA-34: | strk * r2366 /trunk/source/ ( 6 files in 4 dirs ): Fix leak in PolygonBuilder ( overlay operation ). The leak was exposed by the stmlf-cases-20061020.xml testcase. This commit also adds some doc-only throw specs related to the bug. |
| 01:22:03 | strk: | xmltests all run w/out a leak now |
| 01:26:10 | CIA-34: | strk * r2367 /trunk/ ( 2 files in 2 dirs ): Document ownership of DistanceOp::closestPoints return, fix leak in unit test. |
| 01:58:20 | CIA-34: | strk * r2368 /trunk/source/ ( 3 files in 3 dirs ): Fix leak in SimpleGeometryPrecisionReducer, improve memory management docs where topic. |
| 02:14:33 | CIA-34: | strk * r2369 /trunk/tests/unit/util/UniqueCoordinateArrayFilterTest.cpp: Fix memory leak in unit test |
| 02:40:05 | CIA-34: | strk * r2370 /trunk/source/headers/geos/index/quadtree/NodeBase.h: Document ownership of quadtree::NodeBase subnodes |
| 03:08:40 | mloskot: | strk: hi |
| 03:08:57 | mloskot: | strk: just FYI in case you've not noticed, |
| 03:09:24 | mloskot: | tests are failing on buildbot |
| 03:09:45 | strk: | oh |
| 03:09:48 | mloskot: | http://trac.osgeo.org/geos/wiki/Buildbot |
| 03:09:49 | sigq: | Title: Buildbot - GEOS - Trac ( at trac.osgeo.org ) |
| 03:09:50 | strk: | nope, I haven't noticed indeed |
| 03:10:05 | mloskot: | t-quick and t-full have been red since a while |
| 03:10:32 | strk: | is the changeset to check the one below or above the failing point ? |
| 03:10:43 | mloskot: | strk: buildbot grabs updates after each commit ( with a few minutes delay, if new commits are about to arrive shortly ) and then builds it |
| 03:10:58 | mloskot: | you have rev number next to every build |
| 03:11:17 | mloskot: | + committer name to identify who broken the doll |
| 03:12:19 | strk: | TestBufferExternal2.xml, wasn't run in previous revisions |
| 03:12:54 | mloskot: | strk: but it used to be green, see build 28 and earlier |
| 03:13:14 | mloskot: | it got broken with r2352 |
| 03:13:46 | CIA-34: | strk * r2371 /trunk/source/ ( 3 files in 2 dirs ): Few more docs about memory management in quadtree indexing; fix a potential leak in quadtree::Key |
| 03:15:16 | strk: | do the buildbots re-run ./autogen.sh and ./configure after each update ? |
| 03:16:47 | mloskot: | 1. commit |
| 03:16:51 | mloskot: | 2. bb gets notified |
| 03:17:04 | mloskot: | 3. waits 8-7 minutes looking for new commits |
| 03:17:17 | mloskot: | 4. if new commits arrive, it resets timer for another 7-8 mins |
| 03:17:30 | mloskot: | 5. if no commits arrive for 7-8 mins, fires quick build |
| 03:18:05 | mloskot: | quick = not "make clean && make: but just "make" to check new changes |
| 03:18:05 | mloskot: | EOF |
| 03:18:31 | mloskot: | I don't know why bbgeos vanished from the channel, will check tonight |
| 03:18:43 | mloskot: | but when you see bbgeos, you can watch builders |
| 03:18:45 | mloskot: | 1.commit |
| 03:18:51 | mloskot: | 2. bbgeos: watch telascience-quick |
| 03:18:58 | mloskot: | and you will get notified if sth got broken |
| 03:19:20 | strk: | any way to do a non-quick build ? |
| 03:19:27 | strk: | or, to know which was quick and which not ? |
| 03:19:29 | mloskot: | do -full build |
| 03:19:45 | mloskot: | each column represents a builder |
| 03:19:47 | strk: | I've been moving tests around, and changed XML format |
| 03:19:54 | mloskot: | a builder is quick one or full one or a custom one |
| 03:20:01 | mloskot: | we have quick and full |
| 03:20:01 | strk: | so if the *new* XMLTester runs the *old* XML file, it'll fail |
| 03:20:04 | mloskot: | telascience-quick = make |
| 03:20:09 | mloskot: | telascience-full = make clean && make |
| 03:20:47 | mloskot: | Sometimes -quick needs to get cleaned, but this needs to be done manually. I usually do it, so if that's the fix you need, I can do it tonight |
| 03:21:26 | strk: | mm, it seems -full is failing on the same testcase |
| 03:21:41 | mloskot: | then likely sth is broken |
| 03:21:48 | mloskot: | does full rebuild work for you? |
| 03:21:51 | mloskot: | locally |
| 03:22:03 | mloskot: | Anyways, if you don't need that don't bother |
| 03:22:14 | mloskot: | i'll fix it |
| 03:22:39 | strk: | it does work fine here |
| 03:23:24 | mloskot: | ok |
| 03:25:58 | strk: | could still be a numerical stability issue |
| 04:30:19 | strk: | mloskot: I could reproduce the failure on a 32bit system ( success on 64bit ) |
| 04:30:24 | strk: | thanks for pointing out |
| 04:43:40 | strk: | 3.1.0 also fails on that testcase, so not a regression |
| 04:45:25 | strk: | uhm, but 3.1.0 also succeeds on the 64bit |
| 04:52:25 | CIA-34: | strk * r2372 /trunk/source/algorithm/HCoordinate.cpp: typo in disabled section |
| 05:34:22 | strk: | as suspected |
| 05:34:26 | strk: | nhv_: tuned ? : ) |
| 05:34:42 | strk: | mloskot: -ffloat-store <--- add this to the CXXFLAGS and it succeeds |
| 05:35:25 | mloskot: | strk: ok |
| 05:50:16 | mloskot: | pracine: good afternoon/morning : ) |
| 05:52:53 | : | * mloskot has always been suspicious about -ffloat-store requirement |
| 05:54:07 | pracine: | mloskot: Good afternoon! |
| 05:54:41 | mloskot: | afternoon & bye ; ) |
| 05:55:00 | mloskot: | strk: -ffloat-store works for me, if I remove it, then tests fail |
| 05:58:57 | strk: | great :/ |
| 05:59:01 | strk: | thanks |
| 05:59:08 | strk: | I think I'll add to the default flags |
| 05:59:33 | strk: | it's an old friend of mine... horrible to get such different results due to numeric precision isn't it ? |
| 06:06:15 | mloskot: | it is |
| 06:07:01 | nhv: | -ffloat-store is a saviour :- ) |
| 06:07:05 | strk: | http://lists.osgeo.org/pipermail/geos-devel/2006-April/002202.html |
| 06:07:06 | sigq: | Title: [geos-devel] Numeric stability ( at lists.osgeo.org ) |
| 06:07:10 | strk: | nhv: remember those times ? :P |
| 06:07:19 | strk: | I also found an irc log with you trying to help there : ) |
| 06:07:42 | nhv: | yup |
| 06:08:14 | strk: | that thread feels lonely : ) |
| 06:09:22 | strk: | the horrible thing is striking back, with at new tests |
| 06:09:33 | strk: | the new tests add another parameter to the difference: 32 vs. 64 bit... |
| 06:14:12 | FrankW: | pracine: is your wiki access to the user topic working now? |
| 06:15:25 | FrankW: | I was contemplating a partial port of the WKTRaster specification page if you aren't working on it already. |
| 06:16:26 | nhv: | I guess that isn't to surprising it is reassuring that -ffloat-store works across internal 32-64 bit code differences |
| 06:18:46 | strk: | nhv: I think it'a an hazard to say so |
| 06:19:03 | strk: | there are so many variables... |
| 06:22:21 | nhv: | I think -ffloat-store sets the number of bits used by the numeric coprocessor if that is still a valid concept on todays x86 chips |
| 06:22:32 | nhv: | so it should work |
| 06:22:53 | strk: | still, it's interseting to see that the "unrolled computation" in HCoordinates ( disabled due to numerical stability issues ) can now be enabled again with no bad surprises |
| 06:23:43 | strk: | another thing is that in HCoordinates.cpp there's a macro: |
| 06:23:51 | strk: | //#define STORE_INTERMEDIATE_COMPUTATION_VALUES 1 |
| 06:24:01 | strk: | documented as being *required* for -ffloat-store to be effective |
| 06:24:09 | strk: | but evidently it isn't |
| 06:24:21 | strk: | or maybe it is .... partially ( scary ) |
| 06:25:35 | pracine: | mloskot: yes, everything is ok. |
| 06:25:46 | mloskot: | good |
| 06:26:14 | mloskot: | pracine: if you don't see Admin link in menubar, next to Search link, then you haven't got admin privs assigned |
| 06:26:29 | mloskot: | pracine: oh, you have |
| 06:26:34 | mloskot: | I see, you are admin |
| 06:26:37 | mloskot: | login: pracine |
| 06:27:01 | mloskot: | pracine: so, you should be able to go to Admin panel and input Milestones |
| 06:27:49 | pracine: | mloskot:yes |
| 06:27:56 | mloskot: | I'm not sure if space between "postgis X.Y.Z" is a good idea, not sure if it won't cause problems for Trac with URLs |
| 06:28:09 | mloskot: | so I'd suggest wktraster-X.Y.Z |
| 06:28:15 | mloskot: | but perhaps I'm overreacting :- ) |
| 06:33:38 | FrankW: | strk_away, mloskot: any idea what the runtime cost of float-store is? |
| 06:34:21 | mloskot: | I don't have any, actually I've never learned specifics of float-store and I've been trying to ignore platform-specific switches at most |
| 06:34:40 | strk: | FrankW: I was trying to figure |
| 06:34:53 | strk: | FrankW: doesn't seem notable to me |
| 06:34:58 | FrankW: | ok |
| 06:35:04 | mloskot: | The manual says: "this typically involves a big performance hit" |
| 06:35:14 | strk: | fme.xml still takes 0m1.079s |
| 06:35:35 | FrankW: | Does it force value to be flushed from registers to memory storage thereby forcing 80bit to 64 bit value normalization? |
| 06:36:17 | mloskot: | FrankW: this seems to be related to temp variables issue in C/C++, it's always better to avoid a = b + c; and do a = b; b += c; |
| 06:36:19 | strk: | I'll rebuild two parallel version with and w/out and make sure I clean all |
| 06:36:21 | mloskot: | if you care about performance. |
| 06:36:32 | mloskot: | So, this rule seems to help if you use ffloat-store |
| 06:36:37 | mloskot: | correction: |
| 06:36:39 | mloskot: | a = b; |
| 06:36:41 | mloskot: | a += c; |
| 06:36:52 | strk: | mloskot: that's what the macro was for |
| 06:37:07 | strk: | but it seems like the problem wasn't *only* in that single file... |
| 06:37:32 | mloskot: | strk: but most of people love to go chained, so there is plenty of code like a = b + c * x / z ... |
| 06:37:38 | mloskot: | instaed of split to lines |
| 06:37:38 | FrankW: | I'm wondering if float-store actually degrades results even if it provides more portable results. |
| 06:37:49 | mloskot: | strk: so I'd not expect it helps in geos |
| 06:37:55 | strk: | mloskot: wouldn't -ffloat-store also affect that ? |
| 06:38:14 | mloskot: | strk: ffloat-store seems to not affect but suffer of that ( of chains ) |
| 06:38:17 | strk: | FrankW: for GEOS "predictability" helps a lot in tracking JTS.. |
| 06:39:38 | FrankW: | It just seems questionable if what we are doing is degrading precision and performance all in the name of producing matching results on all platforms. |
| 06:39:43 | : | * mloskot would really like to know how other portable projects solve this kind of issues |
| 06:39:53 | mloskot: | FrankW: +1 |
| 06:41:13 | mloskot: | -ffloat-store helps if we stik to single-operation statements, otherwise it does not and in that case it likely decreases performance |
| 06:41:13 | FrankW: | pracine: I'm interested in doing a rough or partial port of the WKTRaster specification into the Trac wiki. Are you working on it now? Is it ok for me to take a crack at it? |
| 06:41:35 | strk: | well, thing is that based on the current test, lack of -ffloat-store did not give different but improved-precision results |
| 06:41:44 | strk: | rather it gave pretty wrong results |
| 06:42:03 | strk: | probably due to unhandled dimensional collapses or similar |
| 06:42:38 | FrankW: | ( forgive the flood ): This option prevents undesirable excess precision on machines such |
| 06:42:38 | FrankW: | as the 68000 where the floating registers ( of the 68881 ) keep more |
| 06:42:38 | FrankW: | precision than a "double" is supposed to have. Similarly for the |
| 06:42:39 | FrankW: | x86 architecture. For most programs, the excess precision does |
| 06:42:39 | FrankW: | only good, but a few programs rely on the precise definition of |
| 06:42:40 | FrankW: | IEEE floating point. |
| 06:42:45 | mloskot: | strk: the problem is that geos works on wide range of diff platforms, but JTS works on single one everywhere |
| 06:43:22 | mloskot: | meaning, Java VM - regardless of underlying OS - always run the same implementation of IEEE |
| 06:43:26 | strk: | FrankW: it could very well be that JTS relies on IEEE |
| 06:43:26 | FrankW: | It must be quite an algorithm that depends on a restricted precision 64bit floating point value to work well. |
| 06:43:44 | mloskot: | Summarizing, I'd not stick to JTS in this regard |
| 06:43:55 | strk: | for sure I know it has some precision-reducing code based on exact IEEE |
| 06:44:07 | FrankW: | I still wonder if the particular algorithm exhibiting this behavior deserves a deeper look, though I can imagine that would not be easy. |
| 06:44:11 | strk: | casting to 64bit ints and bitshifting |
| 06:44:19 | FrankW: | ugg. |
| 06:44:23 | strk: | to drop "common" bits |
| 06:44:31 | strk: | the visible result looks like a scale-down |
| 06:44:38 | strk: | to have more bits available for computing differences and such |
| 06:44:57 | FrankW: | ok, well, I'll withdraw my suggestion of review then - it clearly is not a typical numerical algorithm. |
| 06:48:08 | : | * mloskot has just confirmed, Java lang spec promises to stick to IEEE 754 for all float-point types and operations |
| 06:48:35 | FrankW: | mleslie: what was the rationale for treating WKTRaster specs as tickets? |
| 06:49:31 | mloskot: | FrankW: I believe it was my suggestion |
| 06:49:48 | mloskot: | ah, not, it wasn't. I suggested planning as tickets, not the spec |
| 06:49:56 | FrankW: | sorry -- ml<tab> did not give me the result I expected. |
| 06:50:09 | FrankW: | Ah, I guess I misread the tail of the thread. |
| 06:50:45 | mloskot: | FrankW: I suggested the big table with planning, funding and milestones moves to tickets and then reports can be generated automatically |
| 06:50:53 | pracine: | mloskot: I also understood writing the spec as tickets |
| 06:51:09 | mloskot: | pracine: perhaps I've mis-explained the idea. |
| 06:51:28 | mloskot: | Spec is a monolithic document so it should go as regular page or wiki |
| 06:51:33 | FrankW: | I'm ambivalent on this use of tickets, and feel it might be a stretch inside the postgis ticket database. |
| 06:51:41 | mloskot: | I suggested planning to tickets only. |
| 06:51:51 | mloskot: | Also, I think that mixing spec with planning is a mess |
| 06:52:17 | mloskot: | pracine: But these were loose comments, so feel free to craft it any way you like |
| 06:52:26 | mloskot: | I really don't mind, it's a detail |
| 06:52:37 | FrankW: | I would like to see the spec document be more of a pure specification. |
| 06:52:41 | pracine: | ok. Then we all agree. We`ll contnue writing our spec as wiki pages |
| 06:52:46 | mloskot: | strk_off: geos builds and tests on x64 Linux |
| 06:53:28 | : | * mloskot sometimes is too verbose with his comments, when he should shut down :- ) |
| 06:53:39 | mloskot: | and let things go their way |
| 06:54:12 | mloskot: | strk_off: I mean they build and run without -ffloat-storage on x64 |
| 06:56:17 | strk: | mloskot: I'm on x64 here, I know : ) |
| 06:56:27 | mloskot: | ok |
| 06:56:39 | strk: | the x32 needs -fflloat-storage ( or who knows what other trick ) to make that test pass |
| 06:56:45 | mloskot: | wktraster builds and works so far too |
| 07:00:57 | FrankW: | pracine: btw, I have asked you twice now about working on the raster spec in the wiki - my time window for this has passed for now without an answer, but I might have a chance to return to it if you don't mind. |
| 07:01:14 | strk: | cd test; make check; time make check; |
| 07:01:36 | strk: | normal : real 0m3.023s |
| 07:01:46 | strk: | -ffloat-store: real 0m3.163s |
| 07:02:00 | strk: | need some bigger dataset... |
| 07:02:15 | FrankW: | It's hard to know how statistically significant such a sample is. |
| 07:02:39 | strk: | indeed |
| 07:03:06 | strk: | anyway, one ( 1 ) of the testcases involved in 'make check' used to take 21 seconds before the JTS port... |
| 07:03:18 | strk: | that's to say there's likely lots of improvements that can be done at the algorithmical level |
| 07:03:44 | FrankW: | sweet |
| 07:04:34 | strk: | I wouldn't be concerned about -ffloat-storage, the most improvements can be borrowed from JTS as it gets improved |
| 07:05:24 | strk: | I'm more concerned about catching robustness issues ( the one changing based on -ffloat-storage resulted in a silent failure rather then an exception or something like that ) |
| 07:28:32 | pracine: | FrankW: Where did you ask me that? Here? I`m not here very often... What do you want to do? |
| 07:29:25 | FrankW: | Here ( above ), while you were in the channel. I last wrote: |
| 07:29:41 | FrankW: | pracine: I'm interested in doing a rough or partial port of the WKTRaster specification into the Trac wiki. Are you working on it now? Is it ok for me to take a crack at it? |
| 07:30:13 | FrankW: | Normally when someone includes your handle in the message it should flash your client or highlight things or otherwise inform you that someone is trying to directly speak to you. |
| 07:30:45 | strk: | - electrified keyboard |
| 07:33:42 | pracine: | FrankW: Yes but can I sometimes go to pee? Or be distracted by something else? Or just do not mind too much? |
| 07:34:03 | pracine: | the best way to join me is by email. |
| 07:34:30 | mloskot: | hehe |
| 07:34:35 | : | * FrankW grants permission to pracine to perform bodily functions as required. |
| 07:34:49 | FrankW: | Email is not a very good way to find out if someone is doing something right now. |
| 07:35:02 | FrankW: | Nor to quickly interactively discuss something. |
| 07:35:15 | mloskot: | real hackers do not pee, just dring coffee, eat pizza, grow beard and code ;- ) |
| 07:36:02 | : | * FrankW detects a long term physiologically inconsistency with this theory. |
| 07:36:16 | mloskot: | :- ) |
| 07:37:51 | strk: | real hackers bring the latop to the toilette ( never shake an hacker's hand, or use an hackers keyboard ) |
| 07:38:12 | pracine: | FrankW: We are taking care of it with mloskot |
| 07:38:25 | FrankW: | pracine: the specification document? |
| 07:38:37 | pracine: | FrankW: yes |
| 07:38:49 | FrankW: | ok, I'm glad I didn't just dive in! |
| 07:39:01 | mloskot: | I can take care of lonely dogs only, optionally a nice girl ;- ) |
| 07:54:26 | CIA-34: | strk * r2373 /trunk/source/ ( 8 files in 2 dirs ): New class rename, following JTS |
| 09:05:23 | CIA-34: | pramsey * r4002 /trunk/NEWS: add link to trac for 1.4 |
| 09:11:51 | CIA-34: | pramsey * r4003 /trunk/NEWS: remove tabs |
| 09:14:51 | CIA-34: | pramsey * r4004 /trunk/NEWS: wee reformatting |
| 12:12:12 | mloskot: | bbgeos: status telascience-quick |
| 12:12:12 | bbgeos: | telascience-quick: idle, last build 3h59m34s ago: failed test-xml |
| 12:12:15 | mloskot: | bbgeos: status telascience-full |
| 12:12:15 | bbgeos: | telascience-full: idle, last build 27 seconds ago: failed failed slave lost |
| 12:12:30 | mloskot: | bbgeos: status telascience-stable |
| 12:12:30 | bbgeos: | telascience-stable: idle |
| 12:16:50 | mloskot: | bbgeos: force build telascience-quick |
| 12:16:50 | bbgeos: | build #45 forced |
| 12:16:50 | bbgeos: | I'll give a shout when the build finishes |
| 12:28:06 | mloskot: | libtool is gonna to kill the xblade14 :- ) |
| 12:35:14 | bbgeos: | Hey! build telascience-quick #45 is complete: Failure [failed test-xml] |
| 12:35:14 | bbgeos: | Build details are at http://buildbot.osgeo.org:8506/builders/telascience-quick/builds/45 |
| 12:35:15 | sigq: | Title: Buildbot: telascience-quick Build #45 ( at buildbot.osgeo.org:8506 ) |
| 12:42:13 | mloskot: | strk_off: looks like you haven't added -ffloat-store to default flags, have you? |
| 12:45:32 | strk_off: | nope |
| 12:46:04 | strk_off: | just giving the chance to anyone to start a fight : ) |
| 13:05:57 | mloskot: | : ) |
| 14:57:29 | sigq: | geosfeed: Ticket #248 ( defect created ): build error on trunk <http://trac.osgeo.org/geos/ticket/248> |
| 21:50:21 | CIA-34: | robe * r4005 /trunk/doc/ ( reference.xml xsl/postgis_aggs_mm.xml.xsl ): ADd more curved geometry support functions to list and give curved geometry special index a pretty anchor. |
| 23:27:59 | CIA-34: | robe * r4006 /trunk/doc/installation.xml: Update installation to have link to Windows Compilation guide Nicklas put together. |