On Tue, 1 Oct 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cmm.538.mcz
==================== Summary ====================
Name: Collections-cmm.538 Author: cmm Time: 30 September 2013, 7:50:52.954 pm UUID: f041f162-9c02-499f-866e-27d2e1a31b6b Ancestors: Collections-tpr.537
- Logging output to a #endEntry is sometimes necessary. So let's still allow switching to another kind of WriteStream.
I don't see the point of this change. #flush is part of the Stream protocol, so it's definitely not a compatibility method in WriteStream. It's better to use #flush instead of #endEntry, because all streams understand #flush, but only Transcript (and now WriteStream) understands #endEntry.
Levente
=============== Diff against Collections-tpr.537 ===============
Item was added:
- ----- Method: WriteStream>>endEntry (in category 'compatibility') -----
- endEntry
- "No-op for compatibility with TranscriptStream."!
Item was changed:
- ----- Method: WriteStream>>flush (in category 'compatibility') -----
- ----- Method: WriteStream>>flush (in category 'file open/close') -----
flush!
I had not noticed the existence of TranscriptStream>>#flush. Clearly, TranscriptStream>>#endEntry is miscategorized then -- it should be private, should it not?
My version comment was intended to say: "When Logging output to a TranscriptStream, #endEntry is sometimes necessary. So let's still allow switching to another kind of WriteStream."
Since flush is available, you're right, we don't need it on WriteStream. I'll remove it when I get a chance.
On Tue, Oct 1, 2013 at 10:56 AM, Levente Uzonyi leves@elte.hu wrote:
On Tue, 1 Oct 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cmm.538.mcz
==================== Summary ====================
Name: Collections-cmm.538 Author: cmm Time: 30 September 2013, 7:50:52.954 pm UUID: f041f162-9c02-499f-866e-27d2e1a31b6b Ancestors: Collections-tpr.537
- Logging output to a #endEntry is sometimes necessary. So let's still
allow switching to another kind of WriteStream.
I don't see the point of this change. #flush is part of the Stream protocol, so it's definitely not a compatibility method in WriteStream. It's better to use #flush instead of #endEntry, because all streams understand #flush, but only Transcript (and now WriteStream) understands #endEntry.
Levente
=============== Diff against Collections-tpr.537 ===============
Item was added:
- ----- Method: WriteStream>>endEntry (in category 'compatibility') -----
- endEntry
"No-op for compatibility with TranscriptStream."!
Item was changed:
- ----- Method: WriteStream>>flush (in category 'compatibility') -----
- ----- Method: WriteStream>>flush (in category 'file open/close') -----
flush!
I don't think that #endEntry should be private. AFAIK Transcript wasn't always a stream, and #endEntry was part of Transcript's original protocol. If you check the senders of #endEntry, then you'll find that the receiver is always "Transcript" or "self". Replacing #endEntry with #flush won't hurt in most cases.
Levente
On Tue, 1 Oct 2013, Chris Muller wrote:
I had not noticed the existence of TranscriptStream>>#flush. Clearly, TranscriptStream>>#endEntry is miscategorized then -- it should be private, should it not?
My version comment was intended to say: "When Logging output to a TranscriptStream, #endEntry is sometimes necessary. So let's still allow switching to another kind of WriteStream."
Since flush is available, you're right, we don't need it on WriteStream. I'll remove it when I get a chance.
On Tue, Oct 1, 2013 at 10:56 AM, Levente Uzonyi leves@elte.hu wrote:
On Tue, 1 Oct 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cmm.538.mcz
==================== Summary ====================
Name: Collections-cmm.538 Author: cmm Time: 30 September 2013, 7:50:52.954 pm UUID: f041f162-9c02-499f-866e-27d2e1a31b6b Ancestors: Collections-tpr.537
- Logging output to a #endEntry is sometimes necessary. So let's still
allow switching to another kind of WriteStream.
I don't see the point of this change. #flush is part of the Stream protocol, so it's definitely not a compatibility method in WriteStream. It's better to use #flush instead of #endEntry, because all streams understand #flush, but only Transcript (and now WriteStream) understands #endEntry.
Levente
=============== Diff against Collections-tpr.537 ===============
Item was added:
- ----- Method: WriteStream>>endEntry (in category 'compatibility') -----
- endEntry
"No-op for compatibility with TranscriptStream."!
Item was changed:
- ----- Method: WriteStream>>flush (in category 'compatibility') -----
- ----- Method: WriteStream>>flush (in category 'file open/close') -----
flush!
In the context of Smalltalk-80, I can understand logging straight to Transcript and using Transcript-specific functions (e.g., endEntry). Today, I consider referencing Transcript directly to be bad-form, simply because it tightly binds code to a particular UI.
I prefer to signal Notifications to let the what-is-logged remain independent of the where-its-logged.
always "Transcript" or "self". Replacing #endEntry with #flush won't hurt in most cases.
"Most" cases, or all? I was intending to change all of MY sends of endEntry to flush (if any), is there a caveat?
On Tue, 1 Oct 2013, Chris Muller wrote:
In the context of Smalltalk-80, I can understand logging straight to Transcript and using Transcript-specific functions (e.g., endEntry). Today, I consider referencing Transcript directly to be bad-form, simply because it tightly binds code to a particular UI.
I prefer to signal Notifications to let the what-is-logged remain independent of the where-its-logged.
Notifications kill performance. Here's a small comparison of using no logging at all, using Notifications for logging, and using a ProcessLocalVariable for logging:
"No logging." [ | counter | counter := 0. 100000 timesRepeat: [ [ counter := counter + 1 ] value ] ] timeToRun. "10" "Notifications." [ | counter | counter := 0. [ 100000 timesRepeat: [ [ counter := counter + 1. Notification signal: counter ] value ] ] on: Notification do: [ :not | "logging would happen here" not resume ] ] timeToRun. "274" "Notifications. No logger." [ | counter | counter := 0. 100000 timesRepeat: [ [ counter := counter + 1. Notification signal: counter ] value ] ] timeToRun. "214" "ProcessLocalVariable." [ | counter | counter := 0. DynamicVariable value: [ :messageToLog | "logging would happen here" ] during: [ 100000 timesRepeat: [ [ counter := counter + 1. DynamicVariable value ifNotNil: [ :logger | logger value: counter ] ] value ] ] ] timeToRun. "34" "ProcessLocalVariable. No logger." [ | counter | counter := 0. 100000 timesRepeat: [ [ counter := counter + 1. DynamicVariable value ifNotNil: [ :logger | logger value: counter ] ] value ] ] timeToRun. "32"
The deeper the stack is (depth is 3 in this example: 2 blocks evaluations + 1 message send), the slower Notifications will be.
always "Transcript" or "self". Replacing #endEntry with #flush won't hurt in most cases.
"Most" cases, or all? I was intending to change all of MY sends of endEntry to flush (if any), is there a caveat?
Yes. Replacing #endEntry with #flush in Transcript >> #flush would lead to infinite recursion. In some methods the receiver of #endEntry is a Transcripter, which doesn't have its own implementation of #flush. Without that it would break.
Levente
endEntry is, though, essentially obsolete. flush is better; it's more flexible because it works with Transcript and streams, and has a more generally understood meaning. So I'd like to see endEntry deprecated.
On Tue, Oct 1, 2013 at 9:37 AM, Levente Uzonyi leves@elte.hu wrote:
I don't think that #endEntry should be private. AFAIK Transcript wasn't always a stream, and #endEntry was part of Transcript's original protocol. If you check the senders of #endEntry, then you'll find that the receiver is always "Transcript" or "self". Replacing #endEntry with #flush won't hurt in most cases.
Levente
On Tue, 1 Oct 2013, Chris Muller wrote:
I had not noticed the existence of TranscriptStream>>#flush. Clearly,
TranscriptStream>>#endEntry is miscategorized then -- it should be private, should it not?
My version comment was intended to say: "When Logging output to a TranscriptStream, #endEntry is sometimes necessary. So let's still allow switching to another kind of WriteStream."
Since flush is available, you're right, we don't need it on WriteStream. I'll remove it when I get a chance.
On Tue, Oct 1, 2013 at 10:56 AM, Levente Uzonyi leves@elte.hu wrote:
On Tue, 1 Oct 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/**trunk/Collections-cmm.538.mczhttp://source.squeak.org/trunk/Collections-cmm.538.mcz
==================== Summary ====================
Name: Collections-cmm.538 Author: cmm Time: 30 September 2013, 7:50:52.954 pm UUID: f041f162-9c02-499f-866e-**27d2e1a31b6b Ancestors: Collections-tpr.537
- Logging output to a #endEntry is sometimes necessary. So let's still
allow switching to another kind of WriteStream.
I don't see the point of this change. #flush is part of the Stream protocol, so it's definitely not a compatibility method in WriteStream. It's better to use #flush instead of #endEntry, because all streams understand #flush, but only Transcript (and now WriteStream) understands #endEntry.
Levente
=============== Diff against Collections-tpr.537 ===============
Item was added:
- ----- Method: WriteStream>>endEntry (in category 'compatibility')
- endEntry
"No-op for compatibility with TranscriptStream."!
Item was changed:
- ----- Method: WriteStream>>flush (in category 'compatibility') -----
- ----- Method: WriteStream>>flush (in category 'file open/close') -----
flush!
So I guess we have 24 senders of #endEntry most of which should probably be sending #flush instead.
On Tue, Oct 1, 2013 at 10:56 AM, Levente Uzonyi leves@elte.hu wrote:
On Tue, 1 Oct 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cmm.538.mcz
==================== Summary ====================
Name: Collections-cmm.538 Author: cmm Time: 30 September 2013, 7:50:52.954 pm UUID: f041f162-9c02-499f-866e-27d2e1a31b6b Ancestors: Collections-tpr.537
- Logging output to a #endEntry is sometimes necessary. So let's still
allow switching to another kind of WriteStream.
I don't see the point of this change. #flush is part of the Stream protocol, so it's definitely not a compatibility method in WriteStream. It's better to use #flush instead of #endEntry, because all streams understand #flush, but only Transcript (and now WriteStream) understands #endEntry.
Levente
=============== Diff against Collections-tpr.537 ===============
Item was added:
- ----- Method: WriteStream>>endEntry (in category 'compatibility') -----
- endEntry
"No-op for compatibility with TranscriptStream."!
Item was changed:
- ----- Method: WriteStream>>flush (in category 'compatibility') -----
- ----- Method: WriteStream>>flush (in category 'file open/close') -----
flush!
squeak-dev@lists.squeakfoundation.org