Jump to content

Tommi Prami

Members
 View Profile  See their activity

  • Content Count

    511

  • Joined

  • Last visited

  • Days Won

    6

Posts posted by Tommi Prami

  1. Posted

    On 12/29/2020 at 5:38 PM, Slappy said:

    Do you have any idea why the installation gets stuck on "Installing library Parnassus CodeEditor..." ?

     

    I tried install it like 10 times and never finished installation, it dow=es not matter whether I run IDE in admin mode or not, it is always the same.

    UAC lurking in the task bar, asking for installation permission? 

    Been hit by that few times....

     

    -Tee-

  2. Posted

    14 hours ago, Brandon Staggs said:

    The comments on that readme explicitly state it's not complete. However, it also says Argon2 is not fully documented and isn't as good as bcrypt, both of which are really odd things to say.

    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.

  4. Posted

    13 minutes ago, Kas Ob. said:

    Hi,

    Not sure what is your question is, but from what Arnaud wrote and where did he mentioned the salting, i can expand on this, 

    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-

  5. Posted · Edited by Tommi Prami

    13 minutes ago, Arnaud Bouchez said:

    - there is also a need for 16-bytes padding of the encoded output - here Pkcs7 seems the de-facto standard.

    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?

  9. Posted · Edited by Tommi Prami

    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-

  13. Posted

    12 hours ago, Davide Angeli said:

    Before posting I tried several solutions, some of these suggested in this post: 

     

    According to Primoz OTL book it seems to be enough to assign the IOmniTimedTask instance to nil to get the call to Terminate(INFINITE) and Terminate should stop the task... This works perfectley in a little sample demo. In my case leads to random errors (the app is very complex).

     

    I've tried calling the Stop method and then assign the instance to nil but I get the random errors too.

     

    I've tried calling also Stop + Terminate(INFINTE) + WaitFor(INFINITE) + assigning to nil without results

     

     

    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-

  14. Posted · Edited by Tommi Prami
    Additional info

    13 hours ago, Lars Fosdal said:

    Doesn't that mean that only ONE compression can happen at a time - i.e. serializing your use of CompressFile?
    Edit: Are you reusing the same critical section in multiple locations in the code or on multiple nested levels? That could become a race condition.

     

    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.

  15. Posted

    13 hours ago, David Heffernan said:

    Is CompressFile CPU bound? Are we supposed to know what is in there? Seems like it would be important? 

    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.

  18. Posted

    1 minute ago, Primož Gabrijelčič said:

    See: OmniThreadLibrary and console

    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. 

  20. Posted

    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-

  21. Posted · Edited by Tommi Prami

    2 hours ago, Cristian Peța said:

    If someone do have an issue that is possible solved in latest commit why not trying?

    I can't think that an commit is made without testing first.

    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-

    • Like 1
    • Thanks 1

  22. Posted

    22 minutes ago, Cristian Peța said:

    Have you checked https://github.com/pleriche/FastMM5/activity?ref=master ?

    Latest commit is 6 nov. "Handle a potential race condition in FastMM_DetectClassInstance: If another thread frees a block while it is being evaluated as a potential class then an A/V could occur. This indirectly affects other functionality, like FastMM_LogStateToFile."

    You can download sources if you don't use git to clone repository: https://github.com/pleriche/FastMM5/archive/refs/heads/master.zip

    image.thumb.png.d0a97a75148c6e83aa0a38742f90bae3.png

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

     

    -Tee-

    • Thanks 1

  23. Posted

    19 minutes ago, msd said:

    And just like that, back to latest D11.3 + Updates 🙂

    I'll post here my test and deploy results.

    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-

    • Thanks 1

  24. Posted

    14 hours ago, msd said:

    I'm using Delphi 12 Pro + FastMM 5 (build a 32- or 64-bit app).

     

    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.

    • Like 1

  25. Posted · Edited by Tommi Prami

    https://towardsdatascience.com/34-faster-integer-to-string-conversion-algorithm-c72453d25352

    To my understanding Delphi has bit different algorithm, but looking at "default implementation" mentioned article or one Delphi has, it is pretty complex beast in either case, and some what computationally heavy.  

     

    Delphi has lookup tables and DivBy100()  which I would guess it'll make it faster than the "default implementation". Not sure tough.


    lr_printer Github repo: https://github.com/tigranh/lr_printer

     

    -Tee-

×