An advanced debugger for Ren'py: anyone interested?

[herenvardo]

Well, all I can say is that it sounds interesting, but with that kind of effort it might be actually easier, cleaner, and ultimately more rational in terms of performance etc., to write a VN engine in .NET from scratch.

Actually, there is a good enough reason to not write a VN engine from scratch, regardless of the platform: Ren'py is already good enough, and most probably better than I could ever manage to create; so why bother making something worse of what is already available? If Ren'py was proprietary and expensive, then maybe there could be some sense in that, but it's not the case. OTOH, what Ren'py lacks, IMO, is a well integrated development environment, and that's exactly what I'm trying to do.

Hm... It strikes me that there are several unrelated projects here:

They are quite related, actually

Porting Ren'Py to IronPython

This is perhaps a reasonable thing to do, but I don't see the point of it if you're just going to use the SDL libraries. I mean, what does the CLR bring to the equation over CPython. It's something different if you're targeting Silverlight.

I'm doing this only as a step for implementing the debugger. I had also considered porting Ren'py to Boo, but that would be even tougher
And about the CLR, the only thing it really brings in is the fact that my skills working with it are much higher than my skills working with python (have I mentioned that my experience in python is entirely limited to the FoJ project, which isn't even finished?).

Implementing a Debugger for Ren'Py

This is quite interesting, and a good debugger could really help development.

I hope it indeed can help: that's the entire purpose Even if it's not helpful for everybody, but just for a minority, I hope it will be helpful for, at least, someone.

You could, using only python, implement Advanced Watches, Code Stepping, Breakpoints / Run to Cursor.

Nope. Maybe you, or somebody else, could. But I couldn't. Even if I tried it, and managed to do it, it would most probably take more effort than porting Ren'py to IronPython. And we are speaking only about a few features: for the rest of the features of the debugger, as well as the rest of main features for the IDE beyond the debugger, the difference starts becoming an abbyss I'm not planning to jump into any time soon.

Trying to repeat the code that caused an exception through stack unwinding seems to be difficult and error-prone to me. Some statements cause side-effects, and trying to redo those would be hard.

I'm afraid there might be a bit of missunderstanding here: unwinding and flow manipulation are different things, and they would work quite differently:
Unwinding a call or exception would go back to the previous point and restore the state on that point. That's where having the code being debugged running on a separate context (ie: within IronPython) comes really handy: the entire state of the interpreter can be tracked and saved, so the debugger knows what to restore when something is unwinded (for sanity, only the state that changes on each statement would be saved for that statement: multiplying all the data in the program by the number of run statements would shortly run out of memory). Just a bit of tinkering into the part of IronPython's code that handles the "python" state would be enough to implement this.
There will be no support for directly "re-winding" an unwinded call (and for exceptions that's completelly out of the question, since it would be completelly absurd), which would be insane than I already am: instead, the execution should be resumed so the function is entered (or the exception raised) again by normal program flow. This is conceptually similar to rollback, with only the practical difference that the IronPython engine can perfectly re-run python statements (hey, that's what it was made for after all ), while Ren'py's rollback has some serious limitations when python blocks are involved (about which I learned the hard way ).
Flow manipulation is quite simple: it just moves the "current statement" pointer, allowing to re-run or skip some parts of the code. Moving the pointer doesn't affect the state at all: if it's moved backwards, the code in-between is re-run, and any changes to the state made by it will be made again (sometimes this will change the state, like in a "x += 1" statement, and sometimes it won't, like in a "x = 1" statement). When the pointer is moved forward, the code is simply skipped, exactly as if it was commented out, or wasn't there at all.

So, I'm not really sure what did you mean't with the statement quoted above. Unwinding doesn't cause, by itself, any code repetition: it just unwinds back to a previous, known, stable state. From that point, resuming execution shouldn't be an issue: the state is known and stable, and the execution continues from there.

Edit and continue is similar. I'm actually wondering if it doesn't make sense to modify the shift+R reload code so it can take a filename + line somehow, and jump there.

Whether you do that or not is up to you, although deciding which line to continue from can be a bit tricky when lines have been added or removed from the file before the current one. I'll be including this feature anyway because a debugger without it doesn't make too much sense to me, and it isn't really hard to do (just need to keep track of the relative position between the current execution point and the code being changed, so the interpreter can know from where should it resume execution when asked to do so). Keep in mind that "Edit externally, and then continue" won't be supported, and isn't really sane.

But none of this should require changing IronPython at all...

Maybe you're right (as usual ^^; ), and there isn't any need to change it. But having to do this on python code that would be run in the same context than the code being debugged doesn't seem too sane to me; and I feel much more comfortable with the changes that I'd be doing on IronPython (which is written on statically-typed, draconian-compiled, and quite familiar C#) than the changes I'd need to do on Ren'py and its dependencies otherwise (which are written on a mixture of dynamically-typed, loosely-checked python and long-time-forgotten (for me), not-OO C).

Implementing an Advance Editor

This is something Ren'Py would really benefit from.

That's not to mention the many wizards, the UI designer, the project-management, and all the other elements I plan to put on the IDE. Probably, the debugger itself is going to be the less useful part of this, when taking the entire community into the picture (although for a minority it might as well be the most useful component). But I still think I should deal with the debugger and get done with it ASAP (which doesn't really mean too soon, unfortunatelly), so I can get it out of the way when working on the other, much saner, components of the IDE (and getting good insight of IronPython will be useful on that step, since I'll need some parsing functionality for stuff like refactoring or advanced highlighting).
I don't mind too much if the topic strays a bit towards the bigger project, and this might even help putting the ideas within context; but it was originally intended to get feedback for the debugger idea, and I still hope to get some such feedback.

Just an additional idea that came up to my mind (it's for the mid-long term anyway, but it's quite interesting): since the IDE will be so Ren'py-specific, it'll be possible, and relativelly easy, to retrieve a list of "display texts" (ie: all the strings that are intended to be shown at some point of the game, but not stuff like dictionary keys), which would be useful for spell-checking or proof-reading purposes. And I might try to "import" good-LGPLed OpenOffice's spell-checking tools... the sum of both sounds quite interesting ^^ .

[Hentai Senshi]

I would really love a Ren'Py debugger. I suspect that the only things that could keep me from using one would be if it didn't run under Linux, or if the Ren'Py environment under the debugger was different enough that it would miss bugs that would crash games in the actual distributed form.

Hm. Python has a debugger module, playing around with that might be interesting...