|
Post by felixp7 on Oct 12, 2019 8:10:49 GMT 1
All right, I'm new to BaCon and might be missing something obvious (also using version 3.7.2, so it could be a bug that was fixed in the mean time). When running the attached test program, I get a strange garbage value in the middle of the last DATA row. The curious part is, when the same code is part of a larger program, most values are garbage like that. I'd blame my hardware, but the values returned seem consistent. I'd blame a miscount causing me to read past the end of data, but I double-checked my numbers and all seems fine. Halp! P.S. Couldn't find anything related to that in the forum. Hopefully my search-fu isn't failing me now of all times. Attachments:read-data.bac (5.23 KB)
|
|
|
Post by vovchik on Oct 12, 2019 9:11:52 GMT 1
Dear felixp7, Welcome to the forum, and thanks for your contributions. I checked your test program on Mint 19.2 (64 bit) and everything seems OK. I have attached the output. It is weird that you are getting garbage results. Peter might have an idea... With kind regards, vovchik Attachments:vovdata.txt.tar.gz (389 B)
|
|
|
Post by rikky on Oct 12, 2019 9:25:32 GMT 1
Yes, I checked, you're right. I narrowed it down to I = t_rubble AND Y = 15 AND X = 9 gives => 2147483647 FOR I = 0 TO 7 READ colors$ 'PRINT colors$ NEXT
FOR I = t_nothing TO t_rubble FOR Y = 0 TO 15 FOR X = 0 TO 15 READ idx IF I = t_rubble AND Y = 15 AND X = 9 THEN PRINT STR$(X) & " : "; PRINT idx END IF NEXT 'PRINT NEXT 'PRINT NEXT I swapped the rubble data with the village data Made the CONST t_village = 5 and the CONST t_rubble = 4 And now the error occures in I = t_village AND Y = 15 AND X = 9 gives => 2147483647 Unbelievable. This cannot be real,
|
|
|
Post by rikky on Oct 12, 2019 10:42:40 GMT 1
Ah, It appears that your mountain block has one dataline to short. Rik.
|
|
|
Post by Pjot on Oct 12, 2019 10:52:34 GMT 1
Dear felixp7, Rik was faster than me - well done Rik! @ vovchik: on my Mageia Linux I also got the same result, but this result is coincidence, as the random data seems to be initialized to 0. HTH Peter
|
|
|
Post by felixp7 on Oct 12, 2019 14:11:54 GMT 1
Ha! That's what I get for converting data manually, but it was an expedient. With the missing data line, the test program now works flawlessly. That's the good news. The bad news is, making the exact same correction in my actual code resulted in... unchanged behavior. All the data appeared corrupted, almost from the start. Or rather, all the numeric data; the color names were getting read in just fine. On a whim, I tried moving my entire data block to the start of the program, even before the `INCLUDE "hug.bac"` line... and now it also works fine.
I'd suspect it needs a RESTORE to the start of data, even though it shouldn't, but that was one of the first things I tried before asking for help, and it had no effect. So. Weird. Any ideas?
|
|
|
Post by Pjot on Oct 12, 2019 17:40:04 GMT 1
The bad news is, making the exact same correction in my actual code resulted in... unchanged behavior. All the data appeared corrupted, almost from the start. Any ideas? Well, it might be that you've missed some more lines of DATA. Another common mistake is the counting of array indexes; an array of 16 elements ranges from 0-15. Please check if your code has the correct index counting in place. Apart from these ideas, it will be hard to find a cause without your code. We need to be able to reproduce your error so please provide a code snippet which shows the problem. As you may have observed, we're happy to troubleshoot it further BR Peter
|
|
|
Post by felixp7 on Oct 12, 2019 17:54:59 GMT 1
No I didn't, the data was copy-pasted back and forth, and so was the code that reads it. Besides, as I pointed out above, moving the entire block of data to the very start of my code, with no other changes whatsoever, caused the program to work perfectly all of a sudden. (See the other thread.) In fact we could declare the problem solved... except now we have a mystery on our hands. Why would it matter where the DATA statements are located? The only idea I have is a bug not in BaCon, but in my gcc. But how would I test that?
|
|
|
Post by Pjot on Oct 12, 2019 19:28:23 GMT 1
Hi felixp7, Indeed, when I put the INCLUDE statement before your original 'read-data.bac' code, the reading of the DATA shows unexpected results. The reason for this is that the "hug.bac" context itself also uses READ/DATA statements. The internal housekeeping to keep track of the DATA does not take an INCLUDE statement into account. This is an unexpected side-effect. Some would call it a bug To overcome this problem, you can use LABEL and RESTORE. So you have to change your code as follows: LABEL here
DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 <...more data...>
RESTORE here
READ idx <...etc...>
I have fixed this issue in the latest beta. BR Peter
|
|
|
Post by felixp7 on Oct 13, 2019 6:57:33 GMT 1
Go figure. I suspected restoring to a label would be needed, but placed it after the color name data, because that part was being read in correctly. So it didn't seem to help. Oh well, I know better now. Thank you so much!
|
|