Hello Lazarus-List,

I'm trying to improve some debug parts up to where my skills let me and I had found some things that I was unable to understand:

1) I was unable to find how TIDEWatch is connected with GDBMIDebugger, in special the "GetValue" property getter. As I understand GetValue will return the "default value representation" so to add override representation, in example "memory dump", a new function should be added like "GetValue(FormatSet)".

2) The IDE hints are always draw using DT_CENTER which ruins any multiline representation. Is possible to remove this DT_CENTER from "procedure THintWindow.Paint" ?

3) In the case of class debug I had added to the result the data returned from evaluating de dereference, something like inspecting "Class" and "Class^" which offers more information. Are this kind of improvements of some interest ?

4) gdb class information looks very strange to me, in example a TMemoryStream dumps:

~"type = TMEMORYSTREAM = class : public TCUSTOMMEMORYSTREAM \n" ~" private\n"
~" FCAPACITY : LONGINT;\n"
~"\n"
~" public\n"
~" procedure SETCAPACITY (TMEMORYSTREAM, ONGINT, );\n" ~" function REALLOC (TMEMORYSTREAM, ONGINT, ) : POINTER; virtual;\n" ~" destructor ~DESTROY (TMEMORYSTREAM, OINTER); virtual;\n" ~" procedure CLEAR (TMEMORYSTREAM);\n"
~" procedure LOADFROMSTREAM (TMEMORYSTREAM, STREAM, );\n" ~" procedure LOADFROMFILE (TMEMORYSTREAM, ANSISTRING);\n" ~" procedure SETSIZE (TMEMORYSTREAM, ONGINT, ); virtual;\n" ~" function WRITE (TMEMORYSTREAM, onst7, ) : LONGINT; virtual;\n" ~"end\n"

Note the missing "L" in second parameter when LONGINT was expected, or missing "T" in LOADFROMSTREAM, but the most strange to me is the "onst7". What's "const7" ? Does anybody know why those letters are missing ?

5) When an exception is raised and "stop" button is pressed usually the assembler window pops up instead the line where the exception happends, or the nearest line with debug information. I had changed my code to show the assembler window only if no line with debug information is found in the backtrace. But I do not exactly know how that procedure works and maybe I missed something important, or maybe that's the expected behavior :-?

[...] 2) The IDE hints are always draw using DT_CENTER which ruins any multiline representation. Is possible to remove this DT_CENTER from "procedure THintWindow.Paint" ?

Multilines works with #13 chars.

If you want highlighting, left/right alignment or other fancy stuff, you can pass html. If you install the tp ipro package the hint is replaced by the htmlpanel.

[...]

I leave the rest to the debugger devels. Marc?

Mattias

Hello Lazarus-List,

Friday, October 2, 2009, 9:19:27 PM, you wrote:

MG> On Fri, 2 Oct 2009 20:57:21 +0200

MG> JoshyFun wrote

>[...] > 2) The IDE hints are always draw using DT_CENTER which ruins any > multiline representation. Is possible to remove this DT_CENTER from > "procedure THintWindow.Paint" ?

MG> Multilines works with #13 chars.

I know but the "problem" is that it looks like:

S: TSMemoryStream
Another text in the second line
This is Third
And Four

Debugger has one set of classes for IDE and another set of classes for the debugging itself.
Classes which has IDE in name are used by IDE to save/load their values to/from streams, etc.
TDBGWatch is used as a base class for the debugger - it has TIDEWatch as slave. TGDBMIWatch is a paticular implementation for TDBGWatch which works with gdb debugger.

2) The IDE hints are always draw using DT_CENTER which ruins any multiline representation. Is possible to remove this DT_CENTER from "procedure THintWindow.Paint" ?

Yes, as I remember I did so but don't remember the reason. Many times after I though to remove DT_CENTER too. When I have time to work I will look for reasons and remove it.

Yes, just tried and it is indeed so. Probably some bug of FPC or GDB or both. Can you report this to the fpc bug tracker?

Can't help with other items.

Best regards,
Paul Ishenin.

Heh, some time ago I wanted to remove it too, but decided there was some reason to add it, and hestitated ;-)

Hello Lazarus-List,

Saturday, October 3, 2009, 3:36:46 AM, you wrote:

PI> Debugger has one set of classes for IDE and another set of classes for PI> the debugging itself.
PI> Classes which has IDE in name are used by IDE to save/load their values PI> to/from streams, etc.
PI> TDBGWatch is used as a base class for the debugger - it has TIDEWatch as PI> slave. TGDBMIWatch is a paticular implementation for TDBGWatch which PI> works with gdb debugger.

Ok, I see that part of the path, but there is still a missing point from my side. In one Watch window procedure the code looks like (not exactly):

procedure Update(Watch: TIDEWatch);
begin
  Value:=Watch.Value;
end;

but manually following the execution flow, Watch.Value gets me to TIDEWatch.GetValue which looks like a default stub. So maybe the parameter should be different, maybe a TBaseWatch ?

I was unable to find how to debug the debugger, but that's not a problem by now.

> "procedure THintWindow.Paint" ?

PI> Yes, as I remember I did so but don't remember the reason. Many times PI> after I though to remove DT_CENTER too. When I have time to work I will PI> look for reasons and remove it.

I had removed it to test and no side effect apparently except that there are 2 kinds of tooltips which look similar, the codetools hints and the debugger hints :-? Once removed the DT_CENTER in "procedure THintWindow.Paint" the codetools hints are still centered :-?

PI> Yes, just tried and it is indeed so. Probably some bug of FPC or GDB or PI> both. Can you report this to the fpc bug tracker?

I'll investigate a bit before.

PI> Can't help with other items.

Thank you as usual :)

Paul Ishenin wrote

Yes, as I remember I did so but don't remember the reason. Many times after I though to remove DT_CENTER too. When I have time to work I will look for reasons and remove it.

I can confirm that the Delphi behavior is different from Lazarus: it does not center text in Hint windows.

Removing DT_CENTER in THintWindow.Paint makes Delphi compatible.

BTW: Just yesterday i think of reporting this bug.

Luiz

TIDEWatch is just a baseclass

On the IDE side you realy deal with a TManagedWatch defined in C:\lazarus_latest\ide\debugmanager.pas

Martin

I am not sure, if formatting should happen in the debugger.

IMHO it would be better to have a "GetValueStructure" or "GetValueEx" or similat.

return a class/structure, that can be formatted by the IDE.

My 2 cents / Best Regards
Martin

Did you rebuild IDE + LCL ?

Here, in a simple test the hint was not centered

Luiz

Hi JoshyFun,

in this context, maybe have a look at:
http://bugs.freepascal.org/view.php?id=10665

I don't know if it overlaps with your plans, or is unrelated...

Best Regards
Martin

Hello Lazarus-List,

Saturday, October 3, 2009, 2:40:18 PM, you wrote:

M> in this context, maybe have a look at:
M> http://bugs.freepascal.org/view.php?id=10665

M> I don't know if it overlaps with your plans, or is unrelated...

That's exactly one of the things that I'll try to implement, and the reason that a centered tooltip does not help ;) I wish to indent some information in different lines, but with all information centered the result is more confusing than previously one line information.

Paul Ishenin wrote

Yes, as I remember I did so but don't remember the reason. Many times after I though to remove DT_CENTER too. When I have time to work I will look for reasons and remove it.

I am wrong. That was Mattias who made text centering for the THintWindow.

Best regards,
Paul Ishenin.

If I did that, then I thought it was Delphi compatible. If it is not, then it should be changed.
Can someone test under Delphi?

Mattias

I already tested. It's not centered. See previous mail

Luiz

Thanks for testing. Fixed.

Mattias

Hello Lazarus-List,

Saturday, October 3, 2009, 5:47:53 PM, you wrote:

MG> Thanks for testing. Fixed.

Can anybody apply this patch locally and tell me if this kind of debug changes are of interest ?

Main changes:

1) Once stop on exception the assembler window will only appear if no backtrace information is available. It will show the clser offended line with debug information.

2) Clases on hint, evaluate or watch are multiline displayed with indentation. In watches this will be a small problem, but most important information is kept in the very first line. Clases are evaluated 2 times, one as the class and one as the derefenced to get the class variables/status information.

3) Records are now displayed in multiline also and the record type name is displayed in the first line.

No interface with debugger has been changed, only the way the default value is returned. Partial code adapted from Benito van der Zander in http://bugs.freepascal.org/view.php?id=10665

Sounds useful to me.
The debugger is Marc's work. But Marc is busy the next days, so don't expect anything soon.

Mattias

Hello Lazarus-List,

you wrote

> Can anybody apply this patch locally and tell me if this kind of debug > changes are of interest ?

[...]
MG> Sounds useful to me.
MG> The debugger is Marc's work. But Marc is busy the next days, so MG> don't expect anything soon.

I mostly want to know if this are of interest. If no interest I'll only add the things that need to me (mostly the already added), but if people feels this useful I'll extend the changes and add some more detailed output.

I'll also try to make the inpector work.

I thought it was already the case :)

Formatting of output shouldn't be done in the debugger classes. The idea is/was always to be able to hook in different debuggers. So a class should be reported in some kind of class like TGDBType (but then generalized as TDBGType), where the IDE can format the output as it wants depending on the location something is shown. In a hint you want lines, in a watches view you may want some collapsable tree.

No interface with debugger has been changed, only the way the default value is returned. Partial code adapted from Benito van der Zander in http://bugs.freepascal.org/view.php?id=10665

Marc

Hello Lazarus-List,

you wrote

> 1) Once stop on exception the assembler window will only appear if no > backtrace information is available. It will show the clser offended > line with debug information.

MW> I thought it was already the case :)

No it was not always the case, I do not know exactly the reason, but without the changes in most cases the line is never displayed and even the callstack changes :-? Looks like something in the assembler window changes the stack in someway and the offended line is no more at which it is expected. I'll recheck my changes in order to match the real difference once I'm getting into the debugger inners.

> 3) Records are now displayed in multiline also and the record type > name is displayed in the first line.

MW> Formatting of output shouldn't be done in the debugger classes. The idea MW> is/was always to be able to hook in different debuggers. So a class MW> should be reported in some kind of class like TGDBType (but then MW> generalized as TDBGType), where the IDE can format the output as it MW> wants depending on the location something is shown. MW> In a hint you want lines, in a watches view you may want some MW> collapsable tree.

I know, and that's my next step if there is interest. But by now and in order to help me in my other projects I'm using the "default" returned format, mostly to try to understand the code and at the same time get something usable as fast as possible.

If you have changes in your local codebase will be great to send them to me in a diff to not overlap any work. If you are planning to improve debugger asap I'll stop my changes and wait, as your skills with the debugger is around 1000 times mine :)

2009/10/4 JoshyFun :

I know, and that's my next step if there is interest. But by now and in order to help me in my other projects I'm using the "default"

Another "nice to have" debugging window would be to select a class or record structure you want to debug. It then shows at runtime a "object inspector" window which contains the values of that class and all it's properties or a record with all its field values.

Thats on my todo list for years :)

Marc

OK. When you have a patch, have it separate form other changes.

The latter often wont help. Then all dirty fast solutions will be added to lazarus, which will lead to troubles when you want to do it the better way. So you'll end up with the dirty solution.

If you have changes in your local codebase will be great to send them to me in a diff to not overlap any work. If you are planning to improve debugger asap I'll stop my changes and wait, as your skills with the debugger is around 1000 times mine :)

I should have done somme changes, but not yet. I'll see if I cas move TDBGType soon.

Marc

Hello Lazarus-List,

you wrote

>>> 1) Once stop on exception the assembler window will only appear if no

[...]

> MW> I thought it was already the case :)

[...]

> No it was not always the case, I do not know exactly the reason, but

MW> OK. When you have a patch, have it separate form other changes.

Ok, I'll investigate it...

MW> The latter often wont help. Then all dirty fast solutions will be added MW> to lazarus, which will lead to troubles when you want to do it the MW> better way. So you'll end up with the dirty solution.

Yes I know, so I had not submitted the patch to the bug tracker and post in the mailing list to get some feedback only. This changes should be reverted in my local codebase (or maybe not, but for sure it is not the right way to do the job).

MW> I should have done somme changes, but not yet. I'll see if I cas move MW> TDBGType soon.

I'll try play with it. Now I have 3-4 days with more spare time than usual :)

Hello Lazarus-List,

[...]

> difference once I'm getting into the debugger inners.

MW> OK. When you have a patch, have it separate form other changes.

In original code ViewDebugDialog(ddtAssembler) is almost always called before getting the offended line and as it is shown the next condition is false and the line is not searched.

Maybe the attached solution is not the best, but at least it works :) It basically moves the assembler window show to after the offended line has been found, and only displayed if no line has been found.

JoshyFun wrote

Maybe the attached solution is not the best, but at least it works :) It basically moves the assembler window show to after the offended line has been found, and only displayed if no line has been found.

Please don't comment a code you want to remove - simple remove it. Svn contains all the history and we will restore the old code if needed.

Best regards,
Paul Ishenin.

Hello Lazarus-List,

Monday, October 5, 2009, 4:25:56 PM, you wrote:

PI> JoshyFun wrote

> Maybe the attached solution is not the best, but at least it works :) > It basically moves the assembler window show to after the offended > line has been found, and only displayed if no line has been found. >

PI> Please don't comment a code you want to remove - simple remove it. Svn PI> contains all the history and we will restore the old code if needed.

Marc ask me (or at least I understand him in that way) to send him the modification in order to catch the reason why it does not work previously (for him it seems to work).

Anyway I'll continue in private mail instead adding noise to the list. My apologizes.

Hello Lazarus-List,

you wrote

> Anyway I'll continue in private mail instead adding noise to the list. > My apologizes.

PI> Yes, and you commented the old code using (**) or another comments. PI> That's why I ask you to just remove that old code. Edits are better PI> visible in diff than commenting and there is no need for commenting it PI> at all.

Oooops... you are right, that was completly unintentional :( That commented lines also confused me, I saw them just after your comment :( Sorry again.