Hi,
Thank you to everyone who responded to my last post on VDCT support. I
found that the adoption of it has varied, and that the groups that
haven't adopted it widely are largely sitting on the fence because it
has a number of irritating bugs - particularly for those wanting to use
it as a replacement for a schematic capture tool like Capfast. It is
basically a reasonable replacement for GDCT, but not for Capfast, yet.
This corresponds to my perception - and I would like VDCT to become more
widely used than this. I feel it is important that we have a
well-defined ASCII database file format, so many tools can parse the
file, but only one standard DCT, so that we can develop it in
conjunction with other EPICS developments, so that the toolset matches
the base developments. VDCT is the only contender on the latter front,
and so it needs to be made good enough - before we start enhancing it
with new features (for example, developing the database file format for
version 4). In particular, in the future I feel that we need a
hierarchical tool to enable us to develop standard devices, so that we
can develop a good interface to high level applications.
As a result of all this I have:
1. Drawn up a consolidated list of bugs and feature requests and put
them on the Wiki.
2. Visited Cosylab last week to discuss the effort required to implement
various requests.
The consolidated list is at:
http://www.aps.anl.gov/epics/wiki/index.php?title=VDCT_Bugs_and_Features
_Page
I believe that we, at Diamond, can now fund some of this development -
specifically the items marked priority 1 and 2 on this list. I have
exercised total editorial discretion in determining these priorities and
if you want any input to this process now is your chance to tell me I'm
wrong. Please read the wiki page and let me know if you disagree with my
assessments, and please make reasonable, constructive suggestions, on
how we can do this better. If you just like the way it is, it would be
good to hear this too, because it helps me write a case.
Finally, one thing of note was that no-one made any offer to contribute
to this project. This is probably not surprising really and I am happy
to take the lead, but contributions do not have to be entirely in cash.
In this case, VDCT has been developed as an open source project. I have
found it relatively easy to build - and one of the items on the work
list it to make it even easier. So, if you discover a problem in the
future and have some Java effort available, bug fixes are always
welcome...
I look forward to hearing from you all.
Cheers,
Nick Rees
Principal Software Engineer Phone: +44 (0)1235-778430
Diamond Light Source Fax: +44 (0)1235-446713
- Navigate by Date:
- Prev:
3.14.8 release? Geoff Savage
- Next:
Re: dynamic libraries location Ralph Lange
- 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:
VDCT Support Rees, NP (Nick)
- Next:
RE: VDCT Support Rees, NP (Nick)
- 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
|