Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Attention massive speed up of the debugger
MortenMacFly:
--- Quote from: oBFusCATed on November 04, 2009, 03:55:45 pm ---There is an easy fix you could try (pseudo code below):
--- End quote ---
I am not sure if this would work. Can you be sure that the lines are complete? What if the first buffer contains 1.5 lines and the second buffer the second half of the second line (0.5 lines)? In that case the parser will not understand the second line of the first buffer and the first line of the second buffer. Thus one response is skipped.
To make it more clear... what I am talking about is a scenario like this:
Pseudo buffer1:
--- Code: ---gdb: whatever_message1 what_ever_param1
gdb: whatever_message2
--- End code ---
Pseudo buffer2:
--- Code: --- what_ever_param2
--- End code ---
oBFusCATed:
Hm, yes...
What about buffering if there is non terminated (\n) output?
oBFusCATed:
OK, I've tried the buffering approach and it doesn't work :( :(. It doesn't work because there messages that doesn't end with \n :( (the output from set prompt for example).
Morten: If somehow the message is split in two the ParseOutput code will break, with or without the patch! This is a problem of the used protocol. (you could prove me wrong though)
Jens: I've missed your message before: why the debug log has double '\n'?
Jenna:
The additional crlf's should not be there. I'm quite sure I did not log additional line-endings, and the logs did not contain them.
I deleted the original files, so I can not compare them, to see where this strange thing happens.
If I insert a patch in the textbox while posting the same things happens sometimes( additional line-endings), so it might be an issue of the board software, even if I do not know how this should happen with attached files (but I know that MS Outlook does something similar with mail attachements).
Nevertheless you can ignore the additional newlines.
I don't think an output line can be split in the middle, and if it can, this might happen in your code and in the original code.
But as I wrote before:
--- Quote from: jens on November 04, 2009, 04:26:51 pm ---Can we reach OnGDBOutput, OnGDBError or the OnTimer-function while we are still parsing splitted output ?
If yes we would most likely mess up the order we send the data to the drivers ParseOutput.
--- End quote ---
oBFusCATed:
--- Quote from: jens on November 04, 2009, 04:26:51 pm ---Can we reach OnGDBOutput, OnGDBError or the OnTimer-function while we are still parsing splitted output ?
If yes we would most likely mess up the order we send the data to the drivers ParseOutput.
--- End quote ---
What exactly are you talking about?
Entering OnGDBOutput while we are in ParseOutput or getting OnGDBError, OnGDBOutput, OnTimer in the middle of a result stream?
I think the first is not possible because the messages are in single thread.
And here is an example of the second situation:
--- Code: --->input line1
>input line 2
>error line 1
>input line 3
>error line 2
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version