-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
RFC: Let debug output go to stderr #274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Does fprintf work on the devices? If not, you might need to only map the fprintf when running under unix. |
Perhaps this is something that should go into mpconfigport.h? |
Well, does debugging (I mean, debugging) work on devices? ;-). Otherwise, you guys can define fprintf to printf. |
Apparently, it is possible to setup gdb to run on the device (I personally haven't used it). Maybe call it DEBUG_PRINTF? |
Yes, someone needs to come up with RFC how to handle it, get feedback, implement, pass thru review. On a trivia note, this issue plagues some other no-nonsense projects, for example, Contiki, last time I checked it: contiki-os/contiki#216 (comment) . So, we're in good company ;-) |
Sure, what I meant that it's much less comfortable than doing "make; ./micropython test.py" no matter what. |
Right. But its also much more difficult to debug the device-specific drivers under unix. I mean I tend to write my skeleton and get the python aspects working under unix before trying on the stm, but I still use the debug output on the stm sometimes (regardless of the fact that its more difficult to do than under unix) |
I don't use the debug output on STM, so have no problem changing it to fprintf. The reason there are multiple of these per file (and not a project-wide DEBUG define), is because I sometimes only want to enable certain debug output. I am agnostic to how debugging output should be done. |
Well, it turns out a bit of chore to do this cleanly for STM, because of all those fprintf -> fputs optimizations. My initial idea was to do this on preprocessor level, but that brings question of Plan9 include taboos and leads to issues with system includes. On the other hand, being able to run testsuite while still be able to see debug output anytime is huge debug helper, so I guess I'll follow workarounds which were already done for printf(). |
Actually, why? Let DEBUG_printf() be function proper. |
Ok, please see if you can take or add anything to 44739e2 |
* atmel-samd: Add time back using the SysTick counter in the core. Fixes micropython#261 * Switch to SysTick_Config
The HID descriptor reported by circuitpython erroneously limited the maximum keycode to 101, which prevented circuitpython from sending a number of otherwise valid keycodes. Closes micropython#274
The HID descriptor reported by circuitpython erroneously limited the maximum keycode to 101, which prevented circuitpython from sending a number of otherwise valid keycodes. Closes micropython#274
The HID descriptor reported by circuitpython erroneously limited the maximum keycode to 101, which prevented circuitpython from sending a number of otherwise valid keycodes. Closes micropython#274
The HID descriptor reported by circuitpython erroneously limited the maximum keycode to 101, which prevented circuitpython from sending a number of otherwise valid keycodes. Closes micropython#274
We currently have stuff like below in number if files:
That's bad on its own, because required patching deep source to perform product configuration, but let's concentrate on that "printf()" for now - with debugging enabled, it's no longer possible to run testsuite for example. Let's define it to fprintf(stderr, ...), then at least we can run testsuite with 2>/dev/null .
The text was updated successfully, but these errors were encountered: