Further to my earlier report today I looked into the matter and found :
4270 STOP:L=L+1:L$(L)=LEFT$(N$,77): IF YI=ANT THEN CAMM(L)=1:IF CHP>4 THEN 4280 ELSE QDIV$(L)=MID$(N$,20,13):NANB$(L)=MID$(N$,57,7) ELSE MID$(L$(L),20,13)=QDIV$(L):MID$(L$(L),57,7)=NANB$(L) ?n$,left$(n$,77) ADFCACARREF120172DBC.1.50496042529 19.229 22.632.823.91 0 1 0 1 0 CARREF ADFCACARREF120172DBC.1.50496042529 19.229 22.632.823.91 0 1 0 1 0 l$(1)=left$(n$,77):?l$(1)
It appears that one cannot use the last line more than 21 times in the loop (problem with stack overflow ?bad resetting?)
investigating further more : when i reran my program ,it bugs in the same chained part for a similar reason i.e. the following instruction x$=ldv$+fic$+y$ seems not realised ,although ldv$ , fic$ and y$ are not null strings ,x$ apparently is null when using ?x$ but ?len(x$) presents a correct answer corresponding to len(ldv$)+len(fic$)+len(y$) meaning that x$ contains blanks instead of what ix expected
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If at all possible, having the full program code would be really helpful to reproduce the issue since I think it depends on the layout of variables (such as N$, YI, CAMM() etc) in memory which is set up earlier. The error may come to the fore in this line but the root cause is likely somewhere earlier.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand your point ,but i'm not competent to provide you with such info .I have no clue whatsoever as how to get at this info .i'm ready to follow your instructions to send this data toward solving the bug
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, thanks for your reply! What I'm looking for is the program you're trying to run - the .BAS file, or files if there is more than one - so that I can run it on my computer so that I can see the problem for myself, and do some experimenting to find out.
I have an idea what might be going on - your reports suggest the problem may be triggered when BASIC does garbage collection of its strings when the memory fills up, in particular after a CHAIN, and FIELD may be involved. However I need to try for myself to get to the bottom of it.
Cheers
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please find here enclosed the .bas programs used together with necessary data files .One should know :
1 All files are located in Ramdrive z:
2 Key off-Start with pbxupdat
3 file not found in 70 .Note that len(x$)=10 is consistent with "z:\usuel16" that should be the content of x$ .However ?x$ doesn't show any content
Hi, I had a look at this but can't quite reproduce the issue yet. I think I know what may be the cause (I've found an error in PC-BASIC relating to arrays of strings) but I'm not sure it''s the same problem you have.
What options (on the command line or in PCBASIC.INI) do you use? It seems I need at least max-reclen=256 and max-files=9 for it to run at all, but when I try KEY OFF:RUN "PBXUPDAT" I get File not found in 3310 and the filenames it tries to open for input in 3310 do indeed not exist (yh.txt, yo.txt or abct.txt). But that is not the same as what you're seeing, so I'm doing something different, but not sure what? Do I need these files to be available too?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 15.08.6 - Every file is located in Ramdrive z: - You must load"z:pbxupdat -You need .txt files to progress .- PCBASIC : reclen=256 and / max files=9 arecorrect + shell=native + map-drives=true - here attached files.txt (also in z:)
I tried DOSBOX and found that some lines must be shortened (few are 255 long not compatible with emulators ?)
on another end I noticed that function DOSKEY doesn't work (once shell"ed")
Is it possible to speed up the process ?
Hi, thanks for these, that will sort the File not found problem. I will try again to see if I can get the error you see.
Do you have the issue with long lines in any of the programs sent, or have these already been modified? There was a problem with lines of 255 characters in the prievious version, but this had been fixed in version 15.08.6. If there are more problems with lines of 255 characters in PC-BASIC could you please send me a file that shows the issue (or let me know which of the files you've already sent shows it)?
With shell=native the SHELL command simply shows you a Windows command prompt. Therefore things like DOSKEY won't work as they are no longer part of Windows. Other DOS commands like SHARE and GRAPHICS will not work or have no effect on PC-BASIC either.
This is a fundamental limitation: PC-BASIC is not a DOS emulator, it just runs BASIC programs. If you depend on DOS or machine code emulation you'll need to use something like DOSBox or a virtual machine solution with the original MS-DOS and GW-BASIC.
If with speeding up the process you refer to finding this bug, I'm afraid there's not much more I can do. This is (currently, at least) a project developed by one person in my spare time; I can only put in time as my job (and, indeed, my life) allows. I'll surely find this bug at some point, but so far it's proving to be complex so it will take a while.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Back to you .
You misinterpret my sentence regarding speed .Nothing to do with you debugging .
I meant cpu speed to :speeding up computer calcuulus !
On the other hand no files I sent you were corrected for line length : I found out this problem trying to adapt my progam to DOSBOX .Nothing with PCBASIC appeared relately to line lengfth .I just mentionned this to provide you with a possible lead .
I appreciate very much your efforts toward solving my problem .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, OK - I had misunderstood. You can't make it run faster, PC-BASIC is intrinsically quite slow, mainly because it runs in Python which is itself an interpreted language and I haven't really optimised it much. I have some ideas to make it faster but it will be a long time before that goes anywhere.
Thanks for clarifying the line length issue, strange that this happens in DOSBox - I don't think it is related to the bug you see though.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Further to my earlier report today I looked into the matter and found :
4270 STOP:L=L+1:L$(L)=LEFT$(N$,77): IF YI=ANT THEN CAMM(L)=1:IF CHP>4 THEN 4280 ELSE QDIV$(L)=MID$(N$,20,13):NANB$(L)=MID$(N$,57,7) ELSE MID$(L$(L),20,13)=QDIV$(L):MID$(L$(L),57,7)=NANB$(L) ?n$,left$(n$,77) ADFCACARREF120172DBC.1.50496042529 19.229 22.632.823.91 0 1 0 1 0 CARREF ADFCACARREF120172DBC.1.50496042529 19.229 22.632.823.91 0 1 0 1 0 l$(1)=left$(n$,77):?l$(1)
It appears that one cannot use the last line more than 21 times in the loop (problem with stack overflow ?bad resetting?)
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
investigating further more : when i reran my program ,it bugs in the same chained part for a similar reason i.e. the following instruction x$=ldv$+fic$+y$ seems not realised ,although ldv$ , fic$ and y$ are not null strings ,x$ apparently is null when using ?x$ but ?len(x$) presents a correct answer corresponding to len(ldv$)+len(fic$)+len(y$) meaning that x$ contains blanks instead of what ix expected
Thanks again!
If at all possible, having the full program code would be really helpful to reproduce the issue since I think it depends on the layout of variables (such as
N$,YI,CAMM()etc) in memory which is set up earlier. The error may come to the fore in this line but the root cause is likely somewhere earlier.Rob
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I understand your point ,but i'm not competent to provide you with such info .I have no clue whatsoever as how to get at this info .i'm ready to follow your instructions to send this data toward solving the bug
Hi, thanks for your reply! What I'm looking for is the program you're trying to run - the
.BASfile, or files if there is more than one - so that I can run it on my computer so that I can see the problem for myself, and do some experimenting to find out.I have an idea what might be going on - your reports suggest the problem may be triggered when BASIC does garbage collection of its strings when the memory fills up, in particular after a
CHAIN, andFIELDmay be involved. However I need to try for myself to get to the bottom of it.Cheers
Rob
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Please find here enclosed the .bas programs used together with necessary data files .One should know :
1 All files are located in Ramdrive z:
2 Key off-Start with pbxupdat
3 file not found in 70 .Note that len(x$)=10 is consistent with "z:\usuel16" that should be the content of x$ .However ?x$ doesn't show any content
Hi, thanks, that's exactly what I need. I'll try to reproduce and fix the bug. Will let you know if I need more info.
Cheers,
Rob
Hi, I had a look at this but can't quite reproduce the issue yet. I think I know what may be the cause (I've found an error in PC-BASIC relating to arrays of strings) but I'm not sure it''s the same problem you have.
What options (on the command line or in PCBASIC.INI) do you use? It seems I need at least
max-reclen=256andmax-files=9for it to run at all, but when I tryKEY OFF:RUN "PBXUPDAT"I getFile not found in 3310and the filenames it tries to open for input in 3310 do indeed not exist (yh.txt,yo.txtorabct.txt). But that is not the same as what you're seeing, so I'm doing something different, but not sure what? Do I need these files to be available too?Also, which version of PC-BASIC are you using and which operating system?
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Version 15.08.6 - Every file is located in Ramdrive z: - You must load"z:pbxupdat -You need .txt files to progress .- PCBASIC : reclen=256 and / max files=9 arecorrect + shell=native + map-drives=true - here attached files.txt (also in z:)
I tried DOSBOX and found that some lines must be shortened (few are 255 long not compatible with emulators ?)
on another end I noticed that function DOSKEY doesn't work (once shell"ed")
Is it possible to speed up the process ?
Hi, thanks for these, that will sort the
File not foundproblem. I will try again to see if I can get the error you see.Do you have the issue with long lines in any of the programs sent, or have these already been modified? There was a problem with lines of 255 characters in the prievious version, but this had been fixed in version 15.08.6. If there are more problems with lines of 255 characters in PC-BASIC could you please send me a file that shows the issue (or let me know which of the files you've already sent shows it)?
With
shell=nativetheSHELLcommand simply shows you a Windows command prompt. Therefore things likeDOSKEYwon't work as they are no longer part of Windows. Other DOS commands likeSHAREandGRAPHICSwill not work or have no effect on PC-BASIC either.This is a fundamental limitation: PC-BASIC is not a DOS emulator, it just runs BASIC programs. If you depend on DOS or machine code emulation you'll need to use something like DOSBox or a virtual machine solution with the original MS-DOS and GW-BASIC.
If with speeding up the process you refer to finding this bug, I'm afraid there's not much more I can do. This is (currently, at least) a project developed by one person in my spare time; I can only put in time as my job (and, indeed, my life) allows. I'll surely find this bug at some point, but so far it's proving to be complex so it will take a while.
Rob
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Back to you .
You misinterpret my sentence regarding speed .Nothing to do with you debugging .
I meant cpu speed to :speeding up computer calcuulus !
On the other hand no files I sent you were corrected for line length : I found out this problem trying to adapt my progam to DOSBOX .Nothing with PCBASIC appeared relately to line lengfth .I just mentionned this to provide you with a possible lead .
I appreciate very much your efforts toward solving my problem .
Ah, OK - I had misunderstood. You can't make it run faster, PC-BASIC is intrinsically quite slow, mainly because it runs in Python which is itself an interpreted language and I haven't really optimised it much. I have some ideas to make it faster but it will be a long time before that goes anywhere.
Thanks for clarifying the line length issue, strange that this happens in DOSBox - I don't think it is related to the bug you see though.
Rob
Hi, just to let you know I've found the problem. I'm still working on a solution - it's a bit subtle.
Rob
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thanks keeping me informed .Hope subtelty doesn't involve complexity and/or difficulty .Good luck fixing this bug .
I've fixed the string bug - as far as I can check it it now runs the program correctly. Check out release 15.08.7, let me know if all OK.
Cheers
Rob