Tommi Prami

ExecuteAndWait will pump messages, whic is 99.999% of work app does... Waiths 7-zip.. -Tee-

Take your time.

Could you run the app in debugger and put break points at the end of DoSometing1 and DoSometing2, and be sure that you exit from them cleanly? -Tee-

As far as I know, you can re-enter to critical section, as long as you exit them all. Was not problem with the PPL anyhow. I can remove Critical section code and test tough... Edit: Removed all critical section calls, does not change the behavior. Also removing my own CPU and Memory Throttling code at WaitForSystemStatus don't change the behaviour either.

Posted link to the repo later, did not remember that it was public. Currently it is not CPU bound, uses 10% of CPU and not that much memory also, there is my own CPU and Memory throttling code, but it has no effect. Tested it with putting break point there., There will be one "thread" processing. With PPL it worked pretty well, with OTL it is running all in sequential manner, not in parallel, it completed the process but second compression after the first one.

There is a loop while waiting the running process that will process messages, but not with ProcessMessages-call but uses PeekMessage with PM_REMOVE flag.

Hehe.,.. I have whole code in GitHub: https://github.com/TommiPrami/7zFileCompress Not too clean because just trying to hash it together. And tools for just own usage are not that important that would keep repo cleaned up all the time. -Tee-

Looked into that, but did not quite get how it would solve this problem. Refactored ForEach loop into separate procedure which was used in Future, with same result. Now I let it wun to see if it'll do all "tasks" sequentially. I was using Delphi PPL and it more than less worked, tried to port it to to OTL, but it was not that simple as I thought.

Yes but released in try.. finally. I use Critical section and very short ones.

Just pointing out that is "debug stuff" of FastMM5, usually not compiled to release-binaries, but it depends on how exe is built... I've always used latest FastMM and never there has been proof that something was FastMM's fault. Not saying that it has always been bug free, but problems I've encountered always been at somewhere else, FastMM just had borough them into light. -Tee-

That is debug stuff, but if build that way sure can be one of the reasons... -Tee-

We usually wait some time after new release, and follow Tickets people start to post. Some of the bugs/regressions now in D12 are pretty bad. and also quite weird that no one found those in beta. I ran all of our products and unit/integration tests and saw nothing when D12 came out. So those apparently needed some special code, as usually is when it is regression. But anyhow. I really hope that D12.1 comes soon, because IDE is clearly better than D11. And some good fixes also coming in D12 too. Depending on the situation and project, After we got everything compiling in D12 and made sure we kept D11 compatibility, it took couple of hours for me to get back to D11 with total D11 reinstall. But easily can see the situation that jumping back to early version can take long time, depending on the products and so on. -Tee-

D12 has some very bad bugs/regressions. If you have latest D11 release available, I would go to that, with and without FastMM5 to get to the root of this.

Related video:

Couple of nasty bugs in D12 compiler. Please vote: https://quality.embarcadero.com/browse/RSP-43274 https://quality.embarcadero.com/browse/RSP-43418 (if previously discussed in here, don't read the message 😉 )

Maybe need to evaluate it a and migrate to that. Few years ago when I looked at PEX, it seemed to have tons of not that important checks, which seemed not that useful at the time. Need to actually evaluate it. Thanks for info... -Tee-

Could you give couple examples in what way those are better.

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