MethodFinder.Blocks

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

Am 14.10.2019 01:27:12 schrieb Thiede, Christoph <[hidden email]>:

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

MethodFinder methodFor: {{#(1 2). [:x | Smalltalk saveSession. false]}.#()} "pls don't run this!"

Am 17.10.2019 20:47:57 schrieb Eliot Miranda <[hidden email]>:

On Thu, Oct 17, 2019 at 11:13 AM Eliot Miranda <[hidden email]> wrote:

On Wed, Oct 16, 2019 at 2:55 AM Thiede, Christoph <[hidden email]> 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 <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 16. Oktober 2019 10:54 Uhr
An: gettimothy via Squeak-dev; [hidden email]
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 <[hidden email]>:

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

Am 25.10.2019 01:02:03 schrieb Eliot Miranda <[hidden email]>:

Hi Marcel,

On Wed, Oct 23, 2019 at 8:11 AM Marcel Taeumel <[hidden email]> wrote:

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. :-)

Right.  The approach that I'd figured out a while ago but forgot to state below is that the simulation MethodFinder SandboxContext can maintain a set of objects that it has instantiated and allow assignments only to them.  So any attempt to modify any object that has't been created while performing the method search could be easily prevented.  To do this SandboxContext would have to intercept any and all invocations of the new primitives, plus primitives that create objects such as large integer arithmetic primitives, to collect the results in its "set of writable objects".  Then it would intercept any state altering primitives (at:put: et al) and inst var assignment etc (popIntoReceiverVariable:, popIntoLiteralVariable: et al), and abort the current sub-search if the target was not in the set.

 And if required, exceptions could be added to the set on initialization; global variables whose value could be expected to change often perhaps (caches in class variables?).  The set of writable objects could be organized as a Dictionary from object to evaluable that answers whether a particular index is valid to modify the object, etc.  But the basic idea is that SandboxContext is in a position to mediate any and all accesses while simulating execution and hence selectively prevent assignment to anything, and only allow assignment to specific things.  I apologize for having forgotten to state this earlier.

 

Best,

Marcel

Am 17.10.2019 20:47:57 schrieb Eliot Miranda <[hidden email]>:

On Thu, Oct 17, 2019 at 11:13 AM Eliot Miranda <[hidden email]> wrote:

On Wed, Oct 16, 2019 at 2:55 AM Thiede, Christoph <[hidden email]> 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 <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 16. Oktober 2019 10:54 Uhr
An: gettimothy via Squeak-dev; [hidden email]
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 <[hidden email]>:

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

--

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

best, Eliot

Hi Eliot,

sounds very interesting! :D Respecting a practical aspect, in which degree would such a SandboxContext lower performance? The MethodFinder is running a big amount of methods and it should not take minutes ...

Best,

Christoph