Lazarus Observations

[Gawie]

Dear reader,

I am an aging IT professional with over 3 decades, spanning "everything", most commercial IDEs, languages etc.  Firstly, I am an old (from Turbo Pascal 1.0) Pascal/Delphi fan and regularly check in on whether Lazarus is efficient and effective for production; and can honestly say that the IDE has come a long way (especially wrt stability) - congratulations.

I did not spend significant time to research other similar questions or answers, and also is doubting whether I should send this for not only as my time is limited but in fear of the responses :-)

That said, there are a few old issues that are not entirely obvious to me - maybe it is there - but definitely not "easy" or forthcoming.  I don't want to type essays to explain, but hopefully somebody can either point in the right direction or take note to improve the product:

IDE:
1. The project system, it is single target only.  In order to do unit testing or other, I have to switch to other instances.  This is tough in many ways and make refactoring exponentially more difficult than it should be.  I do understand that there are limitations imposed by the underlying tools, but in order to do anything noteworthy/big I cannot see myself using Lazarus without it driving me up the wall (for this shortcoming).
2. The project system, by its organisation is also surprisingly hard to manage.  It somewhat penalises you for putting a class per file, and makes putting files into directories like "namespaces" more work than it should be


IDE/Debugger:
3. The single biggest issue in adoption of Lazarus is the debugger.  I do respect that Pascal is low level, but with debugging the simplest of things gets very time consuming.  Take e.g. a List of objects; in order to get to the detail you have to go look at memory as the list reflects pointers, while, even with full debugging, I get messsages like "Error: unknown data".  I can name numerous other such cases.
4. The IDE  penalises you for using properties, as the backing property variable and property gets displayed twice when debugging.  This is very distracting and makes working with watches etc double the effort in navigating.  On smaller classes I even avoid the use of properties in favor of smaller watches (which paints the picture...  for coding for a better IDE experence is counterproductive)
5. Even common infrastructure to support the dumping of values here may help.   

Thanks for taking time if you read this post.

Lastly - and please don't fume (sorry) - but choose and promote a single formatter and style; and reformat all the packaged pascal with it.  Age has told me that it is better to conform to a single "standard" rather than to fight the environment.  In other words, when delving into the supporting libraries I see many many different casing, naming conventions etc - and the brain doesn't like it for as much as it is trained to short evaluate colors, inconsistent casing and naming can be very distracting.  When I was young I used to flame about style, now I flame about consistency and will gladly take a slightly inferior style in favor of convention.

Regards

[Thaddy]

I consider this spam. you haven't a clue.

[marcov]

Thaddy: a bit more constructive please.

I am an aging IT professional with over 3 decades, spanning "everything", most commercial IDEs, languages etc.  Firstly, I am an old (from Turbo Pascal 1.0) Pascal/Delphi fan and regularly check in on whether Lazarus is efficient and effective for production; and can honestly say that the IDE has come a long way (especially wrt stability) - congratulations.

I'm 3/4 of that period, most of that with the project.

I did not spend significant time to research other similar questions or answers, and also is doubting whether I should send this for not only as my time is limited but in fear of the responses :-)

Such post rarely resonate with people that actually do something.  Either problems are known, or simply due to a mismatch between the project, and what development systems the poster knows. And the solutions are usually not concrete enough or to radical.

Specially the buildsystem/project stuff suggests a mismatch.

IDE:
1. The project system, it is single target only.  In order to do unit testing or other, I have to switch to other instances.  This is tough in many ways and make refactoring exponentially more difficult than it should be.  I do understand that there are limitations imposed by the underlying tools, but in order to do anything noteworthy/big I cannot see myself using Lazarus without it driving me up the wall (for this shortcoming).

Afaik there are plugins for unit testing. I don't really do unit testing with a framework, so I can't make any practical comments. I only have dedicated test projects for really (algorithmically) complicated code.

2. The project system, by its organisation is also surprisingly hard to manage.  It somewhat penalises you for putting a class per file, and makes putting files into directories like "namespaces" more work than it should be

Both class per file, and putting files into namespace like paths are Javaisms.  The build system of Pascal is totally different then most other popular languages. The Lazarus project system is fairly light, mostly to keep track of files for the GUI parts.

I chalk this comment up to unfamiliarity to Pascal and the principles of its build system.

IDE/Debugger:
3. The single biggest issue in adoption of Lazarus is the debugger.  I do respect that Pascal is low level, but with debugging the simplest of things gets very time consuming.  Take e.g. a List of objects; in order to get to the detail you have to go look at memory as the list reflects pointers, while, even with full debugging, I get messsages like "Error: unknown data".  I can name numerous other such cases.
4. The IDE  penalises you for using properties, as the backing property variable and property gets displayed twice when debugging.  This is very distracting and makes working with watches etc double the effort in navigating.  On smaller classes I even avoid the use of properties in favor of smaller watches (which paints the picture...  for coding for a better IDE experence is counterproductive)
5. Even common infrastructure to support the dumping of values here may help.   

Mostly known. That said, the debugger is what is improving at the speediest rate. It will help if FPC gets it release cadence back in order for this, since improving debugger experience will also need changes to the debug info that the debugging bases on.

Lastly - and please don't fume (sorry) - but choose and promote a single formatter and style; and reformat all the packaged pascal with it.  Age has told me that it is better to conform to a single "standard" rather than to fight the environment.  In other words, when delving into the supporting libraries I see many many different casing, naming conventions etc - and the brain doesn't like it for as much as it is trained to short evaluate colors, inconsistent casing and naming can be very distracting.  When I was young I used to flame about style, now I flame about consistency and will gladly take a slightly inferior style in favor of convention.

Suggested many times, but the actual developers prefer not to pollute VCS over style issues if they are not really pronounced.

Anyway, the only thing I get from this is that the buildsystem (both of FPC compiler, as of the FPC/Lazarus codebases) and the project system on top of it are very misunderstood and under documented.

[carl_caulkett]

I consider this spam. you haven't a clue.

And I consider your response to be abuse.

[silvercoder70]

"Style" is something you/we have to the live with or put up with. And this is not necessarily is criticism of FPC and perhaps goes hand in hand with what the OP said (or part thereof). If you open SysUtils then ....

1. dword vs DWord vs DWORD
2. procedure vs Procedure
3. do you indent 'begin' after procedure or function

Code: Pascal  [Select][+][-]

1. function Foo(...): boolean;
2.   begin
3.   end;
4.  

or

Code: Pascal  [Select][+][-]

1. function Foo(...): boolean;
2. begin
3. end;
4.  

4. the number of spaces between a variable and the colon and variable-type changes

5. whether there are spaces before or after an assignment :=

It just is what it is. I live with it, I don't complain about it. Would consistency be nice? Not gonna poke that bear.

[Martin_fr]

IDE:
1. The project system, it is single target only.  In order to do unit testing or other, I have to switch to other instances.

"Target" is misleading, as it is often used for cross compiling (and that can be managed within one project). I take you mean "single program".

While not exactly what you may be used to, try the package "LazProjectGroups".
Then you can add your
- main program
- test program
- ....
To the group => You can quickly change between them, or run them from the group (context menu).

If you test app is in the same folder as the main app then it does see the same units as the main app.

2. The project system, by its organisation is also surprisingly hard to manage.  It somewhat penalises you for putting a class per file, and makes putting files into directories like "namespaces" more work than it should be

Not sure what you mean.

Namespaces is a language construct, so not sure what that has to do with the project organization. Other than that you may be used to organize your code in certain ways. (I know when I switch between languages (any languages) I do want to write code that does not match the style of the language I switched to)

Maybe you look for packages?

IDE/Debugger:
3. The single biggest issue in adoption of Lazarus is the debugger.  I do respect that Pascal is low level, but with debugging the simplest of things gets very time consuming.  Take e.g. a List of objects; in order to get to the detail you have to go look at memory as the list reflects pointers, while, even with full debugging, I get messsages like "Error: unknown data".  I can name numerous other such cases.

Admittedly, a known problem...

Long history, and complex to solve (in terms of number of involved parties) => GDB/lldb don't know the concept of properties => so until the existence of FpDebug it wasn't happening (well, if someone had wanted to add it to gdb/lldb....).
Now, we have a proposal with the DWARF standard. Then the compiler needs to adapt it, and do a major release. And then the debugger can adapt it....

I know, not your problem what causes it. Just background info.

In some cases (and improved in Lazarus 4) you can call the getter function. (using FpDebug)
- Enable function calling in Tools > Options > debugger
- Enable function calling in the watch property (yes, needs a watch / does not work with hints)
- Add something like (the "()" are mandatory)

Code: Pascal  [Select][+][-]

1.   MyStringlist.Get(1);
2.   MyStringlist.GetText();

Use Dwarf3 or strings may either not work, or cause leaks.

4. The IDE  penalises you for using properties, as the backing property variable and property gets displayed twice when debugging.

How to reproduce?

See my example picture. Width is shown once.

5. Even common infrastructure to support the dumping of values here may help.   

There is LazLogger (search wiki) with plenty of "dbgs()" to print many common types

Code: Pascal  [Select][+][-]

1. debugln(['1:',dbgs(MyPoint), ' 2:', dbgs(MyRect)])

Lastly - and please don't fume (sorry) - but choose and promote a single formatter and style; and reformat all the packaged pascal with it.  Age has told me that it is better to conform to a single "standard" rather than to fight the environment. 

Has its pro and cons => I don't think it currently is likely to happen.

[Martin_fr]

IDE/Debugger:
3. The single biggest issue in adoption of Lazarus is the debugger.  I do respect that Pascal is low level, but with debugging the simplest of things gets very time consuming.  Take e.g. a List of objects; in order to get to the detail you have to go look at memory as the list reflects pointers, while, even with full debugging, I get messsages like "Error: unknown data".  I can name numerous other such cases.

Also you might want to actually name those cases. Some could be bugs in the debugger, others could have simpler workarounds than whatever you currently do.

One other issue, that I know of is if you have several classes of the same name. Yes the language allows that, if each is in a unit of its own. But debug info does not currently support that for all cases. It is fine, if you have a variable declared with the type of such a class.
It fails, if you have a var declared as some base class, and then use a typecast to get the instance class. And it differs from OS to OS... 

So, ideally avoid having to classes of identical name. (It also makes code harder to read, unless your entire code reads like "unitname.typename" / at least IMHO)

In Lazarus 4

In cases were you need complex expressions to get data (be that due to missing debug features, or other)

Use the "debug inspector" to build watch expressions for data in structures. => The debug inspector has
- a search for fieldname
- browse forward/backward
So you can quickly go to a field and then modify the expression. And you don't have to keep opening a watch properties dlg.

For viewing lists, look at the ".." intrinsic of FpDebug
https://wiki.freepascal.org/FpDebug-Watches-Intrinsic-Functions#Array_slice_MyArray[n..m]_with_mapping

Code: Text  [Select][+][-]

1. MyArray[1..9].FieldInArrayEntry
2. ^TObject(SomePointer)[0..9]

[Martin_fr]

And - I should have started with - make sure your debugger is set to FpDebug
Tools > Options > Debugger > Backend

On Mac, that is "LLDB, with FpDebug" (or similar)

[Gawie]

A big thank you for all the good feedback.  I have taken the time to read every post but will take time and have a play with the various options; really some very good options to investigate.  Also thanks for confirming various of my observations, in that it is in process or not supported, or supported by workaround.

And yes, I understand that the Pascal legacy is something different by its design and structure, but with a myriad of good about Lazarus, I find the project management side of it lacking (e.g. navigation, organisation and something as simple as renaming (save as) or deleting a file, file wide move, refactor etc; targetting different "artifacts" with these facilities so obvious in other IDEs that one does not even think of it anymore (and some of it is really low hanging fruit).  Again, I say this with the intent of telling you what I miss in order to make it more complete or easier/nicer to work with; if there is anybody that care. 

In an environment where there is many languages to choose from, I would rather be polite to those interested as maybe they can contribute some day in some way or other, rather than to chase them away.  To those who did not like the question... or the inherent criticism that the tool is still lacking (and vindicated by the answers), you are the reason why I didn't want to ask in the first place.  As a hero member your reply convinces me to not participate to these threads; while your silence would have given me the courage to try and help somebody else.

[Warfley]

IDE:
1. The project system, it is single target only.  In order to do unit testing or other, I have to switch to other instances.  This is tough in many ways and make refactoring exponentially more difficult than it should be.  I do understand that there are limitations imposed by the underlying tools, but in order to do anything noteworthy/big I cannot see myself using Lazarus without it driving me up the wall (for this shortcoming).
2. The project system, by its organisation is also surprisingly hard to manage.  It somewhat penalises you for putting a class per file, and makes putting files into directories like "namespaces" more work than it should be

It depends a bit on what you expect. If you want a big full environment, yes it's not an eclipse or visual studio. But the trend is usually into the opposite direction. Having light editors and using additional tooling for the other features. The most popular ide today is vscode which is just a code editor and for all the extra stuff, like unit tests you pop up a terminal or configure custom build commands and bash scripts.

Also the one class per file while being considered a best practice in the 90s and 00s has generally been reconsidered with smaller classes and grouping multiple small classes in the same file where a file becomes some kind of namespace.

So I agree that if your workflow requires these things, Lazarus is lacking. That said I personally disagree on the need of that. I already think that Lazarus is to fat, with the package and project system being strictly tied to the ide rather than a set of standalone tools.
I much rather work with a dumb editor, an lsp and a set of command line tools than one ide that tries to solve all problems at once.

IDE/Debugger:
3. The single biggest issue in adoption of Lazarus is the debugger.  I do respect that Pascal is low level, but with debugging the simplest of things gets very time consuming.  Take e.g. a List of objects; in order to get to the detail you have to go look at memory as the list reflects pointers, while, even with full debugging, I get messsages like "Error: unknown data".  I can name numerous other such cases.
4. The IDE  penalises you for using properties, as the backing property variable and property gets displayed twice when debugging.  This is very distracting and makes working with watches etc double the effort in navigating.  On smaller classes I even avoid the use of properties in favor of smaller watches (which paints the picture...  for coding for a better IDE experence is counterproductive)
5. Even common infrastructure to support the dumping of values here may help.   

I agree that the debugger requires still a lot of work and is probably the worst part of Lazarus (and I say that as someone whose C++ workflow involves using the command line gdb interface). There has been tremendous improvements with Lazarus 3, like support for arrays, tree view structure, etc. But there are still a lot of issues.
Funnily enough I would not consider the ones you mentioned to be the biggest problems. My problem is more the lack of support for inheritance, meaning I always have to cast around objects manually, the fact that it Halts on any exception even those that are cought by your own code (and  especially when doing multi threaded io, halting for an exception can make debugging of time sensitive issues impossible) and the fact that it does not at all work with inlining makes it very tedious.

Lastly - and please don't fume (sorry) - but choose and promote a single formatter and style; and reformat all the packaged pascal with it.  Age has told me that it is better to conform to a single "standard" rather than to fight the environment.  In other words, when delving into the supporting libraries I see many many different casing, naming conventions etc - and the brain doesn't like it for as much as it is trained to short evaluate colors, inconsistent casing and naming can be very distracting.  When I was young I used to flame about style, now I flame about consistency and will gladly take a slightly inferior style in favor of convention.

Regards

I mean there kind of is the Jedi code formatter (Ctrl+D in the ide) which is non configurable and always enforces a certain style... But to me code formatters are absolute hell. I don't want code formatted to strict rules, code should be formatted to esthetics, which can vary from case to case
For example do you do:

Code: Pascal  [Select][+][-]

1. MyVar := Expr1 + Expr2 +
2.   Expr3 + Expr4;

Or do you do

Code: Pascal  [Select][+][-]

1. MyVar := Expr1
2.        + Expr2
3.        + Expr3
4.        + Expr4;

Well it depends, the former is more compact while the latter emphasizes the steps of the operations.
If I do something very complex I rather do the latter possibly with comments for each line, explaining why this part of the sum is important, while if it's simple I do the former.

There is no one style to rule them all

[Martin_fr]

It is always best to wait for more than one response, if the response isn't helpful, or otherwise off.

If you really get it wrong, one of the moderators (clearly marked as such) will contact you. Usually with a friendly explanation of what should be different.

Critic of the project is explicitly welcome. So your post is fine.

[Martin_fr]

. My problem is more the lack of support for inheritance, meaning I always have to cast around objects manually

You have seen that there is an option "Use instance class"?

It can be turned on for hints in the Tools > Options.
It can be set as default for watches in Tools > Optinos or turned on for each watch.

That has been around for a long time.

, the fact that it Halts on any exception even those that are cought by your own code (and  especially when doing multi threaded io, halting for an exception can make debugging of time sensitive issues impossible)

Exceptions can be disabled by class, in project options.
Though there is still a slight performance hit, as the debugger needs to check the class.

More fine tuned control would be nice... Knowing if it will be handled is not easy to predict, if at all. There is no info from the compiler. Even if there is an Except block, it may not handle all classes.

Most backends have some sort of internal option to completely disable reaction to exception (but that is all or nothing).
Tools > Options > Debugger Backend:
In the property grid "InternalExceptionBreakpoints"

If you need it for some projects, define a project specific backend in the project settings.

and the fact that it does not at all work with inlining makes it very tedious.

Indeed, ... and same feeling here.

But that needs to be fixed in the compiler. The compiler needs to write the info where inlined code is.

I know, its one big project (at least from the users viewpoint), so doesn't matter where the issue is.

[Gawie]

@Martin_fr

Thanks.  Off the cuff there are a few quirks with the Project Groups, but still way better than switching IDE windows.  I am very hesitant in installing anything that is not vanilla Lazarus, I have had issues with plugins in the past.  Same with LazLogger- but thanks, will give it a try tonight still

@Martin_fr
I agree - target is misleading - Artifact?

@Martin_fr
I understand from the thread that there are lots of shortcomings wrt namespaces.  I have seen a few that is not mentioned as well (e.g. it changes the case or cannot handle reserved words as part of the namespace).  Again, maybe I am trying to put a pattern to something that cannot handle it without an arm and a leg - not going to explain my understanding of namespaces but generally I thought that I did not have to worry about duplicate type names in different namespaces and could organise directories to (Javaism) to namespaces.  I like organising code into small classes and unless I want to hide something, I generally put it in a file of its own.  This workflow not only is the way my head works (due to a million other tools), but makes for a much easier git workflow too.

@Martin_fr
My debugger was set to FPDebug; and the debugging on classes are still too shallow.  I hear you, there are known issues and vast improvements on the way - I will refer back to this thread to see if I can improve the Watches and Locals, and what if any I can do to improve otherwise.

@silvercoder70
I will gladly poke the bear.  If the lazarus tool developers can stick to a style - then I am willing to follow it.  As I said, the bear is not in the style, it is in the consistency; and I will gladly take the consistency if advised by the tool developer if they can stick to it.

@marcov
Yes, using the unit testing plugins - but the issue was more in that it is handled as a different project.  The project groups as per @Martin_fr seems to work well.

@marcov
Understood on the development rate of the debugger - thanks for your comments.

@marcov
Quote: Anyway, the only thing I get from this is that the buildsystem (both of FPC compiler, as of the FPC/Lazarus codebases) and the project system on top of it are very misunderstood and under documented.
Marcov, I obviously did not make my point well here, I don't think it a a case of documentation or understanding, it is a case of what constitutes general IDE functionality or editor wrt file management and refactoring (with file management being the low hanging fruit).  And yes, I can do it in a terminal or "explorer", but that makes me leave the IDE which is a bad workflow; or having to open files to Save As to rename a file etc...
Maybe the question is rather - who decides on what is good for the IDE to promote its use...   and those who do not want these facilities in Lazarus, or think that it should be done with a plugin, how does their workflow look and why is it so different from other editors/IDEs.  Am I the only person that want to delete a file or rename a file in Lazarus (regulary?  Not even talking about refactoring in this process - for that would be gold.  Simple low having fruit that would vastly improve this is a copy file path to clipboard (or open explorer here)...  Simple stuff that would make the experience that much better.


PS: I see the Project Group has a copy Filename!

[Martin_fr]

On debugging timing sensitive stuff.

Have you seen the Debug History?

You can set a breakpoint and minimize the time that the app gets paused (e.g. in a gtk menu or click handle, where a breakpoint can freeze some of the desktops).
- set the breakpoint
- in properties: un-check the action "Break"
-                 check  "Take snapshot"

the app will just stop for a moment at the breakpoint and then keep running.

A snapshot is taken
- threads
- stack (top 5 frames or more if stack window is open and set to more)
- locals (currently only for the top most stack entry)
- watches (currently only for the top most stack entry)

You can then later inspect the data via the debug history window.

[Gawie]

Not so clueless after all heh?