Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[plaza1518]

I refuse to accept the mediocrity of others as a valid reason to accept it widely and as something "normal".

A normal and steady amount of dedication is all it takes to produce bug-free software.  Corollary: if the software had been appropriately tested, it's quite likely it wouldn't be as buggy.

Please allow me to ask: After everything you have written here, why do you still use and engage with FPC if it does not seem to meet your requirements?

[marcov]

And also, very little (and even that, only vague) had been communicated.

The "most definite" statement was "problem with Mac / arm". => But that could be anything
- From: A big fix in the depth of the compiler itself (affecting all from parser, to code gen and between)
- To: find the 3.3.1 commits and get them merged

As I said, nothing was communicated, I also have to guess based on Pascaldragon's statements.

[LeP]

I refuse to accept the mediocrity of others as a valid reason to accept it widely and as something "normal".

It's not mediocrity, it's about profusion of resources and how the decisions were done.

A normal and steady amount of dedication is all it takes to produce bug-free software.  Corollary: if the software had been appropriately tested, it's quite likely it wouldn't be as buggy.

We're talking about a project based on volunteering, where people change over time (skills change, interests change, and relationships between volunteers change too).
No one can expect people to be OBLIGED to do or not to do something.

[Martin_fr]

Well, then reflect it on me too...

My contributions to Lazarus aren't bug free either. And for a variety of reasons (technical and personal and biological (e.g., the need to sleep)) some of them have (and will further) persisted for a long time. Longer than they should in a perfect world.

Here are a couple of questions:

1. did you release the software knowing the bugs were there and not declaring their presence ?
2. did you willingly fail to correct bugs you were responsible for after they were reported in spite of the fact that you could have reasonably done so ?

If you answer "yes" to either one of those questions then I state that such behavior reflects very poorly on you.

Take the IDE:

1) Well, the presence is usually declared by them being in the bug tracker.
I can't recall, but its possible that there also have been bugs which I discovered, and hadn't yet reported. It's possible, and then they would not have been declared.

2) "willingly" is tricky to define. "reasonable" too.
Was it
- I had better to do
or was it
- There were other issues (including missing features) that where (IMHO) more important

Or maybe, when (if at some time) I didn't have better to do, they happened to be out of sight.

Though, I would say it wasn't "willingly". I felt forced by not wanting to withhold all other improvements, and by not having the resources/abilities to fix them.
Not sure if that fits your definition of "willingly".



I answered this on the IDE, because I made the original statement as something comparable to your statement toward the FPC team about their doings. So this is the best comparable target.

[440bx]

Please allow me to ask: After everything you have written here, why do you still use and engage with FPC if it does not seem to meet your requirements?

Because the alternative is using C or C++ and, while I've used C in the past, I very strongly dislike the language.

IOW, even though C has a better feature set and is more powerful than FPC, I'd rather deal with FPC's deficiencies than C's shortcomings (not to mention its sad compilation speed.)  To be precise, I use C++ as a C compiler because I get C++ stronger type checking by doing that but, I never use C++ standard libraries or classes (totally out of the question to use that junk.)

I refuse to accept the mediocrity of others as a valid reason to accept it widely and as something "normal".

It's not mediocrity, it's about profusion of resources and how the decisions were done.

I don't see how that justifies all the bugs currently in FPC.  FPC wasn't written yesterday, there has been plenty of time to dedicate to them but, it's probably more "fun" to add new features than to fix bugs.

A normal and steady amount of dedication is all it takes to produce bug-free software.  Corollary: if the software had been appropriately tested, it's quite likely it wouldn't be as buggy.

We're talking about a project based on volunteering, where people change over time (skills change, interests change, and relationships between volunteers change too).
No one can expect people to be OBLIGED to do or not to do something.

Is it really too much to expect a programmer to correct bugs in their code ?   When did it become too much to expect that ?  I must have missed that memo.


Lastly, I believe that it is simpler, easier and requires less manpower to produce a bug-fix only release than one that includes new features.  If that is correct then it shouldn't take 5+ years to get a new release.

One of the benefits of steady releases that do not require a large amount of work is that the project would, at least give the appearance, of being alive and moving forward.


@Martin,

What I've seen from you is that, when someone reports a bug, you take an active interest in fixing it and, so far what I've seen is that the bug is usually dealt with/solved in a reasonable amount of time.

I understand that some bugs may take longer to fix than others but, there are two things I fully expect, the first one is for a known unfixed bug to be acknowledged and described.  This to spare me and/or other people to chase a known bug that is "incognito" in the current release.  The second one is for the bug to be corrected in a timely manner.  "Timely manner" means a true, genuine effort is dedicated to correcting it (and testing the fix.)

Not only do I believe the above are fully reasonable expectations, I also believe that anyone who calls themselves a programmer would do that much.

[Bart]

Is it really too much to expect a programmer to correct bugs in their code ?   When did it become too much to expect that ?  I must have missed that memo.

OK, so I've introduced some new functionality in the past.
(This is Lazarus though).
After a while there seems to be a problem with it, but only in a certain WS.
I don't know how to fix that.

Should I now remove everything I added, because there's a bug in the functionality I added, and I'm the one who should fix it, but I cannot?

If this were to be true, then e.g the whole TMaskEdit should be brought back to the state it was in when I joined: the code compiled, but is was not functional.
Of course this is an argument "ad absurdum", but nevertheless.

There are just not enough people in our (fpc/Lazarus) team.
We are not funded.

And yes, I really would like to see an fpc 3.2.4 release rather today than tomorrow, but I'm not just going to complain, I ask if I can be of any help at all.

Bart

[plaza1518]

My impression so far is that the community around FPC is a closed society. Not because the individuals involved did not want any further supporters, but because the “unstructured” nature of the development makes it impossible to do otherwise.

Anyone can participate if they are able to. But how and in what direction?

Concrete goals must be defined that can be achieved as a group. There is no “leader” in the structure of the community who can or wants to take on the coordination. It is and remains a volunteer project in principle.

However, if there is a concrete direction, then the group can pursue this goal as a community without the responsibility weighing too heavily on the shoulders of individuals.

But to do this, the “core community” would have to come together and consider what it wants and can achieve as a community.

Otherwise, it will remain the case that individuals contribute their ideas to the project and participate only temporarily, regardless of the consequences (including errors).

[Martin_fr]

I do give everyone in the FPC team the same benefit, I do believe that if they know they caused a bug, they will go after it.

The problem with many bugs is that its not that clear who caused it. It may be code that many worked on, and by the time its reported...

Or the description of the bug, does not immediately allow to point to a specific bit of code.

Just got a report on the IDE "completion dropdown on wayland is misplaced" - SynEdit? My Code? Afraid not. Also, this wasn't actually caused by anyone, because wayland didn't exist when the code was created. So this is technically not a bug. Its a missing feature. It only needs to be done when implement that feature... But that isn't good enough? People will not be able to avoid wayland ...

---------
And sometimes by the time a bug comes in, the code I wrote to cause it, may be entangled with lots of other newer code. That may seriously impact how it can be fixed...
And sometimes it gets delayed. And also everyone can forget once in a while.

And, for other bugs, different people judge the impact at different rates.
There is an issue that cpu registers in the debugger don't sort correctly. And for someone that may be a disaster. Yet I haven't attended it yet, currently classifying it as a mere convenience issue (important but not that much).
But having it there, it weighs less compared to other issues. (And also, it may become easier to address if I ever get to do the underlaying refactor for some related code).

Looking at the issues in FPC, some are drastic in my judgment, and I don't understand the reasoning behind there delay. But, I have to assume that I have issues on my hand, for which someone doesn't understand why I bloody haven't done them yet.

[440bx]

I don't know how to fix that.

I have no problem with that. 

The only thing I expect in that case is for the bug to be "documented" so people know it is there.  This prevents two other problems, the first, having additional programmers waste time in a bug that is known to be there, the second, having the bug stay there because the persons who might know how to fix it don't even know the bug exists.

The point is: when software is released its list of known bugs should be 1. documented,  2. that list be very visible,  3. there should be a constant effort to fix the bugs and, 4. the list of known bugs should get smaller with each release.   Of course, the list will grow again after the release as new bugs are found but, hopefully the majority of those will be fixed before the next release.

The above is what I've always thought is part of the normal software life cycle.    Eternal bugs are not part of the software life cycle I'm aware of. 

I also understand that some bugs are present not in the programmer's code but, in the code used by the programmer, e.g, Wayland (I get the impression that subsystem is "problematic"), in that case documenting the problem is just about all the programmer can do.

For instance, there is a bug in some versions of ntdll's RtlLargeIntegerToChar.  All I can do is document the existence of the bug and what its effect is.  That way someone who uses that function knows the problem is in the code that implements the function and not in its definition.

[Bart]

The only thing I expect in that case is for the bug to be "documented" so people know it is there.

Well, it should be in the bugtracker...

Bart

[440bx]

Actually and strangely, it is more likely to have very hard to understand and therefore fix bugs in something like Lazarus than in a compiler (FPC or other.)

That said, I doubt all the bugs in the bug tracker are bugs that no one knows how to fix.

[PascalDragon]

....
This is constantly being re evaluated, and as said, the problem is not that the project misses middle management. It misses workers.

Marcov, I have to disagree. Looking at the number of commits since the start of the year, says to me heaps of activity.

OK, its open source, people work on projects that suit themselves. And, clearly, in the past, the FPC devs must have made very many  altruistic contributions to make FPC the mature, stable product it is.  But is the problem now that most commits are dealing with something of particular interest to just its author ?  That is how open source works of course and its a good thing !  But with no one looking over the author's shoulder asking "have you tested that on XYZ platform" or "does that work in all modes" etc, some of those new features bring in bugs that probably don't affect the author but might hurt some other poor user who assumes the new feature is not just a point fix to solve a specific problem. Or might hurt some poor release manager ....

That's no different to how it had been in the past. The main problem is that we don't have a release manager with sufficient time.

I wonder    if there is anyone else here besides me who thinks the same way - that we should release FPC 3.2.4 right now, as is (well, maybe with a few minor tweaks), and forget about this old stuff

It not useful to release a version that's not really usable on one of the major platforms.

And make FPC [main] the next version 4.0/3.4.0, for example beta, and also release it right now, the beta
So that people can start adapting and adapting their code bases

Definitely not. main is not even remotely in a state for that.

FPC needs to move away from semantic versioning. It makes no sense to stick with it in this project, given its history. Semantic versioning is a hindrance in this case. Semantic versioning only makes sense if you plan to support old stable versions for several years, even though newer versions are already available.

Well, the previous release is supported for several years.

With regard to new features that have not yet been tested/verified on all possible platforms, there should be a “feature matrix.” There, “tested,” “not tested,” and “not available,” or “available since...” can be specified. This makes it clear to every FPC user what they are getting into.

Well, feel free to do that.

The “fetish” that the compiler must be “error-free” at the time of creating a stable version is completely “crazy.”

The idea is not that it is error free, but there should at least be no big and obvious show stoppers and that takes time to ensure.

I just tried to research how I can find information on getting started with programming the compiler. Unfortunately, I couldn't find any information on this. There is “only” extensive information on using FPC.

The only option is for me to analyze the FPC code myself and hopefully understand “everything.” That is, of course, one way to dive into the project.

Well, there is this, but just trying to pick some small issue and trying to fix it is indeed the best way to go. It's how I and many others got into compiler development. After all the compiler is easily debugged in Lazarus...

So there needs to be a statement. Does time exist for the mgmt of the release by anyone in the team who can collect any work done, and based on that bring forward a release? Yes or no?

I did some merging in fall 2024, as Florian seemed to gear up for a release with christmas/ny 2024/2025. The release branch was frozen, and I stopped merging. That is to my knowledge still the state.

So I myself have no idea, as I have seen no communication about the subject, but as you might know, I have had trouble with core messages the last half year, so I might have missed something. Maybe Pascaldragon knows the current status better.

That is also my latest information which is why I abstained from triggering merges myself.

And also, very little (and even that, only vague) had been communicated.

The "most definite" statement was "problem with Mac / arm". => But that could be anything
- From: A big fix in the depth of the compiler itself (affecting all from parser, to code gen and between)
- To: find the 3.3.1 commits and get them merged

As I said, nothing was communicated, I also have to guess based on Pascaldragon's statements.

It's this commit that needs to be merged for macOS. And I only know this because I stumbled upon it through some forum posts.

I refuse to accept the mediocrity of others as a valid reason to accept it widely and as something "normal".

It's not mediocrity, it's about profusion of resources and how the decisions were done.

I don't see how that justifies all the bugs currently in FPC.  FPC wasn't written yesterday, there has been plenty of time to dedicate to them but, it's probably more "fun" to add new features than to fix bugs.

The problem is that one area that was touched was the PPU loading which is very central to the compiler and it turned out that the rework for it done by MvC had not covered everything necessary while working on it. While it did improve quite some it led to catastrophies in other corner cases.

Another issue is one where I'm at fault myself and that is breaking the LLVM backend when introducing support for function references. I'm since then working on a solution, but it's a) not easy, b) I don't have always have the necessary time and c) I don't always have the motivation to work on it. Thus that is taking more time than it might have during my time at university.

[440bx]

The problem is that one area that was touched was the PPU loading which is very central to the compiler and it turned out that the rework for it done by MvC had not covered everything necessary while working on it. While it did improve quite some it led to catastrophies in other corner cases.

Another issue is one where I'm at fault myself and that is breaking the LLVM backend when introducing support for function references. I'm since then working on a solution, but it's a) not easy, b) I don't have always have the necessary time and c) I don't always have the motivation to work on it. Thus that is taking more time than it might have during my time at university.

Is it accurate to say those problems came about due to the addition of new features ?  (obviously function references are a new feature but, the reason for the PPU changes/modifications you left unspecified.)

[dbannon]

Thanks everyone, especially Marcov and PascalDragon who have greatly clarified the situation. Its not great but at least we now whats happening. Thats important.

The other, perhaps more pressing issue is Debian removing FPC/Lazarus from its next release candidate, Forky. I am going to start a new thread on that, under Linux, its not 'just' a GTK2 issue !

Davo 

[LV]

The main problem is that we don't have a release manager with sufficient time.

This is a straightforward and clear response to the topic.