Tommi Prami

I would (did not think this too much) something like this. Go code trough with D7, make it is modern at it can get. (Few refactoring rounds, get rid of code that is not in active use etc) Update all 3rd party components and libraries. Get rid of those not available for modern delphi versions anymore and not supported Get rid of all visual components that are not absolutely needed. In legacy app there might be visual components form 5 different libraries or something like that. If can get byt, use stock Delphi components as much as you can. Mainly just reduse code base as small as you can, before start using new Delphi. Move to the new delphi and make 32bit app with that. Refactor and further modernice as much as you can. Do 64bit port as last step. -Tee-

Added instruction test routines by DelphiUdIT into the repository -Tee-

I never really done anything with ASM, and it is more than less magic to me, did ton of googling and landed this far... This seems to work, but I have no idea is it even remotely correct. function RDSEED64: UInt64; asm DB $48, $0F, $C7, $F8 // RDSEED 64bit value (if correct magic numbers) // The 64-bit result is already in RAX end; I think it would need as per Intel documentation some short, maybe constant loop, Apparently RDSEED returns 0 if it fails (Too many calls in short period of time). Also possibility checking the instruction availability would be nice. I've got even less idea how to port this to 64bit compiler. This is purely "academic" (Read hobby stuff) for me if seems too much work don't bother, but if someone really needs it and someone could help, I think there could be appreciation of some sorts. -Tee-

Please make Pull request. -Tee-

Made repository for this: https://github.com/TommiPrami/Delphi.RdRand/ So easier to pass fixes or enhancements to all...

What I can't understand how it worked on 32bit app, or at least it did not fail or die... Because I need 64bit random seed. So 32bit version should do some bit fiddling to make two calls and make 64bit value from two 32bit value? Something like: {$IF NOT Defined(WIN64)} function RDSEED64(const ARetryCount: UInt32 = 10): UInt64; var LValue1: UInt32; LValue2: UInt32; begin LValue1 := RDSEED32(ARetryCount); LValue2 := RDSEED32(ARetryCount); Result := UInt64(LValue1) shl 32 or LValue2; end; {$ENDIF} -Tee-

Thanks will test those out... -Tee-

Yellow, Never pondered what happen when memory gets fragmented. Bit hard to test maybe. But if there would be easy way, could give good info of performance when environment is in challenging state. https://johnnysswlab.com/faster-hash-maps-binary-trees-etc-through-data-layout-modification/ -Tee-

For some reason lot of units show on top of each other. Even if fixed, would be handy to have some hint, to give some info on the unit while hovering over, with maybe bigger font (Normal UI font), if zoomed to very small, then could check colored ones.... etc... Also this island at top left is bit strange.

Very nice. Hope you continue to make it better. For one I would not need "relaxed search" from the Graph. Like type search 'settings custom' Would give me all units from the graph that would match those words. Like the Delphi Search for units... (Ctrl + F12). You can put everything you just remember the unit you are looking for. Because there is huge number of unis in big projects, and finding from the Graph (without filtering) just my 0.02€... Very good. Thanks. -Tee-

Yellow, Stumbled upon these: https://github.com/YWtheGod/ZSTD4Delphi https://github.com/DenisAnisimov/ZSTD.pas No idea will they work and so, if someone has need and/or interest, here you are... -Tee- Benchmarks For reference, several fast compression algorithms were tested and compared on a server running Arch Linux (Linux version 5.5.11-arch1-1), with a Core i9-9900K CPU @ 5.0GHz, using lzbench, an open-source in-memory benchmark by @inikep compiled with gcc 9.3.0, on the Silesia compression corpus. Compressor name Ratio Compression Decompress. zstd 1.4.5 -1 2.884 500 MB/s 1660 MB/s zlib 1.2.11 -1 2.743 90 MB/s 400 MB/s brotli 1.0.7 -0 2.703 400 MB/s 450 MB/s zstd 1.4.5 --fast=1 2.434 570 MB/s 2200 MB/s zstd 1.4.5 --fast=3 2.312 640 MB/s 2300 MB/s quicklz 1.5.0 -1 2.238 560 MB/s 710 MB/s zstd 1.4.5 --fast=5 2.178 700 MB/s 2420 MB/s lzo1x 2.10 -1 2.106 690 MB/s 820 MB/s lz4 1.9.2 2.101 740 MB/s 4530 MB/s lzf 3.6 -1 2.077 410 MB/s 860 MB/s snappy 1.1.8 2.073 560 MB/s 1790 MB/s

Was just thinking, Can anyone figure out why Embarcadero could/would/should not publish rtl, compiler etc versions and codename for the beta, just as they include first outsider to the beta test? Those things are not that big of an secret. or allow publishing trivial work done with beta versions. Like the packages or support for IDE plugins (with some limitations maybe??). -Tee-

I get the points raised. But if you are in not under NDA, making a guess what defines you might need to tweak into .inc file or put into the package, can't violate the NDA. If you are under NDA and just publish packages and/or project files etc, Emba would shoot them self to the foot if they would enforce it in that case, IMHO. But seen stupider things done, so never know 😄 Problem of the NDA is, I assume, that you can't even ask for help, from lets say, how to add D12 support for the Jcl. But I might be cunning and ask how did you make support for the D11,x And try to duplicate the process. And this is kind of funny, because everyone knows few people that has D12 beta, and are under NDA most likely. And Embarcadero it self leaks that information. But person can't say anything and has to dance around. I understand that there must be some kind of limitations under beta, but making things too tight sure puts everyone in beta in position that they have to do more work that they should. Also most likely can't test everything that they would like to, But this is just pointless rambling because it will not affect the company policy for sure... -Tee-

https://quality.embarcadero.com/browse/RSP-42119?filter=18708 Add hint/warning/error setting for use of Abbreviated compiler directives. I know most of you won't care too much of this. When you come across code that has lot of abbreviated compiler directives is very hard to see what and why, -Tee-

Ah, And forgot that this forum won't let me edit after some time period. Never understood why. Maybe someone at past has been D**K HEAD abusing the edit functionality. Would be better to kick those out, than not been able to correct typos and mistakes, or give more info to the initial message, if problem has been solved. But I digress..

Code that builds in one project fails in other. TResamplerObj = class id: integer; name: string; func: TResamplerFunction; end; if I and public-keyword after class() it'll build TResamplerObj = class public id: integer; name: string; func: TResamplerFunction; end; I've never seen behaviour like this. First of all usually there is strict private/private keyword. But the code should build, because it'll do so in other projects. -Tee-

Emit Runtime type information for Debug build was on.

[dcc32 Error] Img32.pas(605): E2217 Published field 'id' not a class or interface type Maybe there is compiler setting for that... Try to find again...,

Rephrased in comments and in Jira, user can't edit it so...

To make sure that none Abbreviated versions creep in. If it is your cup of tee. -Tee-

Compiler supports only the short versions of compiler direcctives in the IFOPT {$IFOPT C+} LTempVariable := {$ENDIF} DoSometingThatReturnsSomething: Assert(LTempVariable > 0, 'Should return greater than Zero'); would be way easier to read and understand what is going on with long version {$IFOPT ASSERTIONS ON} LTempVariable := {$ENDIF} https://quality.embarcadero.com/browse/RSP-42105 I really do not like those shortened version of Compiler directives. Would need to use them a lot, if at least I would remember them.

Sure can.

https://github.com/TommiPrami/DecimalRound Couple of minor changes, nothing big. -Tee-

Thanks... -Tee-

Could you try will these routines work for you; https://github.com/TommiPrami/DecimalRound/