When working with CP (especially on macOS), it’s likely one will get Corrupt .mpy file messages. It would be immensely helpful if these messages also indicated which file it was talking about.
I took a quick look at the code, and in py/persistentcode.c:
STATIC void raise_corrupt_mpy(void) {
mp_raise_RuntimeError(translate("Corrupt .mpy file"));
}There’s also:
mp_raw_code_t *mp_raw_code_load_file(const char *filename) {
mp_reader_t reader;
mp_reader_new_file(&reader, filename);
return mp_raw_code_load(&reader);
}One way to implement this would be to save filename in a static file-global variable, and then reference it when constructing the error strings (see the handful of translate calls throughout the file). That will take up a pointer’s worth of RAM, though, so it might be better to pass the filename around through all the calls, which is more tedious, but not terrible.
I don’t know what other concerns there might be, and I don’t have time at the moment to get set up to build CP (I really gotta get this other thing done), but I believe in a general philosophy of error messages actually being helpful. I figure this hint should make it trivial for someone steeped in the code to implement, or perhaps indicate why it’s a bad idea.
Thanks.
When working with CP (especially on macOS), it’s likely one will get
Corrupt .mpy filemessages. It would be immensely helpful if these messages also indicated which file it was talking about.I took a quick look at the code, and in
py/persistentcode.c:There’s also:
One way to implement this would be to save
filenamein a static file-global variable, and then reference it when constructing the error strings (see the handful oftranslatecalls throughout the file). That will take up a pointer’s worth of RAM, though, so it might be better to pass the filename around through all the calls, which is more tedious, but not terrible.I don’t know what other concerns there might be, and I don’t have time at the moment to get set up to build CP (I really gotta get this other thing done), but I believe in a general philosophy of error messages actually being helpful. I figure this hint should make it trivial for someone steeped in the code to implement, or perhaps indicate why it’s a bad idea.
Thanks.