Hi,

It seems the other debugger thread was blocked - or Gmail is on the frits again. :-/ Anyway, I added a feature request in the wiki for a working / custom written debugger.

http://wiki.freepascal.org/Feature_Ideas#Integrated_and_Working_Debugger

If anybody has comments or ideas, please add them. I don't know where is the best place for such communications - here or in the wiki page, or wiki Talk pages (I have never used the latter yet).

Maybe we can get a renewed interest in the <lazarus>/debugger/fpdebug/ project. My knowledge of compiler or debugger internals are zero, so don't know how much I can contribute. But if possible, I will try. A working debugger will benefit everybody! I really think a working & integrated debugger must be one of the high priorities for the IDE - more that say new IDE eye-candy. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I still thin you exaggerate "Debugging from inside the IDE is near impossible". => it is not very comfortable though.

Some of the problems are not gdb specific, some a solved.

* CPU window => available in 0928

* Record.field => Not (always) a gdb problem. Never mind which debugger you use, no debugger can guess what the context of your mouse pointer is. If the IDE only passes the word-under-caret for the hint evaluation, then no debugger will know what "field" means.
If the watches window can show "record.field" then gdb can do it, but the IDE must be fixed.

* properties => discussed a thousand times.
With FPC trunc and dwarf debug info, some properties actually do return a result in GDB
Properties that read from a function, are the same as a function. For those who really want to run the function, it comes down to function calling from gdb, rather than being property specific

Martin

2009/10/1 Martin :

I still thin you exaggerate "Debugging from inside the IDE is near impossible". => it is not very comfortable though.

Well, then you clearly know which loops to jump through in Lazarus. Just about everything I try and debug in Lazarus doesn't work - and I try and use Lazarus debugging like I used Delphi or Kylix debugging.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

working debugger will benefit everybody! I really think a working & integrated debugger must be one of the high priorities for the IDE - more that say new IDE eye-candy. :-)

Like ABorka told me in a private email. Once Embarcadero brings out 64bit support and cross-platform compiler (latter is what they are working on now), then Lazarus will loose a large appeal from Delphi developers. At the moment FPC and Lazarus offers features Delphi doesn't have, but not the critical features which will allow them to switch to Lazarus permanently.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Well then help extending the wiki page with the loops....

Like adding tips, how to use (and where not to use) value inspection via hint. (personally I never used this, so I couldn't run into this issue. I dislike having to re-locacte the mouse after every single-step, rather using the watches window.
But a matter of taste, so yes for you it is less comfortable.

Viewing record structures with a hint is still possible, just hover over the actual name of the variable (the record, not the field), and you see *all* values. Usability depends on the size of the record...

Arrays are still an issue. I admit this. With fpc trunc you can get along, if and only if (to many if) you have declared a named type. And if (!) you add the extra pointer dereference.

So are nested procedures, and local variables in the outer scope. Only way is to set the current stackframe in the stack window.

What where your other issues?

Well this is because no one is getting paid for working on Lazarus. So manpower is an issue.

On the other hand it means no one depends on people using it. If they want to use it, that's great. If they don't no problem at all (because no one is losing there job/salary/means-of living).

Anyway, lots of companies just go for delphi, because there still is an implicit mistrust towards open source. They feel more secure if they have bought a product, and have the feeling they got some warranties towards it's usability or availability or whatever.

Anyway no one has denied that features are missing. As for debugging there is a dis-consent about the wording or extend that those missing feature have (at least between me and you (Graeme). But not about the fact that it would be nice (essential for some) to have. But what can be done? There are limited amount of people to do the work on Lazarus. So it takes time.

As for making it a priority, anyone is welcome to supply patches. If not, it's a gift horse, so you know what not to do.... ;>

Best Regards
Martin

my comments, thoughts and desires 1000000000000000000000000000% :)

same for me and my base it TP6 and/or TP&/BP7 :? :(

not only me but many others "old school" TP/BP 6/7 coders who are wanting and, in this day in age, needing to convert to a mode modern coding kit ;)

FWIW: it is hard for others to be able to ply in the same field when others are creating the field and possibly leaving a few hints here and there as to the methods of how to use said playing field... surely there is some mechanism that can be or already is included such that some "real layman's" documentation can be pulled out and compiled into a local help resource as well as being included into an online and even wiki help resource format ???

yes, as an old coder who has played with several addon utils that can/will parse certain comment formats of "how to use", i fully understand then necessity of the developers of FPC, Lazarus and all additional libraries to write these documentations as they go but this and similar discussions have already appeared and the basic consensus is that while it may be done, if the code to do it isn't there, then oh well, we have to deal with what is there...

FWIW2: i agree completely and fully understand all of the above as well as the 3rd party coder's stances... the major thing i see is that FPC/Lazarus could easily become the largest coding platform if more assistance was available from the built in help stuffs... that's first and foremost... secondaryily would be close help and support on a "live" basis but it is also seen that this would detract from the developers of the compilers, debuggers, and RAD interfaces and their work on implementing the necessary capabilities, bug fixes and features... somewhere in here, some group of "layman translators" need be done such that the implementator's descriptions of how things really work can be written in layman's terms for the "casual" pascal coder without the need for them to have an active connection to pull the necessary help info and/or decoding of the ways in which to use the available code functions and routines...

i really do hope that this makes sense and doesn't come off as insulting, belittling or antagonistic to those in the know... remember, eventually, these 3rd party "weekend coders" are/may be a large percentage of the users of this pascal environment... yes, i'd like to see this capability come much sooner than so far later... these days in time, i'm one of the former than the latter which is a major difference than how it was for me some 10+ years ago...

while i fully agree on the one hand, i also see other OSS projects that do have a commercial/professional side to them whereby they do earn $$$ to pay the commercial side developers... at the same time, those OSS projects do also have a truely OSS side to them whereby the OSS side can be easily handled and supported which also goes to enhance and further the commercial side and visa versa...

cannot this also be done with FPC/lazarus??

2009/10/1 waldo kitty :

the 3rd party coder's stances... the major thing i see is that FPC/Lazarus could easily become the largest coding platform if more assistance was available from the built in help stuffs... that's first and foremost...

I agree. The more developers we can attract, then the potential amount of contributes could increase too. I do realize that there isn't a one-to-one relationship with users and contributes, but if I can comment on my own experience as a user... Before lazarus I knew nothing about internal IDE works etc... But using Lazarus and being able to see the code, makes me want to add features I would like to see - obviously based on my skill level.

As I mentioned before, my abilities to work on (or even understand) debuggers is near zero. So I try and contribute in other ways. For example. I see a large need for offline help and a consistent help format. I have this need in fpGUI and Lazarus applications (including the Lazarus IDE). I am currently working on a solution which I will contribute back to the community. I have already worked on a dedicated help file format (uncompiled and compiled help), and am currently busy created a help viewer. As a bonus to all, I will be translating the FPC Programmers and Users Guides to this new help format - as a test for others to see how it works. As a bigger bonus, the new help system works like a bookshelf (or library). I can pass multiple help files to the viewer and it integrates there TOC and Indexes, so searches and browsing happens across all help files. This features will help context sensitive help in the IDE a lot - search for IDE help, Language help, Compiler help etc... all with one F1 key. And have I mentioned it's damn quick.

So no I can probably not help implement a new debugger (though I will try if possible), but I do try and contribute in areas I have skills in. But I can contribute from a users point, by raising issues and features lacking in the IDE. If we can get a constructed discussion going, maybe we can generate more interest in fixing the various shortcomings of the IDE.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/10/1 Martin :

Well then help extending the wiki page with the loops....

I try and update wiki pages where I know about the subject (even though I do not agree that the wiki is a good help system). But it's hard to write help on a subject I know nothing about. I do not have tips and tricks for getting debugging working in the IDE - hence these recent message threads.

So are nested procedures, and local variables in the outer scope. Only way is to set the current stackframe in the stack window.

...and there you lost me already. :-)

What where your other issues?

I will try and use the Watch window today and see how it goes. I'll make a list of things that are not work for me, and post them to the list. If we can get workarounds for other solutions for them, I'll update the debugger wiki pages with those solutions.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Search the archives about the pros and cons

Marc

2009/10/1 waldo kitty :

That would require a lot of administration and setting up a Lazarus Foundation / Organization etc. More work than it's worth.

My company doesn't give financial backing to FPC or Lazarus projects, but it does allow us as developers to spend some time on new features, bug fixes etc for these projects. After all, our company benefited a lot from the switch to FPC and Lazarus. So it's only common decency to give something back.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

[...]

The IDE now passes the current expression string to the debugger for the "tool tip".

For example:

var
  r: TRect;
begin
  r:=Rect(1,2,3,4);
  r.left:=4;
end;

r.left now evaluates to 1.

Mattias

Right, but I doubt that Delphi will become multi-platform multi-widgetset really soon. Unless they learn from the Lazarus implementation ;-)

Well this is because no one is getting paid for working on Lazarus. So manpower is an issue.

About the same for Delphi, their developers cost money, which has to be earned soon. The discussion about Delphi pricing, Explorer versions etc. reveals the future separation between Delphi and Lazarus users.

IMO one thing should be done:

Split Lazarus into an Stable and an Featured/Experimental branch. Remove all half-baked and troublesome features from the Stable branch, then make the remainder work properly, and add the most reqired yet missing features, step by step. Then base the Experimental branch (classes...) on the Stable branch, respecting *all* determined stability requirements.

IMO too much time and efforts is spent in new features and eye candy, while other features are blocked by bad design of essential classes, and the project members do not allow for the required downstripping.

DoDi

Well again the question of man power.

Right after 0.9.26.2 was released, Vincent had ask if any one wanted to maintain the fixes branch, no one came forward (afaik).

Also having a branch doesn't change what people work on:
- If people still work on the "eye candy" (besides it is not as if people did only that), then those features would eventually be merged, and no other work was done on the stable branch.
- You still needed the people who do the "most required yet missing features"

I am not sure what was required to be down striped, but I would be surprised if the reason for not doing it was eye candy. So I doubt that a branch would help.

It has been done the other way round. Where huge experimental changes have been done in a branch and later merged. For example the "lcl smartlink" branch.
I am sure if there was a request, and someone behind it to do the work, and if the concept of the changes was *agreed* on, then a branch could be created, and later merged back (just my opinion).

As for getting the essentials done. the problem is to find a volunteer. The "developers" are volunteers too, they do what they volunteered for. Not what some one else would want them to do (well actually plenty of times they do, what others want).

Best Regards
Martin

I keep my work on pascal debugger
(https://sourceforge.net/projects/duby), but it goes slowly, because of lack of time.

thanks,
dmitry

dmitry boyarintsev wrote

I keep my work on pascal debugger (https://sourceforge.net/projects/duby), but it goes slowly, because of lack of time.

I tried to debug lazarus.exe using it :) Well, it shows me info about dll loading, I can view registers, EIP. But after splash showing it catches an exception and terminating the process.

Anyway, I am pleased to see that you are working both on linux, mac and windows versions at the same time. Good start.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

Anyway, I am pleased to see that you are working both on linux, mac and windows versions at the same time. Good start.

Well, after all, as Marc said for thousands times: writing a proper debugger is not using system API, it's reading debug info.

thanks,
dmitry

2009/10/1 dmitry boyarintsev :

I keep my work on pascal debugger (https://sourceforge.net/projects/duby), but it goes slowly, because of lack of time.

Excellent. I'll fetching the repository now, to try it out. Because the project is so new, maybe now is an ideal time to track the changes and see if I can learn anything about debuggers and how they actually work.

I found the other Object Pascal based debugger in
<laz>/debugger/fpdebug/ but that was a Windows specific project. Which makes me think, why is 'fpdebug' in the lazarus repository if it is Windows specific?

Graeme Geldenhuys wrote

I found the other Object Pascal based debugger in <laz>/debugger/fpdebug/ ?but that was a Windows specific project. Which makes me think, why is 'fpdebug' in the lazarus repository if it is Windows specific?

It's Marc's project. He started it, just because he needed win 64-bit debugger. I guess gdb supports 64 bits these days.

thanks,
dmitry

2009/10/1 dmitry boyarintsev :

I keep my work on pascal debugger (https://sourceforge.net/projects/duby), but it goes slowly, because of lack of time.

I announced your project in the MSEide newsgroup as well. Hopefully we can spark some more interest in this project.

Hello:
In barrapunto.com (a Spanish slashdot) there is an article asking "What do you know about Lazarus?". Most comments were positive, and most negative comments were against Pascal (it's a dead language etc) more than against Lazarus.

Here is the link to the article (in Spanish)
http://preguntas.barrapunto.com/article.pl?sid=09/09/28/2211206

But there were a few comments with objections to Lazarus. One of them was about debugger.
This comment the (also in Spanish)
http://preguntas.barrapunto.com/comments.pl?sid=82108&cid=1176899

In this comment he supported Lazarus, but the last paragraphs made some objections. Here is a translation of the last paragraphs, sorry if my English is not good enough

"Some problems I find in Lazarus a those that unfortunatelly can be found in most OSS. On one hand they have amazing features that can't be found in their commercial counterparts, on the other hand they lack elemental features that are waiting to be implemented and waiting and waiting and waiting and waiting....

"Some of the elemental things I miss are: The debugger can't see properties values of objects (A framework for a OOP without being able to watch objects in the debuger!, that's an oxymoron) and nested procedures can't see parent variables. And some bugs never disappear, or disappear and appear again".

Well, I don't know what bugs he was talking about, but about the debugger I think he is right. I would also add a help. Those should be 0 priority: you need to debug and with thousands of objects/functions you need to access to help very often. Code completion, folding code etc are wonderful features, but with a good debugger and a good help is like a car with GPS, four airbags, but with gas tank for two liters.

Santiago A.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091002/26c330ac/attachment.html>

Correct, and I've still dmitrys patches lying around to make it multiplatform.

Marc

Well as I already mailed: Some properties can be inspected now (using fpc 2.3.1 and dwarf). So this is (partly) fixed.

"Some properties" means properties that have an read-accessor pointing to a variable.

Properties that have a function to provide the value can not be inspected.
* And I am more than happy they can not *

Yes Delphi can do this and does do this. And what does it mean? If in Delphi I accidentally hover the mouse over a property, The function is called (actually Delphi calls it twice). As a result all Values on the object change (because many functions do more than just read values, they update values too).
The application is in a state that is no longer correct (because the values have changed to something they where not supposed to be). And I have to abort my debug session and start over. What help is that?

What help is it when an IDE (Delphi) silently and without warning does things that change the state of my application. How can I expect any results from debugging if the IDE messes around in such ways with the application that I debug?

As far as I am aware the purpose of debugging is to get the same results as in a normal execution. This is unless I intentionally and explicitly ask the debugger/IDE to modify the data.

Please feel free to translate to Spanish, and post in the above forum.

Best Regards
Martin

I disagree with you. Most getter functions only do that, get the value without changing anything, but are functions because the resulting value is processed.
A property getter function, can, but should not, change anything. Even if the getter changes something, it?s up to you, as a developer, to inspect such property or not...
I use this every day on Delphi and, in my work, is an invaluable tool, that lazarus should have.
May be, for people like you, in the debugger options page, could be an option to disable this funcionatility for tooltip debugging or for all the debugging, but this should be enabled by default.

This is only my point of view.

Horacio

Martin escribi?:

2009/10/2 Horacio Jamilis :

I fully agree. Delphi has that option by default and it is very handy. Yes you could have unexpected result, but that is up to you as a developer to know your own code.

A option to disable such support could be handy for developers like Martin, but I am pretty sure most other developers would like that option enabled by default.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

The feature that is missing in lazarus is "function evaluation" and yes it is (yet) missing.
As for how valuable it is, is a personal question. I rarely need it, some other people can not live without it.

As for "Most getter functions only do that, get the value ": I don't have delphi sources, I cannot check. But for example the property "Handle" afaik does change things (if no handle has been allocated it will do that, including requesting it from the OS).

And delphi is inconsistent in that.
  property Foo read GetFoo;

if i put "foo" and "getFoo" in my watches window, then:
- Foo is evaluated (despite the fact that "function evaluation" is NOT ticked on the watches property)
If you ask me, it should *only* work, if explicit enabled.
- getFoo is not evaluated (correct because "function evaluation" is NOT ticked on the watches property)

So why is "Foo" evaluating a function, even so this is not enabled by the settings for this watch? That is a bug if you ask me, and a severe one, since it can thrash hours of debugging work.
Oh yes, of course, I know when I add it as a watch. Actually I may do, but someone new to deplhi doesn't (I was once new to it too), so they get screwed...

And keep in mind, even a function that is not supposed to modify thinks can end up doing so. Evaluating the function, at a time the function was not meant to be called, may cause a crash, and may cause memory corruption..... There are plenty of hidden dangers, they may only occur in a few situations, but the can and will. And there is no warning at all, Simple pointing your mouse on a property (and getting hint evaluation) can destroy hours of debugging effort (again no warning...)

And if the property has a function that does modifications: if you put it in the watches and then run the hint too => you see different values (because they changed in between)

I agree "function evaluation" in the debugger can be a very helpful feature. That is it is helpful when used intentionally, sot the developer knows what side-effects may happen.
The way Delphi has it, doing it with no warning at all => very dangerous.

Best Regards
Martin

In theory is dangerous, in real world it seldom (if ever) happens.

The risk is so little (I have never face such problem) and the advantage so big that the score, in my opinion, is 1E+6 to 1.

Santiago A.

Martin escribi?:

I agree, it is handy option. Well we have to wait till someone has time to do it, or someone contributes it.

A option to disable such support could be handy for developers like Martin, but I am pretty sure most other developers would like that option enabled by default.

It may be valuable for an experienced developper to have it on. From the little I remember of the days i first used delphi as a newbie. It would have been better if It had been off.

Just because of a lot of properties would crash half way through if something wasn't initialized. To explain this, at least when I was new, a lot of my code wouldn't have checks, if things are in the correct state, so it was very easy to crash it (well I was new to programming).

Today of course, my code is more stable, I know the risk, etc => I wouldn't be troubled by the feature. So I could enable it. My view is, that once such a feature has been done/contributed, it should be disabled by default, but when you attempt to evaluate a property, you can be asked (with propper warnings) if you want to enable it.

----
Anyway I think I went of the path. It was not my intention to say that such a feature should not be done, of course it should. (Even though with different defaults).

The point that most annoyed me is the sub-tone some msg seemed to imply (and it was *not* Graeme's messages).
What is the point in "ranting" or "alleging" that it wasn't given priority, or that some one couldn't or wouldn't use Lazarus because of this?

No one is forced to use Lazarus. It's free, free to be used or not to be used, and free as in "no money charged".

Whoever contributes to it, does contribute what they feel they want to do. Because they do so in there spare and free time. (And more than often they do things people have ask for, rather than things they need/want for themself). This is the concept of contribution. How many people would spent there free time to it, if it would mean that some-one else acts as their boss, telling them what to do?

And to save the honour of graeme, he started 3 threads: http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-September/045378.html http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-September/045380.html http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-September/045383.html

All three where basic question, if there was a way, and if so which way it was. Only the last one also expressed some "frustration" about the inaccessibility of the debug features.

Then later mails (other people) developped into statements like "The debugger is not usable as it does not have been in the focus to be developed. " or " lack elemental features that are waiting to be implemented and waiting and waiting and waiting and waiting"; And then soon saying this was a reason for people not to use Lazarus, or to move away from Lazarus.

This is neither true (the focus part, because there was and right now is development) nor does it help the discussion. If the debugger is not usable to someone, then go for the alternative. Spent some hundreds of dollars and buy delphi. No one is stopping you.
Saying that you will do so or have done so may or may not change the path of Lazarus development. While I have observed big efforts by the Lazarus developper team to actually meet the requests of many users => The fact is: Doing so is voluntary, but not an ultimate requirement. Delphi must deliver what the users ask for, or else they make no money. Lazarus does make no maney anyway. Lazarus wants to deliver, but it does not have to.

And if it takes long, Well anyone can contribute. Some brought up the convenient argument they don't know about the internals of debugging. Well you do not need to. Intact the very first patches I sent to Lazarus where about debugging, and I knew nothing. GDB is well documented on the net. The Lazarus part of controlling GDB is well separated from the rest, so it is easy to learn too.

Just my opinion
Martin

I am not sure what was required to be down striped, but I would be surprised if the reason for not doing it was eye candy. So I doubt that a branch would help.

There exist a couple of troublesome elements in basic classes. IMO the Controls unit with those many managers deserves downstripping and refactoring, for better maintenance and extensibility. It should be reconstructed bottom-up, with defined hooks for features and implementations to-be-added.

It has been done the other way round. Where huge experimental changes have been done in a branch and later merged. For example the "lcl smartlink" branch.

That's okay with modifications of almost known impact, which are implemented by a single person. Refactoring with an impact on many places cannot be done this way.

You're right, a branch for itself won't help. What I want is an extract of the existing code, from which in the first step everything is excluded that is not documented in Delphi or somewhere else, and that is not fully implemented and tested. The excluded functionality is replaced by hooks that allow to add according code later, with little impact on the remaining code. When the design is okay, it should be extensible by simply adding modules to the core implementation.

I am sure if there was a request, and someone behind it to do the work, and if the concept of the changes was *agreed* on, then a branch could be created, and later merged back (just my opinion).

Merging back should not really be required in a modular approach. It's the required redesign of the base classes, that is usually blocked by "it works as is, why change it?", and by the consequential work required in other places of the existing code base :-(

As for getting the essentials done. the problem is to find a volunteer. The "developers" are volunteers too, they do what they volunteered for. Not what some one else would want them to do (well actually plenty of times they do, what others want).

It's not a matter of *what* somebody wants to do, but IMO a matter of *how* it should be done, if ever. Bloating the code base should be allowed *only* with according documentation, everything else should be kept out of the trunk. But actually the privileged project members work on what they like to do, leave critical pieces "for later" - meaning "somebody else shall do it" - and then continue with something else. Many contributions are blocked this way, when they deserve hooks that do not already exist in the code base.

IMO we should have an independent project management, establishing the goals (and priorities) for a usable product, and kind of quality control, that is entitled to request documentation and verification from the implementors. All contributors should be proud of having their contributions acknowledeged and added to the project, not only of "I added something that looks useful or nice".

DoDi

Martin wrote:
[...]

I agree "function evaluation" in the debugger can be a very helpful feature. That is it is helpful when used intentionally, sot the developer knows what side-effects may happen. The way Delphi has it, doing it with no warning at all => very dangerous.

I've these experiences too, therefore I put little effort in enabling it in Lazarus.

Marc

And to balance the praise of graeme, he wrote on the wiki http://wiki.lazarus.freepascal.org/Feature_Ideas#Integrated_and_Working_Debugger: <quote>Debugging from inside the IDE is near impossible.</quote> <quote>This should become a bigger priority than more eye-candy for the IDE.</quote> <quote>Unfortunately with open source projects, contributors only contribute to fulfill their own needs, and not the needs of others.<quote>

To me, this pretty much says about the same as in the paragraph above. Fortunately he still<quote>loves the many unique IDE features Lazarus has to offer.</quote>

I wish I was capable of editing that feature request to make it more reasonable and factual. IMHO, the GDB is not as much C/C++ centric, but it is a stand-alone application, and not integrated (in process) in the IDE like in Delphi. Stand-alone debuggers always have more limitations.

And what do you think is next? Delphi like packages? Or should that be implemented before we even think about improving the debugging experience in Lazarus?

Vincent

+1

Writing an multi-platform compiler is easy, compared to an multi-platform debugger. Local procedures introduce many problems, they are not handled by standard debuggers because there exists no common implementation across compilers and languages. Properties are more common, and it should be possible to add them to the Lazarus specific debugging code.

+1

DoDi

Right. A C++ style "const" attribute were helpful, in order to distinguish between mere "inspectors" and other getters that change the state of an object. Or we could add an "inspect" directive to the property "read" and "write" directives...

"property" ... "read" GetProp ["const"] ["inspect" SeeProp] ...

DoDi

2009/10/2 Martin :

My view is, that once such a feature has been done/contributed, it should be disabled by default, but when you attempt to evaluate a property, you can be asked (with propper warnings) if you want to enable it.

That would be sufficient I think. They main thing should be that the behaviour is user selectable. If the default setting is off, it is no effort to simply tick one checkbox and have en enabled for all future development.

themself). This is the concept of contribution. How many people would spent there free time to it, if it would mean that some-one else acts as their boss, telling them what to do?

I fully agree with that. In I apologize if I came of harsh in some of my postings. Sometimes I get a bit frustrated with my PC when it doesn't do what I want. :-)

2009/10/2 Vincent Snijders :

And to balance the praise of graeme, he wrote on the wiki

Oh, it's Friday again! ;-)

http://wiki.lazarus.freepascal.org/Feature_Ideas#Integrated_and_Working_Debugger:

I'll try and put that feature request in a more subtle tone. When I wrote that, it must have been one of my troublesome days.

2009/10/2 Vincent Snijders :

http://wiki.lazarus.freepascal.org/Feature_Ideas#Integrated_and_Working_Debugger:

I have updated that text. Please review and modify as you see fit.

Thanks, it is more balanced. Maybe a future editor (or me in the future) will remove the paragraph that starts with Unfortunately, as it doesn't have much to do with the feature request itself, more with the fact that you don't implement it.

Vincent

2009/10/2 Vincent Snijders :

Thanks, it is more balanced. Maybe a future editor (or me in the future) will remove the paragraph that starts with Unfortunately, as it doesn't have

True. Done!

Martin escribi?:

I apologize if my message seemed aggressive or hostile, I was just translating a comment not written by me. Any how, I think that the paragraph was related to OSS in general, not to Lazarus.

On the other hand, my opinion is that such feature should be enabled by default, as far as I know, no one has ever had a problem with that in delphi. I think you are too cautious disabling such property, or even warning. It is not that dangerous.

Sorry once again if it looked that I don't appreciate your work or Lazarus as it is now. In fact I use Lazarus now.

Santiago A.

That would certainly have a positive side effect here. It would be much more interesting for code optimisation by the compiler....

Martin

I can only very limited answer the below, since without knowing the exact changes in mind I can not judge what is or what is not (according to my opinion) possible

I know there was discussion, do you have the link to it in the archives?

To be honest your description does sound more like a rewrite from scratch (copying bits and pieces in), than just a refactor....

Can the functionality not be moved in small steps? I usually found often in situations like this that it can. It may take a bit longer to do, and it may need some temporary compromises, where the old code keeps some direct links to the new code, whcih will be removed at a later stage....

Then maybe a branch may not even be needed. A branch usually means things get merged at some time. (imho)

What and how translate to the same in this case. Creating a structure like you describe (the "how") is work that needs to be done. And work is "what". If no-one sits done to to the work then it isn't done.

Well the style a project is done, is defined by those who created it. If you can convince them.....
On the other hand the project has come very far, with how it's been done until now.

Anyway as I said if you had the link to the original discussion?

Martin

I just had a look: "all those many managers", there is a drag and a dock manager?

And then the question is who much of this does delphi has?

Martin

Or compiler could deduce this attribute itself and store it in debug info.

> What where your other issues? I will try and use the Watch window today and see how it goes.

As well as the Watch window, are you aware of the excellent little debugserver application (separate executable) written by Michael? This lists messages from your application which you have inserted manually using methods of the dbugintf unit,
such as SendMethodEnter(), Send MethodExit() and SendDebug().

The source is in a folder under /Lazarus/Tools, and the Readme.txt has a stripped down example of actual use.

While you have to set up your application with specific code to send appropriate debug messages, often in debugging you know roughly where things are going belly-up, and a few judiciously placed lines of SendDebug() code will pin-point what is going wrong. Which is far more helpful for those of us who can't make use of the information in the Assembly window!

Howard

2009/10/4 Howard Page-Clark :

I remember hearing about this, but have never look at it or tried to use it. Currently that is very similar to how I debug applications using Lazarus. Simple writeln() statements. Actually what I do lately is create a debugln() method with contains the writeln() code, but that writeln code can be enabled or disabled with a compiler define.

eg:

procedure debugln(<array of params>);
begin
  {$ifdef debug}
   writeln(<array of params>);
  {$endif}
end;

So now I can disable debug output by simply removing the DEBUG define from my project compiler options - no need to go delete the lines all over my code (though I often do that anyway).

Also I created a keyboard shortcut (code template) in Lazarus IDE. I simply type "d" and press Ctrl+J and it adds the following line in my code:

   debugln(<current class.method name here>);

The class and method name is automatically inserted for me via the code templates.

So far this is the most reliable debugging I have found (if I don't use tiOPF which has it's own debugging framework and GUI viewer).