Hi, there is a new release 5.5.4 of Therion. Release notes: v5.5.4 Therion 5.5.4 (2020-12-15): therion: * added layout-statistics carto|copyright-count * use unique pointers in thdatabase [#296] * added support for 270 to 360 degrees gradient readings * bugs fixed - scrap -walls off not working [#297] - various fixes [#293,294,295,296,298,299,301,302,303,305] thbook: * support smaller page formats (configuration at the line 5 of the file thbook/thbook.tex) loch: * bugs fixed: - fix display of Survex 3D with LRUD [#286] - read splay flag from Survex 3D files [#287] make: * allow -j$N [#283] * allow passing of WX_CONFIG variable [#284] * remove local copies of getline and getopt [#290,306] * small fixes infrastructure * use Github actions instead of Travis CI Best regards, Therion team
On 2020-12-15 18:32 +0100, Therion wrote:
Hi, there is a new release 5.5.4 of Therion.
OK. I have updated the debian patches for this release. Mostly straightforward, and I see the build has been made a little less baroque in various places, which is good :-) makeinstall.tcl changing its behaviour to use $DESTDIR and make it's directories was a little surprise, but easily sorted and a cleaner rules file. I see there is now vtk9 support (since 5.5.2). Debian has vtk9 now (in unstable and testing). Do we get useful things for building against vtk9 rather than vtk7? We'd need to use vtk7 (or vtk6) in backports but as vtk is just for the loch gui and image processing I can't see why different versions would matter. Both vtk7 and vtk9 seem to work. I guess we should move on so I'll move to vtk9 unless someone can think of a good reason why not. One oddness: samples/samples.tcl has had the catch stanza commented out in proc process_files {} #catch { eval "exec $p >&@ stdout" # eval exec "cmd /c $p" #} What's that about? It looks like debugging that accidentally got into the release? The effect is to prevent the samples build from completing unless cavern is actually installed. I could make cavern a build-dependency, but we never have before, and if I just put it back then the samples build as usual (so that's what I've done for now). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
VTK9 should be OK, no need to use older versions. Exception catching has been removed from samples intentionally. We use them as a series of tests when implementing a CMake build system. I did not know, that samples are built on Debian. There is an option to have generated .3d files also present in the samples. But adding cavern as a build-dependency seems to me as a better idea in any case. And using it for the loop closure. At least, until we will find a way to link it as a library if it is possible at all. S. On Wed, 16 Dec 2020 at 02:41, Wookey <wookey@wookware.org> wrote:
On 2020-12-15 18:32 +0100, Therion wrote:
Hi, there is a new release 5.5.4 of Therion.
OK. I have updated the debian patches for this release. Mostly straightforward, and I see the build has been made a little less baroque in various places, which is good :-)
makeinstall.tcl changing its behaviour to use $DESTDIR and make it's directories was a little surprise, but easily sorted and a cleaner rules file.
I see there is now vtk9 support (since 5.5.2). Debian has vtk9 now (in unstable and testing). Do we get useful things for building against vtk9 rather than vtk7? We'd need to use vtk7 (or vtk6) in backports but as vtk is just for the loch gui and image processing I can't see why different versions would matter.
Both vtk7 and vtk9 seem to work. I guess we should move on so I'll move to vtk9 unless someone can think of a good reason why not.
One oddness: samples/samples.tcl has had the catch stanza commented out in proc process_files {} #catch { eval "exec $p >&@ stdout" # eval exec "cmd /c $p" #}
What's that about? It looks like debugging that accidentally got into the release? The effect is to prevent the samples build from completing unless cavern is actually installed. I could make cavern a build-dependency, but we never have before, and if I just put it back then the samples build as usual (so that's what I've done for now).
Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On 2020-12-16 18:45 +0100, Stacho Mudrak wrote:
VTK9 should be OK, no need to use older versions.
Done. Therion is stuck waiting for current vtk package to transition to testing, and both are stuck because the mipsel buildds can't keep up but it should be OK in a week or so.
Exception catching has been removed from samples intentionally. We use them as a series of tests when implementing a CMake build system. I did not know, that samples are built on Debian.
We've been doing that for many, many years as it provides some useful local documentation (although, checking, I see that the resolution of some of the images is too low to be useful). I chose not to use cavern so that the back-up calculation system in therion got tested. That seemed more appropriate for the therion build. It also simplified the build-dependency tree a little.
There is an option to have generated .3d files also present in the samples. But adding cavern as a build-dependency seems to me as a better idea in any case. And using it for the loop closure.
OK. But then the therion back-up functionality may hardly ever get tested? Now that we have autopackage tests (tests run after the build on the installed packages), I guess we could run some tests both with and without cavern installed (maybe - not sure if we have that level of control). But we don't have the sample sources available to run a runtime, only at build-time. Using cavern is the 'normal' case so maybe it's better to do that at build-time too. I'll try it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
participants (3)
-
Stacho Mudrak -
Therion -
Wookey