Stefan Glienke

I noticed that 10.2 noticably slows down due to the progress dialog. When compiling the exact same code in the commandline compiler or without the dialog. It even has been reported (https://quality.embarcadero.com/browse/RSP-22056) - not sure exactly what has been done since then as we won't upgrade from 10.1 for other reasons so my 10.2 and 10.3 installations don't see any huge projects.

Especially with DevExpress everything should be setup perfectly if you run their setup. You only end up recompiling their sources (and even if that should not affect linking time it adds a bunch to the compile time) if you manually put the directories with their sources into your library or project search path. Within the DevExpress installation directory there should be a Library folder (besides all the different ExpressWhatever folders for their different component suites). That Library folder contains all the dcus along with dfm and res files being produced by the compilation during their setup. That directory is being put into the library path. If anything else is the case then that is not ideal. P.S.: If you don't mind and are able to send me the map file of your application and I can quickly run that through some tool I wrote to peek if it suffers from heavy generic bloat.

No, it's not a good practice - write your classes in a way that you could do pure DI. If you do field injection that code can't run without a DI container or some other ways to do such injection. If you have too many ctor arguments you are suffering from so called constructor over-injection and there is a way to solve this: refactor your code and respect the single responsibility principle - see https://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/ Always think of a DI container as something like an automated assembling plant - all the screws and pieces that are put together there by robots don't know of the assembling plant. You can as well grab a screwdriver or some other tool yourself and put the pieces together manually with a lot of work and sweat but it's possible.

iirc circular units should affect the compiling but not the linking phase but I could be wrong. Extremely long linking phase for has been almost always a result of extensive use of generics (either through third party or your own) because the linker then has to look through all the dcus and remove identical ones (for example every unit that uses a TList<Integer> has the code for that entire class emitted into its dcu which the linker then has to read again fix up pointers and write that to the final binary which only contains one copy of TList<Integer> - but also one for TList<string>, TList<TPerson>, TList<TcxWhatever>, ....) Also sometimes very innocent looking generic APIs can cause a huge clusterf... of types being emitted into the dcus if one is not careful (I should know I wrote such APIs ^^) Look into the dcu output directly and tell us the size of all dcus combined - that should give a rough estimate if that is the cause or not

Personally I also find threads annoying that have multiple posts after each other from the same person. Possible solutions: - make posts editable for a reasonable amount of time so people don't have to multipost but can amend to their previous one - moderate and manually squash such posts into one

Next to the "unread content" one just like at the bottom I would say

Open the ico, remove all layers but 32x32, change the compression from bmp to png, save, done :) P.S. There you go favicon32.ico FWIW https://www.delphipraxis.net/favicon.ico has only 16x16

TestInsight does no magic in terms of "running tests" - it simply does the same as Run/Run without debugging. The client code then communicates via tcp/ip to the IDE to ask which tests are checked when you only want to run a limited selection and reports the results. However in the few times that I had to run tests on mobile myself the experience is not as smooth as with windows, linux or osx that all support some UI less application that simply starts, runs tests and closes. So I usually had some minimal FMX UI that showed the tests and had a run button or something.

Yes, DUnit (TestFramework.pas) compiles on all platforms that Delphi supports. I think many developers don't really understand the architecture of DUnit - its just a bunch of interfaces and classes using the observer pattern to listen to events like test started, test ended, test passed, test failed. That is what things like the DUnit GUI Runner or the TestInsight client listen to - well in a nutshell, the VCL GUI runner that we all know does a bit more like allowing to select individual tests and only run those but that all works through that interface. So you can implement that interface on any platform or UI or non UI framework you like. All the stuff that I added to make attributes with with DUnit is just ontop - like using enhanced RTTI to discover attributes on the test case methods, read their data and create testcases from that data. Usually it uses the classic rtti looking for published methods and produces test cases from those.

Make sure you are also pulling submodules - that's explained in the instructions linked by pyscripter for when you do it via cmd but when using some Git GUI it might not automatically do that. Otherwise it might use a jedi.inc from somewhere else (yes, other projects also use it)

https://stackoverflow.com/a/9006662/587106 Nowadays I suggest using https://bitbucket.org/sglienke/spring4d/src/master/Tests/Source/Spring.Testing.pas which adds the functionality mentioned in the SO answer but better than at that time and implemented in DSharp back then. Two features that I personally never needed so far but that DUnitX can do which DUnit can't do out of the box are: standalone testcase classes (i.e. not inheriting from TTestCase) and per fixture setup - can also be plugged onto DUnit. There might be other subtle features of DUnitX that I am not aware of but I am very sure that they could be added to DUnit either by inheriting or by modifying TestFramework.pas (the latter was one of the reasons Vincent rather rolled his own iirc)

Everything that DUnitX does can also be achieved using DUnit (with some minor adjustments or extensions) which then makes tests that don't use features that require Delphi2010+ such as attributes still work in older versions or existing DUnit tests can be kept and just improved using new features when moving to newer Delphi versions.

DUnit runs on all platforms that Delphi supports - it just does not have the dcus shipped for each which requires adding the source directory of DUnit for those platforms (such as Linux). I mean the core framework code, not the GUI runner of course - but I think there are some FMX out there and even if not writing your own is easy enough. Running tests on Windows and Linux (and I am referring to pure unit tests) is as easy as it can be using TestInsight. Mobile can be a bit more tricky as you cannot simply shoot the app there and run it without interaction to collect the results (not 100% sure as I don't do mobile or mac development).

Writeln is a joke compared to Pythons print. You can pass any object to print and it then depends on which methods the object implements what gets printed (see https://stackoverflow.com/q/1535327/587106) And yes, almost all library types implement such methods so you can simply pass arrays, lists or dictionaries to print and get their content printed out.

FWIW in Delphi that fear is often caused by the fact that new features often don't work for years and are poorly designed so they affect some important aspects negatively such as compile speed or runtime performance which often you encounter way later when you already extensively use them (latest example: inline variables). Many other languages have a plethora of incredibly smart people designing things for years with enough time to thoroughly test and ensure they are zero or minimal overhead.

You do realize that the -x options are provided by the fixpack and thus are only via some hackery done by Andreas and might not be stable, yes? @jbg FYI

I do and it will be subject of one of my talks I will be giving at some conferences in the coming months so I will not spoil that before.

IOW: no, they still don't work

Even though I don't see them pop up when browsing the forum itself (kudos to the mods being quick enough or having automated it) I see stuff like this on beginend.net almost every day recently:

Which also was an RTL thing that was very late to the party and thus has to compete with solutions that already existed before it. And yes if there have been other solutions in need of some multi-threading they either had to roll their own or only be compatible or rely on other third party components themselves which they usually rather refrain from. So what we have achieved in the past few years in the RTL is closing the gap on the feature matrix to give the impression that for nowadays standard usecases like http, json or easy parallel processing you don't need any specific third party components or libraries but once you start using them you quickly run into numerous issues that range from "little annoying" to "absolute showstopper". And often fixes either take multiple iterations or major versions and range from "now you broke something else" to "dirty hack because of keeping broken behavior because of backwards compatibility" Even using the smallest RTL feature these days causes me to look into the implementation before recommending it to my coworkers, telling them to stop using them or not giving green light to upgrade the newest Delphi version (RSP-19439 for example) - sad but true. If it weren't for licensing reasons and the impossibility to fix many bugs that interest me by just recompiling the RTL (depending on what units you change) I would have started an "enhanced RTL" project already to fix the most annoying issues (like the ridiculous code bloat caused by System.Generics.Collections/Defaults and many other annoyances). At least the latter was solved by banishing those units from our code entirely and exclusively using spring4d collections. Using any third party code and the RTL and VCL itself though still is affected by that.

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.

I doubted that already

Don't tell me - but this the almighty excuse brought up by the decision makers almost every time some issue like this is brought up - "but what about existing code" - like for that dreaded "directly passing result of ctor call to interface parameter issue" - what about existing code? Well existing code is most likely suffering from a defect. The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!

Updating a single application even if complex is not a hard task, almost every other major IDE out there can do it. Only Delphi developers have to manually apply hotfixes by unzipping some archive and unblock the contained binaries...