June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Changing color/fillStyle by morph halo menu in 1.1rc2

by Denis Kudriashov

I done slice for this. See http://code.google.com/p/pharo/issues/detail?id=2595 2010/6/27 Denis Kudriashov <dionisiydk(a)gmail.com> > I can't see full morph appearance. I just see what color I select. > But It's nothing because I need see my little changes in full morph > appearance. > > For example color of button should satisfy color of pane. And when I change > button color I want immediately see full picture of my application view. > > I think It is very important for UI design. > > 2010/6/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > I do not understand because you can see the selected color in the selected >> color little pane. >> Is it not what you need? >> Stef] >> On Jun 27, 2010, at 11:53 AM, Denis Kudriashov wrote: >> >> > I try last Pharo 1.1 rc2 10.06.10. >> > >> > I found that tool for changing color by user is changed. >> ColorPickerMorph is removed. Now I can't dynamically change color by mouse >> and see my changes immediately. Now I must select color in new tool, press >> ok button. And after that tool close and I must open it again if I dont like >> my changes. >> > >> > It is bad behavior compare with pharo 1.0/squeak. But I really like new >> color picker morph. >> > >> > New tool is ColorSelectorDialogWindow. >> > How I can hookup It for tracking color selection? >> > Maybe I must add some event triggering in #basicSelectedColor: method. >> > But I see many #changed: sends in #basicSelectedColor: method. And maybe >> I already can implement some dependent class for needed stuff. >> > >> > What you think? >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

June 27, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by laurent laffont

2010/6/27 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > On 27.06.2010 20:20, laurent laffont wrote: > > > On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 27, 2010

[Pharo-project] [update 1.2] #12019

by StÃ©phane Ducasse

12019 ----- - Issue 156: Pointer tracing tools do not consistently find pointers. Thanks andy, johan and matthew. Stef

June 27, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by Henrik Sperre Johansen

On 27.06.2010 20:20, laurent laffont wrote: > > On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre(a)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

June 27, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by laurent laffont

2010/6/27 Benoit St-Jean <bstjean(a)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(a)gmail.com > Date: Sun, 27 Jun 2010 17:33:53 +0200 > To: pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 27, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by laurent laffont

On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <alexandre(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 27, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by Alexandre Bergel

> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 27, 2010

[Pharo-project] [update 1.2] #12018

by stephane ducasse

12018 ----- - Issue 2593: SystemNavigation#allSendersOf: returns inexisting references - Issue 2480: make and:and:and:and: and and:and: deprecated Stef

June 27, 2010

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

by Philippe Marschall

On 27.06.2010 15:39, GermÃ¡n Arduino wrote: > Hi Philippe: > > What is bad with xmlrpc? A lot of sites are using it to expose its data.... Like whom? Cheers Philippe

June 27, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by laurent laffont

On Sun, Jun 27, 2010 at 5:39 PM, Lukas Renggli <renggli(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 27, 2010