Future Development Ideas - Revision history

AndrewJohnson at 19:51, 1 June 2016

2016-06-01T19:51:31Z

← Older revision		Revision as of 19:51, 1 June 2016
Line 127:		Line 127:

	See original proposal by ANJ, which needs to be modified to add notify interfaces. This work is already under way, talk to ANJ.		See original proposal by ANJ, which needs to be modified to add notify interfaces. This work is already under way, talk to ANJ.

			Part of this development (June 2016) includes [[JSON Field Values]].

	=== Array Field Support ===		=== Array Field Support ===

AndrewJohnson: Separate out tasks for the Codeathon

2014-07-10T17:11:31Z

Separate out tasks for the Codeathon

← Older revision		Revision as of 17:11, 10 July 2014
Line 5:		Line 5:


	== Tasks which could be done now ==		== Tasks for the 2014 Codeathon ==

			These items are of particular interest to have completed before the 3.15.0.2 release in September 2014.

			<blockquote>

			=== Bug Triage and Fixing ===

			See the [https://bugs.launchpad.net/epics-base Launchpad bug tracker]. Bug
			triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.

			=== Review Merge Proposals ===

			The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging.

			=== Record Reference Manual ===

			Work has started on embedding the RRM text inside the record type DBD files, but most record types have still to be documented this way. See ANJ's [https://code.launchpad.net/~anj/epics-base/dbd2html DBD To HTML branch] which contains the work done so far.

			=== Dynamic Array Support ===

			Neither the CAS nor the PV Gateway support the dynamic array size protocol changes that were added in 3.14.12, and it's starting to show.

			=== More test programs ===

			There are test programs in libCom/test which cover quite a lot of the libCom functionality, but they are by far from complete. Writing test code is a very good way to learn the capabilities of the code being tested, and is not usually hard to to, so this would be a good "getting started" project. Specific tests include:

			* Tests for each of the Base record types and device support. This should be based on ANJ's [https://code.launchpad.net/~epics-core/epics-base/ioc-test-module/ IOC Test Module] branch so the tests can be written in Perl.
			* Any parts of libCom which don't currently have tests in libCom/test (C code)
			* Rewrite the tests from the epics-soft-test suite (C or Perl).

			=== Convert makeBpt into Perl ===

			The makeBpt tool in src/bpt generates non-linear break-point tables from data files. A fair bit of the C code is concerned with parsing the input file. There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code. Maybe start this project by writing a program to test the output, then convert the C code into Perl.

			=== Support for 64-bit integer fields ===

			ANJ has started adding support for DBF_INT64 and DBF_UINT64 types to the database, but the result has not been heavily tested and may not work on all target architectures (in particular VxWorks). See ANJ to work on this.

			</blockquote>

			== Other Tasks which could be done now ==

	These items can be worked on immediately as they do not depend on any other work to have been completed.		These items can be worked on immediately as they do not depend on any other work to have been completed.
Line 16:		Line 57:
	triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.		triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.

	=== Review ~~and rebase~~ Merge Proposals ===		=== Review Merge Proposals ===

	The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging~~. In some cases this code needs to be rebased onto the 3.15 branch~~.		The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging.

	=== Documentation ===		=== Documentation ===
Line 25:		Line 66:

	<blockquote>		<blockquote>

	~~==== Record Reference Manual ====~~

	* Work has started on embedding the RRM text inside the record type DBD files, but most record types have still to be documented this way. See Andrew's [https://code.launchpad.net/~anj/epics-base/dbd2html DBD To HTML branch] which contains the work done so far.

	==== Application Developers Guide ====		==== Application Developers Guide ====
Line 41:		Line 78:

	* Look at all the documentation we have and see what's missing		* Look at all the documentation we have and see what's missing

	~~</blockquote>~~

	~~=== Dynamic Array Support ===~~

	~~Neither the CAS nor the PV Gateway support the dynamic array size protocol changes that were added in 3.14.12, and it's starting to show.~~

	~~=== More test programs ===~~

	There are test programs in libCom/test which cover quite a lot of the libCom functionality, but they are by far from complete. Writing test code is a very good way to learn the capabilities of the code being tested, and is not usually hard to to, so this would be a good "getting started" project. Specific tests include:

	* Tests for each of the Base record types and device support
	* Any parts of libCom which don't currently have tests in libCom/test
	* Rewrite tests from the epics-soft-test suite

	~~=== Convert makeBpt into Perl ===~~

	The makeBpt tool in src/bpt generates non-linear break-point tables from data files. A fair bit of the C code is concerned with parsing the input file. There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code. Maybe start this project by writing a program to test the output, then convert the C code into Perl.

	=== VxWorks SMP Support ===		=== VxWorks SMP Support ===
Line 88:		Line 107:

	Libs affected: ca, cas, rsrv		Libs affected: ca, cas, rsrv

	~~=== Support for 64-bit integer fields ===~~

	ANJ has started adding support for DBF_INT64 and DBF_UINT64 types to the database, but the result has not been heavily tested and it does not yet work on all target architectures (in particular VxWorks). See ANJ to work on this.

	</blockquote>		</blockquote>

AndrewJohnson at 21:58, 8 July 2014

2014-07-08T21:58:31Z

← Older revision		Revision as of 21:58, 8 July 2014
Line 89:		Line 89:
	Libs affected: ca, cas, rsrv		Libs affected: ca, cas, rsrv

	=== ~~Conversion Code Clean~~-Up ===		=== Support for 64-bit integer fields ===

	~~The existing conversion routines (i.e.~~ the ~~fast~~ and ~~full versions~~ in db) ~~could be significantly cleaned up by using C++ templated functions~~. ~~There would probably be minor savings in object code size, but major savings in terms of source code size and clarity.~~		ANJ has started adding support for DBF_INT64 and DBF_UINT64 types to the database, but the result has not been heavily tested and it does not yet work on all target architectures (in particular VxWorks). See ANJ to work on this.

	~~Here's a [[Conversion Code Clean-Up\|more detailed description]] of how~~ this ~~could be done~~.

	~~Libs affected: dbStatic, db~~

	</blockquote>		</blockquote>

AndrewJohnson: Removed old stuff, update status.

2014-07-07T23:31:58Z

Removed old stuff, update status.

Show changes

AndrewJohnson: Dynamic array support for CAS and PV Gateway

2012-02-24T18:41:14Z

Dynamic array support for CAS and PV Gateway

← Older revision		Revision as of 18:41, 24 February 2012
Line 43:		Line 43:

	</blockquote>		</blockquote>

			=== Dynamic Array Support ===

			Neither the CAS nor the PV Gateway support the dynamic array size protocol changes that were added in 3.14.12, and it's starting to show.

	=== More test programs ===		=== More test programs ===

AndrewJohnson at 16:27, 14 July 2011

2011-07-14T16:27:10Z

← Older revision		Revision as of 16:27, 14 July 2011
Line 50:		Line 50:
	Check the code coverage report from the		Check the code coverage report from the
	[http://controls.diamond.ac.uk/downloads/other/epics-base-report/ Diamond Autotest Results] for ideas on what code to tackle, although that hasn't been run for quite a while now.		[http://controls.diamond.ac.uk/downloads/other/epics-base-report/ Diamond Autotest Results] for ideas on what code to tackle, although that hasn't been run for quite a while now.

	~~Priority: Medium~~

	=== IOC Test Framework in Perl ===		=== IOC Test Framework in Perl ===

	Once we have good test coverage for libCom we should look at IOC-level testing, including tests for individual record types. This needs code to start a soft IOC with a particular database file, make channel connections over CA and perform the necessary tests, then close down the IOC and clean up. Tests should be automated, i.e. generate TAP output and run under the standard Perl Test::Harness, as used by the 'make runtests' target.		Once we have good test coverage for libCom we should look at IOC-level testing, including tests for individual record types. This needs code to start a soft IOC with a particular database file, make channel connections over CA and perform the necessary tests, then close down the IOC and clean up. Tests should be automated, i.e. generate TAP output and run under the standard Perl Test::Harness, as used by the 'make runtests' target.

			Benjamin Franksen appears to have developed something that does this already for testing the sequencer version 2.1 code, take a look at that first...

	Once the framework exists, write test programs for each core record type and device support. Look at the Soft-Test suite and implement those tests too, although a complete rewrite might be appropriate for them...		Once the framework exists, write test programs for each core record type and device support. Look at the Soft-Test suite and implement those tests too, although a complete rewrite might be appropriate for them...

AndrewJohnson: Various updates

2011-07-12T18:41:31Z

Various updates

← Older revision		Revision as of 18:41, 12 July 2011
Line 15:		Line 15:
	See the [https://bugs.launchpad.net/epics-base Launchpad bug tracker]. Bug		See the [https://bugs.launchpad.net/epics-base Launchpad bug tracker]. Bug
	triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.		triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.

			=== Review and rebase Merge Proposals ===

			The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging. In some cases this code needs to be rebased onto the 3.15 branch.

	=== Documentation ===		=== Documentation ===
Line 24:		Line 28:
	==== Record Reference Manual ====		==== Record Reference Manual ====

	* Extend the DBD to HTML converter so we can move detailed record reference documentation into the record.dbd and/or record.c files. Should we attempt to embed the RRM text inside the DBD files?		* Extend the DBD to HTML converter so we can move detailed record reference documentation into the record.dbd and/or record.c files. Should we attempt to embed the RRM text inside the DBD files? This relies on Andrew's [https://code.launchpad.net/~anj/epics-base/compiled-dbd compiled-dbd branch] which contains the work done so far.

	==== Application Developers Guide ====		==== Application Developers Guide ====
Line 45:		Line 49:

	Check the code coverage report from the		Check the code coverage report from the
	[http://controls.diamond.ac.uk/downloads/other/epics-base-report/ Diamond Autotest Results] for ideas what code to tackle.		[http://controls.diamond.ac.uk/downloads/other/epics-base-report/ Diamond Autotest Results] for ideas on what code to tackle, although that hasn't been run for quite a while now.

	Priority: Medium		Priority: Medium
Line 51:		Line 55:
	=== IOC Test Framework in Perl ===		=== IOC Test Framework in Perl ===

	Once we have good test coverage for libCom we should look at IOC-level testing, including tests for individual record types. This needs code to start a soft IOC with a particular database file, make channel connections over CA and perform the necessary tests, then close down the IOC and clean up. Tests should be ~~automatable~~, e.~~g. by generating~~ TAP output and run under the standard Perl Test::Harness, as used by the 'make runtests' target.		Once we have good test coverage for libCom we should look at IOC-level testing, including tests for individual record types. This needs code to start a soft IOC with a particular database file, make channel connections over CA and perform the necessary tests, then close down the IOC and clean up. Tests should be automated, i.e. generate TAP output and run under the standard Perl Test::Harness, as used by the 'make runtests' target.

	Once the framework exists, write test programs for each core record type and device support. Look at the Soft-Test suite and implement those tests too, although a complete rewrite might be appropriate for them...		Once the framework exists, write test programs for each core record type and device support. Look at the Soft-Test suite and implement those tests too, although a complete rewrite might be appropriate for them...
Line 84:		Line 88:
	=== Packagable Build System ===		=== Packagable Build System ===

	The EPICS Build system currently does not distinguish between programs that are needed by IOC developers (e.g. dbToMenuH) and end-user programs (e.g. caget). We could divide our build targets into these very easily, which would make packaging EPICS Base much more straight-forward. I see the following ~~parts~~:		The EPICS Build system currently does not distinguish between programs that are needed by IOC developers (e.g. dbToMenuH) and end-user programs (e.g. caget). We could divide our build targets into these very easily, which would make packaging EPICS Base much more straight-forward. This should be based on Michael's [https://code.launchpad.net/~mdavidsaver/epics-base/reorg-src reorganized source branch], although that should have been merged into the 3.15 branch before the Codeathon.

			I see the following separate packages:

	<blockquote>		<blockquote>
Line 92:		Line 98:
	* catools		* catools
	* Shared libraries		* Shared libraries
	* SoftIoc (~~requires compiled-in~~ DBD ~~data~~ though)		* SoftIoc (relies on a DBD file though)

	These could be installed into /usr/local from an RPM or equivalent packaging system.		These could be installed into /usr/local from an RPM or equivalent packaging system.
Line 150:		Line 156:
	=== Online Record Creation ===		=== Online Record Creation ===

	It might be possible to add new record instances at runtime, although delete would need a change to the record interface to support. The tricky thing is to do this in a manner which is completely thread-safe since the ~~pdbbase~~ structure does not have many locks, and adding them could significantly affect operation of the IOC.		It might be possible to add new record instances at runtime, although delete would need a change to the record interface to support. The tricky thing is to do this in a manner which is completely thread-safe since the dbBase structure does not have many locks, and adding them could significantly affect the speed of operation of the IOC.

	Libs affected: dbStatic, db, misc		Libs affected: dbStatic, db, misc
Line 172:		Line 178:
	=== Compiling DBD Files ===		=== Compiling DBD Files ===

	A Perl implementation of the DBD file parser exists and provides working dbdToRecordH and dbdToMenuH scripts. ~~I'm working to revive my plans~~ to convert all DBD file information into C tables that get compiled into the IOC executable or its shared libraries.		A Perl implementation of the DBD file parser exists and provides working dbdToRecordH and dbdToMenuH scripts. The aim is to convert all DBD file information into C tables that get compiled into the IOC executable or its shared libraries, so the no DBD data has to be read it at initialization time.

	With ~~this~~ parser written in Perl, it ~~is much~~ easier to add new facilities to DBD files, such as ~~adding~~ new field types (see Variable Length Strings below).		With the DBD parser written in Perl, it will be easier to add new facilities to DBD files, such as new field types (see Variable Length Strings below).

	~~Libs affected~~: ~~dbStatic, +dbHost, db~~.		The code is in the [https://code.launchpad.net/~anj/epics-base/compiled-dbd compiled-dbd branch].

	</blockquote>		</blockquote>
Line 192:		Line 198:
	The command information in the DBD file will also be useful for future versions of the IRMIS parser for st.cmd scripts, where we need to be able to tie the device support configuration commands into IRMIS' need to map hardware devices to record addresses.		The command information in the DBD file will also be useful for future versions of the IRMIS parser for st.cmd scripts, where we need to be able to tie the device support configuration commands into IRMIS' need to map hardware devices to record addresses.

	This work should be done in the compiled-dbd branch.		This work should be done in the [https://code.launchpad.net/~anj/epics-base/compiled-dbd compiled-dbd branch].

	Libs affected: dbHost, all libs Registrar code.		Libs affected: dbHost, all libs Registrar code.

AndrewJohnson: Added vxWorks SMP task

2011-02-14T18:21:06Z

Added vxWorks SMP task

← Older revision		Revision as of 18:21, 14 February 2011
Line 58:		Line 58:

	The makeBpt tool in src/bpt generates non-linear break-point tables from data files. A fair bit of the C code is concerned with parsing the input file. There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code. Maybe start this project by writing a program to test the output, then convert the C code into Perl.		The makeBpt tool in src/bpt generates non-linear break-point tables from data files. A fair bit of the C code is concerned with parsing the input file. There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code. Maybe start this project by writing a program to test the output, then convert the C code into Perl.

			=== VxWorks SMP Support ===

			Recent versions of vxWorks (6.8+) support SMP but present a slightly different API that removes intLock() and taskLock(), and replaces taskVar with __thread variables. The current OSD routines for vxWorks will need significant modification to work with the new APIs. This might require a different target architecture, although if the amount of change is small enough it might be possible to use conditional compilation instead.

			Can obviously only be done by someone with access to vxWorks 6.8 or later.

	=== Database diagnostics ===		=== Database diagnostics ===

AndrewJohnson: Edited to remove (almost) completed projects.

2011-02-03T17:56:23Z

Edited to remove (almost) completed projects.

Show changes

RalphLange: /* Conversion Code Clean-Up */

2010-10-18T16:24:33Z

Conversion Code Clean-Up

← Older revision		Revision as of 16:24, 18 October 2010
Line 157:		Line 157:
	The existing conversion routines (i.e. the fast and full versions in db) could be significantly cleaned up by using C++ templated functions. There would probably be minor savings in object code size, but major savings in terms of source code size and clarity.		The existing conversion routines (i.e. the fast and full versions in db) could be significantly cleaned up by using C++ templated functions. There would probably be minor savings in object code size, but major savings in terms of source code size and clarity.

	Here's a [[Conversion Code Clean-up\|more detailed description]] of how this could be done.		Here's a [[Conversion Code Clean-Up\|more detailed description]] of how this could be done.

	Priority: 3.15<br>		Priority: 3.15<br>