Thanks Stacho That solves the problem. Bruce From: Therion <therion-bounces@speleo.sk> On Behalf Of Stacho Mudrak Sent: Tuesday, 22 December 2020 05:19 To: List for Therion users <therion@speleo.sk> Subject: Re: [Therion] statistics <explo/topo/carto/copyright> number untrapped error Thanks a lot Bruce, looks like a bull's eye. I was able to replicate your error and fix it. Could you pls try again, it should be fixed in <https://github.com/therion/therion/commit/4e3623ea6e7f876a67ef5f116ff0edb4cd5fe65e> 4e3623e. S. On Mon, 21 Dec 2020 at 10:23, Stacho Mudrak <lists@group-s.sk <mailto:lists@group-s.sk> > wrote: Thanks a lot Bruce, untrapped error should never occur. I will try to investigate your findings with greater numbers then surveyors and let you know. S. On Mon, Dec 21, 2020, 08:38 Bruce Mutton <bruce@tomo.co.nz <mailto:bruce@tomo.co.nz> > wrote: Stacho Sorry for the delay. Looks like version 5.5.4 and 647dcea both manifest the same problem at my end. It occurs for both plan and extended elevation pdf outputs. For these ‘failures’ I have the number set to 10, and in some cases the number of explorers, surveyors or cartographers is less than 10. Trial and error with some variations suggests that the syntax ‘statistics explo|topo|carto|copyright <number>’ will always fail if <number> is greater than the actual number of any one of those properties. The failure appears to be untrapped and stops processing unceremoniously. I think that if there are only 3 surveyors, but <number> is >= 3, then there should not be any error condition, and the output should be produced listing the 3 properties. So it seems like a bug to me. Bruce From: Therion <therion-bounces@speleo.sk <mailto:therion-bounces@speleo.sk> > On Behalf Of Stacho Mudrak Sent: Sunday, 13 December 2020 21:15 To: List for Therion users <therion@speleo.sk <mailto:therion@speleo.sk> > Subject: Re: [Therion] statistics <explo/topo/carto/copyright> number untrapped error Thanks Bruce for this feedback. In the latest snapshot, I have tried to fix this error by refactoring the whole problematic code. Could you please try, whether it still fails? S. On Sun, 29 Nov 2020 at 06:14, Bruce Mutton <bruce@tomo.co.nz <mailto:bruce@tomo.co.nz> > wrote: Stacho Further to the untrapped error I mentioned last week… Looks like it is counting scraps correctly. The following statements… statistics carto all statistics carto-count hide (or on or off) … work perfectly. One thing that does seem to be a problem however. The syntax… statistics <explo/topo/carto/copyright> number … is giving me problems. They all seem to result in what seems to be an untrapped error, and truncating the therion.log file in random locations. For example this is what I have been trying… statistics topo 10 statistics topo-length hide I checked with the previous recent version, 552f923 and after removing all the carto-count statements, I get the same behaviour, an untrapped error. So I think the carto-count is working perfectly and I have just unearthed a different problem. Having left the problem for a few days (and rebooting a number of times) I thought I’d try my ‘top 10’ statistics layout (as in the attached LayoutStatisticsReporting.thc file). I ran my thconfig a number of times. For a given input, the point at which the log file truncates seems to be consistent. The file log5 is what I get with a successful compile with all of the statistics. The file log1 is what statistics <whatever> 10 gives me. Thinking that the scraps reported near either side of the log file truncation might be associated, I commented them out of the map. The file log04 shows what happens then – the truncation just occurs a few more characters along the file. Bruce _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion