ProcessClientCommand shoudn't be a part of Debugger class but DebuggerServer

[YindSoft]

Hi.

I'm making an editor for my own script and I want to integrate the debugger with it without using TCP but direct interaction with the Debugger class. I was following the code to do so and I found that part of the parsing for the debuggerserver is within the Debugger class, that isn't as neat as it should be. I suggest that the the parsing of that is within the DebuggerServer or client, and the Debugger class has all the functions to do the operations without any parsing as I want to use it.

Also it seems that it can only Debug existing files and not in memory code, that is quite annoying as I would have to save the file each time I'm debuging and I could easily pass the block of code to debug without having to specify any file.

Best regards.

[vassilych]

Hi, thanks for the suggestion! Do you propose having both, ProcessClientCommand and ProcessClientCommands in DebuggerServer? What about ProcessRepl() then? Also, can you mention, which parts of ProcessClientCommand() do you propose to move? It would be difficult to move the whole method since it has quite a lot of stuff, but might be some parts of it... Thanks, Vassili

[YindSoft]

It should be part of the DebuggerServer as if I wish to delete the whole DebuggerServer class it could continue to work fine and I would be able to Debug any way. Now I encountered the function CreateResult which I need to get the current line and other stuff in my debugger, its output is a string (there are many parts that work that way) and should be an object. For example. DebugExecutionResult, which has the method ToString() overrided and returns the current output, but if it's an object it's better to handle in other operations as mine where I could easily use it like: result.Line, result.CharPosition, result.Variables, etc. instead of having to parse the whole string used in the TCP Debugger. As it should be as modulized as possible I think its the best way to go, there are other things I saw that are handled in string format and should be object oriented, when I see them again I will ping you with them as suggestions. Also I'm doing the debugger modification myself as I need it that way, I can post the changes later but I modified a few parts of the whole code and deleted few things I don't need like the Translation module and some functions.

[vassilych]

Yes, it would be great if you can post your modifications!

[vassilych]

Hi there. I am not sure I follow exactly your way of getting rid of ProcessClientCommand in Debugger.cs (especially that it doesn't do any TCP calls). Can you post your solution here? Thanks, Vassili

[YindSoft]

ProcessClientCommand is used to process the String command in the TCP message, so it should be in the DebuggerServer part despite it's just a simple code, as it's part of the TCP debugging. Debugger class should be isolated to be able to execute debugging without using the DebuggingServer class if wanted, so. I could write a code that executes the script in debugging mode where I can get breakpoints as callback events, step by step executing and variables access without having to parse a string response from the debugger. Instead of this string filename = GetCurrentFilename(script); int lineNumber = GetCurrentLineNumber(script);

        int outputCount = output.Split('\n').Length;
        string result = filename + "\n";
        result += lineNumber + "\n";
        result += outputCount + "\n";
        result += output + "\n";

        string vars = GetAllVariables(script);
        int varsCount = vars.Split('\n').Length;
        result += varsCount + "\n";
        result += vars + "\n";

        string stack = GetStack(script);
        result += stack + "\n";

in CreateResult,

it should create a object called DebuggingResult (for example), and that object should have a ToString method that returns that in that format. But would allow me to use the object in the Debugger reading the properties directly.