Invalid length reading error reported due to (valid) scrap definition
Hello I have a perplexing error, this time around after a complicated git merge, and I have had similar on one occasion a while back. I think I resolved by omitting the file, which is not really a resolution. This time I need a better solution! On compiling a thconfig I get an error: C:\Program Files (x86)\Therion\therion.exe: error -- 11-DeerPlan.th2 [8] -- invalid length reading -- -projection The start of file 11-DeerPlan.th2 is like this: encoding utf-8 ##XTHERION## xth_me_area_adjust -160.83 -127.28 965.01 763.65 ##XTHERION## xth_me_area_zoom_to 200 ##XTHERION## xth_me_image_insert {502.386220472 1 1.0} {626.342677165 11.8} ptopoDeer/11-Deer_p.xvi 0 {} scrap 11-DeerPlan-s1 -projection plan -station-names []@11 -author 2023.02.26 "B Mutton" -copyright 2023 NZSS -scale [0 0 787.4 787.4 0 0 10 10 m] point 10.25 711.5 label -text "Deer Pot" -align l -scale xl point 186.25 712.5 anchor -align r This is a well established scrap in a well established file in a well established project and both of the parent branches compiled without issue through many editing and versioning iterations. Comparison with both of the parent git branches do not suggest any changes that should trigger such an error - at least I have not found it yet. I have checked this file and all calling it for closed blocks (scrap endscrap, map endmap, centreline endcentreline, survey end survey etc) because long ago Therion used to complain in a similar manner if such blocks were not closed (reporting survey data type error due to a drawing file error - illogical). Since this is the second time in a month I've experienced this type of 'illogical' error after nothing like it for years, I'm wondering if anyone else has, or has a clue as to what might be happening? Bruce Using: therion 6.1.8 (2023-06-14) Windows 10 Home 22H2 GitHub desktop 3.2.7 (x64) TortoiseGit 2.14.0
OK, found it. It was as I suspected a missing endcentreline in the file called by an input statement immediately preceding the statement 'input 11-DeerPlan.th2'. So my mistake, I did not check as well as I thought I had. I wonder if Therion could check for endcentreline statements (where they might normally be expected) and if not found by the end of a file, then issue a warning "missing endcentreline in file xxx.th". Thanks Bruce From: Therion <therion-bounces@speleo.sk> On Behalf Of Bruce Mutton Sent: Monday, 7 August 2023 15:36 To: 'List for Therion users' <therion@speleo.sk> Subject: [Therion] Invalid length reading error reported due to (valid) scrap definition Hello I have a perplexing error, this time around after a complicated git merge, and I have had similar on one occasion a while back. I think I resolved by omitting the file, which is not really a resolution. This time I need a better solution! On compiling a thconfig I get an error: C:\Program Files (x86)\Therion\therion.exe: error -- 11-DeerPlan.th2 [8] -- invalid length reading -- -projection The start of file 11-DeerPlan.th2 is like this: encoding utf-8 ##XTHERION## xth_me_area_adjust -160.83 -127.28 965.01 763.65 ##XTHERION## xth_me_area_zoom_to 200 ##XTHERION## xth_me_image_insert {502.386220472 1 1.0} {626.342677165 11.8} ptopoDeer/11-Deer_p.xvi 0 {} scrap 11-DeerPlan-s1 -projection plan -station-names []@11 -author 2023.02.26 "B Mutton" -copyright 2023 NZSS -scale [0 0 787.4 787.4 0 0 10 10 m] point 10.25 711.5 label -text "Deer Pot" -align l -scale xl point 186.25 712.5 anchor -align r This is a well established scrap in a well established file in a well established project and both of the parent branches compiled without issue through many editing and versioning iterations. Comparison with both of the parent git branches do not suggest any changes that should trigger such an error - at least I have not found it yet. I have checked this file and all calling it for closed blocks (scrap endscrap, map endmap, centreline endcentreline, survey end survey etc) because long ago Therion used to complain in a similar manner if such blocks were not closed (reporting survey data type error due to a drawing file error - illogical). Since this is the second time in a month I've experienced this type of 'illogical' error after nothing like it for years, I'm wondering if anyone else has, or has a clue as to what might be happening? Bruce Using: therion 6.1.8 (2023-06-14) Windows 10 Home 22H2 GitHub desktop 3.2.7 (x64) TortoiseGit 2.14.0
Hm, I'm not sure this will not trigger alot of false positives in some of my projects, where structure is heavily divided into smaller files which are inputted to form a whole complete. But I want to second you: the error message shown is very not-intuitive to find the root cause. So maybe we should add some syntax sanity checks to the overall strcture. When an encenterline is missing somewhere, this is some sort of unbalanced braces problem like in a C compiler; so mabye therion should output at the end that there is unbalanced centerline/endcenterline numbers (or all other such structures, in this regard) in the input data. Am 2023-08-07 7:38, schrieb Bruce Mutton:
OK, found it. It was as I suspected a missing endcentreline in the file called by an input statement immediately preceding the statement 'input 11-DeerPlan.th2'.
So my mistake, I did not check as well as I thought I had.
I wonder if Therion could check for endcentreline statements (where they might normally be expected) and if not found by the end of a file, then issue a warning "missing endcentreline in file xxx.th".
Thanks
Bruce
From: Therion <therion-bounces@speleo.sk> On Behalf Of Bruce Mutton Sent: Monday, 7 August 2023 15:36 To: 'List for Therion users' <therion@speleo.sk> Subject: [Therion] Invalid length reading error reported due to (valid) scrap definition
Hello
I have a perplexing error, this time around after a complicated git merge, and I have had similar on one occasion a while back.
I think I resolved by omitting the file, which is not really a resolution. This time I need a better solution!
On compiling a thconfig I get an error:
C:\Program Files (x86)\Therion\therion.exe: error -- 11-DeerPlan.th2 [8] -- invalid length reading -- -projection
The start of file 11-DeerPlan.th2 is like this:
encoding utf-8
##XTHERION## xth_me_area_adjust -160.83 -127.28 965.01 763.65
##XTHERION## xth_me_area_zoom_to 200
##XTHERION## xth_me_image_insert {502.386220472 1 1.0} {626.342677165 11.8} ptopoDeer/11-Deer_p.xvi 0 {}
scrap 11-DeerPlan-s1 -projection plan -station-names []@11 -author 2023.02.26 "B Mutton" -copyright 2023 NZSS -scale [0 0 787.4 787.4 0 0 10 10 m]
point 10.25 711.5 label -text "Deer Pot" -align l -scale xl
point 186.25 712.5 anchor -align r
This is a well established scrap in a well established file in a well established project and both of the parent branches compiled without issue through many editing and versioning iterations. Comparison with both of the parent git branches do not suggest any changes that should trigger such an error - at least I have not found it yet.
I have checked this file and all calling it for closed blocks (scrap endscrap, map endmap, centreline endcentreline, survey end survey etc) because long ago Therion used to complain in a similar manner if such blocks were not closed (reporting survey data type error due to a drawing file error - illogical).
Since this is the second time in a month I've experienced this type of 'illogical' error after nothing like it for years, I'm wondering if anyone else has, or has a clue as to what might be happening?
Bruce
Using:
therion 6.1.8 (2023-06-14)
Windows 10 Home 22H2
GitHub desktop 3.2.7 (x64)
TortoiseGit 2.14.0 _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On 2023-08-07 08:38 +0200, Benedikt Hallinger wrote:
Hm, I'm not sure this will trigger a lot of false positives in some of my projects, where structure is heavily divided into smaller files which are inputted to form a whole complete.
Right. centreline doesn't have to be balanced on a per-file basis. Survey structure and file structure are independent in Therion same as they are in survex.
When an encenterline is missing somewhere, this is some sort of unbalanced braces problem like in a C compiler; so mabye therion should output at the end that there is unbalanced centerline/endcenterline numbers (or all other such structures, in this regard) in the input data.
Right if it errored on unbalanced start/end primitives and said which files were unbalanced that should narrow it down enough to find the mistake (because on most projects most files will be balanced?). I'm not sure if there is a better interface/algorithm? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
participants (3)
-
Benedikt Hallinger -
Bruce Mutton -
Wookey