AFAICT Delphi allows one to 'Evaluate' _all_ properties, but only
allow 'Watch' properties with read functions if 'Allow side effects in
new watches' is enabled.
That does not seem like a very good paradigm :(
FP/gdb/DWARF should be able to do better using a pure pattern. :)
-Michael
And in fact, the same can be done to generate for properties that
directly map to variables/fields. Just one question: what should the
debug information point the debugger to in case of
a) a property without a read specifier, but with a write specifier
going directly to a field? Nothing, or
Michael Schnell wrote on di, 17 mrt 2009:
I still did not yet get any discussion rolling on the issue of pure
read functions (that have no side-effect).
I did discuss it in my first mail to this thread. It first requires
the following two problems to be solved, and none is particularly
b) a property with a read specifier that is a function call, but with a
write specifier directly going to a field? Nothing,
Nothing for now imo.
That is what pure functions in C are defined for.
-Michael
___
fpc-devel maillist -
I still did not yet get any discussion rolling on the issue of pure read
functions (that have no side-effect). The debugger might use a pure read
function to show the property value, but it can't if the read function is
not pure. gcc does know about pure functions, thus I suppose DWARF also
On Sat, Mar 14, 2009 at 12:52 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
But maybe it's easier to ask the usual question: wddd? (what does Delphi do)
The watches window shows 'Cannot read a write-only property'.
Which seems quite logical to me as well. After all, it is a write-only
Paul Ishenin wrote:
Jonas Maebe wrote:
Maybe smart linking is enabled? I don't think it works yet with DWARF
(I'll change the compiler it also disables that when using DWARF debug
info).
No, it does not. I checked with fpc r12887 - still the same problem
under gdb.
Today I tested on my
Schatzl Thomas wrote:
I checked that lnfodwrf.pp at least compiles on win32.
Stabs does not support 64 bit, DWARF is default on all these platforms, that's
why it is used in win64 and not win32.
The lnfodwrf.pp should work fine on win32 though.
If so then please apply attached patch and
On 11 Mar 2009, at 15:12, Jonas Maebe wrote:
It may even be quite challenging to generate debug information for
something like that with Stabs. For DWARF, it seems there is some
code that generates debug information in some cases, but only for
var a: type absolute b;-style expressions
And in fact, the same can be done to generate for properties that directly
map to variables/fields. Just one question: what should the debug
information point the debugger to in case of
a) a property without a read specifier, but with a write specifier going
directly to a field? Nothing, or
On 14 Mar 2009, at 09:16, dmitry boyarintsev wrote:
And in fact, the same can be done to generate for properties that
directly
map to variables/fields. Just one question: what should the debug
information point the debugger to in case of
a) a property without a read specifier, but with a
On 14 Mar 2009, at 09:16, dmitry boyarintsev wrote:
writing a property directly in the field is a hack
No, it's guaranteeing future compatibility, because by using a
property you ensure that you can later on replace the setter with a
procedure if necessary, without breaking existing
No, it's guaranteeing future compatibility, because by using a property you
ensure that you can later on replace the setter with a procedure if
necessary, without breaking existing source code (at least in FPC 2.3.1; FPC
2.2.x misses several checks, allowing you to do all sorts of things with
On 14 Mar 2009, at 09:46, dmitry boyarintsev wrote:
No, it's guaranteeing future compatibility, because by using a
property you
ensure that you can later on replace the setter with a procedure if
necessary, without breaking existing source code (at least in FPC
2.3.1; FPC
2.2.x misses
Jonas Maebe schrieb:
On 11 Mar 2009, at 15:12, Jonas Maebe wrote:
It may even be quite challenging to generate debug information for
something like that with Stabs. For DWARF, it seems there is some code
that generates debug information in some cases, but only for var a:
type absolute
On 14 Mar 2009, at 10:42, Florian Klaempfl wrote:
Jonas Maebe schrieb:
It turned out that DWARF2 was enough, so the implementation should
already work with currently released GDB versions (see
http://bugs.freepascal.org/view.php?id=13313 for some caveats).
And in fact, the same can be done
El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl flor...@freepascal.org escribió:
a) a property without a read specifier, but with a write specifier
going directly to a field? Nothing, or that field?
Nothing. This property is not readable.
It's not readable by the users of the class,
On 14 Mar 2009, at 11:32, Luca Olivetti wrote:
El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl flor...@freepascal.org escribió:
a) a property without a read specifier, but with a write specifier
going directly to a field? Nothing, or that field?
Nothing. This property is not readable.
On Sat, 14 Mar 2009, Jonas Maebe wrote:
On 14 Mar 2009, at 11:32, Luca Olivetti wrote:
El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl flor...@freepascal.org escribió:
a) a property without a read specifier, but with a write specifier
going directly to a field? Nothing, or
On 14 Mar 2009, at 11:52, Michael Van Canneyt wrote:
The watches window shows 'Cannot read a write-only property'.
Ok, thanks. Support for DWARF2 debug info for properties with an
accessor that does not pass via a function is committed.
Jonas
Jonas Maebe wrote:
On 14 Mar 2009, at 11:52, Michael Van Canneyt wrote:
The watches window shows 'Cannot read a write-only property'.
Ok, thanks. Support for DWARF2 debug info for properties with an
accessor that does not pass via a function is committed.
I'm glad to check it but how
On 14 Mar 2009, at 15:00, Paul Ishenin wrote:
Jonas Maebe wrote:
Ok, thanks. Support for DWARF2 debug info for properties with an
accessor that does not pass via a function is committed.
I'm glad to check it but how (fpc r12883)?
c:\programming\fpc\bin\i386-win32\ppc386.exe -O1 -gl
Jonas Maebe wrote:
It's the DWARF version of the lineinfo unit. It's only required to get
line numbers in backtraces when a program crashes. Apparently, it
hasn't been ported to Win32 yet, but it's not required to debug. Just
leave out the -gl parameter.
Ok, I tried to fix it by changing
On 14 Mar 09, at 21:27, Paul Ishenin wrote:
Jonas Maebe wrote:
It's the DWARF version of the lineinfo unit. It's only required to get
line numbers in backtraces when a program crashes. Apparently, it
hasn't been ported to Win32 yet, but it's not required to debug. Just
leave out the
Tomas Hajny wrote:
Keeping -gl instead of -gw?
Sorry, leave out was not in my head dictionary :)
c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp
(gdb) break test.pp:8
invalid dwarf2 offset 4243567
No luck :(
Best regards,
Paul Ishenin.
On 14 Mar 2009, at 15:42, Paul Ishenin wrote:
Tomas Hajny wrote:
Keeping -gl instead of -gw?
Sorry, leave out was not in my head dictionary :)
c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp
(gdb) break test.pp:8
invalid dwarf2 offset 4243567
No luck :(
Strange, that error
Jonas Maebe wrote:
Strange, that error looks very much like the one that should have been
fixed by http://bugs.freepascal.org/view.php?id=12872
Yes.
I tried to compile so (gdb complained the same way):
c:\programming\fpc\bin\i386-win32\ppc386.exe -Aas -gw test.pp
and fpc wrote me this note:
On 14 Mar 2009, at 15:27, Paul Ishenin wrote:
Jonas Maebe wrote:
It's the DWARF version of the lineinfo unit. It's only required to
get line numbers in backtraces when a program crashes. Apparently,
it hasn't been ported to Win32 yet, but it's not required to debug.
Just leave out the
On 14 Mar 2009, at 15:59, Paul Ishenin wrote:
Jonas Maebe wrote:
Strange, that error looks very much like the one that should have
been fixed by http://bugs.freepascal.org/view.php?id=12872
Yes.
I tried to compile so (gdb complained the same way):
On 14 Mar 2009, at 15:59, Paul Ishenin wrote:
Jonas Maebe wrote:
Strange, that error looks very much like the one that should have
been fixed by http://bugs.freepascal.org/view.php?id=12872
Yes.
I tried to compile so (gdb complained the same way):
Hello,
Von: Paul Ishenin webpi...@mail.ru
Jonas Maebe wrote:
It's the DWARF version of the lineinfo unit. It's only required to get
line numbers in backtraces when a program crashes. Apparently, it
hasn't been ported to Win32 yet, but it's not required to debug. Just
leave out the
On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber fp...@bluewin.ch wrote:
Delphi/Kylix probably can't map a variable to the address of another variable,
because of that Delphi needs separate implementations of format functions
with and without FormatSettings parameter.
To be honest that is not
On Thu, Mar 12, 2009 at 10:22 AM, Vincent Snijders
vsnijd...@vodafonevast.nl wrote:
I guess the fpc developers traded debuggability for maintainability, so you
could have a better fpc (more features or less bugs). That is what it
concerns to you as developer. Maybe you disagree with that trade
Op Thu, 12 Mar 2009, schreef Vincent Snijders:
Graeme Geldenhuys schreef:
On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber fp...@bluewin.ch wrote:
Delphi/Kylix probably can't map a variable to the address of another
variable,
because of that Delphi needs separate implementations of format
Vincent Snijders wrote on do, 12 mrt 2009:
I guess the fpc developers traded debuggability for maintainability, so
you could have a better fpc (more features or less bugs). That is what
it concerns to you as developer. Maybe you disagree with that trade off.
No, it's simply an unimplemented
Jonas Maebe schreef:
Vincent Snijders wrote on do, 12 mrt 2009:
I guess the fpc developers traded debuggability for maintainability, so
you could have a better fpc (more features or less bugs). That is what
it concerns to you as developer. Maybe you disagree with that trade off.
No, it's
On Thu, 12 Mar 2009, Vincent Snijders wrote:
Jonas Maebe schreef:
Vincent Snijders wrote on do, 12 mrt 2009:
I guess the fpc developers traded debuggability for maintainability, so
you could have a better fpc (more features or less bugs). That is what
it concerns to you as
On Thu, Mar 12, 2009 at 10:53 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
I've also never seen a bug report about this fact. And although I realise
that it may not be obvious that some variable is not visible due to the fact
that it's an absolute variable, simply a bug report about
On Wed, Mar 11, 2009 at 10:24 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Anybody know what debug format does the Delphi compiler use? I would
guess they have there own format, for exactly the same reasons I
mention here.
I did a bit more research and it seems I was on the right
On Wed, Mar 11, 2009 at 10:24 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Simple things that worked in Delphi IDE and even Kylix IDE, but not in
FPC/Lazarus IDE:
* Breakpoints do not always break
* Tooltip evaluation of highlighted code gives no such symbol in
context errors
*
Graeme Geldenhuys wrote on wo, 11 mrt 2009:
Continuing with the debugging issues on how do I debug something as
simple as the global variable 'ShortDateFormat'? This just shows how
broken debugging is in FPC. With Kylix or Delphi this is a no-brainer!
See the URL below for a screenshot of the
On Wed, Mar 11, 2009 at 3:55 PM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
http://opensoft.homeip.net/~graemeg/gdb_issues_with_fpc.png
And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial things is a no-brainer. Debugging just works.
On Wed, Mar 11, 2009 at 4:12 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
With DWARF3, this should also be quite doable.
So is DWARF3 only supported in the newest (not really released yet)
GDB? Something like the one that apparently comes with Fedora 11?
I'm currently using GDB that came
Graeme Geldenhuys wrote:
And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial things is a no-brainer. Debugging just works.
http://opensoft.homeip.net/~graemeg/kylix_debuging.png
Delphi/Kylix also does not have 'absolute', so FPC requires even more
features in
Micha Nelissen wrote:
Graeme Geldenhuys wrote:
And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial things is a no-brainer. Debugging just works.
http://opensoft.homeip.net/~graemeg/kylix_debuging.png
Delphi/Kylix also does not have 'absolute', so FPC requires
Delphi/Kylix also does not have 'absolute', so FPC requires even more
features in debugging format also than even K/D.
Not true. (Turbo) Delphi does have absolute.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Graeme Geldenhuys wrote on wo, 11 mrt 2009:
On Wed, Mar 11, 2009 at 4:12 PM, Jonas Maebe
jonas.ma...@elis.ugent.be wrote:
With DWARF3, this should also be quite doable.
So is DWARF3 only supported in the newest (not really released yet)
GDB?
Yes.
Something like the one that apparently
To make FPC generate DWARF3 debug info, use the -gw3 command line
switch. Note that this is not yet very well tested, and may still
contain a lot of bugs (with things working with -g and/or -gw2 not
working with -gw3)
But it seems the way FP goes is already defined and seems like
Michael Schnell wrote on wo, 11 mrt 2009:
To make FPC generate DWARF3 debug info, use the -gw3 command line
switch. Note that this is not yet very well tested, and may still
contain a lot of bugs (with things working with -g and/or -gw2 not
working with -gw3)
But it seems the way FP
On Wednesday 11 March 2009 15:14:27 Graeme Geldenhuys wrote:
On Wed, Mar 11, 2009 at 3:55 PM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
http://opensoft.homeip.net/~graemeg/gdb_issues_with_fpc.png
And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial
50 matches
Mail list logo
