[Pharo-project] Xtreme Pharo hacker needed :)
Hi, I struggle for a functionality I want to add on Autotest. Suppose a class with two methods A and B, such as A senders of B Zork>>methodA self methodB And unit tests: ZorkTest>>testSomething ..... Zork new methodA ... self assert: .... If I change methodA, Autotest detects it, search all senders of methodA in tests and run. As ZorkTest>>testSomething is sender of Zork>>methodA, it will find and run it. Now if I change methodB and there's no senders in tests, the previous heuristic won't work. So I added as last heuristic: if no method found, search all TestCases that references the changed method class and run. So here it will find ZorkTest and run all its tests. The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests. So I want to detect this. One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ? So in Autotest>>findRunAndShowTestsOf: I try something like this Autotest>>findRunAndShowTestsOf:changedMethod | testMethods aTestResult methodHit | "Finds the test related to changedMethod, run them and tell the view to update" testMethods := search methodsFor: changedMethod. methodHit := false. thisContext sender runSimulated: [aTestResult := runner run: testMethods] contextAtEachStep: [:current| (current method = changedMethod) "<--- here I detect if changedMethod has been hit" ifTrue: [methodHit := true]]. ..... but using this debugger opens with "SimulationGuardException: triggered by BlockClosure>>newProcess" in MethodContext>>doPrimitive:method:receiver:args: As I don't (yet :) understand all this stuff, I want to know if it's the right way to do it and what should I check. Thanks Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ? So in Autotest>>findRunAndShowTestsOf: I try something like this Autotest>>findRunAndShowTestsOf:changedMethod   | testMethods aTestResult methodHit |   "Finds the test related to changedMethod, run them and tell the view to update" testMethods := search methodsFor: changedMethod. methodHit := false. thisContext sender runSimulated: [aTestResult := runner run: testMethods] contextAtEachStep: [:current| (current method = changedMethod)   "<--- here I detect if changedMethod has been hit"     ifTrue: [methodHit := true]].      ..... but using this debugger opens with "SimulationGuardException: triggered by BlockClosure>>newProcess" in MethodContext>>doPrimitive:method:receiver:args: As I don't (yet :) understand all this stuff, I want to know if it's the right way to do it and what should I check.
This is the stepping mechanism of the debugger. It is dead slow, and likely to break when you fork processes, mess with the stack, or hit other kinds of primitives. I would use method wrappers, they are much easier to use, less error prone, very efficient, and already integrated with the test runner (see the in the GUI code: 'test coverage'). Lukas -- Lukas Renggli www.lukas-renggli.ch
On Sun, Jun 27, 2010 at 5:39 PM, Lukas Renggli <renggli@gmail.com> wrote:
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ? So in Autotest>>findRunAndShowTestsOf: I try something like this Autotest>>findRunAndShowTestsOf:changedMethod | testMethods aTestResult methodHit | "Finds the test related to changedMethod, run them and tell the view to update" testMethods := search methodsFor: changedMethod. methodHit := false. thisContext sender runSimulated: [aTestResult := runner run: testMethods] contextAtEachStep: [:current| (current method = changedMethod) "<--- here I detect if changedMethod has been hit" ifTrue: [methodHit := true]]. ..... but using this debugger opens with "SimulationGuardException: triggered by BlockClosure>>newProcess" in MethodContext>>doPrimitive:method:receiver:args: As I don't (yet :) understand all this stuff, I want to know if it's the right way to do it and what should I check.
This is the stepping mechanism of the debugger. It is dead slow, and likely to break when you fork processes, mess with the stack, or hit other kinds of primitives.
I would use method wrappers, they are much easier to use, less error prone, very efficient, and already integrated with the test runner (see the in the GUI code: 'test coverage').
Thank you Lukas ! I will have a look. Laurent
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Laurent, Perhaps I am missing something but you only need 2 conditions to detect what you are looking for: 1) changed method is a test (and defined in a subclass of TestCase) 2) changed method has a sender that is a test method ----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: laurent.laffont@gmail.com Date: Sun, 27 Jun 2010 17:33:53 +0200 To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Xtreme Pharo hacker needed :) Hi, I struggle for a functionality I want to add on Autotest. Suppose a class with two methods A and B, such as A senders of B Zork>>methodA self methodB And unit tests: ZorkTest>>testSomething ..... Zork new methodA ... self assert: .... If I change methodA, Autotest detects it, search all senders of methodA in tests and run. As ZorkTest>>testSomething is sender of Zork>>methodA, it will find and run it. Now if I change methodB and there's no senders in tests, the previous heuristic won't work. So I added as last heuristic: if no method found, search all TestCases that references the changed method class and run. So here it will find ZorkTest and run all its tests. The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests. So I want to detect this. One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ? So in Autotest>>findRunAndShowTestsOf: I try something like this Autotest>>findRunAndShowTestsOf:changedMethod | testMethods aTestResult methodHit | "Finds the test related to changedMethod, run them and tell the view to update" testMethods := search methodsFor: changedMethod. methodHit := false. thisContext sender runSimulated: [aTestResult := runner run: testMethods] contextAtEachStep: [:current| (current method = changedMethod) "<--- here I detect if changedMethod has been hit" ifTrue: [methodHit := true]]. ..... but using this debugger opens with "SimulationGuardException: triggered by BlockClosure>>newProcess" in MethodContext>>doPrimitive:method:receiver:args: As I don't (yet :) understand all this stuff, I want to know if it's the right way to do it and what should I check. ThanksLaurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ _________________________________________________________________ MSN Dating: Find someone special. Start now. http://go.microsoft.com/?linkid=9734384
2010/6/27 Benoit St-Jean <bstjean@hotmail.ca>
Hi Laurent,
Perhaps I am missing something but you only need 2 conditions to detect what you are looking for:
1) changed method is a test (and defined in a subclass of TestCase) 2) changed method has a sender that is a test method
First Autotest versions have these two heuristics. Then I feel the need to add: - change method is a setUp or tearDown -> run all tests of TestCase - and now when there's no senders of changed method in a TestCase (a private method for example) -> try to find tests of the changed method class (I think it can be better but I have no other solution yet) Indeed, using Autotest I feel the need to be sure that the method I've changed has been called. I would like to see a warning if it's not the case. Cheers Laurent
----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
------------------------------ From: laurent.laffont@gmail.com Date: Sun, 27 Jun 2010 17:33:53 +0200 To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Xtreme Pharo hacker needed :)
Hi,
I struggle for a functionality I want to add on Autotest. Suppose a class with two methods A and B, such as A senders of B
Zork>>methodA self methodB
And unit tests:
ZorkTest>>testSomething ..... Zork new methodA ... self assert: ....
If I change methodA, Autotest detects it, search all senders of methodA in tests and run. As ZorkTest>>testSomething is sender of Zork>>methodA, it will find and run it.
Now if I change methodB and there's no senders in tests, the previous heuristic won't work. So I added as last heuristic: if no method found, search all TestCases that references the changed method class and run. So here it will find ZorkTest and run all its tests. The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
So in Autotest>>findRunAndShowTestsOf: I try something like this
Autotest>>findRunAndShowTestsOf:changedMethod | testMethods aTestResult methodHit | "Finds the test related to changedMethod, run them and tell the view to update" testMethods := search methodsFor: changedMethod. methodHit := false. thisContext sender runSimulated: [aTestResult := runner run: testMethods] contextAtEachStep: [:current| (current method = changedMethod) "<--- here I detect if changedMethod has been hit" ifTrue: [methodHit := true]]. .....
but using this debugger opens with "SimulationGuardException: triggered by BlockClosure>>newProcess" in MethodContext>>doPrimitive:method:receiver:args:
As I don't (yet :) understand all this stuff, I want to know if it's the right way to do it and what should I check.
Thanks
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
------------------------------ Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! <http://go.microsoft.com/?linkid=9734379>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
just in case...in http://www.squeaksource.com/ObjectMetaTools you have interesting packages like MethodWrappers. It sohuld be working in pharo. cheers mariano 2010/6/27 laurent laffont <laurent.laffont@gmail.com>
2010/6/27 Benoit St-Jean <bstjean@hotmail.ca>
Hi Laurent,
Perhaps I am missing something but you only need 2 conditions to detect what you are looking for:
1) changed method is a test (and defined in a subclass of TestCase) 2) changed method has a sender that is a test method
First Autotest versions have these two heuristics. Then I feel the need to add: - change method is a setUp or tearDown -> run all tests of TestCase - and now when there's no senders of changed method in a TestCase (a private method for example) -> try to find tests of the changed method class (I think it can be better but I have no other solution yet)
Indeed, using Autotest I feel the need to be sure that the method I've changed has been called. I would like to see a warning if it's not the case.
Cheers
Laurent
----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
------------------------------ From: laurent.laffont@gmail.com Date: Sun, 27 Jun 2010 17:33:53 +0200 To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Xtreme Pharo hacker needed :)
Hi,
I struggle for a functionality I want to add on Autotest. Suppose a class with two methods A and B, such as A senders of B
Zork>>methodA self methodB
And unit tests:
ZorkTest>>testSomething ..... Zork new methodA ... self assert: ....
If I change methodA, Autotest detects it, search all senders of methodA in tests and run. As ZorkTest>>testSomething is sender of Zork>>methodA, it will find and run it.
Now if I change methodB and there's no senders in tests, the previous heuristic won't work. So I added as last heuristic: if no method found, search all TestCases that references the changed method class and run. So here it will find ZorkTest and run all its tests. The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
So in Autotest>>findRunAndShowTestsOf: I try something like this
Autotest>>findRunAndShowTestsOf:changedMethod | testMethods aTestResult methodHit | "Finds the test related to changedMethod, run them and tell the view to update" testMethods := search methodsFor: changedMethod. methodHit := false. thisContext sender runSimulated: [aTestResult := runner run: testMethods] contextAtEachStep: [:current| (current method = changedMethod) "<--- here I detect if changedMethod has been hit" ifTrue: [methodHit := true]]. .....
but using this debugger opens with "SimulationGuardException: triggered by BlockClosure>>newProcess" in MethodContext>>doPrimitive:method:receiver:args:
As I don't (yet :) understand all this stuff, I want to know if it's the right way to do it and what should I check.
Thanks
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
------------------------------ Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! <http://go.microsoft.com/?linkid=9734379>
_______________________________________________ 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/6/28 Mariano Martinez Peck <marianopeck@gmail.com>
just in case...in http://www.squeaksource.com/ObjectMetaTools
you have interesting packages like MethodWrappers. It sohuld be working in pharo.
Thanks, I will have a look. I've commited a (experimental) version of Autotest which counts hit on the modified method and displays it in the dashboard. It was quite tricky to develop it with unit tests & threads but fun. This sort of code you write and say "waouh this is really cool !". Thank you all ! I really like the hit count in the dashboard, brings confidence. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
cheers
mariano
2010/6/27 laurent laffont <laurent.laffont@gmail.com>
2010/6/27 Benoit St-Jean <bstjean@hotmail.ca>
Hi Laurent,
Perhaps I am missing something but you only need 2 conditions to detect what you are looking for:
1) changed method is a test (and defined in a subclass of TestCase) 2) changed method has a sender that is a test method
First Autotest versions have these two heuristics. Then I feel the need to add: - change method is a setUp or tearDown -> run all tests of TestCase - and now when there's no senders of changed method in a TestCase (a private method for example) -> try to find tests of the changed method class (I think it can be better but I have no other solution yet)
Indeed, using Autotest I feel the need to be sure that the method I've changed has been called. I would like to see a warning if it's not the case.
Cheers
Laurent
----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
------------------------------ From: laurent.laffont@gmail.com Date: Sun, 27 Jun 2010 17:33:53 +0200 To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Xtreme Pharo hacker needed :)
Hi,
I struggle for a functionality I want to add on Autotest. Suppose a class with two methods A and B, such as A senders of B
Zork>>methodA self methodB
And unit tests:
ZorkTest>>testSomething ..... Zork new methodA ... self assert: ....
If I change methodA, Autotest detects it, search all senders of methodA in tests and run. As ZorkTest>>testSomething is sender of Zork>>methodA, it will find and run it.
Now if I change methodB and there's no senders in tests, the previous heuristic won't work. So I added as last heuristic: if no method found, search all TestCases that references the changed method class and run. So here it will find ZorkTest and run all its tests. The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
So in Autotest>>findRunAndShowTestsOf: I try something like this
Autotest>>findRunAndShowTestsOf:changedMethod | testMethods aTestResult methodHit | "Finds the test related to changedMethod, run them and tell the view to update" testMethods := search methodsFor: changedMethod. methodHit := false. thisContext sender runSimulated: [aTestResult := runner run: testMethods] contextAtEachStep: [:current| (current method = changedMethod) "<--- here I detect if changedMethod has been hit" ifTrue: [methodHit := true]]. .....
but using this debugger opens with "SimulationGuardException: triggered by BlockClosure>>newProcess" in MethodContext>>doPrimitive:method:receiver:args:
As I don't (yet :) understand all this stuff, I want to know if it's the right way to do it and what should I check.
Thanks
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
------------------------------ Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! <http://go.microsoft.com/?linkid=9734379>
_______________________________________________ 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
The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf , Section 2.2 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf<http://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf>, Section 2.2
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book. Laurent
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 27.06.2010 20:20, laurent laffont wrote:
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre@bergel.eu <mailto:alexandre@bergel.eu>> wrote:
> The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests. > > So I want to detect this. > > One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf <http://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf> , Section 2.2
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.
Laurent
Note: The Cog VM crashes on TestObjectsAsMethods. Cheers, Henry
2010/6/27 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>
On 27.06.2010 20:20, laurent laffont wrote:
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf<http://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf>, Section 2.2
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.
Laurent
Note: The Cog VM crashes on TestObjectsAsMethods.
Coding a wrapper the TDD way seems tricky, my image is lost as assert: failed, so uninstall not done and since all is upside down... :) Laurent
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/6/27 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>
On 27.06.2010 20:20, laurent laffont wrote:
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf<http://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf>, Section 2.2
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.
Laurent
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people? best Eliot
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. Â I never tried to get this to work. Â How important is this to people?
It is quite important. Most prominently it is used in the test runner to calculate test coverage. Also the Method Wrappers of the refactoring engine use it and various research projects (Persephone, Reflectivity, ...) use it. Lukas -- Lukas Renggli www.lukas-renggli.ch
Hi eliot this was used quite a lot for a lot of infrastructure. For example, persephone put ast that gets recompile on the fly. so this is a nice MOP entry point. Stef On Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote:
2010/6/27 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> On 27.06.2010 20:20, laurent laffont wrote:
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre@bergel.eu> wrote:
The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf , Section 2.2
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.
Laurent
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
best Eliot
Cheers, Henry
_______________________________________________ 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 Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote:
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
For Research: very. Lots of the experiments we did at SCG used this at least at some stage of implementing the prototype: -> For the AOSTa experiments I looked at it originally (see http://www.slideshare.net/MarcusDenker/diplom-vortrag-slides) -> Persephone and therefore Reflectivity: http://scg.unibe.ch/research/reflectivity -> ChangeBoxes used it: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract -> I think ClassBoxes, too -> The most commonly used implementation of MethodWrappers these days uses it (and is *much* simpler than the method-compilation-stub-generating one) It's a quite nice way to hook into "method execution" without having to resort to compile a stub method. If you need an "in-image" JIT of some sort, it provides a real nice way of doing this purely from the image side (no VM change needed): http://scg.unibe.ch/scgbib?query=Denk07b&display=abstract I think Andreas originally suggested ObjectsAsMethods years ago and I then made sure that it was integrated in the VM, as the AOStA experiments showed how powerful this can be for experiments. AOStA had to use a patched VM, then later persephone could run on a standard VM, which simplified things a lot... Yes, stub-methods can do anything (and with care can be faster), and having a good code-generation framework simplified actually doing this a lot.... e.g. one can use bytesurgeon and do it on the level of bytecode. (the paper uses MethodWrappers as an example: http://scg.unibe.ch/cgi-bin/scgbib.cgi/abstract=yes?Denk06a) Or just the RB AST (with the code generator), maybe helped by Helvetia's quoting... (more on Helevetia's quoting implementation: http://scg.unibe.ch/research/helvetia/languageboxes) Nut nevertheless: a MOP for method execution is very valuable not just from an implementation standpoint, even more from a concepual / thinking point of view. Good MOPs provide a better way of *thinking*, they enable exploration. I always rated this as one of those changes that, while being simple, opened up a lot of space for experiments. And it showed to me the value of a platform where a change like this is integrated and not ignored. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
+1 on this. Marcus, we have to talk about Persephone when I'm visiting in Sept! On 28 Jun 2010, at 13:10, Marcus Denker wrote:
On Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote:
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
For Research: very. Lots of the experiments we did at SCG used this at least at some stage of implementing the prototype:
-> For the AOSTa experiments I looked at it originally (see http://www.slideshare.net/MarcusDenker/diplom-vortrag-slides) -> Persephone and therefore Reflectivity: http://scg.unibe.ch/research/reflectivity -> ChangeBoxes used it: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract -> I think ClassBoxes, too -> The most commonly used implementation of MethodWrappers these days uses it (and is *much* simpler than the method-compilation-stub-generating one)
It's a quite nice way to hook into "method execution" without having to resort to compile a stub method. If you need an "in-image" JIT of some sort, it provides a real nice way of doing this purely from the image side (no VM change needed):
http://scg.unibe.ch/scgbib?query=Denk07b&display=abstract
I think Andreas originally suggested ObjectsAsMethods years ago and I then made sure that it was integrated in the VM, as the AOStA experiments showed how powerful this can be for experiments.
AOStA had to use a patched VM, then later persephone could run on a standard VM, which simplified things a lot...
Yes, stub-methods can do anything (and with care can be faster), and having a good code-generation framework simplified actually doing this a lot.... e.g. one can use bytesurgeon and do it on the level of bytecode. (the paper uses MethodWrappers as an example: http://scg.unibe.ch/cgi-bin/scgbib.cgi/abstract=yes?Denk06a) Or just the RB AST (with the code generator), maybe helped by Helvetia's quoting... (more on Helevetia's quoting implementation: http://scg.unibe.ch/research/helvetia/languageboxes)
Nut nevertheless: a MOP for method execution is very valuable not just from an implementation standpoint, even more from a concepual / thinking point of view. Good MOPs provide a better way of *thinking*, they enable exploration.
I always rated this as one of those changes that, while being simple, opened up a lot of space for experiments.
And it showed to me the value of a platform where a change like this is integrated and not ignored.
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
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi Laurent, I have been playing with the Autotest tool and it's quite cool! One major enhancement suggestion. Let's say we have a test method defined as such: testWhatever ^self somethingElse or: [self testSomethingDifferent]. Removing the method #somethingElse or #testSomethingDifferent from the system won't trigger the listener to run the test #testWhatever since you only check for new methods and modified methods. But what happens if we remove a method (called from a test method) and that would break the test? I think this should be handled as well. Besides, another suggestion, why wouldn't we queue the modified methods events instead of ignoring them when the current process is still running a test and has not yet completed? I also suggest that logging should include the test result (not only time & method name). Finally, thanks for such a great tool! ----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) _________________________________________________________________ Look 'em in the eye: FREE Messenger video chat http://go.microsoft.com/?linkid=9734386
Added removal support for Autotest. FileOut file included. ----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) _________________________________________________________________ MSN Dating: Find someone special. Start now. http://go.microsoft.com/?linkid=9734384
On Mon, Jun 28, 2010 at 12:42 AM, Benoit St-Jean <bstjean@hotmail.ca> wrote:
Added removal support for Autotest.
FileOut file included.
Thank you. Would you like to write a test for it ? See AutotestTestListener>>#testCallbackOnAddedMethod and #testCallbackOnModifiedMethod. Don't hesitate to commit directly in the repository, it's public write. Laurent
----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ------------------------------ Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! <http://go.microsoft.com/?linkid=9734379>
On Mon, Jun 28, 2010 at 12:21 AM, Benoit St-Jean <bstjean@hotmail.ca> wrote:
Hi Laurent,
I have been playing with the Autotest tool and it's quite cool!
Thank you ! One major enhancement suggestion.
Let's say we have a test method defined as such:
testWhatever ^self somethingElse or: [self testSomethingDifferent].
Removing the method #somethingElse or #testSomethingDifferent from the system won't trigger the listener to run the test #testWhatever since you only check for new methods and modified methods.
But what happens if we remove a method (called from a test method) and that would break the test? I think this should be handled as well.
Yes, you're right.
Besides, another suggestion, why wouldn't we queue the modified methods events instead of ignoring them when the current process is still running a test and has not yet completed?
First, when a second event occurs I may not have the time to see the result of the first event. Log can be a solution, but I have to click somewhere to open it or bloat the GUI. Second, I've faced a problem when the tests call a method which programmatically add/modify/remove a method as it will send an event, run the tests again, event again and so on => infinite loop. So there may be a better solution but for now the simplest thing I've found is to process only the first event.
I also suggest that logging should include the test result (not only time & method name).
Yes it's planned + the list of all tests run so we can manually check heuristics.
Finally, thanks for such a great tool!
Thanks for feedback Laurent
----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
------------------------------ Turn down-time into play-time with Messenger games Play Now!<http://go.microsoft.com/?linkid=9734381>
participants (10)
-
Alexandre Bergel -
Benoit St-Jean -
Eliot Miranda -
Henrik Sperre Johansen -
Johan Fabry -
laurent laffont -
Lukas Renggli -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse