The Trunk: Kernel-ct.1368.mcz

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

The Trunk: Kernel-ct.1368.mcz

commits-2
David T. Lewis uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-ct.1368.mcz

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

Name: Kernel-ct.1368
Author: ct
Time: 24 January 2021, 3:19:48.003384 pm
UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd
Ancestors: Kernel-mt.1364

Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios.

=============== Diff against Kernel-mt.1364 ===============

Item was changed:
  ----- Method: Process>>longPrintOn: (in category 'printing') -----
  longPrintOn: stream
 
  | ctxt |
  super printOn: stream.
+ stream
+ nextPut: $(;
+ nextPutAll: self name;
+ nextPut: $).
  stream cr.
  ctxt := self suspendedContext.
  [ctxt == nil] whileFalse: [
  stream space.
  ctxt printOn: stream.
  stream cr.
  ctxt := ctxt sender.
  ].
  !

Item was changed:
  ----- Method: Process>>printOn: (in category 'printing') -----
  printOn: aStream
 
  super printOn: aStream.
+ aStream
+ nextPut: $(;
+ nextPutAll: self name;
+ nextPut: $).
  aStream nextPutAll: ' in '.
  suspendedContext printOn: aStream!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

Eliot Miranda-2
I disagree with this.  Only certain processes are named.  Including the destiny name of unnamed processes just introduces noise.  By all means include the name of named processes, but please *don’t* add verbosity where it is unhelpful.

_,,,^..^,,,_ (phone)

> On Feb 12, 2021, at 3:34 PM, [hidden email] wrote:
>
> David T. Lewis uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-ct.1368.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-ct.1368
> Author: ct
> Time: 24 January 2021, 3:19:48.003384 pm
> UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd
> Ancestors: Kernel-mt.1364
>
> Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios.
>
> =============== Diff against Kernel-mt.1364 ===============
>
> Item was changed:
>  ----- Method: Process>>longPrintOn: (in category 'printing') -----
>  longPrintOn: stream
>
>      | ctxt |
>      super printOn: stream.
> +    stream
> +        nextPut: $(;
> +        nextPutAll: self name;
> +        nextPut: $).
>      stream cr.
>      ctxt := self suspendedContext.
>      [ctxt == nil] whileFalse: [
>          stream space.
>          ctxt printOn: stream.
>          stream cr.
>          ctxt := ctxt sender.
>      ].
>  !
>
> Item was changed:
>  ----- Method: Process>>printOn: (in category 'printing') -----
>  printOn: aStream
>
>      super printOn: aStream.
> +    aStream
> +        nextPut: $(;
> +        nextPutAll: self name;
> +        nextPut: $).
>      aStream nextPutAll: ' in '.
>      suspendedContext printOn: aStream!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

Christoph Thiede

Hi Eliot,


we already discussed this below my inbox proposal, but I still think that "destiny name of unnamed processed" is more than noise. It is still helpful to compare the identities of two process instances by taking a short look at their print strings ...


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Samstag, 13. Februar 2021 17:59:54
An: [hidden email]
Betreff: Re: [squeak-dev] The Trunk: Kernel-ct.1368.mcz
 
I disagree with this.  Only certain processes are named.  Including the destiny name of unnamed processes just introduces noise.  By all means include the name of named processes, but please *don’t* add verbosity where it is unhelpful.

_,,,^..^,,,_ (phone)

> On Feb 12, 2021, at 3:34 PM, [hidden email] wrote:
>
> David T. Lewis uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-ct.1368.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-ct.1368
> Author: ct
> Time: 24 January 2021, 3:19:48.003384 pm
> UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd
> Ancestors: Kernel-mt.1364
>
> Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios.
>
> =============== Diff against Kernel-mt.1364 ===============
>
> Item was changed:
>  ----- Method: Process>>longPrintOn: (in category 'printing') -----
>  longPrintOn: stream
>
>      | ctxt |
>      super printOn: stream.
> +    stream
> +        nextPut: $(;
> +        nextPutAll: self name;
> +        nextPut: $).
>      stream cr.
>      ctxt := self suspendedContext.
>      [ctxt == nil] whileFalse: [
>          stream space.
>          ctxt printOn: stream.
>          stream cr.
>          ctxt := ctxt sender.
>      ].
>  !
>
> Item was changed:
>  ----- Method: Process>>printOn: (in category 'printing') -----
>  printOn: aStream
>
>      super printOn: aStream.
> +    aStream
> +        nextPut: $(;
> +        nextPutAll: self name;
> +        nextPut: $).
>      aStream nextPutAll: ' in '.
>      suspendedContext printOn: aStream!
>
>



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

David T. Lewis
In reply to this post by Eliot Miranda-2
I'll revert if it is not a good thing to do.

To me it seems both useful and harmless.

Dave

On Sat, Feb 13, 2021 at 08:59:54AM -0800, Eliot Miranda wrote:

> I disagree with this.  Only certain processes are named.  Including the destiny name of unnamed processes just introduces noise.  By all means include the name of named processes, but please *don???t* add verbosity where it is unhelpful.
>
> _,,,^..^,,,_ (phone)
>
> > On Feb 12, 2021, at 3:34 PM, [hidden email] wrote:
> >
> > ???David T. Lewis uploaded a new version of Kernel to project The Trunk:
> > http://source.squeak.org/trunk/Kernel-ct.1368.mcz
> >
> > ==================== Summary ====================
> >
> > Name: Kernel-ct.1368
> > Author: ct
> > Time: 24 January 2021, 3:19:48.003384 pm
> > UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd
> > Ancestors: Kernel-mt.1364
> >
> > Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios.
> >
> > =============== Diff against Kernel-mt.1364 ===============
> >
> > Item was changed:
> >  ----- Method: Process>>longPrintOn: (in category 'printing') -----
> >  longPrintOn: stream
> >
> >      | ctxt |
> >      super printOn: stream.
> > +    stream
> > +        nextPut: $(;
> > +        nextPutAll: self name;
> > +        nextPut: $).
> >      stream cr.
> >      ctxt := self suspendedContext.
> >      [ctxt == nil] whileFalse: [
> >          stream space.
> >          ctxt printOn: stream.
> >          stream cr.
> >          ctxt := ctxt sender.
> >      ].
> >  !
> >
> > Item was changed:
> >  ----- Method: Process>>printOn: (in category 'printing') -----
> >  printOn: aStream
> >
> >      super printOn: aStream.
> > +    aStream
> > +        nextPut: $(;
> > +        nextPutAll: self name;
> > +        nextPut: $).
> >      aStream nextPutAll: ' in '.
> >      suspendedContext printOn: aStream!
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

Chris Muller-3
In reply to this post by Eliot Miranda-2
On Sat, Feb 13, 2021 at 11:00 AM Eliot Miranda <[hidden email]> wrote:
I disagree with this.  Only certain processes are named.  Including the destiny name of unnamed processes just introduces noise.  By all means include the name of named processes, but please *don’t* add verbosity where it is unhelpful.

+1.  You are so right.  Assigning a *name* for human consumption establishes the intent of the human's desire to utilize its #name as the basis for its consumption.  If specific identity distinction is needed, then set it as part of its name, but we should not include arbitrary attributes in its #printString.  If such additional identity attributes are needed, they should be consumed by sending the appropriate messages from the appropriate places (UI).

In fact, I would recommend taking this concept one step further by, when a name for human consumption is explicitly set, consider it an indication that the "type" (e.g., class), is not really germaine to its #printString, either.  Skip the super call.

Alternatively, the name accessors could be changed to 

    ^ name value

so that a Block could be assigned (e.g., dynamic name).

 - Chris
 


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

David T. Lewis
On Mon, Feb 15, 2021 at 05:01:37PM -0600, Chris Muller wrote:

> On Sat, Feb 13, 2021 at 11:00 AM Eliot Miranda <[hidden email]>
> wrote:
>
> > I disagree with this.  Only certain processes are named.  Including the
> > destiny name of unnamed processes just introduces noise.  By all means
> > include the name of named processes, but please *don???t* add verbosity where
> > it is unhelpful.
> >
>
> +1.  You are so right.  Assigning a *name* for human consumption
> establishes the intent of the human's desire to utilize its #name as the
> basis for its consumption.  If specific identity distinction is
> needed, then set it as part of its name, but we should not include
> arbitrary attributes in its #printString.  If such additional identity
> attributes are needed, they should be consumed by sending the appropriate
> messages from the appropriate places (UI).
>

Eliot and Chris both think that this was a bad idea. I don't understand
the objection, but if no one speaks up in support of it, I will revert
the merge in a day or two.

Dave


> In fact, I would recommend taking this concept one step further by, when a
> name for human consumption is explicitly set, consider it an indication
> that the "type" (e.g., class), is not really germaine to its #printString,
> either.  Skip the super call.
>
> Alternatively, the name accessors could be changed to
>
>     ^ name value
>
> so that a Block could be assigned (e.g., dynamic name).
>
>  - Chris

>


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

Chris Muller-4
Hi Dave, thanks for your efforts in keeping the improvements flowing.  For this, would you please consider Kernel-cmm.1370 (or an improved version of it based on your and others' review), instead of merely reverting Christoph's version to the prior state?  Eliot and I both expressed that the name is a good thing for the #printString, when it's set.  This is an attempt to capture the intent of Christoph's idea, which was good.

Thanks,
  Chris


On Mon, Feb 15, 2021 at 5:39 PM David T. Lewis <[hidden email]> wrote:
On Mon, Feb 15, 2021 at 05:01:37PM -0600, Chris Muller wrote:
> On Sat, Feb 13, 2021 at 11:00 AM Eliot Miranda <[hidden email]>
> wrote:
>
> > I disagree with this.  Only certain processes are named.  Including the
> > destiny name of unnamed processes just introduces noise.  By all means
> > include the name of named processes, but please *don???t* add verbosity where
> > it is unhelpful.
> >
>
> +1.  You are so right.  Assigning a *name* for human consumption
> establishes the intent of the human's desire to utilize its #name as the
> basis for its consumption.  If specific identity distinction is
> needed, then set it as part of its name, but we should not include
> arbitrary attributes in its #printString.  If such additional identity
> attributes are needed, they should be consumed by sending the appropriate
> messages from the appropriate places (UI).
>

Eliot and Chris both think that this was a bad idea. I don't understand
the objection, but if no one speaks up in support of it, I will revert
the merge in a day or two.

Dave


> In fact, I would recommend taking this concept one step further by, when a
> name for human consumption is explicitly set, consider it an indication
> that the "type" (e.g., class), is not really germaine to its #printString,
> either.  Skip the super call.
>
> Alternatively, the name accessors could be changed to
>
>     ^ name value
>
> so that a Block could be assigned (e.g., dynamic name).
>
>  - Chris

>



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

Tobias Pape
In reply to this post by David T. Lewis
Hi

> On 16. Feb 2021, at 00:39, David T. Lewis <[hidden email]> wrote:
>
> On Mon, Feb 15, 2021 at 05:01:37PM -0600, Chris Muller wrote:
>> On Sat, Feb 13, 2021 at 11:00 AM Eliot Miranda <[hidden email]>
>> wrote:
>>
>>> I disagree with this.  Only certain processes are named.  Including the
>>> destiny name of unnamed processes just introduces noise.  By all means
>>> include the name of named processes, but please *don???t* add verbosity where
>>> it is unhelpful.
>>>
>>
>> +1.  You are so right.  Assigning a *name* for human consumption
>> establishes the intent of the human's desire to utilize its #name as the
>> basis for its consumption.  If specific identity distinction is
>> needed, then set it as part of its name, but we should not include
>> arbitrary attributes in its #printString.  If such additional identity
>> attributes are needed, they should be consumed by sending the appropriate
>> messages from the appropriate places (UI).
>>
>
> Eliot and Chris both think that this was a bad idea. I don't understand
> the objection, but if no one speaks up in support of it, I will revert
> the merge in a day or two.

I'd like to retain the synthetic name.
It certainly helps people like me who read and write with a voice in their head.

Best
        -Tobias


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

marcel.taeumel
Hmm... this change would certainly be in line with what "Morph new printString" looks like. :-) I recall a not-too-distant discussion about adding the hash to any object's printOn:. 

http://forum.world.st/Object-gt-gt-printOn-refined-td5117573.html

Best,
Marcel

Am 16.02.2021 07:25:32 schrieb Tobias Pape <[hidden email]>:

Hi

> On 16. Feb 2021, at 00:39, David T. Lewis wrote:
>
> On Mon, Feb 15, 2021 at 05:01:37PM -0600, Chris Muller wrote:
>> On Sat, Feb 13, 2021 at 11:00 AM Eliot Miranda
>> wrote:
>>
>>> I disagree with this. Only certain processes are named. Including the
>>> destiny name of unnamed processes just introduces noise. By all means
>>> include the name of named processes, but please *don???t* add verbosity where
>>> it is unhelpful.
>>>
>>
>> +1. You are so right. Assigning a *name* for human consumption
>> establishes the intent of the human's desire to utilize its #name as the
>> basis for its consumption. If specific identity distinction is
>> needed, then set it as part of its name, but we should not include
>> arbitrary attributes in its #printString. If such additional identity
>> attributes are needed, they should be consumed by sending the appropriate
>> messages from the appropriate places (UI).
>>
>
> Eliot and Chris both think that this was a bad idea. I don't understand
> the objection, but if no one speaks up in support of it, I will revert
> the merge in a day or two.

I'd like to retain the synthetic name.
It certainly helps people like me who read and write with a voice in their head.

Best
-Tobias




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

Eliot Miranda-2
Hi All,

   one thing people may be missing here is that identity hashes are not unique.  Just because two objects have the same identity hash does not imply they are the same object.  In V3 the identityHash field is 11 bits and identity hash’s range from 0 to 2,047. In Spur the identityHash field is 22 bits and identity hash’s range from 1 to 4,194,303. With the 64-bit system one can easily create 4 million instances of some class and in doing so create two distinct objects with the same identityHash.  Including the identityHash in basic print strings, at least for me, carries a false implication that the identityHash uniquely identifies an object.  It does not.

_,,,^..^,,,_ (phone)

On Feb 16, 2021, at 3:58 AM, Marcel Taeumel <[hidden email]> wrote:


Hmm... this change would certainly be in line with what "Morph new printString" looks like. :-) I recall a not-too-distant discussion about adding the hash to any object's printOn:. 

http://forum.world.st/Object-gt-gt-printOn-refined-td5117573.html

Best,
Marcel

Am 16.02.2021 07:25:32 schrieb Tobias Pape <[hidden email]>:

Hi

> On 16. Feb 2021, at 00:39, David T. Lewis wrote:
>
> On Mon, Feb 15, 2021 at 05:01:37PM -0600, Chris Muller wrote:
>> On Sat, Feb 13, 2021 at 11:00 AM Eliot Miranda
>> wrote:
>>
>>> I disagree with this. Only certain processes are named. Including the
>>> destiny name of unnamed processes just introduces noise. By all means
>>> include the name of named processes, but please *don???t* add verbosity where
>>> it is unhelpful.
>>>
>>
>> +1. You are so right. Assigning a *name* for human consumption
>> establishes the intent of the human's desire to utilize its #name as the
>> basis for its consumption. If specific identity distinction is
>> needed, then set it as part of its name, but we should not include
>> arbitrary attributes in its #printString. If such additional identity
>> attributes are needed, they should be consumed by sending the appropriate
>> messages from the appropriate places (UI).
>>
>
> Eliot and Chris both think that this was a bad idea. I don't understand
> the objection, but if no one speaks up in support of it, I will revert
> the merge in a day or two.

I'd like to retain the synthetic name.
It certainly helps people like me who read and write with a voice in their head.

Best
-Tobias





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-ct.1368.mcz

Tobias Pape


> On 16. Feb 2021, at 18:52, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
>    one thing people may be missing here is that identity hashes are not unique.  Just because two objects have the same identity hash does not imply they are the same object.  In V3 the identityHash field is 11 bits and identity hash’s range from 0 to 2,047. In Spur the identityHash field is 22 bits and identity hash’s range from 1 to 4,194,303. With the 64-bit system one can easily create 4 million instances of some class and in doing so create two distinct objects with the same identityHash.  Including the identityHash in basic print strings, at least for me, carries a false implication that the identityHash uniquely identifies an object.  It does not.

It's merely about having a few of them processes and having a quick glance on them and discerning them without much effort.
The code by Christoph provides that and helps.
Let's keep it that way.

-t