QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: FellippeHeitor on September 25, 2021, 12:04:24 am

Title: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 12:04:24 am

New development build available. Testers wanted. (https://www.qb64.org/portal/development-build/)

As seen on https://www.qb64.org/forum/index.php?topic=704.msg5775#msg5775 (https://www.qb64.org/forum/index.php?topic=704.msg5775#msg5775)

So up until v1.5 QB64 contained a bug that wouldn't allow recursion involving a function without parameters. This was incompatible with our mother ship, QuickBASIC 4.5, and in the upcoming v1.6 we will have that behavior fixed.

Drawing from the post I linked above, the code...

Code: QB64: [Select]
  1. X = 5
  2.  
  3.     IF X = 0 THEN
  4.         F = 1
  5.     ELSE
  6.         PRINT "*"
  7.         X = X - 1
  8.         F = F
  9.     END IF
  10.  

...will now properly print 5 stars and the number 1 before it ends, because the assignment line F = F will properly call Function F, as one would expect.

This means you shouldn't work with the return variable of a function as a regular variable. The best practice/approach is to have a temporary variable in case you need to build the return value as the function is processed, and only in the end of the procedure do the functionName = returnValue assignment.

Let me know how the new dev build (https://www.qb64.org/portal/development-build/) will deal with your existing code, while keeping the above observations in mind.

And thank you for flying QB64.
✈️
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 25, 2021, 05:11:41 am
This means you shouldn't work with the return variable of a function as a regular variable. The best practice/approach is to have a temporary variable in case you need to build the return value as the function is processed, and only in the end of the procedure do the functionName = returnValue assignment.

Well done Fellippe, although the above quoted condition will definitly give me some headaches and need to refactoring my GuiTools in some places.

Very good you pointed that out...
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 25, 2021, 08:06:47 am
Well, to clarify that condition somewhat better:
Is that so far correct @FellippeHeitor, or are there other points to be aware of?
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 25, 2021, 08:29:33 am
One more:

The last two points in the list of my previous post are not only valid for the function name used on the right side of the equal sign (=), but also if used as argument in other statements/function calls.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 08:31:38 am
Spot on, Rho.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 25, 2021, 09:26:07 am
Spot on, Rho.

Well, then refactoring can begin,
guess this change has the potential to be a cuckoo egg in many different projects of many different people ;-)
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 11:15:26 am
Exactly due to being a breaking change, we’re internally coming to final terms on bringing the version bump to 2.0.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 11:16:31 am
Btw, are you not on Discord for moral issues or are you just not a chat room guy? Your input in the dev lounge is always very welcome and appreciated.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 25, 2021, 12:34:10 pm
Exactly due to being a breaking change, we’re internally coming to final terms on bringing the version bump to 2.0.
I hope you made sure, that this change doesn't bite your own butt within QB64.bas and all the other basic source files involved, would be too bad, if QB64 breaks itself by enforcing the new behaviour.

At least for my GuiTools the impact is much higher than expected first, as things like assigning a result value through an intended argument side effect of a SUB call won't work anymore.

eg:
SetTag ButtonC$, "ERROR", classID$ + "::" + methodID$ + " -> missing required tags"

that's a typical line in GuiTools, ButtonC$ is the actual function name, and the final error tag assembled by the SetTag SUB was then returned in ButtonC$ as side effect, but now ButtonC$ would call the Button class instead.

I've to find a new elegant method now to do this in a similar way, as simply each time using a temp variable in the SetTag call and afterwards assigning that to the class its function name seems much to plumsy for me.

Btw, are you not on Discord for moral issues or are you just not a chat room guy? Your input in the dev lounge is always very welcome and appreciated.

Not a chat room guy, also with nursing my sick old mom (87y) no time to engage in (almost) real time discussions.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 12:43:01 pm
Quote
I hope you made sure, that this change doesn't bite your own butt within QB64.bas and all the other basic source files involved, would be too bad, if QB64 breaks itself by enforcing the new behaviour.

So far so good with qb64 and several of my personal projects.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: SMcNeill on September 25, 2021, 12:50:51 pm
I’m running into the same issues with a lot of my stuff, particularly with regards to direct assignment issues.

FUNCTION foo$ (filehandle, line)
   SEEK #filehandle, 1
   FOR I = 1 TO line
      IF EOF(filehandle) THEN foo$ = “ERROR, PAST END OF FILE”: EXIT FUNCTION
      LINE INPUT #filehandle, foo$
   NEXT
END FUNCTION

Gets, puts, inputs, prints…. I have a ton of these which just referenced the function name as a variable name, which are going to need alterations.

I imagine we’re going to see a slew of reports about libraries erroring out with the next version update, and the librarians will need to check the code in the forum’s library area to test and make certain everything there works as advertised in the future. (The “Samples Gallery & Reference area now.)
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Ryster on September 25, 2021, 01:04:09 pm
Hello
What's the problem?.
For me it displays as a result of compilation: 5 stars and 1
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: jack on September 25, 2021, 01:13:30 pm
will recursion still work?
Code: QB64: [Select]
  1. Print Factorial_Recursive&&(5)
  2.  
  3. Function Factorial_Recursive&& (n As Integer)
  4.     If n = 0 Then Factorial_Recursive&& = 1: Exit Function
  5.     Factorial_Recursive&& = n * Factorial_Recursive&&(n - 1)
  6.  
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 25, 2021, 01:18:33 pm
I imagine we’re going to see a slew of reports about libraries erroring out with the next version update, and the librarians will need to check the code in the forum’s library area to test and make certain everything there works as advertised in the future. (The “Samples Gallery & Reference area now.)

Of course, somebody could argue, that the required amount of work needed to make existing code compliant to the changed behavior, just for the rare case that argumentless functions can be correctly called recursivly, is not worth the whole thing. In fact, this was my first thought too, but nevertheless I'm fully behind this change, as it's the logical behavior as you also find it in C/C++, Javascript, Perl etc., so let's do the changes now, before it gets even more painful.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Ryster on September 25, 2021, 01:40:53 pm

Is that a question for me?
If so, it displays the result 120 after compilation
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Ryster on September 25, 2021, 01:44:53 pm
will recursion still work?
Code: QB64: [Select]
  1. Print Factorial_Recursive&&(5)
  2.  
  3. Function Factorial_Recursive&& (n As Integer)
  4.     If n = 0 Then Factorial_Recursive&& = 1: Exit Function
  5.     Factorial_Recursive&& = n * Factorial_Recursive&&(n - 1)
  6.  

Is that a question for me?
If so, it displays the result 120 after compilation
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: bplus on September 25, 2021, 01:57:50 pm
Hello
What's the problem?.
For me it displays as a result of compilation: 5 stars and 1

Here's a question for @Ryster: What version are you getting the correct answer of 5 stars and a 1?

My QB64 v1.5 does fail the test demo Fellippe offered.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Petr on September 25, 2021, 01:58:25 pm
It seems to work as it should. I also welcome this upgrade, but I am absolutely sure that it is only a matter of time before this thing catches up with me. It's great that it now works. My current programs all working as expected in this version.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: bplus on September 25, 2021, 02:03:44 pm
I am leary of the change, but I am an old fogy and hate change that is not my idea anyway ;-))

It is so easy to fix a () less function with a dummy I don't see it worth the risk specially a revision # change to 2.

Fixed with dummy, like this
Code: QB64: [Select]
  1. X = 5
  2. Print F(0)
  3.  
  4. Function F (dummy)
  5.     If X = 0 Then
  6.         F = 1
  7.     Else
  8.         Print "*"
  9.         X = X - 1
  10.         F = F(dummy)
  11.     End If
  12.  
  13.  
  14.  

And this line makes way more sense to me.
Code: QB64: [Select]
  1. F = F(dummy)
  2.  
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Ryster on September 25, 2021, 02:04:37 pm
https://www.dropbox.com/s/79v4le52cn44icc/Test_Qb64.jpg?dl=0
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: bplus on September 25, 2021, 02:10:48 pm
https://www.dropbox.com/s/79v4le52cn44icc/Test_Qb64.jpg?dl=0

Well that's older than 1.5 there's no revision number, is that QB45? ;-))

What's that icon in top left corner?
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 25, 2021, 03:36:56 pm
I am leary of the change, but I am an old fogy and hate change that is not my idea anyway ;-))

It is so easy to fix a () less function with a dummy I don't see it worth the risk specially a revision # change to 2.

Fixed with dummy, like this
Code: QB64: [Select]
  1. X = 5
  2. Print F(0)
  3.  
  4. Function F (dummy)
  5.     If X = 0 Then
  6.         F = 1
  7.     Else
  8.         Print "*"
  9.         X = X - 1
  10.         F = F(dummy)
  11.     End If
  12.  

And this line makes way more sense to me.
Code: QB64: [Select]
  1. F = F(dummy)
  2.  

Very good point @bplus to take into consideration. Will probably waiting a couple more days before start refactoring my stuff, to see if @FellippeHeitor and the other responsible DEVs rethink the whole thing and come up with a solution, which makes less impact on existing code (maybe another Meta command to switch between the old/new behavior? - If it ever was worth to add a new meta, then for this one, it would avoid the whole effords mentioned by Steve).
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: bplus on September 25, 2021, 03:47:38 pm
Exactly due to being a breaking change, we’re internally coming to final terms on bringing the version bump to 2.0.

If you ask me, the outstanding revision of having built-in Debugging IS change enough for bumping version number to 2.0 ie after 2.0 you have built-in Debug; makes sense to me.

How much of a need is there for parameter-less functions?

I saw a little discussion on another forum about confusion between using () for functions and () for arrays, just imaging now a string function looking like a string variable F$ = string variable or function?

or using it in an
IF f$ = g$ Then...

Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: SMcNeill on September 25, 2021, 04:04:09 pm
Very good point @bplus to take into consideration. Will probably waiting a couple more days before start refactoring my stuff, to see if @FellippeHeitor and the other responsible DEVs rethink the whole thing and come up with a solution, which makes less impact on existing code (maybe another Meta command to switch between the old/new behavior? - If it ever was worth to add a new meta, then for this one, it would avoid the whole effords mentioned by Steve).

A $NoRecursion meta command would be nice.  When stuff breaks, it’d be simple to point to it and tell folks, “Try this at the top of your code first.”  Recursion was always been just an issue with functions with zero parameters and worked with those that had them (or dummy params).  Back when I posted a fix for this three years ago, nobody wanted the functionality and I never added it into the repo.

https://www.qb64.org/forum/index.php?topic=704.msg6085#msg6085

We discussed it on Discord, tossed the idea around a bit, and then ultimately abandoned it — which is why I never tried to write code around the concept that it’d ever be changed. 

Boy, do I got a lot of rewriting to do now, just to keep all my libraries up to date once this goes live! 
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: doppler on September 25, 2021, 05:02:51 pm
bringing the version bump to 2.0.

All the resistance to going a full point but, I always knew the debugger stuff would warrant a full bump.  Now this just enforces the change.

Sometime near future, when QB64 gets to V4.5, we are going to skip that one right ?
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 05:27:03 pm
will recursion still work?

The fix is exactly to allow recursion all the way. QB64 had the bug described in my first post that wouldn't allow a function without parameters to be called recursively, and the new patch fixes that.

To be clear: QB64 didn't behave like QuickBASIC 4.5 did - any code that relied on this bug wouldn't have worked in QB4.5, due to that. We're catching up with a long-standing issue, one that will require some getting used to.

This is why we need as many of you to help us figure out if anything won't work as outlined in my first post in this thread, like Steve and Rho have been doing (thanks, you two!).

Hello
What's the problem?.
For me it displays as a result of compilation: 5 stars and 1

I have no idea what version of QB64 you're using. That interface sure looks outdated. The code I shared in the first post of this thread won't produce the proper results in v1.5. Please let us know more details.

It seems to work as it should. I also welcome this upgrade, but I am absolutely sure that it is only a matter of time before this thing catches up with me. It's great that it now works. My current programs all working as expected in this version.

That's great to hear, thanks Petr!

How much of a need is there for parameter-less functions?

It's not proper that we support recursion half-way - and the new patch will fix a long-standing issue. We've always aimed to get as close as possible to 100% compatibility with QB4.5 code, and this is a step forward.

As explained before, any existing code that treated the function name as a regular variable was relying on a buggy feature, and it'll take some getting used to the fixed (right) way.

Boy, do I got a lot of rewriting to do now, just to keep all my libraries up to date once this goes live! 

We will have a good chunk of code-reviewing to do all over the place, as you pointed out. We have the Samples gallery and also the wiki - which btw contains an example in the very page for Function that relies on the buggy implementation we're now fixing.

Very good point @bplus to take into consideration. Will probably waiting a couple more days before start refactoring my stuff, to see if @FellippeHeitor and the other responsible DEVs rethink the whole thing and come up with a solution, which makes less impact on existing code (maybe another Meta command to switch between the old/new behavior? - If it ever was worth to add a new meta, then for this one, it would avoid the whole effords mentioned by Steve).

The decision to make this a a new major version release (v2.0) stems from all that's outlined at https://semver.org/ <-- recommended reading.

The tl;dr version is: we're making a fix that can break existing functionality - that grants the version bump while clearly stating "you folks may need some extra work, here's how it works now".

And we're glad it will from 2.0 onwards work as it should always have.

@All: testing continues, I thank you all for joining the ride and please let me know if all works as outlined in the first post in this thread.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 05:29:24 pm
All the resistance to going a full point but, I always knew the debugger stuff would warrant a full bump.  Now this just enforces the change.

Sometime near future, when QB64 gets to V4.5, we are going to skip that one right ?

That's definitely something to consider 🤣
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 25, 2021, 05:34:04 pm
Back when I posted a fix for this three years ago, nobody wanted the functionality and I never added it into the repo.

https://www.qb64.org/forum/index.php?topic=704.msg6085#msg6085

That wouldn't have fixed it entirely, but it's been hanging there for three years, with your question on that thread echoing in my head:

It's kinda a hack, but it works -- unless somebody has a more elegant solution?

I'm glad you're on board.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Ryster on September 26, 2021, 03:04:04 am
I actually tested with an older 32-bit version. After all, there were no test restrictions :). It is currently still the best last 32-bit version to be released so far. The next newer 32-bit versions couldn't handle my code. I am currently using the 64-bit version because none of the newer 32-bit versions, as well as the older one in question, can compile due to the size of the code. For those interested -> in the upper left corner of the window is the coat of arms of my country :).
Applies to: QB64x32 v 0.82
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: jack on September 26, 2021, 03:46:53 am
@FellippeHeitor
I agree with the changes you did to QB64, I think that the compiler is treating recursive functions properly now and gives meaningful error messages if you attemp to use the function name as a variable :)
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 26, 2021, 05:35:31 am
@FellippeHeitor
I agree with the changes you did to QB64, I think that the compiler is treating recursive functions properly now and gives meaningful error messages if you attemp to use the function name as a variable :)

+1
yes, the error messages will definitly be helpful identifying parts of existing code which need refactoring, so far I've catched 12 functions (not GuiTools related) in my programs, which I'll fix first before fighting with the monster, GuiTools :)
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: TempodiBasic on September 27, 2021, 05:05:09 am
Great job!
More backward compatibility.
Milestone changement that requires efforts of coders to change some behaviors based on the previous uncorrect feature.
Great community of QB64
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Dav on September 27, 2021, 09:40:08 am
Tried out the 32-bit Dev build this morning.  I made sure to test it on my games that use a recursive floodfill routine to make sure all works ok.  Working very well. 

Only thing I noticed is that the font size change wouldn't work at all on first run. It did the next time I started QB64.  No big deal of course, but I don't remember that happening before. 

Ayway, the recent changes to QB64 work great.  Well done!

- Dav
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on September 28, 2021, 03:27:17 am
Tried out the 32-bit Dev build this morning.  I made sure to test it on my games that use a recursive floodfill routine to make sure all works ok.  Working very well. 

Only thing I noticed is that the font size change wouldn't work at all on first run. It did the next time I started QB64.  No big deal of course, but I don't remember that happening before. 

Ayway, the recent changes to QB64 work great.  Well done!

- Dav

Great to hear, @Dav! Thanks for helping me test it.

@TempodiBasic: Thank you!

@RhoSigma: you'll notice the latest dev build now calls itself 2.0 😉
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on September 28, 2021, 03:42:10 am
Thanx @FellippeHeitor for your hard work, downloading the latest build just now.

Fixing my non-GuiTools stuff is almost done. Surprising to me is, that most of the things which need refectoring regarding the recursion behavior are of newer dates (post GuiTools). Older code, in part still from my QBasic 1.1 times is not affected. A prove that it wasn't possible there and I just started adapting it when I started GuiTools and realized I could use the function name as a variable directly in QB64. A bad decision, when looking back now :(

And now with this post I finally became a QB64 Developer and Forum Resident, yeah....
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: FellippeHeitor on October 03, 2021, 07:35:30 pm
And now with this post I finally became a QB64 Developer and Forum Resident, yeah....

BTW, becoming Forum Resident is due to posting frequency. Becoming a QB64 Developer happened when you contributed to QB64 itself, so setting your status here was long overdue.

@Cobalt has also been "promoted". Thank you gentlemen for your work in QB64.
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: RhoSigma on October 03, 2021, 07:56:24 pm
BTW, becoming Forum Resident is due to posting frequency. Becoming a QB64 Developer happened when you contributed to QB64 itself, so setting your status here was long overdue.

Ah, makes sense now seeing other "Forum Residents" without being "QB64 Developer", two different things.

To get to the latest dev build, as far as I can tell, everything is working as expected on my side, also finished refectoring of GuiTools and others regarding the fixed recursion bug and not treating the function name as variable anymore, so updates comming soon...
Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: Cobalt on October 04, 2021, 04:20:06 pm
@Cobalt has also been "promoted". Thank you gentlemen for your work in QB64.

😎 Schweet! 😎

Title: Re: [dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!
Post by: SMcNeill on October 04, 2021, 05:29:23 pm
@FellippeHeitor Might I suggest a different title, if possible on the forums.  Instead of QB64 Developers, call us QB64 Contributors.  Rho, Cobalt, and I, (and several more folks) have pushed a few changes into the repo and have contributed to QB64, but we're not really part of the Development team. 

We can’t, for instance, tell someone when the next release is coming out, what the next stage of future development might contain or which way it might develop next, and we have no control over the forums, repo, or other such aspects of the project.  We can write and contribute code that we like, to make additions or corrections, but we're not really Developers. 

New forum members shouldn’t see those Developer tags beside names, as we can only truly make educated guesses on those type subjects.  You and Luke should keep the QB64 Developer titles for yourselves.


(Just my opinion, and in no way is meant to belittle Rho or Cobalt getting the new tag.  They’ve both contributed to the project and deserve some nice recognition for that.  But there really should be one more level of ranking in there so folks won’t misassume we’re the ones with ultimate control over things, when we’re not.)