TranscriptTTY oddity -- fixed in V8.0.1

[PhotonDemon]

Hi All,

In another post, I mentioned that I had extended TranscriptTTY with a #lf method that sent a line feed. I did this because when using TranscriptTTY and sending it #cr there seemed to be extra carriage returns placed in the output. The text editor I use displays these extra Cr's in an anoying way that I can't seem to turn off.

I checked into this a little further and found that sending a LF character to TranscriptTTY results in putting a Cr and Lf in the output. The #cr method sends the CldtConstants::LineDelimiter string (which is a Cr and Lf on windows) and results in two Cr's and a Lf being put in the output. I think (a guess on my part) that this is a problem with the VM as the code that sends characters and strings to TranscriptTTY with #outputToTTY are primitives.

This isn't a big deal, so the developers shouldn't worry too much about it on my part. If anyone else has any other ideas, I'm at least mildly interested.

Lou

P.S. If you can run this in a server (not the development environment) you can see what I mean.

Code: Select all

   tty := TranscriptTTY default.
   tty show: 'LineDelimiter size: '; show: CldtConstants::LineDelimiter size printString; cr.
   tty show: ('xxx', CldtConstants::LineDelimiter, 'xxx'); cr.
   tty show: ('yyy', CldtConstants::Cr asString, CldtConstants::Lf asString, 'yyy'); cr.


[rjs]

In another post, I mentioned that I had extended TranscriptTTY with a #lf method that sent a line feed. I did this because when using TranscriptTTY and sending it #cr there seemed to be extra carriage returns placed in the output. The text editor I use displays these extra Cr's in an anoying way that I can't seem to turn off.

LineDelimiter is initialized in String class>>#initialize. It uses a method called #platformLineDelimiter which notes the primitive could be missing, in which case it defaults to CR/LF.

I think it is unlikely you are missing the primitive, although it is possible. A more likely alternate solution would be to initialize LineDelimiter after String has done its bit.

Richard

[PhotonDemon]

Hi Richard,

LineDelimiter is initialized in String class>>#initialize. It uses a method called #platformLineDelimiter which notes the primitive could be missing, in which case it defaults to CR/LF.

I think it is unlikely you are missing the primitive, although it is possible. A more likely alternate solution would be to initialize LineDelimiter after String has done its bit.
Richard

Thanks for the reply. Perhaps I wasn't clear in my post. LineDelimiter is correctly initialized to CR/LF. The output to TranscriptTTY is CR/CR/LF. With some testing, by manually sending CR/LF and just LF, I see that the LF results in CR/LF being output to TranscriptTTY. Somehow a CR is added out of no-where. As I said, it looks like a primitive is doing this.

Lou

[rjs]

Perhaps I wasn't clear in my post.

Oh, you were clear (as I discovered on rereading what you wrote). I just wasn't reading what you wrote.

[wembley]

Lou -

You are correct, although I don't know why you would see this only at runtime. Here is the explanation:

TranscriptTTY>>#cr on Windows tries to write CR/LF to the log file. The TTYOutputString primitive calls the platform-specific EsTTYOutputString routine which on Windows writes strings a character at a time. So it calls the platform-specific EsTTYOutputChar routine twice, once to write the CR and then to write the LF. However, we are now in C code, so when EsTTYOutputChar gets a '\n' (LF), it writes a '\r' (CR) to the log before writing the '\n'. The result is \r\r\n in the log file.

There actually is a rational for this behavior of the TranscriptTTY primitives on Windows. There really is no way of knowing if the string being written originally came from Smalltalk on Windows (in which case line endings are CR/LF), Smalltalk on Unix (in which case the line endings are LF) or C (in which case the line endings are '\n' (LF)), so it always tries to make sure it outputs a \r\n combination. The best fix seems to be to strip all \r (CR) characters when passing characters from EsTTYOutputString to EsTTYOutputChar on Windows.

Case 42070 opened; fixed in V8.0.1.

[PhotonDemon]

Hi John,

You are correct, although I don't know why you would see this only at runtime....

I'm sorry, I didn't mean to imply that you wouldn't see the same results in the development environment. I have forgotten how to capture the output of TranscriptTTY in the development environment. In my real code I use Transcript, which in the development environment uses the Transcript window, which works correctly, and at runtime uses TranscriptTTY which doesn't work right.

Lou