Leaderboard

Having good core libraries is essential. Otherwise everybody keeps rolling their own. At the end if you have to use multiple libraries they tend to be incompatible and have duplicated code. So +1000 for having things fixed at the root. Same goes for IDE. Every time some basic functionality is either broken or missing, we need to push harder to have that functionality fixed without relying of various plugins. Having said that, I have utmost respect for all people devoting their time creating those valuable tools and libraries.

I would prefer when PPL would be fixed and stabilized instead of not being used at all. There is a couple of functionality in Delphi that relies on PPL and that would need to be reinvented where another external library is used. The lack of manpower dedicated to this part of the RTL (and a lot of others) is a real drawback. I wish Embarcadero would allow more participation from the community or at least all the MVPs that already offered their help in these areas. Another option would be to open source the standard libraries and accept pull requests, but that seems to be only at the edge of their radar - if at all.

Hey, you deal with the Delphi IDE long enough, you need a fistful of cheap unmarked pills of dubious provenance to get through the day!

We have a catch 22 here. If stuff does not work I don't use it - especially if it tries to solve a task that has already been solved years ago. So if people don't use it less people are affected by bugs and less likely it is they get fixed - however even when issues are being reported by many people it takes time to fix them and only with an upgrade you get those fixes. With a library like OTL you don't need to upgrade your entire IDE to get some bugfix. This is the fundamental flaw you have when IDE, compiler and runtime are so tightly coupled that they cannot be upgraded individually. That plus a lack of quality control.

That made me curious and I looked it up: https://stackoverflow.com/questions/54733581/which-operators-in-c-have-wrong-precedence The bit operators in C indeed have a non-optimal operator precedence. I'm also more in favor of breaking changes in programming languages. C++ has tools that do code modernization like the modernization module of clang-tidy: https://clang.llvm.org/extra/clang-tidy/index.html I like how in C++ standards they first deprecated a feature in a standard version and then remove it in the next version of the standard. This gives compilers the change to show warnings for the deprecated feature and the users time to fix their code.

I'm attempting a new release of DDService adding support for XE7 and later. Collected original SvcMgr.pas files from all versions if Delphi, think I have to update each new one to DDSvMrg,pas and then create DIFF files using WinMerge. Not too hard, since there is only a single service bug fix (quoting image path) in 15 years and Arno fixed that in 2008. But are there any other service handler bugs in DDService that should be fixed for a new release? I also want to add an example of how to use DDService for dual GUI/service , there is a demo CombiService on my system but not tried it and not sure where it came from Has anyone done this with DDService? Angus

As long as they are round and colorful I'll take 'em.

What you are trying to do is possible. I guess there is just a mistake somewhere, or some extra detail that we don't know of yet.

I have seen many people report many problems with the PPL over the years. And for that reason, I REFUSE to ever use the PPL at all. I don't trust it. It hasn't worked right since day 1, and Embarcadero just can't seem to get it right. I prefer to stay in control of my own threads.

You are right, SynCrypto is fine with FMX running on Windows - and it uses RawByteString or TBytes as required since Delphi 2009. But it is not a OS compatibility problem - it is a compiler issue. To be fair, it's Delphi cross-platform compiler/RTL which is designed poorly, especially all the backward compatibility breaks they made about strings and heap. Their recent step back is a clear hint of their bad design choices. There is no problem to use SynCrypto on Windows, Linux, BSD, Darwin, for Intel/AMD or ARM 32-bit or 64-bit CPU, if you use FPC. But we didn't lose time with targets breaking too much the existing code base. I am happy I didn't spend weeks making mORMot ARC-compatible - which is now deprecated! - and focused instead on FPC compatibility and tuning. Which was very rewarding.

"Might or might not". Sleep is a good tool to demonstrate a bug. But I agree with you - if it works with Sleep, it still may not work with a high CPU load code. So proving with "Sleep" that the library works is not good enough. OTOH, proving with a high CPU load code that it works is also not good enough. "Unit tests can only be used to prove that a parallel code is NOT working." - me (BTW, I know that we agree here 🙂 I just wanted to state that testing parallel code with Sleep is a perfectly good tool. It is just not good enough.)

Please amend the title. The title should IMO reflect the contents of the post, which "-------" does not.

Make a small testcase to demo the bug so others can confirm it or point to error in code.

Please allow me to disagree. I have made non-trivial use of System.Threading in PyScripter (used by thousands of users) without any problems. The main issue I know of with the library is RSP-11267. You can see a fix in that report, but even without the fix you can work around the issue by using a different mechanism for signalling task to stop As for Parallel.For I have not used it extensively, but you can see some code of mine in this StackOverflow question that I think is now used in a commercial product. An issue with thread creation by Parallel.For (RSP-21177) has been fixed in Rio. Advantages of System.Threading: By far the easiest way to use tasks (as opposed to threads) in your delphi application Nice interface using anonymous methods Avoids third-party dependencies It provides usage statistics that can be used for diagnostic purposes Nowadays, it provides good performance out of the box, but you can still fine-tune the way it works if you are prepared to dig-in It uses state-of-the-art synchronization techniques @Primož Gabrijelčič can correct me on this, but by reading his book "Delphi High Performance", I think, that depending on the type of use, is competitive if not faster than his own OmniThreadLibrary The Parallel library, like many other new features of Delphi (e.g. Generics) got a bad reputation, due to the many bugs in the early days. Unfortunately. trust is easy to lose and very hard to rebuild. But the library does deserves some love from Embarcadero (fixing remaining issues) and Delphi users.