[Pharo-project] Why has MethodFinder a fixed list of results?
Dear list, I was showing off Pharo to a colleague today and was surprised that. My quick introduction of adding new methods on existing system classes String>>firstLetter ^self copyFrom: 1 to: 1 - extension on String worked immediately. But that: in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added .... :-( Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? Kind Regards, Bart
On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote:
Dear list,
I was showing off Pharo to a colleague today and was surprised that.
My quick introduction of adding new methods on existing system classes
String>>firstLetter ^self copyFrom: 1 to: 1
- extension on String worked immediately. But that:
in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added .... :-(
Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )?
The rational is that the MethodFinder would, if it would not have a positive list, quite likely call methods that do bad things to the state of the system. Remember that is just calls all methods to check if some leads to the return value that you gave! e.g. Smalltalk.true. takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list. It would of course be nice to be able to not need a positive list. The question of how to control side-effects (and how to realize a secure yet reflective language in general) is of course a very interesting one... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Smalltalk.true.
takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list.
Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way. Just look at the lists and how many methods you find that have been removed years ago... It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
2010/8/27 Marcus Denker <marcus.denker@inria.fr>
Smalltalk.true.
takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list.
Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way.
Just look at the lists and how many methods you find that have been removed years ago...
It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example.
So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation. best, Eliot
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot, I think the simulation path is good suggestion. Did a quick test for instance on: ContextPart class>>trace: aBlock on: aStream and modified ^ thisContext sender runSimulated: aBlock contextAtEachStep: [:current | (current receiver == Smalltalk) "added" ifTrue: [self error: 'you cant do this ...']. "added" Sensor anyButtonPressed ifTrue: [^ nil]. and then evaluate: ContextPart trace: ['test' perform: #firstLetter]. => works fine, just prints the trace, ContextPart trace: [Smalltalk printString]. => throws the error. and with a nested piece of code that is also to be illegal : String>>illegalFirstLetter Smalltalk printString. ^self copyFrom: 1 to: 1 ContextPart trace: ['test' perform: #illegalFirstLetter]. => also throws the error :-). Meaning if we keep a negative list of combinations of receiver / or messages, (instead of just the (current receiver == Smalltalk) "added" ifTrue: [self error: 'you cant do this ...']. "added") it is possible to throw errors on nested code that is not be executed ... . Something to try out ... Kind Regards, Bart 2010/8/27 Eliot Miranda <eliot.miranda@gmail.com>
2010/8/27 Marcus Denker <marcus.denker@inria.fr>
Smalltalk.true.
takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list.
Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way.
Just look at the lists and how many methods you find that have been removed years ago...
It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example.
So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation.
best, Eliot
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill
Ok if I understand you mean you interpret everything on the copy of the inputs and you run until you either get an ok primitives or you stop on not ok one. Could be a nice way to stress runSimulated: :) Stef
Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way.
Just look at the lists and how many methods you find that have been removed years ago...
It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example.
So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation.
best, Eliot
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Aug 27, 2010 at 1:30 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Ok if I understand you mean you interpret everything on the copy of the inputs and you run until you either get an ok primitives or you stop on not ok one.
Right, /and/ you stop whenever an attempt is made to write to an object not created during the simulation. So one has to trap primitives new, new: & shallowCopy and collect the results along with the copies of the initial arguments. These objects are safe to write to because they were created as one simulates. Anything else is an error. Could be a nice way to stress runSimulated: :)
Interesting to see if this is useful because runSimulated: is probably at least 100 times slower than executing. An alternative would be to have an execution primitive that entered a special mode that did a GC, installed a page fault handler, advanced the allocation pointer to the next page boundary and then write-protected the entire heap. The error handler would unprotect the entire heap and cause a callback that would raise an exception. So one would run until a write into the heap other than to new space. But this alternative requires lots of VM work and is super tricky. Fingers crossed runSimulated: will work :) cheers Eliot
Stef
Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way.
Just look at the lists and how many methods you find that have been removed years ago...
It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example.
So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation.
best, Eliot
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 28, 2010, at 12:12 AM, Eliot Miranda wrote:
On Fri, Aug 27, 2010 at 1:30 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Ok if I understand you mean you interpret everything on the copy of the inputs and you run until you either get an ok primitives or you stop on not ok one.
Right, /and/ you stop whenever an attempt is made to write to an object not created during the simulation. So one has to trap primitives new, new: & shallowCopy and collect the results along with the copies of the initial arguments. These objects are safe to write to because they were created as one simulates. Anything else is an error.
Excellent we should really try that with ByteSurgeon or reflectivity when Opal is ready.
Could be a nice way to stress runSimulated: :)
Interesting to see if this is useful because runSimulated: is probably at least 100 times slower than executing.
An alternative would be to have an execution primitive that entered a special mode that did a GC, installed a page fault handler, advanced the allocation pointer to the next page boundary and then write-protected the entire heap. The error handler would unprotect the entire heap and cause a callback that would raise an exception. So one would run until a write into the heap other than to new space. But this alternative requires lots of VM work and is super tricky. Fingers crossed runSimulated: will work :)
Yes. I like image level trickery since it stays human :) But we will send you what we are doing with ObjectSpaces when this is in a readable state because each object is marked with his memory space and we have a policy manager per memory region.
cheers Eliot
Stef
Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way.
Just look at the lists and how many methods you find that have been removed years ago...
It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example.
So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation.
best, Eliot
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/27 Marcus Denker <marcus.denker@inria.fr>
On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote:
Dear list,
I was showing off Pharo to a colleague today and was surprised that.
My quick introduction of adding new methods on existing system classes
String>>firstLetter ^self copyFrom: 1 to: 1
- extension on String worked immediately. But that:
in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added .... :-(
Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )?
The rational is that the MethodFinder would, if it would not have a positive list, quite likely call methods that do bad things to the state of the system. Remember that is just calls all methods to check if some leads to the return value that you gave!
e.g.
Smalltalk.true.
takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list.
It would of course be nice to be able to not need a positive list. The question of how to control side-effects (and how to realize a secure yet reflective language in general) is of course a very interesting one...
I'd love for someone to try and implement MethodFinder using simulation. If one used something based on ContextPart runSimulated: to execute the tests the simulation could maintain the set of objects that get instantiated as execution proceeds and only allow writes to these objects. Any attempt to write an object outside the set would cause an error and abandon exploring that alternative. This *might* be fast enough for use, but the experiment would show whether this was the case or not. best Eliot
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/27 Bart Gauquie <bart.gauquie@gmail.com>:
Dear list, I was showing off Pharo to a colleague today and was surprised that.
My quick introduction of adding new methods on existing system classes String>>firstLetter ^self copyFrom: 1 to: 1
- extension on String worked immediately. But that: in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added .... :-( Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? Kind Regards, Bart
Suppose you feed MethodFinder with Array and #() just to check whether #new is found. Will you be happy after MethodFinder has tried if ever Array removeFromSystem just wouldn't return #() ? Nicolas
Now what we should do is probably to get a more dynamic way to tag methods because not methodFinder has a huge baglog of selectors and it is probably not in sync with the system We were thinking about using pragma to tag methods that should not be executed but we need a proof of concept. Stef On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote:
Dear list,
I was showing off Pharo to a colleague today and was surprised that.
My quick introduction of adding new methods on existing system classes
String>>firstLetter ^self copyFrom: 1 to: 1
- extension on String worked immediately. But that:
in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added .... :-(
Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )?
Kind Regards,
Bart
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Bart Gauquie -
Eliot Miranda -
Marcus Denker -
Nicolas Cellier -
Stéphane Ducasse