Re: CaSe-IndepeDent Menu SEARches?

["Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>]

On Feb 4, 2021, at 10:58 AM, Ralph Lange via Core-talk <core-talk at aps.anl.gov> wrote:

On Thu, 4 Feb 2021 at 17:31, Johnson, Andrew N. <anj at anl.gov> wrote:

On Feb 4, 2021, at 3:29 AM, Ralph Lange via Core-talk <core-talk at aps.anl.gov> wrote:

In the good old times,

we used to have a static DB parser that was used to provide a "lint" tool for databases. (My mourning of the loss of that feature was largely ignored.)

We should provide linting service on the EPICS web page. Would generate nice data of what EPICS features people are using. (And their most common errors.)

Not convinced; a web-page wouldn’t know about external record types, device support or locally added scan rates or breakpoint tables, amongst other things. That’s why I think it has to be local functionality. A linter would also need to know which DBD file to use for each DB file it’s checking. We’d have to put something into the build system to specifically request running dbLint against each DB file at build time, and it would have to ignore unexpanded macros in the file so there will still be errors that only the IOC would see.

And of course a dbLint program would be of lesser use to sites like PSI or ESS that don’t generate an IOC-specific DBD file anyway, only their IOCs know the complete collection of DBD fragments that are being loaded there. A linter could be taught to ignore unknown record types (or even to ignore just the fields in one that are not found in dbCommon) but the DTYP, SCAN and LINR fields would still generate false positives.

"Fixing" bugs on the fly? Rather not. Large blocks of explanations and suggestions on the IOC console? Rather not.

I assume you are against my original suggestion then, since that would be fixing bugs on the fly.

Correct.

Better error messages are always ... better.

But I would avoid lengthy things like listing all available options. That is more useful in an autocomplete pop-up of the editor, not in an IOC log file.

In general I agree with you on that, although some users and sites like ESS & PSI might appreciate a “verbose errors” flag in the IOC.

<technical details>

The existing error message is output by dbRecordField() in dbLexRoutines.c which only knows the error status value, and displays the related text from the header file that defines that status. How it gets the status S_stdlib_extraneous instead of S_db_badChoice is somewhat confusing though: dbRecordField() calls dbPutString() which calls dbPutStringNum() [both in dbStaticRun.c] and that first uses dbGetMenuIndexFromString()  [from dbStaticLib.c] to compare the choice strings, then if that fails it tries epicsParseUInt16() to see if it’s numeric instead. That’s where the S_stdlib_extraneous status comes from – I was expecting it to be S_db_badChoice since both dbConvert.c and dbFastLinkConvert.c return that. Thus we have 3 places where we look up a choice string in a menu definition: dbStaticLib.c, dbFastLinkConv.c and dbConvert.c, although the last one is probably never used in practice since it would only be called for an array of DBF_MENU fields.

</technical details>

- Andrew

-- 

Complexity comes for free, simplicity you have to work for.