FreeBASIC 1.08 Development

[angros47]

Another thing to ask... for the dos version, has the symbol table been updated?

[robert]

@robert, I believe I have added the needed notes to wiki documentation regarding libtinfo/libncurses for installing and building fbc. You are welcome to change as needed.

If I understand a little of this issue: libncurses and libncursesw both need libtinfo functionality, but libtinfo may or may not be separate library. Some lInux distros have the libtinfo package available for install, but only serves to install a symlink to ncurses. However, if the package dependencies are correct, then all dependencies should get installed when installing ncurses-dev, which includes libtinfo-dev, which may be a library or a just symlink.

Hi Jeff:

Yes that is about as comprehensive an explanation as can be made, in my opinion.

After my initial posts on libtinfo I did more study and found that I could not do a symlink from libtinfo.so.5
in OpenSUSE 15.1 or TumbleWeed. There may have been a combo I missed but I really did try to get a
functional libtinfo.so.5 out of the standard packaging and did not hit a working combination. For OpenSUSE the libncurses5
download is really needed. If I recall correctly, the libncurses5 download installs libncurses.5.9 and symlinks libtinfo.so.5 to it.

Thank you for attending to this.

[coderJeff]

This would allow a simplified maintenance of the bindings and other FB users could easily provide their own or help updating. Everything one needs to do to update a binding that already exists in the fbbindings repository is to
- update the makefile to download the latest version of the C headers
- repeat: run the fbfrog tool & manually review results & update the fbfrog configuration if needed; until headers look fine
- test binding (e.g. compile & run example application (ideally on different platforms)) and apply fixes to fbfrog config (preferable) or manually (if needed)
- submit a PR for the fbbindings repo with the updated configurations and headers

Sounds good to me. I think fbbindings repo has a pretty good work flow. Only improvement I would suggest is I feel llike the repo should be restructured to put scripts/configurations for translating bindings in separate directories; try to make it modular.

[coderJeff]

Another thing to ask... for the dos version, has the symbol table been updated?

Yes, currently updated in fbc/master for 1.08 (and was updated too in 1.07.1 release).

I didn't fully automate it, only a helper makefile. From top-level directory of fbc clone, can do:
make TARGET_OS=dos
make -f src/rtlib/dos/libexp.mk
make TARGET_OS=dos

So it only rebuilds what is needed. However the dependency is still cyclic. Only if I change the master makefile to create an intermediate rtlib can the cyclic dependency be removed. I didn't want to mess with that for 1.07.1 release, so for now is still a manual step.

[Dinosaur]

Hi All

This may seem to be a rather mundane request, BUT it is really annoying to me.

Why is this not allowed ?

Code: Select all

For MyUDT.Index = 1 to MyUdt.Limit

	'Do whatever
	
Next

I have to transfer the udt elements to & from a local or global variable.
I have lost count how many times I wrote code as per above, only to have to change it.

Regards

[fxm]

However, that is allowed:

Code: Select all

For i As Integer = 1 to MyUdt.Limit

   'Do whatever
   
Next

[marcov]

Loopvars often must be simple variables, because there is an attempt to heavily optimize the loopvar, and the number of scenarios and pitfalls rises enormously.

Real FORs only evaluate the bounds once to calculate a number of iterations, so the bounds don't have to be simple variables because they are loaded once anyway. (this is why C FOR is not a real FOR, but a while shorthand)

[jj2007]

Real FORs only evaluate the bounds once to calculate a number of iterations

Right, with my own FOR...NEXT construct I do that for integers, singles and doubles alike. It's by far the simplest and fastest solution. In particular, with non-integer counters you save a float-to-float comparison, which is fairly slow. The only problem to watch for is the precision needed to calculate the exact number of iterations.

Once this number is known, there are two ways to set the counter:
a) add the step in each iteration (short, fast, slightly inexact)
b) multiply the step with the current iteration counter, then add the start value (slower but fairly exact)

[Dinosaur]

Hi All

So, basically it is to complex to implement.
I guess the closest way to do it with While:Wend requires 2 extra instructions.

Code: Select all

While MyUDT.Index <  MyUdt.Limit
	MyUDT.Index += 1
   'Do whatever
   
   Exit while
wend

But then again I have no idea as to the overhead of each method, so while :wend could actually be faster ??

Regards

[D.J.Peters]

In original BASIC the FOR counter var was a local or global var and accessible inside of the loop.
In the early days no EXIT FOR command exists.

Code: Select all

10 FOR I% = 0 to 15 STEP 2
20  IF (I% AND 4) THEN GOTO 40 REM a kind of 'CONTINUE'
30  IF (I% = 6) THEN I% = 15 REM a kind of 'EXIT FOR'
40 NEXT I%

Looks like FreeBASIC follows more the QBASIC behavior.

I'm right ?

Joshy

[caseih]

Alternatively, the direct equivalent to the original non-working for loop code that Dinosaur posted would be something like this:

Code: Select all

dim i as integer
...
for i=1 to MyUDT.Limit
   ...
next
MyUDT.index = i 
'note that i is MyUDT.Limit+1

But if it's important to keep MyUDT.Index updated, it's much clearer to use while/wend anyway.

[caseih]

Real FORs only evaluate the bounds once to calculate a number of iterations

I know you weren't referring to floating point numbers with "real" there, but that reminds me, the earliest BASIC I used was BASICA or GWBASIC, and the default variable type was floating point (single if I recall). That would make it very hard to calculate the number of iterations and know the bounds ahead of time, except when integer was specifically specified. Thus I doubt that BASIC used any optimizations here. It almost certainly was just equivalent to a WHILE loop. I know some earlier BASICs where integer only, so could have had such optimizations.

[marcov]

Real FORs only evaluate the bounds once to calculate a number of iterations

I know you weren't referring to floating point numbers with "real" there, but that reminds me, the earliest BASIC I used was BASICA or GWBASIC, and the default variable type was floating point (single if I recall). That would make it very hard to calculate the number of iterations and know the bounds ahead of time, except when integer was specifically specified. Thus I doubt that BASIC used any optimizations here. It almost certainly was just equivalent to a WHILE loop. I know some earlier BASICs where integer only, so could have had such optimizations.

Interpreters are different beasts all together, specially on such ROM and RAM constrained systems. While I used QBasic regularly for one or two years, I never used the others seriously. I could vaguely remember similar issues with C=64 Basic (which was early eighties Micro Soft Basic, then still spaced, code mostly by a certain Bill Gates (though afaik at the time he called himself still W. for William in formal docs)).

IIRC the for loop of C=64 basic, which was also quite early, reacted different for integer (a%) and real arguments. It was a known beginners mistake to use non % variables.

However I have a book with the commented ROM listing, and found a handy index to it here, so I looked it up.

FOR and NEXT are implemented and operate separately, using the interpreter accumulator, and storing it back to variable before the next statement.

Even variable names and exact nesting status is looked up by searching the interpreter stack each time again. So the base loop is indeed universal, and the integer gains, if any, must have been in the subroutines that do the various actions. (logical, since they wouldn't have to do soft fpu)

For does seem to store the bound and step data in a 18-byte record, iow it seems they are only evaluated once, but since the result is in the loopvar, and there seems to be no integer iteration count in the 18-byte record, it seems it really is the while like.

[Dinosaur]

Hi All

I appreciate the discussion on the issue I raised, even though I thought it a "Mundane" issue.
Also I now understand the complexity involved with changing what I envisaged to be a fundamental issue.

I don't normally get involved with development issues, BUT,reading all the submissions for the next upgrade, I can't help but think the beginners are left out
of the consideration about what is needed. The issues raised are all beyond me and my needs.
I know I am not a beginner, but a traditional programmer that doesn't understand why something is not allowed.
Even though it seems so obvious "THAT IT SHOULD BE".
FB is a tool, and if the tool does not suit the purpose, get one that does.
The path to complexity is via being a beginner.

Perhaps we will attract a lot more "beginners" or "participants" if the focus was more on what seems "obvious".
Many times I have come across those issues,yet been reluctant to question "Why".

Ok, so I have had my rant.

Regards

[jj2007]

The issues raised are all beyond me and my needs.

Hi Dinosaur,
Your rant is perfectly understandable. What I am more worried about, however, is that FB goes into the direction of a BASIC caricature of C++. Nonetheless, keep in mind that this thread is about the development of the next FB version, so it's not really aimed at beginners or occasional users.