[Lazarus] Class operators

[Martin]

On 08/09/2011 12:38, Graeme Geldenhuys wrote:
>> Menu: "View">  "Debug winows">  "debug output" (I advice to open, it
>> before running your app, or it may take several seconds or loner to open
> I attached the full output in a archived text file.
>
> I see the following line appear instantly when I hover the mouse over
> Sender in the code... Then the delay, then the lots of text output.
>
>     <-data-evaluate-expression TfpgButton(TfpgButton(Sender))^>

Ok the flow of commands is as expected => I do need to fic the double 
typecast => that should be a single typecast only

I don't know if that does upset gdb

It's the only gdb command that returns data => and according to you 
apparently the one that takes 7 seconds.

Looking at the amount of output, it doesn't look like it would take 7 
secs on the pipe => so gdb itself seems to take some time

I'll mail when I fixed hte double cast => let's see if that reduces tiem


>
>
>> BTW, if you get a hint for the global "Form1" variabl;e =>  how long does
>> that take. It should get the same info.
> This took almost double as long to output in the Debug Window. I

Makes sense, since the initial 2 ptype, now both must eval the large 
TForm1 => this points to pat of the issue being either gdb or the pipe.

As for using 2 so similar ptype. The current concept is to try and get 
the result as correct as possible (though within limits, gdb isn't 
suited for it)
I do have the idea of implementing a "quick and dirty" option, in the 
debugger setting of the laz-options. So one can switch to a quicker 
evel, but may have to enter some "^" one sefl to get correct result 
(otherwise a class may be seen as pointer to class or vice versa)
Not sure when I get to that...

>> BTW: if you got time =>  try running ./debugger/test/GDBMI/TestGDBMI.lpi
>> I would be interested, how well it does on 64 bit linux. (if there are
>> error, you can enable "write logs" and send them (fro the failed tests)
>> -- though the xml output already contains basic info.
> There seems to be lots of failures. I'll send you the xml and log
> files in a private message. It's too big to attach in a mailing list
> message.

Will look at, thanks

>> then especially if they are classes, record, arrays (arrays aren't to
>> well handled yet, just another gdb limit :(  )
> I'm working on that - though slower than I was hoping. I'm busy
> implementing a Object Pascal based debugger for FPC (a fork of duby
> with lots of code cleanup).
Ah, i have a similar idea for Lazarus 9though no time at the moment)

I want to start with a hybrid. Lazarus directly reading debug info => 
saving all ptype requests to gdb, and also being able to read difference 
that gdb ignores (strings, object<> pointer ....)

Then in a 2nd step, adding directly reading the debug processes memory 
(and reducing gdb to controlling breakpoints and steps

3rd step obviously getting rid of gdb...


But as I said, time is not on my side....