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.

[Vigilans]

@wangtao0101 Thanks for your contribution! I've walked through your fork, and appreciate your work of building a debug framework. Here is some of my simple advice:

First commit

• You specified how to start a debug of javascript program. But for different languages, the way to start a program may varies a lot. Do you have interest in looking into a general method to start a program?
  I've considered to rely on another extension to handle it, e.g, The Code Runner, but without further investigation into whether we could obtain proper API access.

• You reused test's quickpick to start a debug. Do you have interest in creating a webview for debugging, where testcases can be entered in a inputbox, just as what leetcode's console do?

Second commit

• Your referenced your leetcode-problem-type package. It should be noted that for different languages, the format of function name may varies, e.g, for twoSum problem, some of the langs uses TwoSum(C#), and some other uses two-sum(Rust).
• You referenced leetcode-cli's file submodule to use the meta function. It is not recommended, as currently we are paying effort on avoiding to rely on the cli.
• Personally, I suggest the solution code should be kept clean, i.e. we shouldn't modify the content of what user writes to, but use some stub code as proxy.
  Besides, to make the stub logic scalable for every problem, we can fix the code file, and generate some metadata for every problem. The metadata will be used by the stub to handle problem-specific information.
  The stub code is covered in aforementioned gist's pre- and post- solution header.
  The meta data is just as meta.h shown above. For javascript, we could simply use a json, or direcly import a .js file.

In recent days (after July 11th's university summer camp) I will also start to work on it, wish we could have a nice collaboration!

[wangtao0101]

1. The best way to debug is to use vscode debug framework, most of the languages have support it, include javascript, c, c++ python, php, java, go, c# ..... Actually, I think all languages will support vscode.
2. Webview is a good idea for entering testcase,
3. I had noticed the difference between languages, and it is easy to handle by some transform functions
4. I will rewirte it using regexp
5. Stub code with Do not disturb label is also my proposal.

******before Do Not Disturb *****
code
***********  end ***********************

user code

******after Do Not Disturb *****
code
************ end **********************

[wangtao0101]

@Vigilans @jdneo I have finished the debug framework with javascript supported in my repo.

You can review it and make some comments. I will make a PR if the debug framework is work.

Four key points:
1. Using vscode debug framework which support all popular languages and the debug framework is designed to work with all languages including static language. Next step, i will add python then c and c++.
2. Judgement is difficult for our debug framework, so i reuse the test command.
3. When test or submit a stubbed file, i stripped the file and save it to the vscode cache path, then test or submit it.
4. A webview to trigger test, submit , debug like website of leetcode is very useful, but we can realize the feature in another story later.

[xavier-cai]

I have implemented a local debugging framework with c++ supported (repo). I have no experience in open-source projects, so I wonder if you could review it and give me some advice for improvement.

About the debugging framework:

• A debug button (like submit and test) is added for the user to start a debug session.
• The debug configuration is read from launch.json so that user could launch their custom debug session.

About c++ debugger implementation:

• The definition header file will be added to the user's code before starting debugging and be removed after the debug session terminated.
• The debug session starts from a temporary file with the main function is generated from the problem's template code.
• User can modify input and output like this:

#define INPUT_FILE "testcase.txt" // otherwise, input from std::cin
#define OUTPUT_FILE "output.txt"
#define OUTPUT_STD_COUT

Also, I have some problems with future work:

• Currently, the common problem and design problem is supported in c++ debugger, the interactive problem is not supported, I wish the debugging feature could apply to any new problem (not unknown problem type) like what leetcode did, so maybe the interactive function should be written by user, but I can not figure out how to implement this.
• The code used to generate debugging code seems messy because of a lot of constant text, how to organize the code to make it clean?
• Like what Vigilans said, metadata are different for different languages, for dynamically typed languages like Python, it's difficult to automatically get metadata and generate debugging code.

[jdneo]

@XavierCai1996

Maybe you can publish an extension for debugging leetcode c++ problems I guess? Since the LeetCode supports a lot of different languages. Having a general debug support is not an easy task.

[xavier-cai]

@XavierCai1996

Maybe you can publish an extension for debugging leetcode c++ problems I guess? Since the LeetCode supports a lot of different languages. Having a general debug support is not an easy task.

It looks good to me.

[wangtao0101]

@jdneo I have pull a request #525 for the local debug framework i said before, sorry for the late request.

[wangtao0101]

@jdneo any response ?

[jdneo]

Hi all,

Thank you for all of you participating the discussion here. There are a lot of brilliant ideas here.

While unfortunately, so far supporting debugging is not in the roadmap, for the following reasons:

• Almost impossible to provide a general debug framework for all languages
• Too much uncertainties, any of the dependent language extension changes its API, we breaks.

So I suggest if anyone has the interest to support debugging, he can just write his own extension and publish it to enable this scenario.

Besides, by focusing on a specific language, the problem could be much easier! As the above discussion, we already have some guys having great idea for debugging a certain language!

If anyone has problem to make his own extension, just feel free to let me know!

[wangtao0101]

Insert an AD: Debug LeetCode

Currently the extension support js and python, and in few weeks i will support c and c++, next java....

插一个广告: Debug LeetCode
目前支持js和python，几周内会支持c and c++，然后java。。。

别打我。。。。

[jdneo]

Well, actually my intention is, everyone can publish a separate extension which is purely for debugging purpose. And the debugger can communicate with this extension through negotiated APIs (if needed).

This solution will benefit users from:

• avoid conflicts
• all the bugs can be solved in just one place

And it also provides more flexibility and extensibility.

Anyway, since the project is licensed with MIT, so basically you can do whatever you hope to.

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