This is a pre-release of the development branch of PC-BASIC. The code base in this branch has been much refactored to improve maintainability and allow the implementation of various new features. Among the improvements in this pre-release are:
An interface based on SDL2 to supersede the ageing PyGame
Experimental support for IME input methods
Ability to call BASIC code from Python through the basic.Session API
Threaded video and audio, not interrupted by I/O blocking
Improved handling of Unicode file names and directories
Correct memory handling of string literals in code
Border support in curses interface on Unix text terminals
You are cordially invited to give this version a spin; due to the large number of changes some regressions are expected and it would be good to iron them out before the formal release. Note that an OS X release is in the works but not yet available.
All future development of PC-BASIC will take place on this branch; the 15.08 branch will continue to be supported but will only see limited bug fixes and no new features.
You can download the packaged pre-release from GitHub. Note that this pre-release will install in a separate directory and keep its start menu entries and config files separate, so you can try it alongside the stable version.
Have fun!
Rob
Last edit: Rob Hagemans 2016-06-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the release. I am wondering why there is no attempt to do an exact match with commands such as RUN in PC-BASIC. For example, RUN "MYPROGRAM" or RUN "MYPROGRAM.BAS" won't work even if "PCBASIC MYPROGRAM.BAS" works. I think it is very easy to support exact match with commands such as RUN too.
Wengier
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main issue is how to do that and deal with the default extension in a way compatible with GW-BASIC. For example,
LOAD"PROGRAM" and LOAD"PROGRAM.BAS" both load the file PROGRAM.BAS LOAD"PROGRAM." loads the file PROGRAM
If LOAD"PROGRAM" looked for an exact match first, it would behave different from GW-BASIC in directories where both PROGRAM and PROGRAM.BAS exist, even if there were no long file names at all in that directory. That could break old programs in ways difficult to debug.
Add to that the extra complexity of long and short filenames (on Windows) and case-sensitive file names (on Unix) and the whole thing becomes messy.
I have tried to implement workarounds for this in the past, but they ended up being buggy, hard to document and explain with ugly code that was difficult to maintain. In the end, I decided it was better to spend my time on other features. I'm also reluctant to do too much tinkering with this to reduce the risk of someone accidentally overwriting their files due to counterintuitive behaviour...
By the way, Wengier, could you check out if the IME features in the pre-release work for you? It's currently using the window title bar for composition/text editing, which is not ideal but probably better than nothing...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The IME feature certainly looks interesting. The best part is that it actually works, i.e. it is able to output DBCS characters. However, there are also at least two notable problems:
At the moment it does not display a list of characters for users to choose from. For example, for the Pinyin input method, there are usually multiple characters for the same user input, and normally the system will show a list of chacters so that the user will be enter a number to choose that character (if there are more than 10 choices then the system will generally allow the user to go to the next or previous 10 choices). Currently I can use the number key to get a character, but the character list is totally unavailable.
In general the user will be able to get the first (or the only) character from the list of characters by typing the SPACE key. However, currently PC-BASIC will actually output the SPACE chraracter besides this when the user enters the SPACE key to select the first character, which is unexpected. The SPACE key should be reserved for the IME in this case too.
As for commands such as LOAD and RUN, maybe you can just check if the user has entered a dot (.) in the file name. If the dot is not entered, append the ".BAS" extension just like the 8.3 name cases. Then LOAD "MYPROGRAM" and LOAD "MYPROGRAM.BAS" both load the file MYPROGRAM.BAS, whereas LOAD "MYPROGRAM." loads the file MYPROGRAM. There is no need to do exact match first, and the above approach can be simply considered the direct extension of the 8.3 name case, which I don't really think will cause any counterintuitive behavior (the weird case is to have more than one dot in the file name, which is highly uncommon and can still be treated in the usual way). However, for compatibilty purpose maybe you can add a setting to allow or disallow this extension to 8.3 names. As for case-sensitive file names on Unix systems, perhaps you can to a large extent use the existing code as used by commands such as OPEN. This is just a suggestion.
Wengier
Last edit: Wengier 2016-06-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the IME feedback, that's really useful!
I'll look into how to produce the candidate list - from this https://wiki.libsdl.org/Tutorials/TextInput I got the impression that the IME or the operating system should show it automatically when appropriate, but perhaps I need to call SDL_Set TextInputRect to force it to appear.
I was indeed not sure how the space bar event should be handled. Is the Enter key behaving correctly? I'm not sure if it should produce just the composition or if it should produce the composition followed by a CR character. (which I think it does now).
For the file names, thanks for the suggestion! I need to think through the consequences of this approach on both Windows and Unix. I'm planning to refactor the disk device access so if I think it will work OK I may include this as a new feature when I do so.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess the behavior of the Enter key is not universally defined for input methods, but it usually simply outputs the composition (the user inputs) *without* the CR character. Thus in general for both the Space key and the Enter key the SPACE/CR character should *not* be produced when the IME is currently active.
And sure I believe it would be quite useful if commands like LOAD and RUN will be able to handle long filenames directly using this or some other approach.
Wengier
Last edit: Wengier 2016-06-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's strange - whatever I try with PySDL2, the candidate window will not appear. I'm beginning to think this is a bug in SDL2. Or maybe I'm doing something wrong - however, documentation in English about Text Input and IMEs is very sparse, basically everyone refers to the same tutorial on libsdl.org which doesn't discuss this issue... It may be possible to trigger the candidate list to open through the Windows API, but this will require more study. The documentation on IMEs in Windows isn't very clear either.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Awesome Wengier, I was hoping to find something like that. Google translate or no, it's surprising how hard it is to search for anything on the internet written in a language I don't know :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a belated follow-up to the earlier 16.06.0rc0 pre-release. Unfortunately that release had a few major issues that required further reworking.
This pre-release fixes a number of issues with the previous pre-release:
Fixes crashes on maths errors
Implements more faithful handling and memory storage of strings
Implements floating-point operations whose results are closer to GW-BASIC
Fixes screen lockups happening in programs that do a lot of printing
Implements Wengier's suggestion for dealing with file names ending in dots ... and many other improvements; I'll add some more to this list when I have time.
Not all reported issues with the previos pre-release have been fixed; I am still researching how to display the candidate list for character composition with IME; this is unlikely to be fixed for the full release.
I am actively working on an OSX version; unfortunately this requires me to re-install my build environment, which is complicated on Mac.
Have fun!
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a pre-release of the development branch of PC-BASIC. The code base in this branch has been much refactored to improve maintainability and allow the implementation of various new features. Among the improvements in this pre-release are:
basic.Session
APIcurses
interface on Unix text terminalsYou are cordially invited to give this version a spin; due to the large number of changes some regressions are expected and it would be good to iron them out before the formal release. Note that an OS X release is in the works but not yet available.
All future development of PC-BASIC will take place on this branch; the 15.08 branch will continue to be supported but will only see limited bug fixes and no new features.
You can download the packaged pre-release from GitHub. Note that this pre-release will install in a separate directory and keep its start menu entries and config files separate, so you can try it alongside the stable version.
Have fun!
Rob
Last edit: Rob Hagemans 2016-06-18
Thanks for the release. I am wondering why there is no attempt to do an exact match with commands such as RUN in PC-BASIC. For example, RUN "MYPROGRAM" or RUN "MYPROGRAM.BAS" won't work even if "PCBASIC MYPROGRAM.BAS" works. I think it is very easy to support exact match with commands such as RUN too.
Wengier
The main issue is how to do that and deal with the default extension in a way compatible with GW-BASIC. For example,
LOAD"PROGRAM"
andLOAD"PROGRAM.BAS"
both load the filePROGRAM.BAS
LOAD"PROGRAM."
loads the filePROGRAM
If
LOAD"PROGRAM"
looked for an exact match first, it would behave different from GW-BASIC in directories where bothPROGRAM
andPROGRAM.BAS
exist, even if there were no long file names at all in that directory. That could break old programs in ways difficult to debug.Add to that the extra complexity of long and short filenames (on Windows) and case-sensitive file names (on Unix) and the whole thing becomes messy.
I have tried to implement workarounds for this in the past, but they ended up being buggy, hard to document and explain with ugly code that was difficult to maintain. In the end, I decided it was better to spend my time on other features. I'm also reluctant to do too much tinkering with this to reduce the risk of someone accidentally overwriting their files due to counterintuitive behaviour...
By the way, Wengier, could you check out if the IME features in the pre-release work for you? It's currently using the window title bar for composition/text editing, which is not ideal but probably better than nothing...
Hi Rob,
The IME feature certainly looks interesting. The best part is that it actually works, i.e. it is able to output DBCS characters. However, there are also at least two notable problems:
At the moment it does not display a list of characters for users to choose from. For example, for the Pinyin input method, there are usually multiple characters for the same user input, and normally the system will show a list of chacters so that the user will be enter a number to choose that character (if there are more than 10 choices then the system will generally allow the user to go to the next or previous 10 choices). Currently I can use the number key to get a character, but the character list is totally unavailable.
In general the user will be able to get the first (or the only) character from the list of characters by typing the SPACE key. However, currently PC-BASIC will actually output the SPACE chraracter besides this when the user enters the SPACE key to select the first character, which is unexpected. The SPACE key should be reserved for the IME in this case too.
As for commands such as LOAD and RUN, maybe you can just check if the user has entered a dot (.) in the file name. If the dot is not entered, append the ".BAS" extension just like the 8.3 name cases. Then LOAD "MYPROGRAM" and LOAD "MYPROGRAM.BAS" both load the file MYPROGRAM.BAS, whereas LOAD "MYPROGRAM." loads the file MYPROGRAM. There is no need to do exact match first, and the above approach can be simply considered the direct extension of the 8.3 name case, which I don't really think will cause any counterintuitive behavior (the weird case is to have more than one dot in the file name, which is highly uncommon and can still be treated in the usual way). However, for compatibilty purpose maybe you can add a setting to allow or disallow this extension to 8.3 names. As for case-sensitive file names on Unix systems, perhaps you can to a large extent use the existing code as used by commands such as OPEN. This is just a suggestion.
Wengier
Last edit: Wengier 2016-06-22
Thanks for the IME feedback, that's really useful!
I'll look into how to produce the candidate list - from this https://wiki.libsdl.org/Tutorials/TextInput I got the impression that the IME or the operating system should show it automatically when appropriate, but perhaps I need to call
SDL_Set TextInputRect
to force it to appear.I was indeed not sure how the space bar event should be handled. Is the Enter key behaving correctly? I'm not sure if it should produce just the composition or if it should produce the composition followed by a CR character. (which I think it does now).
For the file names, thanks for the suggestion! I need to think through the consequences of this approach on both Windows and Unix. I'm planning to refactor the disk device access so if I think it will work OK I may include this as a new feature when I do so.
Rob
Hi Rob,
I guess the behavior of the Enter key is not universally defined for input methods, but it usually simply outputs the composition (the user inputs) *without* the CR character. Thus in general for both the Space key and the Enter key the SPACE/CR character should *not* be produced when the IME is currently active.
And sure I believe it would be quite useful if commands like LOAD and RUN will be able to handle long filenames directly using this or some other approach.
Wengier
Last edit: Wengier 2016-06-23
It's strange - whatever I try with PySDL2, the candidate window will not appear. I'm beginning to think this is a bug in SDL2. Or maybe I'm doing something wrong - however, documentation in English about Text Input and IMEs is very sparse, basically everyone refers to the same tutorial on libsdl.org which doesn't discuss this issue... It may be possible to trigger the candidate list to open through the Windows API, but this will require more study. The documentation on IMEs in Windows isn't very clear either.
Rob
Rob,
The problem you mentioned is probably very similar to the one posted below:
"SDL2 windows下输入法候选没有显示的解决方法" ("The workaround for SDL2 IME candidate window not showing under Windows")
http://tieba.baidu.com/p/4328496784
The solution it used is to comment out one line in SDL2's SDL_windowskeyboard.c. Perhaps you can try it too. Hope this helps.
Wengier
Last edit: Wengier 2016-06-26
Awesome Wengier, I was hoping to find something like that. Google translate or no, it's surprising how hard it is to search for anything on the internet written in a language I don't know :)
Hi all,
I've uploaded aother pre-release of the development branch of PC-BASIC to github at https://github.com/robhagemans/pcbasic/releases/tag/16.12.0rc0
This is a belated follow-up to the earlier 16.06.0rc0 pre-release. Unfortunately that release had a few major issues that required further reworking.
This pre-release fixes a number of issues with the previous pre-release:
I am actively working on an OSX version; unfortunately this requires me to re-install my build environment, which is complicated on Mac.
Have fun!
Rob