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
___
>
> 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 DWAR
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 eas
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 - fpc-de
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 th
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 re
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 ubunt
On Sat, Mar 14, 2009 at 12:52 PM, Michael Van Canneyt
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 property.
Rega
Hello,
> Von: Paul Ishenin
> 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 p
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.
Best regards,
Paul Ishenin.
___
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.
Btw, it is strange that in rtl\win64\m
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):
c:\programming\fpc\bin\i386-win32\ppc386.ex
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):
c:\programming\fpc\bin\i386-win32\ppc386.ex
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 -
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:
"No
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 lo
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 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
> > leav
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 make
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 -gw
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 (fpc
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
_
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 escribió:
> >
> > > >a) a property without a read specifier, but with a write specifier
> > > >going directly to a field? Nothing, or that fie
On 14 Mar 2009, at 11:32, Luca Olivetti wrote:
El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl 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
El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl 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, but it should be r
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 t
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 a
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 sever
> 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 wi
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 sourc
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 writ
> 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,
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 (a
On Thu, Mar 12, 2009 at 10:53 AM, Jonas Maebe 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 "variable x of
> unit y is not
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
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 simp
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 fe
Op Thu, 12 Mar 2009, schreef Vincent Snijders:
Graeme Geldenhuys schreef:
On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber 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 a
On Thu, Mar 12, 2009 at 10:22 AM, Vincent Snijders
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 off.
I did not mean
Graeme Geldenhuys schreef:
On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber 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
On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber 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 my concern...
On Wednesday 11 March 2009 15:14:27 Graeme Geldenhuys wrote:
> On Wed, Mar 11, 2009 at 3:55 PM, Graeme Geldenhuys
>
> 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-br
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 goe
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 appropriat
Graeme Geldenhuys wrote on wo, 11 mrt 2009:
On Wed, Mar 11, 2009 at 4:12 PM, Jonas Maebe
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 comes with Fedora 11?
T
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
http://lists.free
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
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
On Wed, Mar 11, 2009 at 4:12 PM, Jonas Maebe 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 with Ubuntu 7.10.
grae.
On Wed, Mar 11, 2009 at 3:55 PM, Graeme Geldenhuys
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.
http://opensoft.homeip.net/~graemeg/kylix
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 i
On Wed, Mar 11, 2009 at 10:24 AM, Graeme Geldenhuys
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
> * Properties on obj
On Wed, Mar 11, 2009 at 10:24 AM, Graeme Geldenhuys
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 track.
Delphi seems to u
53 matches
Mail list logo
