Debugging is too difficult.

[kcolford]

Currently, the only way to do debugging in seashell is to use printf lines, yet since macros aren't allowed in cs136 a person has to manually comment out and uncomment those lines or set up some other unwieldly method that keeps the code conformant to what's allowed.

I propose that we integrate a minimal debugger, say we have a popup that gives a dialog to GDB that the user interacts with as if it were a console and we just hook up GDB's stdin and stdout to pass information over the websocket.

There are only two issues I can find with this:

1. GDB is a big tool that has a lot of obscure (but often necessary for certain circomstances like remote debugging) features that a student could get lost in. We would have to configure GDB so as to disable most of these features.
2. Switching between editing and debugging may be messy if we use a separate dialog for GDB, yet incorperating it into the console would require us to set up cleanup code around switching between projects, files, etc.

The other option is to provide a logging API, say one that can automatically including into your own source file, that would only trigger output while running in seashell and wouldn't in marmoset (say by a macro defined on the compiler command line).

Does anyone have any comments on this?

[Gibstick]

As a side note, the option of using a global flag to enable/disable debug output doesn't seem any more unwieldy than using #ifdef DEBUG macros. Performance doesn't really matter for what we're doing either.

If the goal of Seashell is to become a legitimate online IDE for general use, then this should indeed be on the roadmap. However it seems out of the scope of this current project, for reasons different than the ones you listed.

There are a significant number of students in CS 136 who have never programmed before apart from their CS courses at Waterloo. Introducing a debugger into the course would be extra work(*) for everyone for very little marginal benefit, and we have to understand that the curriculum is fairly loaded already. I think it's unfair to make the ISAs and course staff have to support this. CS 246 covers debugging and debuggers, I think. For the complexity of the programs we're doing I believe it's not necessary to have a full debugger available.

Another reason is that we won't have debuggers on exams, and if we did have debuggers that were easy to use, no one would practice tracing through code in their head (and damn is it hard sometimes!). This isn't a practical reason, only a pedagogical one.

A logging API would be a good idea. It might be easier too. Just provide some void functions as wrappers to printf, and redefine them to do nothing for Marmoset. We could even style the debug output differently in console. Having an additional #include won't kill anyone either.

(*) "How much do ISAs get paid?" > "Not enough."

[kcolford]

So in that case, I guess we should introduce a header file, say "seashell-debug.h", that's accessible from every compilation unit. In it, we'll define static functions with short names (i.e. "sd") that mimic printf. We can even provide ones that can control their log level and thus give the user more control over their program. Then, inside the header there will be an #if SEASHELL_DEBUG check that will decide whether or not to make functions actually give any output.

[kpalway]

This has been suggested before, and we've decided not to implement a debugger in Seashell mainly for the reasons Charlie mentioned. We want to keep Seashell's features as simple as possible; if it's not part of the CS136 course content, we generally don't want it cluttering up the interface.

Since debugging with GDB is covered in CS246, and we teach other basic debugging techniques in 136, there isn't much value in adding this feature.

[e45lee]

For what it is worth, fprintf(stderr, ...) should work in your use case.