Local debugger implementation discussion

What we’ve got

• LeetCode problem’s templateMeta property from GraphQL API:

    "templateMeta": {
        "name": "addTwoNumbers",
        "params": [
            {
                "name": "l1",
                "type": "ListNode",
                "dealloc": false
            },
            {
                "name": "l2",
                "type": "ListNode",
                "dealloc": false
            }
        ],
        "return": {
            "type": "ListNode",
            "dealloc": true
        }
    }

• Pre- and Post- Solution code template in cpp. I’ve written a bunch of robust code in this gist. To successfully build a solution, we should provide:
  1. solution code file solution.h.
  2. metadata of the problem meta.h:

#ifndef __CLASS
#define __CLASS(name, ...)
#endif

#ifndef __METHOD
#define __METHOD(name, ...)
#endif

__CLASS(Solution);

__METHOD(inorderTraversal, vector<int>, TreeNode*);

#undef __CLASS
#undef __METHOD

#define __TREE_NODE

//#define __SYSTEM_DESIGN

The meta code could be generated by templateMeta from the extension side.

• vscode-cpptool-api package:

This is not the cpptool extension, but its api package, from which we can provide custom configuration of our currently writing code.

e.g., we can force-include pre-solution.h in the solution.h to provide proper intellisense.

What we may need

• A proper folder structure of leetcode problem files.

I suggest we keep everything about leetcode extension in ~/.leetcode, or somewhere specified by user in settings, rather than an arbitrary workspace. All the files inside the root should be managed by extension, and user intervention should be reduced as little as possible.

• How to organize the dependency with each other language tools? Users only need a small set of languages to write leetcode solutions.

• How to trigger the debugger through a WebView, and feed the testcase data from a WebView textbox?

• …

[wangtao0101]

I am working on a local debugger proposal. I have finished a demo for javascript language for the problem 1.

For the local debugger, we have something to do:

1. get problem meta data

I have finished it by leetcode-problem-types for free available problems.

2. start debug

Using vscode.debug.startDebugging to start debug session

3. handle input and output

As we know the types of all parameters according to problem meta data, so we can write all
transform functions for every kind of parameters. (string, number, ListNode, TreeNode, TreeNode[]…)

4. missing definition

We should add missing definitions for some languages to the problem file when debug, and delete them when submit. For example: javascript needs ‘module.exports’ and C need struct of TreeNode.

5. judge result

The same as step 3 for most problems but some specials which have no output. We should write judge function for thest problems if we support them.

Hoping get some advice for the proposal, i will finish the first version of javascript in few weeks.

[wangtao0101]

@jdneo I have come up with an idea about how to strip the debug feature from vscode-leetcode. After i finish cpp debuger soon, i will do this. I agree with that the way will benefit both users and the two extensions.