Freebasic 1.20.0 Development

[coderJeff]

With the release of fbc 1.10.0 completed, time to move on to the next version.

Currently there is:

Patches for fbc 1.10.x
- https://github.com/freebasic/fbc/tree/fbc-1.10
- https://sourceforge.net/p/fbc/code/ci/master/tree/

Main Development (what the daily builds are based on):
- https://github.com/freebasic/fbc
- https://sourceforge.net/p/fbc/code/ci/master/tree/

The idea is that critical fixes can be committed to fbc-1.10 branch and merged to master (1.20.0) branch with the main development (changes) on the master branch.

Most helpful is if bugs and feature requests can be logged at either:
- https://github.com/freebasic/fbc/issues
- https://sourceforge.net/p/fbc/bugs/

It is good that bugs and features are discussed here on the forums, but having a ticket logged on sourceforge.net or github.com that drills down on the actual issue is incredibly helpful:
- formal ticket means it is not lost in the forums
- tracking number for investigating / reporting / resolving
- we are willing to make an effort if you are willing to make an effort

I know there are a few good discussions buried in the forum, but they are easy to lose track of if it is not the focus of the day.
For example, the topic: Bugs - Discussion

Personally,
For the past few years I have been focusing on mostly 2 things:
- reliable code generation (the user's compiled program really, REALLY, shouldn't crash)
- exposing internals (if fbc can do it, user should be able to do it also)

Even if there are features that users badly desire or bugs which must be worked around, any bad code generation (that I am aware of) I think has usually taken precedence in my efforts over all else. To be honest though, I often allow myself to be distracted by a variety of challenges and personal interests, so please, some leniency in the previous claim.

Moving forward here is personally what I want to do:
- continue squashing the worst bugs
- work on a project that uses freebasic instead of only making freebasic
- encourage user contributions in a way that is manageable and meets my expectations

Of course, I have specific ideas about what I personally would like to do but hopefully the above gives the overall idea what I am thinking about or concentrating on when I use my limited time to work on freebasic. Because for now, even though I find myself as the somewhat self-appointed person-in-charge, I look forward to someday when another will take over and I may have casual involvement as the psuedo-retired-helpful-veteran.

As always, questions or comments welcome.

[jevans4949]

What about versions 1.11 to 1.19?

[Provoni]

Thank you allot coderJeff for all the work you've put in.

Without FreeBASIC, my project probably would not exist:

https://github.com/doranchak/azdecrypt
viewtopic.php?t=23188

I often allow myself to be distracted by a variety of challenges and personal interests, so please, some leniency in the previous claim.

Sure! What do you dabble in?

[adeyblue]

What about versions 1.11 to 1.19?

It's employee evaluation season and he wants to make it look like he's done 10x more work for that sweet, sweet raise

[angros47]

I remember, in the past, a discussion about implementing generics, too. I wonder, what is the current status? I vaguely remember someone mentioning macros and other preprocessor instructions being already implemented, but I couldn't find any recent mention about it

[coderJeff]

What about versions 1.11 to 1.19?

Too many versions with two many extra ones.

ha, only 8 years instead of 80 to version 2.

[exagonx]

With the release of fbc 1.10.0 completed, time to move on to the next version.

As always, questions or comments welcome.

Will compatibility with C11 headers be implemented?
It currently fails and crashes if I use libraries compiled in C higher than 9

[coderJeff]

Will compatibility with C11 headers be implemented?

Do you mean fb's translation of standard C headers in './inc/crt'? Because you are trying to call functions the standard C library?
I won't be working on this anytime soon.

It currently fails and crashes if I use libraries compiled in C higher than 9

What is 'It'?
- fbc itself crashes?
- fbc fails to compile the program because trying to use a function not in CRT headers?
- your program compiles but fails to link?
- your program runs but crashes at run-time?
- all programs crash? or just specific programs?

Maybe you already know or not:
- C11 is a language standard
- "C 9" is a typo for "C99"? Or you mean some compiler version?
- newer compilers have options for compiling C code to a specific standard.
- Mixing different toolchains (i.e. different versions of compilers of runtimes libraries) often does not work for static libraries.
- When using different toolchains / compiler versions, it is good idea (or required) to build fb's libraries with that specific toolchain/compiler.

[coderJeff]

I often allow myself to be distracted by a variety of challenges and personal interests, so please, some leniency in the previous claim.

Sure! What do you dabble in?

This question rolled around in my brain for a while. Thanks.

As far as freebasic goes, nothing really worth mentioning because if I give an example I think that would imply that it has some significance. Which it does't / won't. Mostly failed experiments and incomplete ideas to fix bugs or add features, or investigate what it would take to finish other user's ideas or incomplete contributions.

Ok, for example: debugging DOS is quite the pain and debugging DOS graphics is next to impossible - which are only a couple of the reasons I dislike working on the DOS port. A while back I thought I might try and figure out a DOS debugging solution which involved learning all the ways to connect to DosBOX through emulated serial port, writing a serial debugging host for DOS fb programs, and then only to find out that gdb serial debugging seems fundamentally broken for DOS. I wrote a patch for djgpp gdb's serial client but for the life of me could not figure out how to build a gdb to run on windows that properly reads the djgpp binaries - always invalid format. Eventually I gave up on that and at least tried to get rid of the graphics display update ISR. This might help a little with debugging graphics because the graphics update ISR puts *so much* code in the context of an interrupt handler that it is pretty much guaranteed to crash. There is a couple of minor updates in fbc but most of it still sits in an experimental branch in my repo. And not much point in committing an unfinished effort.

For a more personal example: last few months (or a year) I have become disappointed with automobile mechanics in our area. I have had good ones before, but after trying out a few new repair shops I gave up. Anyway, I used to do all my repairs when I was younger (e.g. change out a motor was probably the biggest) but at some point thought I had enough of crawling around on the ground and that a professional was worth it. Anyway, I have a couple of junkers for vehicles and try to keep them road worthy. Last major repair I did was welding exhaust back together and patching some other defects; which I had to buy a welder and practice with since I hadn't done any welding since years and years ago.

[exagonx]

- C11 is a language standard

When I compile a software with GTK (MSys2 environment) with old C 9.xx Version its work fine.

But when I make a update with C version 11 then give error during compiling missing header or function but the software allready compiled with old C work fine with updated runtime.

At moment I solved keeping a not updated Msys2 for compiling and I use the latest version of GTK for run the software its work fine, I writed A post about that problem is a common issue where my suggestion of not install or update C environment in MSys2 work fine.

viewtopic.php?t=31562

[coderJeff]

viewtopic.php?t=31562

ah ok, you meant gcc version. (... C is not equivalent to gcc)

ok, I give some information: in the other topic
Maybe it will help you find a solution. This doesn't seem like a header compatibility problem.

[Provoni]

I often allow myself to be distracted by a variety of challenges and personal interests, so please, some leniency in the previous claim.

Sure! What do you dabble in?

This question rolled around in my brain for a while. Thanks.

As far as freebasic goes, nothing really worth mentioning because if I give an example I think that would imply that it has some significance. Which it does't / won't. Mostly failed experiments and incomplete ideas to fix bugs or add features, or investigate what it would take to finish other user's ideas or incomplete contributions.

Ok, for example: debugging DOS is quite the pain and debugging DOS graphics is next to impossible - which are only a couple of the reasons I dislike working on the DOS port. A while back I thought I might try and figure out a DOS debugging solution which involved learning all the ways to connect to DosBOX through emulated serial port, writing a serial debugging host for DOS fb programs, and then only to find out that gdb serial debugging seems fundamentally broken for DOS. I wrote a patch for djgpp gdb's serial client but for the life of me could not figure out how to build a gdb to run on windows that properly reads the djgpp binaries - always invalid format. Eventually I gave up on that and at least tried to get rid of the graphics display update ISR. This might help a little with debugging graphics because the graphics update ISR puts *so much* code in the context of an interrupt handler that it is pretty much guaranteed to crash. There is a couple of minor updates in fbc but most of it still sits in an experimental branch in my repo. And not much point in committing an unfinished effort.

For a more personal example: last few months (or a year) I have become disappointed with automobile mechanics in our area. I have had good ones before, but after trying out a few new repair shops I gave up. Anyway, I used to do all my repairs when I was younger (e.g. change out a motor was probably the biggest) but at some point thought I had enough of crawling around on the ground and that a professional was worth it. Anyway, I have a couple of junkers for vehicles and try to keep them road worthy. Last major repair I did was welding exhaust back together and patching some other defects; which I had to buy a welder and practice with since I hadn't done any welding since years and years ago.

You sound like a tinkerer, and that reminds me of D.J.Peters.

An able mechanic / programmer is an interesting combination I've not heard of before. But one can see the similarities.

Thank you again for all your work.

[angros47]

I have a question: is there still any plan to fix the issue with arrays and scalars with the same name, in "LANG QB"?
Code like:

Code: Select all

A=5
DIM A(10)

doesn't work on FreeBasic, while it's perfectly legit in QB or in GWBasic or in hundreds of old basic dialects (in some of them, variables were allowed to have only two characters, for example on Commodore BASIC, so reusing the same name for scalars and arrays was often inevitable).

Sure, it is a bad coding practice, and it should be avoided while writing a new program, but while porting an old program that already used that syntax (and perhaps it used a speghetti-code structure, so editing it is a nightmare) the impossibility to use the same name for scalars and arrays is a severe limit. It is not even possible to automatically replace the variable name in the source code, because often in old codes variables used a single character name (to make parsing faster for the interpreter, and to save some bytes in the source size).

My question is: since such a feature should affect only -lang QB, and not other mode, can it be implemented with some solution like internally converting the name of any symbol used as array name, adding some prefix? Like, if the symbol "A" is encountered, and used as variable, compiler should check if it has an index, and in case process it as "_ARRAY_A" or something similar? It would avoid any conflict, since in QB code the underscore was never used in variable names.

Is my suggestion too naive? After seeing the incredible work CoderJeff made to implement nested types I wonder if the change I suggested is trivial, or if it would involve drastic changes in the compiler.

[exagonx]

Is my suggestion too naive? After seeing the incredible work CoderJeff made to implement nested types I wonder if the change I suggested is trivial, or if it would involve drastic changes in the compiler.

Of course, on the one hand it would be a convenience for individuals who are used to languages like Python where identifiers like VAR, DIM, etc. are not indispensable.

But implementing such a method drastically reduces the potential for objects, furthermore, as happens with Java and Python, an external interpreter is essential during execution.

Please note that GwBasic, Basica, Basic Commodore and QBASIC could use this mode but QB 4.5 onwards this mode was compatible but converted when compiling and creating an .EXE executable
In fact QB 4.5 needed its Runtime BRUN45.exe on the contrary FreeBASIC once created the executable this is autonomous excluding external libraries.

Not to mention that the applications created in BASIC were small so it was possible to trace an error in the sources in a short time, but personally I created applications in FreeBASIC and libraries that after 10 years I still use today implementing code and functions, going to modify a 10 years where currently the only sources measure 11 MegaByte I consider it crazy.

The syntax of FreeBASIC is perfect, it doesn't impose closure like C, it allows the use of blocks like Visual BASIC and it's suitable both for someone who knows how to program and for someone like me who learned everything by himself.

[angros47]

Even in FreeBASIC identifiers like DIM or VAR are not mandatory, in -lang QB and -lang fblite (unless OPTION EXPLICIT is used). Only in -lang fb the usage of DIM AS is required, since it is required for objects (that in fact are available only in -lang fb)

I was not suggesting to change that, my suggestion was about how to handle symbol collisions in qb mode, and only in qb mode.

By the way, GwBasic and BASICA were interpreted languages, and a compiler was available. QB 4.5 was both interpreted and compiled, and there were situations where the compiled and the interpreted mode returned different results (http://www.petesqbsite.com/phpBB3/viewtopic.php?p=39013)

It's not true that QB 4.5 needed BRUN45.EXE, it depended on the option selected during compilation.

I personally love the syntax of FreeBasic, the reason I requested this feature was that older BASIC codes cannot be compiled without it. And this actually include some of the examples of the ANSI BASIC, making FreeBasic non compliant. Also, on old programming magazines there are plenty of programs written in BASIC (gwbasic, commodore basic, MSX basic), almost all of them have collisions between scalars and arrays. If FreeBasic were able to compile them, it would be possible to port them on modern computers, maybe replacing the input-output sections with something more modern, and preserving the original algorithm unchanged. Some algorithms are written in spaghetti code, maybe the author themselves cannot figure how they work anymore (it's what happened in the game Entombed, https://en.wikipedia.org/wiki/Entombed_(Atari_2600)), but they work. I think being able to save this legacy is one of the goals of a language that is the last descendant of the BASIC language