A Few Crazy Suggestions for QB64's Source Code

[davidshq]

Hi All,

I'm just playing around with things, so these ideas may be completely bonkers, but I figured I'd share them and hopefully hear why they are bad ideas or perhaps see them implemented.

I'm starting from the philosophical basis that the less source code there is the better as it makes it easier for folks to get their minds around the code, reduces potential for errors, reduces size of codebase, increases performance of IDE's, refactoring, etc.

1. My understanding is that the Android implementation never really took off and isn't complete and is unlikely to be completed. I'd suggest pulling this out and putting it into a separate repo. This would include the folder source\android
2. Remove internal\help and instead download help content as-needed or redirect to web wiki.
3. Remove download folders in internal\c\parts subfolders and either move into a separate repo or simply include a README.md with links to where the third party code can be downloaded.

Dave

[luke]

1. My understanding is that the Android implementation never really took off and isn't complete and is unlikely to be completed. I'd suggest pulling this out and putting it into a separate repo. This would include the folder source\android

I've been slowly removing Android stuff, just haven't got around to doing it all yet. I think there might be a bit of subtlety relating to the virtual keyboard but yes, it'll all be going.

2. Remove internal\help and instead download help content as-needed or redirect to web wiki.

I'll let Fellippe Heitor address this one.

3. Remove download folders in internal\c\parts subfolders and either move into a separate repo or simply include a README.md with links to where the third party code can be downloaded.

I like this idea.

One more thing, are you using git? If not you should definitely at least have git installed and the qb64 repository cloned so that any changes you might make can easily be bundled and applied to the main repository.

[FellippeHeitor]

2. Remove internal\help and instead download help content as-needed or redirect to web wiki.

I'll let Fellippe Heitor address this one.

Hi. I think the cache is a clever idea and should stay.

BTW, I just pushed a change into the repo to allow the help to be fetched from qb64.org/wiki when [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]/wiki is down (as right now).

PS: An option to redirect to the wiki online is a good thing and fairly easy to implement, that's a good one.

[davidshq]

Fellippe - So you would be onboard for #3 - removing downloads folders? I wasn't clear on what the caching was - either the help files or the downloads.

Luke - If internal/source is auto-generated so one shouldn't really be editing it, does it make sense to remove it from the repo?

[luke]

I presume that's your pull request on github. It'll probably take me a week or so to go through it all, but just off the bat:

I probably didn't make the clear earlier, but although the internal/source/ stuff is automatically generated, it's still needed for bootstrapping the process that produces the content in internal/source/... confusing, eh? If you want to understand exactly how it works, look at .travis/appveyor.bat - that's the script that updates the folder and produces the windows builds on qb64.org homepage (changes to the repository are actually made by the linux scripts or by a [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] process, but that's a story for another time...).

Long story short you can either do a git revert on the commit that deletes the folder or I'll just exclude it when I merge everything in.

[davidshq]

Thanks Luke! Yes, that is my pull request, though I withdrew it and made  a new request after your clarification regarding the source folder.

Saw your notes about the editor making some changes to capitalization. Sorry about that...Let me know if you want me to look through the source in any specific way and try to amend the pull request.

Dave

[davidshq]

I think I figured out what went wrong with the code commit, but I'm not entirely sure why. When I looked at where in QB64.BAS the error was being thrown and saw that it was a call to AryAddStr it felt familiar. I remembered in android_methods.bas I'd seen two functions which weren't like the rest (having Android somewhere in their name), sure enough, you can see the functions in the official repo here:

https://github.com/Galleondragon/qb64/blob/22dcf8b79998d7ae5e09ef5a1e64a10b0e9234dd/source/android/android_methods.bas

So I took these two functions and added them to the very end of QB64.BAS:

Code: QB64: [Select]

1. SUB AryAddStr (Ary() AS STRING, value AS STRING) 'create new entry and return its index
2. IF LEN(Ary(0)) = 0 THEN Ary(0) = "0"
3. index = VAL(Ary(0)) + 1
4. lastIndex = UBOUND(Ary)
5. IF index > lastIndex THEN
6.     lastIndex = index * 2
7.     REDIM _PRESERVE Ary(lastIndex) AS STRING
8. END IF
9. Ary(0) = STR$(index)
10. Ary(index) = value
11. AryNewStr = index
12. END SUB
13.  
14. FUNCTION AryLastStr (Ary() AS STRING) 'get last used index or 0 if none used
15. IF LEN(Ary(0)) = 0 THEN Ary(0) = "0"
16. AryLastStr = VAL(Ary(0))
17. END FUNCTION
18.  

But now in QB64 when I pull up QB64.BAS I'm getting the error:

"Incorrect array type passed to sub"

The line in question being:

Code: QB64: [Select]

1.  AryAddStr installFiles(), sourceContent$

This leads me to believe VS didn't change the code, but there were two functions in android_methods.bas that were used outside of Android functionality. Why it is now giving the error about the array type I am unsure....

[davidshq]

Okay, so I think I figured that out. installFiles() is redimmed in android_global.bas:

https://github.com/Galleondragon/qb64/blob/master/source/android/android_global.bas

So I added the redim toward the top of QB64.BAS

This then surfaced that there were several other redims that were only declared in android_global.bas, so I added them similarly so that when complete the added code looks like:

Code: QB64: [Select]

1. REDIM SHARED installFiles(0) AS STRING
2. REDIM SHARED installFilesSourceLocation(0) AS STRING
3. REDIM SHARED installFilesIn(0) AS STRING
4. REDIM SHARED installFolder(0) AS STRING
5. REDIM SHARED installFolderSourceLocation(0) AS STRING
6. REDIM SHARED installFolderIn(0) AS STRING
7.  

Now on to why I'm getting the errror:

"SUB does not require any arguments in line 1505 of qb64\source\ide\ide_methods.bas included on line 25161"

[davidshq]

I haven't figured out the error I reported in my last post but I have pushed the changes to QB64.bas that should take care of the code in the android folder that was being used for more general purposes.

[davidshq]

So Luke, you were right, the editor did make some changes to capitalization, etc. in the BAS files. I'm not sure why, it didn't even do it consistently across the BAS files.

In any case, I downloaded the repo from Galleon's official and used WinMerge to do a comparison on the BAS files and reverted all the changes that weren't intentional throughout them. I just pushed it live, should show up as part of the pull request now. This should resolve the build issue.

[SkyCharger001]

Removing the internal help-cache is a bad idea:
how is one supposed to access the help-data when either [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] or your internet-connection is down if you don't have a cache?

[davidshq]

SkyCharger - I'm abandoning that suggestion, as the consensus seems to be that it should be retained.