Microsoft MakeCode

Pinpointing errors on the device like a 980?

The error reporting on the Arcade devices is very limited at the moment. I was just surprised to see a 980 error on some code compiled with 0.14.9/5.21.14. I can look this up on and it tells me it’s a 980 (PANIC_CAST_FROM_UNDEFINED): attempted cast from an undefined value to another type. I’ve not seen that before and it wasn’t obvious from the position in the game what code was executing.

Has there been any thought into providing more detailed feedback on runtime errors? A button press to reveal more information like a stack trace with line numbers would be useful. Is there an equivalent of line numbers in block mode? Is there value in a feature which allows a jump to a block based on a line number without having to transition into JavaScript mode?

This is something we’re looking into. We want to improve it for the web experience as well, but it’s much harder to do on the hardware side. Hopefully we can get the web experience to a point where most hardware issues can be reproduced in the simulator.

Thanks. Anything that can be done on the hardware would be great. As an analogy in CircuitPython world the mpy files have line numbers left in so it can report where errors occur. If you can stick an error code on screen then you can report at least a line number. Then it just requires, ideally, a way to map that/jump to a block in the editor.

The bug I’ve found appears to be ultra rare. I don’t think it’s necessarily going to occur in simulator without hours of play.

Our stack is very different from circuit python. Circuit python runs an interpreter, which means the source code is actually sent to the device and all the parsing and execution happens on the board itself.

We don’t transfer the source code to the device; instead we compile it into a binary. This has the advantage of making our code run faster and use less memory, but it also means that providing that debug information when something goes wrong is harder to do.

It’s common for object formats to include a feature for source code line number information. A debug option on the compiler/linker allows these to be inserted into the object file for debugging/analysis.

I suspect there’s some familiarity with this feature at Microsoft with the rich heritage of MS-DOS. The Waite Group’s MS-DOS Bible (3rd Edition) page 359 (177 for those with 2nd edition) (pdf page 382) refers to this to this feature when describing the link command and referring to the golden era of the BASIC compiler, from the third paragraph:

The /linenumber switch (entered as /l) tells LINK to include in the list file the line numbers and relative addresses ofthe source statements in each object module. Source statements are the statements in a computer program in the form that they are entered by the programmer. The Ilinenumber switch only works with object modules produced by a compiler that num­bers each source statement (such as the BASIC compiler).

There is a trade off here between object size and debug information from symbol table and line numbers but I think this can be kept fairly tight and these devices actually seem to have a decent amount of flash, even the humble STM32F401RET6 has 512kb.

Another thing to note is the complete source code is already embedded in .UF2 files generated from the Download button in editor.

I am used to loading from source code from png files but I just dragged in a .UF2 file and the code loads up fine. This also works off the CURRENT.UF2 on a PyGamer - that was something I put on there.

Thanks for the feedback! I didn’t mean to claim that this feature isn’t possible, just that it is not as simple as putting an extra number on the screen. We do transfer the source code, but it is LZMA compressed and we do not uncompress it on the device. As I mentioned earlier, we are actively looking to make improvements in this area and if you have any specific feature requests, feel free to file them at the arcade GitHub repo or make a pull request.