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

http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Samstag, 13. Februar 2021 17:59:54 An: squeak-dev@lists.squeakfoundation.org 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, commits@source.squeak.org 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!

On Sat, Feb 13, 2021 at 11:00 AM Eliot Miranda eliot.miranda@gmail.com 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

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 lewis@mail.msen.com 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 eliot.miranda@gmail.com 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

...

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 das.linux@gmx.de: 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

On 16. Feb 2021, at 18:52, Eliot Miranda eliot.miranda@gmail.com 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