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 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
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 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
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
24 matches
Mail list logo
