Jump to content
aehimself

Delphi 10.4 compiler going senile

Recommended Posts

I have a project, with multiple source files added from other projects. For a while now I switched from TRTLCriticalSection to TMonitor as it requires no additional unit imports and should be more cross-platform (?) than the prior.

Now; most of the said imported files are using TMonitors the usual way:

TMonitor.Enter(Self);
Try
 // Do stuff
Finally
 TMonitor.Exit(Self);
End;

Works like a charm. I added a new VCL form and a private worker thread implementation. In this new unit, I can not use TMonitor.Enter as the compiler says the method does not exist!

 

image.png.29675a49fbd2c97cb36ef52a4eee8a3b.png

 

Ctrl-clicking on TMonitor in the working and the non-working source file both redirects me to the same TMonitor implementation; System.pas:817. Hovering the mouse shows the same tooltip - record, declared in System.pas.

 

Which is even more strange, the project can not even be compiled if I leave the underlined TMonitor calls in this one source file so I suspect it's not only LSP. At the moment I changed TMonitors to TCriticalSections in this file and it is working fine this way.

 

Has anyone seen this issue so far? Any tips how I can make it to work?

 

Share this post


Link to post

We have a winner.

 

image.png.ead31035c5aed66ecf1b0b1d4a9e3c06.png

 

The only thing which bugs me now, if I look up the class declaration, why it redirects me to System.TMonitor in this case...? This is why I did not even think about a different class with the same name in a different unit.

Share this post


Link to post
10 hours ago, Vandrovnik said:

A conflict with tMonitor declared in Vcl.Forms.pas?

Yeah.  They should really rename either System.TMonitor or Vcl.Forms.TMonitor to avoid that conflict.  Frankly, I never understood why the System one was named TMonitor to begin with.  Since it is inherently tied to TObject, maybe something more like TObjectLock, TObjectSync, TObjectMonitor, etc would have made more sense.  Of course, on the flip side, for the Vcl.Forms one, maybe something more like TDisplayMonitor, TScreenMonitor, etc would have made more sense.

 

Oh well, too late now, I guess.

  • Like 1

Share this post


Link to post
3 minutes ago, Remy Lebeau said:

I really wish Delphi would stop mimicking DotNet.  Delphi IS NOT DotNet!

I don't have a problem with it - the DotNet api is really quite nice, broad functionality, well tested, well documented. Nothing wrong with using it for inspiration. 

 

What I wish more than anything is that Embarcadero stops releasing unfinished untested features. 10.4 is up there amongst the worst Delphi releases ever and pretty much unusable for me. LSP is half baked, the IDE is a mess, the debugger barely works and it;s a sloth. The VCL is ruined by poor implementation of themes - flicker everywhere. 

 

  • Like 2
  • Haha 1

Share this post


Link to post
Guest
8 hours ago, Remy Lebeau said:

Delphi IS NOT DotNet!

 

8 hours ago, Vincent Parrett said:

Nothing wrong with using it for inspiration. 

I can't be more conflicted between these both phrases, yet both are quite true and right.

 

One thing though, Embarcadero should hire more experienced .NET developer to build the IDE right !

 

I saw some discrepancy in the .NET part of the IDE, which is big part of it, something wrong with performance counters, like they been left on and had been forgotten and untouched since Delphi 2009 (at least) to Seattle (at least), i can't be sure, but there is something wrong in that part, the memory usage and the calling stacks keep pointing that code built for profiling not for production, that behaviour is not observed in other .NET applications, and yes the RAD IDE eligible to be called .NET application.

Share this post


Link to post
22 minutes ago, Kas Ob. said:

Embarcadero should hire more experienced .NET developer to build the IDE right !

Oh, I meant to have heard that they are trying to eliminate the dependence on DotNet 🤔

  • Like 2

Share this post


Link to post
Guest

Our IDE's are literally one Windows update from obsoletion, up to Seattle the .NET version is 2 (the newer too, i am guessing here) , although the death date is unclear, Microsoft mentioned the end of life first time in 2011, the resources about that on the internet is contradicted and unobvious, but surely enough it is coming, so be careful when you update your Windows 10.

 

 

9 minutes ago, Uwe Raabe said:

Oh, I meant to have heard that they are trying to eliminate the dependence on DotNet 🤔

Sure, they need few days to wrap up the LSP and visual assist... and, oh a new linker ! how we can live without a new linker ?!

Share this post


Link to post
1 minute ago, Kas Ob. said:

Our IDE's are literally one Windows update from obsoletion, up to Seattle the .NET version is 2 (the newer too, i am guessing here) ,

Maybe Delphi should be designed as a plugin for VsCode, and FMX could be an extension for PlatformIO :classic_smile:

( Oh my, TMS is halfway on the direction to that :classic_wacko: )

Share this post


Link to post
9 hours ago, Remy Lebeau said:

I really wish Delphi would stop mimicking DotNet.  Delphi IS NOT DotNet!

Aye, there's the rub.

I propose exchanging DotNet with <SomeLanguage>. But folks keep saying "I want <SomeLanguage> feature x, because that is so cool, and I simply can't write my application without it". And then we get some half cooked thing which resembles <SomeLanguage> feature x by intent, but is buggy and breaks other stuff...

Share this post


Link to post
Guest
1 minute ago, Rollo62 said:

Maybe Delphi should be designed as a plugin for VsCode, and FMX could be an extension for PlatformIO :classic_smile:

OMG, please no ! My VS is working fine and never had seen a crash there !

 

2 minutes ago, Rollo62 said:

( Oh my, TMS is halfway on the direction to that :classic_wacko: )

OMG, please yes ! My VS will be my most used IDE ever !

Share this post


Link to post
11 hours ago, Remy Lebeau said:

I really wish Delphi would stop mimicking DotNet.  Delphi IS NOT DotNet!

I wish when they did (most of all that .NET API inspired copies happened years ago) they actually did not mindlessly copy it:

- Monitor... I think C# at that time already had the lock keyword which does all that underneath to avoid boilerplate,

- generics and mostly type constraints - understanding that class in C# is a constraint on reference types and not only on classes and that struct is a constraint for value types. Porting that properly to Delphi which has kind of hybrid types such as string or dynamic array.

- System.IEnumerable and IEnumerable<T> and that in Delphi without a rooted type system it does not make a bloody sense to inherit the generic one from the non generic one

- System.IOUtils - plagued with ton's of bugs and a rather terrible API and performance

 

I think there are more examples.

 

.NET is not perfect but I am amazed how much effort goes into it - how APIs are being improved (and yes mostly without breaking them - the issue with inventing and dropping things is mostly in the eco system that builds upon it).

Damn they even care about binary size for their guard code! (see the comment in https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/ThrowHelper.cs)

Recently they refactored many APIs to use Span<T> to avoid unnecessary allocations - while in Delphi we still allocate strings all over the place when using the stringhelper methods for example and only the people that care for performance then do all that ugly mess with PChar.

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×