Open/Close program crash

Anything QL Software or Programming Related.
User avatar
tofro
Font of All Knowledge
Posts: 2679
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Open/Close program crash

Post by 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
dinox
ROM Dongle
Posts: 28
Joined: Tue Dec 20, 2016 4:59 pm

Re: Open/Close program crash

Post by dinox »

Thanks everyone!

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


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Open/Close program crash

Post by Dave »

Code: Select all

170 SCROLL #5,0,42
Ooooh... Could you use that to traverse a linked list?


User avatar
pjw
QL Wafer Drive
Posts: 1280
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Open/Close program crash

Post by pjw »

[quote="tofro"]

Code: Select all

170 SCROLL #5,0,42
Cheat! :twisted:


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2679
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Open/Close program crash

Post by tofro »

pjw wrote:
tofro wrote:

Code: Select all

170 SCROLL #5,0,42
Cheat! :twisted:
Nah! Hit one evil with another.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
RWAP
RWAP Master
Posts: 2833
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Open/Close program crash

Post by RWAP »

tofro wrote:
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
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: Open/Close program crash

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


User avatar
dinox
ROM Dongle
Posts: 28
Joined: Tue Dec 20, 2016 4:59 pm

Re: Open/Close program crash

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


User avatar
dinox
ROM Dongle
Posts: 28
Joined: Tue Dec 20, 2016 4:59 pm

Re: Open/Close program crash

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


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Open/Close program crash

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


Post Reply