Unfortunately, once about 2 mails are exchanged on the subject of what I
actually tried to talk about, the whole discussion takes off and all
kind of debugger woes are included
So back again:
I am trying to find out, if the below could make a reasonable feature
request (and therefore have
On 13 September 2011 17:10, Juha Manninen wrote:
>
> Graeme, are you working on Duby or some new debugger?
I'm working on Duby, but all changes are local to my system. I don't
have commit rights to Duby on SourceForge - though I never asked.
I'm also not sure if the original author of duby would
On Tue, Sep 13, 2011 at 8:52 AM, Graeme Geldenhuys
wrote:
> [sorry to be harsh towards DaWorm, but that was a
> damn stupid example]
It was only an example intended to show that executing getters can
have unintended and sometimes disastrous and/or non reversible side
effects. By itself it might
- "Graeme Geldenhuys" schreef:
> the debugger to limit what I am allowed to do. eg: Delphi allows it
> without *anybody* complaining!. You are a programmer, you should know
> what you are doing. If you didn't want the getter method to execute,
> then you should have debugged the field variab
2011/9/13 Graeme Geldenhuys
> Not at all! The debugger I am working on ONLY reads the debug
> information embedded in the executable - in my case DWARF info supplied
> by FPC.
>
Graeme, are you working on Duby or some new debugger?
I found your old mails that mentioned a Sybil debugger.
Another
Graeme Geldenhuys schrieb:
On 13/09/2011 01:43, DaWorm wrote:
I don't understand why a property with a getter could ever be ran by a
debugger. If I have a property called NextValue, implanted by a method
Yes, yes, but I am a big boy and know what I am doing, so I do NOT want
the debugger to l
Flávio Etrusco schrieb:
Right, property getters can have side effects, like all procedures. That's
why I already suggested an hint on property declarations, telling which data
item should be displayed for the property.
Yes. Delphi has/had an option to enable function calls/side effects on
pro
On 13 Sep 2011, at 14:52, Graeme Geldenhuys wrote:
On 13/09/2011 14:33, Jonas Maebe wrote:
No, he's saying that it should not be easy to do this accidentally. I
can imagine that in IDEs that evaluate everything your mouse cursor
happens to hoover over, automatic evaluation of getters with sid
On 13/09/2011 14:33, Jonas Maebe wrote:
>
> No, he's saying that it should not be easy to do this accidentally. I
> can imagine that in IDEs that evaluate everything your mouse cursor
> happens to hoover over, automatic evaluation of getters with side
> effects can be quite an annoyance.
Ag
On 13 Sep 2011, at 14:20, Graeme Geldenhuys wrote:
What you are describing is like saying "we are not supposed to change
values at runtime while debugging either".
No, he's saying that it should not be easy to do this accidentally. I
can imagine that in IDEs that evaluate everything your mo
On 13/09/2011 01:43, DaWorm wrote:
> I don't understand why a property with a getter could ever be ran by a
> debugger. If I have a property called NextValue, implanted by a method
Yes, yes, but I am a big boy and know what I am doing, so I do NOT want
the debugger to limit what I am allowed to d
On 12/09/2011 22:37, Hans-Peter Diettrich wrote:
>
> I expect that RTTI is used by an FPC debugger, but I don't expect that
Not at all! The debugger I am working on ONLY reads the debug
information embedded in the executable - in my case DWARF info supplied
by FPC.
Regards,
- Graeme -
--
f
On 13/09/2011 12:11, Jonas Maebe wrote:
afaik, requires hardware support.
Support has to be implemented in GDB for each architecture before it
will work (currently it's implemented for x86 and ARM, afaik), but it
does not rely on special hardware support.
http://www.gnu.org/s/gdb/news/re
On 13 Sep 2011, at 12:22, Martin wrote:
On 13/09/2011 10:31, Flávio Etrusco wrote:
GDB supposedly has support for reverse execution/walking back; I
don't
even know whether it really works for C, not to mention FPC calling
conventions, but if it does it would be a killer ;-)
It's unrelated
On 13/09/2011 10:31, Flávio Etrusco wrote:
GDB supposedly has support for reverse execution/walking back; I don't
even know whether it really works for C, not to mention FPC calling
conventions, but if it does it would be a killer ;-)
afaik, requires hardware support.
most intel cpu don't
___
On Mon, Sep 12, 2011 at 11:42 PM, Hans-Peter Diettrich
wrote:
> DaWorm schrieb:
>>
>> I don't understand why a property with a getter could ever be ran by a
>> debugger. If I have a property called NextValue, implanted by a method
>> called GetNextValue, that increments a field, stores it in a da
DaWorm schrieb:
I don't understand why a property with a getter could ever be ran by a
debugger. If I have a property called NextValue, implanted by a method
called GetNextValue, that increments a field, stores it in a database,
and returns the new value, I absolutely do not want the debugger
I don't understand why a property with a getter could ever be ran by a
debugger. If I have a property called NextValue, implanted by a method
called GetNextValue, that increments a field, stores it in a database, and
returns the new value, I absolutely do not want the debugger to execute that
even
cced to lazarus list. please switch list.
On 12/09/2011 21:28, Hans-Peter Diettrich wrote:
Martin schrieb:
Mind, I do NOT want to play down say that the lack of property support.
I didn't notice until now that my problems may be related to
properties. AFAIR I also couldn't inspect global va
Martin schrieb:
On 12/09/2011 11:06, Hans-Peter Diettrich wrote:
IMO debugging support was one of the reasons, why Kylix was based on
Wine, and the cross-platform versions of Delphi use remote debugging
only. For that implementation a tiny (remote) debugger interface is
sufficient, and the I
Martin schrieb:
You can't have one tool for everybody and everything. A debugger can
not (and must not) know about all languages. Language specific support
IMO should reside in another layer (IDE, plugin...) between the
debugger and the user.
Never said that. My statement was about pascal (f
On 12/09/2011 20:46, Joost van der Sluis wrote:
On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote:
On 12 Sep 2011, at 20:20, Martin wrote:
Could not properties mapping to a function be implemented the same way => normal
functions are already listed in "ptype" so
public
property Counter
On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote:
> On 12 Sep 2011, at 20:20, Martin wrote:
>
> > On 12/09/2011 19:14, Martin wrote:
> >> Currently properties that map to a field are already present in dwarf
> >> (again why not in stabs?).
>
> Because Stabs is legacy and I don't want to spen
On 12/09/2011 19:31, Jonas Maebe wrote:
On 12 Sep 2011, at 20:20, Martin wrote:
Could not properties mapping to a function be implemented the same way => normal
functions are already listed in "ptype" so
public
property Counter: Integer read GetCounter
could appear the same as the functio
On 12 Sep 2011, at 20:20, Martin wrote:
> On 12/09/2011 19:14, Martin wrote:
>> Currently properties that map to a field are already present in dwarf (again
>> why not in stabs?).
Because Stabs is legacy and I don't want to spend time on it.
>> Could not properties mapping to a function be imp
On 12/09/2011 19:14, Martin wrote:
On 12/09/2011 19:08, Martin wrote:
On 12/09/2011 18:32, Jonas Maebe wrote:
While not a complete solution either, couldn't you use the
information from the Lazarus codetools to figure out which
properties exist? If that's currently not possible because you don
On 12/09/2011 19:08, Martin wrote:
On 12/09/2011 18:32, Jonas Maebe wrote:
On 12 Sep 2011, at 14:07, Martin wrote:
Anyone care to comment on those ideas?
Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature
request?
I really don't
On 12/09/2011 18:32, Jonas Maebe wrote:
On 12 Sep 2011, at 14:07, Martin wrote:
Anyone care to comment on those ideas?
Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature request?
I really don't like hacks like that. They will have
On 12 Sep 2011, at 14:07, Martin wrote:
> Anyone care to comment on those ideas?
>
> Are they worth to be made a feature request?
> And if so, which of the proposed ideas should be made into a feature request?
I really don't like hacks like that. They will have to be maintained almost
forever
Anyone care to comment on those ideas?
Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature
request?
On 11/09/2011 23:15, Martin wrote:
Like it was done for properties that directly map to a field. The now
are somehow encoded, so
On 12/09/2011 11:06, Hans-Peter Diettrich wrote:
IMO debugging support was one of the reasons, why Kylix was based on
Wine, and the cross-platform versions of Delphi use remote debugging
only. For that implementation a tiny (remote) debugger interface is
sufficient, and the IDE can implement
On 12/09/2011 10:55, Hans-Peter Diettrich wrote:
Martin schrieb:
More than that, Lazarus is not the only way to use the info, people
use other IDEs or gdb directly => all that needs to be considered.
You can't have one tool for everybody and everything. A debugger can
not (and must not) know
Graeme Geldenhuys schrieb:
Just the other day I had to use Delphi 7 again to do some maintenance on
one of our older products. That's when I again came to the realization
what dismal state FPC's debugging support is at - it's like travelling
back in time to the early 80's where using writeln() w
Martin schrieb:
More than that, Lazarus is not the only way to use the info, people use
other IDEs or gdb directly => all that needs to be considered.
You can't have one tool for everybody and everything. A debugger can not
(and must not) know about all languages. Language specific support IM
On 12 Sep 2011, at 09:22, Graeme Geldenhuys wrote:
So maybe one should start a wiki page regarding this, putting down
some
ideas that others can review and contribute towards? Building up
towards a specification we can later submit to the DWARF guys.
That certainly sounds like a good idea.
On 12/09/2011 09:13, Jonas Maebe wrote:
>
> You don't have to wait until it is published. Both gcc and gdb
> supported provisional DWARF4 features before the standard was out.
And then standing the chance of it being reject - thus doing the
implementation in GCC and GDB all for nothing. But may
On 12 Sep 2011, at 08:56, Graeme Geldenhuys wrote:
On 11/09/2011 23:40, Jonas Maebe wrote:
extensions. I don't see the advantage of allocating one of those and
communicating it to other compiler writers (to avoid them using that
same extension for something else) instead of submitting it for
i
On 11/09/2011 23:40, Jonas Maebe wrote:
> extensions. I don't see the advantage of allocating one of those and
> communicating it to other compiler writers (to avoid them using that
> same extension for something else) instead of submitting it for
> inclusion in the official DWARF standard though.
On 11/09/2011 22:36, Graeme Geldenhuys wrote:
On 11/09/2011, Jonas Maebe wrote:
Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone
submitting a proposal to add them to the DWARF standard either. See e.g.
I was under the impression that you could now define (at least with
On 11 Sep 2011, at 23:36, Graeme Geldenhuys wrote:
> On 11/09/2011, Jonas Maebe wrote:
>>
>> Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone
>> submitting a proposal to add them to the DWARF standard either. See e.g.
>
> I was under the impression that you could now de
On 11/09/2011, Jonas Maebe wrote:
>
> Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone
> submitting a proposal to add them to the DWARF standard either. See e.g.
I was under the impression that you could now define (at least with
DWARF3 upwards) your own types or language
On 11 Sep 2011, at 19:39, Martin wrote:
> Just thought to catch up.
>
> what is the status on dwarf -3 ?
Nothing has changed recently.
> The 2nd idea is about properties. Afaik in dwarf-3 they may even be encodable
> => though I have no idea what gdb would do with the info.
Neither DWARF 3 n
Just thought to catch up.
what is the status on dwarf -3 ?
I just did a test with fpc trunk / gdb 7.3-2 => It appears to work
reasonable good (though I can't test all possibilities).
A few types get messed up, as the idea tries to work dwarf2 or stabs
tricks on the data, but that can probably
43 matches
Mail list logo
