--==CelesteAttachment75902== Content-type: text/plain;charset=UTF-8
Hi Eliot,
On 2021-11-18T09:52:03-08:00, eliot.miranda@gmail.com wrote:
Hi Christoph, Hi Jaromir, Hi All,
On May 15, 2021, at 6:56 AM, commits at source.squeak.org wrote:
A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1405.mcz
==================== Summary ====================
Name: Kernel-ct.1405 Author: ct Time: 15 May 2021, 3:56:24.713389 pm UUID: 9a92be9b-d778-b54f-b659-713451a2ddb2 Ancestors: Kernel-nice.1402
Counterproposal to Kernel-jar.1404 for fixing VM crashes when resuming from a BlockCannotReturn. Instead of enforcing retrial, repair the context stack if the receiver has ended. There are two reasons for that:
- Not in all situations, the receiver of #cannotReturn: is actually unable to resume. Consider this example for a disproof: a := [true ifTrue: [^ 1]. 2]. "Both statements need to be executed separately in a Workspace so that [a outerContext sender] becomes nil!" a value.
In this situation, it is valid to resume from BlockCannotReturn and currently also possible in the Trunk. Note that BlockCannotReturn even overrides #isResumable to answer true, though the class comment discrecommends resuming it.
- The pattern proposed by Jaromir reminds me of the current implementation of Object >> #doesNotUnderstand: or Object >> #at:, that is, when the error was resumed, just try it again in the manner of a (potentially) infinite recursion. While the issue with infinite debuggers (which was eventually tripped by exactly this pattern) has been solved some time ago [1], I do not really agree with the pattern in general - it makes it unnecessarily hard for ToolSet implementors to consciously resume from an error instead of retrying it (which we have an extra selector on Exception for).
But the pattern is a really useful one in a dynamic environment where one is doing edit and continue. I donbt see any practical alternative, having lived for several years without it, and been frustrated at not being able to catch MessageNotUnderstood, do something (become the receiver, create a method, etc), and continue.
To solve the infinite recursion problem we could implement a wrapper around the message sentTo: receiver e.g. [aMessage sentTo: receiver] on: MessageNotUnderstood do: [:ex| | args | args := ex message arguments. (ex receiver == self and: [ex message selector == aMessage selector and: [(1 to: aMessage size) allSatisfy: [:i| (args at: i) == (aMessage argumentAt: i)]]]) ifFalse: [ex pass]. self error: binfinite recursion in doesNotUnderstand:b]
(& similarly in at: etc). Right?
Unbelievable!! Indeed it works like a charm :) If you felt like merging it into the Trunk right away it would simplify my #terminate changeset. I struggled to get around this recursion but this is of course the most appropriate place to address it. Thanks!
All worked, just replaced aMessage size with aMessage numArgs
Enclosing a fileout with #doesNotUnderstand:
doesNotUnderstand: aMessage "Handle the fact that there was an attempt to send the given message to the receiver but the receiver does not understand this message (typically sent from the machine when a message is sent to the receiver and no method is defined for that selector)."
"Testing: (3 activeProcess)"
| exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. resumeValue := exception signal. ^exception reachedDefaultHandler ifFalse: [resumeValue] ifTrue: [ [aMessage sentTo: self] on: MessageNotUnderstood do: [:ex| | args | args := ex message arguments. (ex receiver == self and: [ex message selector == aMessage selector and: [(1 to: aMessage numArgs) allSatisfy: [:i| (args at: i) == (aMessage argumentAt: i)]]]) ifFalse: [ex pass]. self error: 'infinite recursion in doesNotUnderstand:']]
[1] http://forum.world.st/Please-try-out-Fixes-for-debugger-invocation-during-co...
=============== Diff against Kernel-nice.1402 ===============
Item was added:
- ----- Method: BlockCannotReturn>>defaultResumeValue (in category 'defaults') -----
- defaultResumeValue
- ^ self result!
Item was changed: ----- Method: Context>>cannotReturn: (in category 'private-exceptions') ----- cannotReturn: result
- closureOrNil ifNotNil: [
| resumptionValue |
resumptionValue := self cannotReturn: result to: self home sender.
self pc > self endPC ifTrue: [
"This block has ended, continue with sender"
thisContext privSender: self sender].
^ resumptionValue].
- closureOrNil ifNotNil: [^ self cannotReturn: result to: self home sender]. Processor debugWithTitle: 'Computation has been terminated!!' translated full: false.!
["Object-doesNotUnderstand.st"] --==CelesteAttachment75902== Content-transfer-encoding: base64 Content-disposition: attachment;filename="Object-doesNotUnderstand.st" Content-type: application/octet-stream;name="Object-doesNotUnderstand.st"
J0Zyb20gU3F1ZWFrNi4wYWxwaGEgb2YgMjcgTWF5IDIwMjEgW2xhdGVzdCB1cGRhdGU6ICMy MDUzNV0gb24gMjEgTm92ZW1iZXIgMjAyMSBhdCA1OjI5OjUxIHBtJyENDSFPYmplY3QgbWV0 aG9kc0ZvcjogJ2Vycm9yIGhhbmRsaW5nJyBzdGFtcDogJ3Rlc3QgMTEvMjEvMjAyMSAxNzox NSchDWRvZXNOb3RVbmRlcnN0YW5kOiBhTWVzc2FnZSANCSAiSGFuZGxlIHRoZSBmYWN0IHRo YXQgdGhlcmUgd2FzIGFuIGF0dGVtcHQgdG8gc2VuZCB0aGUgZ2l2ZW4NCSAgbWVzc2FnZSB0 byB0aGUgcmVjZWl2ZXIgYnV0IHRoZSByZWNlaXZlciBkb2VzIG5vdCB1bmRlcnN0YW5kDQkg IHRoaXMgbWVzc2FnZSAodHlwaWNhbGx5IHNlbnQgZnJvbSB0aGUgbWFjaGluZSB3aGVuIGEg bWVzc2FnZQ0JIGlzIHNlbnQgdG8gdGhlIHJlY2VpdmVyIGFuZCBubyBtZXRob2QgaXMgZGVm aW5lZCBmb3IgdGhhdCBzZWxlY3RvcikuIg0NCSJUZXN0aW5nOiAoMyBhY3RpdmVQcm9jZXNz KSINDQl8IGV4Y2VwdGlvbiByZXN1bWVWYWx1ZSB8DQkoZXhjZXB0aW9uIDo9IE1lc3NhZ2VO b3RVbmRlcnN0b29kIG5ldykNCQltZXNzYWdlOiBhTWVzc2FnZTsNCQlyZWNlaXZlcjogc2Vs Zi4NCXJlc3VtZVZhbHVlIDo9IGV4Y2VwdGlvbiBzaWduYWwuDQleZXhjZXB0aW9uIHJlYWNo ZWREZWZhdWx0SGFuZGxlcg0JCWlmRmFsc2U6IFtyZXN1bWVWYWx1ZV0JCQ0JCWlmVHJ1ZTog Ww0JCQlbYU1lc3NhZ2Ugc2VudFRvOiBzZWxmXQ0JCQkJb246IE1lc3NhZ2VOb3RVbmRlcnN0 b29kDQkgICAgICAgICAJCWRvOiBbOmV4fCB8IGFyZ3MgfA0JCQkgICAgICAgICAgICAgICBh cmdzIDo9IGV4IG1lc3NhZ2UgYXJndW1lbnRzLg0JCQkgICAgICAgICAgICAgICAoZXggcmVj ZWl2ZXIgPT0gc2VsZg0JCQkgICAgICAgICAgICAgICBhbmQ6IFtleCBtZXNzYWdlIHNlbGVj dG9yID09IGFNZXNzYWdlIHNlbGVjdG9yDQkJCSAgICAgICAgICAgICAgICBhbmQ6IFsoMSB0 bzogYU1lc3NhZ2UgbnVtQXJncykgYWxsU2F0aXNmeTogWzppfCAoYXJncyBhdDogaSkgPT0g KGFNZXNzYWdlIGFyZ3VtZW50QXQ6IGkpXV1dKSBpZkZhbHNlOg0JCQkgICAgICAgICAgICAg ICBbZXggcGFzc10uDQkJCSAgICAgICAgICAgIHNlbGYgZXJyb3I6ICdpbmZpbml0ZSByZWN1 cnNpb24gaW4gZG9lc05vdFVuZGVyc3RhbmQ6J11dDSEgIQ0= --==CelesteAttachment75902==-- --=--