SmileBASIC 4 Discussion「プチコン4」

Is it the precision of the float to string? Ya get 0.1234567 etc..but the actual value has more precision i think. As soon as ya read the data the value is different... The aryop, the comparison, the sub is gonna give ya the difference... I maybe ya just getting lucky sometimes of the array having a less precise values that can survive the string conversion. Have ya tried just putting the str$() into an array$ Then putting the val() of that into array b.... probably get the same results... i cant prpve it but im guessing READ gives ya the val() of the DATA

I think I found a bug with EXEC.

ACLS

N=1000
DIM A[N],B[N]

A$="@D:DATA "
FOR I=0 TO N-1
 A[I]=FLOOR(RNDF()*1E6)/1E6
 A$=A$+","*!!I+STR$(A[I])
NEXT

PRGEDIT 1
PRGDEL -1
PRGINS A$

REPEAT
 EXEC 1
 RESTORE "1:@D"
 FOR I=0 TO N-1
  READ B[I]
 NEXT
 ARYOP 1,B,B,A
UNTIL MIN(B)||MAX(B)

FOR I=0 TO N-1
 IF B[I] THEN
  ?A[I];":";A[I]+B[I]
 ENDIF
NEXT

This generates an array with random values, writes it to slot 1, and continuously reads and compares the read data to the original. If a difference is found, it outputs the original value and the read value. This piece of code should theoretically loop forever but it tends to end very quickly. Also, putting EXEC before the loop seems to fix the problem if it doesn't end immediately.

When trying to track down an elusive bug, and especially when trying to demonstrate a language bug to others, I use this approach:

• Eliminate randomness. If the bug only happens randomly, it can become very difficult to reproduce a bug, let alone track down its source. One way to do this is to set the RNG's seed to one in which the bug occurs. Another way, if you are generating random data, is to find data which causes the bug, and then change the code to use that specific data.
• Simplify. The best way to find a bug is by process of elimination. Remove code piece-by-piece, and check to see if the bug still happens. If the bug still happens, that code isn't what's causing the bug. If the bug stops happening, that code is part of the cause and should be added back in.
• Double-check afterwards. Once the bug has been tracked down and fixed (in this case, by SmileBoom), make sure to go back and check your original code, not just your stripped-down test case. It's always possible for multiple bugs to be the cause of a problem. If there are still bugs in your original code, repeat the process.

When I look at your test case here, I can see that it's way too complicated. You've got RNDF, PRGEDIT, EXEC, RESTORE, ARYOP, floating-point operations... does your bug really involve all of these? Probably not, right? But all of those things get in the way of tracking down the actual cause of the bug. You may think the problem lies with EXEC, but with all these moving parts it's very easy to be mistaken about where a bug is coming from. Now, this would be the part where I'd try to break it down for you and show you where the bug is. But there's one little problem... I can't get it to happen. At all. Because you use RNDF in this code, I can't tell if I'm just unlucky, or if there's something going on with your system in particular, or if you've posted the wrong test code, or if it actually was a bug in an older version that SmileBoom happened to fix already, or if you and I disagree on what "very quickly" means and you're expecting me to wait 30 minutes on this, or what. This is exactly why I stressed "eliminate randomness" earlier. (I'm using 4.0.3, by the way.)

Yeah, I think the way to go for all parties involved here is to figure out what precision exactly these values are. Converting the floats to strings is a giant red flag; this bug could just end up being "the basic output of STR$ doesn't have enough precision".

Sorry, I was in a rush. Maybe this will make the bug more clear:

ACLS

PRGEDIT 1
PRGDEL -1
PRGINS "@D:DATA .1"

REPEAT
 EXEC 1
 RESTORE "1:@D"
 READ A
 INC L
UNTIL A!=.1
?L
?A

DIM D[1]
COPY D,"1:@D"
?D[0]

This piece of code outputs how many times it cycled through the loop before the bug occurred, the value it incorrectly read with RESTORE and READ, and a separate value it read after the loop using COPY. On my system, which does have 4.0.3, the loop seems to end in about two seconds with some variation.

I see it now. yup its like the read or restore is messing up.added a vsync 1 but of course that slows things down lettin it run..seeing if it still comes back with a misread... Maybe spectre attack heh jk If ya remove exec from the loop, put it above, it works... just seems hammering execs will miss..unreliable Jave you tried it with other types? I only seeing it with floats. Im wondering if some internal non-blocking functions is returning without the proper read value. I changed it to

...
PRGINS "@D:DATA 0.1":VAR B= 0.1
...
IF (A!=B) THEN INC C
?L,A,B,C
UNTIL #FALSE

it happens quite often... But not in its own slot. Cross slot only with float? Ive tried it with the data being a string of ".1" Reading that..getting the val of that string..and it does it... It will do it even in its own slot... no exec at all. Just a loop of

OPTION STRICT
OPTION DEFINT

VAR B=.1
VAR A,L,C=0
REPEAT
 RESTORE @D
 READ A
 A=VAL(A)
 INC L
 IF (A!=B) THEN INC C
 ?L,A,B,C
UNTIL #FALSE
@D:DATA ".1"

maybe its SBs version of disk read errors? Jk also try this... no read just try val

A=".1"'READ A

And of course ya can comment out restore... But awesome bug find..

Even with these, I can't reproduce the bug. I ran Nathaniel's updated program for about five minutes, but the loop didn't terminate. I ran incvoid's program for 10,000,000 loop iterations, but C was still 0 at the end. I typed both programs exactly as written, so I'm not sure what the problem is. Have you had SmileBASIC running for a long time? If you close SmileBASIC and start a new session, then load these programs and run them, without doing anything extra, does the bug still happen? If you power off your Switch entirely, then turn it back on, does the bug still happen? Could it be some sort of hardware difference? I bought my Switch at launch. Was it the same for you?

Have you had SmileBASIC running for a long time? If you close SmileBASIC and start a new session, then load these programs and run them, without doing anything extra, does the bug still happen? If you power off your Switch entirely, then turn it back on, does the bug still happen? Could it be some sort of hardware difference? I bought my Switch at launch. Was it the same for you?

I restarted my switch and the bug still occurred. I bought my switch a week or so after SmileBASIC 4 released. If there is some sort of hardware difference that's determining whether the bug is present or not, it might be difficult to impossible for Smileboom to fix it. Another thought, is your system up to date? Maybe the bug was introduced after an update..? Also, do you have a Japanese or an American switch?

American Launch im pretty sure. Grey joycons. Sd card difference maybe? I doubt itd be wearin out sd cards with like every val Free space? Rebooted, launched, loaded bug demo, now not doing it... cpnaidering i hardly reboot. Reminds of when the wifi wouldnt xonnect afyer sleeping. https://video.twimg.com/ext_tw_video/1149063788261339138/pu/vid/1280x720/-7w7Rj5Ybwh05EuZ.mp4 dunno how long the vid will stay live.

Mine's American, launch, completely up-to-date (system 8.1.0, SB 4.0.3). It's odd that I can't get it to happen at all... it must really be something subtle. When the values don't match, what do they end up being, anyway?

Now I'm really confused...

REPEAT
 A=VAL(".1")
 INC L
UNTIL A!=.1
?L,A

This also terminates on my system. I didn't even use VAL for my second program...

When the values don't match, what do they end up being, anyway?

From my testing, zero. Unless the value is negative; then it outputs "-0"... whatever that means. It seems to output zero OR the number with everything after the decimal removed. Unless the absolute value of the number is greater or equal to ten; then it could output zero or one with the sign of the number.

Honestly I have no idea why unreproduceable glitches occurnin programs. It happens everywhere, not just smileBasic.

Okay! Finally got it to happen myself with Nathaniel's latest code, after restarting my Switch. The result it gives is a float that's either 0 or the first digit of the number, no matter how large that number is. The result also keeps the sign of the original number. For instance, -8000.123 can yield either -0 or -8. My guess is that this is some sort of race condition. VAL probably has an internal loop where it shifts in each individual digit, but for some reason it's on a different thread, and doesn't always yield the right number in time. It could always be something else, though.

Oh... and this is where I actually think to check, and find out this is already a confirmed bug: From the official bug page:

◇実数文字列をVALで変換しようとすると、まれに正しい値を返さない事がある

◇When attempting to convert a real number string with VAL, in rare cases it may not return the correct value.

The "◇" here means it's planned to be fixed in the next version. I guess that means SmileBoom already knows the cause of the bug.

Oh... and this is where I actually think to check, and find out this is already a confirmed bug: From the official bug page:

◇実数文字列をVALで変換しようとすると、まれに正しい値を返さない事がある

◇When attempting to convert a real number string with VAL, in rare cases it may not return the correct value.

The "◇" here means it's planned to be fixed in the next version. I guess that means SmileBoom already knows the cause of the bug.

Cool its known. Uncool we didnt und a newbug haha. I think exec'ing a slot in a repeat helps the bug trigger. May or maynot also be rushed by the onscreen display https://video.twimg.com/ext_tw_video/1149148391336628224/pu/vid/1280x720/aWOQ2UDVYOxaOMn7.mp4 From a fresh power off/power on... not sleep, not restart.

I’m having some trouble with how the layers work. I’m trying to use GBOX to outline collision areas but it appears under sprites and background characters. I think back on the 3DS I used something like GPRIO to set the screen priority of graphics. I don’t see anything like that in the function guide.

Did you try some 3ds programs that work that way on the switch to see if they act differently? P.S. great tutorials btw

I’m having some trouble with how the layers work. I’m trying to use GBOX to outline collision areas but it appears under sprites and background characters. I think back on the 3DS I used something like GPRIO to set the screen priority of graphics. I don’t see anything like that in the function guide.

The graphics layer is now displayed with a sprite. Specifically sprite 4095, which is equal to the constant #GSPRITE. So instead of:

GPRIO Z

You should use:

SPOFS #GSPRITE,,,Z

I’m having some trouble with how the layers work. I’m trying to use GBOX to outline collision areas but it appears under sprites and background characters. I think back on the 3DS I used something like GPRIO to set the screen priority of graphics. I don’t see anything like that in the function guide.

The graphics layer is now displayed with a sprite. Specifically sprite 4095, which is equal to the constant #GSPRITE. So instead of:

GPRIO Z

You should use:

SPOFS #GSPRITE,,,Z

Thanks! I was curious to what that constant meant!