Hi,
Lazarus has a dialog for conditional breakpoints, but it doesn't work. I
tried everything.
MSEide has conditional breakpoints, but only works for integer type
expressions.
I spoke to Martin (MSEide author) and he told me that GDB doesn't
understand Pascal ansi-string expressions - hence
Graeme Geldenhuys wrote:
PS:
Anybody know how the Duby project (Object Pascal based Debugger) is
progressing, and if support for it could be added to Lazarus or MSEide?
creating a debugger is not that difficult, evaluating (pascal)
expressions is.
And even then evaluating properties is
Op 2010-08-13 11:22, Marc Weustink het geskryf:
creating a debugger is not that difficult, evaluating (pascal)
expressions is.
And even then evaluating properties is impossible.
Well, doesn't FPC evaluates expressions - so why can't a debugger? Also,
couldn't Michael new Expression Parser
On 13 Aug 2010, at 11:14, Graeme Geldenhuys wrote:
Does anybody know if there is a way to support Conditional
Breakpoints in FPC + GDB with string types?
It can be solved without changing anything to either FPC or GDB, by
basically writing extensions for GDB in Pascal. Create a unit with a
On 13/08/2010 10:14, Graeme Geldenhuys wrote:
Hi,
Lazarus has a dialog for conditional breakpoints, but it doesn't work. I
tried everything.
* set a breakpoint where condition is: TypeDecl.Name = 'TRGBTriple'
Seems that gdb expects double quotes
FName = abc
but then it wants
On Fri, 2010-08-13 at 03:03 +1100, Alexander Klenin wrote:
On Fri, Aug 13, 2010 at 02:57, Joost van der Sluis jo...@cnoc.nl wrote:
On Mon, 2010-08-02 at 10:41 +0200, Graeme Geldenhuys wrote:
Op 2010-07-30 17:58, Joost van der Sluis het geskryf:
I'm affraid that when the discussion is over,
Op 2010-08-13 11:42, Martin het geskryf:
I can also Do:
SomeString=OtherString
So if you have the desired name in a variable...
I tried that approach in Lazarus IDE and it doesn't work either.
Breapoint Condition: s = TypeDecl.FName
In the code s is assigned 'TRGBTriple', and the
On Fri, Aug 13, 2010 at 1:31 PM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Hopefully Dmitry could solve these problems with Duby. I haven't evaluated
Duby is some months, but last time I did check, it made good progress. I
guess it's time I get another code update.
No updates. Sorry.
On 13/08/2010 11:20, Graeme Geldenhuys wrote:
Op 2010-08-13 11:42, Martin het geskryf:
I can also Do:
SomeString=OtherString
So if you have the desired name in a variable...
I tried that approach in Lazarus IDE and it doesn't work either.
Breapoint Condition: s = TypeDecl.FName
In
Op 2010-08-13 12:43, dmitry boyarintsev het geskryf:
Duby only allowed to view integer variables. I couldn't get any
further because the proper expression and value evaluation is
required. I've started with the pascal expression parser (now
contributed to passrc).
I thought the expression
Op 2010-08-13 13:04, Martin het geskryf:
Do you have those spaces in the expression when you entered it? Lazarus
currently fails to quote them, so that may not work then.
Ah, that could be it. I typed the expression with spaces.
Anyway, Martin's (MSEide) suggestion of the extra testvar is a
On Fri, 13 Aug 2010, Graeme Geldenhuys wrote:
Op 2010-08-13 11:22, Marc Weustink het geskryf:
creating a debugger is not that difficult, evaluating (pascal)
expressions is.
And even then evaluating properties is impossible.
Well, doesn't FPC evaluates expressions - so why can't a debugger?
On 13 August 2010 13:11, Michael Van Canneyt wrote:
Can you explain this ? As far as I know, there no member of the core team
that objects to having properties inspectable in the debugger ?
I was obviously generalized a bit too much. If you really want me to,
I can search the mailing list
On 13/08/2010 12:08, Graeme Geldenhuys wrote:
Op 2010-08-13 13:04, Martin het geskryf:
Do you have those spaces in the expression when you entered it? Lazarus
currently fails to quote them, so that may not work then.
Ah, that could be it. I typed the expression with spaces.
Anyway, Martin's
On 13/08/2010 12:18, Graeme Geldenhuys wrote:
On 13 August 2010 13:11, Michael Van Canneyt wrote:
Can you explain this ? As far as I know, there no member of the core team
that objects to having properties inspectable in the debugger ?
I was obviously generalized a bit too much. If you really
On Fri, 2010-08-13 at 11:14 +0200, Graeme Geldenhuys wrote:
More reasons I hate FPC using GDB as a debugger instead of a native written
one. Does anybody know if there is a way to support Conditional
Breakpoints in FPC + GDB with string types?
You could try the gdb version from Fedora, and
- Graeme Geldenhuys graemeg.li...@gmail.com schreef:
On 13 August 2010 13:11, Michael Van Canneyt wrote:
Can you explain this ? As far as I know, there no member of the core
team
that objects to having properties inspectable in the debugger ?
I was obviously generalized a bit too
Hi [me again], :)
The 'link' attribute inside section tags where introduced so that
descendant classes can link documentation from base classes - without
having to duplicate the documentation.
eg:
TBaseButton = class()
protected
property ImageName: string; //-- docs done
- Graeme Geldenhuys graemeg.li...@gmail.com schreef:
On 13 August 2010 13:11, Michael Van Canneyt wrote:
Can you explain this ? As far as I know, there no member of the core
team
that objects to having properties inspectable in the debugger ?
I was obviously generalized a bit too
Op 2010-08-13 14:08, Dimitri Smits het geskryf:
btw, what I forgot to respond to in my last mail of a few mins ago:
[...off-topic...]
I'm not arguing with anything you said, just want to add something I only
now remembered from my Delphi days.
The Delphi debugger allowed you to change values
On 13 Aug 2010, at 14:20, Graeme Geldenhuys wrote:
The Delphi debugger allowed you to change values while debugging,
then step
back and re-execute that code with new values [I think I did this
back in
the days of Delphi 5]. Delphi's debugger was pretty damn awesome -
just
makes me
In our previous episode, dmitry boyarintsev said:
I've started with the pascal expression parser (now
contributed to passrc).
a propos, added a --parse-impl option to fpdoc, to keep the implementation
parsing testable without recompilation or distubing doc generation.
I quickly tried to run it
On Fri, 13 Aug 2010, Graeme Geldenhuys wrote:
On 13 August 2010 13:11, Michael Van Canneyt wrote:
Can you explain this ? As far as I know, there no member of the core team
that objects to having properties inspectable in the debugger ?
I was obviously generalized a bit too much. If you
Op 2010-08-13 14:46, Jonas Maebe het geskryf:
Programming them in Pascal code that is linked into the target program
moreover has the advantage that GDB (or any other debugger, even one
Do you have any web link on how to do this, or a small single case example
that could be built on to?
Hi,
It seems that passrc parser doesn't populate the ReadAccessorName and
WriteAccessorName correctly on published properties. eg: where a property
was defined in a base class, and visibility simply bumped to published in a
descendant class.
TButton = class(TBaseButton)
published
On 13 Aug 2010, at 14:52, Graeme Geldenhuys wrote:
Op 2010-08-13 14:46, Jonas Maebe het geskryf:
Programming them in Pascal code that is linked into the target
program
moreover has the advantage that GDB (or any other debugger, even one
Do you have any web link on how to do this, or a
On Fri, 13 Aug 2010, Graeme Geldenhuys wrote:
Hi,
It seems that passrc parser doesn't populate the ReadAccessorName and
WriteAccessorName correctly on published properties. eg: where a property
was defined in a base class, and visibility simply bumped to published in a
descendant class.
Op 2010-08-13 14:02, Graeme Geldenhuys het geskryf:
This works in the HTML output writer (which isn't a linear writer
descendant). This doesn't work in any of the Linear output writers. Was
this by design - maybe to prevent duplicate documentation in PDF's or
something? Or simply another
[... sorry I only noticed now my Subj line is wrong. It should read Element
tags...]
Michael,
Due to lack of documentation regarding the link attribute in Element tags,
how are link attributes supposed be be handled. ps: I'm looking at the
latest PDF docs of the last FPC release.
eg:
What
On Fri, 13 Aug 2010, Graeme Geldenhuys wrote:
[... sorry I only noticed now my Subj line is wrong. It should read Element
tags...]
Michael,
Due to lack of documentation regarding the link attribute in Element tags,
how are link attributes supposed be be handled. ps: I'm looking at the
Op 2010-08-13 16:01, Michael Van Canneyt het geskryf:
In my opinion, the overview of a class member should simply refer to the
page containing the parent's implementation (i.e. the target of the link).
It should not duplicate the documentation.
As far as I understand the current PDF docs
On Fri, 13 Aug 2010, Graeme Geldenhuys wrote:
Op 2010-08-13 16:01, Michael Van Canneyt het geskryf:
In my opinion, the overview of a class member should simply refer to the
page containing the parent's implementation (i.e. the target of the link).
It should not duplicate the documentation.
Martin wrote:
On 13/08/2010 10:14, Graeme Geldenhuys wrote:
Hi,
Lazarus has a dialog for conditional breakpoints, but it doesn't work. I
tried everything.
* set a breakpoint where condition is: TypeDecl.Name = 'TRGBTriple'
Seems that gdb expects double quotes
FName = abc
but then it
On 13/08/2010 16:34, Marc Weustink wrote:
[Note in Lazarus the expression
isn't properly quoted before being send to gdb. So (since it has spaces)
you need to double quote the entire expression, before sending it to
gdb]
It is quoted iirc (or did I forget it somewhere ?).
I was partly
34 matches
Mail list logo
