Local debugger implementation discussion

[Vigilans]

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?

• ...

[jdneo]

So #130 Should be one of the issues we should address first, which is to solve:

A proper folder structure of leetcode problem files.

[Vigilans]

I've created a repository for storing these bootstrapper template:
https://github.com/Vigilans/leetcode-bootstrapper

Currently it is owned by me (Edit: and temporarily set private), and when the feature is becoming mature, I will move it to @leetcode-tools.

[Vigilans]

Cpp boostrapper usage:
Provide your solution in solution.h, and provide class and method name in meta.h.

• If you need ListNode or TreeNode definition, define __LIST_NODE or __TREE_NODE in meta.h.
• If you need to write a data structure class (Trie, LRU, etc.), define __SYSTEM_DESIGN and put your constructor in __CLASS macro.

[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.