On 16/1/2023 6:56 pm, Sebastian Huber wrote: > On 16.01.23 01:35, Chris Johns wrote: >> On 13/1/2023 1:54 am, Sebastian Huber wrote: >>> On 12.01.23 15:44, Kinsey Moore wrote: >>>> The other two patches look fine to me. The use of dump() that results in >>>> this >>>> patch does several things: >>>> * Removal of whitespace >>>> This is fine for whitespace at the base level of indentation. Whitespace >>>> within an indented block may be more important for readability. >>>> >>>> * Removal of comments >>>> This is not good as they are exclusively used to annotate manually ordered >>>> blocks of test result expectations >>>> >>>> * Rearrangement of items in alphabetical order >>>> In general, rearrangement of top-level sections is good. For indented >>>> sections >>>> specifically in tst*.yml, this is bad for the above reaso >>> One goal of the new build system was to be able to alter the data through >>> scripts. This requires that the build items are human and machine readable >>> and >>> writable. The Python YAML import/export does not preserve white space and >>> comments. >> Can someone edit the file and add a hex number? > > Yes, you can manually use whatever format is understood by the YAML loader. > When > you write the file with the YAML dumper, then the standard representation is > used.
Are there python modules in rtems.git someone could import that reads and writes the YAML spec files? If not should we provide a module to do this? It could be `spec` so a user can use `import spec` after setting the import path. That is, if external scripts (and I encourage this) all used a common read and write type functionality the format consistency is relative to specific version of rtems.git being used. Updates become read then write. > I changed the representer to use the format attribute, see v2 of the patch: > > https://lists.rtems.org/pipermail/devel/2023-January/074094.html > I see and thanks. How many format strings would cover the majority of formats we have? I am wondering if `format:` is checked against a standard list and those are part of the "writer" support? For example `address`, `address32`, `hex64` etc? I am concerned about repeated common format strings being placed through all the spec files. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel