Re: Apropos making fields configurable

[Benjamin Franksen <franksen@mail.bessy.de>]

Hello everyone,

good news: the changes needed to implement what was proposed for
breakpoint conversion are very simple.

(1) Code in cvtBrk.c need *not* be modified to achieve conversion
without limits. First observation: the limitation is only at the upper
end of the table (i.e. the raw value is greater than the last raw value
in the table), not at the lower end. Second observation: The code is
such that the problem at the upper end is most easily fixed by filling
in the last slope value in the table, instead of keeping it at the
default zero.

Therefore, in base/src/dbStatic/dbLexRoutines.c, function dbBreakBody(),
(reading the breakpoint tables from the dbd file is performed here)
after setting the slopes for all but the last table entries:

    /* Compute slopes */
    for(i=0; i<number-1; i++) {
        ...
    }

add the lines:

    if(number>1)
        pnewbrkTable->papBrkInt[number-1]->slope =
        pnewbrkTable->papBrkInt[number-2]->slope;

and that's it.

(2) Additional field in ao and ai records. I named it BRSV.

BRSV: Severity to apply when out-of-range warnings are returned from
breakpoint conversion functions. These functions return -1 for errors,
and 1 for warnings like value to converted outside table range. If -1
(error) is returned, the behavior is the same as before, i.e.
SOFT_ALARM, INVALID_ALARM. If 1 (out-of-range) is returned, an alarm is
raised only if BRSV is not NO_ALARM. In this case the value of BRSV is
applied for the severity. The default is INVALID_ALARM for maximum
backward compatibility.

Thus the changes in axRecords are: In axRecord.dbd, add

    field(BRSV,DBF_MENU) {
        prompt("Breakpoint Severity")
        promptgroup(GUI_ALARMS)
        pp(TRUE)
        interest(1)
        initial("INVALID")
        menu(menuAlarmSevr)
    }

in axRecord.c, in function convert(), after 

    else { /* must use breakpoint table */

replace lines

        if (cvt...(...)!=0 ) {
            recGblSetSevr(pax,SOFT_ALARM,INVALID_ALARM);
        }

by

        status = cvt...(...);
        if(status == -1) {
            recGblSetSevr(pax,SOFT_ALARM,INVALID_ALARM);
        }
        else if(status && pai->brsv) {
            recGblSetSevr(pax,SOFT_ALARM,pai->brsv);
        }

and add 'long status;' declaration at start of function.

I tested both changes with base R3.13.4.

(3) There is another inconvenience with breakpoint tables, i regularly
stumble over (and which is btw not documented in the developer's guide):
the source values (raw for ai, eng for ao) must be sorted in ascending
order. That's ok as long as the slopes are all positive. Still you have
to remember it, otherwise conversion will give you completely wrong
results.

It becomes very inconvenient if slopes are negative and you want to use
a table in both directions: then you need to provide the same table
twice, once with eng values and once with raw values in ascending order.
I haven't thought of a nice and simple (and efficient!) solution yet.

(3) About the possibility to specify a subroutine name directly into
LINR field, as Rolf Keitel proposed, I think this is a good idea but not
so easily implemented. For the syntax, one could use '()' after the name
to distinguish it from a breakpoint table name. I also have some more
radical solutions in mind, but this is not yet thought through.

Enough of this for today.

Ben