Dalija Prasnikar

4 hours ago, Lars Fosdal said:

you will need more support people.

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.

1 hour ago, Lars Fosdal said:

VS 2022 Enterprise starts at US$500/month for initial year, then slightly less than half of  that for renewal.

What prices are you comparing?

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.

3 hours ago, Lars Fosdal said:

Thanks. I just don't find it very readable - just old and established.

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.

17 hours ago, Anders Melander said:

I know the actual implementation wasn't the point, but I just can't leave code like that unchallenged. It haunts me.

I hear you... 

1 hour ago, dummzeuch said:

So if you get some source code to work on, you really go through it and add begin/end for every code block? I for one are definitely to lazy for that.

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;

9 hours ago, Dave Millington (personal) said:

Oxygene can not only load and compile your Delphi projects (via LLVM, natively) but yes -- it has a case statement with strings.

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.

1 hour ago, Javier Tarí said:

Is that what you do? If not, what did I posted that offended you so much?

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.

2 hours ago, Javier Tarí said:

Claude Code should be configured so it can compile the project it is making, and instructed to not consider a project ready until it compiles without errors, hints or warnings

Ah... if it compiles, ship it.

1 hour ago, Javier Tarí said:

I believe there are very few of us using that kind of tools on the daily workflow, and imo that's a bad thing

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.

5 hours ago, @AT said:

I do not confuse atomic operation with locking primitives. I'm refactoring some legacy code which use a lot of locking primitives mostly for updating a single "global" variable of simple type, class or pointer inside a protected code section.  So I'm planning to replace some of them with an atomic functions.

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

36 minutes ago, @AT said:

increases unsuccessful atomic exchange

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.

3 hours ago, @AT said:

As this assembler code generates multiple set of instructions (tossing register to variables and) vice versa before and after the real exchange, this actual result may be overwritten in the middle by other thread. So my concern is that the TInterlocked.Exchange is called as and atomic primitive, which is not correct in some of declared cases.

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.

4 hours ago, GabrielMoraru said:

I 100% agree with that - if the change will happen in the near future. But I was thinking about a bit more distant future. Sorry I haven't been clear on that 🙂

There is no distant future in which that code will be ported to FMX.

4 hours ago, GabrielMoraru said:

>There are huge amounts of code out there that use VCL, and moving all those to FMX would be impossible.
I know this also (but I wouldn't quite call it impossible). Unfortunately, this is what will make the adoption of FMX close to impossible.

Embarcadero has to invest its resources in two places. Since the resources are so limited, one of the frameworks suffers.

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.

4 hours ago, GabrielMoraru said:

I have seen so many companies that were ditching Delphi for something else (because they needed cross-platform support) without even considering FMX.

A company I worked with recently chose to keep its current Windows code in Delphi VCL, but for the cross-platform, they moved to C#. So, the code base is duplicated ANYWAY. Again, FMX was not deemed worthy (there was also a second reason that does not relate directly to this discussion: lack of trained Delphi programmers).

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.

4 hours ago, GabrielMoraru said:

So, in general I agree with you... as long as we can look more than 5 years into the future. For the moment the "king" lineage does not seem to decelerate its falling. It lost another (almost) 15% in the last 5 year. Another 5 years and Windows popularity will be comparable with Linux (ha ha).

Looking at the "king" line is anybody here that, with open mind and hand on his heart, feels like VCL should remain the high priority framework? 

This forum will hopeful remain here for many years. I am sure it will come a day when we will look back and see that FMX had to become the main (if not the only) Delphi framework.

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.

4 hours ago, GabrielMoraru said:

On 7/16/2025 at 9:34 AM, Dalija Prasnikar said:

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 

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.

39 minutes ago, GabrielMoraru said:

1) We need more libraries/code on GitHub (etc.) to train the AI (I published some of my libraries on GitHub in the last two years; more to come).

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. 

39 minutes ago, GabrielMoraru said:

2) We need tools like Replit or Copilot for VS that can better integrate with the IDE (I am writing one, but I am a beginner at OTA)

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.

39 minutes ago, GabrielMoraru said:

3) We need to look more into the future, ditching the VCL for FMX (here Embarcadero has the last word).

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.

1 hour ago, bravesofts said:

A Future<T> represents a value that will be available at some point in the future.

And that is still true. This value will be available at some point in the future, when you try accessing the value. If that value is not calculated by then, the call will wait until it is. The future guarantees that you will be able to get the value at that specific point without having to worry about whether it is actually ready or not. If you want to access that value immediately, then you don't need future. If you want to avoid blocking UI, then again you don't need future, just run the code in the task or other kind of background thread.

Also you should not compare Delphi with other languages that support async/await and which will not block the UI.

If you want a future which works with callbacks you should not use PPL future but something else. I have one variant here https://github.com/dalijap/code-delphi-async/tree/master/Part4/24.2 TValue future

26 minutes ago, bravesofts said:

but how "my some code" that is between knows exactlly how to continue while future still not ready, inorder to avoid app touching in bad time the 

You don't and that is the whole purpose of blocking Future, to wait until the result can be used. If you don't want to block, then don't use future at all. Just use task instead.

You are trying to solve the problem that does not exists. Task is async, future is just a blocking task. Trying to make PPL future async is pointless.

1 hour ago, bravesofts said:

could you please introduce real work scenario where Future blocking call is usefull.

It can be useful if you have some code running between the point where you start future and point where you retrieve its value:

LFuture := TTask.Future<Integer>(...); // start future task
// ... some other code 
LFuture.Value // use future value  

If you just start future and then immediately ask for its value then future is completely useless:

LFuture := TTask.Future<Integer>(...); // start future task
LFuture.Value // use future value  

The whole point of Delphi Future implementation is to be a blocking call. Now, we can discuss whether this kind of design is useful or not and in which circumstances. 

However, your improved Future is mostly useless. Instead of creating a future and then resolving it in additional task (you are involving two threads here) you should just run the code in the task and that is it.

Simply use

TTask.Run(
  procedure
  begin
    var LValue := (...);
    TThread.Queue(nil, procedure begin
      LogReply('Result: ' + LValue.ToString); // update UI on main thread that service the TTask
    end);
  end);

No need to overcomplicate things.

This has only been an issue if you make a mess out of your code design. In rare situations where you do need circular references using implementation section in one unit will suffice. I doubt that proposed changes would bring too much overall benefit and they would require extensive rework of the existing compiler architecture. 

There is existing feature which would be more beneficial for code organization: class helpers. Currently there is only a single supported helper in scope and having multiple ones would allow breaking down more complex code and organizing it into separate files. Implementing those would be a much simpler task, consistent with the existing architecture.

5 hours ago, David Heffernan said:

Is there any known use case other than the one demonstrated by FreeAndNil, namely to allow modification of a const param?

I think that original need to introducing [ref] was the need to force passing value parameters as references so they would match some cross platform API. I don't remember whether that was merely a difference between 32-bit and 64-bit Windows platforms, or there were other OS involved. I also don't remember whether C++ Builder support also had something to do with it. AFAIK, Allen Bauer explained this somewhere. I am not sure if this was only on his blog or it was also mentioned on old forums.

New FreeAndNil implementation came years later and it merely used the feature that was introduced for other reasons.

Some additional options. You can view form or frame as text and doing the copy paste there. It is faster than doing it in the designer. Another way is aligning other panels to the bottom, and then aligning them back to top in order you want them.

Few notes.

First, when using free AI variants, your code will end up in the AI training data. And I wouldn't trust paid versions either. You need to be very careful that you don't give AI access to sensitive code that contains data which should not end up there. It is also very easy to do that by accident and it is prudent to run AI interactions in restricted environment like VM where you will have only non sensitive code.

Next, anything that AI gives out needs to be carefully reviewed by human. AI often hallucinates and sometimes those hallucinations are not as obvious. This is especially important for code which requires some detailed explanations about how it works and why or some reasoning only person who wrote the code can answer (or the reasons are written in some other documents like specifications or design). 

Similar goes to writing tests with AI help. 

One of the huge problems with AI usage, is that with time, reviewing its output becomes a mundane task and this is where mistakes can more easily creep in.

52 minutes ago, Angus Robertson said:

My major annoyance with Windows 11 is they keep changing File Explorer, rarely for the better.  Specifically there is a new right click menu with the default options, but you have to click again on Show More Options to see the historic menu we've had for 25 years with addon like TortoiseGit, TortoiseSVN, 7Zip, etc.  

You can fix that to show old menu options. Works fine. See https://superuser.com/q/1674122/464320 

5 hours ago, David Heffernan said:

But who honestly wants to go back to 98 or XP? 

I would go back to Vista or Win 7 in blink of an eye.  I would be thrilled if I could have stayed on Win 10, too. 

Windows 11 is by far the worst Windows version ever (and I could not believe this was possible after Windows 8). There are zero new features I want to have and they messed up everything else. 

For start half of the things no longer cannot be configured. Taskbar height is too big, colors and icons are awful, Windows theme even worse (selection colors, checkboxes, and similar), you need ten clicks more to do things, fonts are total nightmare and cannot be uninstalled. Whoever designed that Cascadia Mono font needs to be tarred and feathered. It is absolutely illegible and half of the websites are using is as the default monospace font.

And this is just scratching the surface...