Backlog

Overview

The backlog serves as a scratchpad for ideas. To improve its readability it has been divided into a few categories. Once the ideas get materialized as 'issues' they shall be removed from here.

Refactor

This section spots solutions to be reworked. Just to make things better or more flexible.

1. The names of the signals as well as other properties are stored with every signal's instance. They could be grouped so as to reduce the memory usage. Two solutions were discussed:

   • A separate container for every signal (makes merging more difficult)
   • A pointer to a signal descriptor goes with every signal [Planned for v3.1.1]

2. Exception handling code is duplicated for vcdMaker and vcdMerge. It shall be common. [Planned for v3.0.1]

3. Warnings could be enumerated so as it would be easier to refer to them in the user manual.

4. Parsing sources could be parallel (let's use C++ enhancements). It leads to another problem: synchronizing the output information on the standard output.

5. Flex and Bison auto-generated files can be generated on the fly. This could be integrated to cmake as well as VS.

6. Cmake shall generate statically linked binaries for the zip

   • https://stackoverflow.com/questions/38694058/cmake-linking-statically-against-libgcc-and-libstdc-into-a-shared-library
   • set(CMAKE_EXE_LINKER_FLAGS " -static")
     target_link_libraries(myLib -static-libgcc -static-libstdc++)
     added in commonTarget.cmake
   • Check dynamically linked libraries
     ldd vcdMaker
     objdump -p vcdMaker | grep NEEDED
   • Fedora needs static libraries
     yum install libstdc++-static.x86_64
     yum install glibc-static.x86_64
   • Check by
     yum list installed
     yum install search libname

7. VS shall also generate statically linked version of the package.

Quality

Quality related item and actions.

1. Unit tests are needed. The UT framework needs to be selected (e.g. Catch) and applied. [Planned for v3.0.1]

2. Functional tests. Python scripts shall be updated. See the proposal. [Planned for v3.0.1]

3. Ctest usage. Unit tests as well as functional tests to be executed by ctest(cmake). [Planned for v3.0.1]

4. Code documentation. Let's create some diagrams using PlantUML. [Planned for v3.0.1]

5. Independent Doxygen documentation. E.g. use markdown as in Eigen.

6. Static Analysis. E.g. Scan Coverity. [Planned for v3.0.1]

7. 'cmake' shall be split. [Planned for v3.0.1].

8. While adding new signals to the database just names are checked. What if the signal's size is 0? What if different size or type is provided for the same signal name? [Planned for v3.0.1]

9. Generating code coverage information. Use Coveralls. [Planned for v3.1.1]

10. Executing unit tests as well as integration tests automatically in the CI cycle. [Planned for v3.1.1]

11. Comparison tests shall compare also the execution standard output so as failing test cases could be automated. [Planned for v3.1.1]

12. Valgrind check by Travis.

13. Convert vcd examples to 64-bit vector formats.

14. Add instructions on handling tar/zip archives.

New features

The future of the vcdMaker!

1. VCD files parsing. E.g. as an input to vcdMerge.

2. Parsing user logs. [Planned for v3.0.1]

   • Defining the format in XML
   • Creating a common parser interface

3. Parsing user logs examples.

   • STM Studio alike output
   • Identify other popular loggers

4. On-line manual.

5. Time multiplier. VCD format allows for time stamps specified in 10x or 100x of units. The option could be provided to vcdMaker and vcdMerge.

6. OS X version with the corresponding installer. [Planned for v3.1.1]

7. Compact VCD files. The output VCD files could be smaller by hashing signal names. Maybe this could be provided as an option to be enabled (e.g. -c).

8. Time and date. Currently the time and the data in the output VCD file are fixed strings. [Planned for v3.0.1]

9. User guide. The origin and the meaning of the provided examples shall be explained. [Planned for v3.0.1]

10. Instrumentation. Adding artificial signals (sums, lesser/greater, filtering, etc.) [Planned after v3.0.1]

11. Parsing the log line endings. All formats shall be acceptable in all systems (e.g. '\r\n' in Linux). That's because many serial terminals show the log properly just for 'r\n'. [Planned for v3.0.1].

12. CSV output generation. [Planned for v4.0.1]

Updates

Items required to be done before creating a new release.

1. Windows installer. Bootstrapper versioning shall be clarified. [Planned for v3.0.1]

2. User Guide for v3.0.1. [Planned for v3.0.1]

3. New samples. [Planned for v3.0.1]