Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - RhoSigma

Pages: [1] 2 3 ... 38
1
QB64 Discussion / Re: Cheerio, it's been fun
« on: April 16, 2022, 08:08:27 am »
Oh no, last week already Fellippes account disapeared without a word and now you. Maybe handing qb64.org over to that RCcola guy was the wrong choice.

Is this the end of QB64 ?  -- Or even worst the start of its commercializing ?

But well thanks for all the efforts you did for it, luke ...

Sincerly,
RhoSigma, Roland Heyder

2
QB64 Discussion / Re: _FileExists not working with wildcards
« on: April 14, 2022, 02:42:47 pm »
Quote from: hanness on April 14, 2022, 02:39:32 pm
Actually, I think that I just figured out a little kludge of a workaround.

Before executing the kill command, simply create a fake file called Trash0.txt. That guarantees a file of the format Trash*.txt exists and that will prevent the kill command from throwing an error.

Of course, easy workaround, if it's ok for you to create a file just to immediately delete it again.

3
QB64 Discussion / Re: _FileExists not working with wildcards
« on: April 14, 2022, 02:40:06 pm »
Code: QB64: [Select]
  1. For n% = 0 To 1000 'change if you expect more files
  2.     f$ = "Trash" + LTrim$(Str$(n%)) + ".txt"
  3.     If _FileExists(f$) Then Kill f$
  4. Next n%
  5.  

4
QB64 Discussion / Re: Virus detected when I delete .exe files
« on: March 30, 2022, 07:52:32 pm »
1.) You excluded your QB64 folder from virus scanning
2.) Guess your Recycle Bin is NOT excluded

So what do you think is happening here:
As soon as your deleted exe is moved to Recycle Bin it becomes "visible" for the virus scanner. It also explains why the names are different, as windows maintains the files in the Recycle Bin with internal names (probably symbolic links).

3.) Does the same happen, if you hard delete (bypassing Recycle Bin) using SHIFT-DELETE ??

5
QB64 Discussion / Re: Has $Debug been working well for you?
« on: March 14, 2022, 12:04:21 pm »
Wouldn't $ASSERTS and the _ASSERT command serve for this kind of debugging https://wiki.qb64.org/wiki/$ASSERTS ??

6
QB64 Discussion / Re: Repo renaming compiler folders
« on: March 10, 2022, 09:05:31 am »
Quote from: FellippeHeitor on March 10, 2022, 08:55:17 am
All I know is we're not touching that before Luke chimes in.

Don't worry, I'll do hell and rather keep my hands of the build process :), now that I know what's the (possible) thought behind it, I simply delete the folder(s). It's not just the unused mingw folder but also several others from the actually used (c_compiler) folder, after that I'm down to 5910 files in 296 folders and everything still works as expected. Probably ther's even more stuff we don't really need to use QB64 and compile our programs.

7
QB64 Discussion / Re: Repo renaming compiler folders
« on: March 10, 2022, 08:49:48 am »
Well that's indeed a pro to keep it in the repo as is, but why must the unused mingw folders retain in the development build archives? They are delivered completly setup and ready to use, it's not a local clone of the repo in GitHub Desktop, which you mess up when running the setup script.

We should distinguish here between our repo (where we developers work) and the releases (dev/stable) made for the ordinary user, who doesn't care about QB64 development and what's in the repo. A pure user usually want compact packages with as less as possible files and not 30000 from which 25000 are never used or even touched.

PS - Jesus, you guys are so fast :) consider this to be posted right as the first reply after Steve's initial post...

8
QB64 Discussion / Re: Has $Debug been working well for you?
« on: March 10, 2022, 05:49:47 am »
Quote from: FellippeHeitor on March 09, 2022, 11:59:55 pm
Latest dev build available now contains the new ability to choose number format, as per @RhoSigma's suggestion (dec/hex/oct/bin) as well as a fix for the issue reported by @tomxp411 regarding occasional crashes due to removing variables between $debug sessions.

Just tested, works perfect for me, even the "remember" feature between debug sessions.

But what happened to the development builds? - 145MB 7z, with nearly 30000 files each (32/64)?

Oh, after a closer look, it seems both archives deliver both compiler versions (mingw32/64), one of it is renamed to c_compiler (according to version), but instead deleting the other one, it remains in place. Is this intended or a glitch in the build process?

I mean I could live with it in the development builds, but later in the release archives it should definitly strip out the unused compiler distibution.

PS - talking about the windows archives...

9
QB64 Discussion / Re: Has $Debug been working well for you?
« on: March 09, 2022, 01:19:25 pm »
Quote from: FellippeHeitor on March 09, 2022, 12:26:00 pm
@RhoSigma Does this look like what you had in mind?

@FellippeHeitor, that's perfect. Nice & easy implemented. With that tiny button appearing when hovering a number I'd even say, we can waive to the "remember" feature I suggested, as access and changing the value is only a click away :), well done...

10
QB64 Discussion / Re: Has $Debug been working well for you?
« on: March 08, 2022, 12:28:47 pm »
Quote from: FellippeHeitor on March 08, 2022, 12:23:12 pm
Sounds cool (and very doable!) indeed. Thank you, Rho!

Great, and best would be, if the variables would remember its current display choice between the debug sessions, at least as long as they're not removed from the watch list or the IDE is closed at all.

11
QB64 Discussion / Re: Has $Debug been working well for you?
« on: March 08, 2022, 12:21:54 pm »
Hi @FellippeHeitor,

$DEBUG has been very valuable to me lately when revising the falcon tool set to allow printing on non-32-bit alpha blended screens. It works like charm. However, there was especially one feature I've missed in the variabels watch list. It would be great, if we had a chance here to change the display of numeric variables to either DEC/OCT/HEX/BIN instead just default it to decimal. Had been made checking the 32bit color values much easier to have them as HEX rather than DEC. As I already added the new _BIN$ function to the 2.1 development branch, this is maybe a neat feature to add in the future.

12
QB64 Discussion / Re: &H calculation logic??
« on: March 06, 2022, 12:15:15 pm »
Quote from: SMcNeill on March 06, 2022, 11:36:28 am
We instantly say that 4 hex is an integer, but 5 to 8 hex is a long, and more than 8 hex is an integer64. 

Without any sort of suffix to the value, why wouldn't we count it as always being an integer64, since that's our greatest variable type?  If we want to make it an integer, for example, then all we have to do is assign that value to an integer.  As it is, it means that our hex values aren't going to represent what we'd think they'd actually represent for us over half of the time.

Well, guess that depends on POV, I have never questioned this behavior in 30 years, I found it that way almost everywhere, so I assumed it as standard and worked with it. However, if you ask why it is as it is, then I'd guess it's for historical reasons. We first had 8bit computer architecturs, then 16bit, 32bit and now 64bit, and the programming languages probably always tried to waste as little memory as possible, so if a value fits into a byte, then its a byte, then a word, long...., and with it interpreting the respective sign bit for the smallest possible data type.

13
QB64 Discussion / Re: &H calculation logic??
« on: March 06, 2022, 11:18:14 am »
IMHO, that's correct and correctly intended built into QB64. Since I do programming started back then on the C64 then Amiga500 and finally PCs, one thing I commonly found in almost every manual:

The highest, or speaking correctly the most significant bit (MSB) of an integer number is the so called sign bit. For bytes this is bit #7, for words (integer) #15, for longs #31 and for long longs #63. Whenever that bit is set, the number is to be interpreted as negative unless an explicit type suffix is used to designate it as unsigned.

Unfortunately many people programming todays don't studied informatics or learnd the basics of the binary number system and that causes issues to those people, when they expect a certain result and don't get it. But this is not the fault of the binary system or the sign bit as defined in applicable standards, it's JUST unsufficient knowlege about the internals.

So please don't mess up QB64 its handling of &H/&O/&B numbers, rather encourage people to learn the binary basics, before start complaining about.

And keep in mind:
If you play with bits, then always expect to get bitten....

14
QB64 Discussion / Re: converting a number to a string, formatted like with "print using"
« on: March 05, 2022, 04:49:33 pm »
Ah, so you talk about function overloading. Not possible in QB64 as is, but look on IndexFormat$, it's a function which needs to handle several different arguments/types too, it takes all the different parameters in the argument string, all added together, strings as is, numbers via STR$(). Then, inside the functions you need to parse that whole argument string to get what you need.

Another way would be a user defined type:
Code: QB64: [Select]
  1. Type aNumber
  2.     typ AS STRING * 3
  3.     n8 AS _BYTE
  4.     n16 AS INTEGER
  5.     n32 AS LONG
  6.     n64 AS _INTEGER64
  7.     ns AS SINGLE
  8.     nd AS DOUBLE
  9.     nf AS _FLOAT
  11.  
  12. DIM num AS aNumber
  13. num.typ = "n16"
  14. num.n16 = 32767
  15. res = DoSomthingWithNumber(num)
  16.  
  17. FUNCTION DoSomthingWithNumber (x AS aNumber)
  19.     CASE "n8"
  20.         'do _BYTE stuff here
  21.     CASE "n16"
  22.         'do INTEGER stuff here
  23.     CASE "n32"
  24.         'do LONG stuff here
  25.     CASE "n64"
  26.         'do _INTEGER64 stuff here
  27.     CASE "ns"
  28.         'do SINGLE stuff here
  29.     CASE "nd"
  30.         'do DOUBLE stuff here
  31.     CASE "nf"
  32.         'do _FLOAT stuff here
  35.  
  36.  
As you can see, there are multiple ways to build universal functions, but unfortunately no such easy thing like a 'variants" type. Somewhere you have to go in and do your own coding.

Guess @SMcNeill could also show you a variant doing this with _MEM variables. He made a universal QuickSort function somewhere here in the forum, using _MEM variables to determine the array type which is to be sorted in his function.

EDIT:
here's the _MEM sort, maybe you can derive something useful for your needs...
https://qb64forum.alephc.xyz/index.php?topic=1601.0

15
QB64 Discussion / Re: converting a number to a string, formatted like with "print using"
« on: March 05, 2022, 12:33:52 pm »
Anwer to question 1: yes

Code: QB64: [Select]
  1. 'number as is
  2. PRINT IndexFormat$("MyInteger% = 0{R}", STR$(32767), "~")
  3. 'number with thousands separator ,
  4. PRINT IndexFormat$("MyInteger% = 0{#####,}", STR$(32767), "~")
  5. 'number with thousands separator flipped to .
  6. PRINT IndexFormat$("MyInteger% = 0{?,:#####,}", STR$(32767), "~")
  7. 'number as grouped Hex/Oct/Bin
  8. PRINT IndexFormat$("MyInteger% = 0{?2:H8}", STR$(32767), "~")
  9. PRINT IndexFormat$("MyInteger% = 0{?4:O8}", STR$(32767), "~")
  10. PRINT IndexFormat$("MyInteger% = 0{?4:B16}", STR$(32767), "~")
  12.  
  13. 'insert FUNCTION IndexFormat$ here, get it from:
  14. 'https://qb64forum.alephc.xyz/index.php?topic=2932.msg121898#msg121898
  15. '(7z inclusive example and docs)
  16.  
  17.  

Answer to question 2: not familiar with VB6/VBA, sorry

Pages: [1] 2 3 ... 38