-
Notifications
You must be signed in to change notification settings - Fork 14
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
Step back not synced with the GUI #190
Comments
Thanks for this bug report. Though it's unlikely it'll get fixed: we more or less stopped development on the (external) openMSX debugger. In the latest openMSX developer snapshot we have integrated a debugger directly in openMSX itself. New development is (mostly) only done in that debugger. Part of the motivation for this change is exactly bugs like this one. The old debugger was indeed hard to always keep in sync with the openMSX state. The new debugger is always in sync because the state is not duplicated between two applications. Also the communication with the debugger is much faster now: all debugger views are always real-time updated. So again, thanks for your bug report, but please try the new debugger in the latest openMSX snapshot. |
Thank you for your response. Having an integrated UI for the debugger makes sense absolutely. Anyway, I just hope the emulator will still be accessible remotely. Having extermnal control capabilities is a basic feature for me (I usually integrate the virtual MSX into my tool chain and other scripts). |
Yes, that's not changed. We're hoping for your feedback! Do you know where to get the latest development build? See also https://www.msx.org/forum/msx-talk/openmsx/please-help-testing-upcoming-openmsx-release?page=69 |
Hi, thank you for the hint. Also, having everything as floating windows without an "always-on-top" feature is terrible. Also I would prefer having all of them as dockable windows so I can move them all together to a different monitor. As I said before, I understand this is a WIP development and I should wait for its final form. I'm pretty sure you will do an excellent job. But, currently, I don't like it. |
Hi Colpocorto, You wrote: "...I understand this is a WIP development and I should wait for its final form ...". But without feedback like this, things won't get fixed. So thanks a lot for this feedback! Now more specifically about the two items you reported:
Please try and let us know if these solutions/workarounds work acceptable for you. Any other feedback is also very welcome. Thanks. Wouter BTW: maybe this thread in the openMSX-debugger project is not the best place to discuss openMSX issues itself ;-) |
Ok, I will create a new issue on the main OpenMSX repository to address these features. To be back on topic, I have checked that one of the issues I reported at the beginning of this thread (the extreme slowness when stepping back with F12) has been solved using the old debugger UI with this new OpenMSX build. That suggests that the issue wasn't on the UI side after all ;-) |
Environment:
-OpenMSX 19.1
-Windows 10
-Debugger version 0.10.0-541-geb4d120
Steps to reproduce this issue:
-Open an OpenMSX session and the Debugger
-Break the execution (with console command debug break, the GUI button or adding a break point).
-Step back with console command step_back.
The GUI does not seem to be aware of the step back and remains unchanged.
Furthermore, using F12 to step back on the GUI is sometimes extremely slow (about 2 seconds each step back) and that's why I started using the step_back command.
The text was updated successfully, but these errors were encountered: