Squeak-dev March 2024

squeak-dev@lists.squeakfoundation.org

27 participants
58 discussions

Squeak Oversight Board Election 2024
by Patrick R 10 Mar '24

10 Mar '24

Hi All, It's that time again to raise your voices and elect your leaders! Can you believe it's been over a year and one day already? It's a time for you to stand up, help your community and volunteer to serve! Squeak wants you! Every year we elect the SOB (Squeak Oversight Board) consisting of seven members from our community. The current board members are: 1. Marcel Taeumel 2. Tim Rowledge 3. Craig Latta 4. David T. Lewis 5. Jakob Reschke 6. Bruce O'Neel 7. Benoit St-Jean For more info on the board please see: https://squeak.org/board/#the-mission Everything about the election, including schedule and more, is tracked here: http://wiki.squeak.org/squeak/6665 Now until Friday 25th of February 2024, 18.00 UTC: Nominations of SOB members and campaigning! Candidates should nominate themselves and start their campaign on the squeak-dev mailing list. Or if you nominate someone else, make sure that person really wants to run. :) I will not put anyone on the candidate list until that person makes it known on squeak-dev that he/she intends to run. During this period, the candidates should ideally present themselves on squeak-dev, unless they have already done so, and the community can ask questions. I encourage you to reach out to potential candidates, people that are active in the community and represent your views, and ask them to run. Some people will not run without encouragement. Also, I know that some people wait to the last minute to run for the board to see if others will run but please consider getting this year off to a faster start and just jump right in! The schedule and process are as follows: Now until Friday 25th of February 2024, 18.00 UTC: Nominations of SOB members and campaigning! Friday 25th of February 2024, 18.00 UTC: Candidate list is finalized. Friday 25th of February 2024, 19.00 UTC: Online election starts. Friday 11th of March 2024, 19.00 UTC: Online election ends. Results will be announced immediately after the election ends. The voting period is two weeks long and ballots are sent out via email. And how do you end up on the voter list? See below. :) IMPORTANT: New voters will NOT be added once the election is started. You MUST try to get on the voter list before the 25th of February 2024 or you will NOT be able to vote. If your Email has changed please try to make sure it is changed on the list of voters before the election starts. -------------------------- If you were invited to vote last year you are already on the voter list, no worries! If you are a new Squeaker and wish to vote you should do ONE of the following: * Get a "known" Squeaker to vouch for you. If a known Squeaker sends an email to voters (at) squeak.org giving me a name and email for you, then I will add you. * Send an email to voters (at) squeak.org yourself (and CC to squeak-dev if you like) with information/arguments showing me that you are indeed serious about voting and that you are indeed a Squeaker. When the voting period starts all voters will receive an email with instructions and a link to the voting website. If there are any further questions, just reply *in this thread* and I will closely track it - or send email to voters (at) squeak.org which points to me. ...so let's get on with it! All the best, Patrick

11 16

Zurich Smalltalk Meetup 26 April
by Bruce O'Neel 07 Mar '24

07 Mar '24

Hi, For those of you who can travel to Zurich easily there is a meetup on 26 April. My memories of the summaries from past examples is that it is Pharo focused. Smalltalk-Meetup in Zürich, April 26th, 2024 – Joachims Small World (wordpress.com) [https://joachimtuchel.wordpress.com/2024/03/05/smalltalk-meetup-in-zurich-a…] cheers bruce

1 0

Alan Kay's talk at UCLA in Feb 2024
by Bruce O'Neel 07 Mar '24

07 Mar '24

Alan Kay's talk at UCLA – Feb 2024 [video] | Hacker News (ycombinator.com) [https://news.ycombinator.com/item?id=39612799]

1 0

An amusing performance result
by Tim Rowledge 06 Mar '24

06 Mar '24

A long time ago there was some work done by DanI to make ITX based boxes for running squeak as part of his Weather Dimensions project/product. These boxes had 533MHz VIA x86 cpus of some sort and back then in 2006 they reported tinyBenchmark results of 17,362,995 bytecodes/sec and 736,717 sends/sec. These days a Pi 5 (2.4GHz ARM64) reports 1,600,000,000 bytecodes/sec and 140,000,000 sends/sec - or 90X and 190X as fast. I think that's quite nice to see. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful random insult:- One clown short of a circus.

3 2

Re: Resuming on BlockCannotReturn exception
by Jaromir Matas 05 Mar '24

05 Mar '24

Hi Eliot, How about to nil the pc just before making the return: ``` Context >> #cannotReturn: result self push: self pc. "backup the pc for the sake of debugging" closureOrNil ifNotNil: [^self cannotReturn: result to: self home sender; pc: nil]. Processor debugWithTitle: 'Computation has been terminated!' translated full: false ``` The nilled pc should not even potentially interfere with the #isDead now. I hope this is at least a step in the right direction :) However, there's still a problem when debugging the resumption of #cannotReturn because the encoders expect a reasonable index. I haven't figured out yet where to place a nil check - #step, #stepToSendOrReturn... ? Thanks again, Jaromir ------ Original Message ------ From "Eliot Miranda" <eliot.miranda(a)gmail.com> To "Jaromir Matas" <mail(a)jaromir.net> Date 11/17/2023 8:36:50 PM Subject Re: [squeak-dev] Re: Resuming on BlockCannotReturn exception >Hi Jaromir, > >>On Nov 17, 2023, at 7:05 AM, Jaromir Matas <mail(a)jaromir.net> wrote: >> >> >>Eliot, hi again, >> >>Please disregard my previous comment about nilling the contexts that >>have returned. We are indeed talking about the context directly under >>the #cannotReturn context which is totally different from the home >>context in another thread that's gone. >> >>I may still be confused but would nilling the pc of the context >>directly under the cannotReturn context help? Here's what I mean: >>``` >>Context >> #cannotReturn: result >> >> closureOrNil ifNotNil: [^self pc: nil; cannotReturn: result to: >>self home sender]. >> Processor debugWithTitle: 'Computation has been terminated!' >>translated full: false. >>``` >>Instead of crashing the VM invokes the debugger with the 'Computation >>has been terminated!' message. >> >>Does this make sense? > >Nearly. But it loses the information on what the pc actually is, and >that’s potentially vital information. So IMO the ox should only be >nilled between the BlockCannotReturn exception being created and >raised. > >[But if you try this don’t be surprised if it causes a few temporary >problems. It looks to me that without a little refactoring this could >easily cause an infinite recursion around the sending of isDead. I’m >sure you’ll be able to fix the code to work correctly] > >>Thanks, >>Jaromir >> >> >>------ Original Message ------ >>From "Jaromir Matas" <mail(a)jaromir.net> >>To "Eliot Miranda" <eliot.miranda(a)gmail.com>; "The general-purpose >>Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org> >>Date 11/17/2023 10:15:17 AM >>Subject [squeak-dev] Re: Resuming on BlockCannotReturn exception >> >>>Hi Eliot, >>> >>> >>> >>>------ Original Message ------ >>>From "Eliot Miranda" <eliot.miranda(a)gmail.com> >>>To "Jaromir Matas" <mail(a)jaromir.net> >>>Cc "The general-purpose Squeak developers list" >>><squeak-dev(a)lists.squeakfoundation.org> >>>Date 11/16/2023 11:52:45 PM >>>Subject Re: Re[2]: [squeak-dev] Re: Resuming on BlockCannotReturn >>>exception >>> >>>>Hi Jaromir, >>>> >>>>On Thu, Nov 16, 2023 at 2:22 PM Jaromir Matas <mail(a)jaromir.net> >>>>wrote: >>>>>Hi Nicolas, Eliot, >>>>> >>>>>here's what I understand is happening (see the enclosed >>>>>screenshot): >>>>> >>>>>1) we fork a new process to evaluate [^1] >>>>>2) the new process evaluates [^1] which means instruction 18 is >>>>>being evaluated, hence pc points to instruction 19 now >>>>>3) however, the home context where ^1 should return to is gone by >>>>>this time (the process that executed the fork has already returned >>>>>- notice the two up arrows in the debugger screenshot) >>>>>4) the VM can't finish the instruction and returns control to the >>>>>image via placing the #cannotReturn: context on top of the [^1] >>>>>context >>>>>5) #cannotReturn: evaluation results in signalling the BCR >>>>>exception which is then handled by the #resume handler >>>>> (in our debugged case the [:ex | self halt. ex resume] handler) >>>>>6) ex resume is evaluated, however, this means requesting the VM to >>>>>evaluate instruction 19 of the [^1] context - which is past the >>>>>last instruction of the context and the crash ensues >>>>> >>>>>I wonder whether such situations could/should be prevented inside >>>>>the VM or whether such an expectation is wrong for some reason. >>>> >>>>As Nicolas says, IMO this is best done at the image level. >>>> >>>>It could be prevented in the VM, but at great cost, and only >>>>partially. The performance issue is that the last bytecode in a >>>>method is not marked in any way, and that to determine the last >>>>bytecode the bytecodes must be symbolically evaluated from the start >>>>of the method. See implementors of endPC at the image level (which >>>>defer to the method trailer) and implementors of endPCOf: in the >>>>VMMaker code. Doing this every time execution commences is >>>>prohibitively expensive. The "only partially" issue is that >>>>following the return instruction may be other valid bytecodes, but >>>>these are not a continuation. >>>> >>>> >>>>Consider the following code in some block: >>>> [self expression ifTrue: >>>> [^1]. >>>> ^2 >>>> >>>>The bytecodes for this are >>>> pushReceiver >>>> send #expression >>>> jumpFalse L1 >>>> push 1 >>>> methodReturnTop >>>>L1 >>>> push 2 >>>> methodReturnTop >>>> >>>>Clearly if expression is true these should be *no* continuation in >>>>which ^2 is executed. >>> >>>Well, in that case there's a bug because the computation in the >>>following example shouldn't continue past the [^1] block but it >>>silently does: >>>`[[true ifTrue: [^ 1]] on: BlockCannotReturn do: #resume ] fork` >>> >>>The bytecodes are >>> push true >>> jumpFalse L1 >>> push 1 >>> returnTop >>>L1 >>> push nil >>> blockReturn >>> >>> >>> >>>> >>>>So even if the VM did try and detect whether the return was at the >>>>last block method, it would only work for special cases. >>>> >>>> >>>>It seems to me the issue is simply that the context that cannot be >>>>returned from should be marked as dead (see Context>>isDead) by >>>>setting its pc to nil at some point, presumably after copying the >>>>actual return pc into the BlockCannotReturn exception, to avoid ever >>>>trying to resume the context. >>> >>>Does this mean, in other words, that every context that returns >>>should nil its pc to avoid being "wrongly" reused/executed in the >>>future, which concerns primarily those being referenced somewhere >>>hence potentially executable in the future, is that right? >>>Hypothetical question: would nilling the pc during returns "fix" the >>>example? >>>Thanks a lot for helping me understand this. >>>Best, >>>Jaromir >>> >>> >>> >>>> >>>> >>>>> >>>>>Thanks, >>>>>Jaromir >>>>> >>>>><bdxuqalu.png> >>>>> >>>>>------ Original Message ------ >>>>>From "Eliot Miranda" <eliot.miranda(a)gmail.com> >>>>>To "Jaromir Matas" <mail(a)jaromir.net>; "The general-purpose Squeak >>>>>developers list" <squeak-dev(a)lists.squeakfoundation.org> >>>>>Date 11/16/2023 6:48:43 PM >>>>>Subject Re: [squeak-dev] Re: Resuming on BlockCannotReturn >>>>>exception >>>>> >>>>>>Hi Jaromir, >>>>>> >>>>>>>On Nov 16, 2023, at 3:23 AM, Jaromir Matas <mail(a)jaromir.net> >>>>>>>wrote: >>>>>>> >>>>>>> >>>>>>>Hi Nicloas, >>>>>>>No no, I don't have any practical scenario in mind, I'm just >>>>>>>trying to understand why the VM is implemented like this, whether >>>>>>>there were a reason to leave this possibility of a crash, e.g. it >>>>>>>would slow down the VM to try to prevent such a dumb situation >>>>>>>(who would resume from BCR in his right mind? :) ) - or perhaps I >>>>>>>have overlooked some good reason to even keep this behavior in >>>>>>>the VM. That's all. >>>>>> >>>>>>Let’s first understand what’s really happening. Presumably at tone >>>>>>point a context is resumed those pc is already at the block return >>>>>>bytecode (effectively, because it crashes in JITted code, but I >>>>>>bet the stack vm will crash also, but not as cleanly - it will try >>>>>>and execute the bytes in the encoded method trailer). So which >>>>>>method actually sends resume, and to what, and what state is >>>>>>resume’s receiver when resume is sent? >>>>>> >>>>>> >>>>>>> >>>>>>>Thanks for your reply. >>>>>>>Regards, >>>>>>>Jaromir >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>------ Original Message ------ >>>>>>>From "Nicolas Cellier" <nicolas.cellier.aka.nice(a)gmail.com> >>>>>>>To "Jaromir Matas" <mail(a)jaromir.net>; "The general-purpose >>>>>>>Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org> >>>>>>>Date 11/16/2023 7:20:20 AM >>>>>>>Subject Re: [squeak-dev] Resuming on BlockCannotReturn exception >>>>>>> >>>>>>>>Hi Jaromir, >>>>>>>>Is there a scenario where it would make sense to resume a >>>>>>>>BlockCannotReturn? >>>>>>>>If not, I would suggest to protect at image side and override >>>>>>>>#resume. >>>>>>>> >>>>>>>>Le mer. 15 nov. 2023, 23:42, Jaromir Matas <mail(a)jaromir.net> a >>>>>>>>écrit : >>>>>>>>>Hi Eliot, Christoph, All, >>>>>>>>> >>>>>>>>>It's known the following example crashes the VM. Is this an >>>>>>>>>intended behavior or a "tolerated bug"? >>>>>>>>> >>>>>>>>>`[[^ 1] on: BlockCannotReturn do: #resume] fork` >>>>>>>>> >>>>>>>>>I understand why it crashes: the non-local return has nowhere >>>>>>>>>to return to and so resuming the computation leads to a crash. >>>>>>>>>But why not raise another BCR exception to prevent the crash? >>>>>>>>>Potential infinite loop? Perhaps I'm just missing the purpose >>>>>>>>>of this behavior... >>>>>>>>> >>>>>>>>>Thanks for an explanation. >>>>>>>>> >>>>>>>>>Best, >>>>>>>>>Jaromir >>>>>>>>> >>>>>>>>>-- >>>>>>>>> >>>>>>>>>Jaromir Matas >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>>> >>>>-- >>>>_,,,^..^,,,_ >>>>best, Eliot >><Context-cannotReturn.st>

8 58

Debugging through #fork
by Jakob Reschke 05 Mar '24

05 Mar '24

Dear Squeakers, I was just asking myself, why we cannot debug process forking like this: 0. In the Debugger: [ self doSomething ] "--> next send" fork. nextStatement. 1. Press the Through button. 2. The debugger stops at the next step after the send of #fork: [ self doSomething ] fork. "-->" nextStatement. 3. A second full debugger opens on the new (and now suspended) process: [ self "-->" doSomething ] fork. nextStatement. Do you see any drawbacks or huge implementation challenges or blockers? Or would it be "only" a matter of somebody finding the time and will to implement such a feature? Kind regards, Jakob

6 10

The Trunk: Kernel-jar.1550.mcz
by commits＠source.squeak.org 05 Mar '24

05 Mar '24

Christoph Thiede uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-jar.1550.mcz ==================== Summary ==================== Name: Kernel-jar.1550 Author: jar Time: 9 January 2024, 8:36:02.1473 pm UUID: f53ab664-7278-8944-8a7c-90660a08f773 Ancestors: Kernel-ct.1549 fix and rename private method #stepToCalleeOrNil to #stepToSenderOrNil if you debug and do step through to ^2 and then step over in [^2] ensure: [] the debugger incorrectly stops at #resume:through:. The reason is #resume:through: sends a block as an argument and #stepToCalleeOrNil is just not right for this situation: the purpose of the #stepToSenderOrNil method is to remove the top context from the stack by stepping until the context returns. This means we're not interested in detecting stack increases provided by #stepToCalleeOrNil. It is only used as a helper method in runUntilErrorOrReturnFrom: =============== Diff against Kernel-ct.1549 =============== Item was changed: ----- Method: Context>>runUntilErrorOrReturnFrom: (in category 'controlling') ----- runUntilErrorOrReturnFrom: aSender "ASSUMES aSender is a sender of self. Execute self's stack until aSender returns or an unhandled exception is raised. Return a pair containing the new top context and a possibly nil exception. The exception is not nil if it was raised before aSender returned and it was not handled. The exception is returned rather than openning the debugger, giving the caller the choice of how to handle it." "Self is run by jumping directly to it (the active process abandons thisContext and executes self). However, before jumping to self we insert an ensure block under aSender that jumps back to thisContext when evaluated. We also insert an exception handler under aSender that jumps back to thisContext when an unhandled exception is raised. In either case, the inserted ensure and exception handler are removed once control jumps back to thisContext." | error ctxt here topContext | here := thisContext. "Insert ensure and exception handler contexts under aSender" error := nil. ctxt := aSender insertSender: (Context contextOn: UnhandledError do: [:ex | error ifNil: [ error := ex exception. topContext := thisContext. ex resumeUnchecked: here jump] ifNotNil: [ex pass] ]). ctxt := ctxt insertSender: (Context contextEnsure: [error ifNil: [ topContext := thisContext. here jump] ]). self jump. "Control jumps to self" "Control resumes here once above ensure block or exception handler is executed" ^ error ifNil: [ "No error was raised, remove ensure context by stepping until popped" + [ctxt isDead or: [topContext isNil]] whileFalse: [topContext := topContext stepToSenderOrNil]. - [ctxt isDead or: [topContext isNil]] whileFalse: [topContext := topContext stepToCalleeOrNil]. {topContext. nil} ] ifNotNil: [ "Error was raised, remove inserted above contexts then return signaler context" aSender terminateTo: ctxt sender. "remove above ensure and handler contexts" {topContext. error} ]! Item was removed: - ----- Method: Context>>stepToCalleeOrNil (in category 'private') ----- - stepToCalleeOrNil - "Step to callee or sender; step to return and answer nil in case sender cannot be returned to." - - | ctxt | - ctxt := self. - [(ctxt willReturn and: [ctxt sender isNil or: [ctxt sender isDead]]) not and: [(ctxt := ctxt step) == self]] whileTrue. - ctxt == self ifTrue: [^nil]. - ^ctxt! Item was added: + ----- Method: Context>>stepToSenderOrNil (in category 'private') ----- + stepToSenderOrNil + "Step to sender or step to return and answer nil in case sender cannot be returned to." + + | ctxt | + ctxt := self. + [(ctxt willReturn and: [ctxt sender isNil or: [ctxt sender isDead]]) not and: [(ctxt := ctxt step) == self or: [ctxt hasSender: self]]] whileTrue. + ctxt == self ifTrue: [^nil]. + ^ctxt!

1 0

The Trunk: Kernel-ct.1561.mcz
by commits＠source.squeak.org 05 Mar '24

05 Mar '24

Christoph Thiede uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ct.1561.mcz ==================== Summary ==================== Name: Kernel-ct.1561 Author: ct Time: 5 March 2024, 9:36:04.183802 pm UUID: 066dbe81-44ca-7e44-8623-4652ec3e655e Ancestors: Kernel-ct.1559, Kernel-jar.1550 Merges Kernel-jar.1550 (avoids halting in #resume:through: when stepping over non-local return). See: https://lists.squeakfoundation.org/archives/list/squeak-dev@lists.squeakfou…. =============== Diff against Kernel-ct.1559 =============== Item was changed: ----- Method: Context>>runUntilErrorOrReturnFrom: (in category 'controlling') ----- runUntilErrorOrReturnFrom: aSender "ASSUMES aSender is a sender of self. Execute self's stack until aSender returns or an unhandled exception is raised. Return a pair containing the new top context and a possibly nil exception. The exception is not nil if it was raised before aSender returned and it was not handled. The exception is returned rather than openning the debugger, giving the caller the choice of how to handle it." "Self is run by jumping directly to it (the active process abandons thisContext and executes self). However, before jumping to self we insert an ensure block under aSender that jumps back to thisContext when evaluated. We also insert an exception handler under aSender that jumps back to thisContext when an unhandled exception is raised. In either case, the inserted ensure and exception handler are removed once control jumps back to thisContext." | error ctxt here topContext | here := thisContext. "Insert ensure and exception handler contexts under aSender" error := nil. ctxt := aSender insertSender: (Context contextOn: UnhandledError do: [:ex | error ifNil: [ error := ex exception. topContext := thisContext. ex resumeUnchecked: here jump] ifNotNil: [ex pass] ]). ctxt := ctxt insertSender: (Context contextEnsure: [error ifNil: [ topContext := thisContext. here jump] ]). self jump. "Control jumps to self" "Control resumes here once above ensure block or exception handler is executed" ^ error ifNil: [ "No error was raised, remove ensure context by stepping until popped" + [ctxt isDead or: [topContext isNil]] whileFalse: [topContext := topContext stepToSenderOrNil]. - [ctxt isDead or: [topContext isNil]] whileFalse: [topContext := topContext stepToCalleeOrNil]. {topContext. nil} ] ifNotNil: [ "Error was raised, remove inserted above contexts then return signaler context" aSender terminateTo: ctxt sender. "remove above ensure and handler contexts" {topContext. error} ]! Item was removed: - ----- Method: Context>>stepToCalleeOrNil (in category 'private') ----- - stepToCalleeOrNil - "Step to callee or sender; step to return and answer nil in case sender cannot be returned to." - - | ctxt | - ctxt := self. - [(ctxt willReturn and: [ctxt sender isNil or: [ctxt sender isDead]]) not and: [(ctxt := ctxt step) == self]] whileTrue. - ctxt == self ifTrue: [^nil]. - ^ctxt! Item was added: + ----- Method: Context>>stepToSenderOrNil (in category 'private') ----- + stepToSenderOrNil + "Step to sender or step to return and answer nil in case sender cannot be returned to." + + | ctxt | + ctxt := self. + [(ctxt willReturn and: [ctxt sender isNil or: [ctxt sender isDead]]) not and: [(ctxt := ctxt step) == self or: [ctxt hasSender: self]]] whileTrue. + ctxt == self ifTrue: [^nil]. + ^ctxt!

1 0

The Inbox: Collections-ct.1063.mcz
by commits＠source.squeak.org 05 Mar '24

05 Mar '24

Christoph Thiede uploaded a new version of Collections to project The Inbox: http://source.squeak.org/inbox/Collections-ct.1063.mcz ==================== Summary ==================== Name: Collections-ct.1063 Author: ct Time: 2 March 2024, 6:08:41.266276 pm UUID: e5cc1f5c-62e6-3d4a-81f0-e8de89f894c4 Ancestors: Collections-mt.1058 Fixes WeakSet>>removeAllSuchThat: for GCs during removal. Please review. =============== Diff against Collections-mt.1058 =============== Item was added: + ----- Method: WeakSet>>removeAllSuchThat: (in category 'removing') ----- + removeAllSuchThat: aBlock + "Overridden to avoid NotFound errors when elements where garbage-collected between selection and attempt to removal." + + self copy do: [:each | (aBlock value: each) ifTrue: [self remove: each ifAbsent: []]]!

3 3

The Trunk: MonticelloConfigurations-codefrau.187.mcz
by commits＠source.squeak.org 04 Mar '24

04 Mar '24

Vanessa Freudenberg uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-codefrau.187.mcz ==================== Summary ==================== Name: MonticelloConfigurations-codefrau.187 Author: codefrau Time: 3 March 2024, 10:02:08.630869 pm UUID: 3b4f7c9e-6f22-4013-9eb9-f17f4a3915fc Ancestors: MonticelloConfigurations-codefrau.186 Show author's full name in MC browser =============== Diff against MonticelloConfigurations-codefrau.186 =============== Item was changed: ----- Method: MCConfigurationExtended>>summaryOn: (in category 'printing') ----- summaryOn: aStream name ifNotNil: [aStream nextPutAll: 'Name: '; nextPutAll: name; cr]. + authorInitials ifNotNil: [ | fullName | + fullName := SystemNavigation authorsInverted at: authorInitials + ifPresent: [:names | names asArray joinSeparatedBy: ' or '] + ifAbsent: ['unregistered author']. + aStream nextPutAll: 'Author: '; nextPutAll: authorInitials, ' (', fullName, ')'; cr]. - authorInitials ifNotNil: [aStream nextPutAll: 'Author: '; nextPutAll: authorInitials; cr]. timeStamp ifNotNil: [aStream nextPutAll: 'Time: '; nextPutAll: timeStamp; cr]. id ifNotNil: [aStream nextPutAll: 'UUID: '; nextPutAll: id; cr]. priorVersions ifNotEmpty: [aStream nextPutAll: 'Prior: '; nextPutAll: priorVersions first name; cr]. comment ifNotNil: [aStream cr; nextPutAll: comment; cr]. aStream cr. super summaryOn: aStream. !

1 0