In trying to review this, I see that Behavior>>#startUp: simply says ^self startUp and there are dozens of implementors of #startUp (ugh).
So, I tried evaluating "FileStream halt startUp" to see where the debugger takes me. Can't step into it, which means its a no-op.
Are you sure the super call is doing something?
On Thu, Aug 14, 2014 at 2:58 PM, commits@source.squeak.org wrote:
A new version of Files was added to project The Inbox: http://source.squeak.org/inbox/Files-cbc.137.mcz
==================== Summary ====================
Name: Files-cbc.137 Author: cbc Time: 14 August 2014, 12:58:30.28 pm UUID: d0cae3e8-88fc-db40-a2ee-05ccc2714789 Ancestors: Files-eem.136
Fix FileStream class>>startUp: to call super startUp:. This allows normal startup routines (such as MutliByteFileStream) to determine what kind of line endings the platform uses at startup time (in other words, normal startup activities).
=============== Diff against Files-eem.136 ===============
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 ]] ].
"Allow regular #startUp activity as well"super startUp: resuming!
TheStdioHandles := Array new: 3 ]] ]!
On Thu, 14 Aug 2014, Chris Muller wrote:
In trying to review this, I see that Behavior>>#startUp: simply says ^self startUp and there are dozens of implementors of #startUp (ugh). So, I tried evaluating "FileStream halt startUp" to see where the debugger takes me. Can't step into it, which means its a no-op.
Are you sure the super call is doing something?
This solution works in the sense that it'll evaluate MultiByteFileStream class >> #startUp at startup, but it'll still evaluate it whenever the image is saved, and keep the double initialization of the stdioFiles. IMHO the right solution is to implement MultiByteFileStream class >> #startUp: as
resuming ifTrue: [ self guessDefaultLineEndConvention ]
And remove MultiByteFileStream class >> #startUp. Also it's time to remove CrLfFileStream from the startup list, because it also triggers another initialization of the stdioFiles. We should also revisit all implementors of #startUp, and probably change them to #startUp:, because changing the implementation in the superclass can have side effects like this.
Levente
On Thu, Aug 14, 2014 at 2:58 PM, commits@source.squeak.org wrote: A new version of Files was added to project The Inbox: http://source.squeak.org/inbox/Files-cbc.137.mcz
==================== Summary ==================== Name: Files-cbc.137 Author: cbc Time: 14 August 2014, 12:58:30.28 pm UUID: d0cae3e8-88fc-db40-a2ee-05ccc2714789 Ancestors: Files-eem.136 Fix FileStream class>>startUp: to call super startUp:. This allows normal startup routines (such as MutliByteFileStream) to determine what kind of line endings the platform uses at startup time (in other words, normal startup activities). =============== Diff against Files-eem.136 =============== 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 ] ] ]. + "Allow regular #startUp activity as well" + super startUp: resuming! - TheStdioHandles := Array new: 3 ] ] ]!
On Fri, Aug 15, 2014 at 2:58 AM, Levente Uzonyi leves@elte.hu wrote:
On Thu, 14 Aug 2014, Chris Muller wrote:
In trying to review this, I see that Behavior>>#startUp: simply says
^self startUp and there are dozens of implementors of #startUp (ugh). So, I tried evaluating "FileStream halt startUp" to see where the debugger takes me. Can't step into it, which means its a no-op.
Are you sure the super call is doing something?
This solution works in the sense that it'll evaluate MultiByteFileStream class >> #startUp at startup, but it'll still evaluate it whenever the image is saved, and keep the double initialization of the stdioFiles. IMHO the right solution is to implement MultiByteFileStream class >> #startUp: as
resuming ifTrue: [ self guessDefaultLineEndConvention ]And remove MultiByteFileStream class >> #startUp. Also it's time to remove CrLfFileStream from the startup list, because it also triggers another initialization of the stdioFiles. We should also revisit all implementors of #startUp, and probably change them to #startUp:, because changing the implementation in the superclass can have side effects like this.
+1
Levente
On Thu, Aug 14, 2014 at 2:58 PM, commits@source.squeak.org wrote: A new version of Files was added to project The Inbox: http://source.squeak.org/inbox/Files-cbc.137.mcz
==================== Summary ==================== Name: Files-cbc.137 Author: cbc Time: 14 August 2014, 12:58:30.28 pm UUID: d0cae3e8-88fc-db40-a2ee-05ccc2714789 Ancestors: Files-eem.136 Fix FileStream class>>startUp: to call super startUp:. This allowsnormal startup routines (such as MutliByteFileStream) to determine what kind of line endings the platform uses at startup time (in other words, normal startup activities).
=============== Diff against Files-eem.136 =============== Item was changed: ----- Method: FileStream class>>startUp: (in category 'systemstartup') ----- startUp: resuming
resuming ifTrue: [ self voidStdioFiles. [ TheStdioHandles := self stdioHandles ] on: Error do: [:ex| TheStdioHandles isArray ifFalse: [ + TheStdioHandles := Arraynew: 3 ] ] ]. + "Allow regular #startUp activity as well" + super startUp: resuming! - TheStdioHandles := Array new: 3 ] ] ]!
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Eliot Miranda -
Levente Uzonyi