Open/Close program crash

[tofro]

Or, hit a bug with another bug:

instead of

Code: Select all

170 GET #5\0

as in Per's proposal, you can also use

Code: Select all

170 SCROLL #5,0,42

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

[dinox]

Thanks everyone!

There's a few different things to try. I'll let you know how I go on.

[Dave]

Code: Select all

170 SCROLL #5,0,42

Ooooh... Could you use that to traverse a linked list?

[pjw]

[quote="tofro"]

Code: Select all

170 SCROLL #5,0,42

Cheat!

[tofro]

Code: Select all

170 SCROLL #5,0,42

Cheat!

Nah! Hit one evil with another.

Tobias

[RWAP]

The "32768 OPENs per session" is apparently a bug that was only fixed in MG and newer (according to an old article in QL World here: http://www.cowo.ch/downloads/198x_Sincl ... s-SQPP.pdf , see page 21 of August '87, middle column bottom)

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

[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.

[dinox]

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.

[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!

[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.