Greek characters can't be diplayed.
Thank you very much. I can report that your second patch fixed the second bug. I did your test and everything worked like it should. Great work!
After recompiling the following test should confirm the second bug is fixed. bwBASIC: REM TEST 'RUN' COMMAND bwBASIC: bwBASIC: bwBASIC: LIST 100 PRINT "HELLO" bwBASIC: SAVE "GOOD.BAS" bwBASIC: bwBASIC: bwBASIC: REM THESE SHOULD DISPLAY "HELLO" bwBASIC: bwBASIC: bwBASIC: RUN HELLO bwBASIC: RUN 100 HELLO bwBASIC: RUN#100 HELLO bwBASIC: RUN "GOOD.BAS" HELLO bwBASIC: bwBASIC: bwBASIC: REM THESE SHOULD DISPLAY AN ERROR MESSAGE bwBASIC: bwBASIC: bwBASIC: RUN 1 ERROR: Undefined line bwBASIC: RUN 999 ERROR:...
Glad the initial bug is fixed. The attached "patch-20230419.txt" should fix the second bug you reported above.
Thank you a lot for fixing that bug. Your fix worked. But i found another bug that is related to this bug. BWBasic freezes when trying to run code starting with a line number that is not in the code listing. I used your code listing example above and entered: run 150 And after pressing the return key, BWBasic freezes. See the screenshot below. The same applies for variants like this one: run # 150 or run #150 I added your fix manually. I didn't use the diff patch because I didn't have the appropriate...
One more information. I found out that it is possible to switch back to the interpreter by pressing CTRL + C when a none existing line number was given to run the basic code. The problem with this is, BWBasic returns to the interpreter only, when only a number like run 150 was given and the keys CTRL+C was pressed If i enter a number with a # character run # 150 and then press the CTRL+C key, then BWBasic exists or crashes to DOS prompt. But from there, the memory seems to be rather corrupted, because...
One more information. I found out that it is possible to switch back to the interpreter by pressing CTRL + C when a none existing line number was given to run the basic code. The problem with this is, BWBasic returns to the interpreter only, when only a number like run 150 was given and the keys CTRL+C was pressed If i enter a number with a # character run # 150 and then press the CTRL+C key, then BWBasic exists or crashes to DOS prompt. But from there, the memory seems to be rather corrupted, because...
As an additional information to my last comment: I was curious how GW-BASIC reacts when entering a line number that doesn't exist. When trying to do so, it prints the line: Undefined line number OK And returns to the GW-BASIC interpreter. See screenshot as an example:
As an addition information to my last comment: I was curious how GW-BASIC reacts when entering a line number that doesn't exist. When trying to do so, it prints the line: Undefined line number OK And returns to the GW-BASIC interpreter. See screenshot as an example:
Thank you a lot for fixing that bug. Your fix worked. But i found a another bug that is related to this bug. BWBasic freezes when trying to run code starting with a line number that is not in the code listing. I used your code listing example above and entered: run 150 And after pressing the return key, BWBasic freezes. See the screenshot below. The same applies for variants like this one: run # 150 or run #150 I added your fix manually. I didn't use the diff patch because I didn't have the appropriate...
Thanks for finding this bug. Sorry for the delay in responding - I am not often online. If you are comfortable updating the source code with diff/patch, the attached "patch-20230417.txt" should fix this bug and all the other bugs I know about. If you are not comfortable with diff/patch, then open "bwb_cmd.c" with a text editor and goto to around line 1555, which should look like this: if (line_read_expression (L, X) == FALSE) /* bwb_run_filename_or_linenumber */ { WARN_SYNTAX_ERROR; return L; } Update...
Thanks.
You can tell the Freedos people you would like it included, as an actual user. I'll leave the feature request open for Howard to comment about including the functionality in the interpreter itself.
I see, thank you for your answer. Maybe informing the people from the FreeDOS project would be a good thing so they ship BWBASIC with a working RENUM executable in one of their next FreeDOS versions. On the other side, it would also be nice to have that command in the BWBasic interpreter in the first place.
I see, thank you for your answer. Maybe informing the people from the FreeDOS project would be a good thing so they ship BWBASIC with a working RENUM executable in on of their next FreeDOS versions. On the other side, it would also be nice to have that command in the BWBasic interpreter in the first place.
I understand. But the BWBasic version of FreeDOS 1.3 does not ship with a renum DOS command.
I see that the executable isn't provided in the download folder though. You need to compile it yourself. Alternatively, there is a precompiled binary on the PDOS/386 hard disk image available from http://pdos.org - it is a win32 executable. It's also in customb.zip.
Here's a picture of a short example: The example works in GW-BASIC. EDIT: I also added a screenshot of GW-Basic.
You have run "renum" instead bwbasic. It is a separate executable.
Here's a picture of a short example: The example works in GW-BASIC.
Here's a picture of a short example:
Hi Oliver. I'm a bit confused. Are you aware that there is already a renum command shipped with bwbasic? I'm not sure how to use it, but it's there. Are you saying it is insufficient for what you are trying to do? If so, it would be good if you could explain what is wrong with it.
Please add the RENUM command for code with line numbers
BWBasic 3.2 freezes after entering run#
My apologies for the late response -- I am not often online. If you would be so kind, please try this: gcc -D_SVID_SOURCE -o bwbasic -lm bw*.c
My apologies for the late response -- I'm not often online. Please remove the trailing semicolon. OLD: while (line_skip_seperator (l)); NEW: while (line_skip_seperator (l))
Daniel, My apologies for the late response -- I am not often online. If you would be so kind, please try this: gcc -D_SVID_SOURCE -o bwbasic -lm bw*.c
Wow! Could you share your source code with these changes? I have created a GitHub repository and uploaded all available versions one by one there, for historical purposes. In addition to making it easier to compare changes, using diff. Take a look, you may like it. I made a mistake in my GitHub repository and made your version 3.20f available in the Releases section as if it were version 3.20 of Howard S. Wulf (a.k.a. AF5NE). I know that Howard S. Wulf was working on a 3.30 version, but never released....
Daniel - Condensed change log (3.20c-g): Functional updates: Fix memory leaks in function handling Make HELP & EDIT available in ALL VERSIONs. All files are closed when variables are cleared: NEW & RUN Fix LSET & RSET so they fill the complete field length LINE INPUT now reads whitespace correctly Greeting changed to reflect new contributions Renum was much improved but still fails in some situations. Renum complete rewrite to renum2 Prevent random seeks with BINARY mode files. This makes it compatible...
Hey Howard, can you share the code for bwbasic 3.30? Also, FYI, I have created a GitHub repository: https://github.com/nerun/bwbasic. If you want access, let me know.
@KenUnix, Have you changed anything in the code? What are the differences from 3.20 in Files section (2017) tô yours 3.20f? What you have changed in renum2? There's any changelog.gz?
What error did you get? You might need to put the “-lm” at the end. Can you try that? I am aware that you got a more complicated procedure to work. BFN. Paul. From: Daniel D. Rodrigues Sent: Sunday, February 6, 2022 4:17 AM To: [bwbasic:bugs] Subject: [bwbasic:bugs] Re: #7 Compilation failure. gcc -o bwbasic -lm bw*.c Didn't work for me. Using gcc 10.2.1 and bwbasic 3.20. [bugs:#7] Compilation failure. Status: open Group: v1.0 (example) Labels: compilation Created: Mon Mar 26, 2018 01:44 PM UTC by...
New and updated bwbasic package for Linux Debian Amd64
@KenUnix, worked like a charm! I've dug around in the guts of bwBASIC enough to know stuff about it. The simple answer is that bwBASIC is not a "shell" in the sense that "BASH" or just plain "SH" are. Its a BASIC interpreter. It runs BASIC programs. You can execute shell commands from it with the "SHELL" function. So you would do something like this: bwBASIC: shell "ls" Or if you want to capture the exit code and do something with it, you use the SHELL() function, like this: x = shell("ls") I've...
I've dug around in the guts of bwBASIC enough to know stuff about it. The simple answer is that bwBASIC is not a "shell" in the sense that "BASH" or just plain "SH" are. Its a BASIC interpreter. It runs BASIC programs. You can execute shell commands from it with the "SHELL" function. So you would do something like this: bwBASIC: shell "ls" Or if you want to capture the exit code and do something with it, you use the SHELL() function, like this: x = shell("ls") I've not played with v2 so I can't speak...
Why shell commands are not working? In bwbasic 2.20 i can use ls -l *.bas: bwBASIC: ls bwbasic bwbasic-3.20.zip renum2 In 3.20f i can't: bwBASIC: ls ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls bwBASIC: ls -l *.bas ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls -l *.bas
DELETED
Why shell commands are not working? In bwbasic 2.20 i can use ls -l *.bas: bwBASIC: ls bwbasic bwbasic-3.20.zip renum2 In 3.20f i can't: bwBASIC: ls ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls bwBASIC: ls -l *.bas ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls -l *.bas
Why shell commands are not working? In bwbasic 2.20 i can use ls -l *.bas: bwBASIC: ls bwbasic bwbasic-3.20.zip renum2 In 3.20f i can't: bwBASIC: ls ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls bwBASIC: ls -l *.bas ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls -l *.bas
Why shell commands are not working? In bwbasic 2.20 i can use ls -l *.bas: bwBASIC: ls bwbasic bwbasic-3.20.zip renum2 In 3.20f i can't: bwBASIC: ls ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls bwBASIC: ls -l .bas ILLEGAL COMMAND AFTER LINE NUMBER: 1 ls -l .bas
Sorry, I got it now. I read Clement T. Cole's comment and found the solution: First: $ gcc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bw*.c Second: $ gcc bw*.o -lm -o bwbasic Run: ./bwbasic Thank you @JohnT, without you i would never see the solution!
I am using this command, from INSTALL file: gcc -o bwbasic -lm -ansi -pedantic -Wall -Werror bw*.c
Daniel, are you building with a makefile or with the commandline? Here's the compilation from my build with makefile, BWBasic 3.20 and I think gcc 10.2.1. gcc -c -I. -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRING=1...
Daniel, are you building with a makefile or with the commandline? Here's the compilation from my build with makefile, BWBasic 3.20 and I think gcc 10.2.1. gcc -c -I. -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRING=1...
gcc -o bwbasic -lm bw*.c Didn't work for me. Using gcc 10.2.1 and bwbasic 3.20.
I got the same error.
Hi there, By Feb 5, 2022: Using gcc v10.2.1 and bwbasic 3.20, i got this error too. $ gcc -o bwbasic -lm -ansi -pedantic -Wall -Werror bw*.c bwb_fnc.c: In function ‘IntrinsicFunction_execute’: bwb_fnc.c:966:13: error: implicit declaration of function ‘putenv’; did you mean ‘getenv’? [-Werror=implicit-function-declaration] 966 | if (putenv (A) == -1) | ^~~~~~ | getenv cc1: all warnings being treated as errors bwb_var.c: In function ‘bwb_COMMON’: bwb_var.c:113:9: error: this ‘while’ clause does not...
bwbasic is a standard C90 program, so it is not appropriate for bwbasic documentation to mention anything about CMS in particular. It is the C library documentation that should take it to the next step. Or as you can see below with the double quotes, it is CMS that needs to document it. Yes, the interactive environment is included. Here is Sixpack 1.2 running: 08:10:08 /(0009) bwbasic 08:10:08 Bywater BASIC Interpreter/Shell, version 2.50 08:10:08 Copyright (c) 1993, Ted A. Campbell 08:10:08 Copyright...
Is there any documentation on how its set up for CMS. Is the interactive environment included. It just seems to want to run a program and exit.
Hi Ken. Thanks for the link. You’re probably going to put out versions faster than me (I’m still waiting for Howard), so I would suggest you put your executables there, and I provide a link from Sourceforge to your alternate distribution. Happy with that? BFN. Paul. From: KenUnix Sent: Wednesday, December 22, 2021 9:10 AM To: [bwbasic:discussion] Subject: [bwbasic:discussion] Updated BWBASIC Paul, Please see link below for the complete source for the latest BWBASIC: https://yeolpishack.net/repos/ChipMaster/bwBASIC...
Paul, Please see link below for the complete source for the latest BWBASIC: https://yeolpishack.net/repos/ChipMaster/bwBASIC This site is readable by anyone. Ken
Hi Ken. It is a condition of the bwbasic license that any binaries need to have accompanying source code. I haven’t seen any source code. And then I need to review that source code. And then I need to merge it. I’m not promising to cut a new release based on these changes though. BFN. Paul. From: KenUnix Sent: Monday, December 20, 2021 3:15 AM To: [bwbasic:discussion] Subject: [bwbasic:discussion] Re: Reading from STDIN in Linux Paul I supplied binaries for multiple OS from Linux to Windows to Mac....
Paul I supplied binaries for multiple OS from Linux to Windows to Mac. What exactly do you need to add these on SFN under files? Categorized for Linux, Windows, and the Mac (new). renum2 is a complete rewrite of renum fixing many short comings. And it actually works! Ken On Thu, Dec 16, 2021, 10:04 PM Paul Edwards kerravon86@users.sourceforge.net wrote: Hi Ken. I didn’t see any source code to merge. Note that the latest (beta) source code is in custom.zip at http://pdos.org and contains your previous...
Hi Ken. I didn’t see any source code to merge. Note that the latest (beta) source code is in custom.zip at http://pdos.org and contains your previous changes. BFN. Paul. From: KenUnix Sent: Friday, December 17, 2021 11:39 AM To: [bwbasic:discussion] Subject: [bwbasic:discussion] Reading from STDIN in Linux Paul, I have uploaded into the support area new versions of bwbasic and a new renum2 which replaces renum. renum2 was a total rewrite addressing short comings of renum. Your will also find a bwbasic...
Delighted to hear bwBASIC is being updated — I was the original author, /ted — Ted A. Campbell tc@tedcampbell.com On Dec 16, 2021, at 1:29 PM, KenUnix kenmartin@users.sourceforge.net wrote: [support-requests:#5] https://sourceforge.net/p/bwbasic/support-requests/5/ Updated and new bwbasic Status: open Group: v1.0 (example) Labels: new Created: Thu Dec 16, 2021 07:29 PM UTC by KenUnix Last Updated: Thu Dec 16, 2021 07:29 PM UTC Owner: nobody Attachments: bwbasic.exe https://sourceforge.net/p/bwbasic/support-requests/5/attachment/bwbasic.exe...
Paul, I have uploaded into the support area new versions of bwbasic and a new renum2 which replaces renum. renum2 was a total rewrite addressing short comings of renum. Your will also find a bwbasic for the Mac OS X Amd64 and Windows 7 32 bit up to Windows 11 64bit i386, Linux Arm64 and Linux Amd64. These changes and additions will bring the version up to 3.20f and can be placed in the files area. Ken
Updated and new bwbasic for Linux Arm
Updated and new bwbasic for Linux Arm64
New and updated bwbasic for Linux Amd64
new updates bwbasic for Linux i386
new bwbasic for Mac OS X Amd64
Updated and new bwbasic
Initial version for Apple OS X Amd64. Linux versions to follow.
Updated and New for bwbasic bwb3.20f bwbasic should run on all Windows platforms Windows 7 32bit up to Windows 11 64bit. renum2 is a complete rewrite of renum to improve it's operation. Try: renum2 --help Others to follow for Linux and Apple OS X for Amd64.
Hi Ken. Thanks for contributing work to bwbasic Are the things in bwbasic-tests*.zip here: https://sourceforge.net/projects/bwbasic/files/bwbasic/version%203.20/ suitable? Note that I don’t have any BASIC programs myself. I’m a C programmer, not a BASIC programmer. BFN. Paul. From: KenUnix Sent: Thursday, August 19, 2021 10:28 AM To: [bwbasic:discussion] Subject: [bwbasic:discussion] Re: Reading from STDIN in Linux Paul, I have been doing a lot of work on the renum program. It has a lot of short...
Paul, I have been doing a lot of work on the renum program. It has a lot of short comings. Most all have been corrected. You can actually renumber a bwbasic program by specifying starting line # and increment. Great when you run out of line numbers or to make the listing look neater. It now handles among others ON X GOTO or GOSUB x,xx,xx,xx. PRINT. among others. I am trying to validate it's operation. You know look for bugs. Can you email me with attachments of complex or simple bwbasic programs...
Paul, I have been doing a lot of work on the renum program. It has a lot of short comings. Most all have been corrected. You can actually renumber a bwbasic program by specifying starting line # and increment. Great when you run out of line numbers or to make the listing look neater. It now handles among others ON X GOTO or GOSUB x,xx,xx,xx. PRINT. among others. I am trying to validate it's operation. You know look for bugs. Can you email me with attachments of complex or simple bwbasic programs...
Sorry Paul - I thought I was entering in the GnuCOBOL discussion. I was only trying to contact kenunix specifically. David
Sorry Paul - I thought I was entering in the GnuCOBOL discussion. I was only trying to contact kenunix specifically. David Paul Edwards wrote: Hi David. I’m confused as to why the subject is GnuCOBOL but this is bwbasic. What is the relationship between these two things? Thanks. Paul. From: David Wall Sent: Tuesday, August 10, 2021 7:15 PM To: [bwbasic:discussion] Subject: [bwbasic:discussion] Scripts for building GnuCOBOL under Visual C. Particularly for kenunix - do you still have a copy of the...
Hi David. I’m confused as to why the subject is GnuCOBOL but this is bwbasic. What is the relationship between these two things? Thanks. Paul. From: David Wall Sent: Tuesday, August 10, 2021 7:15 PM To: [bwbasic:discussion] Subject: [bwbasic:discussion] Scripts for building GnuCOBOL under Visual C. Particularly for kenunix - do you still have a copy of the scripts you and cdg used to banter about. I'm particularly interested in his build script for 3.1 to see if I can mod it for 4.0. Have you got...
Particularly for kenunix - do you still have a copy of the scripts you and cdg used to banter about. I'm particularly interested in his build script for 3.1 to see if I can mod it for 4.0. Have you got anything like that also - i'd be interested. It seems - building under Mingw/msys - like I do - tends to make the make check & make test (nist) tests think they're running under a linux flavour - and thus possibly give false results for me (under windows). Just a thought.
Hi Ken. I only compile under Windows, not Linux. Yes, I am the current maintainer. Note that the previous fixes you sent me have been incorporated into the source code but not yet formally released. However, there is a beta release available with your fixes (plus other things) which can be found in custom.zip from http://pdos.org Please let me know if you need anything else to debug the issue. Thanks. Paul. From: KenUnix Sent: Saturday, August 7, 2021 9:02 AM To: [bwbasic:discussion] Subject: [bwbasic:discussion]...
Paul, Sorry I missed your message. That zip file is complete. Thanks. On Thu, Aug 5, 2021 at 6:33 PM Paul Edwards kerravon86@users.sourceforge.net wrote: Hi Ken. The link points to two zip files and one executable. The zip file that I named (the last file), contains the complete source code (I just downloaded it to verify): C:\Users\kerra\Downloads>unzip -v bwbasic-3.20.zip | grep -i bwb_ 230584 Defl:X 29723 87% 2017-06-08 11:20 92258688 bwb_cmd.c 43588 Defl:X 6868 84% 2017-06-08 11:20 024193c6 bwb_cnd.c...
Paul, Thanks for pointing me in the right direction. Sorry for the delay I missed your post. Have you ever compiled this or ran this under Linux? Are you the current maintainer? I have seen this before and have fixes so no errors are generated when compiling under Linux. Ken
Hi Ken. The link points to two zip files and one executable. The zip file that I named (the last file), contains the complete source code (I just downloaded it to verify): C:\Users\kerra\Downloads>unzip -v bwbasic-3.20.zip | grep -i bwb_ 230584 Defl:X 29723 87% 2017-06-08 11:20 92258688 bwb_cmd.c 43588 Defl:X 6868 84% 2017-06-08 11:20 024193c6 bwb_cnd.c 27655 Defl:X 3682 87% 2017-06-08 11:20 3a6b8d86 bwb_dio.c 93086 Defl:X 13815 85% 2017-06-08 11:20 0db5d2a8 bwb_exp.c 99685 Defl:X 15050 85% 2017-06-08...
Paul That link points to a zip file that only contains TEST basic programs not the source for bwbasic itself. Ken On Thu, Aug 5, 2021 at 2:25 PM Paul Edwards kerravon86@users.sourceforge.net wrote: What do you mean the source is gone? At this link: https://sourceforge.net/projects/bwbasic/files/bwbasic/version%203.20/ you will find bwbasic-3.20.zip which contains the complete source code for bwbasic if that is what you are talking about. And what do you mean “it really doesn’t say”? Are you talking...
What do you mean the source is gone? At this link: https://sourceforge.net/projects/bwbasic/files/bwbasic/version%203.20/ you will find bwbasic-3.20.zip which contains the complete source code for bwbasic if that is what you are talking about. And what do you mean “it really doesn’t say”? Are you talking about the BASIC standard? Maybe it requires a user-defined sentinel for all input files, or maybe there is some sort of “on EOF goto xxx” statement. Which BASIC standard did you look up? I checked...
It really doesn't say. I would investigate it but on sourceforgenet the source is gone. Ken On Thu, Aug 5, 2021, 1:28 PM Paul Edwards kerravon86@users.sourceforge.net wrote: The program for testing is simple 100 print "start" 102 let l = 0 120 line input a$ 122 let l = l +1 130 print l , a$ 140 goto 120 200 rem print "total " , l Via the program how could I get to 200? This is a function of the BASIC programming language, not bwbasic in particular. How do other BASIC interpreters do it, and what...
The program for testing is simple 100 print "start" 102 let l = 0 120 line input a$ 122 let l = l +1 130 print l , a$ 140 goto 120 200 rem print "total " , l Via the program how could I get to 200? This is a function of the BASIC programming language, not bwbasic in particular. How do other BASIC interpreters do it, and what does the BASIC standard say to do? BFN. Paul.
Paul Linux. A file called xxx as an example has an unknown number of lines or ls -1 You do ls -1 | bwbasic program.bas or cat xxx | bwbasic program.bas In either case bwbasic exits at end on input without the program being able to do for example sum the results. The program for testing is simple 100 print "start" 102 let l = 0 120 line input a$ 122 let l = l +1 130 print l , a$ 140 goto 120 200 rem print "total " , l Via the program how could I get to 200? Ken On Thu, Aug 5, 2021, 12:42 PM Paul Edwards...
How does a BASIC program read from stdin? Presumably some sort of INPUT X$ What happens when ctrl-D or whatever is hit when an INPUT X$ is in effect? This should be part of the BASIC language. If you can write a standard BASIC program and check for the EOF condition, you can see if bwbasic works properly. If it doesn’t, I can investigate that. BFN. Paul. From: KenUnix Sent: Friday, August 6, 2021 12:47 AM To: [bwbasic:discussion] Subject: [bwbasic:discussion] Reading from STDIN in Linux With bwbasic...
With bwbasic is there a way to detect end of file when reading from command line like cat XXX | bwbasic program.bas When XXX is exhausted bwbasic exits. Can that be caught so processing can be done? Thanks
Due to more-or-less unrelated work being done on the PDOS/386 operating system, I wanted to compile bwbasic to provide another language for this OS, and as a result, I published the beta source code on my system, which can be found at http://pdos.org along with a Win32 executable that should be able to be run standalone on almost any 80386+ system if you install the appropriate support (Wine if you're using Linux, HX if you're using FreeDOS, etc). I'm still waiting on Howard for the official version...
Well, but I have the standard Lunbuntu installation... They all time long create new and new inventions , not keeping the old useful staff working... (The similar situation with Musescore.) :-(
Hi. 2.20 is very old. I looked at the DOCS/BYWATER.txt and the file was only created in 3.20. What file are you looking at that says that that was valid syntax in 2.20? BFN. Paul. From: xerostomus Sent: Wednesday, June 23, 2021 4:50 AM To: [bwbasic:discussion] Subject: [bwbasic:discussion] options I have Linux Lubuntu 18.4. sudo apt install bwbasic bwbasic Bywater BASIC Interpreter/Shell, version 2.20 patch level 2 Copyright (c) 1993, Ted A. Campbell Copyright (c) 1995-1997, Jon B. Volkoff bwBASIC:...
I have Linux Lubuntu 18.4. sudo apt install bwbasic bwbasic Bywater BASIC Interpreter/Shell, version 2.20 patch level 2 Copyright (c) 1993, Ted A. Campbell Copyright (c) 1995-1997, Jon B. Volkoff bwBASIC: OPTION VERSION "BYWATER" ERROR: at line 0: Unknown statement <version> following OPTION.</version> This way I am unable to set any option. What am I doing wrong? Thanks :-) X
Thanks for the bug report. I have updated the instructions to what you provided. BFN. Paul. From: avhohlov Sent: Sunday, January 17, 2021 1:11 AM To: Ticket #11: Compilation error on Linux Subject: [bwbasic:bugs] #11 Compilation error on Linux [bugs:#11] Compilation error on Linux Status: open Group: v1.0 (example) Created: Sat Jan 16, 2021 02:11 PM UTC by avhohlov Last Updated: Sat Jan 16, 2021 02:11 PM UTC Owner: nobody Compilation instruction on unix seems wrong (in INSTALL file): On Unix using...
Compilation error on Linux
Must enable ANSI in Windows terminal
the extra semicolon there seems to be wrong Unless the number of dimensions is actually ignored by the COMMON statement. Then the actual code would just skip the commas and always return 2 as the number of dimensions, which would not be used later. I don't know if this is the case.
I'm sorry, for some reason I misread something in your original report. I thought the code did not had the comma, and the compiler was suggesting to add it. It is the opposite. I guess the comma should not be there. line_skip_seperator is defined in bwb_int.c, and it calls function buff_skip_seperator, which has this comment: /* skip the next non-space character in 'buffer' if it is a seperator (comma, semicolon, or colon). if successful then 'position' is updated past the character and returns the...
BTW: I do stand by my original note and the warning seems reasonable. I'm curious that icc did not catch it. I wish I had a copy of Gimpel's pclint() and see what they say. As I said in my original note: while (line_skip_seperator (l)); { dimensions++; } compiles to/ becomes equiv too: while (line_skip_seperator (l)) / null statement /; dimensions++; not: while (line_skip_seperator (l)) { dimensions++; } If the code was intended to work as I mentioned, then you might consider getting rid of the redundant...
Nice catch -- always possible -- C compiler is clang Apple Version 11 ( a.k.a. LLVM see below). You might want to add a note, that it might not compiler with a clang compiler front-end. Using: sh-3.2$ make clean rm -f .o bwbasic core sh-3.2$ CC=gcc-10 sh-3.2$ export CC sh-3.2$ ./configure checking how to run the C preprocessor checking for install checking for size_t in sys/types.h checking for string.h checking for stdlib.h checking for unistd.h checking for raise creating config.status creating...
I guess the compiler got it wrong. The code is counting commas in "DIM(,,,)". And if the formatting changed, it would be inconsistend with the rest of the code (which uses the opening brace in the next line) What compiler issued that warning?
I would encourage you to correct this. I’m the original author but I have not worked with the code for a decade or more, /ted — Ted A. Campbell tc@tedcampbell.com On Oct 27, 2020, at 2:38 PM, Clement T. Cole clemc@users.sourceforge.net wrote: I ran into this accidently. I know its old code, but I think the compiler is on to something. If the code is as intended, then it probably needs to be reformated to be a tad more explicit as per the warning, but I'm thinking there might be something that was...
I ran into this accidently. I know its old code, but I think the compiler is on to something. If the code is as intended, then it probably needs to be reformated to be a tad more explicit as per the warning, but I'm thinking there might be something that was missed for many years.
Possibly silent but latent bug in bwb_var.c caught with a more modern compiler.
Thanks. I checked the patch, and we already have those changes in dev. BFN. Paul. From: Jeronimo Pellegrini Sent: Friday, August 21, 2020 9:23 PM To: Ticket #7: Fix gcc warnings for renum.c Subject: [bwbasic:patches] #7 Fix gcc warnings for renum.c [patches:#7] Fix gcc warnings for renum.c Status: open Group: Unstable (example) Created: Fri Aug 21, 2020 11:23 AM UTC by Jeronimo Pellegrini Last Updated: Fri Aug 21, 2020 11:23 AM UTC Owner: nobody Attachments: a.. renum.diff (452 Bytes; text/x-patch)...
Makefile clean target does not remove renum
Fix gcc warnings for renum.c