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 <[email protected]> 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 <[email protected]>
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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
