Closed NealeTools closed 4 months ago
Note to self: I need to merge the logic from the parser across to the validation (specifically subStatement int logic)
Bump: example 2 and 3 still fail export in v1.11.8
Yeah, this is validation, as per my comment, I need to make time to merge the logic from the new parsing to the validator (not a simple process)
In the short-term could you just turn off the validator? The code compiles and runs fine in CSpect, so the tokenisation is OK, but export never happens due to the check, so I cannot test any export functionality etc. :-)
yep - you can disable it from the settings ("Perform custom inline NextBASIC validation" - uncheck that)
Great! My apologies for not realising what this option did! 🫣
Hi @remy : Unfortunately, unticking this option does not allow the export to complete. I can see that the red underline no longer is present, but the file does not build if there are any syntax errors. This prevents me exporting to test on HW via NextSync, which is an essential part of my workflow now because I am using some HW features that CSpect does not support - thanks!
I'll sort this. That checkbox is primarily there to disable validation across the board and allow export even when my (wrong) validation fails.
On Thu, 13 Jun 2024, 11:06 MattN, @.***> wrote:
Hi @remy https://github.com/remy : Unfortunately, unticking this option does not allow the export to complete. I can see that the red underline no longer is present, but the file does not build if there are any syntax errors. This prevents me exporting to test on HW via NextSync, which is an essential part of my workflow now because I am using some HW features that CSpect does not support - thanks! image.png (view on web) https://github.com/remy/vscode-nextbasic/assets/19664927/a783ffff-c0b0-4076-9086-3d4818be434c
— Reply to this email directly, view it on GitHub https://github.com/remy/vscode-nextbasic/issues/59#issuecomment-2165204016, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADLBBXPVQVZL2TWRARVBDZHFVLFAVCNFSM6AAAAABJG2NHZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGIYDIMBRGY . You are receiving this because you were mentioned.Message ID: @.***>
@remy Apologies for the nag, but is there any quick fix for turning off the validation on export? I feel like the new parser is 99% there! :-) The validation check is currently preventing me from exporting working code as multiple .bank sections—or indeed exporting any code for test on HW. Thanks!
I'm snagging early morning time to get these done.
Any chance you have a snippet of the code that's causing this. I'm reviewing the code and it "says" it's not validating by default, so I wonder if I'm missing something else...
IF %SPRITE AT (j,1)>127 THEN SPRITE CONTINUE %j,,%SPRITE AT (j,1)-(i*i[0]) TO %239 STEP %SGN{-i[0]} RUN
Also %CODE and ERROR$ get underlined. They pass "run in CSpect", so get encoded correctly, but the syntax checker flags them (red underline) and stops the Export script.
Actually, %CODE seems OK now, but ERROR$ is underlined and fails:
Here is the another one:
Found the code now, it says the default is false, but somehow I changed the default much deeper down to true 🤦
Okay, v1.11.1 (all the ones) disables validation during export. Sorry that took so long.
Thanks Remy! I can confirm the export now works (syntax is still underlined in red when enabled).
I'll try out bank exports next and hopefully there won't be any further headaches I unearth! :-)
v1.11.7 There are a few parsing bugs that pass OK into RunInCSpect, but are picked up as errors in Export (and cause export to fail).
Examples:
%CODE:
ERROR$:
IF %SPRITE AT (j,1)>127 THEN SPRITE CONTINUE %j,,%SPRITE AT (j,1)-(i*i[0]) TO %239 STEP %SGN{-i[0]} RUN (I think this is referring to both the "TO %239" and "%SGN{-i[0]}" parts, both of which are valid syntax and actually encode fine I think it i just the error stops the export.