EPICS Home

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  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 
<== Date ==> <== Thread ==>

Subject: Re: Problem with the basic example
From: Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de>
To: <tech-talk@aps.anl.gov>
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 
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