Libraries: MultiTester - page 15

[fxsaber]

Сергей Таболин:

Is it already possible to zipped or not? (It's like - what if it works ))))

Yes, the zips in KB have been quietly fixed - the updates get there. The dates of the files inside become equal to the date of the update. So by these dates you can immediately understand what time the content corresponds to.

[Good Beer]

fxsaber:

Tester's logs need to be looked at.

Rebooting the terminal + waiting for about 10 minutes helps. Even an alert appears. You should start testing immediately after opening the terminal; don't even flip through trends. But with time everything can be interrupted or looped. The last time I had a normal 172 passes. If the situation repeats, I will send the log. I have not noticed any deviations from the norm there before.

[fxsaber]

Good Beer:
You should start testing immediately after opening the terminal; don't even flip through the trends.

This is not a normal situation. The norm is that everything works without any conditions.

[fxsaber]

On the basis of MTTester you can compare the efficiency of different trading logics.

For example, there is TS1 and TS2. We need to understand which one is better (conditionally, of course).

We make optimisations of each TS, and then we run the best passages as singles on different OOS intervals.

All this can be done automatically via MTTester.

We compare the OOS results and decide which TS is better.

[traveller00]

Interesting log just came up

2019.12.21 13:38:35.994 Tester  Ready to set
2019.12.21 13:38:36.617 Tester  i=100

on the code.

  static bool ClickStart( const bool Check = true, const int Attempts = 100 )
  {
    bool Res = !Check || MTTESTER::IsReady();

    if (Res)
    {
      static const int ControlID[] = {0xE81E, 0x804E, 0x2712, 0x4196};
      GET_HANDLE

      user32::SendMessageW(Handle, BM_CLICK, 0, 0);

      Res = !Check || !MTTESTER::IsReady();

      int i = 0;
      for (i = 0; (i < Attempts) && (!Res)/* && !::IsStopped() */; i++) // The global destructor may need to
        if (Res = !Check || !MTTESTER::IsReady())
          ::Sleep(100);
      Print("i="+(string)i);
    }

    return(Res);
  }

Print("Ready to set");
MTTESTER::SetSettings2(TesterInput);
MTTESTER::ClickStart();

Ideally at i=100 it should sleep for 10 seconds minimum. How it pulled that off in a second (and essentially went to execute incorrectly), I haven't figured out yet. But it's worth saying that the button was pressed, yes. Apparently there's a lag in the button indication. Because there is a second instance running in parallel on the test and it's loading the CPU at 100%.

[traveller00]

I think I got it. The conditions were messed up. Probably why they had to change the number of attempts to 50 last time. He only sleeps when he succeeds, when he's on his way out anyway. And it goes by quickly when it's a good time to sleep. It must be a bug. And the bug is sad, obviously did not show up for almost a month, and I was hoping that the passages are fine. I'll have to retest everything. And I kept wondering why rarely, but sometimes passages don't match.

I guess it must be

if (!(Res = !Check || !MTTESTER::IsReady()))

[fxsaber]

traveller00:

Apparently, it's supposed to be

Yes, the loop was losing meaning due to my inattention. Thanks for looking into it and clearly pointing out the location. I'll reupload it if possible.

[fxsaber]

fxsaber:

Yes, the loop was losing meaning due to my inattention. Thanks for sorting it out and clearly pointing it out. I'll reupload it if possible.

Updated.

[Good Beer]

While waiting for the update, I figured out the reasons for the multitester task list looping.

The first one was a third-party task manager "process lasso" on my computer. It helps with the wireless mouse and keyboard, but doesn't like it when one application takes all the CPU cores.Test agent processes would just interrupt and results would be lost. You got an incomplete task, each time with a new result. Raising the metatester priority fixed everything.

The second problem is that multitester does not support forward. If forward is not enabled, everything works fine. But if it is enabled, the task list starts to bog down. Forward testing starts when the "DONE" message appears at the end of a pass. Multitester wants to scroll through the list, but forward starts. And the "START" button is pressed and the old task is started. What is your algorithm's criteria for ending a pass?

Please consider the forward in future versions of multitester.

[fxsaber]

Good Beer:

Please consider the forward in future versions of multitestera.

I have never run Forward mode in my life. I'll probably try it someday.