+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: I have issues with Github (/showthread.php?tid=1100)
I have issues with Github - mnrvovrfc - 11-10-2022
I cannot create an account with Github because it goes against my pride, and some web browsers cannot handle well content of that site. Therefore this very bored user will bore you further with creating a thread just to offer even more opinions that might not be wanted...
If you want to "visit" the issue just drop into the address blank of your web browser:
s://github.com/QB64-Phoenix-Edition/QB64pe/issues/NUMBER
Purposely beheaded so it's not "clickable," and "NUMBER" should be the number shown after pound-sign below.
#233
I support this; just make release (middle) number padded with zero but not make it obvious to the programmer because some code exists that would test for "0.5.0", for "3.2.0" and it's only the beginning. For "3.2.0" case "internally" test for "3.02.0". In fact do it for "03.02.00" in case this programming system could reach version 10!
#219
One fault is that some users like "small" terminal windows, while a typical dialog could require at least 100 characters across. It would be impossible to predict when an user maliciously resizes that window to smaller size to see if the user program crashes. Would have to stick to low-bit characters to draw the dialog. I've discovered "ANSI" codes for coloring not reliable on some "terminal emulators" of Linux distros. This was from using a library called "Lua-term" which allowed simple output to the terminal with coloring and positioning, by using Lua code.
#212
Have "_RESULT" keyword, a lot like Pascal/Delphi, as alternative to "_RETVAL". I resist "EXIT FUNCTION" more than "EXIT SUB", I think it's a retarded way to break out of a function early, and there is too much code already which keeps using function name on LHS which is bad form. This new keyword should put an end to it at least for new programs.
#211
I support this. However, instead of lame-ass keywords from Visual Basic, as alternative how about a compiler option for it? I would like the short-circuit evaluation to be absolute if I choose.
#206
(To the one who opened this issue: ) You would have to change your way of thinking about this. If the concept of MAK file is insisted on you must rearrange your "project" so there is only one main program, and the other BAS files then become BI to be included into the main program. Each "main program" in "slave" BAS files should be put into their own "SUB's" to be called in a desired order by the only true main program. Otherwise each BAS file is destined to be compiled into a separate executable file, without relation to one another. This could be a pain because "CHAIN" and "COMMON SHARED" weren't meant to be used in 32-bit and 64-bit environment where security has some emphasis.
#187
On the Linux side you guys might want to talk to "angros47" that Italian guy who did an audio/MIDI playback library for Freebasic.
#30
This is one of my longest requests.