Leaderboard

I think moving from SVN to Git had quite a steep learning curve, but only because I was accustomed to using SVN and mostly for single-developer projects. Once I finally "got" Git I never want to go back, even for projects nobody but me works with, but ESPECIALLY on a project that has more than one concurrent developer. SVN is slow and restrictive in comparison.

My impression of VSCode as an editor is that it is light-years ahead of Delphi as an editor. Of course, Delphi does more for me because it integrates with the form designer. However, if an Electron app can smoothly lint multiple interpretated languages for me without slowdown or just mysteriously stopping the linting, as LSP in Delphi often does, one wonders what the advantages to all this native code is in the first place. And I do know the advantages -- it just burns a bit that I can't really experience them in the very IDE I am using to build native applications.

As a person who once converted a lib from C to Delphi, I'd suggest to consider other options like building DLL and linking to it (the easiest) or building OBJ and linking them (more complex but possible) or even using CBuilder to compile both C and Delphi sources. Converting is boring and applying changes every time is 10x more boring.

Can you try with the latest version V15.1.6 please? As I wasn't able to reproduce it at will, I cannot be sure to actually have fixed it.

This is not true. You can use an inline variable declaration. https://docwiki.embarcadero.com/RADStudio/en/Inline_Variable_Declaration Please don't tell us we are jerks. That's just offensive and rude.

Are you Roman? What do you expect from "StrToInt('x')" ? 10 ?

Nice! To bad that there's no chance in hell that the Delphi compiler can compile it branchless. It could be hand-coded in asm but then the call to the comparer can't be inlined, making the whole thing pointless.

Are you sure that poor speed is acceptable on desktop applications? What about applications that need to load complex forms where opening such form can take half a minute or more? Or when you need to create plenty of business objects, or when you need to do some textual processing. Good compiler means a lot in such cases. In last few Delphi releases @Stefan Glienke has continuously submitted hand crafted code to improve speed of some widely used RTL routines that have impact on overall performance. With better compiler that would not be necessary. Not only that, but with better compiler all other code we write would be faster and when speed matters we wouldn't have to bend over backwards, writing horribly unreadable code just to get the speed we need. We could just write the clean and readable and maintainable code and leave the dirty work to the compiler. Speed always matters. Now, Delphi still might be fast enough for many purposes, but for many that is simply not enough. Once it was state of the art compiler, now it is seriously falling behind.

FPluginTimer.Enabled := False; if (Assigned(FPluginTimer)) then FreeAndNil(FPluginTimer); That part doesn't make much sense. Either FPluginTimer is assigned, then you can simply FreeAndNil it, or it isn't, then the first line will cause an AV. I don't really like the fact that it needs to use a TTimer, but if there is no other way to be notified when the the interface becomes available... You also should put all that into IFDEFs because the code won't compile with anything earlier than Delphi 11.

Fixed it: If you encounter this issue open the project's .dproj file with notepad and search for the <EnabledSysJars> tag. Remove the content between the <EnabledSysJars></EnabledSysJars> tag. and save the file. Building should work now.