Leaderboard

You already have a begin...end pair: with whatever do begin end; So why not just move the inline inside the begin...end and get rid of the with: begin var thisorthat := whatever; ... end; I see no reason to change the language so we can keep using with. Just get rid of it and forget it ever existed.

Did quick google search to familiarize myself on the subject and ran into this: https://github.com/minio/sha256-simd Seems to be worth checking out. .Tee.

GetIt, I just don't get it. Surely you are better off pulling from the repo?

Yes, exactly. We're going to be dropping support for old compilers, Delphi and FreePascal alike, which do not support UnicodeString (we are not going to handle WideString). Providing backwards compatibility for AnsiString when Unicode is now part of most modern network protocols, as well as modren RTLs being Unicode-based, has made a real mess of the codebase. We are also dropping support for .NET completely. Indy 11 is intended to be a maintenance release to do some much-needed cleanup.

I tried with both TDialogService.TPreferredMode.Async and Sync and I see the same main thread in the procedure. So, no synchronize needed.

Damnation, right. This is correct URL: https://quality.embarcadero.com/browse/RSP-18953 Thanks... Copy paste errors all day 😄 -tee-

I'd like this to be possible, and a compiler switch that bans the old with statements. with var ref := Some.Array[Index1].Reference, var thing := Function(Index1).Thing do begin if ref.Value <> thing.Value then begin ... end; end; // ref and thing are not present

That's the only way of doing it, and it's very trivial to do. https://quality.embarcadero.com/browse/RSP-16741

Just saying... RSP-16751

Cross process window parenting relationships never end well. Don't try this. https://devblogs.microsoft.com/oldnewthing/20130412-00/?p=4683

Range checking is an interesting thing - lets look at the compiler output for the following code with range checking: procedure Test; var numbers: array of Integer; i: Integer; begin SetLength(numbers, 10000000); for i := Low(numbers) to High(numbers) do numbers[i] := i; end; Project376.dpr.18: for i := Low(numbers) to High(numbers) do 004CF162 8B45FC mov eax,[ebp-$04] 004CF165 85C0 test eax,eax 004CF167 7405 jz $004cf16e 004CF169 83E804 sub eax,$04 004CF16C 8B00 mov eax,[eax] 004CF16E 8BD0 mov edx,eax 004CF170 4A dec edx 004CF171 85D2 test edx,edx 004CF173 7C1B jl $004cf190 004CF175 42 inc edx 004CF176 33C0 xor eax,eax Project376.dpr.19: numbers[i] := i; 004CF178 8B4DFC mov ecx,[ebp-$04] 004CF17B 85C9 test ecx,ecx 004CF17D 7405 jz $004cf184 004CF17F 3B41FC cmp eax,[ecx-$04] 004CF182 7205 jb $004cf189 004CF184 E86F96F3FF call @BoundErr 004CF189 890481 mov [ecx+eax*4],eax 004CF18C 40 inc eax Project376.dpr.18: for i := Low(numbers) to High(numbers) do 004CF18D 4A dec edx 004CF18E 75E8 jnz $004cf178 Now without range checking: Project376.dpr.18: for i := Low(numbers) to High(numbers) do 004CF162 8B45FC mov eax,[ebp-$04] 004CF165 85C0 test eax,eax 004CF167 7405 jz $004cf16e 004CF169 83E804 sub eax,$04 004CF16C 8B00 mov eax,[eax] 004CF16E 8BD0 mov edx,eax 004CF170 4A dec edx 004CF171 85D2 test edx,edx 004CF173 7C0D jl $004cf182 004CF175 42 inc edx 004CF176 33C0 xor eax,eax Project376.dpr.19: numbers[i] := i; 004CF178 8B4DFC mov ecx,[ebp-$04] 004CF17B 890481 mov [ecx+eax*4],eax 004CF17E 40 inc eax Project376.dpr.18: for i := Low(numbers) to High(numbers) do 004CF17F 4A dec edx 004CF180 75F6 jnz $004cf178 The question is: does this code even need range checking? The answer is no - the loop range itself guarantees it. What if the compiler would notice if I mistakenly would write: for i := Low(numbers) to Length(numbers) do numbers[i] := i; instead of putting some code that slows things down and can optionally be turned off. Of course this is a simple example of an out of range error and there are others that are not easily noticeable at compiletime - but those that are the compiler (or static code analysis) could do a whole lot of potential error detection.

I found this one to https://community.idera.com/developer-tools/b/blog/posts/what-is-my-ip-address

@Stefan Glienke These are the main pain points with DUnit: Viewer has no filter functionality. When you have hundreds of tests, you have to scroll until you find the test you would like to execute. Viewer is not DPI aware. Seems to be no longer mantained. Lack of test categories. We would like to be able to specify which test categories to run. Normally you don't want to run all test while developing. DUnitX seems to already have most features. Its open source, so I will take a look at how involved it would be to extend the viewer to show the tests grouped by category. Could you please give me a hint on how to dynamically create a Test in DUnitX? It is sufficient if you mention which class(es) I should look at. That would be a great headstart. Once I have that figured out I can look into the viewer issue. Thank you!!

YIKES. $474/year for a Code signing certificate ????? Shouldn't be any more than $100/Year or so via some Sectigo reseller. Examples here and here. You'll need a Code signing certificate ("SSL" EV won't do and I've never needed an EV Code certificate). I also never seen the icon disappear. What tool do you use to sign and what command line options?