Hi, When I compile therion, it appears to compile fine (assuming I haven't made a mistake!), and the green button on the right changes to green, and says "OK", but then it will hang. It is still running, and using lots of CPU, but I cant do anything with it without killing it. This happens either if I compile by hitting F9, or pressing the "compile" button. The same thing happens if I make a mistake and it doesn't compile, but gives me a red "Error" button. When I restart therion, and load back in my files everything works as expected... until I compile it again. I am running therion from debian (unstable) package 5.3.14-1, but I think this also happened in the previous version. Thanks, Jenny ___ Re-sending this message a week later as it didn't appear to reach the list (though i got no bounce message), apologies if you get it twice.
Hi Jenny I get something similar on my Windows versions of 5.3.14 and 5.3.15 With smaller projects, Xtherion compiles normally, and is available for further input immediately. With larger projects, Xtherion compiles normally, button goes green, but it hangs using cpu for some time (minute or so) before becoming available for further input. As the outputs are available for use as soon as they are written to disk it is only a minor annoyance most of the time. Is frustrating if I want to use that instance of Xtherion immediately though. Bruce _____ From: therion-bounces@speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Jenny Black Sent: Tuesday, 10 June 2014 2:26 p.m. To: List for Therion users Subject: [Therion] Therion hanging after compile Hi, When I compile therion, it appears to compile fine (assuming I haven't made a mistake!), and the green button on the right changes to green, and says "OK", but then it will hang. It is still running, and using lots of CPU, but I cant do anything with it without killing it. This happens either if I compile by hitting F9, or pressing the "compile" button. The same thing happens if I make a mistake and it doesn't compile, but gives me a red "Error" button. When I restart therion, and load back in my files everything works as expected... until I compile it again. I am running therion from debian (unstable) package 5.3.14-1, but I think this also happened in the previous version. Thanks, Jenny
There are various things that can make Therion do the described when compiling. I think an empty th2 files is one of them. The are various data sets that work on cave-registry.org.uk. http://www.cave-registry.org.uk/svn/CheddarCatchment is the one I know best. Any thconfig file should work, but they all refer to a cople of files in the root directory, so you might be best to grab it all, see is the copile problem still happens. I am using debian jessie with whatever the latest (as of last wednesday) is from there is and it is compiling for me. (Cannot check as will not be at home until tomorrow) Andrew On 10 Jun 2014 03:26, "Jenny Black" <jenelopy@gmail.com> wrote:
Hi,
When I compile therion, it appears to compile fine (assuming I haven't made a mistake!), and the green button on the right changes to green, and says "OK", but then it will hang. It is still running, and using lots of CPU, but I cant do anything with it without killing it.
This happens either if I compile by hitting F9, or pressing the "compile" button. The same thing happens if I make a mistake and it doesn't compile, but gives me a red "Error" button.
When I restart therion, and load back in my files everything works as expected... until I compile it again.
I am running therion from debian (unstable) package 5.3.14-1, but I think this also happened in the previous version.
Thanks, Jenny
___ Re-sending this message a week later as it didn't appear to reach the list (though i got no bounce message), apologies if you get it twice.
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
Hi, Thanks very much Bruce and Andrew. I tested Andrew's Cheddar files on this linux machine, and therion ran nice and quickly. I then tested my files on my Windows 7 machine at work. Having seen that it would sometimes hang for Bruce for a minute, I was patient and left it after it hung. It hung for 10.5 minutes, but then was OK. The same is true on linux. I wasn't patient enough! Olly has just had a look (thank you Olly!), and in xtherion he changed: set rx {\S*[^\]\s]\s+\[\d+\]} to: set rx {\s\[\d+\]} It now no longer hangs, and runs as well as ever. We're not sure what the regular expression search was for, or whether changing it matters. As far as I can see it doesn't, as the pdf and log files have already been made. Maybe someone with more therion knowledge will know, and if the cahnge is good maybe it can be applied. Thanks, Jenny
+++ Jenny Black [2014-06-11 19:12 +1200]:
Hi, Thanks very much Bruce and Andrew. I tested Andrew's Cheddar files on this linux machine, and therion ran nice and quickly. I then tested my files on my Windows 7 machine at work. Having seen that it would sometimes hang for Bruce for a minute, I was patient and left it after it hung. It hung for 10.5 minutes, but then was OK. The same is true on linux. I wasn't patient enough! Olly has just had a look (thank you Olly!), and in xtherion he changed: set rx {\S*[^\]\s]\s+\[\d+\]} to: set rx {\s\[\d+\]} It now no longer hangs, and runs as well as ever. We're not sure what the regular expression search was for, or whether changing it matters. As far as I can see it doesn't, as the pdf and log files have already been made.
Just noticed this. Well fettled. I've filed a bug in Debian BTS about this so it doesn't get forgotten. I'll do a 5.3.15 upload with this and ol's other fixes in very soon. I was holding out for vtk6 and wx3 fixes but it looks like those might take a little longer to finalise. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
On Fri, Jun 13, 2014 at 11:15:26AM +0100, Wookey wrote:
+++ Jenny Black [2014-06-11 19:12 +1200]:
Olly has just had a look (thank you Olly!), and in xtherion he changed: set rx {\S*[^\]\s]\s+\[\d+\]} to: set rx {\s\[\d+\]} It now no longer hangs, and runs as well as ever. We're not sure what the regular expression search was for, or whether changing it matters. As far as I can see it doesn't, as the pdf and log files have already been made.
Just noticed this. Well fettled. I've filed a bug in Debian BTS about this so it doesn't get forgotten.
I'll do a 5.3.15 upload with this and ol's other fixes in very soon.
I'm not at all confident this fix is correct - my grasp of Tcl is insufficient to understand what the code is actually doing with this regex. All I did was to prune the bit off the start of the pattern which was causing the regex engine to do insane amount of backtracking (which with a large log file could easily result in it taking 10 minutes to run this regex over the whole log). So you might want to wait for comments from Stacho or Martin before shipping this. Cheers, Olly
# Having to wait 10 minutes counts as a major effect on usability Control: severity -1 important On Sat, Jun 14, 2014 at 12:16:27PM +0100, Olly Betts wrote:
On Fri, Jun 13, 2014 at 11:15:26AM +0100, Wookey wrote:
+++ Jenny Black [2014-06-11 19:12 +1200]:
Olly has just had a look (thank you Olly!), and in xtherion he changed: set rx {\S*[^\]\s]\s+\[\d+\]} to: set rx {\s\[\d+\]} It now no longer hangs, and runs as well as ever. We're not sure what the regular expression search was for, or whether changing it matters. As far as I can see it doesn't, as the pdf and log files have already been made.
Just noticed this. Well fettled. I've filed a bug in Debian BTS about this so it doesn't get forgotten.
I'll do a 5.3.15 upload with this and ol's other fixes in very soon.
I'm not at all confident this fix is correct - my grasp of Tcl is insufficient to understand what the code is actually doing with this regex.
All I did was to prune the bit off the start of the pattern which was causing the regex engine to do insane amount of backtracking (which with a large log file could easily result in it taking 10 minutes to run this regex over the whole log).
So you might want to wait for comments from Stacho or Martin before shipping this.
After staring some more, I'm fairly sure my patch doesn't actually constitute a fix (it was never really intended to - I just meant it to show what was taking all the time). But it would be good to fix this before the Debian release freeze, so in the absence of any clues as to what this code is trying to do (as far as I can make out so far, it seems to be parsing a log to get a list of errors to show), I'll sit down with the tcl docs and figure it out. Cheers, Olly
+++ Olly Betts [2014-09-14 11:28 -0300]:
# Having to wait 10 minutes counts as a major effect on usability Control: severity -1 important
On Sat, Jun 14, 2014 at 12:16:27PM +0100, Olly Betts wrote:
On Fri, Jun 13, 2014 at 11:15:26AM +0100, Wookey wrote:
+++ Jenny Black [2014-06-11 19:12 +1200]:
Olly has just had a look (thank you Olly!), and in xtherion he changed: set rx {\S*[^\]\s]\s+\[\d+\]} to: set rx {\s\[\d+\]} It now no longer hangs, and runs as well as ever. We're not sure what the regular expression search was for, or whether changing it matters. As far as I can see it doesn't, as the pdf and log files have already been made.
Just noticed this. Well fettled. I've filed a bug in Debian BTS about this so it doesn't get forgotten.
I'll do a 5.3.15 upload with this and ol's other fixes in very soon.
I'm not at all confident this fix is correct - my grasp of Tcl is insufficient to understand what the code is actually doing with this regex.
All I did was to prune the bit off the start of the pattern which was causing the regex engine to do insane amount of backtracking (which with a large log file could easily result in it taking 10 minutes to run this regex over the whole log).
So you might want to wait for comments from Stacho or Martin before shipping this.
After staring some more, I'm fairly sure my patch doesn't actually constitute a fix (it was never really intended to - I just meant it to show what was taking all the time).
But it would be good to fix this before the Debian release freeze, so in the absence of any clues as to what this code is trying to do (as far as I can make out so far, it seems to be parsing a log to get a list of errors to show), I'll sit down with the tcl docs and figure it out.
This is the only remaining (filed) therion bug (in Debian). Some comment from the authors would be helpful on the right way to fix this, and from users on whether it still exists in the current releas. I'm not sure whether to apply Ol's attached patch at least for the time being or whether that will actually break something (as well as speeding it up). Currently it's not applied. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
I am sorry, I was never able replicate this bug. If it is this regex that causes problems, it can be removed completely. It is used to enable clicking on error source and opening in in appropriate editor. Feature almost never used. Adding "return" just behind proc xth_cp_show_errors {} { in cp_procs.tcl should work. S. On 12 January 2015 at 03:14, Wookey <wookey@wookware.org> wrote:
+++ Olly Betts [2014-09-14 11:28 -0300]:
# Having to wait 10 minutes counts as a major effect on usability Control: severity -1 important
On Sat, Jun 14, 2014 at 12:16:27PM +0100, Olly Betts wrote:
On Fri, Jun 13, 2014 at 11:15:26AM +0100, Wookey wrote:
+++ Jenny Black [2014-06-11 19:12 +1200]:
Olly has just had a look (thank you Olly!), and in xtherion he changed: set rx {\S*[^\]\s]\s+\[\d+\]} to: set rx {\s\[\d+\]} It now no longer hangs, and runs as well as ever. We're not sure what the regular expression search was for, or whether changing it matters. As far as I can see it doesn't, as the pdf and log files have already been made.
Just noticed this. Well fettled. I've filed a bug in Debian BTS about this so it doesn't get forgotten.
I'll do a 5.3.15 upload with this and ol's other fixes in very soon.
I'm not at all confident this fix is correct - my grasp of Tcl is insufficient to understand what the code is actually doing with this regex.
All I did was to prune the bit off the start of the pattern which was causing the regex engine to do insane amount of backtracking (which with a large log file could easily result in it taking 10 minutes to run this regex over the whole log).
So you might want to wait for comments from Stacho or Martin before shipping this.
After staring some more, I'm fairly sure my patch doesn't actually constitute a fix (it was never really intended to - I just meant it to show what was taking all the time).
But it would be good to fix this before the Debian release freeze, so in the absence of any clues as to what this code is trying to do (as far as I can make out so far, it seems to be parsing a log to get a list of errors to show), I'll sit down with the tcl docs and figure it out.
This is the only remaining (filed) therion bug (in Debian). Some comment from the authors would be helpful on the right way to fix this, and from users on whether it still exists in the current releas.
I'm not sure whether to apply Ol's attached patch at least for the time being or whether that will actually break something (as well as speeding it up). Currently it's not applied.
Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
On Mon, Jan 12, 2015 at 04:29:09PM +0100, Stacho Mudrak wrote:
I am sorry, I was never able replicate this bug.
You need a large log file for it to be noticeable, as the problem seems to be that trying to match this pattern causes Tcl's regexp engine to do a lot of backtracking: set rx {\S*[^\]\s]\s+\[\d+\]} I don't really follow the Tcl code around this, but if this is trying to match on lines such as: 2253> input:42871 -- gemse.th [4] Then adding "-- " to the start of the pattern and then adjusting the offsets when highlighting in the text widget should address the problem. The fixed substring "-- " serves as a way to efficiently limit where the regexp engine tries to match the pattern.
If it is this regex that causes problems, it can be removed completely. It is used to enable clicking on error source and opening in in appropriate editor. Feature almost never used.
If you think it's best just to kill it, that's fine, but I can probably package up the example that we hit this on if you want to take a look, and I can certainly test a patch. Cheers, Olly
On Tue, Jan 13, 2015 at 12:01:51AM +0000, Olly Betts wrote:
On Mon, Jan 12, 2015 at 04:29:09PM +0100, Stacho Mudrak wrote:
I am sorry, I was never able replicate this bug.
You need a large log file for it to be noticeable, as the problem seems to be that trying to match this pattern causes Tcl's regexp engine to do a lot of backtracking:
set rx {\S*[^\]\s]\s+\[\d+\]}
I don't really follow the Tcl code around this, but if this is trying to match on lines such as:
2253> input:42871 -- gemse.th [4]
Then adding "-- " to the start of the pattern and then adjusting the offsets when highlighting in the text widget should address the problem. The fixed substring "-- " serves as a way to efficiently limit where the regexp engine tries to match the pattern.
I managed to guess enough tcl and tk to implement this, patch attached which fixes the 10 minute wait while xtherion parse the log, while still creating the links as before (at least as best I can tell). Cheers, Olly
I am sorry, I was never able replicate this bug.
It occurs with most of my large projects and never with small ones.
If it is this regex that causes problems, it can be removed completely. It is used to enable clicking on error source and opening in in appropriate editor. Feature almost never used.
I don't use the feature much at all, but I expect that is because I am quite familiar with Therion and usually have the culprit files open in a text editor already. When I was a new user and had not figured out how to make use of external editors with Therion, I used the feature all the time. I think it is worth fixing the bug, especially if Olly is on the right track. Bruce
participants (6)
-
Andrew Atkinson -
Bruce -
Jenny Black -
Olly Betts -
Stacho Mudrak -
Wookey