Page 2 of 3
Re: Open/Close program crash
Posted: Thu May 10, 2018 6:03 pm
by tofro
Or, hit a bug with another bug:
instead of
as in Per's proposal, you can also use
which does the same thing (re-positioning the file pointer to 0 without TK2 by perusing another bug in the SuperBASIC interpreter
- I think that's just fair and fixes it in pure Sinclair style...
Tobias
Re: Open/Close program crash
Posted: Thu May 10, 2018 6:28 pm
by dinox
Thanks everyone!
There's a few different things to try. I'll let you know how I go on.
Re: Open/Close program crash
Posted: Thu May 10, 2018 6:57 pm
by Dave
Ooooh... Could you use that to traverse a linked list?
Re: Open/Close program crash
Posted: Thu May 10, 2018 7:14 pm
by pjw
[quote="tofro"]
Cheat!
Re: Open/Close program crash
Posted: Thu May 10, 2018 7:24 pm
by tofro
pjw wrote:tofro wrote:Cheat!
Nah! Hit one evil with another.
Tobias
Re: Open/Close program crash
Posted: Thu May 10, 2018 8:56 pm
by RWAP
Or even read the section on the OPEN command in the SBASIC / SuperBASIC Reference Manual which does indeed note this bug:
https://superbasic-manual.readthedocs.i ... .html#open
Re: Open/Close program crash
Posted: Thu May 10, 2018 11:56 pm
by EmmBee
Hi,
Your listing it is not exactly clear where you test for EOF(#5). Do you make this test at the beginning or the end of the loop? There is a comment about processing the data, but of course, it is quite common to add comments to the code about what this block will do. There is also a count added. The question is are you testing for EOF(#5) before or after the first piece of data has been read? You may indeed be doing this correctly, but it is far from clear going by how you have worded this. I hope you agree. The test for EOF must be made at the very beginning of the loop in case the file is empty. If this test is not made and the file is empty, then an error would occur. There are other things that can go wrong with a file, and it is usual to test for integrity before opening such. Do you make such tests? All important software usually does. On the QL, one of the best tools to use is DEVICE_STATUS from the Turbo toolkit. In case you are not already using this, it is well worth the time and effort to acquire and start using. This is how you could use such ...
Code: Select all
ds = DEVICE_STATUS(1,"flp1_") : IF ds<0 : PRINT #0,"flp1_ "; : REPORT ds : STOP
OPEN_OVER #4,"ram2_map_files" : WDIR #4, "flp1_"
GET #4\0
REPeat files
IF EOF(#4) : EXIT files
INPUT #4, f$ : file$ = "flp1_" & f$
ds = DEVICE_STATUS(1,file$)
IF ds < 0 : PRINT #0,file$ !!; : REPORT ds : NEXT files
OPEN_IN #5,file$
REPeat details
IF EOF(#5) : EXIT details
INPUT #5, xy$
process xy$
END REPeat details
CLOSE #5
END REPeat files
CLOSE #4
PRINT #0,"map data processed"
You mention FOPEN won't work. This is interesting. Would you like to expand? Can you give us some examples, please?
FOPEN and FOP_IN are part of the toolkit 2. They both support the default data device, and so can sometimes give unexpected results.
DEVICE_STATUS is far easier to use, as you have to use the full device plus filename, and so less confusion can result. I wish you the best with your project - hundreds of files about map data.
Re: Open/Close program crash
Posted: Fri May 11, 2018 1:25 pm
by dinox
EmmBee wrote:Hi,
Your listing it is not exactly clear where you test for EOF(#5). Do you make this test at the beginning or the end of the loop? There is a comment about processing the data, but of course, it is quite common to add comments to the code about what this block will do. There is also a count added. The question is are you testing for EOF(#5) before or after the first piece of data has been read? You may indeed be doing this correctly, but it is far from clear going by how you have worded this. I hope you agree. The test for EOF must be made at the very beginning of the loop in case the file is empty. If this test is not made and the file is empty, then an error would occur. There are other things that can go wrong with a file, and it is usual to test for integrity before opening such. Do you make such tests? All important software usually does. On the QL, one of the best tools to use is DEVICE_STATUS from the Turbo toolkit. In case you are not already using this, it is well worth the time and effort to acquire and start using. This is how you could use such ...
Code: Select all
ds = DEVICE_STATUS(1,"flp1_") : IF ds<0 : PRINT #0,"flp1_ "; : REPORT ds : STOP
OPEN_OVER #4,"ram2_map_files" : WDIR #4, "flp1_"
GET #4\0
REPeat files
IF EOF(#4) : EXIT files
INPUT #4, f$ : file$ = "flp1_" & f$
ds = DEVICE_STATUS(1,file$)
IF ds < 0 : PRINT #0,file$ !!; : REPORT ds : NEXT files
OPEN_IN #5,file$
REPeat details
IF EOF(#5) : EXIT details
INPUT #5, xy$
process xy$
END REPeat details
CLOSE #5
END REPeat files
CLOSE #4
PRINT #0,"map data processed"
You mention FOPEN won't work. This is interesting. Would you like to expand? Can you give us some examples, please?
FOPEN and FOP_IN are part of the toolkit 2. They both support the default data device, and so can sometimes give unexpected results.
DEVICE_STATUS is far easier to use, as you have to use the full device plus filename, and so less confusion can result. I wish you the best with your project - hundreds of files about map data.
The program was just a quick one to demonstrate what I thought was the bug. Not that I can use that as an excuse since most of my code is untidy.
I forgot to load TK when I tried FOPEN. But I've moved on from that now anyway - see next post.
Re: Open/Close program crash
Posted: Fri May 11, 2018 1:40 pm
by dinox
BUG REMOVED...
Thanks for all the help everyone!
My program has been running for nearly a day now without crashing so I think the problem is solved. The bug was a limit to how many times a file could be opened (32768 OPENs). This bug had already been removed in the MG rom so I just used that newer version. Problem fixed!
Re: Open/Close program crash
Posted: Fri May 11, 2018 5:53 pm
by Dave
I think the bug is also removed in Minerva. Minerva is quite a bit more optimized over MG ROMs too, so you'd get a noticeable performance boost.