[squeak-dev] The semantics of halfway-executed unwind contexts during process termination

mail at jaromir.net mail at jaromir.net
Fri Dec 17 15:04:55 UTC 2021


Hi Christoph,

On 2021-12-16T03:10:36+01:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> 
> I just have uploaded a revised version of Process-terminateAggressively.2.cs to the Trunk! :-) It includes #terminateAggressive & #destroy, the connection to the debugger/process browser, UI & E2E tests, and a bit of documentation. Please see the version message of Kernel-ct.1434 for more details.
> 

Congratulations! Beautiful, in my opinion :) I like the classic "teminate" option in the Debugger's window menu and the new "destroy" option nicely hidden under the Shift + right-click menu ;) 

> 
> Updated summary:
> 
> - [x] We want to implement three modi of process termination:
>   - [x] (i) - #destroy
>   - [x] (ii) - #terminateAggressively
>   - [ ] (iii) - #terminate, I still need to review your fixes
>
The latest is Kernel-jar.1436 (and KernelTests-jar.417)
>
> - [x] Decide on names for (ii) and (iii) - done provided no objections
> - [x] Decide on UI integration into debugger - done provided no objections
> - [x] Decide on UI integration into Process Browser - done provided no objections
> 
> And just for some orientation, the other remaining issues:
>
> - [ ] open #terminate issues (I still need to review them)
>
Yes
> - [ ] proceedable BlockCannotReturn (I still need to review them?)
>
I'd say yes, I removed the dependency on your solution from the current #terminate; if agreed by others I'd be happy to see it implemented.
>
> - [ ] Tackling Context>>#runUntilErrorReturnFrom: (most likely also my turn)
>
not sure what you're referring to
>
> - [ ] issue with #unwindTo: - see http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215758.html#:~:text=unwindTo%3A (regression tests & patches welcome :))
>
yes, still pending; I just don't have enough energy now :)
> 
> Some by-the-way notes:
> 
> - I have merged some of your process tests earlier today. Thank you for providing them!
> 
Many thanks indeed!
>
> - I keep seeing some unexpected 'infinite recursion in doesNotUnderstand:' from time to time but could not reproduce them. Just FYI, afaik you and Eliot have concocted this - I still need to read up all the details in my overflowing inbox. ;-)
> 
Purely Eliot's idea :) I haven't had any problem since the fix (but I'm mostly working with the new terminate in my image so maybe the current terminate has an issue - let me know if you find an example).

Thanks again for this nice addition to the Debugger.

Best,
~~~
^[^    Jaromir

Sent from Squeak Inbox Talk

> 
> On 2021-11-15T18:33:33+01:00, mail at jaromir.net wrote:
> 
> > Hi Christoph,
> > 
> > Once again, apologies for the huge delay in my responding :)
> > 
> > > Hm, I would rather say that closing the window should have the same effect as pressing "abandon" - personally, I am very much used to this and we do not really have good options to communicate a different behavior of the close button. 
> > 
> > Yes, you're right indeed.
> > 
> > > A kill item in the stack trace menu sounds fine for now (even though killing is not actually related to the selected context). In the long term, I would like to introduce menu buttons in the fashion of [1] in the Morphic UI.
> > 
> > Your Abandon button with options is terrific, please disregard my suggestion :)
> > 
> > > > look at something in the debugger (on a healthy process) and close the window (i.e. full termination is appropriate and I'd even say preferable).
> > >
> > > Can you help me please, if the process is healthy (so no unwind context is lying on the stack), would there be any difference between the different terminate modi (ii) and (iii)?
> > 
> > I thought there was a difference, e.g. if you debug #ensure on a healthy process and want to abandon the debugger in the middle - does it make sense?
> > 
> > Example: 
> > [^2] ensure: [Transcript cr; show: 'done'. "do some cleaning"]
> > 
> > Now, you start a debugger, do a few steps and in the middle of the ensure block you decide you've seen enough and hit Abandon - if it's implemented with (ii), i.e. the 'aggressive', less safe version of terminate, the block won't get completed. If it contained some cleaning procedures, the cleaning wouldn't be executed... That's why I'm still leaning slightly towards full termination as a default Abandon action - but e.g. Visual Works use the less safe termination in this case, as you suggest. Other Smalltalks I checked (Cuis, Pharo and VA) don't have three ways to terminate at all (yet) :) However, ultimately users that use Squeak the most should have the final say. I'll be happy with both options. (Or make it a preference?). 
> > 
> > [[x1 := nil] ensure: [x1 := (2 / 0)]] 
> > ����ensure: [self inform: x1 asString].
> > 
> > Hmm, this example of your nicely justifies your approach: Abandon = (ii)  :D
> > 
> > Naming:
> > 
> > > Hm, "light" reminds me of "friendly" and (iii) would certainly be more friendly (giving the process more freedom for cleaning things up). Difficult ...
> > > What about #terminateNow for (ii) and #terminate for (iii), slightly related to #updateStyle and #updateStyleNow? Since (iii) might continue with the execution of the current halfway-executed context, (ii) is more urgent.
> > > Another option would be "terminate: aggressive", analogously to "cleanup: aggressive" on Behavior where #terminate would fall back to "terminate: false". But this would make the new mode a little bit worse accessible.
> > 
> > Agreed, "light" is not good. Checked Visual Works again and they use terminate for (iii), terminateUnsafely for (ii) and terminateUnsafelyNow for kill (i). #teminateNow suggests it would terminate now as opposed to later :) No hint about the nature of the procedure that will attempt to terminate with increased level of possible damage to the environment... But we're getting closer and again, I'll be happy with either of them :)
> > 
> > > Here are some ideas for better names:
> > >
> > > (i) #destroy (as opposed to #kill, this sounds more like the cheap and unreactable operation it is)
> > > (ii) #terminateAggressively, which redirects to #terminate: true
> > > (iii) #terminate, which redirects to #terminate: false
> > 
> > One more naming suggestion:
> > (iii) terminate (~run all unwind blocks)
> > (ii) terminateLessSafely (~skip unwind blocks in progress, run all not-yet-started ones)
> > (i) terminateUnsafely (~kill, run no unwinds)
> > 
> > Marcel wrote:
> > 
> > > How would you summarize the differences between #terminate, #terminateAggressively, and #kill, each with 1-2 sentences? :-)
> > 
> > Inspired by VW:
> > 
> > (iii) "Terminate the process and allow all unwind blocks to run, even if they are currently in progress." This is the behavior we expect when terminating a healthy process.
> > 
> > (ii) "Terminate the process and run all not-yet-started unwind blocks; if the process is in the middle of an unwind block, then that unwind block will not be completed, but subsequent unwind blocks will be run." This is the behavior we expect when we close the debugger in a situation when the unwind block may not be able to complete, either because of an error, or because it is hung. In most other circumstances, we would want to use #terminate, which allows unwind blocks in progress to complete.
> > 
> > (i) "Terminate the process without attempting to run any of its unwind blocks." This is the behavior we might need in very rare circumstances when modes (iii) and (ii) fail.
> > 
> > Changeset:
> > 
> > > Please find the attached changeset in which I have changed the names accordingly and also have removed the kill/destroy operation from the UI as per request of Marcel. I aggree with his argument that destroy is a kind of private operation that affects the interna of the process and should be only used for troubleshooting, so we should not give this hack too much visibility.
> > 
> > Nice! I liked your Abandon button with options more but this is a start. 
> > Kill option: do you mean no access to the kill option from the Process browser either? Process browser is a very troubleshooting tool :)
> > 
> > And finally, If I may - I'd slightly prefer not adding another #terminate: to the Process class only to serve a single sender but rather inline it and address the two termination modes directly in the ProcessBrowser class:
> > 
> > 
> > ProcessBrowser class >> #terminateProcess: aProcess aggressively: aggressive
> > 
> > ����aProcess ifNil: [^ self].
> > ����
> > ����self suspendedProcesses
> > ��������removeKey: aProcess
> > ��������ifAbsent: [].
> > -����aProcess terminate: aggressive.
> > +����aggressive
> > ��������ifFalse: [aProcess terminate]
> > ��������ifTrue: [aProcess terminateAggressively]
> >  
> > 
> > > Concerning your #unwindTo: issue - not sure if this actually related to this thread? Actually I've lost the overview which terminate mode - (ii) or (iii) - you are referring to, maybe we should discuss this in a separate conversation. :-)
> > 
> > Yes, it's a bug and deserves its own thread.
> > 
> > ===
> > Summary:
> > 
> > > TLDR: Concerning our next steps - consider this a small to-do list:
> > >
> > > - [ ] We want to implement three modi of process termination:
> > >   - [x] (i) is not yet implemented but should be easy to implement
> > >   - [x] (ii) is in my proposal from [2], maybe needs further refinement
> > >   - [ ] (iii) is pretty much what we have in Process >> #terminate in the current Trunk. Is there anything still missing yet?
> > > - [ ] Decide on names for (ii) and (iii) - see above
> > > - [ ] Decide on UI integration into debugger - see above
> > 
> > Add this one?
> > - [ ] Decide on UI integration into Process Browser
> > 
> > Regarding Process >> #terminate - the current Trunk version is not final; the final version is the Inbox's Kernel-jar.1414. 
> > 
> > More or less done! :)
> > 
> > Thanks,
> > 
> > Jaromir
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On 2021-08-30T12:51:21+02:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> > 
> > > Hi Marcel, hi all,
> > > 
> > > > How would you summarize the differences between #terminate, #terminateAggressively, and #kill, each with 1-2 sentences? :-)
> > > 
> > > Let's keep using the numbers from above instead, as the names are only my imperfect proposals:
> > > 
> > > (i) run no unwind contexts (harshest possible way; currently only achievable by doing "suspendedContext privSender: nil" prior to terminating). You would need this very rarely, if at all, for troubleshooting.
> > > (ii) run not-yet started unwind contexts (this is what I proposed in fix-Process-terminate.1.cs [1]). This is the behavior we expect from the Abandon button in a debugger. I think?
> > > (iii) run all unwind contexts, including those that already have been started (this is the most friendly way that you implemented in #terminate recently). This is the behavior we expect when terminating a healthy process.
> > > 
> > > Here are some ideas for better names:
> > > 
> > > (i) #destroy (as opposed to #kill, this sounds more like the cheap and unreactable operation it is)
> > > (ii) #terminateAggressively, which redirects to #terminate: true
> > > (iii) #terminate, which redirects to #terminate: false
> > > 
> > > Please find the attached changeset in which I have changed the names accordingly and also have removed the kill/destroy operation from the UI as per request of Marcel. I aggree with his argument that destroy is a kind of private operation that affects the interna of the process and should be only used for troubleshooting, so we should not give this hack too much visibility.
> > > 
> > > Best,
> > > Christoph
> > > 
> > > ---
> > > Sent from Squeak Inbox Talk
> > > 
> > > On 2021-08-23T13:59:04+02:00, marcel.taeumel at hpi.de wrote:
> > > 
> > > > Hi Christoph --
> > > > 
> > > > How would you summarize the differences between #terminate, #terminateAggressively, and #kill, each with 1-2 sentences? :-)
> > > > 
> > > > Best,
> > > > Marcel
> > > > Am 23.08.2021 13:18:40 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
> > > > Hi all, hi Jaromir,
> > > > 
> > > > based on the to-do list from my previous message, I have created a changeset that adds Process >> #terminateAggressively (ii) and Process >> #kill (i) and integrates them into the process browser and the debugger. Most importantly, the following snippet will inform "nil" now instead of "ZeroDevision" after abandoning the error:
> > > > 
> > > > ????[[x1 := nil] ensure: [x1 := (2 / 0)]]
> > > > ????????ensure: [self inform: x1 asString].
> > > > 
> > > > With this changeset, I would be fully happy again with the functionality of the debugger. :-) What remains to do is the following:
> > > > 
> > > > - [ ] We want to implement three modi of process termination:
> > > > - [x] (i) - see #kill
> > > > - [X] (ii) - see #terminateAggressively
> > > > - [ ] (iii) is pretty much what we have in Process >> #terminate in the current Trunk. Is there anything still missing yet?
> > > > - [ ] Decide on names for (ii) and (iii) - see my previous message
> > > > - [ ] Decide on UI integration into debugger - proposal exists in Process-terminateAggressively.1, but open for criticism
> > > > - [ ] Test #terminateAggressively (actualy, I don't have a good of overview of all your new #terminate tests - probably it would be easiest to wait until they have arrived in the Trunk and then create copies of them to test #terminateAggressively analogously :D)
> > > > 
> > > > Best,
> > > > Christoph
> > > > 
> > > > ---
> > > > Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
> > > > 
> > > > On 2021-08-22T16:07:54+02:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> > > > 
> > > > > Hi Jaromir,
> > > > >
> > > > > back from vacation, *finally* I have found some time to return back to this pleasant problem! :-)
> > > > >
> > > > > Great, it sounds like we're already agreeing pretty much, just let me address some small points:
> > > > >
> > > > > > Debugger - Abandon could be the lightweight version you proposed. Why not
> > > > > > have a proper Abandon button for it?
> > > > > > ????The right click menu on a context could offer the Kill option (next to
> > > > > > 'peel to first like this'); no button necessary.
> > > > > > Now the question is what should be under the "window close" red-circle-x -
> > > > > > heavyweight terminate? I'm thinking this scenario: if the debugger returns
> > > > > > after closing the window you start thinking what happened and use Abandon;
> > > > > > if it still doesn't help you go right-click and kill it?
> > > > > >
> > > > > > My usual scenario is (limited experience however): look at something in the
> > > > > > debugger (on a healthy process) and close the window (i.e. full termination
> > > > > > is appropriate and I'd even say preferable). If something goes wrong - then
> > > > > > I'd welcome a hint there are options - thus the proper Abandon button - what
> > > > > > do you think?
> > > > >
> > > > > Hm, I would rather say that closing the window should have the same effect as pressing "abandon" - personally, I am very much used to this and we do not really have good options to communicate a different behavior of the close button. I think presenting the new behaviors Kill (i) and (iii) in some kind of menu would be less confusing.
> > > > > A kill item in the stack trace menu sounds fine for now (even though killing is not actually related to the selected context). In the long term, I would like to introduce menu buttons in the fashion of [1] in the Morphic UI (Marcel is currently reviewing my proposal for this), then we could move Kill into the Abandon menu, but for now, your proposal sounds perfectly fine to me. :-)
> > > > >
> > > > > > look at something in the debugger (on a healthy process) and close the window (i.e. full termination is appropriate and I'd even say preferable).
> > > > >
> > > > > Can you help me please, if the process is healthy (so no unwind context is lying on the stack), would there be any difference between the different terminate modi (ii) and (iii)?
> > > > >
> > > > > > > But I don't have any good idea for version (ii) yet. Call it #abandon like
> > > > > > > in the debugger? Then again, #abandon is rather a verb from the Morphic
> > > > > > > language. Further possible vocables (according to my synonym thesaurus)
> > > > > > > include #end, #stop, #finish, #unwind, #abort, #exit. Please help... :-)
> > > > > >
> > > > > > I'd probably go with something like #terminateLight because it's a proper
> > > > > > process termination including unwinds except the ones currently in progress
> > > > > > - so it is a light version of #terminate :) I've checked VisualWorks: they
> > > > > > chose #terminateUnsafely for this type of termination which I don't like
> > > > > > much, it sounds too negative; the real meaning is rather
> > > > > > #terminateAsSafelyAsPossibleGivenTheCircumstances ;).
> > > > >
> > > > > Hm, "light" reminds me of "friendly" and (iii) would certainly be more friendly (giving the process more freedom for cleaning things up). Difficult ...
> > > > > What about #terminateNow for (ii) and #terminate for (iii), slightly related to #updateStyle and #updateStyleNow? Since (iii) might continue with the execution of the current halfway-executed context, (ii) is more urgent.
> > > > > Another option would be "terminate: aggressive", analogously to "cleanup: aggressive" on Behavior where #terminate would fall back to "terminate: false". But this would make the new mode a little bit worse accessible.
> > > > >
> > > > > Concerning your #unwindTo: issue - not sure if this actually related to this thread? Actually I've lost the overview which terminate mode - (ii) or (iii) - you are referring to, maybe we should discuss this in a separate conversation. :-)
> > > > >
> > > > > ---
> > > > >
> > > > > TLDR: Concerning our next steps - consider this a small to-do list:
> > > > >
> > > > > - [ ] We want to implement three modi of process termination:
> > > > > ????- [ ] (i) is not yet implemented but should be easy to implement
> > > > > ????- [ ] (ii) is in my proposal from [2], maybe needs further refinement
> > > > > ????- [ ] (iii) is pretty much what we have in Process >> #terminate in the current Trunk. Is there anything still missing yet?
> > > > > - [ ] Decide on names for (ii) and (iii) - see above
> > > > > - [ ] Decide on UI integration into debugger - see above
> > > > >
> > > > > Further answers following soon.
> > > > >
> > > > > Best,
> > > > > Christoph
> > > > >
> > > > > [1] https://user-images.githubusercontent.com/48567372/60924070-4472fe80-a26e-11e9-9e61-5c167bc31e9b.png
> > > > > [2]
> > > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215608.html (fix-Process-terminate.cs)
> > > > >
> > > > > ---
> > > > > Sent from Squeak Inbox Talk
> > > > >
> > > > > On 2021-05-29T14:31:13-05:00, m at jaromir.net wrote:
> > > > >
> > > > > > Hi Christoph,
> > > > > >
> > > > > > > Jaromir, your proposal to provide multiple selectors for modeling separate
> > > > > > > modes of termination sounds like a very good idea to me. But how many
> > > > > > > different modes do we actually need? So far I can count three modes:
> > > > > > >
> > > > > > > (i) run no unwind contexts (harshest possible way; currently only
> > > > > > > achievable by doing "suspendedContext privSender: nil" prior to
> > > > > > > terminating)
> > > > > > > (ii) run not-yet started unwind contexts (this is what I proposed in
> > > > > > > fix-Process-terminate.1.cs [1])
> > > > > > > (iii) run all unwind contexts, including those that already have been
> > > > > > > started (this is the most friendly way that you implemented in #terminate
> > > > > > > recently)
> > > > > >
> > > > > > I think this is it.
> > > > > >
> > > > > > Litereally minutes ago had to use privSender: nil to get rid of a debugger
> > > > > > :) Fully terminate really is too strong to recover from fatal errors.
> > > > > >
> > > > > > > ... my point here is: Proceeding from an error almost always doesn't seem
> > > > > > > "right". :-) It is always a decision by the debugging programmer to
> > > > > > > override the default control flow and switch to the "next plausible
> > > > > > > alternative control flow", i.e., resume as if the error would have never
> > > > > > > been raised.
> > > > > >
> > > > > > yes - I'd add: even an error may quite often be completely benign, like
> > > > > > 'Transcript show: 1/0' - possibly a typo so you just may want to Proceed or
> > > > > > fully terminate. In case the error damages a whole subsequent chain of
> > > > > > events, you're absolutely right a full termination seems a silly option and
> > > > > > a light version of terminate may be the most appropriate.
> > > > > >
> > > > > > So I fully agree the decision which termination mode it is stays with the
> > > > > > user - so I'm all for giving the user the choices you suggested.
> > > > > >
> > > > > > > \1. Which mode should we use in which situations?
> > > > > > >
> > > > > > > I think this debate could benefit from a few more concrete usage
> > > > > > > scenarios. I'm just collecting some here (thinking aloud):
> > > > > > >
> > > > > > > \- Process Browser: We can provide multiple options in the process menu.
> > > > > > > \- Debugger: I agree with you that Abandon should always run not-yet
> > > > > > > started unwind contexts but never resume halfway-executed unwind contexts.
> > > > > > > So this maps to to mode (ii) from above.
> > > > > > > \- Skimming through most senders of #terminate in the image, they often
> > > > > > > orchestrate helper processes, deal with unhandled errors or timeouts, or
> > > > > > > do similar stuff - usually they should be very fine with the friendly
> > > > > > > version of #terminate, i.e. mode (iii) from above. I think.
> > > > > > > \- Regarding option (1), I think you would need it extremely seldom but
> > > > > > > maybe in situations like when your stack contains a loop, your unwind
> > > > > > > contexts will cause a recursion/new error, or you deliberately want to
> > > > > > > prevent any unwind context from running. No objections against adding a
> > > > > > > small but decent button for this in the debugger. :-)
> > > > > > >
> > > > > > > Would you agree with these behaviors? Maybe you can add further examples
> > > > > > > to the list?
> > > > > >
> > > > > > Yes
> > > > > >
> > > > > > Process Browser - the right click menu could provide all options
> > > > > >
> > > > > > Debugger - Abandon could be the lightweight version you proposed. Why not
> > > > > > have a proper Abandon button for it?
> > > > > > ????The right click menu on a context could offer the Kill option (next to
> > > > > > 'peel to first like this'); no button necessary.
> > > > > > ????Now the question is what should be under the "window close" red-circle-x -
> > > > > > heavyweight terminate? I'm thinking this scenario: if the debugger returns
> > > > > > after closing the window you start thinking what happened and use Abandon;
> > > > > > if it still doesn't help you go right-click and kill it?
> > > > > >
> > > > > > My usual scenario is (limited experience however): look at something in the
> > > > > > debugger (on a healthy process) and close the window (i.e. full termination
> > > > > > is appropriate and I'd even say preferable). If something goes wrong - then
> > > > > > I'd welcome a hint there are options - thus the proper Abandon button - what
> > > > > > do you think?
> > > > > >
> > > > > > > \2. How should we name them?
> > > > > > >
> > > > > > > Direct proposal: (i) #kill and (iii) #terminate.
> > > > > > > After looking up the original behavior of #terminate in Squeak 5.3, I
> > > > > > > think it would be consistent to resume all halfway-executed unwind
> > > > > > > contexts in this method. So yes, I also withdraw my criticism about
> > > > > > > #testNestedUnwind. :-)
> > > > > > >
> > > > > > > But I don't have any good idea for version (ii) yet. Call it #abandon like
> > > > > > > in the debugger? Then again, #abandon is rather a verb from the Morphic
> > > > > > > language. Further possible vocables (according to my synonym thesaurus)
> > > > > > > include #end, #stop, #finish, #unwind, #abort, #exit. Please help... :-)
> > > > > >
> > > > > > I'd probably go with something like #terminateLight because it's a proper
> > > > > > process termination including unwinds except the ones currently in progress
> > > > > > - so it is a light version of #terminate :) I've checked VisualWorks: they
> > > > > > chose #terminateUnsafely for this type of termination which I don't like
> > > > > > much, it sounds too negative; the real meaning is rather
> > > > > > #terminateAsSafelyAsPossibleGivenTheCircumstances ;).
> > > > > >
> > > > > > I'm wondering whether #unwindTo: (used ony by Generator) is bugged (with
> > > > > > regard to dealing with non-local returns), and could be fixed/unified with
> > > > > > your approach. Look at these examples:
> > > > > > ```
> > > > > > p := [[Processor activeProcess suspend] valueUninterruptably] fork.
> > > > > > Processor yield.
> > > > > > p suspendedContext unwindTo: nil
> > > > > > ```
> > > > > > or
> > > > > > ```
> > > > > > p := [[:exit | [Processor activeProcess suspend] ensure: [exit value]]
> > > > > > valueWithExit] fork.
> > > > > > Processor yield.
> > > > > > p suspendedContext unwindTo: nil
> > > > > > ```
> > > > > >
> > > > > > If you do `p terminate` instead of `p suspendedContext unwindTo: nil`, it
> > > > > > works fine, but #unwindTo causes a block cannot return error - I think it's
> > > > > > the same bug all over again :) #value evaluates the non-local return on the
> > > > > > wrong stack...
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regarding our cannot return discussion - I have to think about it and I'll
> > > > > > post my reply later in [1] to keep it separate :)
> > > > > >
> > > > > > Thanks again and regards,
> > > > > >
> > > > > > [1]
> > > > > > http://forum.world.st/The-Inbox-Kernel-ct-1405-mcz-td5129706.html#a5130114
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----
> > > > > > ^[^ Jaromir
> > > > > > --
> > > > > > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
> > > > > >
> > > > > >
> > > > > -------------- next part --------------
> > > > > An HTML attachment was scrubbed...
> > > > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210822/d1ac62ea/attachment.html>
> > > > >
> > > > >
> > > > -------------- next part --------------
> > > > An HTML attachment was scrubbed...
> > > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210823/888835d9/attachment.html>
> > > > 
> > > > 
> > > ["Process-terminateAggressively.2.cs"]
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210830/0c36d9e3/attachment.html>
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: Process-terminateAggressively.1.cs
> > > Type: application/octet-stream
> > > Size: 12392 bytes
> > > Desc: not available
> > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210830/0c36d9e3/attachment.obj>
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: Process-terminateAggressively.2.cs
> > > Type: application/octet-stream
> > > Size: 13196 bytes
> > > Desc: not available
> > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210830/0c36d9e3/attachment-0001.obj>
> > > 
> > >
> > 
> > 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211216/cbd3c0ec/attachment-0001.html>
> 
> 


More information about the Squeak-dev mailing list