The idea itself would be to tinker around Microsoft's IronPython (a Python implementation upon the CLR, with a surprisingly GPL-compatible license) to build a Ren'py debugger that runs on both .Net and Mono.
Ideally, the final version of this tool would include these features (mostly, what I find as missing on Ren'py's developer menu):
- Advanced watches: it can be compared to Ren'py's variable viewer, but with several aspects that make it more similar to Visual Studio's "watch" features:
- Detail view of complex objects, such as sequences and user-defined classes. Currently, the variable viewer doesn't give you any insight into custom objects, and I've found myself creating some global variables when I needed to keep track of certain object attributes a few times, which is clumsy, annoying, and error-prone .
- Variable modification, so you can "try on the fly" what value should a variable have for something to work, and edit the code once you have figured out. Currently, you'd have to edit the code and reload the script to try each value.
- Pause on change and pause on condition watches. These are quite self-explanatory, and are quite related to the breakpoint and stepping features (see below).
- Code stepping: "Step into" (into a function/method), "Step out" (from the current function/method), and "Step through" (through the current function/method call) would be in. Sometimes one needs to find out if execution is flowing through the code as expected, in order to figure out what's going wrong.
- Breakpoints and run to cursor: So if you just want to see the "results" of your (insert some 4-or-more-digits number here) lines of init code, you can simply put a breakpoint at the beginning of the start label, and then watch all the stuff you want to check. The "run to cursor" feature would be a trivial addition, which adds a "temporal" breakpoint at the current cursor position which is removed as soon as the execution pauses for any reason (if the reason wasn't hitting that temporal breakpoint, then you'll probably want to "run to cursor" again, and the temporal breakpoint just removed will be created again ).
- Exception and call unwinding: IMHO, debugging an exception with the currently available tools is, simply put, painful: you need to restart the game and reach the "criticall point" again everytime you try some change. Although saving just before that point is often helpful, you don't normally know where the crash is going to happen until... well, it happens, at least once. If it takes ten minutes to reach the criticall point from the beginning (which may be quite reasonable for big, complex projects), then the pain is guaranteed (and if you try to use "Skip mode" to save some time, it may backfire if your reflexes fail and you skip into the exception again). The case of call's is a needed feature to make good use of the exception unwinding tool: if your wrong code causes an exception deep in Ren'py's code (example: inside ui.interact()), then you'll probably want to unwind back to the line of your code that caused Ren'py to crash.
- Execution flow manipulation: if you have ever drag-and-drop'ed that green arrow in Visual Studio known as "currently executing statement", you'll know what I mean: basically, you can move the "execution point" back and forth through the code, and even "upwards" (in the call stack) when combined with the call unwinding feature.
- Edit & Continue: Last, but not least, this feature would allow a developer to pause execution (it will probably be already paused due to an exception or "pausing watch"), edit the code (although with some limitations), and continue running the modified version; without needing to start over. Once you start moving the execution point to re-run edited lines and are doing this due to an exception, you get the ability to fix many errors on the fly .
If someone is wondering why I'm thinking on doing this rather than asking PyTom to incorporate such support into Ren'py itself, or even hack the engine myself; and/or why I'm doing this on .Net/Mono instead of directly on Python, there are many reasons:
- I'd rather let PyTom focus on the general audience's needs, and care myself about my own specific needs .
- The current design of Ren'py doesn't bend too well to suporting these features: unwinding python exceptions and calls from python code itself can be extremelly hard, if possible at all. Having two separate execution engines (such as the CLR, and IronPython on top of it) provides the ideal environment to have the code running on the "bottom" one (in this case, the CLR code) tinkering with the code and state of the "top" engine (IronPython) on the fly.
- Although it should be, in theory, possible to have a python interpreter running from python code on a separate interpreter, which would match the "dual-engine model" described above, my Python skills are simply not enough to implement this on python, so I'll be doing it on the language/platform I'm currently most proficient at: C# upon .Net/Mono.
- Since nesting a [ spoiler] inside a [ list] is as ugly as putting a < div> inside a < li>, see spoiler below
First of all: I'm aware that the debugger idea can only raise interest among a small subset of people within this community. One of the goals of this thread was to get an idea of how big or small that subset would be.
The debugger itself is intended to be (the first) part of a bigger project, which I'll probably title "Ren'py Studio" and will be a fully-featured IDE for Ren'py development. The IDE would ideally include several features, most prominently a visual UI function designer, project-management functionalities, code refactoring, a highly Ren'py-specific editor, and some purpose-specific code generators (such as Character and Image wizards).
The main reason to begin with the debugger is that it will be the toughest part; so once it is ready other features will come in steadily.
Finally, I want to mention that the choice of C# upon .Net/Mono is mostly based on the facts that this is my usual working environment, and that it would allow for better features in shorter times (there are many things I simply couldn't do directly on Python).
[/EDIT]
So, the question is: if I manage to pull this forward, how much attention should I expect from this community? More specifically, how many among Ren'py users would be interested in using the finnished product; and/or willing to test the pre-release versions?
(BTW, although I still have to chose a license, the tool would be 100% free, both in terms of freedom and price .)
I'm looking forward for anything any of you wants to say about this idea .