Dalija Prasnikar

Yes, but that makes usage of such classes more convoluted on the Delphi side.

First of all, TThread is a very old class. It is an abstract class and it needs to have its features available to the descendants. Because it is old, some of the added features might have not been there from the start and there may have been constraints on how the class could be extended. Also, you cannot use configurable properties unless you have a reference and once you have a reference you cannot easily say it shouldn't be used. And because of C++ Builder integration you cannot have overloaded constructors. So, making TThread and some of its descendants more fool proof would have negative impact on all code which uses it. Now, some additional protection could be implemented without adding too much cruft, but that could also have impact on how one can use the whole TThread class and its flexibility. And at the end of the day, any such measures you can implement on the base class, could be easily rendered useless in the descendant classes. So you would be back at the square one as developers can easily shoot themselves in the foot if they have never read the documentation. I guess that trying to protect what is basically unprotectable was never deemed too important because it would be mostly futile endeavor, and threading is a more advanced feature which requires some knowledge anyway or one can make a huge mess from which nobody can protect you. The behaviors are documented and all what is needed is reading the documentation.

Because TThread can be self destroying or not based on the value in FreeOnTerminate property which can be configured after construction. Besides that property, there are others that can be configured before thread starts running, Also how would you prevent developers from taking reference of any abstract class that is meant to be extended and is therefore publicly accessible?

I guess it was not anticipated that developers would store references to self destroying threads. And without having a reference you cannot wait for such thread. References to self destroying threads basically become invalid the moment the thread is started and they can only be used for initial configuration for threads that were created in suspended state. Once thread starts running, you should not touch the reference anymore. From documentation: https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.CreateAnonymousThread https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.FreeOnTerminate I am not going to discuss about how one can potentially use anonymous threads beyond their intended purpose: being fire and forget kind of thread, because such code can be very fragile and cause more problems than it solves. And like I mentioned earlier in this thread, without having a very specific code and a use case, it can be hard to discuss potential problems and solutions because in multithreading even slight changes in code and how it is used can make a huge difference and break it.

You don't need to post the code within Execute. We just need to know how are you creating and waiting for a thread. Is it a self destroying thread, or not. If it is self destroying thread with FreeOnTerminate set to True, then you cannot wait for it. If you need a waitable thread, just use a thread with manual memory management and free it when you are done. There is nothing wrong with creating and destroying thread when you need one. The only problem with recreation is that creating and starting a thread takes some small amount of time, and if you need to do that frequently (multiple times in a second) then such code will have some small impact on performance.

It would help if you can post the code example here. With threads even slight change in code can make a difference. But the example in the link shows waiting for self destroying thread and this is something which cannot be done with such thread. Hanging is expected behavior.

No. You need separate client for each request if you want to run them in parallel.

This is a slippery slope. Some of use still remember Adobe.

I am not sure I want to go in such subscription model direction. At the end value such subscription provides would be to small for the paid price, or it would have to be extremely cheap (10-20$ a month) with ability to use same Delphi version without forced upgrade. But even then I don't think that would solve the problem. Persistent licenses are the only good model for development tools, nobody will start developing anything (not even as a hobby) in a tool they might not be able to pay at some point and can lose access (even with stepping in and out, as vendor can always change the pricing model). The main problem is the base price for the lowest SKU (PRO) itself which is too steep comparing to other paid and free options available.

When it comes to NX Horizon implementation, it is its simplicity and "lack" of some features what makes it both fast and thread-safe. Because it is simple, it can also be easily adapted or extended according to particular needs. For instance, adding channels can be done by adding thread-safe dictionary which would hold multiple event bus instance, one for each channel besides the default one.

Support for what? There is no free support. Only for installation problems and I don't think there are to many of those. Embarcadero needs to lower low end prices to bring in new users. I doubt there are many prospective new users willing to shell out over 1600$ on new PRO license. Not to mention that there is no upgrade path for existing users with old versions. They need to pay full price.

VS Studio PRO one time purchase is 499$ https://www.microsoft.com/en-us/d/visual-studio-professional-2022/dg7gmgf0d3sj Also VS 2022 Enterprise includes Azure and other stuff. There is also as subscription only Enterprise which is 250$ per user monthly again with basic Azure plan. And there is PRO subscription which is 45$ per user monthly. Right now RAD Studio is extremely overpriced. I cannot comment on Enterprise version and the value it provides, but PRO is literally out of reach for many people who would otherwise more than willing to pay some amount of money comparable to what JetBrains or MS offer on the low end. Not to mention that it does not include Linux compiler which is rather ridiculous. Compare that to Delphi 99$ license with which they started 30years ago (which is around 250-300$) in today's value. If Embarcaderos wants to revive Delphi, they seriously need to change their pricing policy on the low end for PRO SKU and even having additional low cost Community edition with perpetual license would take them a long way.

Beauty is in the eye of the beholder. I literally get dizzy trying to read your code formatting. Even with braces I very much dislike any style besides Allman, and in Pascal, begin and end absolutely must be on the same vertical line for me.

I hear you...

And then you write things like this https://quality.embarcadero.com/browse/RSP-23924 function TBaseFoo.BrokenFoo: IFoo; var LOwner: TComponent; begin Result := nil; if Supports(Self, IFoo) then Result := Self as IFoo else LOwner := Owner; // if block execution will continue here !!!! while LOwner <> nil do begin if Supports(LOwner, IFoo) then begin Result := LOwner as IFoo; Break; end else LOwner := LOwner.Owner; end; end;

Oxygene has plenty of features that would be great to have in Delphi. I wanted to have a case statement with strings for years now. I think it was even reported in the old, old Quality Central. If may look like a simple thing but it makes code more readable. Now when we got if expressions, maybe we wil eventually get case with strings, too.

No, but that is apparently what you are suggesting is enough. Maybe I got what you are saying wrong. But there is way more to code than being able to compile it.

Ah... if it compiles, ship it.

I would say that is a good thing. This means in the future Delphi will still have a solid base of developers who know how to write their code.

I selected "Existing forums are sufficient", because they definitely are sufficient and can cater for topics around using AI in Delphi. I am also monitoring all activity on this forum, so it does not matter to me whether such posts have another subforum or not.

You should be very careful when doing this, because not all code logic protected with locks can be replaced with atomic operations.

What do you mean by this? If there are multiple threads trying to do such atomic operation on a variable, then only single one will succeed regardless of which method is called. And one thread will always be successful. That is the whole point of atomic operation. You should also remember that in multithreading there is no guarantee which thread will be able to make the atomic exchange nor which thread will be able to acquire some lock. Even if 100 times operation happens in particular order, that does not mean that it will happen in the same order the next time.

It is atomic, because only one thread will be able to make the exchange and retrieve non-nil value stored in the Src variable, provided that all other threads also use atomic exchange. The extra shuffling does not matter for atomicity as the shuffled values before the call are not related to the value stored in the Src variable (one that will be atomically exchanged by lock xchg instruction). Note that lea instruction loads the address, not the value stored in memory location.

There is no distant future in which that code will be ported to FMX. VCL is mature framework, and it requires very little work. Also you should keep in mind that IDE is also written with VCL. FMX does not suffer because VCL exists, it is the other way around. VCL received very little love, fixes and new features since Delphi became cross-platform. Don't blame VCL for that. The reasons for such choice are probably multifold. Today, I would certainly choose Delphi for cross-platform as the major problems for cross-platform have been resolved, even there are still issues which make such development harder than it should be. Again, VCL, is not high priority framework. Most of new development and features go to FMX. VCL has been a second class-citizen ever since XE2. And again, killing VCL would kill Delphi. The only thing that can kill it, is if MS ditches Win32 API support and that is not likely happening either. Am I asking for that much? Why should we be second-hand class citizens? Others have it in their editor. Why shouldn't we? If I use VSCode instead of Delphi, why not switching to VSCode permanently? (joking) Because not everyone uses AI and there are way more important features that would benefit all Delphi developers. I wish that Embarcadero would be able to work on everything needed, but the truth is that they cannot do everything and they need to prioritize. If you think that Embarcadero does not have resources to maintain VCL, then you will surely understand that. Anything AI related in IDE takes time away from other non-AI related features and lack of AI integration is not critical as it can be successfully used with the help of other tools. I am also using VSCode a lot (not AI related) when working on Delphi code and yes, I would like it better if I could avoid that and do everything directly in Delphi IDE.

We are no magicians. We cannot create code which does not exist. There is simply not enough Delphi code around for AI training. It is easy to have good coverage for JavaScript and similar where you literally have bazillion web pages available for scraping, where plenty of them virtually repeat the most common, required functionality. Pushing for more publicly available code without considering its quality, can also backfire. What we need is better non-AI code completion. If you need to generate larger chunks, then you don't have to do that directly within the IDE. Also you can easily use some other editor, like VSCode to give AI access to context and generating code, and then simply reload changed files in IDE. This works fine in both ways. This is not a showstopper. Ditching VCL would be the most stupid idea ever. It would be suicidal. There are huge amounts of code out there that use VCL, and moving all those to FMX would be impossible. And this is not just about old code, people use VCL for writing new code, too. Because they already have all the other infrastructure built around VCL. I am certainly not going to start new Windows application based on FMX, unless I really need some of its features. What could help this transition would be restructuring VCL and FMX to use common Application layer which would enable mixing VCL and FMX frameworks in the same application. However, this is also something that is not very likely to happen as both frameworks are rather mature at this point and such restructuring could have impact on backward compatibility. Maybe having support for multiple helpers in scope and opening up private parts of VCL and FMX allowing more customizations from the ground up could help in such transition. But this would be long term and slow process.