The debugger doesn't work very well in SDK 8.1.1, VSCode 1.99.3 Mac, Monkey C extension 1.1.2.
I almost never see the local variables. Does it also happen to you?
The debugger doesn't work very well in SDK 8.1.1, VSCode 1.99.3 Mac, Monkey C extension 1.1.2.
I almost never see the local variables. Does it also happen to you?
For the most part, it works fine for me, but I’ve occasionally noticed that some variables are missing. One particularly annoying issue is that the "Locals" tree under "Variables" collapses every time I step through the code.
Another issue I’ve seen fairly consistently is that the last element of arrays often appears to be missing.
But in general the development environment got quite unstable with SDK 8. Sometimes the compiler runs wild and reports a bunch of error, next run everyhing is fine again. The errors shown on-the-fly in the code sometimes stay, even when the issue is fixed, and it is necessary to restart VS Code to get rid of them. The simulator sometimes does not start or crashes when switching between glance and widget.There are notification boxes showing errors that can be traced to some NullPointerException in monkeybrains.
Yes, the collapse is indeed annoying! I only use VSCode with Monkey C, so I don't know if this is a bug in the Monkey C extension (I guess it is) or if it's a bug in VSCode.
And yes, the whole thing got worse with SDK 8.x compared to 7.x :( sometimes I feel like I am using vi...
And yes, the whole thing got worse with SDK 8.x compared to 7.x
To expand on the issues with 8.x: the compiler sometimes crashes with a critical error, but running it again usually works without any changes; the simulator occasionally reports a false settings redefinition and deletes all properties; and at times, the F5 (Run) command in VS Code stops working entirely, requiring a restart of VS Code to restore functionality.
the F5 (Run) command in VS Code stops working entirely, requiring a restart of VS Code to restore functionality.
Personally I've found that when F5 doesn't work, pressing F5 a second time usually works. The funny thing is at this point, it seems that the initial press of F5 is retroactively applied, because I get a dialog saying that the app is already running and asking me if I want to terminate the current instance and run the app again. In this case, I have to answer no, otherwise it really will terminate the currently running instance and run the app again.
I haven't recently had a case where F5 stops working completely, although I don't doubt that's what's happening to you.
I haven't recently had a case where F5 stops working completely, although I don't doubt that's what's happening to you.
When I exit VS Code - after the F5 (Run) functionality has stopped working - a small, unstyled window briefly appears. It mentions something about launcher.json, but it disappears too quickly to read. I’ll try to capture a screenshot the next time it happens. I haven’t really paid much attention to these temporary issues with the compiler and VS Code.
Does the window say something about being unable to run GetTargetDevice?
I saw that a few times recently when trying to run someone else's Monkey C project that has launch.json (I typically don't use that file for Monkey C).
ime:
- When launch.json does not exist and you run a Monkey C project, you are asked once (per VS Code "session") for the device to build/run, but afterwards, the run command just remembers the last device that was built. If you want to switch devices, you have to build the project manually
- When launch.json does exist and you run a Monkey C project, you are asked to select a device every time
Could it be that you have a launch.json file, you're not being prompted to select a device (due to some bug), and that's why the run command is failing?
Some could argue it's a bug in the VSCode Monkey C extension that it doesn't ask for a device unless we have a launch.json.
It asks once, then it remembers your previous choice until the next time you close and reopen the project. I personally like having this as an option, although I recognize others may dislike this behaviour.
I actually see it the other way around: I think it's a (borderline) bug (perhaps closer to an inconvenience) that having a launch.json file forces the extension to ask you for the device on each run. (I absolutely realize it's probably a consequence of the way the extension works with launch.json, but I'm sure Garmin could have done it the other way, if they really wanted to.)
To make both camps happy, I think this behaviour should just be an option in the extension which applies equally whether you have launch.json or not. Or perhaps launch.json could gain a new command like "GetTargetDeviceOnce" or something (yeah, it needs a better name).
Yeah, I also see both ways, though personally I prefer to have the option to change in every run, the best would be to have a checkbox at the top of the list: "Remember", and for sure it should behave similarly no matter if there's a launch.json. I'd not display the question if there's only 1 device in the manifest.