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! |
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! > > |
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!
|
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! > > > > > |
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 |
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 > |
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: |
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 |
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
|
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:
|
> 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 |
Free forum by Nabble | Edit this page |