On 13/09/2011 13:07, Graeme Geldenhuys wrote:
On 13/09/2011 00:12, Martin wrote:
I do not recall having ever had an issue with globals, nor local vars.
Nope, the problem is still there... just as when I tested it back in
2008-2009.
http://opensoft.homeip.net:8080/~graemeg/gdb_issues_with_fpc.png
ShortDateFormat is declared in the RTL
So you need an rtl with debug info.
On my system, I can inspect it (including hint). But my rtl has debug info.
I understand this is annoying. And I understand from a users point of
view, it makes no difference.
But, if we wish to look at solving it (or determining if/how it can be
solved), then we need to differ between failurses by the debugger, and
things the compiler does not make available.
So as far as the recent "naitve debugger" discussion goes => a native
debugger will not fix this, IF it is indeed caused by the complete
absence of debug info for the symbol.
Maybe FPC can include info of certain symbols (if they are used) from
other units, even if those units are without debug info...
I believe that happens for class structures in a partial way.
This exact same code works perfectly in Delphi 7 and Kylix 3. Above is
an old screenshot, but I just tested with latest Lazarus Trunk and GDB
7.3 - nothing has changed.
And yes, I know in FPC it is an absolute variable, but it is a global
variable to the developer none the less.
See note about debug info
I agree with Dodi, 95% of the things I try and debug I simply get 'No
symble in current context". Thus making GDB rather useless for my code.
Well maybe if you debug alot of RTL symbols, and have an debug info free
rtl => then this is true.
But then the "what debugger to use" discussion will not help.
Oh, and ALL my code is done via OOP, so inspecting properties of a class
is vital.
So is much of the code I use. If properties do not modify the state of
that app, or objects (and that is kind of vital to allow running getter
functions) then all relevant info can be gotten by expecting fields.
I assume debugging ones one classes, one would be familiar where a
property gets a value from?
I do not argue that there is a serious impact on COMFORT. there is an
impact. no doubt.
But yes, I take your word for it, that for you, your classes are
designed in a way, that there is absolutely no way around inspecting the
property instead of a field.
Given that there seems no alternative to gdb yet, and given that your
code can under no circumstances be debugged using gdb => I must say, I
have a huge amount of respect for your archivment of implementing fpgui
without using any debugging at all. WOW. (scnr :) )
And yes the "inspecting properties could change data" is a moot point.
Delphi allows it, and NOBODY complains about the possible data change
issue. The pros far outweigh the cons. We are programmers, we should
know what is "dangerous" or not - but it should be our choice to use
such "dangerous" features.
I am not avoiding the feature because of it;'s potential dangers.
If the feature was do-able => fine.
I just say from my personal experience, I can live without it, but that
may just be me.
And I am saying, if properties are the only problem => then the
situation certainly is not as bad as some people say.
But I begin to see, that on some installations further problems exist,
that add to it. Those problems should not exist => as they are working
already on other systems (like mine)
I also agree, that being able to read the field variable value via the
property name would already be a huge improvement. NOTE: I mentioned
here "via property name", not field name, because often I don't know
what the field name is, especially if you have a large hierarchy of objects.
Well again => that works perfectly fine on my installation
maybe again that you have units without debug info (or you mix dwarf and
stabs)?
Martin
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
