Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[plaza1518]

I already addressed this issue in a previous post.

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.

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.

[robert rozee]

[...] The truth is the gap between FPC322 and Main is just too great. It has been allowed to grow to an unmanageable degree and, apparently, is only going to get worse. That is the real problem.

Davo

we have python2 and python3 as two concurrent paths, why not FPC3 and FPC4?

1. those developers who are willing can join the FPC3 path and put their efforts into bug fixes with a view to making FPC3 the most rock-solid bug-free compiler that is perfect adequate for use with the Lazarus IDE. at the same time the Lazarus IDE should (must) stick to being buildable with FPC3 - this is absolutely essential.

2. those developers who are more interested in adding new features can stick with what is currently referred to as 'FPC main', which represents the FPC4 path and should be officially renamed thus. there is no reason it should not be released today as FPC 4.0.0, albeit a project that has bugs.

then we just need to sit back and see where the cards fall. all this is just my opinion, of course!


cheers,
rob   :-)

[LV]

"Secretly", I'd like to see a Pascal compiler match C feature for feature before adding any other features to it. 

Openly admit that you possess the secret ability to read other people's minds. 😉

[paweld]

It should be remembered that components for FPC/Lazarus are released by other companies - both free and paid - and I think that releasing a version with bugs will cause some of these companies to stop supporting releases for FPC.
I also think that releasing trunk/main as a “stable” version will not cause Linux distribution maintainers to include it in their systems, because it will be clear that it is “stable” in name only.
If someone wants to use trunk/main or even a patch version, there is FPCUpDeluxe, which allows you to easily install any version of FPC and Lazarus on Windows/Linux/MacOS.
I have been using FPC 3.2-fixes for several years and I do not consider it stable - but I mostly use only Windows, with a few additional components (including paid ones).

The last problem I encountered on FPC 3.2-fixes was when switching from Lazarus x86 to x84-64: https://gitlab.com/freepascal.org/fpc/source/-/issues/41539

[robert rozee]

It should be remembered that components for FPC/Lazarus are released by other companies - both free and paid - and I think that releasing a version with bugs will cause some of these companies to stop supporting releases for FPC. I also think that releasing trunk/main as a “stable” version will not cause Linux distribution maintainers to include it in their systems, because it will be clear that it is “stable” in name only [...]

ALL software has bugs - if you insist on only ever release totally bug-free packages then you will never be able to make a release. the important thing is that the software is 'good enough'; it does the job, provides the user with utility, and any problems can be worked around where necessary.

[...] If someone wants to use trunk/main or even a patch version, there is FPCUpDeluxe [...]

while i am sure that FPCUpDeluxe does a great job for some people, it is far too complicated for many non-programmer users. i looked at it once and gave up! if there was a version that has just ONE button (and just that ONE button) labelled "install Lazarus x.y.z in userspace" then it would be a great way to get Lazarus/FPC onto linux machines, and could likely even be included in Debian and many other linux distros. this would likely require any such 'cut down' FPCUpDeluxe to ship with a bootstrap FPC compiler that is (as it is now) agnostic to the widgetset/etc, and to build the Lazarus IDE and all the libraries locally to match the widgetset available on the local machine.

hmmm, i may start another thread to discuss this - how to make Lazarus more palatable to the Debian developers.

[...] I have been using FPC 3.2-fixes for several years and I do not consider it stable [...]

do you consider the FPC 3.2.2 available from sourceforge (link below) to be stable?

https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20amd64%20DEB/Lazarus%204.4/


cheers,
rob   :-)

[Martin_fr]

I have been using FPC 3.2-fixes for several years and I do not consider it stable - but I mostly use only Windows, with a few additional components (including paid ones).

The last problem I encountered on FPC 3.2-fixes was when switching from Lazarus x86 to x84-64: https://gitlab.com/freepascal.org/fpc/source/-/issues/41539

And are those issues regressions from 3.2.2?

Or does 3.2.2 also have the/those issue(s)?
Or does 3.2.2 not have the feature(s) at all, and therefore can't have the/those issue(s)?


I would very much like at least the code generation issues be resolved for 3.2.4. But, current 3.2.3 already is better at that than 3.2.2 (at least within the limits of my knowledge). So I take it any day just the way it is today.

And yes, given the amount of time that has passed, most of us will have their list of woes (can't do this or that). But, its not realistic to expect them all to still make it into 3.2.4 (even if they are fixed in trunk).

Errors that simple abort compilation with an error, are annoying, and to the right person can be a blocker. But they are nothing compared to code generator issues. The latter can hit anyone anytime, and the victim want even know it isn't there fault. That is a completely different game. Especially when they cause - in the users view - random errors.  (That is such issues as the inline problems / wrong register allocations / etc)


Just to say, I don't say that because I would need them fixed. I am capable to work around them. But there will (or will have been) people who may have abandoned there project because they couldn't figure out were they have gone wrong (when actually they hadn't gone wrong).


Btw, anyone noted what is missing in this thread?

It's not offerings of help (though we don't know how far they would go). What about commitment to accept such? And I don't recall seeing any mention of a concrete task that need to be done (i.e. what work could be accepted as help / not just a general: that must still be made to work, but no details on if/what is planed).

[plaza1518]

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

Please take a look at the current status of the Go compiler, which can certainly be compared to FPC in terms of platform independence: https://github.com/golang/go/issues

Standards are being set for FPC that could almost be described as “sabotage of the project.”

A pragmatic approach must be taken. Anything else is only theoretically possible and hardly feasible in practice.

[paweld]

ALL software has bugs - if you insist on only ever release totally bug-free packages then you will never be able to make a release. the important thing is that the software is 'good enough'; it does the job, provides the user with utility, and any problems can be worked around where necessary.

Let's not go to extremes - of course every software has bugs (that's why patch versions are released), but there is a difference between releasing a version that has been tested and seems to be stable, and a version that is still in development, where things are constantly changing and most of them have not been tested by anyone other than the developer who adds them.

while i am sure that FPCUpDeluxe does a great job for some people, it is far too complicated for many non-programmer users.

Yes, FPCUpDeluxe has many different options, but for a basic installation of FPC and Lazarus, you only need to perform four steps (see screenshot):
- select the installation path
- select the FPC version
- select the Lazarus version
- click “Install FPC and Lazarus”
That's all. Of course, under Linux, you need to install dependencies, such as git, without which it will not install - more information here: https://github.com/LongDirtyAnimAlf/fpcupdeluxe?tab=readme-ov-file#linux
As for MacOS, I can't comment because I don't use it.

do you consider the FPC 3.2.2 available from sourceforge (link below) to be stable?

Sorry, my mistake. I meant to say that I consider this version stable (I corrected this in my previous post). FPC 3.2.2 too, but I use 3.2-fixes because of the fixes I need (I don't remember them all, but for example, support for additional types in the db unit has been added, as well as fixes in pdf support).

[plaza1518]

Btw, anyone noted what is missing in this thread?

It's not offerings of help (though we don't know how far they would go). What about commitment to accept such? And I don't recall seeing any mention of a concrete task that need to be done (i.e. what work could be accepted as help / not just a general: that must still be made to work, but no details on if/what is planed).

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.

However, this is only of limited help in attracting further supporters, because hardly anyone can acquire the know-how that the current FPC programmers have built up over many years in a “short time.”

If the desire is for more FPC users to help with debugging/further development in FPC, then there needs to be a slightly easier way to get started. Otherwise, it will remain a closed society.

[440bx]

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

No, what's crazy is that somehow buggy software has somehow become acceptable.

In addition to that, a compiler is a very special kind of program.  When done _correctly_ the compiler is defined by a set of productions.  From those productions, not only the scanner and parser are determined and coded but also the set of test cases the compiler MUST pass.

It is completely realistic to demand that a compiler be bug free.  I've used some compilers for over 7 years and in that time found only 1 bug in it (related to code generation), of course, this wasn't a PC hosted compiler, it ran on big iron where the presence of bugs can easily cost tens of thousands (if not more) dollars.

I suggest you read "Per Brinch Hansen On Pascal Compilers" then read the code of Per Brinch Hansen's SuperPascal.  Granted that Per Brinch Hansen's Pascal- is a long ways from FPC or a commercial Pascal compiler but, the _principles_ used to ensure the compiler is bug free apply equally to a full Pascal compiler as they do to Pascal_.  As Per Brinch Hansen says in the book, it's just "more of the same".  Of course, "more of the same", means the volume of work is greater but, it is most definitely doable if the determination (and knowledge) to do it exists.

Yes, even with great care, a piece of software can have bugs but, there is NO valid reason for bugs to survive, therefore the goal of bug-free software isn't a myth, the "myth" is just an excuse used by those who can not be bothered to put the work into making it that way.

[paweld]

Or does 3.2.2 also have the/those issue(s)?

Yes, this problem also exists in version 3.2.2. The attachment contains the minimum project needed to reproduce the error. The error occurs in Lazarus x86-64; I tested it on Windows.
The attached patch solves the problem - it is a patch from trunk/main adapted to 3.2-fixes.

No, what's crazy is that somehow buggy software has somehow become acceptable.

+1

[plaza1518]

No, what's crazy is that somehow buggy software has somehow become acceptable.

In my humble opinion, that is the difference between theory and practice. Of course, it is easy to get a small, defined area “error-free,” but it is quite another thing to develop a large project “error-free.”

It is almost impossible to program a “Hello World!” program completely error-free.

And it is simply impossible to prevent errors from occurring in a program or library. As a user of FPC, insisting that it must be “completely” error-free in order to use it is a little arrogant.

With this attitude, every programmer would have to program their own tools and functions entirely from scratch.

If I, as a programmer, use the tools of other programmers, I always have to check whether these tools are suitable anyway. This is in my own interest, in case my users encounter problems with my programs in which I have used these tools.

If, for example, I have used FPC (stable in your sense) in my program and an error occurs due to a hidden error in the compiler, I still cannot blame FPC.

With the requirement that FPC must be completely error-free when it is released, FPC would have to issue a “product recall” if a previously hidden error became known after release.

[BeniBela]

i suspect that many (most?) of those bugs "declared for Windows 7" will also still exist under Win10 and Win11. indeed, in theory it should be possible to target (for example) WinXP, on the assumption that any binary that runs on WinXP should also run on all later versions of windows.

It would be good to support old systems

I had a user who still used WinXP recently, until perhaps a year ago. And he would still be using WinXP, if his PC had not died. And the user  used my software because -- being compiled with FPC -- my software still runs on XP.

I used to write my software with Delphi 4 on Win98. Win98 was peak Windows.

i'd like to ask one main question: what features are now being added to FPC? more specifically: it seems like Version 3.2.2 of FPC (released on May 20, 2021 according to wikipedia) is fully functional - it seems to be the one that introduced support for macOS on AArch64 (M1 et al). and is nearly 5 years old.

3.2.2 does not work at all for recent Android.

That makes it more important to get a 3.2.4 asap


 

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

No, what's crazy is that somehow buggy software has somehow become acceptable.

In addition to that, a compiler is a very special kind of program.  When done _correctly_ the compiler is defined by a set of productions.  From those productions, not only the scanner and parser are determined and coded but also the set of test cases the compiler MUST pass.

It is completely realistic to demand that a compiler be bug free. 

People believe compilers to be bug-free. If you apply for some job and say in the interview, my software did not work because of compiler bugs they laugh you out of the interview

It is only FPC that so many bugs

[plaza1518]

It is only FPC that so many bugs

I beg to differ:

• Go: https://github.com/golang/go/issues?q=is%3Aissue+state%3Aopen+label%3Acompiler%2Fruntime
• Rust: https://github.com/rust-lang/rust/issues?q=is%3Aissue+state%3Aopen+label%3AC-bug

[BrunoK]

There are 2 different situations :

1 - Trunk code that uses new "features" like anonymous calls and other developpers favourites novelties and require a compiler that knows about these things. These cannot be considered as stable.

2 - Code not requiring new features and that have been stable for a long time with very few patches, here I think about things like \packages\fcl-db, that has not seen breaking changes and compiles with 3.2.2. These codes would be nice to have in a 3.2.X version BEFORE they get refactored with "improved features".
These should come in the stable distribution.

I remember the times where we had, in svn, a distibution compiler that got some corrections patches as they appeared to be safe and useful. That worked quite well at the time.