On 17/1/2023 6:39 pm, Sebastian Huber wrote: > On 17.01.23 03:48, Chris Johns wrote: >> 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. > > The Python modules to work with specification items are in rtems-central.git. > This repository contains also a format specification of the build items.
And how does that help here with this repo? I suggest you reconsider the accessibility of those modules before pushing scripted generation changes like this into rtems.git. > We > could add an action to a Github work flow to check the build item format for > pull requests and commits. Thanks for including github in this thread. It has now confirmed my position of no github automations in our repos (including rtems-central). >>> 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. > > The format string is a standard Python format string. This is easy to > implement > and flexible. We could replace this with a fixed set of formats. Maybe if you have scripting support which this repo does not. I think the formats should be controlled however I see the whole discussion and patch as academic until rtems.git has scripting support in python modules. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel