EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Problem with the basic example
From: Benjamin Franksen <[email protected]>
To: <[email protected]>
Date: Wed, 1 Aug 2012 01:42:13 +0200
Am Mittwoch, 1. August 2012, 01:19:32 schrieben Sie:
> On 2012-07-31 Benjamin Franksen wrote:
> > Am Dienstag, 31. Juli 2012, 18:52:54 schrieb Andrew Johnson:
> > > On 2012-07-31 Ralph Lange wrote:
> > > > Shouldn't the db parser complain about this?
> > >
> > > It should print a warning, but we haven't been very strict about the
> > > set of allowed characters in the past so I don't think 3.14.x can
> > > reject all of the characters that fall outside the set that is
> > > documented as legal. I'll add code to warn about space, both quotes,
> > > dot and dollar — any others that I should add to that (fairly
> > > arbitrary) list?
> >
> > the Developer's Guide is fairly precise about it (3.14.12, page 107):
> ... but the documented restrictions have never been enforced, and there
> were no adverse effects if you did use many of the characters outside of
> those documented limitations.  For example I believe there are sites that
> use braces {} in their record naming convention.  If we are too strict
> about the characters we allow, we risk alienating such sites, making it
> impossible for them to upgrade.

If the documented restrictions are too strict, by all means do relax them. I
have no problem with allowing all sorts of characters in record names.
However, the dot in particular /is/ problematic and dbLoadRecord should fail
(to load that record instance) and report an error. Having a record listed
using dbl but not being able to access it is just a bit too surprising IMO and
I see no use case for such a feature. I also think that the exceptions (i.e.
characters that are not allowed in valid record names) should be properly
documented.

> > > The real bug here though is that makeBaseApp.pl should have removed the
> > > dot and any other illegal characters from the user-name when it
> > > instantiated the example template in the first place.  Bruno's
> > > generated example should never have tried to create record names with
> > > dots in them at all.
> >
> > I am not so sure about this. I think this places too much burden on
> >
> >  something as simple as makeBaseApp.pl that just replaces some strings in
> >  a (template) directory of files while copting them somewhere else.
> >  Ultimately, it is the function that /loads/ a db file that has the
> >  responsibility to make the definitive check (after doing a last round
> >  of macro substitutions).
>
> The makeBaseApp.pl script already does exactly this kind of filtering on
> the application name to generate the app_RegisterRecordDeviceDriver
> function name, which must be a legal C identifier.  It's not hard...
>
> > For 3.15, I think dbst (or some replacement with similar functionality)
> >
> >  should be re-bundled with base and should be used by default
> >  (DB_OPT=YES), e.g. in the Makefiles of the makeBaseApp example. This
> >  would also have cought the error early.
>
> My solution works, and avoids having to write documentation telling the
> user how to edit their application files if their user name happens to
> have a . in it and they get a nasty error message.

You are right, of course. If makeBaseApp.pl can easily avoid the problem then
it should do that.

> I prefer to avoid the
> problem from occurring at all, rather than just flagging an error when it
> does.  It's fixed in 3.15.0.1 and also in 3.14.12.3 when that comes out.

I just wanted to stress that there are many many other ways to end up with
record names that contain invalid characters. I think there should be (at
least) one point where things reliably and loudly fail if that is the case.

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de


References:
Re: Problem with the basic example Ned Arnold
Re: Problem with the basic example Benjamin Franksen
Re: Problem with the basic example Andrew Johnson

Navigate by Date:
Prev: Re: Problem with the basic example Andrew Johnson
Next: Matlab choices S. Stein
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Problem with the basic example Andrew Johnson
Next: Re: Problem with the basic example Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·