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@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@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@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