_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> Blitz -> Memory Access Violation |
|
| Sat, 03 Aug 2013, 17:10 | |
|
dna |
Hello. The code below gives the error when the loop reaches file #509 for soem reason. There's somthing I'm missing somewhere. I checked to make sure my system was formatted to NTFS since the number is close to the max for FAT -=-=- DNA |
| Sat, 03 Aug 2013, 18:07 | |
HoboBen
|
I'm not sure DNA but is it anything to do with RT$ which you keep appending to? Should it be reset e.g. by RT$ = "" just after the "For FX=100000 To S:" bit?
-=-=- blog | work | code | more code |
| Sat, 03 Aug 2013, 20:24 | |
|
dna |
That was not it. I found the problem in the CLOSE FN$ Line It should have read CLOSE FH1. Now it's running and goes past 509. If it's a BUG and should not do that at all then it needs to be posted wherever the BUG reports for BB are listed. -=-=- DNA |
| Sun, 04 Aug 2013, 04:15 | |
Jayenkai
|
You'll find these things are easier to track down if you use an ounce of clarity in your code. THIS IS MUCH HARDER TO SP0T THE MISTAKE IN. This Is much Easier To f1nd Where the Bug is -=-=- ''Load, Next List!'' 
|
| Sun, 04 Aug 2013, 15:18 | |
|
dna |
You are right again Jay but should that syntax even have compiled?
-=-=- DNA |
| Sun, 04 Aug 2013, 17:35 | |
steve_ancell
|
One major problem that causes hard to find bugz, using semicolon separated code on one line. Try using indentation in blocks of code, you will find bug squashing a whole lot easier.
|
| Mon, 05 Aug 2013, 12:35 | |
|
dna |
You're right again Steve however finding the problem was small compared to why it worked at all. CLOSE FN$ vs CLOSE FH1 The first one should not have worked at all according to the manual that I checked. In my mind the program should have stopped or given a syntax error but it ran until it got up to the 509th file and then it gave an error. That was the bug of which I was referring. -=-=- DNA |
| Mon, 05 Aug 2013, 15:17 | |
|
Jayenkai
|
It's not a bug. A file handle is simply a number. A string, in blitz, can also be interpreted as a number. What's happening is your asking it to "close BANANA" and it goes " I ain't got no banana!!", but decides to continue.. Since the file isn't open, why worry about closing it... This is not a bug, this is a programmer error. If you feel uncomfortable with this methodology, you might want to use a more strict language. -=-=- ''Load, Next List!''
|
| Mon, 05 Aug 2013, 15:22 | |
|
dna |
That I did not know. Do you know if Blitz tries to interpret the string as a number when closing the file? -=-=- DNA |
| Mon, 05 Aug 2013, 15:54 | |
|
Jayenkai
|
These are the sorts of things that I tend to learn through experimenting with a language, and trying out different things. I've found, over the years, that learning and playing and throwing odd things at a language, can result in some interesting methods. I also tend to end up with my own ruleset, when it comes to using the language. At the end of the day, you won't know until you try. Start a small test program, and fling shit at it, until you understand what it's doing, and why it's doing it. Test things. Experiment with the language. See what it is, and isn't doing, and you'll become more comfortable with the ins and outs of the thing you're using. -=-=- ''Load, Next List!''
|
| Mon, 05 Aug 2013, 21:20 | |
|
dna |
I see. So the compiler will do things that are completely undocumented. That's different. -=-=- DNA |
| Tue, 06 Aug 2013, 01:24 | |
rockford
|
They are undocumented because the original compiler author didn't expect the end-user to abuse the system and do things that he wouldn't do  Of course it's the end-user's job to do these things that shouldn't be done. Just for the sake of testing, you know I haven't used Blitz in years now and can't remember - does it have a STRICT/SUPER-STRICT etc. option? |
| Tue, 06 Aug 2013, 12:05 | |
|
dna |
There's no strict or Super Strict in BB or B3D. In BMax there might be a command like that. -=-=- DNA |
|
|
| |||
|
| ||||