Big messages over thespian

[migranram]

Hi! Thanks for your work. I have been enjoying a lot the editor and I would like to contribute somehow. I have seen the issue #458 and have been having a look at possibilities to get the git blame of a file and then display the information.

Displaying and interacting with git is really easy, but I am having some trouble with the communication with thespian. I have tested to send the git blame of a file and just one line, and everything seems to work fine, but if I try to send the whole git blame of the file, I received multiple messages.

Here part of the code I am adding to the git module to enable the blame feature:

pub fn blame(context_: usize, file_path: []const u8, line_number: usize) !void {
    const tag = @src().fn_name;
    var arg: std.Io.Writer.Allocating = .init(allocator);
    var linearg: std.Io.Writer.Allocating = .init(allocator);
    defer arg.deinit();
    try linearg.writer.print("-L{d},+1", .{line_number});
    try arg.writer.print("{s}", .{file_path});
    try git(context_, .{
        "blame",
        "--show-number",
        "--porcelain",
        // linearg.written(),
        arg.written(),
    }, struct {
        fn result(context: usize, parent: tp.pid_ref, output: []const u8) void {
            parent.send(.{ module_name, context, tag, output }) catch {};
        }
    }.result, exit_null(tag));
}

I have looked into thespian and it seems like it splits big messages. But this "multi-part" message decoding does not seem to be yet fully supported in the editor, for example in the project_manager.zig.

Am I missing something here? Navigating such big codebases is sometimes a bit tricky and I might be overseeing some trivial aspect.

Thanks in advance!

[neurocyte]

Yes, reading a large amount of from git will cause the OS the return the results in multiple chunks.

We don't reassemble the output until it is actually used or parsed. What the git.zig module will do here is just forward the output via the parent.send call in the result handler. parent in this case is probably the project_manger and it forwards the messages to whatever actor made the original call, usually the main TUI which runs in it's own actor.

This results in a stream of .{ module_name, context, tag, output } messages until the git child process terminates. When that happens the exit handler (in this case exit_null(tag)) will send a final message to parent. This message has the form .{ module_name, context, tag, null }. In other words, the stream is terminated by a null instead of output in the final message.

You can see examples of this pattern by searching for code matching messages on tp.null_.