I was trying to solve a puzzle on Advent of Code’s website, by the following bit of code:
10 ' BATH.BAS - Second puzzle part 1
20 ' WRITTEN 3 Dec 16 JRA
30 ' Variables
40 ' B current number of door Button. LC Loop counter
50 ' F$ - one of five data files (one for each code no). D$ - direction of move
100 ’
110 B = 5 ' This is where we start for the first file only. Other runs have
111 ' their starting point from the preceding run.
120 INPUT "Datafile "; F$
130 LC = 1
140 OPEN F$ FOR RANDOM AS #1 LEN=1
145 GET #1, LC
150 INPUT #1, D$
160 PRINT D$
This is as far as I had got with the coding, (the file F$ exists) when the error arose, as follows:
150 INPUT #1, D$
pcbasic.statements:1979, exec_input
None
pcbasic.devices:403, read_var
None
pcbasic.devices:423, _input_entry
None
pcbasic.devices:411, _skip_whitespace
None
TypeError: 'in <string>' requires string as left operand, not bytearray
Would it be possible to enhance PC-BASIC with such matters as having longer allowable string lengths? Relaxing the present restriction to 255 characters would not hurt the running of old programs, but would help those using an old language for new programming - I need to read in over 500 characters!
Many thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, that looks like bug, I'll investigate - thanks for the report!
Unfortunately it is not possible to have strings longer than 255 characters, for the simple reason that GW-BASIC strings are stored with only a single-byte field for the length. Therefor ethe length can only be a one-byte integer, i.e. between zero and 255. Changing this would have knock-on effects basically everywhere in the interpreter, and would break old programs that depend on strings being stored in the GW-BASIC format.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This code still throws a Field Overflow in 150 after the fix, by the way - not entirely sure why, but it does the same thing in GW-BASIC so it's not a bug. I think the way to access the record is with
142 FIELD#1, 1 AS D$
and getting rid of line 150.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Rob. Thanks for your work. I think "Field overflow" is correct - since the GET in 145 reads in the first character of the data, and then the INPUT in 150 presumably tries to address the same thing. Could it have anything to do with where the pointer is in the field?
I will look forward to the new release.
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"
I was trying to solve a puzzle on Advent of Code’s website, by the following bit of code:
10 ' BATH.BAS - Second puzzle part 1
20 ' WRITTEN 3 Dec 16 JRA
30 ' Variables
40 ' B current number of door Button. LC Loop counter
50 ' F$ - one of five data files (one for each code no). D$ - direction of move
100 ’
110 B = 5 ' This is where we start for the first file only. Other runs have
111 ' their starting point from the preceding run.
120 INPUT "Datafile "; F$
130 LC = 1
140 OPEN F$ FOR RANDOM AS #1 LEN=1
145 GET #1, LC
150 INPUT #1, D$
160 PRINT D$
This is as far as I had got with the coding, (the file F$ exists) when the error arose, as follows:
150 INPUT #1, D$
pcbasic.statements:1979, exec_input
None
pcbasic.devices:403, read_var
None
pcbasic.devices:423, _input_entry
None
pcbasic.devices:411, _skip_whitespace
None
TypeError: 'in <string>' requires string as left operand, not bytearray
Would it be possible to enhance PC-BASIC with such matters as having longer allowable string lengths? Relaxing the present restriction to 255 characters would not hurt the running of old programs, but would help those using an old language for new programming - I need to read in over 500 characters!
Many thanks
Hi, that looks like bug, I'll investigate - thanks for the report!
Unfortunately it is not possible to have strings longer than 255 characters, for the simple reason that GW-BASIC strings are stored with only a single-byte field for the length. Therefor ethe length can only be a one-byte integer, i.e. between zero and 255. Changing this would have knock-on effects basically everywhere in the interpreter, and would break old programs that depend on strings being stored in the GW-BASIC format.
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 Rob. I understand about the string length.
This bug is fixed by commit 49058c3, will be in next release.
This code still throws a
Field Overflow in 150after the fix, by the way - not entirely sure why, but it does the same thing in GW-BASIC so it's not a bug. I think the way to access the record is withand getting rid of line 150.
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hello Rob. Thanks for your work. I think "Field overflow" is correct - since the GET in 145 reads in the first character of the data, and then the INPUT in 150 presumably tries to address the same thing. Could it have anything to do with where the pointer is in the field?
I will look forward to the new release.