[dev build] $DEBUG mode ✨ Step through your code, watch variables! 🤩

[Richard]

@FellippeHeitor

Even works for

DIM e AS UNSIGNED BIT *1
DIM f AS BIT * 1

as expected.

Thanks for fixing $NOPREFIX not recognizing BIT (needed to be _BIT)

One should be careful  because   e   and    f   variables now do not have suffixes in the watch window.






  [ You are not allowed to view this attachment ]  







  [ You are not allowed to view this attachment ]  








  [ You are not allowed to view this attachment ]  

[Richard]

@FellippeHeitor

Bit of a problem with this code

Code: QB64: [Select]

1. $DEBUG
2. $NOPREFIX
3. i% = 0
4. c~` = c~`
5. d` = d`
6. DIM e AS UNSIGNED BIT * 1: e = e
7. DIM f AS BIT * 1: f = f
8. DIM ee AS UNSIGNED BIT * 64: ee = ee
9. DIM ff AS BIT * 64: ff = ff
10. DIM a~`(0 TO 3)
11. DIM b`(0 TO 3)
12. DIM aa(0 TO 3) AS UNSIGNED BIT * 63: aa(0) = aa(0)
13. DIM bb(0 TO 3) AS BIT * 63: bb(0) = bb(0)
14. c~` = 1
15. d` = 1
16. e = 1
17. f = 1
18.  
19. FOR i% = 0 TO 3
20.     a~`(i%) = 1
21.     b`(i%) = 1
22.     aa(i%) = 1
23.     bb(i%) = 1
24. NEXT
25.  

I am trying to watch everything (I know you will "frown" because there are too many variables to watch).

I seem to have trouble setting up watch list to contain

ee AS UNSIGNED BIT * 64: ee = ee
ff AS BIT * 64: ff = ff
aa(0 TO 3) AS UNSIGNED BIT * 63: aa(0) = aa(0)
bb(0 TO 3) AS BIT: bb(0) = bb(0)

something about UDT elements (refer screen shots)

I think I got confused trying to set up the four lines above





  [ You are not allowed to view this attachment ]  








  [ You are not allowed to view this attachment ]  









  [ You are not allowed to view this attachment ]  

[FellippeHeitor]

Does it happen without $NoPrefix?

[Richard]

@FellippeHeitor

NO problem when ticked out $NOPREFIX





  [ You are not allowed to view this attachment ]  



and no mention of UDT

[FellippeHeitor]

Ok, thanks. I'll get to investigating the issue.
🕵️‍♂️

[Richard]

@FellippeHeitor

Actually running my code

Code: QB64: [Select]

1. $DEBUG
2. '$NOPREFIX
3. i% = 0
4. c~` = c~`
5. d` = d`
6. DIM e AS _UNSIGNED _BIT * 1: e = e
7. DIM f AS _BIT * 1: f = f
8. DIM ee AS _UNSIGNED _BIT * 64: ee = ee
9. DIM ff AS _BIT * 64: ff = ff
10. DIM a~`(0 TO 3)
11. DIM b`(0 TO 3)
12. DIM aa(0 TO 3) AS _UNSIGNED _BIT * 63: aa(0) = aa(0)
13. DIM bb(0 TO 3) AS _BIT * 63: bb(0) = bb(0)
14. c~` = 1
15. d` = 1
16. e = 1
17. f = 1
18.  
19. z = z
20. ee = 1
21. ff = 1
22.  
23. FOR i% = 0 TO 3
24.     a~`(i%) = 1
25.     b`(i%) = 1
26.     aa(i%) = 1
27.     bb(i%) = 1
28. NEXT
29.  

there is an issue with      ee     variable   (see screen shots)




  [ You are not allowed to view this attachment ]  







  [ You are not allowed to view this attachment ]








   [ You are not allowed to view this attachment ]  








  [ You are not allowed to view this attachment ]  






will next try     ee     as   _UNSIGNED BIT * 63   (instead of   *64)

[SMcNeill]

Can you even do a bit * 64?  WTH is the point of DIM anything AS BIT * (more than one)??

With arrays, it makes sense for bit packing purposes, but for single variables??

My mind is boggled just at the concept of it. 

If there’s a glitch here, it’s the one where the IDE fails to scream loudly and slap the user.  (With an error, of course, as sadly there’s no _SLAPSILLY command available so the PC can pummel someone with the CD tray, or whatever.)

AS BIT * should only work with arrays, in my opinion.  If you need to reserve 64 bits to reserve a single one of them to hold a 0/1 value, you’re doing something wrong.

[mpgcan]

The following function fails on dev build QB64x64 edb4d40
Error message:  Incorrect number of arguments passed to function on line 14
Note: Worked fine on previous builds

Ref: https://www.qb64.org/forum/index.php?topic=1015.msg102131#msg102131

Code: QB64: [Select]

1. Dim x As Integer
2. Dim m As _MEM
3. m = _Mem(x)
4. Print m.OFFSET
5. Print ConvertOffset(m.OFFSET)
6.  
7.  
8. Function ConvertOffset&& (value As _Offset)
9.     $Checking:Off
10.     Dim m As _MEM 'Define a memblock
11.     m = _Mem(value) 'Point it to use value
12.     $If 64BIT Then
13.         'On 64 bit OSes, an OFFSET is 8 bytes in size.  We can put it directly into an Integer64
14.     _MEMGET m, m.OFFSET, ConvertOffset&& 'Get the contents of the memblock and put the values there directly into ConvertOffset&&
15.  
16. $ELSE
17.     'However, on 32 bit OSes, an OFFSET is only 4 bytes.  We need to put it into a LONG variable first
18.     _MEMGET m, m.OFFSET, temp& 'Like this
19.     ConvertOffset&& = temp& 'And then assign that long value to ConvertOffset&&
20. $END IF
21. _MEMFREE m 'Free the memblock
22. $CHECKING:ON
23. END FUNCTION
24.  

[FellippeHeitor]

@mpgcan please refer to https://www.qb64.org/forum/index.php?topic=4209.msg135786#msg135786 for information regarding important new changes to the latest build.

Steve’s library will require adapting to the new compiler fixes, as it relied on a buggy behavior.

[SMcNeill]

Code: QB64: [Select]

1.  FUNCTION ConvertOffset&& (value AS _OFFSET)
2.     $CHECKING:OFF
3.     DIM m AS _MEM 'Define a memblock
4.     m = _MEM(value) 'Point it to use value
5.     $IF 64BIT THEN
6.         'On 64 bit OSes, an OFFSET is 8 bytes in size.  We can put it directly into an Integer64
7.     _MEMGET m, m.OFFSET, temp&&
8.     ConvertOffset&& = temp&&
9.  
10. $ELSE
11.     'However, on 32 bit OSes, an OFFSET is only 4 bytes.  We need to put it into a LONG variable first
12.     _MEMGET m, m.OFFSET, temp& 'Like this
13.     ConvertOffset&& = temp& 'And then assign that long value to ConvertOffset&&
14. $END IF
15. _MEMFREE m 'Free the memblock
16. $CHECKING:ON
17. END FUNCTION
18.  

The above should fix the recursive function issue.  Looks like I’ll have to go back and check a lot of stuff for these small discrepancies soon.

[Richard]

@FellippeHeitor

Feature Request - "At ALL times, in $DEBUG mode, "somewhere" in the IDE it is always visible the current build, OS etc - that way I do not have to keep typing this in my replies (whenever I supply a screenshot).

Feature Request - "EVERY TIME a DIM variable is referenced for the "Watch List" - always the suffix is displayed (to be consistent in Watch List window with the typical variables eg x%=... x&&=..."

Feature Request - "When DIM s AS STRING * n referenced for the "Watch List" - it is important that the *n value is displayed as part of a suffix for the s variable"

I claim that _FLOAT does not work - refer screenshot for the Z(2) value.






I thought that I used to be able to say something like



DIM t() as integer


but the IDE changes it to


DIM t as INTEGER





  [ You are not allowed to view this attachment ]  

[Richard]

@FellippeHeitor

Re _FLOAT z(2)


Sorry - I should have inspected the index "1" instead of "2" to watch the value of z(2).

Note - just downloaded a newer dev build

All mentions as per previous reply still applicable with this dev build.




  [ You are not allowed to view this attachment ]  

[Richard]

@FellippeHeitor

dev 5118185  Win 10 x64 Pro 21H1 (AUG update)

It appears that the assignment of a numeric value to a variable (SINGLE DOUBLE FLOAT) is broken for very large ranges (but still well within the scope of the variable in question).  Referring to the screenshot and  program attached for same...

The program simply ranges through powers of 10 and increments by 1 to the variables of type SINGLE, DOUBLE and FLOAT. The powers of 10 are explicitly coded in (e.g. c## = 1000000000) and the other variables are assigned with the values given to the first variable.

As a cross-check the process is repeated for C##, C# and C! initial assignment. in any case the range of the powers of 10 is well within the scope of the SINGLE type.

The problem is NOT ABOUT the resolution of the storage of the values when incremented by one -as the resolution is determined by the number of bits, mantissa. exponent etc. The program is self-explanatory.



  [ You are not allowed to view this attachment ]  

[FellippeHeitor]

If you're using PRINT, then we already have another thread reporting the issue.

If it has nothing specifically to do with $DEBUG mode, please start a new thread.

[FellippeHeitor]

✨
Latest dev build has a fix for dealing with _BIT and _FLOAT variables in $Debug mode.

@Richard, thanks for reporting the issues.

@All: you'll notice the dev build now boasts v2.0 ⚡️❤️