Port of FS28 - #debug message not displayed.

[wfpokorny]

http://bugs.povray.org/task/28

---

Details:

The #debug message stream is only being flushed when it hits a newline character,
instead of after each #debug statement. This means that some final strings don't show up.

#debug "This line prints,\n but this line doesn't."

---

Coments:

---

Comment by Christoph Lipka (clipka) - Wednesday, 20 May 2009, 19:32 GMT+5

Field changed: Status (Unconfirmed -> Assigned)

This is a known issue; I think a convention of flushing the #debug stream at the end of each #debug statement is a reasonable idea.

---

Comment by Nicolas Calimet (calimet) - Wednesday, 27 May 2009, 13:25 GMT+5

No: doing so would defeat the purpose of having buffered debug output in the first place. Instead, a single, forced flush right before the render starts should be enough.

---

Comment by Tim Attwood (TimA) - Thursday, 28 May 2009, 02:31 GMT+5

In 3.6 some macros produced a progress bar by printing dashes.
If you only flush the buffer before render then those progress bars will be broken.
If you are worried about buffers because of file redirection, then it makes sense performance wise to actually redirect output to a file buffer, then only flush the file buffer when it's full, and at end of the render.
For the message window display it makes sense to flush after each #debug command.

---

Comment by Thorsten Fröhlich (thorsten) - Wednesday, 24 March 2010, 20:06 GMT+5

In 3.6 some macros produced a progress bar by printing dashes.

This did not work in 3.6 either, the buffering was included there already. One intelligent way to restore a meaningful progress output would be to implement a smart handling of "\r" (backslash-r) that would be detected by the debug message printing code and convert them into progress messages handled similar to the parser token progress messages. This could be implemented i.e. by appending any #debug stream message that ends with a backslash-r to the parser progress message display. Regular text stream output would remain as is, meaning only the last "progress debug" message before the next new backslash-n would be printed. This would reduce output of debug message junk to log files (if used), yet it would also permit meaningful progress reporting from inside the SDL

[c-lipka]

To pick up on the old discussion, let's examine the situation more closely:

The current implementation seems to be primarily geared towards situations where multiple #debug statements are used to compose a single line. In this scenario, the implementation has the following benefits:

1. It reduces the workload of the components involved in displaying messages.
2. It prevents warnings from breaking apart individual debug output lines (*).
3. It makes sure warnings and error messages start at a new line (*).

(* presuming the line doesn't exceed the buffer size)

In the same scenario, it also has the following disadvantages:

4. Error messages cause part of the debug output to be swallowed.

It also has the following disadvantages in other scenarios:

5. When forgetting to add a newline, debug output is swallowed at the start of the render.
6. Any progress indication based on #debug necessarily needs to be very talktive.

I consider 2. to be the single most important benefit, with 4. and 6. being the biggest drawbacks.

Drawbacks 4. and 5. could be mitigated by demanding that whenever an error message is issued or the render is started, if the debug output buffer isn't empty a newline shall be injected to not only force the buffer to be flushed but also to ensure that subsequent output starts at a new line.

This leaves us with Drawback 6:

A \r-based approach as proposed by Thorsten might be a viable alternative for many cases, but probably still wouldn't be a catch-all.

However, progress output has one key property: It is only relevant if a notable timespan elapses. So an easy solution would be to force a flush of the debug output buffer at more or less regular intervals even if no newline was issued - for example, the #debug code might check how much time has elapsed since the last flush, and if it exceeds, say, 0.1 seconds force another flush.

(This will extend the asterisk restriction to properties 2. and 3. to not only include overly long debug lines, but also lines that take a certain time to assemble. We can probably live with that for 2., but we probably want to eliminate this restriction from property 3. Then again, maybe we can delegate this job to the message sink.)

[c-lipka]

For the records: Since this is long-standing behavior, I don't think there's much need to do anything about this in v3.8.0.