Lazarus Observations

[Gawie]

@Martin_fr

No, I have not had a look at the debug history.  Thank you I will.  That history however seems more like a deep dive while my issue is at the moment when I hit the line, make the change and hit the line again.  But definitely will give it a try.

[Martin_fr]

@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.

Well it's not java. Directories aren't namespaces... Though IIRC in fpc trunk there are additional namespace features, but I haven't looked at them yet.

Without those new namespaces (in trunk, or IIRC in trunk?) you just have your unit names. All unit names must be unique across all directories. (Yes that is a limit / and afaik those new namespaces will bring relief for that / but fpc trunk is still a long time to next release...)

Keywords can be prefixed:  "&begin"  allows you to use "begin" as name/identifier/...

Classes (and types) can have non-unique names. There full name is "unitname.typename".
And as lang as you can figure out to which "TMyClass" your code is referring (if you have lots of different TMyClass) that is fine...

Almost...
If the debugger encounters "TMyClass" it will not know to which unit that refers. So the debugger may use the wrong one. Shortcoming in part of the debugger, in part of debuginfo and what the compiler provides.
The debug info does unfortunately not provide the full scoping rules. And it does not include wich other units were in uses, so if the debugger doesn't find TMyClass in the current unit, then it doesn't know which one. (and a couple of other issues... too technical)

But also shortcoming in concept. Because you can pass an instance of UnitFoo.TMyClass to a function in the current unit. And that will work, even if UnitFoo is not in the uses class.

So, if you have such a TMyClass which has different declarations in various units, then you must (in the debugger) always manually write "UnitFoo.TMyClass(instance)".

The auto-cast "Use instance class" does not do that (not yet, on my list, but wont be in Lazarus 4)

So, yes re-using names is possible, but does have it's downsides in the debugger.
(And imho in code readability, because as a reader I may not know which TMyClass it is / but that is just my opinion)

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.

small classes and duplicate names aren't necessarily related...

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.

Well, as indicated

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

1. property Foo read GetFoo

Properties that have a method as getter don't work. Known problem. In the works, but will take major time, as a lot of parties need to do their homework.

Otherwise, please let me know what you think needs improving.

Btw, 4.0 RC1 should be there in a few days => so you might use that for testing.

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...

What exactly was your issue with "save as"?

I used that in the past, and usually the file is saved in the new place, the path added to the project, and the IDE offers to delete the old file.

Moving/Saving an entire project to a new folder may be a bit different.
Though, it can be done with "Publish project" (not the most intuitive)

Refactoring.
At least renaming exists in
menu: Source > Refactoring > Rename Identifier.

In most case at least. Know issue, iirc are inherited methods.

Maybe the question is rather - who decides on what is good for the IDE to promote its use... 

Probably mainly man power...

[Martin_fr]

@Martin_fr

No, I have not had a look at the debug history.  Thank you I will.  That history however seems more like a deep dive while my issue is at the moment when I hit the line, make the change and hit the line again.  But definitely will give it a try.

That was directed at Warfley.

But of course, give it a try. But well yes, I don't think it will help with your current problems.
It doesn't some any data you don't get to see before. Just preserves it.

Not sure what you mean by

when I hit the line, make the change and hit the line again.

Changes only come into affect, once you stopped the exe, recompiled and started again (there is no run-time patching)

[marcov]

Dotted unitnames are not like Java namespaces. They don't map to directory history, and you can't import them with wildcards.  (so no import java.x.y.* like functionality)

Basically they are just unit names with dots in them but in certain circumstances you can omit (some of ) the initial part. This makes it handy to disambiguate units with fairly common names. 

[PascalDragon]

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

The Object Pascal language as a whole is simply not geared towards the "a single class per file"-approach. It is normal for a unit to contain multiple classes. So either adapt or continue to struggle.

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.

No. That is unnecessary noise in the version history that distracts from the important changes.

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.

For renaming a unit simply store the unit under a new name from within the IDE and the IDE will rename all references inside the project.

[jamie]

Gawie reminds of one that may have recently paid their subscription on software that can only get fixed in that fashion.

 Then comes more bugs, kind of keeps the revenue engine cranking.

 
  Be smart and learn to give to help pave the way instead of making the roads rough for yourself and everyone else.

[Gawie]

Gawie reminds of one that may have recently paid their subscription on software that can only get fixed in that fashion.

 Then comes more bugs, kind of keeps the revenue engine cranking.

 
  Be smart and learn to give to help pave the way instead of making the roads rough for yourself and everyone else.

Hi Jamie -

What is the end game - are you trying to build a product that can compete and maybe get Pascal back in 'mainstream' again, or is it for fun and amusement; and a place to have a chat.  I have no illusion that as a collaborative effort that it is not a product per se - but at the same time is it doing so many more difficult things well that why not rid yourself of the legacy (of how it used to be) and make it better/on par with the the subscription based IDEs... 


As a product, I have no issue contributing financially if there is something that I can make/sell with it.  As a tool and language I cannot with confidence and safety do with it what I cannot do just as well or better with other languages, free, with good support and all the bells and whistles.  So again - how do you make the tool more enticing - or is that not the idea.  Is it for hobbyists only?

Can I poke the bear? :-)  What still draws me to Lazarus is its ability to do a GUI (mostly cross platform), that is of reasonable quality at reasonable effort...  while running 6MB of memory and not 150MB (in order to carry with it the whole-kitchen-and-the-sink).  If you compare to Flutter, Rust (various GUIS),  GoLang (various GUIs), C++, C#, Java FX, Swing, SWT (And yes, I have done GUIs in them all) ...   The Pascal language is tedious (on par with C++) with lots of gotchas; and a sad sad history to boot; which even sadder made me lose a lot of personal knowledge and investment on it.  For most other things, there are tools that can do it quicker, safer, better organised and smaller (in code at least)

In short - where is it going, and what do you need to get it there; for as a potential user - I am clueless.  I am willing to support it in more ways than one, if I have an idea that it is "going" in the direction where I can see me doing something for production with it with reasonable safety in "support" ;-)

I pick Lazarus up once a year, and review again, but is not getting that warm fuzzy that I need - especially not in the simplest of things like the project management, source control etc.  And yes, maybe I am barking up the wrong tree. 

[Gawie]

@Martin_fr

No, I have not had a look at the debug history.  Thank you I will.  That history however seems more like a deep dive while my issue is at the moment when I hit the line, make the change and hit the line again.  But definitely will give it a try.

That was directed at Warfley.

But of course, give it a try. But well yes, I don't think it will help with your current problems.
It doesn't some any data you don't get to see before. Just preserves it.

Not sure what you mean by

when I hit the line, make the change and hit the line again.

Changes only come into affect, once you stopped the exe, recompiled and started again (there is no run-time patching)

No, it is not a case of automatic reloading, simply a case of rerunning the app with different parameters to see the effect on the code.  Keeping in mind - the issue is in the difficulty in "reflecting" down the hierarchy in seeing what the values are. 

[marcov]

What is the end game - are you trying to build a product that can compete and maybe get Pascal back in 'mainstream' again, or is it for fun and amusement; and a place to have a chat.  I have no illusion that as a collaborative effort that it is not a product per se - but at the same time is it doing so many more difficult things well that why not rid yourself of the legacy (of how it used to be) and make it better/on par with the the subscription based IDEs... 

Purely collaborative things take longer to gestate. If you change at every fashion, it will usually be out of fashion before it is completed.   Startups can spend venture capitalist money chasing marketshare in a hurry, we can't.

In 2000 there were many Java IDEs, now only a few big ones remain. Same for the enormous .NET boom that consolidated, with Microsoft now even owning Xamarin.

The room for third party projects outside of mainstream is very narrow, long time.

Everybody and his uncle is creating an own typed compile-to-javascript (or webassembly) variant nowadays, we too. A shake out will happen here too.

As a product, I have no issue contributing financially if there is something that I can make/sell with it.  As a tool and language I cannot with confidence and safety do with it what I cannot do just as well or better with other languages, free, with good support and all the bells and whistles.  So again - how do you make the tool more enticing - or is that not the idea.  Is it for hobbyists only?

FPC and Lazarus have been used commercially for multiple decades. It might not appeal to what mainstream IT managers read in heavily sponsored rags and sites, but that is a different, narrower, kind of commercial.

Can I poke the bear? :-)  What still draws me to Lazarus is its ability to do a GUI (mostly cross platform), that is of reasonable quality at reasonable effort...  while running 6MB of memory and not 150MB (in order to carry with it the whole-kitchen-and-the-sink). 

Add to that being quite consistent in time (keeping old investments), and on Windows it is easy to move an installation (with components installed) from system to systems.

If you compare to Flutter, Rust (various GUIS),  GoLang (various GUIs), C++, C#, Java FX, Swing, SWT (And yes, I have done GUIs in them all) ...   The Pascal language is tedious (on par with C++) with lots of gotchas; and a sad sad history to boot; which even sadder made me lose a lot of personal knowledge and investment on it.  For most other things, there are tools that can do it quicker, safer, better organised and smaller (in code at least)

There is a lot of taste in that, and it also depends on how much you want to do under that GUI. Personally I always considered Java or C# string handling tedious compared to Pascal.

In short - where is it going, and what do you need to get it there; for as a potential user - I am clueless.  I am willing to support it in more ways than one, if I have an idea that it is "going" in the direction where I can see me doing something for production with it with reasonable safety in "support" ;-)

Mostly we are going the same direction we have been going for years. Except maybe for some adventures with jvm and javascript backends that still have to prove themselves.

I pick Lazarus up once a year, and review again, but is not getting that warm fuzzy that I need - especially not in the simplest of things like the project management, source control etc.  And yes, maybe I am barking up the wrong tree.

Looking it from a mainstream view is not healthy. The goals and means are simply not the same, nor aligned.

Look at what you can do. Even in my Java and C#/ASP.NET years I still used FPC for a lot of standalone programming (business work too) as a kind of swiss knife tool that didn't mutate too fast.

[Martin_fr]

No, it is not a case of automatic reloading, simply a case of rerunning the app with different parameters to see the effect on the code.  Keeping in mind - the issue is in the difficulty in "reflecting" down the hierarchy in seeing what the values are.

Then maybe I need an example of
- what you see / what currently happens / is shown
- what you expect / want to see

Because maybe it's just a way I never thought of doing it that way.

I have seen that in the past, when people come up and ask "I've been waiting for years, when is <whatever> going to be added/implemented?" => And I had never even known it could be done "<whatever>", leave alone thinking of it as useful (for how can I think of something as useful, if I neither know it exists, nor have any other idea of it).

I can tell you, I do debug a lot. And I look at some really complex data. But, I have the advantage, that I know the tool (the debugger) in and out. And that it perfectly fits the way that I think about a problem.
Don't get me wrong, that isn't because I just care how I want to use the debugger. If and when I get feedback, I pick things that others say they find useful.... If and when...

Hence, as I said. I need feedback that allows me to have a concrete idea what you are looking for. Then I can comment on it, and decide if/when to do it, or how it already exists, or ....

You can post screenshots, what you get in Lazarus, and what you get in an other IDE (even with another language).

[VisualLab]

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).

Handling multiple projects at the same time adds significant complexity to the IDE architecture. But it would be nice to have such a solution. Managing multiple projects simultaneously would be convenient not only because of unit tests (actually, this is too weak an argument). For example, I would like to apply this to cases like:

• a project consisting of multiple executables (e.g. EXE + several DLLs),
• a library project consisting of several packages,
• a project combining both of the above, i.e. EXE + several DLL + packages.

However, there is one issue - what solution to use. Because it could be like in:

• NetBeans - list of projects, where each of them has its own independent node,
• Delphi - project group, where projects are somehow related to each other.
  

I have shown what I mean in the attachments. I use both of these environments (except Lazarus). And both of these solutions have their advantages and disadvantages. The project group seems to have more possibilities (options).

However, it seems to me that life without managing multiple projects in Lazarus at the same time is not that burdensome. It is bearable.

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

Here I agree with the previous statements that:

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.

Having to put each class in a separate file is a pain. I can't imagine such a way of working. The current solution allows both placing classes in separate source files and placing several classes in one source file. I conclude from your statement that you would like the IDE to force the programmer to follow the rule: "one class - one file". But in this case it is a very bad idea. Namespaces are resolved in different languages ​​in different ways. The one used in Java has some advantages but also has its drawbacks. I don't think that "kneading" Object Pascal into the shape of Java is desirable for most of its users.

[Martin_fr]

• a project consisting of multiple executables (e.g. EXE + several DLLs),
• a library project consisting of several packages,
• a project combining both of the above, i.e. EXE + several DLL + packages.

However, there is one issue - what solution to use. Because it could be like in:

• NetBeans - list of projects, where each of them has its own independent node,
• Delphi - project group, where projects are somehow related to each other.
  

Well, we do have project groups. I haven't looked at how they are done I Delphi.

The main issue I see is that many of the goodies we have aren't pre installed.

Then again, there is the other group of people who want a leaner, less pre-installed IDE. Despite the Lazarus IDE start up time is IMHO pretty good, even if you install a few extras. And I don't thing disk space still matters? Download... Maybe, depends where  you live. Memory usage, in some cases => but that isn't the size of the code, much more memory is used by data, and for many of those extras data usage probably only starts when you use them.


Btw, for projects with libraries etc => you have in project settings "execute before compile" => you could call the compiler (or lazbuild) for your library (or a script for several).

[TRon]

Well, we do have project groups.

I was just about to write that down, see wiki for VisualLab

Then again, there is the other group of people who want a leaner, less pre-installed IDE.

That is imho something you never can do right. I like lean and can add the features I want later. Other (seasoned) users might prefer to have everything they use pre-installed (but that varies per user).

Imagine being a noob, starting Lazarus for the very first time.... I already get lost in the features that accompany a new release.

[Martin_fr]

Actually, project groups are pre-installed (at least in 4.0)

[VisualLab]

The Pascal language is tedious (on par with C++) with lots of gotchas...

This is definitely a gross exaggeration. In the competition of "annoyance" of programming languages ​​in their everyday use, there is no point in comparing Object Pascal to C++. Moreover, at the top of the annoyance, apart from C++, you can (equally) put Java, Rust and also Python. They are a pain in the ass for many (sometimes different) reasons. Pascal (Object Pascal) of course also has various flaws, but not as much as C++. What's more, Object Pascal is much "nicer" in everyday use than C# (although I would put C# slightly lower than C++ in the hierarchy of annoyances).