[squeak-dev] MethodFinder.Blocks

Marcel Taeumel marcel.taeumel at hpi.de
Wed Oct 23 15:11:45 UTC 2019


What about unwanted side effects that are in-image? My precious collection of objects here, my background wallpaper there ... I don't want my wallpaper to turn black and my objects to get lost ... or surprisingly sorted for that matter. :-)

Best,
Marcel
Am 17.10.2019 20:47:57 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Thu, Oct 17, 2019 at 11:13 AM Eliot Miranda <eliot.miranda at gmail.com [mailto:eliot.miranda at gmail.com]> wrote:



On Wed, Oct 16, 2019 at 2:55 AM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de [mailto:Christoph.Thiede at student.hpi.uni-potsdam.de]> wrote:

Hi Marcel,
as I see it, this Blocks check only restricts the possible hits, so removing it should not damage any existing functionality. (I am *not* talking about modifying Dangerous!)
And if you do
MethodFinder methodFor: {{#(1 2). [:x | Smalltalk saveSession. false]}.#()} "pls don't run this!"
you will surely expect the side effects to be executed?

If MethodFinder were implemented using simulation (a la Context class>>runSimulated:) then we could implement a proper sandbox and completely discard Dangerous.  We could catch any attempt to change the class hierarchy, save a snapshot, etc.

It would be a great project to create a subclass of Context, say SandboxContext, and have this ensure that when simulating it only creates more SandboxContexts, never a normal Context, and have SandboxContext override primitive invocation.  This could be a place to intercept modification of the class hierarchy (at:put: & become: on MethodDictionary, and Array to see if an attempt is being made to assign to or become: a MethodDictionary and/or a subclasses Array).  Perhaps SandboxContext would need SandboxClosure, perhaps it could simply intercept value: et al on Closure (see Context>>#doPrimitive:method:receiver:args:).

My gut tells me that while this implementation is clever, it will also be more general and more easily maintainable than the current one.  There are issues; a time limit would have to be placed upon simulated executions (that's also a potential issue for the current implementation).  But it would be safer since instead of relying on Dangerous to identify dangerous code it would depend on a reasonably well-defined notion of sandbox, what is possible to evaluate when searching, and what is not.  One could, for example, implement an instantiation budget in SandboxContext>>#doPrimitive:method:receiver:args:.

> Just curious: what would be the block example for these examples?
MethodFinder methodFor: {{#(1 2). #even}. #(1)}. '(data1 reject: data2) '
MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}. '(data1 sorted: data2) (data1 sort: data2) '

Hey, maybe we should make a small game of it? :-) GuessTheSelectorGame :D
Christoph


Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-bounces at lists.squeakfoundation.org]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 16. Oktober 2019 10:54 Uhr
An: gettimothy via Squeak-dev; squeak-dev at mail.squeak.org [mailto:squeak-dev at mail.squeak.org]
Betreff: Re: [squeak-dev] MethodFinder.Blocks
 
Hi, Christoph.

The method finder (or selector browser) has a hard-coded list of possible results (or messages) to not trigger dangerous side effects. Any new feature, such as that "quasi higher-order-message" symbol , would have to be added. Sure. But keep compatiblility with block arguments. :-)

Just curious: what would be the block example for these examples?

MethodFinder methodFor: {{#(1 2). #even}. #(1)}
MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}.

Especially the latter seems kind of cryptic to me.

Best,
Marcel

Am 14.10.2019 01:27:12 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de [mailto:christoph.thiede at student.hpi.uni-potsdam.de]>:
Hi all,

I just got irritated as I evaluated

MethodFinder methodFor: {{#(1 2). #even}. #(1)}

and got no hit.
This is because the MethodFinder stores an extra list of selector parameters that are assumed to require a block argument (Blocks) -- but nowadays this requirement is not given, as you can pass a Symbol, MessageSend, SortFunction or whatsoever, thanks to polymorphy. So (how) is this block check still relevant? If I remove it, I get the right hit and can do thinks like

MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}.


Also, #ifError: will prevent any error thrown if the block does not match the selector.

Looking forward to your answers :)
Christoph



--

_,,,^..^,,,_

best, Eliot


--

_,,,^..^,,,_

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191023/5b1477cc/attachment.html>


More information about the Squeak-dev mailing list