Winboard Forum

I wonder if this feature is broken.
I tried implementing it for Dirty but the "." is only send once to the engine and never more unless f.i. after setting a new position.
Same with fruit 2.1 and crafty 23.2

Related to analyze output: what is xboard supposed to do encountering the failhigh/faillow indicators ( "--" and "++" strings) ?
I don't see anything special?

Best
Fonzy

(*xboard 8.0 gtk version)

F. Bluemers wrote:I wonder if this feature is broken.
I tried implementing it for Dirty but the "." is only send once to the engine and never more unless f.i. after setting a new position.
Same with fruit 2.1 and crafty 23.2

Related to analyze output: what is xboard supposed to do encountering the failhigh/faillow indicators ( "--" and "++" strings) ?
I don't see anything special?

Best
Fonzy

(*xboard 8.0 gtk version)

I have found the cause of the periodic updates problem.
AnalysisClockCallback() //xtimer.c was only called once.
According to the glib page when adding a function with g_timeout_add:: "The function is called repeatedly until it returns FALSE, at which point the timeout is automatically destroyed and the function will not be called again."**
It seems that (void) AnalysisClockCallback() was doing just that.
uglyhacktweaking it to return a value made periodic analysis work again.

Code: Select all

int //void
AnalysisClockCallback(gpointer data)
{
    if (gameMode == AnalyzeMode || gameMode == AnalyzeFile
         || appData.icsEngineAnalyze) { // [DM]
   AnalysisPeriodicEvent(0);
    }
return 1;
}


I also found the answer to my second question on encountering "--" or "++" xboard sets programStats.got_fail accordingly.However that variable
seems not to be used anywhere.
Best
Fonzy

**source: https://developer.gnome.org/glib/stable ... imeout-add

I noticed a display bug when using two engines,one using periodic updates,the other not.
In this case the stats output(current movenumber of totalmoves,move considered) will show in both engine analyze windows.
It seems that in backend.c when the considered move is in the programStats->move_name,then this move will be copied over on other events.
A possible fix:

Code: Select all

       } else if (sscanf(message,"stat01: %d " u64Display " %d %d %d %s",
               &time, &nodes, &plylev, &mvleft,
               &mvtot, mvname) >= 5) {
      /* The stat01: line is from Crafty (9.29+) in response
         to the "." command */
      programStats.seen_stat = 1;
      cps->maybeThinking = TRUE;

      if (programStats.got_only_move || !appData.periodicUpdates)
        return;

      programStats.depth = plylev;
      programStats.time = time;
      programStats.nodes = nodes;
      programStats.moves_left = mvleft;
      programStats.nr_moves = mvtot;
      safeStrCpy(programStats.move_name, mvname, sizeof(programStats.move_name)/sizeof(programStats.move_name[0]));
      programStats.ok_to_send = 1;
        programStats.movelist[0] = '\0';
        SendProgramStatsToFrontend( cps, &programStats );
        programStats.move_name[0]=NULLCHAR; //<------------------------------------------fix(?)
      return;


Best
Fonzy

Sorry for ignoring this so long.

Actually it is the first time I notice the mention of ++ and -- in the protocol specs. None of my engines supports periodic updates, so I am quite unfamiliar with that command. Or are this ++ and -- supposed to be seperate commands? Not even this is clear to me.

Due to the annoying habit of engines to output all these failed PVs in the normal thinking output I introduced a new convention there, indicating fail high by ! and fail low by ? at the end of the PV. In the Engine Output panes XBoard then also prints that !? directly behind the score, to better focus attention on it.

I must say I am at a loss as to what XBoard should do, in response to ++ or --, or when exactly an engine is expected to send those. (At the moment they would otherwise print normal thinking output? Before it, to indicate that the following thinking output should not be taken seriously? I already introduced the !? embedded in the PV for the latter...)

Thanks for the timer fix; this must have slipped in when we ported to GTK.

I must admit that I don't see how the second thing could be a problem. If the second engine does not emit any stat01 commands, then SendProgramStatsToFrontend should never be called with the 'cps' of that engine. And I would expect that sendin stats for the second engine would be the only event that can cause writing of the move field above the second pane. But I guess things can go wrong if one of the engines sends a stat01 command without a move, which also seems allowed. Then the sscanf would not put anything in mvname, so that the old move keeps hanging there. Your proposed fix would not fix that, however. It is really mvname that should be set to a null string.

H.G.Muller wrote:Sorry for ignoring this so long.

Actually it is the first time I notice the mention of ++ and -- in the protocol specs. None of my engines supports periodic updates, so I am quite unfamiliar with that command. Or are this ++ and -- supposed to be seperate commands? Not even this is clear to me.

Due to the annoying habit of engines to output all these failed PVs in the normal thinking output I introduced a new convention there, indicating fail high by ! and fail low by ? at the end of the PV. In the Engine Output panes XBoard then also prints that !? directly behind the score, to better focus attention on it.

I must say I am at a loss as to what XBoard should do, in response to ++ or --, or when exactly an engine is expected to send those. (At the moment they would otherwise print normal thinking output? Before it, to indicate that the following thinking output should not be taken seriously? I already introduced the !? embedded in the PV for the latter...)

Thanks for the timer fix; this must have slipped in when we ported to GTK.

I must admit that I don't see how the second thing could be a problem. If the second engine does not emit any stat01 commands, then SendProgramStatsToFrontend should never be called with the 'cps' of that engine. And I would expect that sendin stats for the second engine would be the only event that can cause writing of the move field above the second pane. But I guess things can go wrong if one of the engines sends a stat01 command without a move, which also seems allowed. Then the sscanf would not put anything in mvname, so that the old move keeps hanging there. Your proposed fix would not fix that, however. It is really mvname that should be set to a null string.

Maybe older xboard versions worked with -- and ++ ?
I only saw it in the specs,tried it and ...
The second problem also shows up when the second engine does not send sta01,you can test it with some older dirty versions.
Best Fonzy

A bit more on ++ ,--
HGM,I guess you found what follows yourself.
I was curious and got a copy of the winboard_x sources from the wayback machine.
Here are some snips

Code: Select all

.................
       } else if (strncmp(message,"++",2) == 0) {
      /* Crafty 9.29+ outputs this */
      programStats.got_fail = 2;
      return;

       } else if (strncmp(message,"--",2) == 0) {
      /* Crafty 9.29+ outputs this */
      programStats.got_fail = 1;
      return;
.............................

void
DisplayAnalysis()
{
    char buf[MSG_SIZ];
    char lst[MSG_SIZ / 2];
    double nps;
    static char *xtra[] = { "", " (--)", " (++)" };
    int h, m, s, cs;
 
    if (programStats.time == 0) {
   programStats.time = 1;
    }
  ......................
       sprintf(buf, "depth=%d %d/%d(%s) %+.2f %s%s\nNodes: %lu NPS: %d\nTime: %02d:%02d:%02d.%02d",
          programStats.depth,
          programStats.nr_moves-programStats.moves_left,
          programStats.nr_moves, programStats.move_name,
          ((float)programStats.score)/100.0, lst,
          only_one_move(lst)?
          xtra[programStats.got_fail] : "",
          programStats.nodes, (int)nps, h, m, s, cs);


I ported the ++ convention to xboard 4.8 and played a bit with it.
Not so crazy about it yet.
Once Dirty sends a ++ or -- ,xboard will keep appending the indicator till it received a different one.
My hack did not reset got_fail when xboard encountered a new pv but neither did winboard_x!
In my opinion it would be simpler to remove ++/-- from xboard and allow an engine to decorate the currently analysed move from stat01 itself
Also,the whole thing only works in analyze mode,like there would be no fail low or high in games
Best Fonzy