Very recently, I learned that Duktape has full built-in support to act as a debug server.  This means it would be entirely feasible to implement a Sphere debugger right now.

Duktape's debug API and protocol are full-featured, with single-step, step-over, etc., the ability to evaluate arbitrary code in the current scope, view and modify variables, and more.  My question is, would anyone other than me be interested in this?

Sounds like a handy tool in my opinion.

If I knew how to debug properly I would certainly be interested in this.

In all honesty, I feel Sphere should have had a "developer mode" like this with either emulator-style debug functionality or Firebug-like debugging a long time ago, but due to lack of resources and knowledge until now minisphere (and TurboSphere if Flying Jester officially decides to offer it) will likely be the first Sphere implementation.

Given that there's no previous use case for Duktape to base yours off of, feel free to choose whether it behaves more like WebKit's Remote Inspector or like some other JavaScript debugger like Venkman or something.

If it can be linked to Sphere's Studio's code editor, I for one am totally for it. You can create a standalone .exe with command line operations that the Sphere Studio uses. The added bonus? Your code would be hopefully cross platform and Windows users (for now) can get a GUI for it.

I imagine it would be possible to integrate with Sphere Studio.  The way the Duktape debug API is set up is, it acts as a server with its own protocol and everything, and you just provide a communication channel between it and the debugger.  So it would be a simple matter of having the engine open a port on localhost and let the IDE connect to it to initiate debugging.  It would even be possible to debug remotely this way.

Well, I've done the requisite initial work in minisphere itself to support this.  It's essentially a thin wrapper over Duktape's own debug protocol, so it was ridiculously easy to get it set up.

How it works is, you pass the command line option --debug to the engine.  This causes the debugger to be attached just prior to calling game() (pausing JS execution), and the engine will then wait for a connection on TCP port 812.  Once a debug client connects, it can then control JS execution remotely through Duktape's (surprisingly robust!) debugging protocol.

Currently the Duktape interface doesn't provide source code, so there must be matching source available on the client side.  For an IDE like Sphere Studio, this is of course trivial, but it's something to keep in mind if anyone wants to design a command-line debugger.

What I think I'll do is, implement a proof-of-concept debugger in C# before trying to tackle the task of implementing it in Sphere Studio.  This will let me get familiarized with Duktape's debug commands and such too.

Wow, this is proving more tedious than I thought.  Not the debugger support itself, that's easy, it's just that Duktape's debugging API is set up using dumb streams for communication between the engine and the debugger, with no guarantee you have a full message available at any given time (it can do reads and writes piecemeal, write more than one message at a time, etc.).  Which means in order to interpret debug commands you have to constantly do trial parses on the data you have available to see if you can do anything with it and if not, you have to buffer the data until you can.

Complicating matters even more is that the protocol allows pipelining--more than one request can be outstanding at a time, and requests are unnumbered: responses are associated with requests by the order they are received in, necessitating maintaining state on top of the tedious message buffering.

Long story short, it's a nightmare.  Worse, there's no actual synchronous API I could use instead--all debugging has to be done through this ridiculous protocol.

Why would the Duktape team create something so unweildly? Wouldn't they have these same issues?

It seems to have been designed with TCP in mind, which has no concept of message boundaries, so Duktape itself doesn't make any such assumptions either.  That's the impression I get, anyway.

Following up on this to mention that, for minisphere 3.0, I want to make a command-line debugger.  The Sphere Studio integration served as an experiment to see if the concept of a Sphere debugger could work.  It worked very well, but since I can't get Mono to run Sphere Studio, debugging is limited to Windows.  Adding a command-line debugger like gdb will allow debugging on any platform minisphere itself runs on.

Now... what should this new debugger be called?

I suggest the unceremonious "minisphere-debug".

Anyway, this sounds excellent. I'd use it.

Nah, I don't particularly feel like typing msphere-debug on the command line every time I want to debug a game.  I ended up going with "SSJ", continuing the theme of naming minisphere GDK tools after DBZ concepts that I started with Cell.

so... my hair won't go shiny yellow when I use SSJ?

By chance, do you know about the DBZ abridged series? (using the original footage, storyline gets scrambled up. super funny)

Oh I wouldn't go near him. He's got a nasty case of the explosions.

so... my hair won't go shiny yellow when I use SSJ?

By chance, do you know about the DBZ abridged series? (using the original footage, storyline gets scrambled up. super funny)

That was part of the joke behind the name actually: You get so pissed off at your code because it keeps crashing or whatever, that you go Super Saiyan.  Then you type ssj on the command line to debug it.

My nephew introduced me to DBZ Abridged a year or two ago, it's pretty damn funny.