The Trunk: Kernel-eem.1117.mcz
Locked
 
|
Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.1117.mcz ==================== Summary ==================== Name: Kernel-eem.1117 Author: eem Time: 7 November 2017, 5:11:32.043344 pm UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b Ancestors: Kernel-tpr.1116 Use a slightly less baroque implemetation for Context>>arguments, equivalent to Pharo's. =============== Diff against Kernel-tpr.1116 =============== Item was changed: ----- Method: Context>>arguments (in category 'accessing') ----- arguments + "Answer the receiver's arguments as an Array. + We could use simply ^(1 to: self numArgs) collect: [:i| self tempAt: i] + but for performance and minimality we use the implementation below." + | n args | + args := Array new: (n := self numArgs). + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. + ^args! - - ^ Array new: self numArgs streamContents: [:args | - 1 to: self numArgs do: [: i | - args nextPut: (self tempAt: i)]]! |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
> On 08.11.2017, at 02:11, [hidden email] wrote: > > Eliot Miranda uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-eem.1117.mcz > > ==================== Summary ==================== > > Name: Kernel-eem.1117 > Author: eem > Time: 7 November 2017, 5:11:32.043344 pm > UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b > Ancestors: Kernel-tpr.1116 > > Use a slightly less baroque implemetation for Context>>arguments, equivalent to Pharo's. > What is baroque about that? I'd prefer the other stile any time. I especially find the assignment in the "computation" of the argument ugly (the n assignment) and potentially confusing. I'm a bit puzzled you prefer the style you just put there to the streaming constructor… Best regards -Tobias > =============== Diff against Kernel-tpr.1116 =============== > > Item was changed: > ----- Method: Context>>arguments (in category 'accessing') ----- > arguments > + "Answer the receiver's arguments as an Array. > + We could use simply ^(1 to: self numArgs) collect: [:i| self tempAt: i] > + but for performance and minimality we use the implementation below." > + | n args | > + args := Array new: (n := self numArgs). > + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. > + ^args! > - > - ^ Array new: self numArgs streamContents: [:args | > - 1 to: self numArgs do: [: i | > - args nextPut: (self tempAt: i)]]! > > |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
+1. #streamContents: is a high-level message.
Eliot is a master of C programming, I guess we all see our own style as less baroque. I generally try to retain original authors' style and formatting as much as possible unless I'm making significant changes to the method. I would never only replace someone's formatting or style with my own. On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <[hidden email]> wrote: > >> On 08.11.2017, at 02:11, [hidden email] wrote: >> >> Eliot Miranda uploaded a new version of Kernel to project The Trunk: >> http://source.squeak.org/trunk/Kernel-eem.1117.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-eem.1117 >> Author: eem >> Time: 7 November 2017, 5:11:32.043344 pm >> UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b >> Ancestors: Kernel-tpr.1116 >> >> Use a slightly less baroque implemetation for Context>>arguments, equivalent to Pharo's. >> > > What is baroque about that? > I'd prefer the other stile any time. > I especially find the assignment in the "computation" of the argument ugly (the n assignment) and potentially confusing. > > I'm a bit puzzled you prefer the style you just put there to the streaming constructor… > > Best regards > -Tobias > >> =============== Diff against Kernel-tpr.1116 =============== >> >> Item was changed: >> ----- Method: Context>>arguments (in category 'accessing') ----- >> arguments >> + "Answer the receiver's arguments as an Array. >> + We could use simply ^(1 to: self numArgs) collect: [:i| self tempAt: i] >> + but for performance and minimality we use the implementation below." >> + | n args | >> + args := Array new: (n := self numArgs). >> + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. >> + ^args! >> - >> - ^ Array new: self numArgs streamContents: [:args | >> - 1 to: self numArgs do: [: i | >> - args nextPut: (self tempAt: i)]]! >> >> > > |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
But old implementation was a to:do: loop on indices with (self tempAt: i) So we already pay the price of low level procedural style, why having to pay the stream overhead? It makes code more convoluted than necessary (a higher level dsiguise) Or should we rewrite most of SequenceableCollection protocol? 2017-11-10 2:55 GMT+01:00 Chris Muller <[hidden email]>: +1. #streamContents: is a high-level message. |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
> On 10.11.2017, at 08:00, Nicolas Cellier <[hidden email]> wrote: > > But old implementation was a to:do: loop on indices with (self tempAt: i) > So we already pay the price of low level procedural style, > why having to pay the stream overhead? > It makes code more convoluted than necessary (a higher level dsiguise) > > Or should we rewrite most of SequenceableCollection protocol? > I don't get it. Best regards -Tobias > 2017-11-10 2:55 GMT+01:00 Chris Muller <[hidden email]>: > +1. #streamContents: is a high-level message. > > Eliot is a master of C programming, I guess we all see our own style > as less baroque. I generally try to retain original authors' style > and formatting as much as possible unless I'm making significant > changes to the method. I would never only replace someone's > formatting or style with my own. > > > On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <[hidden email]> wrote: > > > >> On 08.11.2017, at 02:11, [hidden email] wrote: > >> > >> Eliot Miranda uploaded a new version of Kernel to project The Trunk: > >> http://source.squeak.org/trunk/Kernel-eem.1117.mcz > >> > >> ==================== Summary ==================== > >> > >> Name: Kernel-eem.1117 > >> Author: eem > >> Time: 7 November 2017, 5:11:32.043344 pm > >> UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b > >> Ancestors: Kernel-tpr.1116 > >> > >> Use a slightly less baroque implemetation for Context>>arguments, equivalent to Pharo's. > >> > > > > What is baroque about that? > > I'd prefer the other stile any time. > > I especially find the assignment in the "computation" of the argument ugly (the n assignment) and potentially confusing. > > > > I'm a bit puzzled you prefer the style you just put there to the streaming constructor… > > > > Best regards > > -Tobias > > > >> =============== Diff against Kernel-tpr.1116 =============== > >> > >> Item was changed: > >> ----- Method: Context>>arguments (in category 'accessing') ----- > >> arguments > >> + "Answer the receiver's arguments as an Array. > >> + We could use simply ^(1 to: self numArgs) collect: [:i| self tempAt: i] > >> + but for performance and minimality we use the implementation below." > >> + | n args | > >> + args := Array new: (n := self numArgs). > >> + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. > >> + ^args! > >> - > >> - ^ Array new: self numArgs streamContents: [:args | > >> - 1 to: self numArgs do: [: i | > >> - args nextPut: (self tempAt: i)]]! > >> > >> > > > > > > > |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
2017-11-10 10:53 GMT+01:00 Tobias Pape <[hidden email]>:
Hi Tobias, I say that the main interest of stream is to release you from direct index manipulation which are considered as lower level implementation details The code below is just doing a copy. It was done with low level index iteration on one side for reading, and invoking higher level stream on the other side for writing, despite the fact that the low level indices would perfectly match... We are thus complexifying the code un-necessarily by using two concepts where a single one would have been enough. Incidentally, code was less efficient, but I don't know if we ever have to care (maybe Eliot cares for VM simulation). So that's why I call this a higher level disguise: it's fake since we continue manipulating low level indices. SequenceableCollection if full of those low level iterations on indices, but there it's mainly for the sake of speed/efficiency. If we have to conceptualize every 4 liners like that, Squeak is really going to be conservative ;)
|
Re: The Trunk: Kernel-eem.1117.mcz
|
|
On 11/10/17, Nicolas Cellier <[hidden email]> wrote:
> 2017-11-10 10:53 GMT+01:00 Tobias Pape <[hidden email]>: > >> >> > On 10.11.2017, at 08:00, Nicolas Cellier <nicolas.cellier.aka.nice@ >> gmail.com> wrote: >> > >> > But old implementation was a to:do: loop on indices with (self tempAt: >> > i) >> > So we already pay the price of low level procedural style, >> > why having to pay the stream overhead? >> > It makes code more convoluted than necessary (a higher level dsiguise) >> > >> > Or should we rewrite most of SequenceableCollection protocol? >> > >> >> I don't get it. >> >> Best regards >> -Tobias >> >> > Hi Tobias, > I say that the main interest of stream is to release you from direct index > manipulation > which are considered as lower level implementation details > > The code below is just doing a copy. > It was done with low level index iteration on one side for reading, > and invoking higher level stream on the other side for writing, > despite the fact that the low level indices would perfectly match... > > We are thus complexifying the code un-necessarily by using two concepts > where a single one would have been enough. > Incidentally, code was less efficient, but I don't know if we ever have to > care (maybe Eliot cares for VM simulation). > > So that's why I call this a higher level disguise: it's fake since we > continue manipulating low level indices. > > SequenceableCollection if full of those low level iterations on indices, > but there it's mainly for the sake of speed/efficiency. > > If we have to conceptualize every 4 liners like that, Squeak is really > going to be conservative ;) But it means as well that the code is well documented ... 1. At least in the mailing list here = a traceable record of development history a.k.a. developer journal. 2. and hopefully also elsewhere such as in method and class comments. and this results ... In code reviewed in such a way will also be of very good quality (peer - reviewed !!) :-) > >> 2017-11-10 2:55 GMT+01:00 Chris Muller <[hidden email]>: >> > +1. #streamContents: is a high-level message. >> > >> > Eliot is a master of C programming, I guess we all see our own style >> > as less baroque. I generally try to retain original authors' style >> > and formatting as much as possible unless I'm making significant >> > changes to the method. I would never only replace someone's >> > formatting or style with my own. >> > >> > >> > On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <[hidden email]> wrote: >> > > >> > >> On 08.11.2017, at 02:11, [hidden email] wrote: >> > >> >> > >> Eliot Miranda uploaded a new version of Kernel to project The Trunk: >> > >> http://source.squeak.org/trunk/Kernel-eem.1117.mcz >> > >> >> > >> ==================== Summary ==================== >> > >> >> > >> Name: Kernel-eem.1117 >> > >> Author: eem >> > >> Time: 7 November 2017, 5:11:32.043344 pm >> > >> UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b >> > >> Ancestors: Kernel-tpr.1116 >> > >> >> > >> Use a slightly less baroque implemetation for Context>>arguments, >> equivalent to Pharo's. >> > >> >> > > >> > > What is baroque about that? >> > > I'd prefer the other stile any time. >> > > I especially find the assignment in the "computation" of the argument >> ugly (the n assignment) and potentially confusing. >> > > >> > > I'm a bit puzzled you prefer the style you just put there to the >> streaming constructor… >> > > >> > > Best regards >> > > -Tobias >> > > >> > >> =============== Diff against Kernel-tpr.1116 =============== >> > >> >> > >> Item was changed: >> > >> ----- Method: Context>>arguments (in category 'accessing') ----- >> > >> arguments >> > >> + "Answer the receiver's arguments as an Array. >> > >> + We could use simply ^(1 to: self numArgs) collect: [:i| self >> tempAt: i] >> > >> + but for performance and minimality we use the implementation >> below." >> > >> + | n args | >> > >> + args := Array new: (n := self numArgs). >> > >> + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. >> > >> + ^args! >> > >> - >> > >> - ^ Array new: self numArgs streamContents: [:args | >> > >> - 1 to: self numArgs do: [: i | >> > >> - args nextPut: (self tempAt: i)]]! >> > >> >> > >> >> > > >> > > >> > >> > >> > >> >> >> > |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
In reply to this post by Nicolas Cellier
+1 The streamContents: variant is both inefficient and inelegant. Eliot's version is inelegant too, but efficient. This one would be elegant but inefficient, as mentioned in Eliot's comment: arguments ^(1 to: self numArgs) collect: [:i | self tempAt: i] If we wanted it to be elegant and efficient, we would have to write it like arguments ^1 to: self numArgs collect: [:i | self tempAt: i] ... and expand to:collect: in the Compiler just like #to:do: is expanded. I have wished for a to:collect: method numerous times, maybe we do actually want this? - Bert - |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
> On 10-11-2017, at 8:36 AM, Bert Freudenberg <[hidden email]> wrote: > > > I have wished for a to:collect: method numerous times, maybe we do actually want this? > If only we had made a method for adding code to the system… how could we have forgotten to do that? ;-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Don't sweat petty things....or pet sweaty things. |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
In reply to this post by Nicolas Cellier
I get what you're saying. It's not _necessary_ to introduce any
streaming concepts into this. Very good point. On Fri, Nov 10, 2017 at 1:00 AM, Nicolas Cellier <[hidden email]> wrote: > But old implementation was a to:do: loop on indices with (self tempAt: i) > So we already pay the price of low level procedural style, > why having to pay the stream overhead? > It makes code more convoluted than necessary (a higher level dsiguise) > > Or should we rewrite most of SequenceableCollection protocol? > > 2017-11-10 2:55 GMT+01:00 Chris Muller <[hidden email]>: >> >> +1. #streamContents: is a high-level message. >> >> Eliot is a master of C programming, I guess we all see our own style >> as less baroque. I generally try to retain original authors' style >> and formatting as much as possible unless I'm making significant >> changes to the method. I would never only replace someone's >> formatting or style with my own. >> >> >> On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <[hidden email]> wrote: >> > >> >> On 08.11.2017, at 02:11, [hidden email] wrote: >> >> >> >> Eliot Miranda uploaded a new version of Kernel to project The Trunk: >> >> http://source.squeak.org/trunk/Kernel-eem.1117.mcz >> >> >> >> ==================== Summary ==================== >> >> >> >> Name: Kernel-eem.1117 >> >> Author: eem >> >> Time: 7 November 2017, 5:11:32.043344 pm >> >> UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b >> >> Ancestors: Kernel-tpr.1116 >> >> >> >> Use a slightly less baroque implemetation for Context>>arguments, >> >> equivalent to Pharo's. >> >> >> > >> > What is baroque about that? >> > I'd prefer the other stile any time. >> > I especially find the assignment in the "computation" of the argument >> > ugly (the n assignment) and potentially confusing. >> > >> > I'm a bit puzzled you prefer the style you just put there to the >> > streaming constructor… >> > >> > Best regards >> > -Tobias >> > >> >> =============== Diff against Kernel-tpr.1116 =============== >> >> >> >> Item was changed: >> >> ----- Method: Context>>arguments (in category 'accessing') ----- >> >> arguments >> >> + "Answer the receiver's arguments as an Array. >> >> + We could use simply ^(1 to: self numArgs) collect: [:i| self >> >> tempAt: i] >> >> + but for performance and minimality we use the implementation >> >> below." >> >> + | n args | >> >> + args := Array new: (n := self numArgs). >> >> + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. >> >> + ^args! >> >> - >> >> - ^ Array new: self numArgs streamContents: [:args | >> >> - 1 to: self numArgs do: [: i | >> >> - args nextPut: (self tempAt: i)]]! >> >> >> >> >> > >> > >> > > > > |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
Interestingly, the streaming thing is more natural to me here than the make-array-and-put.
Some people I asked agree, some don't. Seemed to correlate with age, tho… ;P Best regards -Tobias > On 11.11.2017, at 02:31, Chris Muller <[hidden email]> wrote: > > I get what you're saying. It's not _necessary_ to introduce any > streaming concepts into this. Very good point. > > On Fri, Nov 10, 2017 at 1:00 AM, Nicolas Cellier > <[hidden email]> wrote: >> But old implementation was a to:do: loop on indices with (self tempAt: i) >> So we already pay the price of low level procedural style, >> why having to pay the stream overhead? >> It makes code more convoluted than necessary (a higher level dsiguise) >> >> Or should we rewrite most of SequenceableCollection protocol? >> >> 2017-11-10 2:55 GMT+01:00 Chris Muller <[hidden email]>: >>> >>> +1. #streamContents: is a high-level message. >>> >>> Eliot is a master of C programming, I guess we all see our own style >>> as less baroque. I generally try to retain original authors' style >>> and formatting as much as possible unless I'm making significant >>> changes to the method. I would never only replace someone's >>> formatting or style with my own. >>> >>> >>> On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <[hidden email]> wrote: >>>> >>>>> On 08.11.2017, at 02:11, [hidden email] wrote: >>>>> >>>>> Eliot Miranda uploaded a new version of Kernel to project The Trunk: >>>>> http://source.squeak.org/trunk/Kernel-eem.1117.mcz >>>>> >>>>> ==================== Summary ==================== >>>>> >>>>> Name: Kernel-eem.1117 >>>>> Author: eem >>>>> Time: 7 November 2017, 5:11:32.043344 pm >>>>> UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b >>>>> Ancestors: Kernel-tpr.1116 >>>>> >>>>> Use a slightly less baroque implemetation for Context>>arguments, >>>>> equivalent to Pharo's. >>>>> >>>> >>>> What is baroque about that? >>>> I'd prefer the other stile any time. >>>> I especially find the assignment in the "computation" of the argument >>>> ugly (the n assignment) and potentially confusing. >>>> >>>> I'm a bit puzzled you prefer the style you just put there to the >>>> streaming constructor… >>>> >>>> Best regards >>>> -Tobias >>>> >>>>> =============== Diff against Kernel-tpr.1116 =============== >>>>> >>>>> Item was changed: >>>>> ----- Method: Context>>arguments (in category 'accessing') ----- >>>>> arguments >>>>> + "Answer the receiver's arguments as an Array. >>>>> + We could use simply ^(1 to: self numArgs) collect: [:i| self >>>>> tempAt: i] >>>>> + but for performance and minimality we use the implementation >>>>> below." >>>>> + | n args | >>>>> + args := Array new: (n := self numArgs). >>>>> + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. >>>>> + ^args! >>>>> - >>>>> - ^ Array new: self numArgs streamContents: [:args | >>>>> - 1 to: self numArgs do: [: i | >>>>> - args nextPut: (self tempAt: i)]]! >>>>> >>>>> >>>> >>>> >>> >> >> >> >> > |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
> On 11.11.2017, at 08:59, Tobias Pape <[hidden email]> wrote: > > Interestingly, the streaming thing is more natural to me here than the make-array-and-put. > Some people I asked agree, some don't. Seemed to correlate with age, tho… ;P Should have said "correlate with what people where exposed first to", sorry > Best regards > -Tobias > >> On 11.11.2017, at 02:31, Chris Muller <[hidden email]> wrote: >> >> I get what you're saying. It's not _necessary_ to introduce any >> streaming concepts into this. Very good point. >> >> On Fri, Nov 10, 2017 at 1:00 AM, Nicolas Cellier >> <[hidden email]> wrote: >>> But old implementation was a to:do: loop on indices with (self tempAt: i) >>> So we already pay the price of low level procedural style, >>> why having to pay the stream overhead? >>> It makes code more convoluted than necessary (a higher level dsiguise) >>> >>> Or should we rewrite most of SequenceableCollection protocol? >>> >>> 2017-11-10 2:55 GMT+01:00 Chris Muller <[hidden email]>: >>>> >>>> +1. #streamContents: is a high-level message. >>>> >>>> Eliot is a master of C programming, I guess we all see our own style >>>> as less baroque. I generally try to retain original authors' style >>>> and formatting as much as possible unless I'm making significant >>>> changes to the method. I would never only replace someone's >>>> formatting or style with my own. >>>> >>>> >>>> On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <[hidden email]> wrote: >>>>> >>>>>> On 08.11.2017, at 02:11, [hidden email] wrote: >>>>>> >>>>>> Eliot Miranda uploaded a new version of Kernel to project The Trunk: >>>>>> http://source.squeak.org/trunk/Kernel-eem.1117.mcz >>>>>> >>>>>> ==================== Summary ==================== >>>>>> >>>>>> Name: Kernel-eem.1117 >>>>>> Author: eem >>>>>> Time: 7 November 2017, 5:11:32.043344 pm >>>>>> UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b >>>>>> Ancestors: Kernel-tpr.1116 >>>>>> >>>>>> Use a slightly less baroque implemetation for Context>>arguments, >>>>>> equivalent to Pharo's. >>>>>> >>>>> >>>>> What is baroque about that? >>>>> I'd prefer the other stile any time. >>>>> I especially find the assignment in the "computation" of the argument >>>>> ugly (the n assignment) and potentially confusing. >>>>> >>>>> I'm a bit puzzled you prefer the style you just put there to the >>>>> streaming constructor… >>>>> >>>>> Best regards >>>>> -Tobias >>>>> >>>>>> =============== Diff against Kernel-tpr.1116 =============== >>>>>> >>>>>> Item was changed: >>>>>> ----- Method: Context>>arguments (in category 'accessing') ----- >>>>>> arguments >>>>>> + "Answer the receiver's arguments as an Array. >>>>>> + We could use simply ^(1 to: self numArgs) collect: [:i| self >>>>>> tempAt: i] >>>>>> + but for performance and minimality we use the implementation >>>>>> below." >>>>>> + | n args | >>>>>> + args := Array new: (n := self numArgs). >>>>>> + 1 to: n do: [:i| args at: i put: (self tempAt: i)]. >>>>>> + ^args! >>>>>> - >>>>>> - ^ Array new: self numArgs streamContents: [:args | >>>>>> - 1 to: self numArgs do: [: i | >>>>>> - args nextPut: (self tempAt: i)]]! >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >> > > |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
2017-11-11 9:24 GMT+01:00 Tobias Pape <[hidden email]>:
:) Logically, punching cards should help developping a taste for an economy. Unfortunately, it was just an economy of punch... Maybe that's why we like those short words, to:, do:, at:
|
Re: The Trunk: Kernel-eem.1117.mcz
|
|
On Sat, Nov 11, 2017 at 10:23:49AM +0100, Nicolas Cellier wrote:
> 2017-11-11 9:24 GMT+01:00 Tobias Pape <[hidden email]>: > > > > > > On 11.11.2017, at 08:59, Tobias Pape <[hidden email]> wrote: > > > > > > Interestingly, the streaming thing is more natural to me here than the > > make-array-and-put. > > > Some people I asked agree, some don't. Seemed to correlate with age, > > tho??? ;P I also find the streaming thing more natural, despite my advanced years and early exposure to fortran and C. But ultimately I am convinced by Nicolas' explanation. > > > > Should have said "correlate with what people where exposed first to", sorry > > > > > :) > Logically, punching cards should help developping a taste for an economy. > Unfortunately, it was just an economy of punch... > Maybe that's why we like those short words, to:, do:, at: > This prompts me to remind everyone to load Bob Arning's excellent PunchdCard morph from SqueakMap or http://www.squeaksource.com/PunchedCards. Every modern image should have this. But I am dismayed to see that bit rot has set in recently, and I can no longer punch holes in the cards by clicking the mouse over the card columns, so this needs fixing. No complaints though, the real card punches back in the day required preventive maintenance, and it was not uncommon for them to just stop punching properly. So I guess that an occasional malfunction is to be expected for the PunchedCard morph, especially since I have not been keeping up with its preventive schedule on new Squeak releases. Dave |
Re: The Trunk: Kernel-eem.1117.mcz
|
|
On Sat, Nov 11, 2017 at 10:16:54AM -0500, David T. Lewis wrote:
> On Sat, Nov 11, 2017 at 10:23:49AM +0100, Nicolas Cellier wrote: > > 2017-11-11 9:24 GMT+01:00 Tobias Pape <[hidden email]>: > > > > > > > > > On 11.11.2017, at 08:59, Tobias Pape <[hidden email]> wrote: > > > > > > > > Interestingly, the streaming thing is more natural to me here than the > > > make-array-and-put. > > > > Some people I asked agree, some don't. Seemed to correlate with age, > > > tho??? ;P > > I also find the streaming thing more natural, despite my advanced years and > early exposure to fortran and C. > > But ultimately I am convinced by Nicolas' explanation. > > > > > > > Should have said "correlate with what people where exposed first to", sorry > > > > > > > > :) > > Logically, punching cards should help developping a taste for an economy. > > Unfortunately, it was just an economy of punch... > > Maybe that's why we like those short words, to:, do:, at: > > > > This prompts me to remind everyone to load Bob Arning's excellent PunchdCard > morph from SqueakMap or http://www.squeaksource.com/PunchedCards. Every > modern image should have this. But I am dismayed to see that bit rot has > set in recently, and I can no longer punch holes in the cards by clicking > the mouse over the card columns, so this needs fixing. > > No complaints though, the real card punches back in the day required > preventive maintenance, and it was not uncommon for them to just stop > punching properly. So I guess that an occasional malfunction is to be > expected for the PunchedCard morph, especially since I have not been > keeping up with its preventive schedule on new Squeak releases. Oh dear, the error was entirely in my own failing memory cells. The punched card responds only to key events, not any mouse events. Aside from needing some minor font tweaks, it is working fine despite my lack of attention to its preventive maintenance schedule. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |