Missing ass-end of rendered frames about notcurses

[dankamongmen]

I straced the intro screen draws. I also added code to dump the output to stderr, along with an expected byte count. Here's what we see:

• first render (good):
  • write(1, "\33[?1049h\33[22;0;0t\33[H\33[2J\33[39;49m"..., 1024) = 1024
  • write(1, "90;0;90m\33[48;2;0;0;180m\342\224\200\33[38;2"..., 162816) = 162816
  • many 8192-byte writes to stderr, concluding with a 303-byte write
  • claim of 164127 bytes
• second render (truncated):
  • write(1, "39;49m \33[39;49m \33[39;49m \33[39;49"..., 1024) = 1024
  • write(1, "39;49m \33[39;49m \33[38;2;90;0;90m\33"..., 162816) = 162816
  • many 8192-byte writes to stderr, conclusing with a 472-byte write
  • claim of 164296 bytes

btw, if i remove the first render, we render PROPERLY with just about the same arguments:

• write(1, "\33[?1049h\33[22;0;0t\33[H\33[2J\33[39;49m"..., 1024) = 1024
• write(1, "90;0;90m\33[48;2;0;0;180m\342\224\200\33[38;2"..., 162816) = 162816
• many 8192-byte writes to stderr, concluding with a 472-byte write
• claim of 164296 bytes

note that we have a 1049 at the beginning, which corresponds to smcup. had that not been sent already? very odd. might need to be flushing there if we're not going to properly write it out with tputs().

[dankamongmen]

Also, note that the second render call appears to be missing a '\33' at the beginning. I don't think that's an strace effect, since we're showing the leading '\33' on the first lines for the successful renders. Could that be our problem?

In no case that I can see are we writing a total number of bytes equivalent to the expected number of bytes, according to write() returns.

1024 + 162816 == 163840 < 164127
1024 + 162816 == 163840 < 164296
1024 + 162816 == 163840 < 164296

I think I'm misinterpreting the buflen aspect of POSIX memstreams? This could be explained if the buflen is the allocated length, and we've got a '\0' in there which cuts the write() short...but it's not like 164127 bytes are going to get allocated (hopefully), and 164296 isn't exactly a power of two either. Hrmmm.

[dankamongmen]

Ahhhhhh, of course. stdout is connected to a TTY and thus line-buffered. A fflush(stdout) here solves things. We could put it into unbuffered mode, but then we chew up more CPU time with smaller (8192b) write() calls. This fix is perfect.

We also now fflush() following the smcup transition into alternate mode, and see that go out immediately. Everything's working better. Let's cut a motherfucking release.