The Inbox: Files-dtl.163.mcz

David T. Lewis uploaded a new version of Files to project The Inbox:
http://source.squeak.org/inbox/Files-dtl.163.mcz

==================== Summary ====================

Name: Files-dtl.163
Author: dtl
Time: 27 August 2016, 11:16:05.899859 pm
UUID: b4b2f4c1-4c24-44b4-8fc7-90a63a0f5940
Ancestors: Files-ul.162

Add StandardFileStream>>update: to handle #appendEntry by flushing the stream. This allows the standard output stream to be a dependent of the Transcript, flushing output as expected for a transcript view.

=============== Diff against Files-ul.162 ===============

Item was changed:
  ----- Method: FileStream class>>startUp: (in category 'system startup') -----
  startUp: resuming
 
  resuming ifTrue: [
  self voidStdioFiles.
  [ TheStdioHandles := self stdioHandles ]
  on: Error
  do: [:ex|
  TheStdioHandles isArray ifFalse: [
+ TheStdioHandles := Array new: 3 ] ].
+ (Smalltalk at: #TranscriptStream)
+ ifNotNilDo: [ :t | "Reestablish dependency for stdout Transcript view"
+ t redirectToStdOut: t redirectToStdOut ] ]!
- TheStdioHandles := Array new: 3 ] ] ]!

Item was added:
+ ----- Method: StandardFileStream>>update: (in category 'updating') -----
+ update: aParameter
+ super update: aParameter.
+ aParameter == #appendEntry
+ ifTrue: [self flush]. "Transcript is being redirected to this steam, stdout"
+ !

On Sun, 28 Aug 2016, [hidden email] wrote:

Smalltalk >> #at: will raise an error when there's no entry for the given
key.

> + ifNotNilDo: [ :t | "Reestablish dependency for stdout Transcript view"

We should deprecate #ifNotNilDo: in favor of #ifNotNil:.

Levente

On Sun, Aug 28, 2016 at 12:47:26PM +0200, Levente Uzonyi wrote:
>
> Smalltalk >> #at: will raise an error when there's no entry for the given
> key.

Oops, thank you.

>
> > ifNotNilDo: [ :t | "Reestablish dependency for stdout Transcript view"
>
> We should deprecate #ifNotNilDo: in favor of #ifNotNil:.
>

Yes. Or at least update the method comment to make the difference clear.

Possibly we should we have a package named 'Deprecated-Compatibility' for
methods that are deprecated, but that we do not actually want to remove
from the system any time soon. There is probably a small number of methods
that may be used by externally maintained packages that should be marked
as deprecated, but kept in the image as a convenience for loading existing
packages from SqueakMap.

Dave