On 2/4/21 10:03 AM, Johnson, Andrew N. via Core-talk wrote:
> On Feb 4, 2021, at 10:58 AM, Ralph Lange via Core-talk <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>> wrote:
>>
>> On Thu, 4 Feb 2021 at 17:31, Johnson, Andrew N. <anj at anl.gov <mailto:anj at anl.gov>> wrote:
>>
>> On Feb 4, 2021, at 3:29 AM, Ralph Lange via Core-talk <core-talk at aps.anl.gov <mailto: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.
My dbdlint has two modes. --partial does syntax checks with only a .db file, and --full
does more complete checks against a "full" database (including .dbd). It would be really
super nice if there were make rules to support both cases since the first could be added
in as a default.
> 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.
You might be surprised. A group at SLAC is using my linter as a (python) library
to verify the output of their .db file generator.
>>> "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.
>
- References:
- CaSe-IndepeDent Menu SEARches? Johnson, Andrew N. via Core-talk
- Re: CaSe-IndepeDent Menu SEARches? Torsten Bögershausen via Core-talk
- Re: CaSe-IndepeDent Menu SEARches? Ralph Lange via Core-talk
- Re: CaSe-IndepeDent Menu SEARches? Johnson, Andrew N. via Core-talk
- Re: CaSe-IndepeDent Menu SEARches? Ralph Lange via Core-talk
- Re: CaSe-IndepeDent Menu SEARches? Johnson, Andrew N. via Core-talk
- Navigate by Date:
- Prev:
Re: CaSe-IndepeDent Menu SEARches? Timo Korhonen via Core-talk
- Next:
RE: Unit tests on Windows DLL internals Akeroyd, Freddie (STFC, RAL, ISIS) via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: CaSe-IndepeDent Menu SEARches? Timo Korhonen via Core-talk
- Next:
Re: CaSe-IndepeDent Menu SEARches? Michael Davidsaver via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|