I have a little difference when opening a file in RANDOM with the last FIELD Block. GWBASIC applies nulls to the last block to complete the specified bytes allocated to that block (e.g. FIELD #1, 128 as D$), while PC-BASIC do not complete with nulls the length of the last block leaving it with the right amount of bytes left. If GWBASIC prints the length of the las block < ? len(D$) > it will answer with 128 (as specified in the FIELD statement); while PC-BASIC will answer with 55 (or what’s left of the last block).
For example, lets say that BBALL.BAS has 1591 bytes.
10 OPEN “BBALL.BAS” FOR RANDOM AS #1: FIELD #1, 128 AS D$
20 A=LOF(1): B=INT(A/128)+1: ‘ +1 because there’s data left in the last block
30 GET #1, B
40 PRINT LEN(D$): CLOSE: END
55
OK
Which in GWBASIC the answer will be:
128
OK
Of course we can work around this situation, but if you’re looking for PC-BASIC to be as much as possible as GWBASIC, there’s a tiny bug. In my personal opinion for me it’s not a bug, it just reports the right amount of bytes left in the last block, but any program will cause a stop when using extra bytes in the last block when it’s not there (e.g. MID$(D$, 128,1) ).
Ronald.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I found another bug to look at. By the same situation if the variable D$ (from the FIELD statement) is used for adding extra bytes to compensate any length (e.g. D$ = D$ + CHR$(0) ), then the assigned variable D$ is no longer useful with the GET #1, (any number) to continue with the field blocks. This let the variable D$ useless to the GET statement. This is important.
Ronald.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ronald, thanks for reporting this. Interestingly, the first one is a bug while the second one is correct behaviour (which is only a problem because of the first bug).
As to the first issue, the FIELD string should always be of the declared length (as in GW-BASIC) so this is a bug. I think I've spotted the cause so wil fix soon.
The second issue is in fact expected behaviour. If you assign to a field variable, you break the connection with the field buffer, so the contents will not be read or written with GET or PUT anymore. The way to change the variable without breaking the connection with the FIELD is by using LSET and RSET statements. In your example, you could do LSET D$="a" which should change D$ to "a" plus 127 spaces to fill up. Note that (if the first bug was not there) it would not make sense to do LSET D$=D$+chr$(0) as D$ should be already 128 characters long.
Thanks again for digging up these issues, this is very helpful as I have to divide my time between testing, coding and my day job :)
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ronald, if you want to try the version in git you can get a ZIP of the source code at https://github.com/robhagemans/pcbasic/archive/release-15.08.zip or, if you have git installed, you can get a copy of the repository directly with git clone https://github.com/robhagemans/pcbasic.git. That way you can always stay up to date with the latest code. Note that the master branch is the current development branch and may not be in a working state.
Thank you for everything. Since, I have no knowledge with Python and less compiling them (probably in a near future I shall learn) I'll, just, wait happily when you post a release for it, again thank you! Ron.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a little difference when opening a file in RANDOM with the last FIELD Block. GWBASIC applies nulls to the last block to complete the specified bytes allocated to that block (e.g. FIELD #1, 128 as D$), while PC-BASIC do not complete with nulls the length of the last block leaving it with the right amount of bytes left. If GWBASIC prints the length of the las block < ? len(D$) > it will answer with 128 (as specified in the FIELD statement); while PC-BASIC will answer with 55 (or what’s left of the last block).
For example, lets say that BBALL.BAS has 1591 bytes.
10 OPEN “BBALL.BAS” FOR RANDOM AS #1: FIELD #1, 128 AS D$
20 A=LOF(1): B=INT(A/128)+1: ‘ +1 because there’s data left in the last block
30 GET #1, B
40 PRINT LEN(D$): CLOSE: END
55
OK
Which in GWBASIC the answer will be:
128
OK
Ronald.
I think I found another bug to look at. By the same situation if the variable D$ (from the FIELD statement) is used for adding extra bytes to compensate any length (e.g. D$ = D$ + CHR$(0) ), then the assigned variable D$ is no longer useful with the GET #1, (any number) to continue with the field blocks. This let the variable D$ useless to the GET statement. This is important.
Ronald.
Hi Ronald, thanks for reporting this. Interestingly, the first one is a bug while the second one is correct behaviour (which is only a problem because of the first bug).
As to the first issue, the FIELD string should always be of the declared length (as in GW-BASIC) so this is a bug. I think I've spotted the cause so wil fix soon.
The second issue is in fact expected behaviour. If you assign to a field variable, you break the connection with the field buffer, so the contents will not be read or written with GET or PUT anymore. The way to change the variable without breaking the connection with the FIELD is by using LSET and RSET statements. In your example, you could do LSET D$="a" which should change D$ to "a" plus 127 spaces to fill up. Note that (if the first bug was not there) it would not make sense to do LSET D$=D$+chr$(0) as D$ should be already 128 characters long.
Thanks again for digging up these issues, this is very helpful as I have to divide my time between testing, coding and my day job :)
Rob
This issue is now solved in the git repo - in the fixed version your test program now returns 128 as it does in GW-BASIC.
Rob
Hi, how do I get the fixed version of the git repository. I mean, I don’t know how to do it.
Ronald.
Hi Ronald, if you want to try the version in git you can get a ZIP of the source code at https://github.com/robhagemans/pcbasic/archive/release-15.08.zip or, if you have git installed, you can get a copy of the repository directly with
git clone https://github.com/robhagemans/pcbasic.git. That way you can always stay up to date with the latest code. Note that themasterbranch is the current development branch and may not be in a working state.To use it, you need to have a working Python installation and the required modules as described in https://github.com/robhagemans/pcbasic/blob/release-15.08/BUILDING.md.
I will also probably push out a bugfix release to the usual download location in the next week or so, so alternatively you can simply wait for that.
Rob
Thank you for everything. Since, I have no knowledge with Python and less compiling them (probably in a near future I shall learn) I'll, just, wait happily when you post a release for it, again thank you! Ron.
15.08.2 is available now!