2023 Codeathon project ideas - epics-base/epics-base GitHub Wiki

Codeathon Project Ideas

A collection of projects and development ideas for EPICS Codeathon sessions. They are not presented in any particular order.

Review Recent Pull Requests

Check the existing discussions and when there was last any activity to judge whether a particular PR is in need of review. Concentrate on PRs from this Codeathon, but if you see an older PR in an area that you have experience in we'd be happy for any additional insight that you might have in that area.

Bugs tagged 'codeathon'

  • On GitHub
  • On Launchpad — most of these are old and some may no longer be applicable, so try to replicate them and comment if they don't seem to be a problem any more.

Add help for iocsh commands

  • Added by: @mdavidsaver
  • Claimed by: @henrique-silva and @AlexanderWells-diamond
  • Difficulty: low

Add/expand the iocshFuncDef::usage messages for the builtin IOC shell commands. This string is printed by help <cmd>. Most of these commands were documented in the Application Developers Guide – look in the IOC Test Facilities chapter, or in the index.

Similar work can also be performed on external modules, but make sure that you use conditional compilation so the module can still be built against older versions of Base which don't support the extended usage help text.

Note that previous work has been done on this: https://github.com/epics-base/epics-base/pull/242

Cleanup compiler warnings

  • Added by: @mdavidsaver
  • Claimed by: @dirk-zimoch (in particular VxWorks)
  • Difficulty: low/moderate

Build Base with a recent compiler(s): GCC (eg. >= 8), clang, and/or msvc. Triage the various warnings. Identify any actual issues, and quiet false positives.

A task for multiple people working together. eg. could be partitioned by module and/or compiler. Check the LGTM.com scanner output for other similar kinds of issues.

See PR #250

Used compilers (for various 64 and 32 bit x86, ppc and arm Linux, 32 bit ppc vxWorks 6, and 32 and 64 bit Windows targets):

  • gcc 3.4.3, 4.2.2, 4.3.3, 4.4.2, 4.4.7, 4.6.1, 4.6.4, 4.7.2, 4.8.3, 4.8.5, 7.2.0, 11.2.0
  • clang 3.4.2, 12.0.0
  • (MSVC 1916 not yet...)

Tested C++ standards (using gcc): c++98, c++0x, c++11, c++17, c++20, c++23

GNU compilers could use -Wall -Werror now.

Further suggestion for either removing or marking all unused function arguments with EPICS_UNUSED: https://github.com/dirk-zimoch/epics-base/pull/4

MSVC printf() spec. validation

  • Added by: @mdavidsaver
  • Claimed by: @evalott100
  • Difficulty: low/moderate

See about applying _Printf_format_string_ and the -analysis compiler pass to various printf wrapper functions in Base.

This feature works ~like __attribute__((format, ... with GCC/clang, but is expressed differently. So the existing EPICS_PRINTF_STYLE() macro won't be enough.

Improve the CAS error message generated when an IOC gets port-scanned

  • Added by: @anjohnson
  • Claimed by: Marcio - @marciodo (SLAC)
  • Difficulty: moderate

cf. previous work https://github.com/epics-base/epics-base/pull/141

Read this tech-talk thread.

The code that needs changing is in camessage.c::camessage(). In the case described in tech-talk above, checking the condition msg.m_cmmd < NELEMENTS(tcpJumpTable) would have indicated that the TCP socket was not opened by a real CA client. There may be better ways to distinguish the first message received over TCP from a pre-3.12.0-beta1 client, but the IOC should attempt to detect non-CA clients and report them as such.

Github issue: https://github.com/epics-base/epics-base/issues/128

Enable CI builds of Base for Linux/ARM and aarch64

  • Added by: @mdavidsaver
  • Claimed by: @minijackson (Rémi NICOLE)
  • Difficulty: moderate

Builds for linux-arm and linux-aarch64 were added to the CI builder services, but are not yet configured for EPICS Base builds. Explore whether the unit tests can be run on GHA, beyond just cross-compiling (separate PR).

Add Doxygen annotations to C/C++ header files

  • Added by: @anjohnson
  • Difficulty: low
  • Claiming: Edit the wiki page linked below

https://github.com/epics-base/epics-base/wiki/Header-annotations-project

At previous Codeathons we have been annotating the public C/C++ API header files that get installed into the base/include directory so they can be parsed by Doxygen to generate reference documentation. The task then was to take the API descriptions from the libCom and libCom OSI chapters of the Application Developers Guide and add them to the relevant header files as Doxygen annotations. Many of those annotations have now been completed, but there are still many remaining, including those for the IOC and Channel Access APIs.

This task requires you to checkout and build the EPICS 7.0 development branch, and to have installed the Doxygen program and any tools which it needs (the tool dot is used to generate diagrams for instance, that may be installed as part of GraphicsMagick). Before you can run Doxygen you must have configured and built Base for your host architecture, or at least run make inc at the top level. Run that again after you've edited any header files (don't edit files directly in the include directory, it's easy to lose all your work if you do that). Then to have Doxygen process the annotations cd documentation; make. To view the results in your browser, use File Open and navigate to the base/documentation/O.linux-x86_64/html directory (or its equivalent for your $EPICS_HOST_ARCH setting) and open the index.html file to see the main page.

Many of the APIs in the include files are described detail in the EPICS Application Developers Guide — that link goes to the last version we published, for Base-3.16.2. There's a useful Index at the end of that which can help you find documentation about specific functions or commands.

Create tests for functionality of the Base record types and device support

  • Added by: @anjohnson
  • Difficulty: medium-low
  • Claiming: Edit this wiki page, add the record type and your name/handle to the list below:
  1. xxRecord your-name
  2. bo Karl Vestin
  3. bi Karl Vestin
  4. printf Karl Vestin
  5. ai Karl Vestin

The self-tests in Base (make runtests or make tapfiles test-results) don't cover the behavior of many of the built-in record types and soft device support included. Some do have tests, although they might only cover some more recently-added functionality. New tests that demonstrate the documented operation of these would be welcome. The descriptions in the Record's reference page might also be out of date, so please check and update the text first and ask if you're not sure — in general the code should be definitive. A first project might be to examine what tests would be worth adding.

Generated Base Documentation: Provide versioned content

  • Added by: @ralphlange
  • Difficulty: medium
  • Claimed by: @ralphlange & Timo

The generated documentation from EPICS Base (Doxygen and static HTML) should be run on GHA in a way that allows browsing it by release version. Still using RTD tools and styles, but not published there.

RTEMS: Generate Documentation

  • Added by: @hjunkes
  • Difficulty: medium
  • Claimed by: @hjunkes

The idea is to write a usable guide to install EPICS7 (base + modules) on a RTEMS6 system.

  1. beatnik (MVME6100)with modules : seq, asyn, busy, calc, autosave, devlib2, recsnyc, iocStats, motor, sscan, StreamDevice, ...) ( We have access to this hardware and I/O cards, e.g. SIS3316 )
  2. qemu-arm, qemu-pc686, qemu-mvme3100?
  3. If we still have time, we can adapt the manual to RTEMS5 (with and without LEGACY_STACK).
  4. And if there is still time ;-)
  5. also for new boards like MVME2500 ...

It would be nice if a native speaker could join in here.

Programming work:

Finish RTEMS5/6 for epics-base, possibly add support for raspi-2 hardware and build it as a demo project.

Requests from SLAC for cexp and other stuff?

Finish iocDevStat for RTEMS5/6 and release it (there is an implementation by Miroslav Dach that already works quite well).

Discuss NFSv4 with Chris Johns.

Discuss NTP/PTP2 with Chris. Info just for myself: hw-host == rizzo

Allow qsrv fields to be generated in parse order

  • Added by: @coretl
  • Difficulty: medium
  • Claimed by:

Add a mechanism to control the order that records are aded in qsrv.

See https://github.com/epics-base/pva2pva/issues/53

JCA lockup when IOC responds to UDP but not TCP

  • Added by: @aawdls
  • Difficulty: medium
  • Claimed by: @rjwills

When connecting to a PV, if the IOC will respond to the UDP search request but establishing the TCP connection fails, JCA will take an extremely long time to connect to any other PVs, effectively locking up the session. This is seen in CS-Studio as almost all widgets showing white / disconnected. Although a relatively rare case, there are a couple of mechanisms for such a failure and the impact is severe.

See https://github.com/epics-base/jca/issues/36

Prototype a spec for the BOB file format

  • Added by @aawdls
  • Difficulty: medium/big
  • Claimed by: @aawdls, @joehshannon

We would like to collaborate around the BOB file format and allow multiple client implementations to coexist (DLS's interest is in a new web-based client). The knowledge of the widgets, properties and defaults is contained in the Phoebus code. We are proposing to develop a spec for the file format to capture this information, and agree a process for making changes that can propagate to all client implementations.

There are three technical levels at which this can be done:

  1. Documentation only: extract existing information into a spec document. Implementations are based on this. Changes need to be synced by hand.
  2. Write an XML schema and use this for validation in all implementations. Changes are agreed and updated in the schema, prompting implementations to update
  3. Write an XML schema and write a library that uses the schema to generate dataclasses/records in java, typescript,... to be used for the model in the client implementations.

During the codeathon we could agree an approach and develop a very basic prototype. DLS like idea number 3.

Phoebus documentation

  • Added by @katysaintin
  • Difficulty: medium
  • Claimed by: @katysaintin
  1. Development of a java tool to generate document file for all the existing widgets in Phoebus (property name and type). This tool will use Java Reflection Api to create dynamically this documentation each time a new widget or a new property is created. The document file format has to be defined (see the previous topic)

  2. Add documentation on script python and jython Conversion impact when convert CSS opi file to Phoebus Bob file Add examples of scripts to use MACRO (change the value dynamically ...) Improve examples for Table and ComboBox ... widgets (function are note the same from SWT to JavaFX)

JCA issues

  • Added by @katysaintin
  • Difficulty: medium
  • Claimed by: @katysaintin
  1. On the same idea of previous topic on JCA issue (lockup) All client using JCA (CSS and Phoebus) are sometime freezing when some PV are disconnected. I will analyse the problem through Java Profiling tool jvisualvm

  2. When closing a jca Client, a CARepeater is still running, and sometime we have to kill the process. (Port is already used by the old one). So we will try to clear properly the process.

Archive Appliance improvements

  • Added by @lcaouen
  • Difficulty: medium
  • Claimed by: @lcaouen
  1. Add a "delete selected PV" button to the web page and create the web api route (DeletePVs)
  2. Improve performance when checking status with * wildcard and a lot of PVs in the database

Add statistic counters to caPutLog

  • Added by: @henrique-silva
  • Difficulty: low
  • Claimed by: @henrique-silva

See https://github.com/epics-modules/caPutLog/issues/11

PR for review: https://github.com/epics-modules/caPutLog/pull/16

⚠️ **GitHub.com Fallback** ⚠️