The Trunk: Kernel-eem.1117.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Kernel-eem.1117.mcz

commits-2
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)]]!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Tobias Pape

> 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)]]!
>
>


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Chris Muller-3
+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)]]!
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Nicolas Cellier
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)]]!
>>
>>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Tobias Pape

> 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)]]!
> >>
> >>
> >
> >
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Nicolas Cellier


2017-11-10 10:53 GMT+01:00 Tobias Pape <[hidden email]>:

> 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


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 ;)

> 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)]]!
> >>
> >>
> >
> >
>
>
>





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Hannes Hirzel
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)]]!
>> > >>
>> > >>
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Bert Freudenberg
In reply to this post by Nicolas Cellier
On Fri, Nov 10, 2017 at 11:44 AM, 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 <[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


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.

​+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 -​


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

timrowledge

> 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.



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Chris Muller-3
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)]]!
>> >>
>> >>
>> >
>> >
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Tobias Pape
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)]]!
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Tobias Pape

> 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)]]!
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

Nicolas Cellier


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

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:


> 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)]]!
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-eem.1117.mcz

David T. Lewis
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