Tommi Prami

This is quite interesting. Have not looked into how it is implemented, but speedup claims are pretty substantial. https://github.com/intel/x86-simd-sort Rarely sort is the real bottleneck in any code, but faster is still faster 🙂 -Tee-

Sent many emails past 2 years, to support of: - Known issues/bugs - About next release - Feature requests And sent direct question to TMS sales about FixInsight, is there going top be new version, and about the same message to their support forum thingy. No response, what so ever. Nothing. Not even hello, we have received your message. Absolutely nothing... We have been paid customer from the start (about)... -Tee-

This is very interesting project, only problem for me is that there is so big dependencies. For some that is not problem, I get that. As now it seems that FixInsight is abandonware, I have been thinking that community would start project of our own, that would be made with pure delphi without extra dependencies. -Tee-

Weird. Maybe some automated Spam detection in this forum kicks in... Or "too many" post in short period in time or something like that... -Tee-

https://github.com/d-mozulyov/Rapid.Generics/tree/master (Don't used just stumbled upon it, and did not analyze it either)

Hello, I tried to port Generics.Colllections code to using Spting4D collections instead. I got the "raised exception class EInvalidCast with message '"TMyRecord" is not a class type.'" exception, are the records at all supported, or I am doing something wrong. Code somethin g like that. FRecordCache.Add(LKEyString, LMyRecord); Created this way: FRecordCache:= TCollections.CreateDictionary<string, TMyRecord>([doOwnsValues]) Never mind, it was the doOwnsValues 😄

I've never had that... What was the content... -Tee-

Trying to find right package form the list, some of witch have quite similar names, is total pain in the but. When lkot of components installed there are tons of packages to go through. At worst case, you don't know thew exact name of the package, then you have to actually read all, and not just add some keywords like "tms aur" to get to tms aurelius (if it has package, don't know, just an example) Voted for this one, that is still open: https://quality.embarcadero.com/browse/RSP-14203

How much this will add overhead at runtime?

JCLK and JVCL should support D12 in their repository received commits today.

Yellow, Now that there is "Public" Beta of Delphi 12. ( https://blogs.embarcadero.com/delphi-supports-android-api-33-via-yukon-beta/ ) Some OSS component/library supporters have already made "Educated guess" what there need to be done to support D12, making packages and so. If possible/time/willing to make such a guess, please do, I think it would make everyone's job easier to test the Beta, since almost all of products made with Delphi, use some kind of Open source libs. I think it would just help all people in beta, even if maintainer would not be. In some cases making packages are trivial thing, but quite waste of time if everyone in Beta will do it themselves. Like the great folks maintaining: https://github.com/EtheaDev/SVGIconImageList https://github.com/skia4delphi/skia4delphi (Just to mention two I've noticed) -Tee-

Thank you very many 😉 -Tee-

Good point. Mainly in real life apps I've been working with almost every time sorting is been for strings. Then some quite small portion been list of objects or records. -Tee-

That is perfectly OK. Especially if Embarcadero knows that this person/company is using Delphi certain way, change possibly breaks it or makes better, let them test first etc... That is smart I think. Beta should be, at first for small group of people, to keep amount of messages and bugreports at bay etc... I was referring to the communication channel/channels to take full advantage of the Public Beta. Also if there would be private repository for Beta testers of open code that is ready for the future release. Would make testing with everyone's own products faster and more efficient.

Yellow, https://quality.embarcadero.com/browse/RSP-42524 Delphi comes with very old PCRE (8.45) and it'll wont get any updates according to pcre.org. Latest 10.4.2 : https://github.com/PCRE2Project/pcre2/releases -Tee-

With Library I mean PCRE and the it's Delphi wrapper. -Tee-

Then this system should change, I think... -Tee-

Interesting... I've been in beta couple of time in past 20+ years, and first time I hear about this.

While back I was pondering this situation again. When new Delphi comes out, it takes sometimes quite a long time we get it into the production, because have to wait some of the dependencies to release updates. We can fix those ourselves, but not always. IT can be pretty hard to familiarize the third party code that needs a fix (it maybe somewhat obscure considering the problem how to actually fix it). So I would propose that there would be some faster channel among of the Beta testers. Many of those in Beta provide some Open/Closed Source -code to others in community. If there would be common place to exchange those fixes, privately, and preferably also chat about how the beta is going etc, this would guess also lead to better bug reports and so on. Something like private Discord-server/channel (Or something similar) and/or forum similar to this. I mean that now people and companies doing beta test are separate islands of information that does not spread. And I think it would, in long run, help everyone. -Tee-

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-