At the Lazarus Congress in Cologne in October 2024, it ended up being very interesting. An important question came up.

Why are no new users coming to Lazarus/Freepascal? Why do we find it so difficult?
How can we get new, younger users to come to us?

The same questions came up over a year ago at a Freepascal/Lazarus meeting in Backnang.

I have some answers:

- The official Freepascal website doesn't look like the project is very lively.

- Lazarus looks very complicated with its many windows. And it is also relatively complicated to understand and use. There are too many options that are too nested.

- Crosscompiling: The compiler file name is hidden in Tools - Settings instead of in the project settings. I found this out after some time. Since it was nowhere to be found in the project settings I first thought it might be hard- coded!

- Linux: All relevant files (executable files, configuration files, source code, etc.) are scattered all over the Linux system. This is very complicated again. If Lazarus/Freepascal were a Linux system program it would make sense. But it is NOT a Linux system program. The chance that it will be used by several users on a multi-user system is close to zero.

- Fpcupdeluxe: A good idea. But it doesn't work. I have tried to install an AVR crosscompiler on a Linux system. Fatal: Can't find unit Infodrwf used by Project1. And ‘Project1’ does not use any For a new installation of Lazarus: The most important quick start icons have to be configured again at the bottom of the source code window. So that fast and smooth work is possible. Instead of placing them like this from the start. The many confusing windows I have already mentioned above.

As good as Freepascal is. The situation described above is a brake pad and sooner or later leads to a dead end.

My tip is to put all the required files in one directory. This also makes it easier to install an installation on the different systems. Only one ZIP file is then required. And you can even install it without internet access.

Translated with www.deepl.com

Auf dem Lazarus Kongress im Oktober 2024 in Köln war es am Ende sehr interessant. Eine wichtige Frage kam auf.

Warum kommen keine neuen Anwender zu Lazarus/Freepascal? Warum tun wir uns damit so schwer?
Wie können wir es schaffen, dass neue, jüngere Anwender zu uns kommen.

Die gleichen Fragen kamen auch schon vor über einem Jahr bei einem Freepascal/ Lazarus-Treffen in Backnang auf.

Ich habe einige Antworten:

- Die offizielle Freepascal Webseite sieht nicht so aus, als wäre das Projekt sehr lebendig.

- Lazarus sieht mit seinen vielen Fenstern sehr kompliziert aus. Und es ist auch relativ kompliziert zu verstehen und zu bedienen. Es gibt zu viele Optionen, die zu sehr verschachtelt sind.

- Crosscompiling: Der Compiler Dateiname ist in Werkzeuge - Einstellungen anstatt in den Projekteinstellungen versteckt. Das habe ich nach einiger Zeit herausgefunden. Da er nirgendwo in den Projekeinstellungen zu finden war, dachte ich zuerst er sei vielleicht fest einkompiliert!

- Linux: Alle relevanten Dateien (ausführbare Dateien, Konfigurationsdateien, Quellcodes, etc.) sind über das gesamte Linux-System verstreut. Das ist wieder sehr kompliziert. Wäre Lazarus/Freepascal ein Linux Systemprogramm würde es Sinn machen. Es ist aber KEIN Linux Systemprogramm. Die Chance, dass es von mehreren Benutzern auf einem Mehrbenutzersystem verwendet wird, geht gegen null.

- Fpcupdeluxe: Eine gute Idee. Aber es funktioniert nicht. Ich habe versucht auf ein Linux System einen AVR Crosscompiler zu installieren. Fatal: Can't find unit Infodrwf used by Project1. Und "Project1" benutzt überhaupt keine Unit.

- Bei einer Neuinstallation von Lazarus: Es müssen die wichtigsten Schnellstart Icons wieder sehr aufwändig unten im Quellcodefenster konfiguriert werden. Damit ein schnelles und reibungsloses Arbeiten möglich ist. Anstatt diese von Anfang an so zu platzieren. Die vielen verwirrenden Fenster habe ich oben schon erwähnt.

So gut Freepascal auch ist. Dier oben beschriebene Situation ist ein Bremsklotz und führt früher oder später in eine Sackgasse.

Mein Tipp ist es alle benötigten Dateien in einem Verzeichnis zu legen. Dadurch wird es auch einfacher eine Installation auf den verschiedenen Systemen zu installieren. Es wird dann nur noch eine ZIP-Datei benötigt. Und man kann es sogar ohne Internetzugang installieren.

---- On Tue, 15 Oct 2024 19:07:58 -0400 Rainer Stratmann via fpc-pascal wrote ---

At the Lazarus Congress in Cologne in October 2024, it ended up being very

interesting. An important question came up.

Why are no new users coming to Lazarus/Freepascal?

Why do we find it so difficult?

How can we get new, younger users to come to us?

The most fundamental reason more people are not adopting Pascal as a programming language is because in the mid-1990's Pascal lost out to Java as the initial language that was taught in university settings. Because that was the last place Pascal was widely used, it quickly became obscure. Also, C was always thought to be the pinnacle of achievement. That is, if you could program in C you were considered elite. That continues today, although those promoting Rust are making a commendable and stalwart effort to have it accepted into the Linux kernel.

Today, Python is probably the most widely used programming language. Its appeal is based on ease of learning and relaxed rules that increase ease of use. While it is as severely flawed language from a strict design viewpoint, it has taken over.

So, faced with this situation, what can be done? Short of a massive and expensive marketing effort, not much, except to remove obvious attributes that hinder adoption. One such attribute is the messy, cluttered look of the IDE. An IDE redesign with a cleaner, simpler, and visually appealing presentation would help enormously. It looks like that is what is being proposed here.

I have always found that the self-contained nature of Pascal/Delphi executables is a big advantage over other language systems. Just copy the file and run it, even on a system that has never seen a Pascal/Delphi executable before. If we could do that with the IDE/compiler it would be magic! The install process is far from that goal right now.

Doug C.

DougC wrote

So, faced with this situation, what can be done? Short of a massive and expensive marketing effort, not much...

Please notice that Telegram does not spend any money in marketing! Pavel Durov, the founder of Telegram says that clearly in this interview: https://www.youtube.com/watch?v=1Ut6RouSs0w&ab_channel=TuckerCarlson

In addition he says Telegram has a way better functionality than Whatsapp.

Telegram is one of the most popular messenger:
https://www.oberlo.com/statistics/most-popular-messaging-apps

Because it values the privacy it is under heavy pressure. Otherwise it would be may be higher in the ranking.

---- On Tue, 15 Oct 2024 21:34:01 -0400 Rainer Stratmann via fpc-pascal wrote ---

Please notice that Telegram does not spend any money in marketing!

Telegram is one of the most popular messenger:

https://www.oberlo.com/statistics/most-popular-messaging-apps

I don't think the situations are vary similar, so I don't think the comparison is useful. Messaging apps are relatively new and the market is in a state of flux. No one has much of an investment in their messaging app - they could change in an instant. But the programming language market requires substantial investment in learning. The technical debt of active systems is also huge. It is not nearly as easy to change programming languages as messaging apps!

User privacy is a huge draw for messaging apps. There is nothing comparable in programming languages except maybe simplicity. But Object Pascal has already succumbed to the lure of complexity that accompanies features like generics, attributes, redefined operators, and other decorative comments.

Doug C.

DougC wrote

I don't think the situations are vary similar, so I don't think the comparison is useful.

I mainly wanted to say that it is possible to do so without extensive marketing. Linux is another example. Linux does not spend a huge amount of money in marketing. It is widely used because it runs stable and for some other reasons.

FPC is not keeping up with trends in the industry which new programmings want despite all the older programmers who are settled in their ways. Even if there is a market for Lazarus type apps people in 2024 don’t want to use a massive legacy IDE and prefer better tools like VSCode.

If you want to use FPC these days what does a new user do? If they follow tutorials on YouTube they expect to have some VSCode package installed easily and start working that way. FPC of course has no official support for this and it’s hard to get my language server and it’s buggy due to CodeTools (a user created project with no official backing AFAIK).

As for the language I think for GUI apps programmers don’t need or want a manual memory managed language like Pascal and would prefer something like C#. In general the ease of programming is not there in Pascal compared to other languages and the community is extremely resistant to change.

I don’t think it’s hard to see Pascal are simply going to get old and die at this point. I even had an old time programmer contact me and say how much more productive he is with Swift when writing macOS apps now so quit using FPC. There’s lots of reason for this so FPC would need to be actively learning and making changes to keep pace.

Too many details to go into but there’s myriad problems that would need to be addressed.

---------- Forwarded message ---------

Some half baked ideas:
* month after month, the percentage of code coded by AI grows and human made shrinks.
* could Pascal be the ideal language coded (or preferred) by AI?

Given that Pascal is strongly typed, easy to read and debug, avoids many types of bugs, could we make AI to prefer pascal?

I wonder to which extent our current programming languages will end as a middle coding layer.

AI based transpilers from Python to Pascal are each day closer to reality.

- Linux: All relevant files (executable files, configuration files, source code,etc.) are scattered all over the Linux system. This is very complicated again.

This is important part. I agree. Some FPC binaries are in /usr/bin. Data files are here, src files are there.
Bad!
We need one folder of FPC in ~/fpc33 (version suffix is optional):

fpc33
-- bin (compiler, cross-compilers, tools)
-- src
-- rtl
-- packages
-- tests
etc

So I must be able to copy this folder to new Linux system, create symlinks to /usr/bin and it's good.
For Lazarus usage, I don't even need symlinks! Lazarus will take the fpc33 dir and it's good.

Next FPC versions will have dirs fpc36, fpc40, etc. Alex

Mistake. FPC already has good dirs when installed in fpcupdeluxe:

ls
bin lib msg share units

So all I need if I use Deluxe, is to make symlink to /usr/bin. Good already. What is not good is the default FPC installer which scatters dirs here and there.
And 'src' dir is not 'integrated' into FPC installer, it's not good too. Some macOS users have problems with fpc-src package, it will be solved if 'src' will be integrated into installer.

Maybe another redesign is necessary? Unfortunately, good compiler developers often aren't very good at web design, and someone has to contribute this. Look at the gcc or the llvm site, it's even worse. :)

https://gcc.gnu.org/

https://llvm.org/

Or maybe, it's better? I don't know. Maybe explain what do you mean by "doesn't look like the project is very lively". Maybe we should post updates more often?

- Lazarus looks very complicated with its many windows. And it is also relatively complicated to understand and use. There are too many options that are too nested.

Kinda agree, at least for beginners and for small programs. How about the console IDE? I sometimes prefer it for small programs. But for large programs, nothing beats Lazarus.

Free Pascal is exactly as "scattered" all over the Linux system, as gcc, clang, rust and pretty much any other compiler. How is this exactly a problem, since all major distros ship fpc as an official package and it is used to build other packages as well? It's not exactly difficult to do e.g. on Fedora:

sudo dnf install fpc

or

sudo dnf install lazarus

Even strange distros like NixOS ship fpc. I'm sorry, but I don't get it, how is this a problem? Maybe for people who are new and want to get into FPC development and want to build it from source? But definitely not for new users.

- Fpcupdeluxe: A good idea. But it doesn't work. I have tried to install an AVR crosscompiler on a Linux system. Fatal: Can't find unit Infodrwf used by Project1. And ‘Project1’ does not use any 've never used it, so I can't comment. But if you think it's a good

idea, you should contribute patches to make it work. That's how open source works. Sadly, IIRC, the person who originally created this project died a few years ago, so the project probably needs new contributors?

- For a new installation of Lazarus: The most important quick start icons have to be configured again at the bottom of the source code window. So that fast and smooth work is possible. Instead of placing them like this from the start. The many confusing windows I have already mentioned above.

I tend to agree that Lazarus is a little bit too complex and convoluted for beginners.

Still don't get it. Use your distro's package manager. If your distro doesn't package fpc, then become a packager and contribute fpc as a package. This way, fpc-compiled programs can also be added to the distro.

Best regards,

Nikolay

I am cross posting this to the Lazarus list, since some of this relates to Lazarus.

Rainer Stratmann wrote

- Lazarus looks very complicated with its many windows. And it is also relatively complicated to understand and use. There are too many options that are too nested.

About the options: This is 2 fold.

1) The count
2) The presentation

"Count": Of course (assuming that all those involved in the decision  making can be convinced) they can be reduced. Then existing users will just have to live with the loss of their favourite setting. Or be forced to install (included or 3rd party) add ons. Or worst, leave.

"Presentation": Oh, yeah, that could be a lot better. Including an "advanced" mode, to reduce what is immediately show to a newby. And Including a wizard.
Just needs someone to do the work.
Some part is bound to the underlaying structure where options are stored => that makes it more work to change stuff.

- Crosscompiling: The compiler file name is hidden in Tools - Settings instead of in the project settings.

If it is cross compiling (using same compiler version), and if the compiler is installed (as cross compiler):
Project Options > Compiler opts > Config and Target

- For a new installation of Lazarus: The most important quick start icons have to be configured again at the bottom of the source code window. So that fast and smooth work is possible. Instead of placing them like this from the start. The many confusing windows I have already mentioned above.

You mean the editor toolbar?
I don't know if it has ever been discussed, if/what the default config for it should be.

However, Linux is marketed by countless people blogging and making videos, as well as mentioning in PC related press/magazines.

IMHO its 50/50

The impression a user gets when using the project can decide if they stay or turn away. But it does rarely bring them to the project to begin with.

And, the impression is not just what they explore on their own, but what help they have to explore. Not just language but also environment. E.g., while I still prefer to search for text explanations of how to get an app to do what I need, I would guess that many people want a quick video showing them.
Yet, of course, no amount of help will change if the environment feels familiar or not. On the other hand, we don't want to pay for that by driving away old users, so we must preserve (at least as option) their preferred functionality and presentation.

But all that does not bring anyone new. It does at best help to keep them, once they are there. Word needs to be out, and it needs to be out on all channels/media, and as much as possible.

Hence IMHO: 50/50.

And of course, it isn't just agreeing on this. We obviously don't have many people for the marketing/social-media/... part. But we also are limited on the implementation side. Let's say we could find agreement on how to improve the editor-toolbar => then who does it?  (initial changes, maintenance, options, ... not all needed for the toolbar, but for other  changes maybe...)

If  I do a "apt-cache policy lazarus" it looks like it is an old version that get installed.

$ apt-cache policy lazarus
lazarus:
  Installed: (none)
  Candidate: 2.2.6+dfsg2-2
  Version table:
     2.2.6+dfsg2-2 500
        500 http://raspbian.raspberrypi.com/raspbian bookworm/main armhf Packages

Carsten

What trends, exactly? Can you be more specific?

If you think that way, then maybe create your own VSCode plugin for Pascal. What "official backing" do you expect, exactly? There's no such thing as "official backing". There are things that users care enough about to donate their development time and work on them. That's how open source works. How is it CodeTools' fault that your language server is buggy? Did you submit merge requests with fixes? Did they get rejected?

Do you have a garbage collection proposal for Pascal?

Free Pascal has a JVM target that supports garbage collection and pretty much nobody is using it. Why do you think that is?

One developer moving from one language to another is pretty anecdotal. IMO, Swift is a pretty decent language, but there's nothing entirely original or amazing for Object Pascal developers. It's an improvement over C, C++, Objective C, etc, but not so much over Object Pascal. What is it about Swift, that makes your old time friend more productive when writing macOS apps? Is it really the language, or is it the Apple IDE and framework? If it's the latter, there's a cost to that, your app isn't multiplatform, you need to rewrite it, if you want to support other platforms. Apple has no incentive in making that process easy.

Too many details to go into but there’s myriad problems that would need to be addressed.

Unlike others, your post is so negative and so vague and light in details it almost looks like trolling.

Best regards,

Nikolay

On Oct 16, 2024 at 4:44:35 PM, Nikolay Nikolov via fpc-pascal <

The biggest thing I see stopping new programmers from using Pascal is some form of automatic memory management. ARC, garbage collector, smart pointers or even RAII. That right there is a killer if you ask me. Even people who want to high performance will use C++ instead of Pascal for this reason.

If you want to use FPC these days what does a new user do? If they follow

It’s no one's fault there’s just not enough people working on these things. I tried to make a language server and a plugin even for VSCode but it’s hard to use and not clear for new users. Sorry I dont’ have the time either.

As for the language I think for GUI apps programmers don’t need or want a

I don’t even know how to use that! I assume it’s not something you just enable on any program. I’ve never seen programs adopt it.

I don’t think it’s hard to see Pascal are simply going to get old and die

Swift has a ton of features that Pascal doesn’t have which the kind UI apps which Apple supports. We could spend hours going over everything but I’m just saying a new programmer would look at Swift vs Pascal and choose Swift.

The bigger problem is of course support for Apples frameworks. Once the platform chooses a language like Apple does it kind of kills everything else. Even popular languages like C# don’t compete so I don’t expect Pascal to come out ahead her either.

Sorry to be negative I’m just sounding the alarm. I’ve watched the community dwindle over the years and people move on and new programmers adopt new languages. It’s clearly going in the wrong direction as noted by the original post. Am I wrong?

Best regards,

Op 16/10/2024 om 02:54 schreef DougC via fpc-pascal:

I agree roughly with you. It is simply a case of what brings in initial users. It used to be TP and Delphiers for either platform or cost but that is decreasing. We don't have big patron or other mechanism that substitutes.

All the navelgazing on what could be wrong with the presentation or initial user experience don't make up for those initial numbers. That mostly influences the conversion rate of initial impressions to users that try it, but we simply don't have the same number of initial impressions.  And those initial impressions are generated by major vendors or linux distributors or whatever adopting a language.

Keep in mind that before Python became data scientist's darling, many distributions installed it by default for over a decade to replace default distro engineering scripting in Perl (the scripting darling before Python). It is not just features, exposure is also a factor.

So, faced with this situation, what can be done? Short of a massive and expensive marketing effort, not much, except to remove obvious attributes that hinder adoption.

Not always.  Keep in mind that entice an initial user to stick around a bit longer is only one stage.   Core motivation to start and persist with anything beyond the first install, and all other stages till you are a core developer ;-) (and each stage has a progressively smaller conversion factor).

Overly focusing on the initial user experience is a luxury from projects with enormous initial impressions, where every effort for the initial user leads to masses of extra new converts, that will sooner or later permeate all aspects of the project. Either by paying the bills or taking part in development)

But we are not in that situation, and must keep an eye on all users, not just focus on the initial user conversion. Making sure the few initial converts stick is as important as getting more initial impressions.

One such attribute is the messy, cluttered look of the IDE. An IDE redesign with a cleaner, simpler, and visually appealing presentation would help enormously. It looks like that is what is being proposed here.

I think the docked IDE by default will have its advantages. Redesign is probably not an option.

And the longevity of those binaries, and quick install.   Copies that are installed standalone can be copied with components and all. Here at work we use Delphi for the main delivered applications, but lazarus for everything else because of the limited number of Delphi installs.

On Wed, Oct 16, 2024 at 2:12 AM Rainer Stratmann via fpc-pascal <

This is due to the default debug option that enables the "Display line numbers in run-time error backtraces". This option is not supported on the embedded targets.
To disable this in Lazarus go to: Project > Project options > Compielr Options > Debugging

Am Mittwoch, 16. Oktober 2024, 11:07:25 CEST schrieb Nikolay Nikolov via fpc- pascal:

Or maybe, it's better? I don't know. Maybe explain what do you mean by "doesn't look like the project is very lively". Maybe we should post updates more often?

It all comes to the point of easy beginning.

For example if you look for Linux AMD64/Intel 64/x86_64 and want to download Freepascal.

You go to download. Then there are all kinds of various systems.

In my opinion it would be better to put the most popular systems on top. This is Windows and Linux.

So you have to search AMD64/Intel 64/x86_64 and click on Linux.

Then if you click on SourceForge again you have a big confusing list of things you can download. At least for a beginner who wants to start coding. And that is the topic here: What to do to get new users?

If you click on Hungary/Canada this situation is not much better.

And if you finally got the right Package and were able to install it what do you have? Only the compiler.

This method is suitable for the experts of the experts. But not at all for a beginner.

Kinda agree, at least for beginners and for small programs. How about the console IDE? I sometimes prefer it for small programs. But for large programs, nothing beats Lazarus.

Console IDE :-) Then better Lazarus.

In my view that is a huge problem. You defend it simply by saying other programs do it, too. You rely on the distro in relation to updates.

I am very experienced in making software that my clients understand. If I would throw the software in front of my clients like this I had no chance to sell it to them and to survive. I know exactly what I'm talking about. If there is an Update of the software more than 100 clients can press a button and in 10 seconds at the latest they have the newest version. I'm putting it on a golden platter because they don't even have to pay for it at the moment. Because I see it also as an advantage for me to learn from the clients needs. And it is a very big advantage to have a fast feedback. Instead of waiting years for the newest version.

With one ZIP File that contains all necessary files you can have a similar effect.

Even strange distros like NixOS ship fpc. I'm sorry, but I don't get it, how is this a problem? Maybe for people who are new and want to get into FPC development and want to build it from source? But definitely not for new users.

May be it has changed (a little bit), but at least in the past it did not work smoothly "out of the box". I am happy if I get Freepascal/Lazarus to work on my Debian distro. And then I cut the internet access and don't touch it anymore for years. Because I am afraid that something goes wrong and I have to start the whole process again.

It would definitely be better for understanding if everything is in one directory and not scattered over the whole system.

I tend to agree that Lazarus is a little bit too complex and convoluted for beginners.

:-)

Still don't get it. Use your distro's package manager. If your distro doesn't package fpc, then become a packager and contribute fpc as a package. This way, fpc-compiled programs can also be added to the distro.

I made the compiler ignore the option and print a warning on these platforms:

https://gitlab.com/freepascal.org/fpc/source/-/commit/bdeb161d85e590f36fb0b5eb88c2cd1e3f1943ef

Please test.

Nikolay

Rainer Stratmann wrote

At the Lazarus Congress in Cologne in October 2024, it ended up being very interesting.

Promoting the event better might help! I did not know about it at all.

Why are no new users coming to Lazarus/Freepascal?

Pascal is not trendy any more. It should be but it isn't.

How can we get new, younger users to come to us?

Some more visible high-profile Linux apps implemented in it would certainly help. If they are some, get them to state that they are.

If there are not, then maybe it needs some.

One of the highest-project single Kylix (Delphi for Linux) projects I ever saw languishes in unmaintained obscurity: XPde.

https://kylixapps.narod.ru/

https://sourceforge.net/projects/xpde.berlios/

Picking that up, porting it from Kylix to Lazarus, and simply sharing the result, without updating anything, would be a good start, IMHO.

Good gods, no! No no no.

Keep it plain and stock.

Saying that, the macOS version is a bombsite and needs to be fixed. I have an old version and it's so complicated I do not know how to upgrade it.

But, if you want a simpler and better distribution/packaging model, then why is neither FreePascal nor Lazarus on either the Snap or Flatpak app stores? It should be. You should fix that.

Hairy Pixels wrote

I’ve watched the community dwindle over the years and people move on and new programmers adopt new languages. It’s clearly going in the wrong direction as noted by the original post. Am I wrong?

You may be wrong...

I don't have the numbers for FPC, but Lazarus has an ever increasing amount of downloads.  (Numbers for Windows, you can find others yourself) https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/stats/timeline?dates=2004-07-18+to+2024-10-16

On Linux you have to consider that many distros include it. And on top, you have other downloads, such as from git directly (FpcUpDeluxe).

That said, it could always grow faster. And hence this is **not** a "We are doing so great, lets lean back and just watch" statement.

Am Mittwoch, 16. Oktober 2024, 11:20:35 CEST schrieb Martin Frb via fpc- pascal:

If it is cross compiling (using same compiler version), and if the compiler is installed (as cross compiler): Project Options > Compiler opts > Config and Target

But there is not the compiler itself. If you have different targets (for example i386 and avr embedded) I think you need different fpc compiler versions.

You mean the editor toolbar? I don't know if it has ever been discussed, if/what the default config for it should be.

http://85.114.142.209:18080/uploads/x_Lazarus_with_icons.png What you can see here at the bottom is what I called shortcut Icons. If you want to compile the whole project you simply click on the button instead of searching it in the menu. That is one step to make it easier for all kinds of users.

https://wiki.lazarus.freepascal.org/Screenshots
Look at all this screenshots. This userfriendly icons are configured nowhere. I did not see them by now.

Am Mittwoch, 16. Oktober 2024, 14:03:39 CEST schrieb Marco van de Voort via fpc-pascal:

Making sure the few initial converts stick is as important as getting more initial impressions.

I can't see any contradiction here. If we do things better, everyone benefits.

Hi! I want to preface this by saying I am one of the new, younger (almost 23) devs that the FP team is looking for. I clearly grew in a different context when it comes to the programming world around me, so I hope my perspective will be valuable. This also brings forward the perspective of some active users over on the Free Pascal Discord server.

Programming language /and expectations thereof/ has evolved tremendously over the last ten or so years, and Lazarus can't keep up (and Delphi's limping along, despite having Embarcadero backing it up). I consider that we have to reach beyond Delphi and innovate as much as we can within this niche (as FPC has done before, implementing generics before Delphi) if we want to establish FPC's longevity.

There are many, many things lacking currently that are part of ``modern'' expectations:

1. a build system that is ergonomic and can be used in the terminal;
2. a package manager that can be used independently (looking at you,
OPM...);
3. ideally, something that could combine 1 and 2 (see cargo, go, Ada's
Alire etc.);

4. a proper VSCode extension (we can include Vim and Emacs there too, but the main focus is VSCode) with all the bells and whistles more established extensions have. I know we would all want to stick to Lazarus and we all know that VSCode is bloated, but we have to accept the reality that people do use it and it is really popular. Survive, adapt, overcome. :-) OmniPascal was a nice attempt, but it's dead and also closed source;

5. some form of describing projects that's (ideally) separate from Lazarus; it brings 1-4 together, as well as helping the following items in one form or another;

6. an independent language server (no, cutting Lazarus' guts doesn't count, not until people can easily install precompiled versions) that can be used with the VSCode extension;

7. a popular and documented testing library and some way of integrating
it into the aforementioned tool at #3;

8. a nicely-made (or at least not stuck in 1999... looking at you, GCC) website for the language itself (this would be an effort to promote Object Pascal in general, with a focus on Free Pascal, since Embarcadero definitely has the budget to hire some designers...). Even Forth, Fortran and Ada learned that lesson with their websites, we surely can do better;

9. educational and promotional materials (documentation's definitely NOT
the strong suite of Free Pascal...);

10. more widespread usage of PasDoc, or a solution like it, and improve how the documentation is displayed within Lazarus itself. We *really* have to insist on documentation and tutorials, since a lot of parts of the RTL and FCL might as well not be documented, with no examples;

11. more social media presence/marketing effort (at least The Silver Coder has been doing a good job on YouTube, as well as Code with Huw). YouTube, blog posts, Reddit, HackerNews etc.

It would be absurd to expect the Free Pascal team to do all of these, everyone's already stretched thin and overworked. More people that could develop FP would be nice. Notice that all of the things listed above *don't* involve changing the language in any way (maybe changing Lazarus, but not by a whole lot).

I have done my fair share of promotion of Free Pascal in my local communities (more generally Wirth's work, but that's not relevant) and I did bring people over to FPC and change their minds regarding Pascal, but this effort needs to be coordinated. We can't be an insular community, otherwise we'll die surrounded by the sharks of misinformation or of old age. We must not ignore the advancements that have been made by other current programming languages (tooling or otherwise) and how they've pushed the envelope of what's possible from a DX standpoint. I don't blame someone coming at me and thinking Pascal's old, when we're clinging on to Lazarus with *everything*. It is a bit sad if you think about it: we're putting Lazarus on a pedestal, which made the wider community (IMO) not consider what happens if you have to use its features outside of the IDE. We shouldn't be like Delphi, where everything *has* to use RAD Studio. We can be better than that. What's more frustrating is that there have been separated attempts at at least one of these items, so solutions do exist, but nobody put these together into something a beginner can use. Have fun using OPM outside of Lazarus without putting a lot of work into making it a CLI tool that can be used in CI/CD.

I have plans for 1-6 and 8 (especially #6, that's what I am working on right now), but I can't do it all by myself (I also have a thesis in progress). As a community, we all have to come together and work on all these fronts. Free Pascal will not suddenly become trendy again, but we shouldn't give up without trying. You miss 100% of the shots you don't take. I still have trust in this language (despite the occasional paper cuts and features I miss, but that's nothing a transpiler couldn't fix). This will probably fall on deaf ears and I don't expect action to be taken solely because of this message, but I hope it is valuable regardless.

Am Mittwoch, 16. Oktober 2024, 15:09:47 CEST schrieb Liam Proven via fpc- pascal:

Define "Compiler".

You use one and the same fpc.exe.

But you need a different ppc____.exe. All those ppc live in the same folder. And they are all called by the same fpc.exe, depending on the options given to that fpc.exe.

Of course, for that they must be installed as cross compilers. So they also share the fpc.cfg. But the all have their own ppu and o files.

> You mean the editor toolbar? > I don't know if it has ever been discussed, if/what the default config > for it should be. http://85.114.142.209:18080/uploads/x_Lazarus_with_icons.png

Yeah, editor toolbar => you get that name, if you click the "configure" option. The toolbar can be on top or bottom.

What you can see here at the bottom is what I called shortcut Icons. If you want to compile the whole project you simply click on the button instead of searching it in the menu. That is one step to make it easier for all kinds of users.

Generally a matter of personal preference. I use a key combo, For me the toolbar is lost screen space.

But, I don't say my preference has to be the defining one. Since it can be disabled, IMHO it may be there to start with.
As for which buttons should be on there by default, I have only a basic opinion (since I don't use it).

But for people using toolbars, there is (both can be configured)
- the "IDE coolbar" (toolbar in the main IDE window, where the menu is)
- "Editor toolbar"

Since you can have many editor windows open, and each of them shows you the same "editor toolbar", IMHO that toolbar should have (as default) only buttons relating to the current editor (or the editor window / the tabs in the editor window).
https://pasteboard.co/8CdEFiy4cZiy.png has 3 editor windows => 3 times the toolbar (not much on it in my case, but that is not the point)

Functions such as "compile the whole project" don't relate to a single Editor. Showing them multiply times (for each editor window) is imho not a proper default.

But of course fine for anyone who likes it.

https://wiki.lazarus.freepascal.org/Screenshots Look at all this screenshots. This userfriendly icons are configured nowhere. I did not see them by now.

Well, I am not against having them visible as default. Or having a different set of them.
Though I don't call that decision on my own.

- Find out on the Lazarus list (or bug tracker), what would be accepted
- Within that, provide a patch. Or try to find someone who will.

That is how change happens.

On Oct 16, 2024 at 8:50:21 PM, Ștefan-Iulian Alecu via fpc-pascal <

I have a language server I made and VSCode extension but it’s hard to use and buggy (mainly because CodeTools) but for other reasons that are my own fault. I never got the package working well enough to download binaries and run smoothly. Personally I use Sublime Text but I use VSCode for the debugger.

There is one other person helping me but I haven’t touched it in a long time after many changes were made (for Lazarus users I think) so I’m not sure how well it’s working now. There’s just not enough community interest and people with free time to tie up all the loose ends.

Compilers are very different, compared to regular apps. Linux distros usually have very special rules for packaging compilers, as well as for updating them. So, in a way, they are sort of a "system" program, as far as Linux distros are concerned. They are a tool, used for building the distribution's other binary packages. They're not just some self-contained app.

Most Linux users should be fine with just using fpc from their distro. And those who want to build fpc trunk (and these are not beginners) can still use fpc from the distro as a starting compiler.

Maybe the FPC website needs to include information on how to install fpc from the distro, for distros that package it. For example, the download page for the Nim compiler includes that under "Installation using package managers":

https://nim-lang.org/install_unix.html

Nikolay

One of the highest-project single Kylix (Delphi for Linux) projects I ever saw languishes in unmaintained obscurity: XPde.

I tried to compile it using Free Pascal and fix it, however I am constantly stuck with all the Kylix-specific parts. I even tried installing actual Kylix just to see if it was my fault, but that's apparently notoriously hard to install on modern distros, so I gave up. I think it needs a rewrite, at least a partial one. I don't know how good Kylix compatibility is, but I don't have much faith as is. Also, a lot of apps seem to be lost to time, so if someone dares to embark on this journey, they'd have to remake said apps, at which point you could just rewrite everything and possibly port it to FP or move away from X11 to Wayland.

On Oct 16, 2024 at 8:50:21 PM, Ștefan-Iulian Alecu via fpc-pascal <

The question I have is, if you’re a new programmer not wanting to make a cross platform app what are building with Pascal? It’s still a good low level compiled language and you can do things like SDL and games with it but people are using C++ for that mainly and think FPC lags behind in some areas like smart pointers and RAII.

I’d look at what languages like Zig and Rust have done to attract so many new users and what kind of programs they’re making. I like the Jai (closed beta) and Odin projects too in that they promote games and have all the stuff you’d need to get started right out of the box.

Regards,
Ryan Joseph

Another point is that FPC doesn’t have an official forum except for the mail list and that in and of itself is a problem if you ask me. Most young people don’t use email and won’t like this. I myself don’t prefer the mail list over some of the very nice forums that allow posting code and very easy to use and browse information.

You can’t even easily browse the old messages compared to other services. I would much prefer what https://discourse.llvm.org/ does and many others for example. I brought this up a while ago and people didn’t seem to like the idea. Very well but for new users I think you’re shooting yourself in foot by not have a competitive way to get help.

I am aware of your work. As long as you still depend on CodeTools and Lazarus internals, the language server can't be called independent. I have tried to compile the LSP (at least Michaël's version) and it seems to fail every time. Which is why I am trying to make my own, in an attempt to be more usable right away for VSCode. I also use ST4 from time to time, as well as Neovim and Emacs, and the experience there has been lackluster, sadly. IMO, there is community interest in the project itself, but when push comes to shove, magically nobody wants to get involved. Is this the bystander effect? Maybe. /shrug

I'll revisit your extensions and give pascal-language-server yet another shot, but I am not too confident. If I can make it work within a CI/CD context, I'll send a PR. This would imply cloning all of Lazarus, and following trunk (I wonder if that's still needed, since Laz 3.6 is out), and that's why not having Lazarus in the mix would be a net benefit.

Op 16/10/2024 om 04:32 schreef Rainer Stratmann via fpc-pascal:

I don't think we can compare ourselves to projects that IBM already invested a billion into two decades ago.

The foundation helps, but is not yet in that magnitude :-)

Portable Lazarus would just kick ass.

g.

Op 16/10/2024 om 15:36 schreef Rainer Stratmann via fpc-pascal:

You need the new users to stick, not just to try it. Specially if you have to do a lot of trouble to increase the numbers only a bit. This is different from the really popular projects where small efforts can huge changes in usage.

It is not bad to work at release engineering and default behavior of the IDE, but it should be more focussed on what can be done with limited means without changing course, rather than wild new plans.

I have some interest in implementing a language server client in the fp console IDE, so I have some interest in helping with the language server as well. However, I'm quite busy with other projects right now, so I don't know when I'll have the time to work on that. Maybe in a few (6-12) months?

I also have some experience from my day job on making a VS Code extension for the Nim language (you can see my commits in the Nim language server here
https://github.com/nim-lang/langserver/graphs/contributors and for the Nim VS code extension here https://github.com/nim-lang/vscode-nim) and I can definitely say VS Code is horrible crap. It's buggy as hell, new versions break API compatibility all the time and it makes it look like it's your language extension's fault.

From my experience, the FPC community is lucky to have something as good and stable as Lazarus. The IDE experience for Nim in VS Code sucks so much and the only reason people tolerate it, is because, there's no alternative IDE for

I am definitely not saying it isn't a good low level language. That is one of the things I use to promote the language. However, you are right in that we should invest in being more than "the free Delphi alternative". Great, you're attracting 10 people from the Delphi side, but for the average shmuck they don't know what Delphi is or what it's about. Lazarus can still market itself as a RAD editor, that's what it is, but I don't know how you can market Pascal in general. Are we forever destined to be the old GUI language, akin to VB6? We have to think about how we can sell ourselves, otherwise nobody's going to consider us. Or maybe they're a student, in which case... /shrug

Op 16/10/2024 om 06:53 schreef Alexey T. via fpc-pascal:

Afaik the FPC installer script already suggest a location in the home dir if you execute it with /usr/lib non writable, and it does so for at least two decades.

On Oct 16, 2024 at 9:08:13 PM, Stefan-Iulian Alecu via fpc-pascal <

Exactly it’s hard to use and the building fails for people. I only use it on macOS but things always change and are breaking. It DOES work though and offers a good deal of functionality, at least all the important stuff.

This is more of a build problem for you though right? I know it’s not a standalone thing and relies on Lazarus but what realistically are you going to do? Already CodeTools is a massive project and I wouldn’t want to recreate that just to for easier building. Then you need to keep it updated for every new change the compiler makes, which no one has time for.

I wonder how other new compilers handle this. I think unless the compiler itself has a “quick” mode for LSP’s you’ll need a whole other program which knows the syntax and isn’t in sync with the compilers parser/type checking etc…

On Oct 16, 2024 at 9:18:01 PM, Nikolay Nikolov via fpc-pascal <

Not my experience. I prefer the editor in Sublime Text but VSCode is a good debugger which works with LLDB and Pascal. VSCode is wildly popular as well so FPC is missing out on new users by not having this as option. Maybe some packages you used were the culprit? They have a monthly update cycle too so I would think they catch these things.

When I learn a new compiler these days I download the installer, run it, then check VSCode or Sublime Text for extensions to install in one click. If that doesn't work I probably just give up because I idon’t have time to be playing around and there’s myriad of new languages to play around with these days.

I don't know, it could be the Nim to JS compiler, or the fact that the previous plugin developer didn't use the LSP protocol, but direct integration instead. But I don't like the whole idea of an IDE, written in JavaScript. It's horribly bloated and difficult to debug.

The LSP protocol is fine, though. I like the idea, it allows integration with many different IDEs and editors. Sublime Text is just one example, there are many people who use Vim, Neovim, Emacs, Helix and many others. I also think it's a nice and quick way to improve the console IDE by adding an LSP client. But I have a huge backlog of things to do, so I haven't started on this, yet.

Yeah, it's tempting with its store of extensions. Too bad most of it is crap. And it's not fully open source. Sorry, I use it at work, and just don't like it. Anyhow, there's nothing wrong in developing an VS Code plugin for Pascal. Anybody interested can try to do that. Most of the work is probably fixing the LSP server, as it does most of the work. This way, the extension itself can be kept minimal.

Best regards,

Nikolay

On Oct 16, 2024 at 9:46:05 PM, Nikolay Nikolov via fpc-pascal <

Agree it’s a web app and you can feel it. That’s why I use Sublime Text (an excellent high performance editor but hard to configure it’s JSON settings) but you must use VSCode for a debugger on macOS unless you want to use Lazarus and that editor.

The LLDB extension works well and many others. Sure it’s filled full of crap but the highly rated packages tend to work well. It’s fast to install and lightweight compared to Lazarus and Visual Studio or the likes. It's wish it wasn’t Electron but that’s why Microsoft chose for cross platform and they are making monthly updates so apparently it’s worked for them.

The official Freepascal website look just fine.

- Lazarus looks very complicated with its many windows. And it is also relatively complicated to understand and use. There are too many options that are too nested.

Lazarus does not look complicated. It has it own distinctive look & feel. User
should be able to completely detach windows from from main so it would be possible to move them to different monitor, virtual desktop & freely move on monitor.

Freepascal will never become popular in a world where JavaScript is everywhere, Delphi exists & Pascal has a reputation of not cool programming language.

Am Mittwoch, 16. Oktober 2024, 15:54:20 CEST schrieb Martin Frb via fpc- pascal:

That means fpc.exe calls another (more specific) compiler?

Yeah, editor toolbar => you get that name, if you click the "configure" option. The toolbar can be on top or bottom.

However, this has to be done from scratch every time you install Lazarus instead of having it in the basic installation.

Generally a matter of personal preference. I use a key combo, For me the toolbar is lost screen space.

Then may be a simple turn on/off toolbar button (I hope it is not a lost screen space for you :-) ) would make sense.

But, I don't say my preference has to be the defining one. Since it can be disabled, IMHO it may be there to start with. As for which buttons should be on there by default, I have only a basic opinion (since I don't use it).

I think the buttons on my little mentioned screenshot are useful for all (beginners and experts). And next to it a shortcut icon to the edit of the toolbar. Edit of the toolbar is already possible with a right button click. Better would be an explicit button so that this is more obvious.

Am Mittwoch, 16. Oktober 2024, 16:16:45 CEST schrieb Marco van de Voort via fpc-pascal:

It is not that much work to appear more userfriendly. Often it are little things. But when they not work you got stuck.

Am Mittwoch, 16. Oktober 2024, 17:40:26 CEST schrieb xuser13--- via fpc- pascal:

Freepascal will never become popular in a world where JavaScript is everywhere, Delphi exists & Pascal has a reputation of not cool programming language.

I strongly believe that many users will have fun with Freepascal when it would be easy to use. Turbo Pascal was very popular because they made it easy. You can do everything with Freepascal.

Yes.

You can directly configure ppc___.exe instead. But there is rarely a benefit in it.

Btw, on your initial statement: You can also set a completely different compiler (e.g. diff version) in the project options. Under "Compiler commands", in the edit "Compiler", which is preset to "$(CompPath)" // Which despite it names returns the exe
https://wiki.freepascal.org/IDE_Macros_in_paths_and_filenames#Paths_and_Parts

> Yeah, editor toolbar => you get that name, if you click the "configure" > option. The toolbar can be on top or bottom. However, this has to be done from scratch every time you install Lazarus instead of having it in the basic installation.

That sounds like a bug to me. Unless you mean a really new install, not an upgrade?

I have not tested this one (as I do not use it), but normally, if you upgrade the config is kept (in your primary conf dir / default ~/.lazarus ).

> Generally a matter of personal preference. I use a key combo, For me the > toolbar is lost screen space. Then may be a simple turn on/off toolbar button (I hope it is not a lost screen space for you :-) ) would make sense.

The option already exists. In Tools > options > Editor toolbar. Hence, I said its no issue for me if it is there by default. Actually: I just checked the released 3.6 => and the Toolbar is shown by default.

It just comes with only 2 buttons, but as I said, I am not opposed to an other preset, but you need to see what others in the team think. So Lazarus mail list, or bug report.

http://85.114.142.209:18080/uploads/x_Lazarus_with_icons.png They look like edit command => Though I am not sure what the gears are....

My personal concern was from your statement:

If you want to compile the whole project you simply click on the button instead of searching it in the menu.

IMHO, that should be in the cool-bar => the global toolbar below the menu. It doesn't relate to any particular editor. See the quote of mine at the very bottom of this mail.

Edit of the toolbar is already possible with a right button click. Better would be an explicit button so that this is more obvious.

So is the coolbar (well don't know about right click, but in the options)

The irony in this question is that your appear to think too technical, too much caring about internal details...
More of what an expert would think, than what a beginner would look for ... (And yet, this is about making it more beginner friendly...)

If you want to cross compile, you shouldn't need to think about which compiler to use. Just what target (defined by OS and CPU) you need. (and in future FPC 3.4  or 4.0 maybe what sub-target (widestring vs ansistring)).

Then you see "... Target" in the tree of options and it has
- Target OS
- Target CPU family

And, yes well "Target Processor", which is not really cross compile, but optimization for a specific processor (removing backward compatibility for any older CPU of that type).
That may lack a bit of clarity....

Of course, it will only work if you setup is correct.

On Window there are installers for cross compiling between 64 and 32 bit Windows. If you install that into the same dir as your Lazarus then it will work out of the box.
Sorry, no such think for Linux to other OS (not yet anyway)

Am Mittwoch, 16. Oktober 2024, 18:27:19 CEST schrieb Martin Frb via fpc- pascal:

Yes, I mean a really new install.

Sorry I am tired for today...

Prease DON'T add garbage collector. IMO it isn't a good idea. I had very bad experiences with it. Unless somebody found a new magic algorithm in the last decade...

I'm a bit baffled. I'm using the VS Code plugin, it works OK. It needs some configuration because Lazarus works fundamentally different from VS Code, but when that is done, the plugin works fine.

Some more actions can be added, but the basic actions work fine.

From my experience, the FPC community is lucky to have something as good and stable as Lazarus. The IDE experience for Nim in VS Code sucks so much and the only reason people tolerate it, is because, there's no alternative IDE for may like or dislike VS Code, but young programmers are trained with VS Code.

It is the number 1 editor/IDE. These are the people to be seduced.

Lazarus breathes 1995. This is ok for me, and probably all old-timers here, but for young developers, they look like they ended up in the middle ages of computing.

Most will simply not do the effort to look beyond that. I had to work long on my colleagues to make them see that Lazarus has in fact better things on offer than Delphi and/or IntelliJ/VSCode.

At work, now they make available a default setup of Lazarus: It looks almost like VS code. With the latest additions, it is possible.

Without the possibility to get the VS code look and feel and feature list, they would not have made it available to all developers in the company.

So if you want young people to come to pascal, but present them with an IDE that looks like a 1995 IDE, don't be surprised that they don't stay.

Michael.

Op 16-10-2024 om 16:06 schreef Hairy Pixels via fpc-pascal:

FPC asked the Lazarus team to provide FPC specific forum section to act as official forum, so this is FUD IMHO

Op 16-10-2024 om 15:50 schreef Ștefan-Iulian Alecu via fpc-pascal:

To paraphrase GJC, I came, I provided the resources and I overcame.

5. some form of describing projects that's (ideally) separate from Lazarus; it brings 1-4 together, as well as helping the following items in one form or another;

Does VSCode have a project system then nowadays?  I thought that being projectless was the main feature of VSCODE.

There is fpdoc, and the FPC docs are quite ok. The problem is contributors.

Agree. In practice the best solution is to try to rise through the ranks and become a bugreporter and triager, delivering good quality patches to core, and maybe have a bunch of own projects on the side. Core developers are usually recruited from those ranks.

We can't be an insular community, otherwise we'll die surrounded by the sharks of misinformation or of old age.

Or because we spread ourselves too thin. Having dreams of an ivory tower that somehow restores equilibrium ( new developers > old developers) is easy. Making the economics work is much harder.

Attempting to whipold and tired Lazarus developers into submission to work on vscode plugins IMHO it doesn't make sense. In short, I think the new IDEs developers must come from the new developers ranks, those who actually believe in it.

Sorry, but there has been so much nonsense in this thread, I just had to add my 2c as well.

An absolute non-factor. Yes, the "Latest News" seems to be dated, but then I would prefer people involved in the project work on compiler related issues rather than on web sites.
The latest FPC announcement is now 3 years ago, but then the overall release cycle is much slower than on a lot of other projects, but by and large, I could consider this a good thing....

- Lazarus looks very complicated with its many windows. And it is also relatively complicated to understand and use. There are too many options that are too nested.

Well, what is so complicated about it? Of course, you need to know what you are doing. Maybe some windows could be hidden until they might be used (like Watches, Evaluate/modify, or debugger), and they are easily activated from the Window menu. But if you are really programming, it actually make sense.
Is Lazarus "perfect"? Probably not, but IMHO, it is light years better and easier to use like abominations like Visual Studio (Code, yes, I know they are not the same) or any of that Eclipse based stuff. And definitely FAR more lightweight than any of those.

That doesn't make any sense!  Yeah, cross-compiling could be made it bit more obvious, but then in a lot of the "alternatives", you can't then, if you properly design your software,
this isn't a task that you do a couple of dozen times and hour...

non-issue IMHP

- Fpcupdeluxe: A good idea. But it doesn't work. I have tried to install an AVR crosscompiler on a Linux system. Fatal: Can't find unit Infodrwf used by Project1. And ‘Project1’ does not use any 't care, never used it in all the years that I am using FPC (going

back when it was still called FPK) and Lazarus.

You completely lost me on this one.... 😕

As good as Freepascal is. The situation described above is a brake pad and sooner or later leads to a dead end.

Maybe you need to look at your overall approach to (application) programming, not as FPC/Lazarus being another Python (or whatever is the rad programming language de jour)

My tip is to put all the required files in one directory. This also makes it easier to install an installation on the different systems. Only one ZIP file is then required. And you can even install it without internet access.

I don't see the general problem here. By and large, FPC (and Lazarus) is installed rather quickly. What I however miss is an option to transfer a (general) configuration from one system to another, specially between different OS, as I do most of my work on Windows 1[0,1] but some of my application also need to be tested and worked on on Linux or macOS. This cross-platform capability is IMHO one of the reasons why you couldn't just "put everything into one directory". The directory structure, including permissions, is simply different for each of them.

If I would have some serious complains, it would be that in the last few years at least some of the developers have paid too much attention to include all those (supposedly) fancy new paradigms instead of the core of programming in Pascal. Even Object Pascal, though IMHO not every little thing needs to be put into objects/classes when there really isn't any gain from it. Some times, commonly used functions might be clearer and thus easier to understand and maintain written in procedural form.

As far as Lazarus is concerned, the only thing that just keeps bugging me is that there is no ability to "just compile" a file that is currently active in the editor, to test it for syntactical correctness/typos, without having to create a separate test project each and every time or recompiling it in the context of a larger application. This could be one thing that could make it easier for newbies to Pascal to get started, specially when at first dealing with non-GUI programs.

Translated withwww.deepl.com

Ist Dein Problem möglicherweise dass Deine Englischkenntinisse nicht die Besten sind und Du deshalb einige der Strukturen nicht verstehst?

Ralf

Actually, my employer has already offered twice to sponsor a web-designer to overhaul the website. Money was not an issue. The idea was to announce a contest and to select a winning design. The designer gets then the money.

I have proposed this to the FPC core team, after some insistance I managed to get a list of constraints from (if memory serves well?) 1 person.

I admit I was put off by what I perceived to be a complete lack of enthusiasm for this plan in the team, so I put it in the refrigerator for the time being...

My intent is to re-start the debate on this after 3.2.4 comes out.

Just to say that I do think the site (20+ years old?) can use an overhaul, and that with the above plan, no developer time needs to be spent on it.

Michael.

There is fpdoc, and the FPC docs are quite ok. The problem is contributors.

In my experience (and in that of the people I brought along, as well as already existing devs around me), no, they aren't OK. They're passable at times, yes, but they aren't what I would call "good". I have been slowly going through the FP docs and improving this as I go on my private fork, once I get more time and go through everything I'll send a PR. This is one way people who might otherwise be scared of compiler code can contribute. Actually, there should probably be a call to action regarding contributors and tell people how to help either team (FP or Laz). I am sure there are people on the forums who would be more than glad to help, but are intimidated by the thought of dealing with compiler code, not knowing they can contribute with bug reports or docs.

I mentioned that, in the previous quotation you used. We can't expect people that are already working on the compiler and Lazarus to also work on VSCode extensions and whatnot, that's absurd for plenty of reasons. Nothing good can come out of overworking the current team, so this is a call to the community (that should be made on the forums too, I am sick of repeating the same message over on the "Unofficial" Free Pascal Discord server) to help.

We all have to realize that nobody will implement these things for us, and complaining is easy when you're just a bystander unwilling to contribute. I have discussed these things with the Discord server and have started a GitHub org for this purpose (strictly speaking focused on Object Pascal as a whole, but it's a cover-up to work on things related to Free Pascal for now). But this shouldn't be a one man project, it should involve /everyone/, so the CtA in the first paragraph is even more important.

Hairy Pixels via fpc-pascal schrieb am
Mi., 16. Okt. 2024, 16:07:

The official forum for Free Pascal is the Lazarus forum. It does not make sense to split the community even further (which it had been back when FPC had its own forum till it was decided that the Lazarus forum is the way to go).

No, thank you.

Regards,
Sven

Freepascal will never become popular in a world where JavaScript is everywhere, Delphi exists & Pascal has a reputation of not cool programming language.

I don't think Delphi existing should be your main concern. It's a miracle it still exists right now and it has clients. I still use it as a "hey, this is what the Pascal community can achieve" argument, after telling people about Free Pascal (and rarely PascalABC.NET and Oxygene). True, Free Pascal will never be "popular" (not like Delphi is either...), but it doesn't mean we shouldn't try to promote it. Also, we can capitalize off of JS being popular, since we have Pas2JS. That's what Scala has done with Scala.JS, Clojure with ClojureScript, Ocamljs, Smart Mobile Studio (even Pascal can market itself properly), Ruby with Opal etc. People really don't want to deal with writing JS (look at how many people choose TypeScript and back in ye olde days it was CoffeeScript), so we can offer a viable alternative. Instead of denying the reality around us (we're just a small school of fish (yes, that's the proper name) in the large Programming Sea, so we won't do a lot), we can try to mold around the current environment and take advantage of it and market ourselves that way. It's easier to convince already existing Pascal programmers that have done Turbo Pascal since the dawn of time than new people, and the latter group is what we should be focusing on.

You might've not realized that, but this is *foreign* and totally different from how most IDEs out there function. If you're familiar with Delphi 7 and lower, great, this feels natural, but the problem is that other IDEs aren't like Delphi 7. Lazarus is still stuck in that era, and that's /fine/ (at least, as far as the old Pascal devs are concerned), but I see most people around me (beginners and otherwise) immediately dock the IDE or ask me how to do it. Not to mention that it immediately fails to function for tiling window managers. And "distinctive look and feel" doesn't mean said look and feel is intuitive. I believe it would be better if Lazarus was docked by default and give the option to easily undock it, because far more beginners or curious people would want to dock it, it's a better default. If you don't believe me, please look at as many IDEs as you can and tell me *one* that's undocked like Lazarus is. It genuinely is something unusual and jarring to newcomers. Maybe there's a reason most other IDEs are docked, and even if you disagree with that particular decision, it would be hard to deny the reality that it's how people expect IDEs today to be structured. Even *RAD Studio* gave up on the idea. Happy birthday 2002!

Stefan-Iulian Alecu via fpc-pascal
schrieb am Mi., 16. Okt. 2024, 16:08:

I am aware of your work. As long as you still depend on CodeTools and Lazarus internals, the language server can't be called independent.

The point of using CodeTools is that they are kept fairly up to date with what the compiler supports and even across different versions of the compiler. Completly implementing one's own language parser is essential unnecessary duplicated work considering that we don't have easy pickings regarding personpower.
Also once a CodeTools driven language server would be usable enough one might argue for having it used by the Lazarus IDE as well (assuming the language server protocol can support everything that the current direct use of CodeTools supports), thus possibly moving CodeTools and the language server out of the Lazarus IDE.

Regards,
Sven

geneb via fpc-pascal schrieb am Mi., 16.
Okt. 2024, 16:19:

At least the Windows installer already provides an option to make the installation portable. Something similar can probably done for Linux as well (macOS requires the installation of development tools provided by Apple, so a totally fresh system would not work).

Regards,
Sven

Guillermo Martínez Jiménez wrote

Prease DON'T add garbage collector. IMO it isn't a good idea. I had very bad experiences with it. Unless somebody found a new magic algorithm in the last decade...

I agree. Although, I'm not against someone adding a .NET target (which has to be garbage collected), or doing some cool things (like, apps, libraries, frameworks, etc.) with the JVM compiler (which uses a garbage collector). But people don't seem to be interested in that.

For the native targets, I think garbage collection is a bad idea.

That being said, I think some garbage collectors that can be used with C and C++ can also be used with Free Pascal, or at least, support for them should be easy to implement for the few people who want to use them.

Nikolay

> By and large, FPC (and Lazarus) is installed rather quickly.

The only thing I wish for the installation of FPC is that all the help files were included and installed by default. I am always annoyed by being required to go get the help files and add them in myself when I install FPC. I think many years ago making them separate files that could be downloaded if needed made sense, but those days are long gone and manually downloading and installing the help files is just not necessary anymore. I know you don’t need the help files if you have Lazarus, and I’m in the minority, but I like the text IDE and use it exclusively.

I think anyone coming across the IDE and not realizing the help needs to be downloaded and installed separately would just assume there is no help. I know it states it quite clearly on the download page, but when downloading it you are just tying to get it working it’s not until you want to really do something and try to use the help that you realize there is none, and by then you forgot what was on the download page.

James

Stefan-Iulian Alecu via fpc-pascal
schrieb am Mi., 16. Okt. 2024, 23:38:

I think there are still some issues simply switching between the docked and undocked layout. If that would be solved (patches welcome 😉) then it would be a much easier decision to have the IDE be docked to default, cause those users that prefer undocked (and those *do* exist and we don't want *those* to leave just because we did this wrong) can then easily switch it to undocked.

Regards,
Sven

Hairy Pixels via fpc-pascal schrieb am
Mi., 16. Okt. 2024, 13:49:

It's not something you enable. It's a completely different platform, namely the Java Virtual Machine, so essentially a different processor.

Regards,
Sven

Nikolay Nikolov via fpc-pascal schrieb am
Mi., 16. Okt. 2024, 11:44:

To be fair working with the JVM target is quite a bit different and then not even all language constructs are supported yet (though there is a merge request I want to take a look at to improve the situation).

Regards,
Sven

Rainer Stratmann via fpc-pascal schrieb
am Mi., 16. Okt. 2024, 01:16:

News flash: this is how well behaved Linux applications are supposed to behave no matter if they are a "Linux system program" or not.

That said the FPC installer allows you to install FPC in a completely separate folder with only the configuration file(s) in your home directory (I do so for example, cause I have multiple FPC versions installed).

Regards,
Sven

Ok, that's cool, then. So, what's the problem? If the VS Code plugin works, why all the complaining about the lack of VS Code support?

Nikolay

Interesting. Thanks for looking into it!

And here is my 2c worth ...

Firstly, I will say that I do not know much about the group that manages FPC and related tools. I am also relatively new to FPC but a long time user of Delphi. Here is a newbies view of the world:

1. while the content on the website may be correct, it looks dated (first impressions count
2. I cannot remember how many options there were regarding what to download but stuck for a minute or two

From then on it was OK.

Now, to what I wanted to say... I joined this list last night because it was suggested to me based on this topic. Depressing reading. I also understand that users venting is a normal thing. (And then the messages will prolly get picked up by AI and people read all about what's missing!)

Here are some questions/ideas/thoughts:

1. Will the ideas get collected and considered for the "next" version?
2. Is there, or should there be a roadmap to give users hope?

Also, are there things (features) in the language that we can leverage from a marketing perspective - that you can build for a large number of devices is not very useful (if the langage is flagging). Just my opinion.

Also, given that I have also have a YouTube channel, if there are things you would like promoted for the benefit of the language, then let me know. I would even appreciated collaborating with others.

But when ideas are put forward by the truck load, something has to be done with these.

Cheers,
Tim
(The Silver Coder @silvercoder70 on YouTube)

On Thu, Oct 17, 2024 at 7:17 AM Michael Van Canneyt via fpc-pascal <

Am Donnerstag, 17. Oktober 2024, 00:08:27 CEST schrieb Sven Barth via fpc- pascal:

News flash: this is how well behaved Linux applications are supposed to behave no matter if they are a "Linux system program" or not.

Haha, I did not know this. Very good that you tell me...

As far as I know fpcupdeluxe stores everything in one folder and that works (better).

That said the FPC installer allows you to install FPC in a completely separate folder with only the configuration file(s) in your home directory (I do so for example, cause I have multiple FPC versions installed).

Very good.

Am Mittwoch, 16. Oktober 2024, 23:12:08 CEST schrieb Michael Van Canneyt via fpc-pascal:

Actually, my employer has already offered twice to sponsor a web-designer to overhaul the website. Money was not an issue. The idea was to announce a contest and to select a winning design. The designer gets then the money.

What counts is a site that is alive.

Look at
https://www.mikrocontroller.net
This site is very alive. A lot of development is going on there. You can even make a post as a guest without registration.

May be we don't have to reinvent the wheel and ask the owner. https://www.mikrocontroller.net/contact

Sorry, but do you really suggest that Lazarus should intentionally adjust itself to the shortcomings of other IDEs? Being able to move windows around over multiple (2 or 3) monitors is the most effective way to work., like one screen for the source code/object inspector, once screen for the program output and one for all debug related windows. Everything easily in view, no need to move around (or resize) windows like stupid, just because what you want to see is somewhere in a docked and minimized window...

Again, just because other IDEs do it differently doesn't mean that this is in fact the best way to go. It's IMHO rather a result that other IDEs (which are mostly somehow web browser based) don't handle undocked windows properly...

Ralf

Not sure what kind of help you are referring to, but Help seems to be installed on my system I am currently working on, and all I ever download when upgrading or installing a new version is the 64bit version of Lazarus&compiler as well as the 32bit cross-compiler... And on Linux, I download and install in order 3 files, as clearly indicated, which are fpc-laz (the compiler), fpc-src (source code) and lazarus-project (IDE), with the later including the help files...

Ralf

We don't have a way to access the Lazarus forum from the main page, so there is no way to make it “livlier” that way.

And for news: I prefer to spend the time coding instead of trying to think up something that might be useful news for the community.

That's also a difference between mikrocontroller.net and Free Pascal: the former is simply a community of enthusiastic users. They don't have a specific team that works on something concrete like we do.

May be we don't have to reinvent the wheel and ask the owner. https://www.mikrocontroller.net/contact

There is no need to ask them, cause the main point is that they use some custom forum software and website. We don't for the forum and for the website we have static pages to reduce maintainenace.

Regards,
Sven

He's talking about the help for the textmode IDE. As he wrote Lazarus includes the help, but the FPC installer does not.

Regards,
Sven

But that doesn't make it correct from a Linux point of view.

Regards,
Sven

On Oct 17, 2024 at 4:12:08 AM, Michael Van Canneyt via fpc-pascal <

This thread is supposed to be about getting new users but I hear many people still digging their heels in on these out dated elements. A 20 year old website can’t be good. No business would allow this so I don’t see how it should be different for a compiler. It’s possible new potential users get to the website and think it’s a joke and leave right then. This is what people are like in the real word and it should be taken notice of in my opinion.

Regards,
Ryan Joseph

On Oct 17, 2024 at 12:03:47 AM, Guillermo Martínez Jiménez via fpc-pascal <

I used C# for Unity quite a bit and never had any problems. That’s even with the worst case scenario for game developing that needs real time graphics. Does that power all of .NET too and all those desktop applications? It’s been battle tested many years as far as I can tell.

In 2024 you don’t need the performance of manual memory management in UI apps. Garbage collector or anything else will work perfectly well.

Regards,
Ryan Joseph

I fully agree. It is especially true for young people.

My wife creates websites for a living.
I nearly had to re-animate her after she looked at the FPC website. The FPC website is a no-go area for her since that time.

Hence my intent to re-open the debate.

Michael.

Yet, Delphi .NET was a failure. And nobody uses FPC for the JVM platform. That's why I'm reluctant to implement a .NET target, even though it's possible to do. I mean, given infinite developer time, it's cool, but I don't have that much time, therefore, .NET is very low priority.

In 2024 you don’t need the performance of manual memory management in UI apps. Garbage collector or anything else will work perfectly well.

Well, surely, you can probably use something like this with Free Pascal as well:

https://www.hboehm.info/gc/

We're eagerly waiting for your patches to make this work.

For me, it's not worth it. Calling .Free on objects doesn't bother me, nor does it make development for me any more difficult. With the built-in leak detection (-gh option), it's even easier.

Nikolay

I also agree. Unfortunately, as I said, compiler developers don't make good web designers.

Examples for bad sites (I'm repeating myself, I know):

https://gcc.gnu.org/

https://llvm.org/

But this time I'll also give some better examples:

https://nim-lang.org/

https://www.haskell.org/

https://www.rust-lang.org/

https://ziglang.org/

https://www.python.org/

Nikolay

Another example - Ada, a Pascal-like language:

https://ada-lang.io/

Nikolay

Hence the idea for a contest for actual designers...

Nice site, interesting language...

https://www.haskell.org/ https://www.rust-lang.org/

This last one is the one my bosses use as a reference when offering to fund. (does not mean it needs to be copied, just an example of a "modern" site)

Michael.

I don't write UI apps, only server apps.
Performance matters there, so a GC is not good.
We see this at times in our servers, when the GC kicks in; everything just stops.

In each case, it is a bad idea to slap this on an existing language:

a GC collected language is a complete paradigm shift from non-GC. C# and Java (and probably others) were designed with GC in mind. That it works there is therefore not surprising.

By contrast, Pascal is not designed with GC in mind. You'd need to redesign the language.

If you do that, you can throw away all existing code if you introduce GC, because the two concepts do not merge easily.

Embarcadero tried it in Delphi, and they failed. Not surprisingly, they removed again all automatic memory management.

Michael.

Ralf Quint wrote

Sorry, but do you really suggest that Lazarus should intentionally adjust itself to the shortcomings of other IDEs? Being able to move windows around over multiple (2 or 3) monitors is the most effective way to work., l

Nope. (And I do prefer non-docked myself).

Being able to do things the way you feel most comfortable doing them (and likely the way you have previously done it in other environments) =>  That is the most efficient way.
Then, if need arises to adapt, the ability to do so at a speed of your choosing.

And anyway, we have both. It is not about having the feature, but about how it can be discovered and configured.
Which in case of discovery of docking can be considered solved, as users will in future be asked anyone really leaves, because Lazarus provides a non-docked mode too... Well, that really can't be helped. And imho is not likely.

But of course there are tons of other options. And some may toggle (don't know, but likely) between how sublime versus vscode vs ... does it. So then there is no one perfect preset (there never is). The question is just, how to present those options in  a way users will find them? Or even learn they may exist, so they go looking for them.

And "learn they may exist": We got tons of cool features, and extremely few people know them (and many to whom I showed them, found them useful). Even after nearly 2 decades, I still sometimes discover new features that had been there all the time.

Also, we better do *not* just copy one specific other IDE (or other language/compiler). Maybe that would give a cheap startup boost. But it most certainly would be a dead end. We would never be able to keep up. And if one is always 2nd place (or less) then one looses. We must have our own innovations (and cuts) too (and we do, we just don't advertise those well enough).

**
In any case, it needs manpower. And that means new contributors who are willing to help. Including to compromise to something that may not be "all the way they want", but tuned down to go with the ideas of the current team .
(Some change is better than none)
**

And lastly, and without wanting to spoil the effort of becoming more "new user" friendly" (if volunteers will hopefully take that on).

We have to remember, we also do need the old users (both long term, and of higher age). There usage and feedback helps keeping things going. And while not all presets have to be "the old way", the effort to set the older style should be as minimal as possible.

El 16/10/24 a les 5:00, Hairy Pixels via fpc-pascal ha escrit:

Even if there is a market for Lazarus type apps people in 2024 don’t want to use a massive legacy IDE and prefer better tools like VSCode.

I'm biased because I've been programming in pascal for almost 40 years, starting with line editors/command line compilers and linkers (*), using clipper for the user interface (anybody remembers it? the syntax for defining input fields was way better that doing it in basic, yes, plain old ms dos basic), marvelling at what was possible with delphi (even if at the time it had no autocompletion or other smarts) then switching to lazarus 20 years ago.
So I mostly do "old style" gui applications (which, btw, have to work 24/7 unattended), but not only.
I recently had to use other ides for other languages (personal projects in C/C++), one of them VSCode and I find it a steaming pile of s*it, bloated and its "smart" features barely work (it's probably me though). Good luck trying to design a GUI with it (I think that even clipper was way better for that).
Same experience with eclipse and netbeans (I had to do some java work, ouch), again, it's probably me, but good luck designing a GUI with those (but at least the "smart" features work somewhat better). So give me a "massive legacy IDE" that actually works any day, please. I'm sure that this "massive legacy IDE" will allow me one day to design web interfaces with the same ease that it now allows me to design an "old style" gui application.

(*) programming embedded systems, so no debugger, not even writeln.

Bye

El 17/10/24 a les 7:58, Hairy Pixels via fpc-pascal ha escrit:

I used C# for Unity quite a bit and never had any problems. That’s even with the worst case scenario for game developing that needs real time graphics. Does that power all of .NET too and all those desktop applications? It’s been battle tested many years as far as I can tell.

Maybe you should give some tips to Siemens, because the can't make a decent app in .NET.
I'm referring to tia portal, a monstrous app written in C# (I think, definitely .NET), which is slow, bloated and generally unpleasant to use. Maybe it's because they only add new features that nobody needs instead of fixing bugs...

Bye

Hi Nikolay,

and are these compiler suites with bad websites short of users?

Anybody,
on the subject of llvm; does anyone know if the option of llvm back-end for fpc is ever going to make an official release?

That would be really interesting if it means fpc could be bootstrapped to new hardware.

On Debian, we build llvm on all 20 architectures, fpc for only half of those.
https://buildd.debian.org/status/package.php?p=llvm-defaults https://buildd.debian.org/status/package.php?p=fpc&suite=sid

Regards,
Peter

Am Donnerstag, 17. Oktober 2024, 03:24:07 CEST schrieb Ralf Quint via fpc- pascal:

Sorry, but do you really suggest that Lazarus should intentionally adjust itself to the shortcomings of other IDEs? Being able to move windows around over multiple (2 or 3) monitors is the most effective way to work.,

May be for you it is the most effective to work.

To exaggerate, the more monitors the better your code???

For me, at least at the moment the opposite is the case. I concentrate on a defined, clear area without any major distractions.

Of course, it is good to have the option of placing the windows on umpteen monitors. But this should not be the default setting.

Peter B via fpc-pascal schrieb am Do.,
17. Okt. 2024, 13:29:

Anybody, on the subject of llvm; does anyone know if the option of llvm back-end for fpc is ever going to make an official release?

The LLVM port has some shortcomings that will for the foreseeable future have it be a less good choice (like missing floating point exception handling if I remember correctly).

That would be really interesting if it means fpc could be bootstrapped to new hardware.

The LLVM port does not help in that regard at all, because the platform specific backends are still required for some low level stuff.

Regards,
Sven

Michael Van Canneyt via fpc-pascal
schrieb am Do., 17. Okt. 2024, 11:40:

Probably something like the std::*_ptr (shared, unique, auto, etc.) from C++ could be implemented in FPC. Main point missing for a convenient solution would be a mechanism so that e.g. classes could be accessed as is from such types (for example default fields)
A proof of concept implementation should be doable without that however.

Regards,
Sven

Nikolay Nikolov via fpc-pascal schrieb am
Do., 17. Okt. 2024, 09:16:

No patches needed:
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/libgc/src/gcmem.pp?ref_type=heads 😉

Regards,
Sven

I have one provided by a colleague that is a C++ jedi... I planned to put it in types.pp, since the implementation is ridiculously small and depends on nothing.

Michael.

Blödsinn, und dass weisst Du auch selber.
No, more monitors don't "make code better", but having two or three monitors makes the debugging/testing task much more efficient...

Maybe you are then one of those code m*****ys that just crouch over their overpriced lightweight laptops with a fruity company logo. Your "clear defined area without any major attraction" idea goes out of the window as soon as you have to refer to your project documentation while you're programming. Or testing/debugging.

Ralf

Hi all,
Interesting discussion that was bound to happen at some point.

As a long-time (+30 year) user of the language and many years of FreePascal and Lazarus, I did not mean to pile on too much, but it looks like I may. Sorry.

From what I read so far, my views match well those of Nikolay and Luca. Maybe age has to do with it or that my projects are rarely GUI apps and mostly low-level API programming where I barely make use of generics and where try to avoid classes and managed data structures as much as possible. I value less the looks and new language features but more the low-level programming power, the stability of the compiler, build tools and the the accuracy of the documentation. I am very grateful that FreePascal and Lazarus do exist, as imperfect as they may be!

My higher level, less API-oriented, dynamic programming needs are currently met by the Python+VSCode combination as we gave up on NodeJS a while ago. This also matches the needs of many of my students that are doing data analytics, data visualization and occasionally simple GUI apps, employing rather cumbersome tools based on quirky frameworks such as Tk and maybe Wx. Here is where RAD tools are helpful and why some may take a liking to C#. But as much as I would like them to, many I know are less likely to program embedded devices or to build low-level or complex GUI applications that need to squeeze every ounce of performance. Yet to me personally the need of low-level programming remains relevant. This is why I would still prefer a stable fpc compiler with macros, build tools and easy to configure targets, similar in power to gcc but hopefully less cumbersome and with faster compile times. It would also form a solid enough foundation to allow many other things to be built with it.

Stefan

Michael Van Canneyt schrieb am Do., 17. Okt. 2024, 14:37:

Does it have tests as well? Otherwise that sounds good 😁

Regards,
Sven

They were trying to make know a new interesting product, not to resucite an almost dead language.

Pascal opened the path with structured programming and hard typed languages.

But most languages nowadays are hard typed: Java, rust, go, c#, swift... c is here to stay, but modern language got rid of c-like types byte=char=bool=everything. In fact modern development uses tools to control types in c and c++.

I'm sorry to say than other language are better, handier without sacrificing security and readability.
A few points:

* Concurrency as part of the syntax of the language
* Declaring a var when you need it
* Tuples, so easy to return two values
* Some functional programing

And all those languages are backed by big corporations.

Lazarus is for Delphi nostalgic guys, like me. I'm sure 90% of Lazarus users have worked professionally with Delphi before.

Op 17-10-2024 om 09:10 schreef Michael Van Canneyt via fpc-pascal:

The discussion back then was about adding a CMS for more timely updates, as that was the other problem of the website.

But while a CMS might be slightly easier (but be a drag in maintenance), adding new items to the site is not THAT hard, ergo, the problem is in the content generation, not the website.

It is the same problem with the documentation (as in contributions from people other than you and few contributors like Don), the tools are always blamed, but the real problem is that nobody really bothers.

Hi there,

I'm doing my part by creating a Cookbook (along with an intro to FPC and snippets).

https://ikelaiah.github.io/free-pascal-cookbook/
https://ikelaiah.github.io/free-pascal-cookbook/docs/basics/intro-objpas-fpc/

Regards,
Ikel

On the contrary, I've used some of the so called "modern" languages and found them to be inferior to Pascal in some regards. Especially, if you include things like runtime performance, compilation speed, IDE experience, ease of writing code, etc. I've used C, C++, Java, C#, Nim, Rust, Python, JavaScript. They all suck. C# and Nim come close to being good, but still have drawbacks.

C# is slow and bloated and I don't like the fact that it forces you to use classes always, like Java. On the other hand, C# has an excellent IDE experience, but only for Windows.

Nim is nice from a language design point of view, however it has slow compilation speeds (compiler generates C code), bad IDE experience (VS Code plugin), bad debugger experience (compiler generates C code, debug info is generated for the C code, not the Nim code), not a lot of libraries (and they lack stability), not a very stable language (new versions break compatibility, especially major versions), not a very advanced OOP support (supports inheritance and virtual methods, but e.g. no interfaces), the module system is also inferior - no interface and implementation parts, no way to tell if something is a unit, or a program, etc. The powerful macro system is a pro, but also a con, because it's so easily abused by bad programmers.

The other languages are not even worth discussing, IMO. I know Rust has a lot of fans. I've been writing Rust professionally for almost a year now, and still find it to be one of the most unpleasant languages to write code in. The borrow checker is certainly not something I want to see in other languages. Anyhow, it's a feature that is very unlikely to creep into Pascal, IMO. If I have to do manual memory management, I prefer Object Pascal's explicit way, instead of languages that hide it for you (by using the RAII idiom or the borrow checker), and then still expect from the programmer to fix things, when the automatics fail.

A few points: * Concurrency as part of the syntax of the language

What do you mean? Do you mean stuff like OpenMP or is it something else?

* Declaring a var when you need it

Not a huge fan, but AFAIK latest Delphi has it, so we probably need to support it in FPC. Anyhow, it's 's not some "quality of life" type of issues, like the slow C++ compilation times, or the encouragement of buffer overflows. When I need to use a local var declaration, I usually consider that my procedure or function has become too complex and split it into nested procedures. Also, Lazarus declares the variable automatically for you, when you press Ctrl+Shift+C, so it's even less of an issue. You just write:

i := 1;

Or:

for i := 1 to 10 do

You then move the cursor on top of "i" and press Ctrl+Shift+C and it declares a "i: integer" automatically in the local var block. And yes, it does automatic type inference.

* Tuples, so easy to return two values

Nice in theory, but I've used tuples in other languages and always hit some roadblock. For example in Rust, I've had to switch from using tuples to using structs several times, because of some language quirks, that doesn't handle tuples somewhere. Anyhow, the lack of tuples is only cosmetic, it's not a serious "quality of life" issue. It's easy to declare a record type with two elements, or an array.

* Some functional programing

Not a huge fan of functional programming either (out of the big three - procedural programming, object oriented programming, functional programming, I consider functional to be the least useful - worst in performance, does not map well to how the CPU works, is elegant only for a very restricted set of tasks), however FP features are coming to FPC as well, for example FPC trunk supports anonymous functions.

Not me. I really think Free Pascal is an improvement over many "modern" languages. When I say some of the issues are not "quality of life" issues for me, means that I would never trade things like 10 times faster compilation speed or the runtime speed for something like tuples or having the ability to declare vars everywhere.

Nikolay

Hi,

Maybe it was mentioned in the thread, I just glanced through it, but how about ARC (Automatic Reference Counting), Objective C style? To be honest, I really liked that, and we already have it kind of in place for strings, even temporary strings and maybe even temporary arrays created inside a function. We'd just need to extend it for a bunch of other things, I suppose. Manual FreeAndNil() is the ugliest part of Object Pascal for me for sure... OTOH, for Object Pascal you might end up with RAII in this case, instead of ARC, because how how the language works. I did not like it that much in C++, but maybe because modern C++ syntax is properly horrid...

But anyway, that concept replaces GC for a majority of use cases, and I really liked it for the couple of years I've been doing iOS stuff. But of course Apple adopted it for all the underlying classes too, which points back to the fact, that modern languages are usually a thin wrappers around some library concept, and if your library API is as full of legacy and as inherently messy as ours, there's little you can do.

For once, I'd be really glad if a bunch of the containers would be Thread-Safe by default, like TList and things, and they aren't, because they're based on almost 3 decade old Delphi concepts, when multithreading wasn't as big of a deal as these days. No amount of "lets add GC" would fix this. (And I know we have thread-safe alternatives, but they aren't used everywhere and consistently. So when using a bunch of libraries, you still end up managing thread-safety by hand...)

Charlie

Op 18-10-2024 om 10:41 schreef Karoly Balogh via fpc-pascal:

Delphi tried and failed.  IMHO it was also messy with all the "weak" attributes.

I think it is better that people wanting GC go for the backends that implement GC.

Reference counting already exists, if all your objects are accessed through interfaces. Then you just inherit from TInterfacedObject and you're good. I used this approach in PTCPas and it works well. I wonder why it's not used more often.

There are also advanced records, which support implementing reference counted smart pointers, RAII-style objects, etc. It's just that there are not ready made implementations in the standard library. However, the language already supports them. I used advanced records for the Unicode support for the video unit, to implement TEnhancedVideoCell in a way that conserves memory, by overlaying a WideChar and a WideString. Since most graphemes are represented by a single Unicode code point, that falls in the BMP, it fits in a single WideChar, so there's no need to allocate extra memory on the heap for a WideString. However, to support all languages, we need to support graphemes, represented by a sequence of code points (e.g. non-BMP characters, combining characters), so for them, a WideString is allocated on the heap. See the implementation in videoh.inc and video.inc, if you're curious. This means we have all the power of C++ objects, without the ugly parts (no multiple inheritance of classes and the "diamond" problem).

Btw, I usually don't mind calling FreeAndNil() myself, most of the time, objects have a clear ownership, so an object creates the objects it owns in the constructor, and destroys them in the destructor. For the more complicated cases, there are the options, mentioned above. I've used them very few times, but when I needed them, they were there.

More modern container libraries, using generics, RAII, or whatever else are always a good idea, but AFAIK there are already some decent TList alternatives in the RTL and packages (fgl, rtl-generics)? It's just a matter of learning about them and getting used to using them.

I think we should start using more modern (generics-based) containers inside the compiler sources itself, but that's another story, that only concerns compiler developers, not users. :)

Nikolay

Hi,

Just because Delphi failed at something... Doesn't mean we couldn't succeed. :P Or do it right. But anyway, it definitely serves as a big fat warning sign, I do agree in that.

I think it is better that people wanting GC go for the backends that implement GC.

No argument there.

Charlie

And, I am glad they are **not** used everywhere by default.

I want to control when and where my threads interact with other threads. And anywhere else, they are to access only data that is not shared (including any list that they use, outside the zones I designated for sharing).
So no list (of my own, or any 3rd party code), in no thread of mine should manage that on its own. I will do so, as I see fit for the context of my app.
(That doesn't mean that I object to the existence of such list as alternative, that can be used wherever it is seen fit)

Of course, that means no 3rd party code must introduce global vars. If it does => bad.

I agree with Martin. Threading should always be optional.

But to have a set of 'primitive' classes (lists etc.) that handle threading in SyncObjs would be good, though.
So people do not have to re-implement them themselves.

Michael.

Op 18-10-2024 om 11:23 schreef Karoly Balogh via fpc-pascal:

Python also uses reference counting (or at least did before the most recent version), and it was often blamed for its bad performance.

Reference counting has two problems:

1. as soon as you duplicate references you need to use helpers. This can already be seen in ansistrings, but at least by ansistrings it saves (some) deep copies of the string contents (compared to shortstrings)

2. These helpers are also in runtimes, so you can't make it optional.

3.  If you have nestable objects, you risk cycles. Defanging that is also complicated and costly.

The weak modifiers for references try to cut down on both cases, but it is a manual bit.

Personally I don't need GC nor any web or easy deployment for most of my work, but I would either have the whole hog (safe, generational, movable, i.e. a GC on  scripting language level), or manual witth maybe something like shared_ptr for special cases.

But most importantly, since this thread is all about newbs, that is what they expect if they , not some halfway beast.

Note that this is already Embarcadero's second halfway attempt, after Delphi.NET that iirc tried to declare all classes IDisposable, which frustrated the GC and caused heaps to cut out the middle man and go for C# directly.

> I think it is better that people wanting GC go for the backends that > implement GC. No argument there.

Or Pascal.NET, component pascal or one of the umpteen others.

My motivation is that it is then the whole hog above, not something two wings duck taped to the back of an elephant.

Am Freitag, 18. Oktober 2024, 06:37:59 CEST schrieb Nikolay Nikolov via fpc- pascal:

I agree with all your statements.
If we can make it easier for new users then they will use it more.

Op 16-10-2024 om 23:49 schreef James Richters via fpc-pascal:

3.4.4 will swap the PDF helpfiles for CHM in the windows installer.

One way to attract new users is create great software applications with FPC for the world to see.

Thomas Young

Am Freitag, 18. Oktober 2024, 14:02:15 CEST schrieb Thomas Young via fpc- pascal:

One way to attract new users is create great software applications with FPC for the world to see.

https://klimaregelung.de/pages/deutsch/software.php

On Oct 18, 2024 at 3:41:49 PM, Karoly Balogh via fpc-pascal <

The compiler already has all the plumbing for implementing this but they would need to agree to a new class type which includes has the same ref counting as AnsiString, Interfaces and other types. I mentioned this multiple times but Sven objected to it stating he already tried and uncounted some edge cases.

I think an entirely new class type would be required and that’s where the resistance came from. Sven can refresh us on this if he wants.

Regards,
Ryan Joseph

Rainer, did you create this application with FPC? Please provide more information about its development.

Thomas Young

I'd like to point out that the main reason for using Lazarus is for ease of use when programming, keeping track of source files and the like.  Unfortunately, Lazarus is not very user friendly to screen reader users, and (as far as I know), it never has been.

That eliminates a small but significant number of users right out of the gate.

Another problem is the fact that these days, nearly everything is pushing online, connected systems, and this kind of app is a nontrivial exercise on FPC.  I struggle with this every time I want to make an application that talks to other servers, because (as mentioned above) I can't use lazarus, and there are precious few examples of this kind of thing that comes with the FPC install.  There are a few examples of tcp/ip code, but they are overly simplistic, and don't really show the whole server/client dynamic most folks are looking for these days.

I'd wager that's a large part of the reason why fpc isn't getting more use.  Even those of us that want to use it for development struggle to do relatively simple things if we're not using lazarus for our development environment.

Sometimes, folks just want to integrate their pascal development into their current tool chain, and there's nothing wrong with that, but not using lazarus knocks off a large portion of the capabilities that can be showcased when someone new starts using fpc for their development.  We really need more sample/example code showing how things are done w/o lazarus to pick up the slack.  I think that more than anything else would go a long way to helping adopters stick with fpc as a development environment.

Also, I see very few (if any) examples of how to generate GUI apps when using fpc commandline compiling, (again, without lazarus in the mix).

This also makes for complications.  I almost always have to use powerbasic on windows, and java on other platforms if I want a decent gui, since there are very few tools for generating Graphical interfaces if you're not using the default development environment, (fpc is not the only culprit on this one).

With java it's easy, I just use the grid layout, and poof, it's all handled for me, I don't have to worry about where to put things on the screen.

I don't know how to mix java with pascal, like I do with C, I can generally generate the gui with java, then use another language for the backend items.  I have no idea how this can be done using fpc.

Generally though, I avoid gui entirely on platforms other than windows, since powerbasic makes gui generation simple, just by creating elements, and placing them anywhere I like.  I know this can be done on fpc, but again, zero examples are included with the distribution, and any searches I've done all turn up lazarus code for doing these kinds of things, which is not ideal.

That's my take on it all, from a different perspective,  Feel free to use/ignore as is your want.

Hairy Pixels via fpc-pascal schrieb am
Fr., 18. Okt. 2024, 17:21:

The problem is that we can't simply introduce reference counting for existing classes, because that would lead to memory leaks in existing codes, because that might have cyclic references.

This would mean that a new class type or some kind of additional attribute would have to be introduced which would have to be incompatible to non-reference-counted classes as otherwise there would be the chance for memory leaks or use-after-free again. This in turn would mean that essenentially the whole class hierarchy would have to be reimplemented.

And that whole shebang is just not worth it. If someone wants a full ARC language then simply don't use Object Pascal.

Regards,
Sven

On Oct 19, 2024 at 2:31:36 AM, Sven Barth via fpc-pascal <

You just only adopt it when you want it or in new programs entirely. Remember we’re talking about new users with no programs wanting to start fresh.

And that whole shebang is just not worth it. If someone wants a full ARC language then simply don't use Object Pascal.

What’s the appeal to new programmers with this attitude? FPC already has ARC on a few types so it stands out the classes are excluded. They don’t care about backwards compatibility of course. New programers will look at this and go for the full ARC language which is easier or go to C/C++ if they want performance and lots of libraries/resources.

Regards,
Ryan Joseph

Hairy Pixels via fpc-pascal schrieb am
Sa., 19. Okt. 2024, 03:18:

You don't get it, do you? It's either all or nothing. Because otherwise there *will* be problems.

New users might not care about backwards compatibility, but existing ones do. We are not helping us if we scare away many existing users to get a few new ones. If they want ARC/GC or high performance then those users should simply go somewhere. One can't cater to everyone and thus we should stick with what made Pascal strong, not chasing after some dreams.

Regards,
Sven

Den 18.10.2024 14:02, skreiv Thomas Young via fpc-pascal:

One way to attract new users is create great software applications with FPC for the world to see. Thomas Young

https://peazip.github.io/

https://cudatext.github.io/

You are not taking the reasoning to its logical conclusion.

These "new users" will want to have some standard library - the RTL and packages.

So the whole rtl/packages needs to be recreated if you introduce this, for the reasons that were mentioned by Sven.
Reasons that were already voiced 20 years ago, by the way.

You are in effect redesigning the language, and inescapably need to redesign the rtl/packages as well. With all the backwards compatibility issues added on top, because we do not have the manpower to maintain 2 RTLs.

So, regardless of the question whether the ARC is good/bad, it should be obvious that this complete rewrite of literally everything is simply not an option.

Therefore the whole "ARC in FPC" debate is simply moot: It's not going to happen.

Not because ARC is a bad idea (it may well be), but because it is not realistic to do so, even if we wanted to.

As a corollary, the conclusion is that if you want ARC, you should indeed use another language.

I regret that this is so, but I think this really is the unavoidable conclusion.

Michael.

Which IMHO, means another (potentially drastic) downside.

If it would be possible and would be done, you end up with 2 incompatible products. That would mean you split the community into 2 groups, each group smaller than the current. Effectively immediately downsizing the amount of users (in each group).
Even if you gain 20% new users (and I find that more than optimistic, I would guess more like 5% tops, if we are lucky), and then split unevenly 60/40 => the larger of the 2 new communities will be at 70% of the current size.

The amount of sample code will be split, and not only that, but similar looking samples will be all over the place, but wont work, often even crash, because they are for the "other fpc". Users will give up on examples, because they don't work.

IMHO, this is a sure way of harming the project.

Of course, that said, I can not predict the future. Anyone may think entirely different. Anyone may assume completely different numbers. Oh, I am sure there will be someone promising a much bigger amount of new users to come from that. Well, while I can't predict the future, I can learn from the past. Such promises have been around for a long time, and whenever (99% of cases) by coincidence the requested feature was added, the promise has not been fulfilled.

On Thu, Oct 17, 2024 at 10:08 AM Michael Van Canneyt via fpc-pascal <

Skip the debate and use your own vision and judgement to do it well. Most developers are geeks and are no experts in attractive web sites. You apparently have knowledge and skill in your family. You even get funding. After you publish a new web page, some people will give feedback and more ideas. Before that a forced empty debate is just a waste of time.

Juha

On Oct 19, 2024 at 3:35:25 PM, Michael Van Canneyt via fpc-pascal <

Yes all the RTL would need to be redesigned and all the manual frees removed. I don’t think it’s THAT difficult honestly to make that work, just loads of precious of time.

The bigger problem though is now everyone is forced to use ARC on new projects and the old RTL is frozen in time. This is very bad of course and deal breaker.

This is probably why C++ did smart pointers. Doing those right with Pascal is even harder than C++ due the predeclared variables. I’ve played with the management operators and they still have problems, most of all is the default property which has been discussed for over 5 years with no progress.

So right now if you wanted a low level compiled language to learn and you want some memory safety you’re still going for C++.

Regards,
Ryan Joseph

On Oct 19, 2024 at 4:26:51 PM, Martin Frb via fpc-pascal <

this is a very good point. The splitting of the RTL is a deal breaker too. Unless it was possible to turn it on and off with a compiler directive and make very minimal code changes it’s off the table.

Regards,
Ryan Joseph

Hairy Pixels wrote

The bigger problem though is now everyone is forced to use ARC on new projects and the old RTL is frozen in time. This is very bad of course and deal breaker.

Who is forcing *everyone* ?

To the day, that person has not knocked on my door. Am I the last free (not forced) person on the planet?

And actually: ARC, are we talking the simple version => just a refcount, and it will fail as soon as you have circular refs? Or the complex system, that needs to do more involved checks, and may at times take more time?

Because if the latter, well I know some people who would shot the person introducing that in a high performance software...

Actually, if we are talking safety (rather than comfort for the developer) then we may not need freeing memory is not the only (nor biggest?) worry. Running out of mem (and handling it gracefully, and without vulnerability)  is important too. But ARC doesn't solve that.
One way to solve that is pre-allocate any mem that may be needed, and then never free or alloc any mem thereafter. And then you need no ARC at all.
And then counting references is just an unnecessary overhead.

So how does something become a deal breaker, if it should not be needed at all?

On Oct 19, 2024 at 7:24:15 PM, Martin Frb via fpc-pascal <

I mean if there are two version of the RTL to be maintained then you get stuck with the old version or you must upgrade your entire project to ARC. It’s very heavy handed like that. This is of course assuming upgrading the RTL is as easy as internally disabling free calls. All the container classes need to call finalize instead of free now but is possibly a huge disaster.

Regards,
Ryan Joseph

On Oct 19, 2024 at 7:37:15 PM, Martin Frb via fpc-pascal <

yes it’s bad except for UI apps which is what FPC and new users seem to be focusing on. FPC has it already on some types which are widely used.

FPC sadly has no concept of custom allocators for classes, just something you can add to the type itself but that’s very limited. I really like how Jai and Odin have added allocators in as a core part of the language and library. Zig does something like this too but it’s much more clumsy and tedious.

Regards,
Ryan Joseph

Am Samstag, 19. Oktober 2024, 14:20:45 CEST schrieb Hairy Pixels via fpc- pascal:

So right now if you wanted a low level compiled language to learn and you want some memory safety you’re still going for C++.

I feel very safe with freepascal. I don't know what you are talking about. It depends on the programmer who is in front of the computer.

On Oct 19, 2024 at 7:53:14 PM, Rainer Stratmann via fpc-pascal <

We’re talking about new users and programmers that don’t have 25 years of experience with manual memory management. All news languages have some form of non-manual memory management where you don’t have to worry about memory leaks and double-frees etc.. leaving Pascal behind. That’s all I’m saying.

Regards,
Ryan Joseph

Hairy Pixels via fpc-pascal schrieb am
Sa., 19. Okt. 2024, 14:20:

It's an unnecessary maintenance burden, because the current RTL (and packages) needs to be kept as well for backwards compatibility. Anything that compromises that will not be accepted, because this is one of *the* strengths of FPC. As Michael said, we will not maintain two RTLs.

This is probably why C++ did smart pointers. Doing those right with Pascal

is even harder than C++ due the predeclared variables. I’ve played with the management operators and they still have problems, most of all is the default property which has been discussed for over 5 years with no progress.

Smart pointers or more precisely "external reference counting" is the way to go. And for it to simply work "default properties" or something similar is not even needed only if we want to reduce typing. And predeclared variables compared to C++ is also not a problem.

Regards,
Sven

NOTE: the below is NOT about ARC. It is about the implication that ARC == Safety (in the environment that we have)
----------

But if you are talking about memory safety for new users, the ARC is a drop in the ocean. Sure it might catch some cases...

And, if you add that every variable needs to be initialized safely by the compiler, then it catches yet a few more. And at the same time you yet again make the compiler less useful for other projects, that are better off without this. So you don't gain users, you just change which users you have...

But, also it still isn't save. You can still do
   MyObj := TFooClass(Other.Tag);

And since examples exists, new users will do...
And then, it still goes wrong.

So remove all pointers, all typecasts, all ....
If you remove all typecasts, then why have types?

Only then we have an entirely new language...

Am Samstag, 19. Oktober 2024, 14:57:32 CEST schrieb Hairy Pixels via fpc- pascal:

Sorry, but if you start then you start with a simple program and then you have to gain experience over time. That is the same case everywhere.

There is a german sayword "Es ist noch kein Meister vom Himmel gefallen".

No master has yet fallen from the sky

What you want causes much work and is not easy at all if I understand it right. I did not read all the details.

Hairy Pixels via fpc-pascal schrieb am
Sa., 19. Okt. 2024, 14:49:

For UI apps it can also be bad depending on the performance impact.

For a class one can override NewInstance and FreeInstance. And with TVirtualMethodInterceptor (I think not yet implemented in FPC) it might even be possible to replace these on an existing class type without inheriting from it. I have not tested that yet, but it *might* work.

Regards,
Sven

On Oct 19, 2024 at 8:10:02 PM, Sven Barth via fpc-pascal <

This isn’t good enough though. The idea is you have multiple allocators for different life times in your program and allocate each class from one of those. A type based allocator is global for all classes and while you can push/pop allocators in scopes this isn’t thread safe.

Regards,
Ryan Joseph

On Oct 19, 2024 at 8:06:44 PM, Martin Frb via fpc-pascal <

Not following "in the environment that we have”. I’m just saying manual memory management is hard and bug prone which leads to crashing. New programmers are not usually keen on taking on this burden when they have easier solutions which let the compiler automate the hard parts.

Regards,
Ryan Joseph

You're exaggerating severely. Manual memory management is not that hard and not that bug prone. It has a reputation of being hard, because of the flaws in the popular C language (like char* strings and arrays without range checking), which Pascal doesn't have. And programs, written in the so called "memory safe" languages in practice crash just as often, if not more often. On top of that, they're slow.

Nikolay

On Oct 19, 2024 at 8:06:56 PM, Rainer Stratmann via fpc-pascal <

All true but if the compiler can make your life easier then new people will be going that route. Manual memory management is a thing of the past I think it’s safe to say.

Regards,
Ryan Joseph

Well, I replied to "memory safety" from

Hairy Pixels wrote

So right now if you wanted a low level compiled language to learn and you want some memory safety you’re still going for C++.

The problem with "new user want..." is that we don't have that date. But also, more important, even if some of our assumptions are right, we don't know how many of those will stay "programmers" at all.

It is easy to try some coding, when you have a language that (seems to) do everything for you. And you get some quick nice looking, but little functionality apps. But if you want to continue from there, you need to dive deeper. On that basis, you will reach a point were you can't go further.

If this is about getting more users, then it doesn't help attracting people who will stay only a few month (and would do the same on any other environment).

I don't disagree, that there are bits and pieces that could help. But not every "new user wants" will really increase the amount of users.

And then, many of those that will be more long term dedicated could equally (if not better) be helped by creating tutorials (video and text), and other helpful info. So lets go there first. Because there are a lot more people who have enough skills to do that, and who could put in the manpower, and save the core team from needing to spent time on it.

Exaggeration. Calling .free is not hard. Nobody complains about e.g. having to close files or sockets, after use. It's the same with memory.

Manual memory management is a thing of the past I think it’s safe to say.

No, it's not. The GC languages are just a tiny layer on the top, scripting things. All the performance critical work underneath is done by languages, that compile to native code and use manual memory management. Take a look at the source of your kernel, your GPU drivers, your graphics environment, or your browser. These aren't getting rewritten in a GC'd language anytime soon.

Nikolay

And yet, I recall that only a few mails back, you yourself limited ARC/GC to desktop apps.
To which, btw, others already replied, that even there it can cause performance issues.

So, I disagree.

Hairy Pixels via fpc-pascal schrieb am
Sa., 19. Okt. 2024, 15:14:

You didn't understand what I wrote. Assuming what I thought up works, it would be possible to replace NewInstance and FreeInstance *per instance* as desired.

Regards,
Sven

Am Samstag, 19. Oktober 2024, 15:34:48 CEST schrieb Hairy Pixels via fpc- pascal:

I really can not see where beginners have to struggle with memory management. If a project gets bigger you have to think about it, yes. It depends on the coding style. In my project I wrote my own memory management for the webserver. It took me 3 weeks of work.

On Oct 19, 2024 at 9:15:10 PM, Rainer Stratmann via fpc-pascal <

I didn’t mean to get into a big flame war over this and debate the merits of both I’m just telling you what I see in the industry and trends in programming. This isn’t the only thing either just one of the larger ones.

If you really want to know then FPC should conduct a survey and see what users say. Ask existing users and try to reach out to other programmers too.

Regards,
Ryan Joseph

Counterexample 1: The growth of Rust.

Counterexample 2: Pascal is also growing.

Counterexample 3: The amount of C and C++ code your computer is running.

GC is only used as the top "scripting" layer, everything else is C++. Every pixel that you see on your screen, every animation, all of this is done by C or C++ code. Rewriting all of this in a GC'd "memory safe" language will result in your computer becoming slow as a snail. Moore's law has been dead for some time, so this situation is here to stay.

If you really want to know then FPC should conduct a survey and see what users say. Ask existing users and try to reach out to other programmers too.

I could easily predict that the majority of FPC users don't have a problem with manual memory management.

Nikolay

On Oct 19, 2024 at 9:37:49 PM, Nikolay Nikolov via fpc-pascal <

wrote: Counterexample 1: The growth of Rust.

which is the opposite of Pascal, total memory safety. Rust is one of the reasons that show people don’t want bug prone manual memory management anymore.

Counterexample 2: Pascal is also growing.

Then why are we talking about new users? I thought Pascal was getting smaller every year.

I think FPC is closest to C++ in spirit but less powerful and easier to use. That’s maybe where new users could from.

Regards,
Ryan Joseph

Regarding Memory Management

Its possible to write a Pascal program w/o any pointer, but it may be not elegant and interfaces to some C-like GUI structures, as used in all common OSs, are impossible.

But, I am using Borland Pascal (sic!) and also FreePascal (no Lazarus) for small embedded system for over 25 years now w/o any pointer.

Code is sometimes ugly, but it is (proofed by reality with many different projects) hard rock stable for 24/7/365 applications.

Maybe I am wrong, but afaik, procedural programming w/o objects and pointers requires no add. memory management.

The size and memory location of all variables is fixed. And, yes, of course, you have to care about an array access, but $R+ is your friend.

See: N. Wirth Algorithms and Data Structures chapter 4.2:

"A further consequence of the explicitness of pointers is that it is possible to define and manipulate cyclic data structures. This additional flexibility yields, of course, not only increased power but also requires increased care ("erhöhte Sorgfalt" in the German ed.) by the programmer, because the manipulation of cyclic data structures may easily lead to nonterminating processes.
This phenomenon of power and flexibility being intimately coupled with the danger of misuse is well known in programming, and it particularly recalls the GOTO statement."

So as in real life: the price for freedom is increased care!

I am awaiting your shitstorms......

Markus

And totally the same as Pascal in the lack of garbage collection. Your second sentence is inaccurate. It should be: Rust is one of the reasons that show people don't want C++-style memory management anymore. Rust was developed by Mozilla to replace their C++ code base. The original goal was to rewrite Mozilla's browser engine in Rust. This plan was, however, abandoned, so in a way, Rust has failed in achieving its original goal. However, most Rust developers come from C++ background, not Pascal. The problem with Rust is it imposes a memory model (a simple linear passing of memory ownership), that is not suitable for a lot of software projects. My impression is that Rust programs are more bug prone, compared to C and C++ programs. This could be explained by the fact that the language is new, and thus, it contains a lot of new code, and new code is less well tested and contains more bugs. However, from my experience from writing Rust, I'm of the opinion, that Rust's so called "memory safety" guarantees don't result in less buggy code. In fact, the constraints of the borrow checker force people to use design patterns that introduce whole classes of other bugs. I can talk about it for hours, giving concrete examples, but it would be off-topic for this list.

Your impression that Pascal was getting smaller was not supported by evidence. On the contrary, download statistics were provided, showing that the number of Free Pascal downloads has been increasing in the past 10 (or 20? I forgot the exact number) years.

Of course, that's not a reason not to make improvements that attract new users, but they need to be grounded in reality, instead of fantasy.

Easier to use, yes. Less powerful in what way? Where new users are coming from is an interesting question, actually worthy of a survey. Maybe we should do one?

Nikolay

Am Freitag, 18. Oktober 2024, 18:11:54 CEST schrieb Thomas Young via fpc- pascal:

Originally it was started around 1990 with QuickBasic, then 1991 or 1992 moved to Turbo Pascal when it still wasn't very big. Inbetween there was another compiler and around 2005 it moved to Freepascal.

Sourcecode now:
- 4MB, 120.000 lines, about 100 units
- build in server written from scratch (which is not very difficult)
- own memory management for the server
- the software runs 24/7
- more than 100 clients use it
- runs on a debian linux os x86 system
- plain screen 800 x 600 pixel or in a window (windows, kde) which puts the 800x600 bitmap to the window
- minimum dependencies, nearly everything I wrote myself (serial unit,graphical output, browser access, etc.)
- very close to the operating system
- if an update is available all the clients have to do is to press an update button, all data structures (if they change) are updated automatically

Travis Siegel wrote

Also, I see very few (if any) examples of how to generate GUI apps when using fpc commandline compiling, (again, without lazarus in the mix).

There is a modernised version of TurboVision out there:

https://github.com/magiblot/tvision

It's aimed at C++. Would it be possible to adapt that, or integrate with it?

It's Windows/Linux cross-platform already.

Liam Proven via fpc-pascal schrieb am
Sa., 19. Okt. 2024, 21:05:

We already have FreeVision which the textmodewis using and which is even Unicode-capable in main. If anything is missing then that should be improved/fixed instead of porting another one.

Regards,
Sven

No shitstorm from my part :-)

I am working with Pascal, C and other programming languages (PL/1 for example) for more than 40 years now,
and I am thinking sometimes about what makes programming languages secure or insecure - or: what are the
common reasons for runtime errors?

Some observations:

1. a big problem IMO is the null-termination of C strings (or: the possibility to use it or not use it, say: memcpy). This C paradigm often creates hard-to-find runtime errors; languages, which operate on fixed-sized strings or
strings with length fields like PL/1 varchars don't have this problem and are more secure

2. Automatic checking of array bounds should always be enabled, and I prefer languages that support this (like Pascal
and PL/1, for example).  For example: in the 1980s, I translated a large Fortran program to Pascal, and I suddenly
observed how many bounds checking errors still remained in the Fortran program (although it was in production use
for 4 years).

3. Standard Pascal has only pointers, which point to the heap and are created by the NEW procedure.
I am the maintainer of another Pascal dialect (Stanford Pascal) - and, like many others, I have an ADDR function
which allows to assign the address of a stack variable to a pointer (and pointer arithmetic and so on).
So this may look like pandora's box, but IMO this is needed to write useful programs - and it needs to be done carefully, of course. Run time errors are created by using uninitialzed pointers etc.; but that's not much different from using
ANY OTHER variable without initialization. We have no protection against this with current platforms.

4. This said, missing initializations are another major source for runtime errors. I am working much on IBM mainframes. IMO, a big part of the "stability" of the mainframe platform comes from the fact that on this platform
many programs (written in COBOL and PL/1) work with DECIMAL data, where uninitialized variables
(with hex zeroes) are NOT VALID and create runtime errors, when referenced. In constrast, with binary
variables like integers, every bit pattern has a meaning, and you never get a runtime error when
referencing a variable which has not been initialized. With some historic platforms like the Telefunken TR440
machine, you had the possibility to initialize the stack frames with a bit pattern that always creates runtime
exceptions when you referenced uninitialized data ... this was possible because of the storage tags the
Telefunken machine had. If you referenced uninitialized data (even integer), the Telefunken machine
produced a runtime error, called "Typenkennungs-Alarm". Unfortunately, such concepts of the 1960s
and 1970s didn't survive.

5. My observation regarding C++ versus C: we once added C++ components to a large C software package
(insurance math). The C++ evangelists told us that we would get more security (among other goodies).
But what we observed after some months or years: in the C++ area in almost every release we had
hard to find memory leaks (the application requiring more and more memory until hard stop).
It took us advanced tools like ValGrind or special diagnostic memory managers (from IBM)
to diagnose and repair the C++ functions which were the culprits.

My summary:

- Pascal - by language definition - is much better in this respect than C or C++
- Garbage collection doesn't really help and makes things slow (counter example: in my Stanford Pascal,
when working with strings, for example concatenation etc., this is done in the string workarea,
and the temporaries there are garbage collected at statement boundaries ... this is necessary and
cannot be avoided)
- to write useful programs, you occasionally need pointers and functions operating on them
(using explicit lengths, maybe) and you have to take care, when using such functions

HTH, kind regards

Bernd

On Oct 21, 2024 at 7:54:22 AM, Bernd Oppolzer via fpc-pascal <

FPC can take a pointer to stack memory. I don’t understand what the difference is with the ADDR function.

then isn’t Pascal’s requirement to predeclare uninitialized variables the worst possible design? In C you can at least declare a variable with its assignment in one step but with Pascal by design you can always read uninitialized memory with the exception of arguments.

Many bugs I’ve caused because I didn’t set the “result” of a function for example. I wish they could make that an option to always set the default value.

Why did the smart pointers and RAII help? FPC does nothing to help you manage memory so I would expect more leaks. Being able to declare classes on the stack and destroy automatically automates away a big category of memory leaks right there.

Regards,
Ryan Joseph

Free Pascal produces warning for uninitialized values and has an option to treat warnings as error. My advice is to compile your programs with -Sew

FPC does nothing to help you manage memory so I would expect more leaks.

It's not nothing. There's:

0) built-in leak detection with the -gh compiler option

1) ansistrings, widestrings and dynarrays

2) record types (as opposed to class), which can live on the stack and have a pass-by-value semantics. FPC trunk supports advanced records, so you get C++-style copy constructors.

3) the object type also has pass-by-value semantics

4) interfaces are COM-like and reference counted by default. Every interface inherits from IUnknown and the compiler automatically inserts calls to AddRef() and Release() when a variable enters or leaves scope, or when assigning values, or when passing them as parameters. If your class is only accessed through interfaces, you can just do:

type

  TMyReferenceCountedClass = class(TInterfacedObject, IMyFirstInterface, IMySecondInterface, ...)

Being able to declare classes on the stack and destroy automatically automates away a big category of memory leaks right there.

You can't with classes, but you can with records, objects and static arrays, which are usually more appropriate in these cases.

When using classes, the proper way to use them is to design them with some sort of ownership relations between them. For example ClassA contains a ClassB, so ClassA is responsible for creating ClassB and destroying ClassB, when ClassA is destroyed. That's how 99% of the class memory management system works, and it's so easy. The fact that the ownerships are explicit, and easily seen (and not hidden like in C++'s RAII style) makes thinking about this and debugging it easy. Out of the languages that require manual memory management, I've written C, C++, Rust and Object Pascal. Object Pascal is the easiest of them all. C comes second, but it has some horrible flaws, like the char* strings, which are very difficult to use correctly and very bug-prone.

Nikolay

Nikolay Nikolov via fpc-pascal schrieb am
Mo., 21. Okt. 2024, 08:32:

2) record types (as opposed to class), which can live on the stack and have a pass-by-value semantics. FPC trunk supports advanced records, so you get C++-style copy constructors.

Advanced records are already supported since 2.6. What you mean is records with management operators, but even those are already supported since 3.2. ;)

Regards,
Sven

Yes. Even better. Thanks for the correction.

I got them confused, because I don't use them often.

Nikolay

Rainer Stratmann via fpc-pascal said on Wed, 16 Oct 2024 01:07:58 +0200

First of all, Joanna on #fpc (and other fpc related IRC channels) has blown off over 100 potential fpc users, including myself. I'm learning Ada now, and liking it a lot.

Second, fpc is neither fish nor fowl: It has way too much "stuff" to be an easy to learn or use language, but that "stuff" isn't useful to most non-Lazarus users. The solution to this problem is to publicize the hell out of the -M tp mode, which brings it back to Turbo Pascal 5.5, and then publicize it as a quick way to program relatively safely. It's quicker and easier to develop than C (or that horrid C++) and it's certainly safer than C or C++. Hammer these things home.

Look at the posts on . 90% of them are
of no use whatsoever to somebody wanting an easier and safer C. It seems to me to be a discussion of a neverendingly growing set of arcane library functions for edge case usage. The solution would be a , and publicize the hell out of it.
Seriously, the Pascal stuff discussed
is every bit as complicated as Ada, but without the extreme safety of Ada. Make and publicize .

Lazarus and Delphi are more complicated than they need to be. One time the fonts on my Lazarus application became unusably huge, I couldn't fix it, nor could the people on #lazarus find a way to fix it. Also, on Delphi and I assume Lazarus, it's very non-intuitive how to put your own libraries in directories other than the default. I lost a very nice puzzle application because my directories got overwritten.

HTH,

SteveT

Steve Litt

http://444domains.com

Nikolay Nikolov via fpc-pascal said on Wed, 16 Oct 2024 12:44:35 +0300

Do you have a garbage collection proposal for Pascal? Free Pascal has a JVM target that supports garbage collection and pretty much nobody is using it. Why do you think that is?

This is what I meant in my previous post. JWM? Garbage collection? What was wrong with Turbo Pascal 5.5? If you want garbage collection, what's wrong with Python, Ruby or Lua?

SteveT

Steve Litt

http://444domains.com

On Nov 15, 2024 at 9:23:41 PM, Steve Litt via fpc-pascal <

what authority does she have to such things?

Second, fpc is neither fish nor fowl: It has way too much "stuff" to be an easy to learn or use language, but that "stuff" isn't useful to most non-Lazarus users.

I tend to agree. Feels like it’s somewhere in between C, Java and C++ without committing to either direction. Not a bad thing I guess but no inspiring to new users either.

Regards,
Ryan Joseph

The little authoritarian monster has ops on the channel, and as far as I know, there's no one available with both the access and the interest to kick her out.  #fpc refugees created #fpc-alt, but I don't know how well known that is.  She certainly won't permit it to be discussed on #fpc.

g.

Sven Barth via fpc-pascal said on Thu, 17 Oct 2024 07:46:22 +0200

Who cares about a correct Linux point of view? I've used Linux every day exclusively for 23 years, but Linux isn't perfect in every way, and one way it's not perfect is requiring all the libraries at runtime. Why not make an fpc subset that runs reliably off a DVD or small thumb drive?

What got me hooked on Turbo Pascal was TP 2 and 3, which I could put on a floppy and use at every one of my clients to get past stuff their chosen languages couldn't do, and do so within a few minutes.

SteveT

Steve Litt

http://444domains.com

Michael Van Canneyt via fpc-pascal said on Thu, 17 Oct 2024 09:10:54 +0200 (CEST)

My wife creates websites for a living. I nearly had to re-animate her after she looked at the FPC website. The FPC website is a no-go area for her since that time.

Exactly what should a FreePascal website have in order to gain her approval?

SteveT

Steve Litt

http://444domains.com

Nikolay Nikolov via fpc-pascal said on Thu, 17 Oct 2024 11:20:15 +0300

This is interesting. You've described two sets of sites, one relatively bad and relatively good:

Bad = (freepascal.org, gcc.gnu.org, llvm.org)

Good =
(nim-lang.org, haskell.org, rust-lang.org, ziglang.org, python.org, ada-lang.io);

So I compared the two sets and the most noticeable thing that stood out was that the good sites had substantial sections having a dark background. A second, less noticeable and less consistent difference between the sets is that the good websites have subsections within the sections that are separated by substantial whitespace and on wide monitors are side by side. The bad ones seem to be massive walls of text.

Please think about it. If you had to give somebody a specification for a "good web page" and avoid the dreaded "you know what I mean" that our clients always give us when asked, would these two factors comprise most of the difference between good and bad websites? If so, it's pretty easy to make a good website, always assuming somebody with aesthetic taste decides on those background colors and the foreground colors that go with them (and please make them contrast for the visually impaired).

If I'm right about the definition of good sites, all it takes is HTML5 and some CSS skills. Even the top menus can be made with CSS sans Javascript.

I also noticed that a lot of the good websites were good on the home page but reverted to the bad style on other pages. The Python site always had the "good" layout.

Nikolay, your post is the first time I ever heard anyone specify a specification for a good site. Everyone else seems to ether say "you know what I mean" or "you don't have the skills, hire a designer".

So what do you all think? Does a good site really boil down to generous sections of light content on dark background plus generous spacing between sections and subsections?

Thanks,

SteveT

Steve Litt

http://444domains.com

Sven Barth via fpc-pascal said on Thu, 17 Oct 2024 14:17:23 +0200

See, the preceding is what I've been talking about. The preceding is complicated, hard to understand, and done well by the languages built to do it. Adding this would make fpc late to the party with a glommed on feature that gobbles up mindshare on the mailing list and community.

Leave with the one that brung you, the person who just wants a quick and easy way to make a fast runtime application.

SteveT

Steve Litt

http://444domains.com

I'm tempted to ask if you are seriously asking this. But I won't.

Design is a whole professional specialty. To say it boils down to light vs. dark background or the amount of whitespace is to insult those who do this work as a career. I'm sure you aren't trying to do that, so I'm not sure what you are looking for in this line of inquiry.

In the off chance that you really do not know the answers, here is some info for you:

-----
White
space, also known as negative space, plays a crucial role in effective web design. Here are the key ways white space contributes to creating compelling and user-friendly websites: Enhancing Readability and Content Prioritization

White space significantly improves the readability of content on a website. By breaking up blocks of text and providing visual breathing room, it allows users to process information more efficiently.This is especially important in the age of skim reading, as it helps visitors quickly comprehend content without feeling overwhelmed.White space also aids in content prioritization. By surrounding important elements with ample space, designers can draw attention to key messages, calls-to-action (CTAs), or other critical content.This strategic use of space creates a visual hierarchy, guiding users' focus to the most important parts of the page. Improving User Experience and Navigation

Effective use of white space contributes to a better overall user experience: Reduced Cognitive Overload: By preventing visual clutter, white space helps users avoid feeling overwhelmed by too much Navigation: White space can create clear separations between different sections of a website, making it easier for users to understand the structure and navigate the content.

Enhanced Focus: By
isolating important elements, white space helps direct users' attention to specific areas, improving engagement with key features or content.

Creating Visual Appeal and Brand Perception

White space plays a significant role in the aesthetic aspect of web design: Elegance and Sophistication: Websites with ample white space often appear clean, modern, and uncluttered, which can enhance the perception of professionalism and trustworthiness.

Balance and Harmony: White space helps create a sense of balance in design, contributing to a more visually pleasing and cohesive layout.

Brand Tone: The use of white space can communicate a brand's personality and style, reinforcing its identity in the digital space.

Facilitating Responsive Design

In the context of responsive web design, white space is crucial for ensuring a seamless experience across different devices. It allows for flexibility in layout adjustments, ensuring that content remains readable and visually appealing on various screen sizes.Conclusion

White space is not merely empty space but a powerful design element that significantly impacts the effectiveness of a website. When used strategically, it enhances readability, improves user experience, creates visual appeal, and supports responsive design. By mastering the use of white space, designers can create websites that are not only aesthetically pleasing but also highly functional and user-friendly.

---- On Fri, 15 Nov 2024 18:35:22 -0500 Steve Litt via fpc-pascal wrote ---

So what do you all think? Does a good site really boil down to generous sections of light content on dark background plus generous spacing between sections and subsections?

I am a little on the fence regarding the comment re neither fish or fowl...

each developer does their own thing in the language - whether that is writing something for platform X or working on database Y etc. Resources for learning are few and far between if you can find them. If you wanted to learn Pascal for web development, should there be something before re learning Pascal fundamentals?

If you ask people in the developer community what they know about "Pascal" what answers would you get?

Do they (people) understand how the language has evolved? What is possible in the language now!

While I don't do much C programming these days, I still read a bit about what has been added.

There maybe announcements in the fpc community, these appear on the forums vs fpc main site? In the news section, the latest entry is regarding the death of Wirth and then one before that was the 2021. This announcement was in 2022...

https://forum.lazarus.freepascal.org/index.php/topic,59468.0.html

On Sat, Nov 16, 2024 at 1:36 AM Hairy Pixels via fpc-pascal <

Consistency also helps...

A web site, wiki and documentation in html, all with different appearances does not help the end user.

but it is hard and a thankless task as well. That there is information available is a boon.

On Sat, Nov 16, 2024 at 10:25 AM DougC via fpc-pascal <

The Free Pascal wiki has pages for new features that have been added to each FPC version, as well as a page, containing any changes that may break existing code. These are for trunk:

https://wiki.freepascal.org/FPC_New_Features_Trunk

https://wiki.freepascal.org/User_Changes_Trunk

And you get a pair of these for each stable FPC version as well, e.g. for FPC 3.2.2:

https://wiki.freepascal.org/FPC_New_Features_3.2.2

https://wiki.freepascal.org/User_Changes_3.2.2

Best regards,

Nikolay

Rainer Stratmann via fpc-pascal said on Sat, 19 Oct 2024 16:15:10 +0200

I really can not see where beginners have to struggle with memory management. If a project gets bigger you have to think about it, yes. It depends on the coding style. In my project I wrote my own memory management for the webserver. It took me 3 weeks of work.

See this is what I don't understand. In the 7 years I used Turbo Pascal professionally, I don't remember ever having to allocate or free memory: I just declared variables. This was one of the big advantages of Turbo Pascal over C.

If these hypothetical Pascal newbies are sophisticated enough to write something like a server that busts off chunks of RAM for every user, they're familiar with allocation and freeing.

SteveT

Steve Litt

http://444domains.com

DougC via fpc-pascal said on Fri, 15 Nov 2024 19:15:13 -0500

If not possessing both light and dark backgrounds and use of ample whitespace, I'd like to know how Nikolay sorted these web pages into good and bad sets.

Thanks for your info on whitespace regarding content prioritization, skim reading, Calls To Actions, responsive design and structure and navigation. It all made sense.

SteveT

Steve Litt

http://444domains.com

If you know nothing about the language, the main page explains to you quickly what's the point of the language, and gives you example code, so you can immediately see how it looks like. There are relatively large and easy to find buttons/links for:

1) download

2) tutorials/docs

3) some (Nim) even have a link for trying the language in the browser

The download page is also easy to navigate, with large buttons/links for the main platforms (Windows, Linux, macOS).

I think that was pretty much my criteria. It's not much, but it does matter for new users.

Nikolay

On Nov 16, 2024 at 3:13:26 PM, Nikolay Nikolov via fpc-pascal <

Some here are not appreciating just how fickle people are these days. It’s not 1995 anymore and there are literally dozens of languages you can choose from so if it’s not clear what language looks like within 30 seconds browsing a web page people will click away and go to the next one.

I saw this video recently (https://www.youtube.com/watch?v=vFFcCLzOOyw) where this person goes over a list of languages he considered before choosing Odin for his projects (Free Pascal not included sadly). Notice the web pages and resources he reviewed in his process. The FPC web page doesn’t even have anything to view in terms of code snippets. People are going to click away for sure.

Regards,
Ryan Joseph

Users will judge a website within seconds. And unfortunately that is the nature of the game today.

On Sat, 16 Nov 2024, 9:28 pm Hairy Pixels via fpc-pascal, <

The website is due for an overhaul. After 3.2.4 is out, this subject comes back on the table.

That said, the Free Pascal website is not about the pascal language.

It is about the compiler. The GNU compiler or LLVM C compiler also do not contain code on their website. Not that I would recommend their sites, but these tools are used massively.

By contrast, there is only one Python. There is only one Rust, Ruby whatnot. Their compiler/interpreters *are* the language, so there it is logical and suitable to present the language on their site.

But my plan is to include a 'Try it out now' page with the pas2js compiler (or the fpc webassembly compiler) embedded.

Michael.

HI,

Michael Van Canneyt wrote

By contrast, there is only one Python. There is only one Rust, Ruby whatnot. Their compiler/interpreters *are* the language, so there it is logical and suitable to present the language on their site.

Actually, there's some recent drama in the Rust world, that some Rust purists are really against the GNU Rust/GCCrs project. :) (Basically the Rust version of what GNU Pascal wanted to be.) And Python has multiple implementations as well. But I get your point, there's still a single one that de-facto defines the language. In our case this was Delphi for a long time... Even if Pascal goes back way before Delphi (and BP/TP before that), of course.

But it's hard to be the smaller alternative, yet still advocate for the greater good.

Charlie

See this is what I don't understand. In the 7 years I used Turbo Pascal professionally, I don't remember ever having to allocate or free memory: I just declared variables. This was one of the big advantages of Turbo Pascal over C.

Well, then you never needed datastructures > 64k (IIRC). Even my addressbook (who didn't write one?) used GetMem/FreeMen or New/Dispose to allocate new records on the heap for that. Even basic Pascal books (yes, books on paper in those years) extensively covered this subject.

I could see that if it was a compiler for “Pascal” which was defined by some other group and you could reference them but it isn’t. FPC is a language in its own right and the compiler is the only place that implements it. It’s the compilers sole responsibility to document and promote it’s own language.

Regards,
Ryan Joseph

Really ?

You never heard of Delphi, ElevateWeb, Smart Mobile Studio, PascalScript, OxyGene ? There are some others, can't recall the name. There is a Russian version, called abcpascal or something similar.

They all implement "object pascal", as defined by Delphi.

FPC has some specific extensions, but overall it is 'just' object pascal. And these extensions we document.

Don't misunderstand me, I'm all for promoting pascal. I'm just not sure the FPC website is the right place to do it.

Michael.

On Nov 16, 2024 at 9:46:25 PM, Michael Van Canneyt via fpc-pascal <

The compiler has FPC and OBJFPC modes. There’s so many little differences and mode switches at this point it’s not good enough to say “go to Delphi’s website for more information” and even if you did why would you rely on them?

It’s just a big missed opportunity to not take control of language promotion at the place the people are downloading the compiler. This level of misdirection is enough to lose users before they even consider anything.

Regards,
Ryan Joseph

This is something I don't understand. Why should all these environments and we, as Free Pascal/Lazarus users, follow Delphi's standards?

Don't get me wrong. I've been working with Delphi for over 25 years and with FPC for 6 or 7 years. My career is based on Object Pascal. So, I too am interested in keeping the language relevant... but why follow Delphi? Why does FPC/Lazarus need to maintain this compatibility? Why does FPC/Lazarus need to follow the trends (erroneous, in my opinion) of Delphi or any other language?

Object Pascal is, in my opinion, one of the best programming languages ever created—if not the best. It is easy to understand and write; you can implement anything with it, from an operating system to visual applications for end-users. Its structural organization is one of the things that sets it apart from other languages, where everything has its proper place to be declared... well, that used to be the case. Now, variables can be declared "anywhere"; "anonymous procedures" now exist and can also be declared "anywhere"; we have Generics because, well, Delphi and other languages have them, so we must have them too, right?

Wrong!

In my humble opinion, what keeps a language/environment/architecture relevant is how it deals with the world's innovations. It's not about adding new features to the language but adding new layers to address current problems.

Let me explain: think about all these new features that have been added to the language and tell me what (most of them) allow us to build now that we couldn't build before. Most people still use the language to create the same kinds of systems. Does that make the language obsolete? Not if it can still create systems that are usable today! If it has performance, is easy to write, and is maintainable...

So instead of "wasting time" implementing things Delphi did or what another language did, we could use that time to make everything simpler in the "FPC + Lazarus ecosystem" and forge our own path instead of following "false leaders" who are, in fact, just a slightly larger niche than FPC/Lazarus itself.

How about:

- finally unifying FPC and Lazarus, whether on the FPC website, the Lazarus website, or a new one;
using fpcupdeluxe as the official installation method; cross-compilation is very important, and most people using Lazarus for real-world applications use fpcupdeluxe to install Lazarus;
- having pas2js pre-configured for creating web applications;
- having an option to create mobile applications; we know it's possible (Castle does it), but nobody knows how to do it with a standard Lazarus setup; mobile is current, and we need that!
- simplifying/deleting most of the libraries that are not used by default;
- simplifying the naming conventions of units; using something like "lazarus.blablabla" and "fpc.blablabla" and leaving the main system units with names without prefixes;
- do you want to add new features to the language? Then why not "fix" the WITH statement by adding something like [WITH someobject AS obj DO], so we can use WITH without the problems we all know;
- how about allowing the same AS in unit declarations so we can do something like [unit MyUnitWithABigName AS MyUnit] and then use [MyUnit.TSomeClass] — this can already be done with MACROS, so it would be simple to implement in the language, right?

Notice that all these new features would NOT break the "philosophy of the language," unlike what has been added over the years.

In short, if the language retained its philosophy, its simplicity, while adding only what the world demands today (web and mobile apps), we wouldn't need to spend time debating how to attract new developers to the language, as it would happen organically, as it does with some languages that don't have the marketing power of Oracle or Microsoft.

Sincerely,
Marcos Douglas

Because it means we can reuse code written for Delphi.

Not only components on github/gitlab, but entire projects.

At my current job I'm converting a Delphi application to WebAssembly. FPC has (meanwhile very good) support for webassembly. Delphi does not have it.

Due to the good compatibility, the same codebase can be used to create a desktop/mobile application that runs in the browser.

If we didn't have it, this project would be impossible.

Object Pascal is, in my opinion, one of the best programming languages ever created—if not the best. It is easy to understand and write; you can implement anything with it, from an operating system to visual applications for end-users.

No argument.

Depending on your goals, yes.

That is what I am doing. All my work for FPC is geared towards a single goal:

Whatever your project, FPC can do realize it.

Desktop. Server. Browser. Embedded Device: FPC has what you need.

I agree.

I don't use these new features, or only very sporadically.

I have no idea how big the Delphi community is.
It's a secret only known to Embarcadero, and they're not talking.

Do you know how big (or small) FPC/Lazarus is ?

I have no idea. I of course hope it is big.

How do you know this ? On what do you base this statement ?

Again, I have no idea.

- having pas2js pre-configured for creating web applications;

What is missing ? It is present in current lazarus ?

- having an option to create mobile applications; we know it's possible (Castle does it), but nobody knows how to do it with a standard Lazarus setup; mobile is current, and we need that!

We're working on improving the support for mobile.

- simplifying/deleting most of the libraries that are not used by default;

Such as ?

- simplifying the naming conventions of units; using something like "lazarus.blablabla" and "fpc.blablabla" and leaving the main system units with names without prefixes;

No. I think prefixes are actually a good idea.
Initially, I also didn't like them.
But I have changed my opinion.

In projects with lots of units (roughly 27.000 in my job project) they are actually useful to structure the code.

- do you want to add new features to the language? Then why not "fix" the WITH statement by adding something like [WITH someobject AS obj DO], so we can use WITH without the problems we all know;

Actually, it has been implemented.

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/860

It needs some attention, but basically it is ready.

- how about allowing the same AS in unit declarations so we can do something like [unit MyUnitWithABigName AS MyUnit] and then use [MyUnit.TSomeClass] — this can already be done with MACROS, so it would be simple to implement in the language, right?

Basically, more syntactic sugar ?

You can do this today.

uses MyUnitWithABigName;
Type
   TSomeClass = MyUnitWithABigName.TSomeClass;

Notice that all these new features would NOT break the "philosophy of the language," unlike what has been added over the years.

As most people on the lists know, my concern for the "philosophy of the language" is big. I make no secret of it.

But Delphi compatibility is a must-have. If there are things in Delphi we don't like, we can implement it, but forbid the use in the FPC code base. Such as inline variables - I agree this has no place in well-written pascal code.

Michael.

Sure. If we maintain compatibility with Delphi so we can use some libraries (or even entire projects) and later convert them into something better, that’s fine—of course, I agree. My comment was more along the lines of saying we shouldn’t follow Delphi just for the sake of it. In other words, just because it was implemented there doesn’t mean we should implement it here, especially if there’s no actual benefit for us.

And I believe you will achieve that goal.

But if it’s not at least easy to start a project from scratch using Lazarus, it will be hard for new developers to see any advantage in choosing Pascal over another language (one that already provides those features out of the box).

I don’t have official numbers—it’s more of a feeling, based on my own research—but it’s much easier, for example, to look for jobs in any other language (like C/C++, Java, .NET, or even Rust) than in Pascal. On LinkedIn, for instance, you can type "Delphi" (or variations like "Delphi Developer") and the auto-completion will work. However, if you try typing "Pascal," you’ll hardly find a position for a "Pascal Developer"—you might instead get several results for companies with "Pascal" in their name (the same for "Lazarus").

In every company I’ve worked at that used Lazarus, we always relied on fpcupdeluxe. In all the groups I’m part of, most people are familiar with and use fpcupdeluxe. Even new users often report issues with the official installation, until someone suggests using fpcupdeluxe—and then everything just works.

> - having pas2js pre-configured for creating web applications; What is missing ? It is present in current lazarus ?

I have no idea. In fact, I’m not using the latest version of Lazarus—my mistake—so some of my ideas might be outdated.

Great news!

> - simplifying/deleting most of the libraries that are not used by default; Such as ?

I don’t know. Anything that’s there solely to support 20-year-old legacy projects but is holding back or hindering the development of more important priorities.

Sure, it's a good idea.
Even if that breaks some code, it wouldn’t be a big issue to just rename units—after all, you’ve already done that with the VirtualTrees unit, renaming it to Laz.VirtualTrees (which wasn’t the best choice), and you didn’t face many problems, right?

Good to know. I didn't understand why use [with const...] but, Ok, it's a start.

For a single class, sure. But imagine using many classes, functions, etc. Also, think about having two (or more) different units with many functions/classes that share the same name. If the units have long names with dots, for example, each argument in a method would need to use the full naming convention (like a.unit.name.very.long.function), which would be very verbose, don’t you think?

Now, I can do this in FPC (but not Delphi, right?):

uses
  {$macro on}
  FPC.RTL.Windows,
  {$define Win := FPC.RTL.Windows}
  FPC.RTL.Graphics;
  {$define Graph := FPC.RTL.Graphics}
var
  B1: Win.TBitmap;
  B2: Graph.TBitmap;

It works very well.

Now, considerer this:

uses
  FPC.RTL.Windows as Win,
  FPC.RTL.Graphics as Graph;
var
  B1: Win.TBitmap;
  B2: Graph.TBitmap;

So, throughout the unit, you could use Win.Something or Graph.Something.

Much more elegant and still in the spirit of Pascal. Don't you think?

As I mentioned earlier, if the goal is to maintain compatibility with Delphi just to use good libraries that were only made for Delphi, then yes, let's maintain that compatibility! But keep in mind that if the compatibility is only partial, it won’t be very useful.

Best regards,
Marcos Douglas

Marcos Douglas B. Santos wrote

"anonymous procedures" now exist and can also be declared "anywhere";

You didn't get the important part of the feature then. The important part is less the anonymous function, but the function reference. That you can have a function capture state from within the function and then have that state leave the function. Unlike Delphi FPC can also pass nested functions to function references, so if you don't like anonymous functions you can still benefit from this feature by utilizing nested functions together with function references.

we have Generics because, well, Delphi and other languages have them, so we must have them too, right?

Wrong. FPC had generics before Delphi. And they allow for typesafe code without duplicating the necessary source code for everything. I wouldn't want to miss them by a long shot.

- finally unifying FPC and Lazarus, whether on the FPC website, the Lazarus website, or a new one;

FPC and Lazarus are as unified as is sensible. We keep them different by *choice* so that users don't think that they *have* to choose Lazarus if they don't want to.

using fpcupdeluxe as the official installation method;

No. The Windows and Linux installers are much more sensible for the release versions. FpcUpDeluxe makes sense for development versions or for quickly setting up a cross platform compiler for a platform that doesn't have an installer.

- simplifying/deleting most of the libraries that are not used by default;

I agree that most libraries should be moved over to the fppkg repository once we get that up and running. But until then we will not remove anything.

- simplifying the naming conventions of units; using something like "lazarus.blablabla" and "fpc.blablabla" and leaving the main system units with names without prefixes;

No. That affects backwards compatibility. Not gonna happen. Which is also why the 3.4.0 release which will support both non-namespaced and namespaced units (for Delphi compatibility) will be available in both flavors. At least for the major platforms.

- how about allowing the same AS in unit declarations so we can do something like [unit MyUnitWithABigName AS MyUnit] and then use [MyUnit.TSomeClass] — this can already be done with MACROS, so it would be simple to implement in the language, right?

That alone shows that you have no clue how the compiler works...

Regards,
Sven

We do. Most Linux devs do. Linux distros do.
Only because you say that you don't doesn't mean that the majority doesn't.

Regards,
Sven

We will *not* advertise a legacy mode for new development. The main purpose is FPC is to be an Object Pascal compiler, meaning the Object Pascal dialect introduced by Delphi and thus either modes ObjFPC or mode Delphi. The others are nice to haves, just like support for the two ISO standards that essentially no-one uses.

Users already don't graps the difference between the fpc-pascal and fpc-devel lists. No need to provide yet another separation.

Regards,
Sven

The point of the JVM target is that it allows to use Pascal code on the Java Virtual Machine. What's wrong with supporting more platforms? Same as FPC supporting either JavaScript directly (through pas2js) or WebAssembly.

Regards,
Sven

Hi,

Can we please move this discussion to the fpc-other list? It has grown very large and lies not really within in the primary purpose of this list (getting help with using FPC).

Thanks,

Jonas
One of the FPC mailing lists admins

On Nov 17, 2024 at 7:57:07 PM, Sven Barth via fpc-pascal <

Why is that such a crazy idea? There are already type aliases and module names work like types so it makes sense they could be aliased too. Why not?

Regards,
Ryan Joseph

I understand that the important part is about function references. However, anonymous functions don’t align with the spirit of the Pascal language, so I wrote about that.
But now you’ve made it clear that I can also pass nested functions to function references, which is great—a language evolution without breaking its philosophy.

I’m completely in favor of maintaining backwards compatibility—that’s one of the reasons I’ve continued developing in Object Pascal year after year.

What I meant, however, is that it can be challenging to maintain code (libraries,
compiler, etc.) just to ensure backwards compatibility. Wouldn’t it be easier to keep a simpler compiler and libraries rather than having conditionals and modes to accommodate everything and everyone?

It would be up to the developer to decide whether it’s worth migrating an entire project to the new compiler version or keeping it on the same version (but one that is already stable, works, and still allows them to update their project normally over the years).

I don't.
I’m not a compiler developer. I just thought it would be "easy" to implement something that’s already possible with a MACRO. I’m sorry if it seemed like I was saying implementing something in the compiler is easy. I guess we all know it’s not.

best regards,
Marcos Douglas

But the problem is (as I've repeatedly stated on this list) is that if one doesn't use lazarus for their IDE, then building anything other than basic command line programs is nearly impossible.  I've asked (multiple times) on this list for samples of doing various things with FPC that lazarus does with ease, (such as GUI, and networking), without using lazarus, and each and every time, the silence has been deafening.

I've never once received any information on doing these kinds of things without Lazarus.  Sure, there's a (very) few examples of using tcp/ip networking with the default FPC install, but those examples are about as simplistic as it's possible to get, which actually shows next to nothing about such capabilities.  aAnd, I've *never* seen any samples of how to build a GUI app just by using the command line compiler.  I've done searches on google, and asked on this list, and everything I can turn up shows nothing as relates to building an FPC app with a GUI w/o using some IDE or other.(mostly lazarus), so if you could kindly point me to such resources, I'd love to see them

Typically when I ask such questions on this list, I get either no response at all, or I get snarky ones that contribute nothing to the discussion.  (mostly from yourself).

This is why I almost never use FPC for program development, unless it's a cross platform application that can run from the command line, there's just no point in doing otherwisesince I don't use an IDE of any kind.

I use powerbasic when GUI is required on windows, and java when GUI is required on other platforms.

I'd love to use FPC, since it otherwise checks all the boxes, cross platform, and capable of networking, and GUI programming, but I simply can't, because I can't find any examples of such for someone who doesn't use Lazarus.

Travis,

There is a discussion in the fpc archives 2014 I believe about using Geany.

I have been using Geany for over 10 years with complex GUI programs ... but you must use a file located in the directory where the executable is linked.

... in this case extrafps.cfg

... and reference the file extrafpc.cfg  in Geany

BTW : The guys documenting FPC have never bothered to describe this in any documentation that I can find.

Vern

The compiler by itself will not use that file. Here is the mechanism used by the compiler:
https://www.freepascal.org/docs-html/current/user/usersu10.html

So if geany or one of its plugins does something with that file, then you should be looking in the geany documentation for the mechanism used: I can't be expected to document every plugin for every editor on the planet.

Based on your scant information, I can only assume that the abovementioned file (is it extrafps.cfg or extrafpc.cfg or both, or is that a typo ?) is a regular FPC configuration file.

I know the fpGUI project uses extrafpc.cfg or extra.cfg or so, but you need to pass it to the compiler through @extrafpc.cfg.

If it is a fpc config file, then in that case it is definitely documented here:

https://www.freepascal.org/docs-html/current/user/userse17.html

Michael.

to pass it to the compiler through @extrafpc.cfg. If it is a fpc config file, then in that case it is definitely documented here: https://www.freepascal.org/docs-html/current/user/userse17.html

"One of the command line options allows you to specify a second configuration file: Specifying @foo on the command line will open file foo, and read further options from there. When the compiler has finished reading this file, it continues to process the command line."

Adding to what Michael said, the @ command line option is also documented here: https://www.freepascal.org/docs-html/user/userap1.html "@<x> Read compiler options from <x> in addition to the default fpc.cfg"

(it can include a path so it is not a requirement to locate the file in the same directory where the program is linked)

To avoid interference from other config files in the system or home directories, this can be used at the same time:
"-n Do not read the default config files"

e.g. fpc -n @"/some/path/to/config/fpc.cfg"

Nikolay Nikolov via fpc-pascal said on Sat, 16 Nov 2024 10:13:26 +0200

Thanks Nikolay, this is good information.

SteveT

Steve Litt

http://444domains.com

Hairy Pixels via fpc-pascal said on Sat, 16 Nov 2024 06:28:38 -0500

Thanks Ryan,

What you say makes a lot of sense, and not just for computer language websites.

SteveT

Steve Litt

http://444domains.com

Bart via fpc-pascal said on Sat, 16 Nov 2024 14:59:10 +0100

I didn't.

Even my addressbook (who didn't write one?) used GetMem/FreeMen or New/Dispose to allocate new records on the heap for that.

You're right. I never implemented a linked list or binary tree with Turbo Pascal, or anything that used an arbitrary number of "things". I always used C, Python or Perl for that kind of thing. So you're right and I was wrong, Getmem/Freemem are very important.

SteveT

Steve Litt

http://444domains.com

Does FPC have an equivalent site to http://www.getlazarus.org/? It's very well presented.

g.

Travis Siegel wrote

But the problem is (as I've repeatedly stated on this list) is that if one doesn't use lazarus for their IDE, then building anything other than basic command line programs is nearly impossible.

I guess you didn't look very hard that. :-)

https://fpgui.sourceforge.net/

https://github.com/mse-org/mseide-msegui

Both of those can do what Lazarus does (ide & gui framework). I'm very happy the FPC compiler is kept as a separate project. It makes project like the above viable.

Regards,
Graeme

Alternative projects to Lazarus, but built with FPC:

* fpGUI: https://fpgui.sourceforge.net
* MSEide & MSEgui: https://github.com/mse-org/mseide-msegui

Examples
========
Animated GIF showing fpGUI's form designer in action (not using Lazarus or LCL at all):
http://geldenhuys.co.uk/~graemeg/editform.gif

fpGUI themeing support, and some custom apps (last two screenshots): http://geldenhuys.co.uk/~graemeg/themes/start.html

Screenshots of apps included and written using fpGUI: https://fpgui.sourceforge.net/screenshots_apps.shtml

fpGUI's DocView help viewer, integrated with various IDEs: https://fpgui.sourceforge.net/docview_ide_integration.shtml

AggPas software 2D rendering engine:
https://github.com/graemeg/fpGUI/tree/develop/src/corelib/render/software

tiOPF - Database Persistence Framework, which supports VCL, LCL and fpGUI. It also includes its own non-DB visual component layer (aka Mediators), which uses the model-gui-mediator design pattern, to make any standard components "object aware" with bidirectional updates. https://github.com/graemeg/tiopf/tree/tiopf2

This video is a bit dated, but MSEide & MSEgui in action: http://geldenhuys.co.uk/~graemeg/videos/mse_demo.mpeg

All these have been around for 15+ years.

I believe there used to be a FPC wiki page listing these and many many more like these.

Regards,
Graeme

Again, both of which are IDEs (just of a different type.

You still haven't shown me how to build a GUI app with default fpc installed resources.  What's the point of claiming FPC can do gui apps if it can't do them w/o third party support?

You missed the part when I said without some IDE or other.

Show me a raw source file that doesn't depend on any IDE at all written in FPC, something I can compile from the command line using *only* FPC default installed resources.

FPC provides headers for Win API, GTK2, Cocoa, etc. so you can create GUI applications with a default FPC installation.

W dniu 2024-11-20 o 15:45, Travis Siegel via fpc-pascal pisze:

Op 20-11-2024 om 15:45 schreef Travis Siegel via fpc-pascal:

On my stock win32 install:

cd  /d c:\fpc\3.2.2\demo\win32

fpc edit

edit

Regardless of if the requirement that everything is in the default install is a sane one.

Travis Siegel wrote

Again, both of which are IDEs (just of a different type.

fpGUI has a "demo app IDE" only. It's not an IDE, but whatever.

You still haven't shown me how to build a GUI app with default fpc installed resources.

In fpGUI's README it has build instructions for IDEs and command line (CLI) usage.

cd <fpgui>/src
./build.sh

That builds the whole GUI toolkit from the command line. Works on Windows, MacOS, Linux and FreeBSD.

To build the demos or all GUI applications (Visual Forms Designer, DocView etc). For example:

cd <fpgui>/docview/src
fpc @extrafpc.cfg docview.lpr

  What's the point of claiming FPC can do gui apps if it can't do them w/o third party support?

You've got to learn to read mate. ;-)

Regards,
Graeme

Travis Siegel wrote

Again, both of which are IDEs (just of a different type.

And in case it wasn't obvious... fpGUI is fully implemented in Object Pascal. Every widget (component) is written in Object Pascal - even the optional 2D rendering engine (AggPas).

Regards,
Graeme

Travis Siegel wrote

Show me a raw source file that doesn't depend on any IDE at all written in FPC, something I can compile from the command line using *only* FPC

https://en.wikipedia.org/wiki/FpGUI#Example_program

[mic drop]

G.

Travis Siegel via fpc-pascal schrieb am
Mi., 20. Nov. 2024, 15:47:

Here is an example for using GTK2 directly:

https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/gtk2/examples/helloworld/helloworld.pas?ref_type=heads

This page contains an example for X11:

https://wiki.lazarus.freepascal.org/X11

And here are some examples for work with the WinAPI:

https://wiki.freepascal.org/Windows_API_examples

In the end nearly all relevant GUI toolkits to interact with are C-based (with the exception of Qt which is C++ and for which a flattening library is available), thus for those that don't want to work with Lazarus, they should simply look at corresponding documentation of the GUI toolkits.

Regards,
Sven

Hello,

I'm not sure, but I am working on this one:
https://ikelaiah.github.io/free-pascal-cookbook/
<https://ikelaiah.github.io/free-pascal-cookbook/>, and it mentions how to install FPC and use FPC for common tasks for newcomers.

Regards,
Iwan

On Nov 24, 2024 at 4:12:03 AM, Iwan Kelaiah via fpc-pascal <

Great work. This is exactly the kind of thing I was talking about. FPC team should take notice.

Regards,
Ryan Joseph

❤️
reacted via Yahoo Mail

On Sun, Nov 24, 2024 at 8:04, Hairy Pixels via fpc-pascal wrote: _______________________________________________ fpc-pascal maillist  - 
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

https://ikelaiah.github.io/free-pascal-cookbook/

High quality advertising for Pascal / Lazarus -

congrats on a job (very) well done

SteveG

We do. Well, I did :).

Very nice job on the site, indeed. Love the image!

Reminds me of the cook in Linux Journal (some Canadian guy posed as a chef, presenting Linux recipes. Don't recall his name).

Good idea to use the cheetah in a completely different setting. Maybe we should generate a different cheetah image per subject. A professor for help pages, a mechanic for downloading and installing. Psychiatrist for FAQ. Union representative with bullhorn for the lists pages ;-)

Well done pages, for sure!

Michael.

Michael Van Canneyt wrote

Great work. This is exactly the kind of thing I was talking about. FPC team should take notice. We do. Well, I did :).

Request to Iwan, he have some new changes for “extended RTTI” like Delphi has and it would be nice to have an RTTI section with examples of how read/write the various types. I have resorted to using ChatGPT to remember how to do things like iterate record fields etc… but it would be nice to have them all in once place in a concise format.

Is the extended RTTI complete yet in the RTL? I think the compiler part got merged into trunk but the RTL was still pending (Michaels area). Been months now and lost track of where it stands.

Regards,
Ryan Joseph

Den 24.11.2024 10:21, skreiv Michael Van Canneyt via fpc-pascal:

What about a section on the front page with links to stuff like this provided by guys like Iwan (and others)?

Hi Michael,

Thanks for noticing and for the kind words!
The cookbook site is still far from finished, I'm still adding contents as I learn FPC and Lazarus.

Regards,
Iwan

Thanks for the kind words.
RTTI is on my list, along with anonymous methods (happily waiting).

Thanks,
Iwan

>That builds the whole GUI toolkit from the command line. Works on Windows, MacOS, Linux and FreeBSD.

I'm intrigued by FPGUI, I'm trying to build FPGUI on Windows 10, and I'm having some difficulty. When I follow the instructions from Install.txt I get this:

R:\fpgui_src_1.4.1\fpgui-1.4.1\src>build
"You've got the correct output lib directory"
Compiling GDI CoreLib
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386 Copyright (c) 1993-2021 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling corelib\gdi\fpgui_toolkit.pas
Compiling .\corelib\fpg_base.pas
Compiling corelib\gdi\fpg_impl.pas
Compiling .\corelib\fpg_main.pas
Compiling .\corelib\fpg_constants.pas
Writing Resource String Table file: fpg_constants.rsj Compiling corelib\gdi\fpg_interface.pas
Compiling corelib\gdi\fpg_gdi.pas
Compiling corelib\gdi\fpg_oledragdrop.pas
fpg_oledragdrop.pas(113,23) Error: No matching implementation for interface method "SetData(const tagFORMATETC;var TagSTGMEDIUM;LongBool):LongInt; StdCall;" found fpg_oledragdrop.pas(203,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: I:\Programming\FPC\3.2.2\bin\i386-Win32\ppc386.exe returned an error exitcode

Anyone have any ideas what I'm doing wrong? This is all way over my head I'm afraid.

James

Thought this should be a separate thread... sorry it if ends up confusing things.

I'm trying to get FPGUI to work on Windows 10 with just FPC without Lazarus, and I'm just not having any luck.
These seem to be three ways to install FPGUI on Windows.
1. Build it from a command line
2. Compile it with the Text IDE
3. Install it with FPCUPDELUXE

I haven't got any of these to work. When I try to build from the command line I get
fpg_oledragdrop.pas(113,23) Error: No matching implementation for interface method "SetData(const tagFORMATETC;var TagSTGMEDIUM;LongBool):LongInt; StdCall;" found
See original message below

Next I thought I would try FPCUPDELUXE, so I used it to install a fresh copy of 3.2.2 and then went to modules to install FPGUI it seems like it's going to work, but then it gets an error:
Exception: EInOutError. File not open

The info has this:
info: Universal Installer (GetModule: fpgui): Getting module fpgui. info: Universal Installer (GetModule: fpgui): Going to download/update from GIT repository https://github.com/graemeg/fpgui.
info: Universal Installer (GetModule: fpgui): Please wait: this can take some time (if repo is big or has a large history). info: Performing SVN/GIT/HG/FTP/URL checkout/download. Please wait, could take some time.
info: Universal Installer (GetModule: fpgui): Download/update from GIT repository ok.
info: Universal Installer (GetModule: fpgui): No fpgui patches defined. Then it just stops, and I don't see any fpgui directory in my units/{Processor} folder which is what I was expecting to happen... maybe this isn't what's supposed to happen... but it doesn't seem to finish.

So finally I tried the instructions for compiling it with the Text IDE, I added all the directories required as per the instructions, and randomly pick a few examples to try to compile, and fpg_base.pas on line 41 I get: fpg_base.pas(41,32) Error: Parameters or result types cannot contain local type definitions. Use a separate type definition in a type block. The line is: TfpgChar = type String[4]; It doesn't seem to like the [4]

I have tried all kinds of various compiler options like Use AnsiStrings and just a bunch of random settings like turning optimizations on and off... because it seems like this would be more of a compiler setting than a bug in the program, because a bug would have been fixed years ago... so I'm guessing it's something wrong with how I have it set up, but what I would need to fix? I have no idea... other than changing the source code... I guess I could change it to an array of characters or something... but why am I getting an error at all? Nothing I change allows this line to compile.

So I thought maybe it's because I'm trying to use the current trunk, so I tried the same thing with 3.2.2, and on there I get: fpg_impl.pas(26,3) Fatal: Can't find unit x used by fpg_impl
Just for fun I commeneded fpg_impl out and 3.2.2 does get past TfpgChar = type String[4]; without error... but then there are more errors because of commenting out fpg_impl. So I feel I might be getting close.. but what is Unit X? and where do I get it? Is there some dependency I need for FPGUI?

For even more fun I tried to change TfpgChar = type String[4]; to just TfpgChar = String[4]; in the current trunk, and then that line does compile, but then I'm back to being unable to find Unit X. I'm not sure if I have some setting in a way that FPGUI doesn't expect it to be, or what the issue is, I just don't know where to look. I don't know what Unit X is or why I don't have it. It looks like a really cool package and I hope I can get it working. I have some GDI windows in my FPC projects, but FPGUI looks a lot easier to implement and a lot less confusing.

James

On Nov 29, 2024 at 8:11:11 AM, James Richters via fpc-pascal <

This is very much on topic. FPC has no build system so what do you do when you encounter a project like this without clear building? I want to try this too but I have no idea what to do with it. It’s just a bunch of directories and some text files not about building.

Does it even run on macOS? I built the one program file I found (fpmake.pas) but running that crashes. Looks like a cool project but I don’t have time for any more than this.

If there’s anything that would kill a compiler more it would have to be “new user can’t build projects”. Even for me I will simply ignore projects because I don’t want to spend 30 minutes digging around source code and asking questions on mail lists.

Regards,
Ryan Joseph

Huh ? Of course it does, it has 2. fpcmake (older) and fpmake.

Please don't spread incorrect information.

Michael.

Maybe some forgotten writeln.

Mattias

On Nov 30, 2024 at 3:11:10 PM, Michael Van Canneyt via fpc-pascal <

sorry but it’s not really part of the compiler, just something that generates commands it feeds to the compile right?. aren’t new compilers doing away with this design and integrating the whole setup? Having the build system and the compiler as two different programs is the root of so much confusion.

Look I tried to build that project but it just crashes. Maybe the fpmake.pas is too older for my compiler? It’s from 2015.

src$ ./fpmake
Threading has been used before cthreads was initialized. Make cthreads one of the first units in your uses clause. Runtime error 211 at $0000000104D2610C
$0000000104D2610C
$0000000104CBA24C
$0000000104CA1118
$0000000104CC78DC
$0000000104CA1090
$0000000104CA10E8
$0000000180C5C274

src$

Regards,
Ryan Joseph

Hairy Pixels via fpc-pascal schrieb am
Sa., 30. Nov. 2024, 09:53:

The spread of make, CMake and all the other various build systems for various compilers tells otherwise.

Also compared to other compilers FPC and Delphi are relatively aware of stuff. Just be sure to pass in the right directories, have some start unit and things will be compiled as intended. That can even be simplified by the author providing some fpc.cfg that can be loaded with "@" on the command line. As long as specific units don't require special settings that come from outside that is all that is needed.

Regards,
Sven

No, they are not. I don't know where you got that from. On the contrary, build systems proliferate like crazy.

Michael.

I decided to try to fix this myself, and I'm happy to say I got it working!

I finally figured out that the error message itself told me how to fix the error in fpg_oledragdrop.pas:
Error: No matching implementation for interface method "SetData(const tagFORMATETC;var TagSTGMEDIUM;LongBool):LongInt; StdCall;" found

It was telling me that the constant medium should be a variable:
function    SetData(const formatetc: TFormatEtc; var medium: TStgMedium;
fRelease: bool): HResult; stdcall;

I also found that in fpg_base.pas the line:
TfpgChar = type String[4];
While this does work in FPC3.2.2, it Just doesn't work in the current FPC trunk, so I changed it to
TfpgChar = String[4];
I thought it was more important to keep it a String[4] than to create a special type for it... I'm not sure exactly when FPC changed that causes this to be an issue, or if there is a better way to fix it, but for the current trunk it needs to be addressed.

I then went on to figure out that X11 is a Linux thing, but I'm on Windows. I was trying to compile fpGUI with the Text IDE... on Windows, and since I was following the instructions for compiling with the IDE, which are not valid at all for Windows, there is no way it could work. I knew to reverse all the / to \ but I didn't know X11 was for Linux and I should be using GDI for windows... why would I know that? Since I don't have linux, I have no idea what the designation X11 is, and I really didn't even know GDI was an option because it doesn't tell me to use it in the instructions. Well I asked ChatGPT and it knew right away that X11 was not for Windows, and that's the only reason I know it now.

I figured out that what I should be compiling with the IDE to build the All the Units needed for fpGUI is fpgui_toolkit.pas, from either the GDI directory for Windows, or the X11 directory for Linux, and I have no idea what to do for Mac. Well the instructions don't make any of this clear at all, and if you try to compile fpgui_toolkit.pas with the text IDE, you need to put a LOT more directories in the units than what is indicated in the instructions. I needed:
fpGUI\src
fpGUI\src\corelib
fpGUI\src\corelib\GDI
fpGUI\src\GUI
fpGUI\src\gui\db
fpGUI\src\reportengine
fpGUI\src\3rdparty\regex

I finally did get it to compile on both 3.2.2 and the current trunk and I got build.bat to work as well, so I thought I would contribute my findings to make it easier for others, as it took me 3 days to get this figured out. So I found the fpGUI repo and noticed it had a develop branch, so I figured that's where I should make pull requests... so I cloned the repo and had a look and I noticed that the issue with setdata had already been fixed!

It has this code in it:
    {$IF FPC_FULLVERSION >= 30200}
    function    SetData(const formatetc: TFormatEtc; var medium: TStgMedium;
fRelease: bool): HResult; stdcall;
    {$ELSE}
    function    SetData(const formatetc: TFormatEtc; const medium:
TStgMedium; fRelease: bool): HResult; stdcall;
    {$ENDIF}

So apparently this has been an issue since v3.0.2 but I was trying to compile it with 3.2.2, which is > 3.0.2, and is the latest stable release of FPC.

I didn't even think to go try the develop branch from the repository on GitHub because I figured I would use the stable release of fpGUI on SourceForge and when I couldn't get that to work, I assumed I was doing something wrong... it was the stable release after all, and I was trying it with the latest stable release of FreePascal: 3.2.2 It never occurred to me that what is on Sorceforge would only good for versions of FreePascal Less than 3.0.2

This one change should have been pushed through and released on Source Forge the moment it was fixed, but surely when FPC 3.0.2 was released in 2017, because the this error has been preventing build from working since and including FPC 3.0.2

I made a pull request on GitHub and I hope SourceForge can be updated with this one change. It would be nice to see a new version released with all the many changes that are on the Develop branch, but I can understand how the develop branch might not have been tested enough to justify a new release. But fixing this one issue and releasing it is an easy fix to publish... there isn't much to test, it simply won't work for 3.0.2 or later without the fix, and it works fine with it. It seems like such a shame that people can't build it and therefore don't even give it a try, myself included, because I tried to get this to work years ago and didn't take the time to figure it out back then.

Now that I have it working, I have run a few of the example programs, and I must say it looks really great! I wish I took the time to get it working sooner. It seems a lot easier than fiddling around with windows API calls.

James

James Richters via fpc-pascal wrote on 1/12/24 8:36 am:

I decided to try to fix this myself, and I'm happy to say I got it working!

Well done!

I then went on to figure out that X11 is a Linux thing, but I'm on Windows.

X11 (X Window System) was originally a UNIX thing (macOS, FreeBSD/OpenBSD/NetBSD, Linux) but it has also found its way to Windows. For example, when I used to use Windows more frequently I used Cygwin to run X11 applications from remote servers. From the Cygwin website:

"Cygwin is a distribution of popular GNU and other Open Source tools running on Microsoft Windows. The core part is the Cygwin library which provides the POSIX system calls and environment these programs expect.

The Cygwin distribution contains thousands of packages from the Open Source world including most GNU tools, many BSD tools, an X server and a full set of X applications. If you're a developer you will find tools, headers and libraries allowing to write Windows console or GUI applications that make use of significant parts of the POSIX API. Cygwin allows easy porting of many Unix programs without the need for extensive changes to the source code. This includes configuring and building most of the available GNU or BSD software, including the packages included with the Cygwin distribution themselves. They can be used from one of the provided Unix shells like bash, tcsh or zsh."

Cheers,
TREV.

On Nov 30, 2024 at 11:54:21 PM, Michael Van Canneyt via fpc-pascal <

that was point there is no build system that the compiler system nows about so there’s tons of 3rd party ones which break easily. I always wondered why this information just couldn’t be part of the program file itself so everything is in one place and the compiler knows about it. Building in C, C++ and Pascal is always a sore point in my experience.

Regards,
Ryan Joseph

James Richters wrote

Thought this should be a separate thread... sorry it if ends up confusing things.

ummm... so you know: changing the subject does not create a new thread... posting a new message _/*without*/_ using (one of) the "Reply" buttons does... so while the subject has changed, it is still buried in the original long thread about how to get new users...

And the compiler is not supposed to know about it. The compiler needs to do exactly thing: compile pascal code.

python, rust, go, nodejs, they also don't know about build systems.

Each of them provides a 'build system' but it is just "make" all over but written in the language of choice.

Exactly like FPC.

I always wondered why this information just couldn’t be part of the program file itself so everything is in one place and the compiler knows about it.

Because you don't know the end-user's installation. What mac version, what windows version, what linux distro: things will be in different places.

The list of possible parameters is endless. You can't put this in in a single program file. That is why build systems were conceived: to handle this wide variety of parameters.

Building in C, C++ and Pascal is always a sore point in my experience.

Then we have very different experiences.

Whenever I meet npm, grunt, gradle, bazel, I know I'm in for a lot of trouble, conflicting versions, need to update my system, download half of the repositories on github in N different places etc.

How we got to think that downloading 1200 different packages from internet to build and install a 200-line javascript program (so basically creating a zip) is OK, will forever remain a mystery to me.

Michael.

Hi James.

James Richters wrote

I'm intrigued by FPGUI, I'm trying to build FPGUI on Windows 10, and I'm having some difficulty. When I follow the instructions from Install.txt I get this: R:\fpgui_src_1.4.1\fpgui-1.4.1\src>build

I just got back from a weekend away. I believe that is an old bug that has been fixed years ago. I just never created an official 1.4.x release since. <face-palm>

Could you switch to the "maint" branch and run the "build.bat" from inside the <fpgui>/src/ directory. That should work.

All example applications and demos should then compile with the following syntax:

fpc @extrafpc.cfg <project-name>.lpr

Regards,
Graeme

Hi Graeme,
I know how those things can get away from you, I recently saw a memory photo on Facebook from 2008, the photo taken in my kitchen and it shows a missing piece of molding that belongs on the left side of my oven.... and it's 2024 now, and that dang thing is STILL not installed... it's sitting right over there ---> and I'll be lucky if it takes me more than 5 minutes to permanently install it! Uggg @ time!

I managed to figure fpGUI out... Basically rediscovering the issue and how to fix it, only to discover later that it indeed was already fixed! But I'm glad I went through the exercise, because now I have a forked repo of fpGUI, and a little better idea what's going on.

The main issue I faced is that I was using 1.4.1 from SourceForge, and didn't even think to go look at it on GitHub... So I think it would help a LOT of potential users would benefit if you could update the download on SourceForge. If I had started out on GitHub, I would have probably seen the Maint branch and tried that, instead of spending a few days downloading FPC and trying all kinds of compiler options.

I've got the fpGUI examples working and had a look at how some of them work, and It's very impressive! I've made a few GDI windows with my Freepascal programs before, but they are clumsy and hard for me to follow.. there is a lot of constant converting between FreePascal variable types and Windows like their PChar thing. From what I see in fpGUI so far, it's just a whole lot cleaner and a lot easier to understand. I'm excited to integrate it into my projects. After I get a few things going, I could switch to the Develop branch and see if there are any issues. It seems like there is quite a lot of work that's been done in the develop branch.

James

El 2/12/24 a les 1:44, James Richters via fpc-pascal ha escrit:

I guess you don't know there's a project called Lazarus that, not only wraps the windows' api in a pascal way that's a lot easier to use (and that's not really new, Delphi did it 30 years ago), but it does it in a cross-platform manner, so that your program can be compiled under windows, linux and macos.
That's no to diminish the value of fpGUI (a toolkit that I never needed to use so I cannot speak about its merits or shortcomings), but only to tell you that what impressed you has been available for a long time (I don't remember the first version I used to deliver a project, but it was 0.9.something in 2005, almost 20 years ago).

Bye

Hi James,

James Richters wrote

there ---> and I'll be lucky if it takes me more than 5 minutes to permanently install it! Uggg @ time!

lol - yeah, I have so many of those.

I managed to figure fpGUI out... Basically rediscovering the issue and how to fix it, only to discover later that it indeed was already fixed! But I'm glad I went through the exercise, because now I have a forked repo of fpGUI, and a little better idea what's going on.

Apologies for the inconvenience. I'm very glad to hear you got it working in the end. \o/

The main issue I faced is that I was using 1.4.1 from SourceForge, and didn't even think to go look at it on GitHub... So I think it would help a LOT of potential users would benefit if you could update the download on

Good point. I'll make a plan. I use SourceForge services to run the fpGUI's website, so didn't want to abandon it [sourceforge] completely. The git repo there, is just a read-only mirror. Things could definitely be improved, because many have faced this same issue you did.

I've got the fpGUI examples working and had a look at how some of them work, and It's very impressive!

Thank you. It all came about, me wanting to understand how desktop GUI's actually work. In the end I spent a good part of 15 years developing it. lol

Regards,
Graeme

Michael Van Canneyt wrote

How we got to think that downloading 1200 different packages from internet to build and install a 200-line javascript program (so basically creating a zip) is OK, will forever remain a mystery to me.

I feel your pain, and fully agree. In our work's Java projects, we use both Maven and Gradle. Gradle is an absolute pain and we often and up debugging the build system itself. Maven is much simpler, but yes, compiling our projects (web services) downloads 1000's of JAR files on a clean environment. It's nuts! The only saving grace, is that downloads/dependencies all pull from a Maven Central Repository, making that part painless.

Regards,
Graeme

I really don't understand all this fuss.

A language is a language, a compiler is a compiler, and then there is the toolchain and the whole ecosystem, the libraries etc. There a fuzzy border between a compiler and its standard toolchain (let' it be standard, or a de facto), but FPC has what you need.

The problem with "how to get new users" is not that it is very complex Freepascal.  FPC does everything if you want to taste the language. I've compiled some programs with just an editor and the old ppc386, and worked fine.
But nowadays I use an IDE, it is much more convenient. As soon as a project becomes a little complex, uses libraries etc, no have an easy way to gather everything is a suicide. An IDE that helps you with the parameters of thousands of functions is a necessity... in Freepacal or any language.

(try to write a Java application just using Oracle java download)

I ran across this 15 min lightning talk from FOSDEM 2024 that has some good points:

Project websites that don't suck
https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3154-project-websites-that-don-t-suck/

"Does the homepage of your project website encourage potential users to try it out? Or is it actively repelling people? Even worse, could it be attracting all the wrong people?..."

Not a garbage collector but an autofree when the objects gets out of scope would be handy

procedure foo()
var
  s: *auto *TStringList;
begin
  s:=TStringList.create;
  doWhatever(s);
end;

would be equivalent to

procedure foo()
var
  s: TStringList;
begin
  s:=TStringList.create;
  try
    doWhatver(s);
  finally
    s.free;
  end
end;

Think of it, which one is more readable?

procedure foo()
var
  s1: *auto *TStringList;
  s2: *auto *TStringList;
  s3: *auto *TStringList;
begin
  s1:=TStringList.create;
  s2:=TStringList.create;
s3:=TStringList.create;
doWhatever(s1,s2,s3);
end;
procedure foo()
var
  s1: TStringList;
  s2: TStringList;
  s3: TStringList;
begin
  s1:=TStringList.create;
  try
    s2:=TStringList.create;
    try
s3:=TStringList.create;
      try
doWhatever(s1,s2,s3)
      finally
        s3.free;
      end;
    finally
      s2.free;
    end;
  finally
   s1.free;
  end
end;

_______________________________________________ fpc-pascal maillist https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

On Jan 24, 2025 at 2:10:53 AM, Santi via fpc-pascal <

Honestly this is the worst memory management strategy I've seen in any language. It's more keywords than code! It was Delphi’s idea right? If you’re making some UI app in 2025 a garbage collector or full ARC is perfectly fine so I don’t see how they get away with selling this.

Regards,
Ryan Joseph

Maybe because there's a much better way to write it:

procedure foo();
var
   s1: TStringList = nil;
   s2: TStringList = nil;
   s3: TStringList = nil;
begin
   try
     s1:=TStringList.create;
     s2:=TStringList.create;
     s3:=TStringList.create;
     doWhatever(s1,s2,s3);
   finally
     FreeAndNil(s3);
     FreeAndNil(s2);
     FreeAndNil(s1);
   end;
end;

Best regards,

Nikolay

On Jan 24, 2025 at 8:38:25 AM, Nikolay Nikolov via fpc-pascal <

I’ve basically never used try..finally in my own code but I have seen really ugly nested like about in other projects. This a down stream consequence of exceptions right?

Regards,
Ryan Joseph

Then your code will probably cause memory leaks in case of exceptions, and even worse - leaks of other resources (file handles, sockets, etc.).

This a down stream consequence of exceptions right?

That's a downstream consequence having error handling with proper cleanup, regardless of whether the language uses exceptions, or not. Consider the case, without exceptions, as is typical for procedural APIs:

function foo: LongInt;
var
   s1, s2, s3: TStringList;
begin
   s1 := Create_StringList;
   if s1=nil then

  begin

     Result := error;
     exit;
   end;
   s2 := Create_StringList;
   if s2=nil then

  begin

     Free_StringList(s1);
     Result := error;
     exit;
   end;
   s3 := Create_StringList;
   if s3=nil then

  begin

     Free_StringList(s1);
     Free_StringList(s2);
     Result := error;
     exit;
   end;
   if not doWhatever(s1, s2, s3) then

  begin

     Free_StringList(s1);
     Free_StringList(s2);
     Free_StringList(s3);
     Result := error;
     exit;
   end;

  {...etc.}

   Free_StringList(s1);
   Free_StringList(s2);
   Free_StringList(s3);
end;

As you can see, it's more complicated and more error prone. You can simplify it a little bit with goto, but it will never be better, compared to try...finally

Best regards,

Nikolay

On Jan 24, 2025 at 11:20:02 AM, Nikolay Nikolov via fpc-pascal <

ok, I’ve never used exceptions in FPC except to mean actual exceptions as in the program is corrupted so quit and exit.

I’ve seen other people put these all over their code though. I guess the idea is that they’re trying to recover from exceptions and so they need to wrap literally every single function that could fail anywhere with try…finally. I don’t have any examples but I think I’ve seen this (feel free to post any if people could think of some from real projects).

Feels to me like manual memory management and exceptions don’t mix well. I use exceptions in C# and Swift and they don’t require all this boiler plate to prevent memory leaks.

Regards,
Ryan Joseph

That's not what exceptions are meant to be used for, though. What you describe is called a program "defect". When you encounter a "defect" in your program, you terminate the program. The proper handling of a defect is to fix (modify) the program, so it doesn't happen again. In the case of a "defect", there's no much point in freeing the memory, because all of the program's memory is freed anyway, when the process terminates. An exception is used for reporting an unanticipated condition, encountered at runtime. A program can be correct (bug free) and still encounter exceptions. For example, a web browser might encounter a network error, during the loading of a web page, in which case, it should report the error to the user in its GUI, and it should continue operating normally, instead of crashing, so the user can continue browsing, by e.g. trying again, or typing in a different URL, or switching to a different tab, etc.

I fail to understand how you came to this conclusion, since I just showed how the same code would look without exceptions, and it's way worse.

Nikolay

On Jan 24, 2025 at 12:43:51 PM, Nikolay Nikolov via fpc-pascal <

Yes I know I’m just saying that’s the most I’ve done with them in Pascal. I do use them to escape deep recursion too and then they’re very helpful but I would have random allocations in a recursive that could fail randomly at any point.

Feels to me like manual memory management and exceptions don’t mix well.

I fail to understand how you came to this conclusion, since I just showed how the same code would look without exceptions, and it's way worse.

That example was the best scenario for exceptions where they’re handled in the same scope they occur and they don’t bubble up through the call stack. Once you let them bubble up you need to wrap all call sites with try..finally right? I think that’s what I’ve seen.

Regards,
Ryan Joseph

Doesn't matter whether they're handled in the same scope or not. It's the same code. Usually they're not handled in the same scope, but in a very distant place. That's usually when exceptions are convenient.

Once you let them bubble up you need to wrap all call sites with try..finally right?

Wrong. Only sites that allocate memory, that needs to be freed, before leaving the scope need a try..finally. You don't need to wrap every call. That's nonsense. The pattern is:

var

  {... initialize local vars you're going to allocate in this function with nil}

begin

  try

    {lots of code, allocations, calls, etc}

  finally

    {cleanup code}

    {free stuff that isn't nil}

   end;
end;

Nikolay

On Jan 24, 2025 at 1:34:26 PM, Nikolay Nikolov via fpc-pascal <

Yes that’s what I meant. If you don't know which calls could fail you need to wrap all functions that allocate memory in try..finally. That’s what the original post was commenting on, the need for some other syntax which knows to free a variable if the function terminates early due to an exception, like the implicit exception frames for managed types like dynamic arrays.

Regards,
Ryan Joseph

Hairy Pixels via fpc-pascal schrieb am
Fr., 24. Jan. 2025, 06:16:

Feels to me like manual memory management and exceptions don’t mix well. I use exceptions in C# and Swift and they don’t require all this boiler plate to prevent memory leaks.

Don't know about Swift, but C# uses garbage collection, so of course you won't see resource protection blocks there... 🙄

Regards,
Sven

Yes, that could probably save some typing, however it comes at a price:

1) only works for classes

2) not obvious order of destructor calls. What if they have side effects, and the order matters?

3) doesn't support procedural APIs.

In really, I find try..finally to be much nicer, because you can do a proper cleanup in the finally section that includes any of the following:

* destructor calls

* FreeMem

* Dispose

* function calls (e.g. Close(), XFree(), etc.)

And the order is well defined by you.

So, I prefer try..finally. And it's not much typing, when used properly.

Nikolay

Op 24-1-2025 om 07:56 schreef Sven Barth via fpc-pascal:

Not to avoid memory leaks, but you do need jump through hoops to get scarce resources deallocated (IIRC implement IDisposable, and hope that it gets called in time). Delphi.NET used a lot of IDisposable.