EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CaSe-IndepeDent Menu SEARches?
From: "Cobb, Tom \(DLSLtd,RAL,LSCI\) via Core-talk" <core-talk at aps.anl.gov>
To: EPICS Core Talk <core-talk at aps.anl.gov>, Ralph Lange <ralph.lange at gmx.de>, "Abbott, Michael (DLSLtd,RAL,LSCI)" <michael.abbott at diamond.ac.uk>
Date: Thu, 4 Feb 2021 11:12:00 +0000
Hi Ralph,

We use epicsdbbuilder to create and verify databases from Python, which I guess is similar:

(I'm about to package it in PyPI so that it's just a pip install away)

The dbVerify function in dbCore or dbStaticHost that it relies on disappeared for a while (in 3.16 maybe?) but appears to be back now.

Thanks,
Tom


From: Core-talk <core-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Core-talk <core-talk at aps.anl.gov>
Sent: 04 February 2021 09:29
To: EPICS Core Talk <core-talk at aps.anl.gov>
Subject: Re: CaSe-IndepeDent Menu SEARches?
 
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.)
In such a tool, I would support and encourage all kinds of intelligent hints for improving databases, showing similar options for typos being the simplest example.
(What about "Engineers that used the calcout record also often use the seq and compress records.")

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

Cheers,
~Ralph


On Thu, 4 Feb 2021 at 08:38, Torsten Bögershausen via Core-talk <core-talk at aps.anl.gov> wrote:

> On 4 feb. 2021, at 01:21, Johnson, Andrew N. via Core-talk <core-talk at aps.anl.gov> wrote:
>
> A colleague just presented me with one of those frustrating little problems where his database wouldn’t load because he spelled a calcout.OOPT field value using “to” instead of “To” and he couldn’t find it.
>

Thar is sad to hear - but who hasn’t been there ?
Doesn’t the database loader give a useful warning/error ?
What is the difference between “to”, “fo”, “io”, “tu” ?
They are all typos, spelling errors.
What is the “real name” ? “To” or “to” ?
My suggestion would be to use a (naming) convention here - the same problem hits me all the time.
“CamelCase" or “snake_case" or “UPPERCASE" or “lowercase”  ?
None of my compilers is intelligent to figure out how to fix this typos - and that is a good thing.

And: Helping colegues to find this kind of bugs puts people together.
Exchange knowledge, chat about other stuff.
Best practise, new projects, problems, even the solved ones.

> How about when putting to a menu field we do a second pass through the choice strings using epicsStrCaseCmp() so this kind of thing would be silently accepted? The first pass should still use strcmp() in case some IOC has choices (in mbbo strings) that only differ by case, but the second pass would accept the first to match even when the cases differ.
>
> We could make this configurable so sites could turn it off, or even have it display a warning, but I’m not sure who would really want that much strictness.
>
> I already wrote the code, although it could be posted as a Codeathon project instead (requiring tests and Release Notes as well).
>

> - Andrew
>
> --
> Complexity comes for free, simplicity you have to work for.
>

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 


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

Navigate by Date:
Prev: Re: CaSe-IndepeDent Menu SEARches? Ralph Lange 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  <20212022  2023  2024 
Navigate by Thread:
Prev: Re: CaSe-IndepeDent Menu SEARches? Ralph Lange 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  <20212022  2023  2024 
ANJ, 04 Feb 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·