CodeGuide 7.0 - featuring unique back-in-time debugger

Look at http://www.omnicore.com/debugger.htm

1. Topnotch IDE for Java and JSP – we can argue about it
2. Unique back-in-time debugger – it shouldn’t be unique
3. Unique on-the-fly compiler – we can argue about it
4. Refactorings, inspections, smart tools – everybody has it
5. Full support for Java 1.5 – !!!

33 comments

1. Topnotch IDE for Java and JSP – we can argue about
it


Not really. For plain (non-J2EE) Java and JSP projects CodeGuide sure is a very nice, slick IDE -- it reminds me of IDEA's early days. However, it is still far from a full-featured, enterprise-ready environment like IDEA. CodeGuide also lacks an extension mechanism, so there's no third-party add-ins to it's limited functionality (by the way, IDEA's OpenAPI still has a long way to go).

2. Unique back-in-time debugger – it shouldn’t be
unique


But unfortunately, it is unique. There's no other mainstream IDE out there with similar feature. There are, however some more obscure (and opensource) projects in this area, like BDBJ[/url] and LambdaCS[/url]

3. Unique on-the-fly compiler – we can argue about
it


At least eclipse has something like this. IDEA's approach is different -- it doesn't rely on compilation to do code analysis.

4. Refactorings, inspections, smart tools – everybody
has it


IDEA has always been, at still is #1 on that. But other products are catching up fast, and CodeGuide surely fills the basic refactoring needs.

5. Full support for Java 1.5 – !!!


Again, CodeGuide is the only mainstream IDE with this feature. I hope IDEA changes that soon :)

0

On Thu, 18 Mar 2004 16:04:41 +0000, Vladimir Goncharov wrote:

2. Unique back-in-time debugger ? it shouldn?t be unique


AFAIK they have there own compiler which adds a heap of meta to your
classses to support this...

0

Obviously, it is easy to say then implement, but as I can see it shouldn’t be that complicated. The IDE just logs all the debugging data to some file as a state of every debug step and then it is possible to go backwards. Of course it is going to be a little bit slow since the IDE should always perform step-in to have the state info, but it doesn’t look that the separate compiler is needed for this. Thigh, I’m still not sure that this feature is absolutely needed.

0

I don't think it's needed either, I don't use the debugger much (System.out.println is usually good enough) and when I do, I don't ever wish I could go back in time. But maybe it's one of those things that you don't realize you need until you use it.

0

Have you tryed their back-in-time debugger on any significant project? How useful is it?

0

CodeGuide actualy got two nice features in their debugging: the first one is back in time debugging, the second is statement-level stepping (as opposed to line stepping).

Back in time debugging is useful. Maybe not the greatest thing in the world, but quite useful. Imagine you're stepping in the code and then BANG, an exception ocurred. Now you just wonder how was the state of the system a few statements before the exception ocurred. Without the back-in-time debugging you'll need to set a breakpoint somewhere before the exception and run the app again. With the back-in-time debugger you just step back a few statements and examine you data to find what caused the unexpected bug. So put in a few words, back-in-time debugging simplify breakpoint setting. You can just set a breakpoint where the exception (or other kind of bug) occurs, and then get back to see how was the system before that happened.

Now, statement stepping is VERY VERY useful. When you have multiple statements in the same line (and depending on your code style, this happens a lot), it's very convenient to step only into the statement you want, and step over the other ones. Something like this:

System.out.println(someObject.doSomething(otherObject.getSomething()));

Now suppose you want to get into the "doSomething" method. Without statement stepping you'll have to press F7 (step into) when the debugger hits this line, but you'll then step into the "getSomething" method. Now you need to step out of this method and then step into the next. CodeGuide underlines the next statement to be executed. So you can just step over the getSomething method and then step into the doSomething, which is the method you really want to step into. The above example is quite simple -- more complex app's will have lines which are quite trickier for you to step into the right method.

There are SCR's submitted for both features. See:

#22227[/url], #30349[/url] and #30848[/url]

0

Back in time debugging is useful. Maybe not the greatest thing in the world, but quite useful. Imagine you're stepping in the code and then BANG, an exception ocurred. Now you just wonder how was the state of the system a few statements before the exception ocurred. Without the back-in-time debugging you'll need to set a breakpoint somewhere before the exception and run the app again. With the back-in-time debugger you just step back a few statements and examine you data to find what caused the unexpected bug. So put in a few words, back-in-time debugging simplify breakpoint setting. You can just set a breakpoint where the exception (or other kind of bug) occurs, and then get back to see how was the system before that happened.


+0.1 for BID (very good explanation)

Now, statement stepping is VERY VERY useful. When you have multiple statements in the same line (and depending on your code style, this happens a lot), it's very convenient to step only into the statement you want, and step over the other ones. Something like this:


+1

See also http://www.intellij.net/tracker/idea/viewSCR?publicId=12126 and
http://www.intellij.net/tracker/idea/viewSCR?publicId=23622 .

Tom

0

Yes! But along with
http://www.intellij.net/tracker/idea/viewSCR?publicId=22227 don't forget:
http://www.intellij.net/tracker/idea/viewSCR?publicId=12126,
http://www.intellij.net/tracker/idea/viewSCR?publicId=23622,
http://www.intellij.net/tracker/idea/viewSCR?publicId=24454

but check the bug number on the true original :)
http://www.intellij.net/tracker/idea/viewSCR?publicId=235

I think someone at JetBrains needs to do some duplicate marking :)

N.


Marcus Brito wrote:

CodeGuide actualy got two nice features in their debugging: the first one is back in time debugging, the second is statement-level stepping (as opposed to line stepping).

Back in time debugging is useful. Maybe not the greatest thing in the world, but quite useful. Imagine you're stepping in the code and then BANG, an exception ocurred. Now you just wonder how was the state of the system a few statements before the exception ocurred. Without the back-in-time debugging you'll need to set a breakpoint somewhere before the exception and run the app again. With the back-in-time debugger you just step back a few statements and examine you data to find what caused the unexpected bug. So put in a few words, back-in-time debugging simplify breakpoint setting. You can just set a breakpoint where the exception (or other kind of bug) occurs, and then get back to see how was the system before that happened.

Now, statement stepping is VERY VERY useful. When you have multiple statements in the same line (and depending on your code style, this happens a lot), it's very convenient to step only into the statement you want, and step over the other ones. Something like this:

System.out.println(someObject.doSomething(otherObject.getSomething()));

Now suppose you want to get into the "doSomething" method. Without statement stepping you'll have to press F7 (step into) when the debugger hits this line, but you'll then step into the "getSomething" method. Now you need to step out of this method and then step into the next. CodeGuide underlines the next statement to be executed. So you can just step over the getSomething method and then step into the doSomething, which is the method you really want to step into. The above example is quite simple -- more complex app's will have lines which are quite trickier for you to step into the right method.

There are SCR's submitted for both features. See:

#22227[/url], #30349[/url] and #30848[/url]

0

Well, all these issues just show how much wanted these features are :)

0

Nathan Brown wrote:

but check the bug number on the true original :)
http://www.intellij.net/tracker/idea/viewSCR?publicId=235


And there's also the related bug #136, dating back to February 2001:
http://www.intellij.net/tracker/idea/viewSCR?publicId=136

Vil.
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0

Guys,
nobody has still answered the question asked:)
This feature sounds really great, but did you try their implementation with
your projects? Personally I doubt that backstepping will ease the task of
debugging in case of some production code full of UI, I/O and
multithreading, while it is really going to slow the program down.

Eugene.

"Alexei Nikitin" <lex@intellij.com> wrote in message
news:5950432.1079680329290.JavaMail.itn@is.intellij.net...

Have you tryed their back-in-time debugger on any significant project? How

useful is it?


0

This feature sounds really great, but did you try their implementation with
your projects? Personally I doubt that backstepping will ease the task of
debugging in case of some production code full of UI, I/O and
multithreading, while it is really going to slow the program down.


I did not tried it and as already said, back-in-time debugging is (for
me) by far not that important than the other debug-rfe's I reported. I
also share your doubts about UI, I/O and multithreading.

But what about Jetbrains-typical new ideas? Ideas to not just a small
step forward, but a large jump ahead? Something like detecting
dead-locks before they occur for instance...

Tom

0

I gave it a go after seeing this thread. CodeGuide is, overall, nowhere near
as slick as IDEA (I can't believe anyone would pay $300 for it given IDEA is
$500 and is much nicer) but...

Back in time debugger is pretty nice. You can step forwards/backwards in
time to work out exactly what went on. All seems pretty slick (and it might
just be my imagination but quicker than IDEA - maybe because of all the
extra information it adds to the class files?). Interestingly the first time
I ran it I couldn't step back because it was running on classes compiled by
IDEA!

IDEA could do a lot worse than to mimic this functionality - I'll miss it in
IDEA now that I have tried it in CodeGuide :(

Cheers,

TicH


0

I gave it a go after seeing this thread. CodeGuide is, overall, nowhere near
as slick as IDEA (I can't believe anyone would pay $300 for it given IDEA is
$500 and is much nicer) but...


I can't understand people wasting money for JBuilder... ;)

Tom

0

But what about Jetbrains-typical new ideas? Ideas to not just a small
step forward, but a large jump ahead? Something like detecting
dead-locks before they occur for instance...


Well, I guess we prefer static analysis over dynamic interaction with the
program, hence the inspections.
As for analysing concurrent programs, this is indeed interesting though is
likely to require vast resources. But I'm in no way an expert in such kind
of analyses, so if you know any succesful implementations, please share your
knowledge with us=)


0

I heard that Bill Pugh, author of the new memory model implemented in Java 1.5, spent years trying to make a deadlock tool, and finally gave up because it's so hard or impossible to catch a lot of deadlock cases. He then wrote FindBugs.

0

It would be good enough to provide the simple post-mortum deadlock detection that Eclipse does. A decent monitor browser, along with with detection of obvious deadlocks after they've happened. I've always missed this in IDEA, as even the much-maligned JBuilder has had a pretty good monitor browser for years. And yes, theirs already a tracker for it, and yes, it already has some of my votes :).

0

When I described the features above I was describing my personal experience with them and how I felt their usefulness.

0

The JVM itself will tell you about deadlocks when you click on the Thread Dump button in IDEA's Run window, or press Ctrl+Break at a console running your program.

0

have tried this now on my (medium-size) project (35k lines).
it's great, at least for my case. For the first time in 1.5 years I feel
there is something amiss in Idea.
+1 for the BiTD.

"Alexei Nikitin" <lex@intellij.com> wrote in message
news:5950432.1079680329290.JavaMail.itn@is.intellij.net...

Have you tryed their back-in-time debugger on any significant project? How

useful is it?


0

Hmm. Cant't find the corresponding request in tracker. Do you mean http://www.intellij.net/tracker/idea/viewSCR?publicId=292 ?

0

In article <5950432.1079680329290.JavaMail.itn@is.intellij.net>,
lex@intellij.com says...

Have you tryed their back-in-time debugger on any significant project? How useful is it?

I used it with VC+6 back in my C+ days. I think it is very useful.
YMMV
--
-


David H. McCoy


-


0

VC++6 had a back in time debugger? I thought CodeGuide was the first IDE with this feature.

0

Keith Lea wrote:

VC++6 had a back in time debugger? I thought CodeGuide was the first IDE with this feature.


I suspect he's confusing it with the "Edit and Continue" feature which was
introduced in VC++ 6.0 (IIRC). That's HotSwap to you and me.

Vil.
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0

i've seen it working on some version of vc++ (5.0 i think), but as far as i
remember often it would refuse to step back for unknown to me reasons... i
guess they were cleaning all history as soon as they hit something that
qualifies for irreversible side effect.

...or is it possible that i've been dreaming ?!?



"Vilya Harvey" <vilya.harvey@digitalsteps.com> wrote in message
news:c3sfo0$k6v$1@is.intellij.net...

Keith Lea wrote:

VC++6 had a back in time debugger? I thought CodeGuide was the first IDE

with this feature.
>

I suspect he's confusing it with the "Edit and Continue" feature which was
introduced in VC++ 6.0 (IIRC). That's HotSwap to you and me.

>

Vil.
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/




0

SoftICE has had a Trace function that does something similar
to back-in-time debugging. That could be what you're
dreaming of.

/Mikael

0

In article <c3sfo0$k6v$1@is.intellij.net>, vilya.harvey@digitalsteps.com
says...

Keith Lea wrote:

VC++6 had a back in time debugger? I thought CodeGuide was the first IDE with this feature.


I suspect he's confusing it with the "Edit and Continue" feature which was
introduced in VC++ 6.0 (IIRC). That's HotSwap to you and me.

Vil.

Let's say you were on line 50(breakpoint) and you say the problem on
line 45, int x = 5 should be int x = 10, VC++ would let you make the
change, put the debug pointer on line 45, and move back to that point
without hitting line 51.

Isn't that back in time?
--
-


David H. McCoy


-


0

No, CodeGuide's debugger records the state of your program after each instruction, and lets you view the value that any field or variable has ever had, at any point during the program's execution.

0

Please sign in to leave a comment.