![]()
#Purebasic source files verification#It comprises all the regular options required for inspecting the code either in its entirety or by pieces.Ī compiler is also included in the application, allowing the user to build the source code into an executable file.Īmong the options available for the compiler there is the possibility to run a syntax verification and compile the program with or without the debugger. Like all respectable IDE programs, PureBasic sports a debugging tool for checking the accuracy of the code. #Purebasic source files windows#The most part of the application windows is occupied by the code editor, which includes support for tabs, making it easy for a more experienced user to access code lines from different projects at the same time. The program is a full-blown interactive development environment that can help the user create or edit PureBasic code, debug, run it and create the executable file. Needless to say, the old saying that "too many cooks in a kitchen slow down cooking" also applies here, but chances are that in the long term the benefits will outcome the shortcomings, because more minds at works on the same problems tend to always come up with better solutions.PureBasic has been created as a simple programming language for beginners that stems from the old BASIC however, it can also address more experienced users that want to expand the horizon of their programming knowledge. I'm confident that the collaborative effort and experience might enrich everyone who participates (and few PB projects have the same traction has this one has), and that although it might not be as effective as selectively excluding contributors who don't regularly work on all platforms, it might pay in the long run in terms of invigorating the user base and lifting the collaborative spirit.Īfter all, this repository has opened the doors to an unprecedented collaborative experience in the PB community - which, IMO, has great outcome potentials in terms bringing people together and learning from each other. How many PB users have access to all three major OSs (and to SpiderBasic too) is anyone's guess. The PB user base is not that huge, and even less so on GitHub. So, thinking in terms of one's favourite OS and merely expecting others to fix problems on other platforms is definitely not in the collaborative spirit but relying on others' experience to collaboratively ensure that these changes work is quite OK (IMO at least). Good coordination is usually sufficient to make things work, although it might not replace experience of working on all OSs and writing code with that perspective (as you mentioned). In most open source projects covering multiple OSs that I've seen, only the core maintainers have the luxury of accessing all OSs at all times, with many contributors working mostly on their OS of choice. This would prevent many common problems and dead ends, especially if people with expertise on different platforms would participate in planning code changes and new features, being able each to contribute insights regarding specific platforms. I agree on this, and I also think that discussing changes before implementing them would be a great start in that direction. It is of no use if people check in changes that work only on their preferred OS and expect others to work out the problems for the other platforms for them. #Purebasic source files free#Then, whoever wishes to re-compile the C components is free to do so, but testing should (IMO) be done using the same exact binaries that will go in the official build, to prevent differences in behaviour.Įxpecting all contributors to have access to all three OSs is going to reduce drastically the number of participants - especially if you also need support for 32-bit macOS and Linux, with the latest macOS and Ubuntu dropping support for it, which would require users to also have access to older versions of these OSs in order to test 32-bit builds. PS: In this respect, I'd feel more comfortable if the repository were to offer official pre-compiled C binaries, to enable stricter testing conditions. This is a tricky situation, and lacking automated tests at commit time, we need some testing protocol to prevent bugs from creeping into the official IDE package. Since we can't rely on CI tools like Travis (due to PB being proprietary software) we need to form a testers team which can check that the IDE compiles without problems on all three OSs - and, possibly, devise a way to test for features bugs somehow, manually or automated.Ĭurrently, the risk is that a contributor adds/tweaks a features on a specific OS, oblivious of new bugs arising on other OSs. I totally agree, but we still have to find a way to actually test changes to the code base. Gradual changes are much easier to verify that sweeping refactorings. I suggest to add it to new files and gradually introduce it in code areas that need to be updated anyways. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |