Leaderboard

Update: I have now completed a massive set of minor changes, affecting over 1400 units. Removed all units from uses clauses which were not needed, and demoted from interface to implementation, where possible. The other change was to add a module to manage unit initialization, rather than leaving that to Delphi. All initialization and finalization clauses have been replaced by procedures. That should leave us less susceptible to sequence issues as we continue to resolve the coupling issues. In the process, also reduced by about 25% the unit dependency cycles identified by MMX. And in my VM on an SSD, the time for a first full build after loading the IDE dropped from nearly 4 minutes to about 40 seconds. Progress.

There is a german saying: Kaum macht man es richtig,funktioniert es. It roughly translates to: As soon as you do it right, it works. It is all too true for most everything 😄

No LLVM optimization is really disappointing. If you wind the clock back to 1995, many of the early developers coming from VB3 were exited about a compiled executable that ran at the same speed as "C" programs. They wanted and valued fast executables. Borland / Codegear / Embarcadero have each ignored this value their developers place on fast code and haven't improved the code optimization for 20 years. It seems they take a, "it's good enough" view. I'd encourage them to invest some time and include all the optimizations that LLVM offers (even if it slows down compilation speed for the Release Build). I think they'd be surprised at how well this would be received by the Delphi community. Steve

TOC and book preview here: https://books.google.com.br/books/about/Introducing_Delphi_ORM.html?id=LuWmDwAAQBAJ&source=kp_book_description&redir_esc=y

https://community.idera.com/developer-tools/b/blog/posts/august-2019-delphi-android-beta-plans-august-roadmap-update Here’s what’s planned for 10.3.3: Platform Enhancements iOS 13 & macOS Catalina Support RAD Server Deployment with Docker C++ Expand C++ libraries support Delphi Android 64-bit platform support User Experience Further IDE UI/UX Improvements New Downloads/Licensing Portal Quality Focus Areas App Tethering for VCL and FMX IDE Quality C++ Toolchain performance and quality improvements With the addition of 10.3.3 this fall, we’re now planning the 10.4 release for early in 2020. As outlined in our May 2019 PM roadmap commentary blog post, 10.4 is going to focus on improved code tooling, language enhancements, VCL High DPI styles, RAD Server enhancements, FireMonkey features and quality and more.

I remember Windows introduced manifest resources into exe files at some version and they also control the mapping to one of the versions of comctrl.dll that is present in the system. Could a manually modified .manifest file be causing this problem?

If it's too slow for you, buy a faster computer™

Compiler optimization Bug fixing Support for current versions of the supported OSes Finished. That is what I expect from 10.3.3. Looks like some of it is being done. So: Bravo. I really don't need new language features, but that's just old unflexible me. Then there's the trend to issue a major release early in a year and getting it fixed by the end of it, only to start the cycle again a couple of weeks later. That is tedious.

Ancient. Yes, the IdObjs and IdSys units were removed from Indy well over a decade ago. Any code that references them is severely outdated and needs to be updated to a modern version. The GitHub repository is just a mirror, the real repository is still on SVN instead. So the Git history may not have everything. When the IdObjs/IdSy units were removed, TIdThreadList was replaced with the RTL's standard TThreadList (and various other compatibility classes were likewise replaced with standard equivalents - TIdStrings -> TStrings, etc).

Thanks, your changes are in SVN. Angus

10.4 has "language improvements". Some of the stuff I'd want to see here - although I expect only the two top ones to actually be candidates... - parameterless record constructors - nullable types - proper record constants that are treated as constants - generic support for nullable types - generic constraint for enumerated types so that you can for a Value:T use Ord(Value), Set of T, Value in Set, etc. - generic constraint for number, so that you can use mathematical operators on a value of T - generic record helpers - TArray<T> / record helper for TArray<T> - helper aggregation/overload/scoping so that one helper does not have to replace another - lambda expressions - ternary operator to shorten those lambdas

The list of known classes is built from parsing the project files (if checked) and the files opened in the editor (at least once when Persistent Module Information is checked). F.i. to add TInterfacedObjectEx to the known types list, the unit Spring.pas either has to be included in the project or opened in the editor so that MMX can parse the source. The parsed modules with the types declared are stored per IDE and MMX version in %LOCALAPPDATA%\Raabe Software\MMX Code Explorer\15.0\BDS20_known_modules.xml (for MMX15 in Delphi Rio). You can inspect that file for the missing type identifiers.