Xtreme Pharo hacker needed :)
Locked
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/ _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by laurent laffont
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: [hidden email] Date: Sun, 27 Jun 2010 17:33:53 +0200 To: [hidden email] 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! _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by Lukas Renggli
On Sun, Jun 27, 2010 at 5:39 PM, Lukas Renggli <[hidden email]> wrote:
Thank you Lukas ! I will have a look. Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by laurent laffont
> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <[hidden email]> wrote:
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book. Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by Benoit St-Jean-2
2010/6/27 Benoit St-Jean <[hidden email]>
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by laurent laffont
On 27.06.2010 20:20, laurent laffont wrote:
Note: The Cog VM crashes on TestObjectsAsMethods. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
2010/6/27 Henrik Sperre Johansen <[hidden email]>
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Autotest enhancement suggestions
|
|
In reply to this post by laurent laffont
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) Turn down-time into play-time with Messenger games Play Now! _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Autotest enhancement suggestions
|
|
Added removal support for Autotest.
FileOut file included. ----------------- 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! _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
AutotestListener-installSystemNotifications.st (596 bytes)
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by Henrik Sperre Johansen
2010/6/27 Henrik Sperre Johansen <[hidden email]>
Yes. I never tried to get this to work. How important is this to people? best Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Xtreme Pharo hacker needed :)
|
|
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by Eliot Miranda-2
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 <[hidden email]> > On 27.06.2010 20:20, laurent laffont wrote: >> >> On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Autotest enhancement suggestions
|
|
In reply to this post by Benoit St-Jean-2
On Mon, Jun 28, 2010 at 12:21 AM, Benoit St-Jean <[hidden email]> wrote:
Thank you !
Yes, you're right.
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.
Yes it's planned + the list of all tests run so we can manually check heuristics.
Thanks for feedback Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Autotest enhancement suggestions
|
|
In reply to this post by Benoit St-Jean-2
On Mon, Jun 28, 2010 at 12:42 AM, Benoit St-Jean <[hidden email]> wrote:
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by laurent laffont
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 <[hidden email]>
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
2010/6/28 Mariano Martinez Peck <[hidden email]> just in case...in http://www.squeaksource.com/ObjectMetaTools 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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Xtreme Pharo hacker needed :)
|
|
In reply to this post by Eliot Miranda-2
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
+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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |