Tommi Prami

Just to point it out: I am looking for ideas how to make it fast and simple etc... I made simple proof of concept. Make some Unit Tests for it some point- If there is better idea, easy to test that then. @Uwe Raabe made very simple implementation indeed. -Tee-

Meaning "No value given to the Container". If not added value, there can't be any it has... Most likely I'll return defined value, but that is just implementation detail. -Tee-

I think exactly that. integer ranges like 1-5: 1 15-40: 1 102-150: 2 and if I search for: 1 -> I'll get that range exists and get also associated value 1 7 -> No range, and no value 149 -> Range exists and associated value 2 returned code could be something like: if FRanges.Contains(1, LRangeValue) then begin case LRangeValue of 1: HandleRangeType1; 2: HandleRangeType2; end; end;

UAC lurking in the task bar, asking for installation permission? Been hit by that few times.... -Tee-

I take it as the BCrypt is better if run it one second or shoter period. . Whats actually the point of Argon2 that you run it long, and use much resources, to make it hard for brute force attack, even with GPU farms.

There is couple implementations. like: https://github.com/JackTrapper/argon2-for-delphi Have not tested them tough... -Tee-

Used word Salt as to ask in different words. But your explanation, I think answered question. It is not about adding "salt" to beginning but padding to end. I would think that is the job for the AES library, not for individual programmer using the library. Kind would hope that best practices would be used as default, and if need something else, lets say receive data from 3rd party system, then you can change behavior. -Tee-

What do you mean here actually. Add "salt" to the data to be crypted or to the crypted it result data? and why is 16 bytes important, or it is 16 bytes or more, or any multiple of n bytes?

Code is basically this: LFiles.AddStrings(TDirectory.GetFiles(LRootFolder, LSearchPattern, TSearchOption.soTopDirectoryOnly)); if LFiles.Count > 0 then begin Parallel.ForEach(LFiles).Execute( procedure(const AFileName: TOmniValue) var LCurrentFile: string; begin LCurrentFile := AFileName; CompressFile(LRootFolder, ExtractFileName(LCurrentFile)); end ); end LFiles is TStringList; This is in CommandLine app, so maybe it could not even work this way, and I should use some other coding pattern here than ForEach. I could not find way to wait the ForEach loop, If I put .NoWait in there. -Tee-

Thank you all, Now I've ported the code from PPL to OTL, and next I'll polish it a bit and just use it, or maybe tune it a bit,. As is, it's good enough what it does... -Tee-

Thanks... I'll look into that... That seems too obvious now, hopefully in few minutes also 😄 🙂 -Tee-

How I can wait for the ForEach to finish, if I use the NoWait-pattern? Could not figure that out yet. -Tee-

Tried to add .NoWait to ForEach call, and did infinite loop processing messages after that it'll start more than one "task" parallel. IOmniParallelLoop does not contain flag that I could wait for, that would be nice... (As I saw in some demo maybe in future, IsDone etc...) -Tee-

Ah OK, did not realize that difference... Thanks for info... -Tee-

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-