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

Re: [Pharo-project] About TDD and Pharo

by Hernan Wilkinson

cool! I did not know about it... I have some questions... if you are writting a test in the browser and want to run it (just test), if you press ctr+t, does it run that test or all the tests? and also, if it does not save the method, how does it run the test you just wrote ? I did the ctrl+t do the save before running because I found myself saving then running, saving then running, etc, all the time... and if you want to run the test you have to save it before... why do you think you would not like the two things combined? do you see something that could bother or be wrong about it? On Fri, Jun 4, 2010 at 1:36 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > OBSUnitIntegration is already providing some of those: > > > 1) When you are in the browser writing a test method, you can press ctrl > + t > > to save the method and run the test. If the test runs, it will show the > > green dot in the browser, if it does not, it popups the debugger directly > on > > the error. So, this is a way to avoid pressing ctrl + s (save) then going > to > > the method list, rigth click an select run test and if it fails select > that > > you want to debug it. > > Ctrl+T does not save, but it runs the tests and shows the debugger. I > don't think that I like the two things to be combined :-) > > > 2) Same as ctrl + t but ctrl + r to directly debug the test. It saves the > > method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo > > breakpoints dont show very well in the debuger (it highlights incorrect > > collaborations) > > Ctrl+D opens a full debugger on the first line of the selected test, > no matter if the test fails or not. It doesn't use breakpoints. And I > use it all the time :-) > > So maybe we could combine some of that code? > > 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 4, 2010

Re: [Pharo-project] Pharo sprint @ Brussels

by Tudor Girba

Hi, I will join. On Friday, I will probably not be there the whole day, but I do not know yet when exactly. Cheers, Doru On 4 Jun 2010, at 10:34, Johan Brichau wrote: > Hi everyone, > > This is just a reminder that if you are planning to attend the Pharo > sprint in Brussels on friday 11 and saturday 12 June, please fill in > your name on the wiki or respond in this thread. > Also, if you do not plan on attending both days, let us know. > > We need to know how many sandwiches to order for lunch :-) > > Cheers > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

June 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Mariano Martinez Peck

On Fri, Jun 4, 2010 at 10:40 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> > 1) When you are in the browser writing a test method, you can press > ctrl > >> > + t > >> > to save the method and run the test. If the test runs, it will show > the > >> > green dot in the browser, if it does not, it popups the debugger > >> > directly on > >> > the error. So, this is a way to avoid pressing ctrl + s (save) then > >> > going to > >> > the method list, rigth click an select run test and if it fails select > >> > that > >> > you want to debug it. > >> > >> Ctrl+T does not save, but it runs the tests and shows the debugger. I > >> don't think that I like the two things to be combined :-) > > > > That's what I don't like, ctrl + t runs all the tests of the class, not > only > > the method were you are. > > No, this is not the case. > Ups...spoke faster than speaking. It's true, Pharo 1.1 with the latests OB it works as expected. Can we just change the label "run tests" to "run test" ? Thanks lukas mariano > > > This was discussed with Adrian Kuhn and he integrated this change in his > > package. I don't know where is it neither if it was integrated or not. > > Yes, I integrated that a year ago or so :-) > > 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 4, 2010

Re: [Pharo-project] Something I don't see in ImageSegment

by Mariano Martinez Peck

2010/6/3 Eliot Miranda <eliot.miranda(a)gmail.com> > Hi Mariano, Hi All, > > response below. But does anyone have any tests for the image segment > primitives? I'm refactoring them and would like some tests. > Hi Eliot. First, congratulations!! I though several times to refactor the primitives what I was not brave enough. I was not confidence of myself hahaha Originally, ImageSegment didn't have a single test. Only some class side examples that in Pharo at least were not even working. Adrian Lienhard wrote the first 2 or 3 tests for them. Then I needed to understand ImageSegment for my PhD, and the best way to understand them were writing unit tests ;) So, now if you take a Pharo 1.1 image you will see there are 26 tests. The classes are ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap. The tests are quite simple and cover not too much. They can be improved and there are more to write. They may be even not completly correct as I wrote them to understand ImageSegment, not because I already understood them ;) In addition, there is one failing that I yet don't understand why: #testOutPointers3 I asked in mailing list but not really an answer in my opinion: http://forum.world.st/Something-I-don-t-understand-with-ImageSegments-tp129… If you know why it is failing, tell me :) continue answering above... > > 2010/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> > > .... >> >> But here I see it is only marking Interpreter oops, not all objects. And I >> don't see where all objects are marked even in the code that follows this >> little piece. >> > > markInterpreterOops marks all objects accessible from the interpreter oops, > including the specialObjectsArray, recursively marking any unmarked objects > and their referents. i.e. it marks all objects reachable from the roots of > the system. > Ok...but where is the roots of the system? it is the instVar rootTable of ObjectMemory? so all the root table is also marked? At the beginning I though it was this that you are saying. But then I check in the senders of markAndTraceInterpreterOops and you can see in ObjectMemory >> markPhase that it does: "trace the interpreter's objects, including the active stack and special objects array" self markAndTraceInterpreterOops. statSpecialMarkCount := statMarkCount. "trace the roots" 1 to: rootTableCount do: [:i | oop := rootTable at: i. self markAndTrace: oop]. 1 to: extraRootCount do:[:i| oop := (extraRoots at: i) at: 0. (self isIntegerObject: oop) ifFalse:[self markAndTrace: oop]]. So...it is manually iterating the table. Why? shouldn't be done as you told me? In summary, my question is: is these code doing this (iterating the table) even if it is not necessary or ImageSegment should also do it? > This would mark all objects in the system were it not for the fact that the > primitive marks the rootArray and so markInterpreterOops does not marl > objects /only/ reachable from the rootArray. So once the rootArray objects > have been unmarked, only those objects that should go in the image segment > are unmarked. > > So the primitive works by > - marking the objects in rootArray, preventing marking of objects reachable > from them in the next step > - recursively marking all objects reachable from the roots (except those > already marked) > - unmarking root objects, leaving the transitive closure of objects > accessible from the roots and no where else unmarked > - writing the unmarked objects to an image segment > > yes, this is clear :) Thanks for the help. Mariano > > HTH > Eliot > > >> You can see the comment: "Then do a mark pass over all objects" and even >> without the comment it makes sense to mark all objects in order to detect >> outPointers. >> >> Does anyone has a hint? >> >> Thanks >> >> Mariano >> >> _______________________________________________ >> 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 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Lukas Renggli

>> > 1) When you are in the browser writing a test method, you can press ctrl >> > + t >> > to save the method and run the test. If the test runs, it will show the >> > green dot in the browser, if it does not, it popups the debugger >> > directly on >> > the error. So, this is a way to avoid pressing ctrl + s (save) then >> > going to >> > the method list, rigth click an select run test and if it fails select >> > that >> > you want to debug it. >> >> Ctrl+T does not save, but it runs the tests and shows the debugger. I >> don't think that I like the two things to be combined :-) > > That's what I don't like, ctrl + t runs all the tests of the class, not only > the method were you are. No, this is not the case. > This was discussed with Adrian Kuhn and he integrated this change in his > package. I don't know where is it neither if it was integrated or not. Yes, I integrated that a year ago or so :-) Lukas -- Lukas Renggli www.lukas-renggli.ch

June 4, 2010

[Pharo-project] Pharo sprint @ Brussels

by Johan Brichau

Hi everyone, This is just a reminder that if you are planning to attend the Pharo sprint in Brussels on friday 11 and saturday 12 June, please fill in your name on the wiki or respond in this thread. Also, if you do not plan on attending both days, let us know. We need to know how many sandwiches to order for lunch :-) Cheers ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

June 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Michael Roberts

With a few sprints coming and such enthusiasm for our tools this is an opportune thread to remind folks the debugger itself needs some serious work on it. I would suggest doing this first before adding features to it. Any volunteers? 1) pressing send does not always change the highlighted context. You often press send twice to achieve what you want and then sometimes over step. I have debugged into this and in one example it does simulate the bytecode but the debugger does not change. I am trying to write a test for it. See below. 2) highlighting is badly broken. To this end I am trying to write some tests that demonstrate the problems. I am finding it quite hard to write a test harness since debugging it is sometimes a challenge and I get caught out by the simulation guard. Any help/suggestions on the best way to invoke the debugger in this context would be appreciated. It requires quite a deep understanding of the execution machinery... At the moment I create a new process that is suspended and then open the debugger in it using the no suspend api but I am not sure this is the best approach. There are subtleties in the opening protocol which I don't fully understand surrounding what happens to the active process. There is an existing test case that uses semaphores but I have found that approach problematic in what I am trying to do. My basic goal is this and could easily be expressed in a table with columns 1) method source The string of an exactly formatted method 2) Debugger commands Send,send,send,send, 3)highlight interval before 1:14,5:8,12:34 etc The debugger would then be created on the fly invoked on the method and then the sequence of commands replayed and positions checked. Once basic highlighting could be checked I would enhance it to check step, step into block and asserting the top context and other things. Cheers Mike On 4 Jun 2010, at 07:38, Jorge Ressia <jorge.ressia(a)gmail.com> wrote: > I've been using TDDFacilities in Pharo since it was first released. It > is precisely what I needed to achieve real TDD while developing my > tools. > New features in the New Compiler and TextLint (from scratch) were > developed using this tool. > > Doru, if you want I can give you a short demo of it. > > I think that what Hernan is proposing is very important. The debugger > is the tool that TDD developers use the most, we should concentrate on > it first and then try to find out other potential improvements in > other tools. > > I think we should invest some time into this. > > Cheers, > > Jorge > > On Fri, Jun 4, 2010 at 7:36 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: >> OBSUnitIntegration is already providing some of those: >> >>> 1) When you are in the browser writing a test method, you can >>> press ctrl + t >>> to save the method and run the test. If the test runs, it will >>> show the >>> green dot in the browser, if it does not, it popups the debugger >>> directly on >>> the error. So, this is a way to avoid pressing ctrl + s (save) >>> then going to >>> the method list, rigth click an select run test and if it fails >>> select that >>> you want to debug it. >> >> Ctrl+T does not save, but it runs the tests and shows the debugger. I >> don't think that I like the two things to be combined :-) >> >>> 2) Same as ctrl + t but ctrl + r to directly debug the test. It >>> saves the >>> method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo >>> breakpoints dont show very well in the debuger (it highlights >>> incorrect >>> collaborations) >> >> Ctrl+D opens a full debugger on the first line of the selected test, >> no matter if the test fails or not. It doesn't use breakpoints. And I >> use it all the time :-) >> >> So maybe we could combine some of that code? >> >> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Mariano Martinez Peck

On Fri, Jun 4, 2010 at 7:36 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > OBSUnitIntegration is already providing some of those: > > > 1) When you are in the browser writing a test method, you can press ctrl > + t > > to save the method and run the test. If the test runs, it will show the > > green dot in the browser, if it does not, it popups the debugger directly > on > > the error. So, this is a way to avoid pressing ctrl + s (save) then going > to > > the method list, rigth click an select run test and if it fails select > that > > you want to debug it. > > Ctrl+T does not save, but it runs the tests and shows the debugger. I > don't think that I like the two things to be combined :-) > > That's what I don't like, ctrl + t runs all the tests of the class, not only the method were you are. I would love ctrl + t to run only the test where I am and if I want to run all the test of the class, then I select the class and then ctrl + t. This was discussed with Adrian Kuhn and he integrated this change in his package. I don't know where is it neither if it was integrated or not. Cheers Mariano > > 2) Same as ctrl + t but ctrl + r to directly debug the test. It saves the > > method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo > > breakpoints dont show very well in the debuger (it highlights incorrect > > collaborations) > > Ctrl+D opens a full debugger on the first line of the selected test, > no matter if the test fails or not. It doesn't use breakpoints. And I > use it all the time :-) > > So maybe we could combine some of that code? > > 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 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Jorge Ressia

I've been using TDDFacilities in Pharo since it was first released. It is precisely what I needed to achieve real TDD while developing my tools. New features in the New Compiler and TextLint (from scratch) were developed using this tool. Doru, if you want I can give you a short demo of it. I think that what Hernan is proposing is very important. The debugger is the tool that TDD developers use the most, we should concentrate on it first and then try to find out other potential improvements in other tools. I think we should invest some time into this. Cheers, Jorge On Fri, Jun 4, 2010 at 7:36 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > OBSUnitIntegration is already providing some of those: > >> 1) When you are in the browser writing a test method, you can press ctrl + t >> to save the method and run the test. If the test runs, it will show the >> green dot in the browser, if it does not, it popups the debugger directly on >> the error. So, this is a way to avoid pressing ctrl + s (save) then going to >> the method list, rigth click an select run test and if it fails select that >> you want to debug it. > > Ctrl+T does not save, but it runs the tests and shows the debugger. I > don't think that I like the two things to be combined :-) > >> 2) Same as ctrl + t but ctrl + r to directly debug the test. It saves the >> method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo >> breakpoints dont show very well in the debuger (it highlights incorrect >> collaborations) > > Ctrl+D opens a full debugger on the first line of the selected test, > no matter if the test fails or not. It doesn't use breakpoints. And I > use it all the time :-) > > So maybe we could combine some of that code? > > 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 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Lukas Renggli

OBSUnitIntegration is already providing some of those: > 1) When you are in the browser writing a test method, you can press ctrl + t > to save the method and run the test. If the test runs, it will show the > green dot in the browser, if it does not, it popups the debugger directly on > the error. So, this is a way to avoid pressing ctrl + s (save) then going to > the method list, rigth click an select run test and if it fails select that > you want to debug it. Ctrl+T does not save, but it runs the tests and shows the debugger. I don't think that I like the two things to be combined :-) > 2) Same as ctrl + t but ctrl + r to directly debug the test. It saves the > method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo > breakpoints dont show very well in the debuger (it highlights incorrect > collaborations) Ctrl+D opens a full debugger on the first line of the selected test, no matter if the test fails or not. It doesn't use breakpoints. And I use it all the time :-) So maybe we could combine some of that code? Lukas -- Lukas Renggli www.lukas-renggli.ch

June 4, 2010