Experimental Physics and Industrial Control System
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
<2012>
2013
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024