The Trunk: Collections-cmm.538.mcz

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.

=============== 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!

On Tue, 1 Oct 2013, [hidden email] wrote:

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

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 <[hidden email]> wrote:

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 <[hidden email]> 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:

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