Chris Muller uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-cmm.610.mcz ==================== Summary ==================== Name: System-cmm.610 Author: cmm Time: 26 October 2013, 2:17:09.114 pm UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 Ancestors: System-dtl.609 Consider valueWithAllPossibleArguments: special enough to inline, for now. =============== Diff against System-dtl.609 =============== Item was changed: ----- Method: SmalltalkImage>>do: (in category 'command line') ----- do: aBlock + [ [ (aBlock numArgs = 1 and: [ self arguments size > 1 ]) + ifTrue: [ aBlock value: self arguments ] + ifFalse: [ aBlock valueWithEnoughArguments: self arguments ] ] - [ [ aBlock valueWithAllPossibleArguments: self arguments ] on: ProgressInitiationException do: [ : pie | "Don't want to log this notification." pie defaultAction ] ] on: Notification , Warning do: [ : noti | StandardFileStream stdout nextPutAll: DateAndTime now asString ; space ; nextPutAll: noti description ; cr. noti resume ] on: SyntaxErrorNotification do: [ : err | StandardFileStream stdout nextPutAll: err errorCode ; cr. self haltOrQuit ] on: Error do: [ : err | err printVerboseOn: StandardFileStream stderr. self haltOrQuit. err isResumable ifTrue: [ err resume ] ]! |
Another question, why do: ? I find this a false polymorphism and its usage is rather hard to trace...2013/10/26 <[hidden email]> Chris Muller uploaded a new version of System to project The Trunk: |
And yet another, shouldn't we rather integrate the excellent work that Camillo Bruni did in Pharo? See System-CommandLine at MCHttpRepository location: 'http://smalltalkhub.com/mc/Pharo/Pharo30/main' user: '' password: '' 2013/10/27 Nicolas Cellier <[hidden email]>
|
Also note that Smalltalk do: did mean a different thing when Smalltalk was the SystemDictionary. 2013/10/27 Nicolas Cellier <[hidden email]>
|
Yes, that's a good point, but how about proposing an alternative next time?
#run:? On Sun, Oct 27, 2013 at 3:36 PM, Nicolas Cellier <[hidden email]> wrote: > Also note that Smalltalk do: did mean a different thing when Smalltalk was > the SystemDictionary. > > > 2013/10/27 Nicolas Cellier <[hidden email]> >> >> And yet another, shouldn't we rather integrate the excellent work that >> Camillo Bruni did in Pharo? >> >> See System-CommandLine at >> >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/Pharo/Pharo30/main' >> user: '' >> password: '' >> >> >> 2013/10/27 Nicolas Cellier <[hidden email]> >>> >>> Another question, why do: ? >>> I find this a false polymorphism and its usage is rather hard to trace... >>> >>> >>> 2013/10/26 <[hidden email]> >>> >>>> Chris Muller uploaded a new version of System to project The Trunk: >>>> http://source.squeak.org/trunk/System-cmm.610.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: System-cmm.610 >>>> Author: cmm >>>> Time: 26 October 2013, 2:17:09.114 pm >>>> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >>>> Ancestors: System-dtl.609 >>>> >>>> Consider valueWithAllPossibleArguments: special enough to inline, for >>>> now. >>>> >>>> =============== Diff against System-dtl.609 =============== >>>> >>>> Item was changed: >>>> ----- Method: SmalltalkImage>>do: (in category 'command line') ----- >>>> do: aBlock >>>> + [ [ (aBlock numArgs = 1 and: [ self arguments size > 1 ]) >>>> + ifTrue: [ aBlock value: self arguments ] >>>> + ifFalse: [ aBlock valueWithEnoughArguments: self >>>> arguments ] ] >>>> - [ [ aBlock valueWithAllPossibleArguments: self arguments ] >>>> on: ProgressInitiationException >>>> do: >>>> [ : pie | "Don't want to log this notification." >>>> pie defaultAction ] ] >>>> on: Notification , Warning >>>> do: >>>> [ : noti | StandardFileStream stdout >>>> nextPutAll: DateAndTime now asString ; >>>> space ; >>>> nextPutAll: noti description ; >>>> cr. >>>> noti resume ] >>>> on: SyntaxErrorNotification >>>> do: >>>> [ : err | StandardFileStream stdout >>>> nextPutAll: err errorCode ; >>>> cr. >>>> self haltOrQuit ] >>>> on: Error >>>> do: >>>> [ : err | err printVerboseOn: StandardFileStream >>>> stderr. >>>> self haltOrQuit. >>>> err isResumable ifTrue: [ err resume ] ]! >>>> >>>> >>> >> > > > > |
In reply to this post by Nicolas Cellier
On Sun, Oct 27, 2013 at 3:33 PM, Nicolas Cellier
<[hidden email]> wrote: > And yet another, shouldn't we rather integrate the excellent work that > Camillo Bruni did in Pharo? > > See System-CommandLine at > > MCHttpRepository > location: 'http://smalltalkhub.com/mc/Pharo/Pharo30/main' > user: '' > password: '' Not sure. The 4 methods I added are not a REPL. That's not something I myself need, but a sophisticated command-line interface to Squeak sounds neat and novel. I don't think I've ever really fully understood the case where I'd want to _interact_ with Smalltalk via a command-line (on an on-going, ad-hoc basis). It seems like I always either want full GUI interaction, or simple job control that can properly respond to errors and nothing more.. > 2013/10/27 Nicolas Cellier <[hidden email]> >> >> Another question, why do: ? >> I find this a false polymorphism and its usage is rather hard to trace... Normally since the scripts are external, they won't be traceable anyway. However, since I'm just now starting to include my scripts in the image (so they have benefit of being _documented_ and under MC's control), perhaps #run: would be better.. >> >> >> 2013/10/26 <[hidden email]> >> >>> Chris Muller uploaded a new version of System to project The Trunk: >>> http://source.squeak.org/trunk/System-cmm.610.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: System-cmm.610 >>> Author: cmm >>> Time: 26 October 2013, 2:17:09.114 pm >>> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >>> Ancestors: System-dtl.609 >>> >>> Consider valueWithAllPossibleArguments: special enough to inline, for >>> now. >>> >>> =============== Diff against System-dtl.609 =============== >>> >>> Item was changed: >>> ----- Method: SmalltalkImage>>do: (in category 'command line') ----- >>> do: aBlock >>> + [ [ (aBlock numArgs = 1 and: [ self arguments size > 1 ]) >>> + ifTrue: [ aBlock value: self arguments ] >>> + ifFalse: [ aBlock valueWithEnoughArguments: self >>> arguments ] ] >>> - [ [ aBlock valueWithAllPossibleArguments: self arguments ] >>> on: ProgressInitiationException >>> do: >>> [ : pie | "Don't want to log this notification." >>> pie defaultAction ] ] >>> on: Notification , Warning >>> do: >>> [ : noti | StandardFileStream stdout >>> nextPutAll: DateAndTime now asString ; >>> space ; >>> nextPutAll: noti description ; >>> cr. >>> noti resume ] >>> on: SyntaxErrorNotification >>> do: >>> [ : err | StandardFileStream stdout >>> nextPutAll: err errorCode ; >>> cr. >>> self haltOrQuit ] >>> on: Error >>> do: >>> [ : err | err printVerboseOn: StandardFileStream >>> stderr. >>> self haltOrQuit. >>> err isResumable ifTrue: [ err resume ] ]! >>> >>> >> > > > > |
On Sun, Oct 27, 2013 at 06:38:15PM -0500, Chris Muller wrote:
> On Sun, Oct 27, 2013 at 3:33 PM, Nicolas Cellier > <[hidden email]> wrote: > > And yet another, shouldn't we rather integrate the excellent work that > > Camillo Bruni did in Pharo? > > > > See System-CommandLine at > > > > MCHttpRepository > > location: 'http://smalltalkhub.com/mc/Pharo/Pharo30/main' > > user: '' > > password: '' > > Not sure. The 4 methods I added are not a REPL. That's not something > I myself need, but a sophisticated command-line interface to Squeak > sounds neat and novel. I don't think I've ever really fully > understood the case where I'd want to _interact_ with Smalltalk via a > command-line (on an on-going, ad-hoc basis). It seems like I always > either want full GUI interaction, or simple job control that can > properly respond to errors and nothing more.. I made ExternalCommandShell (in package CommandShell) to do exactly that - serve as a REPL and evaluate Smalltalk and/or unix input. It's kind of interesting to see that it can be done, but I can't say that I actually use it for anything, and as far as I know nobody else does either. I'm not quite sure what Camillo Bruni did for Pharo, but if it improves the ability to run Smalltalk scripts from a command line, it might be quite useful. Dave |
In reply to this post by commits-2
On 26 October 2013 20:17, <[hidden email]> wrote:
> Chris Muller uploaded a new version of System to project The Trunk: > http://source.squeak.org/trunk/System-cmm.610.mcz > > ==================== Summary ==================== > > Name: System-cmm.610 > Author: cmm > Time: 26 October 2013, 2:17:09.114 pm > UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 > Ancestors: System-dtl.609 > > Consider valueWithAllPossibleArguments: special enough to inline, for now. > > =============== Diff against System-dtl.609 =============== Why "StandardFileStream stdout" and not "FileStream stdout"? The latter is shorter and more abstract. frank |
Indeed. OTOH, stdout and stderr ARE kinds of StandardFileStreams so I
question whether the location of _those_ accessors is appropriate, or whether they should be on StandardFileStream..? On Wed, Oct 30, 2013 at 5:09 PM, Frank Shearar <[hidden email]> wrote: > On 26 October 2013 20:17, <[hidden email]> wrote: >> Chris Muller uploaded a new version of System to project The Trunk: >> http://source.squeak.org/trunk/System-cmm.610.mcz >> >> ==================== Summary ==================== >> >> Name: System-cmm.610 >> Author: cmm >> Time: 26 October 2013, 2:17:09.114 pm >> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >> Ancestors: System-dtl.609 >> >> Consider valueWithAllPossibleArguments: special enough to inline, for now. >> >> =============== Diff against System-dtl.609 =============== > > Why "StandardFileStream stdout" and not "FileStream stdout"? The > latter is shorter and more abstract. > > frank > |
Well, I just mean that as a user of stdout I don't particularly care
whether stdout is a StandardFileStream or a SpecialSnowflakeFileStream, so FileStream seems like the more appropriate receiver. (Also, it's a lot shorter. I'm sad enough about how long "FileStream" is.) frank On 30 October 2013 22:44, Chris Muller <[hidden email]> wrote: > Indeed. OTOH, stdout and stderr ARE kinds of StandardFileStreams so I > question whether the location of _those_ accessors is appropriate, or > whether they should be on StandardFileStream..? > > > On Wed, Oct 30, 2013 at 5:09 PM, Frank Shearar <[hidden email]> wrote: >> On 26 October 2013 20:17, <[hidden email]> wrote: >>> Chris Muller uploaded a new version of System to project The Trunk: >>> http://source.squeak.org/trunk/System-cmm.610.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: System-cmm.610 >>> Author: cmm >>> Time: 26 October 2013, 2:17:09.114 pm >>> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >>> Ancestors: System-dtl.609 >>> >>> Consider valueWithAllPossibleArguments: special enough to inline, for now. >>> >>> =============== Diff against System-dtl.609 =============== >> >> Why "StandardFileStream stdout" and not "FileStream stdout"? The >> latter is shorter and more abstract. >> >> frank >> > |
In reply to this post by Chris Muller-3
On Wed, 30 Oct 2013, Chris Muller wrote:
> Indeed. OTOH, stdout and stderr ARE kinds of StandardFileStreams so I > question whether the location of _those_ accessors is appropriate, or > whether they should be on StandardFileStream..? You should use FileStream. The class of the actual streams depends on the value of the #encodeAndDecodeStdioFiles preference. Its value is true by default, which means that streams should be instances of MultiByteFileStream. If they are StandardFileStreams in your image, then you have changed the value of the preference. Levente > > > On Wed, Oct 30, 2013 at 5:09 PM, Frank Shearar <[hidden email]> wrote: >> On 26 October 2013 20:17, <[hidden email]> wrote: >>> Chris Muller uploaded a new version of System to project The Trunk: >>> http://source.squeak.org/trunk/System-cmm.610.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: System-cmm.610 >>> Author: cmm >>> Time: 26 October 2013, 2:17:09.114 pm >>> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >>> Ancestors: System-dtl.609 >>> >>> Consider valueWithAllPossibleArguments: special enough to inline, for now. >>> >>> =============== Diff against System-dtl.609 =============== >> >> Why "StandardFileStream stdout" and not "FileStream stdout"? The >> latter is shorter and more abstract. >> >> frank >> > > |
But MultiByteFileStream is-a StandardFileStream.
On Wed, Oct 30, 2013 at 10:46 PM, Levente Uzonyi <[hidden email]> wrote: > On Wed, 30 Oct 2013, Chris Muller wrote: > >> Indeed. OTOH, stdout and stderr ARE kinds of StandardFileStreams so I >> question whether the location of _those_ accessors is appropriate, or >> whether they should be on StandardFileStream..? > > > You should use FileStream. The class of the actual streams depends on the > value of the #encodeAndDecodeStdioFiles preference. Its value is true by > default, which means that streams should be instances of > MultiByteFileStream. If they are StandardFileStreams in your image, then you > have changed the value of the preference. > > > Levente > > >> >> >> On Wed, Oct 30, 2013 at 5:09 PM, Frank Shearar <[hidden email]> >> wrote: >>> >>> On 26 October 2013 20:17, <[hidden email]> wrote: >>>> >>>> Chris Muller uploaded a new version of System to project The Trunk: >>>> http://source.squeak.org/trunk/System-cmm.610.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: System-cmm.610 >>>> Author: cmm >>>> Time: 26 October 2013, 2:17:09.114 pm >>>> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >>>> Ancestors: System-dtl.609 >>>> >>>> Consider valueWithAllPossibleArguments: special enough to inline, for >>>> now. >>>> >>>> =============== Diff against System-dtl.609 =============== >>> >>> >>> Why "StandardFileStream stdout" and not "FileStream stdout"? The >>> latter is shorter and more abstract. >>> >>> frank >>> >> >> > |
In reply to this post by Levente Uzonyi-2
FYI I sent Frank a private note that I've changed it to simply FileStream.
So I'm not trying to resist you, just making conversation.. :) On Wed, Oct 30, 2013 at 10:46 PM, Levente Uzonyi <[hidden email]> wrote: > On Wed, 30 Oct 2013, Chris Muller wrote: > >> Indeed. OTOH, stdout and stderr ARE kinds of StandardFileStreams so I >> question whether the location of _those_ accessors is appropriate, or >> whether they should be on StandardFileStream..? > > > You should use FileStream. The class of the actual streams depends on the > value of the #encodeAndDecodeStdioFiles preference. Its value is true by > default, which means that streams should be instances of > MultiByteFileStream. If they are StandardFileStreams in your image, then you > have changed the value of the preference. > > > Levente > > >> >> >> On Wed, Oct 30, 2013 at 5:09 PM, Frank Shearar <[hidden email]> >> wrote: >>> >>> On 26 October 2013 20:17, <[hidden email]> wrote: >>>> >>>> Chris Muller uploaded a new version of System to project The Trunk: >>>> http://source.squeak.org/trunk/System-cmm.610.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: System-cmm.610 >>>> Author: cmm >>>> Time: 26 October 2013, 2:17:09.114 pm >>>> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >>>> Ancestors: System-dtl.609 >>>> >>>> Consider valueWithAllPossibleArguments: special enough to inline, for >>>> now. >>>> >>>> =============== Diff against System-dtl.609 =============== >>> >>> >>> Why "StandardFileStream stdout" and not "FileStream stdout"? The >>> latter is shorter and more abstract. >>> >>> frank >>> >> >> > |
In reply to this post by Chris Muller-4
On Thu, 31 Oct 2013, Chris Muller wrote:
> But MultiByteFileStream is-a StandardFileStream. Right, but this case is just an example of misuse of inheritance instead of encapsulation. Levente > > On Wed, Oct 30, 2013 at 10:46 PM, Levente Uzonyi <[hidden email]> wrote: >> On Wed, 30 Oct 2013, Chris Muller wrote: >> >>> Indeed. OTOH, stdout and stderr ARE kinds of StandardFileStreams so I >>> question whether the location of _those_ accessors is appropriate, or >>> whether they should be on StandardFileStream..? >> >> >> You should use FileStream. The class of the actual streams depends on the >> value of the #encodeAndDecodeStdioFiles preference. Its value is true by >> default, which means that streams should be instances of >> MultiByteFileStream. If they are StandardFileStreams in your image, then you >> have changed the value of the preference. >> >> >> Levente >> >> >>> >>> >>> On Wed, Oct 30, 2013 at 5:09 PM, Frank Shearar <[hidden email]> >>> wrote: >>>> >>>> On 26 October 2013 20:17, <[hidden email]> wrote: >>>>> >>>>> Chris Muller uploaded a new version of System to project The Trunk: >>>>> http://source.squeak.org/trunk/System-cmm.610.mcz >>>>> >>>>> ==================== Summary ==================== >>>>> >>>>> Name: System-cmm.610 >>>>> Author: cmm >>>>> Time: 26 October 2013, 2:17:09.114 pm >>>>> UUID: a27149c5-0fd6-4bef-a34a-57db707aec83 >>>>> Ancestors: System-dtl.609 >>>>> >>>>> Consider valueWithAllPossibleArguments: special enough to inline, for >>>>> now. >>>>> >>>>> =============== Diff against System-dtl.609 =============== >>>> >>>> >>>> Why "StandardFileStream stdout" and not "FileStream stdout"? The >>>> latter is shorter and more abstract. >>>> >>>> frank >>>> >>> >>> >> > |
Free forum by Nabble | Edit this page |