Now for the second installment: USING (Feri) ----------------------- A. winetest Winetest will have to support a new option -B <filename> This will add a new section to the report, just before the test results, called "Build Info". The body of this section will be read from <filename>, with each time indented (say 4 spaces), and a blank line to end it (for neatness). B. Dissect & gather Need only recognize the "Build Info" section as optional, and ignore it for now. Maybe dissect should do that as a rule, ignore sections it doesn't understand. This way we can easily add more data in the future, without needing to constantly patch dissect. Such sections would have all lines indented, and would end with a blank line. BTW Feri, can we indent the body of our current sections? Would that break stuff? It would be nice to, would make the report more readable. We should be more forgiving with the parsing, like HTML is. The idea would be: "we should look only for stuff that we need for the report, additional stuff should be ignored. Moreover, non-essential stuff should be optional, and if not present/parsed, don't display". -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
BTW Feri, can we indent the body of our current sections?
The OS version section is already indented, although that's optional an it's defined instead as a series of equations. The only other section, Test output is not indented, and that would go against my design principle, which is to have the tests write their output exactly as they want to by redirection. Do you have anything else in mind?
It would make the report more readable.
One shouldn't read the report at all. One can read the important parts of it separately. If a feature is missing, we should add it the most usable way.
We should be more forgiving with the parsing, like HTML is. The idea would be: "we should look only for stuff that we need for the report, additional stuff should be ignored. Moreover, non-essential stuff should be optional, and if not present/parsed, don't display".
Well, I'm parsing stuff written by myself, and being strict simplifies code at both ends. On the other hand, I took quite some effort to ensure bit-by-bit fidelity in the test results. So strict parsing is unavoidable at some places. Presently, non-essential stuff can be empty. My pending patches change the file format, still I didn't provide a smooth path forward as we are testing. I'm not even sure about the best way of doing so. I'm toying with the idea of a separate conversion tool to be run once on the open builds and always before dissect until we close all previous builds. If we do. -- Feri.
On April 22, 2004 7:26 pm, Ferenc Wagner wrote:
The OS version section is already indented, although that's optional an it's defined instead as a series of equations. The only other section, Test output is not indented, and that would go against my design principle, which is to have the tests write their output exactly as they want to by redirection. Do you have anything else in mind?
You are right, I haven't looked at a report in a while, it looks very good. I agree with you that the Test section should not be indented, I only meant the metadata ones that come before. (And yes, the Operating system version section is indented exactly as I wanted it :)). -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Winetest will have to support a new option -B <filename> This will add a new section to the report, just before the test results, called "Build Info".
Why not to put this into a resource instead? I implemented the URL option because I thought the permanent archive URL may not be known at build time; it's surely not the case now. -- Feri.
On April 22, 2004 8:38 pm, Ferenc Wagner wrote:
Why not to put this into a resource instead? I implemented the URL option because I thought the permanent archive URL may not be known at build time; it's surely not the case now.
Yes, but it seems easier like this. We handle winetest sources, they build, they don't need to mess with the sources they build. Besides, the implementation is trivial, I'll produce a patch. If there are reasons why we would want these in the resources, we can trivially move it there. But for now, from an operational perspective, it does seem easier to manage like this. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
On April 22, 2004 8:38 pm, Ferenc Wagner wrote:
Why not to put this into a resource instead? I implemented the URL option because I thought the permanent archive URL may not be known at build time; it's surely not the case now.
Yes, but it seems easier like this. We handle winetest sources, they build, they don't need to mess with the sources they build.
Well, they already have to take care about the WINE_BUILD environmental variable. We could instead/also mandate the presence of script which is run by maketest and produces all the build information we need: tag, archive url and build info block. It has to be a script if we want automatically determined version numbers for the build tools. Why do I advocate this? Because I want winetest be a standalone application easy to run also by occasional testers besides WinRash users how aren't affected by our way of implementing all this. If we neglect this winetest won't really serve a useful purpose anymore. Clearly, the burden of providing two or three long (albeit static) command line options isn't what users want. If I'm not fundamentally mistaken, I'll start along this route. It can't be that hard. Kevin, Paul, please speak up! Is the URL determined at build time or by the service script? If so, it will have to remain a command line option or be computed when we generate the HTML, only the build tag and the build info could be moved into resources. -- Feri.
On Friday 23 April 2004 08:48 am, Ferenc Wagner wrote:
Well, they already have to take care about the WINE_BUILD environmental variable. We could instead/also mandate the presence of script which is run by maketest and produces all the build information we need: tag, archive url and build info block. It has to be a script if we want automatically determined version numbers for the build tools.
This would be fine with me, I'm currently doing something along those lines to create the .info file dimi mentioned
If I'm not fundamentally mistaken, I'll start along this route. It can't be that hard. Kevin, Paul, please speak up! Is the URL determined at build time or by the service script? If so, it will have to remain a command line option or be computed when we generate the HTML, only the build tag and the build info could be moved into resources.
I cant speak for Paul, but my URL is determined before build time so could easily be included in the build
Hi everyone, (catching up with email...) On Fri, 23 Apr 2004, Kevin Koltzau wrote:
If I'm not fundamentally mistaken, I'll start along this route. It can't be that hard. Kevin, Paul, please speak up! Is the URL determined at build time or by the service script? If so, it will have to remain a command line option or be computed when we generate the HTML, only the build tag and the build info could be moved into resources.
I cant speak for Paul, but my URL is determined before build time so could easily be included in the build
In principle, the URLs known in advance, modulo changes that don't affect winetest.exe: if the binary is the same, there's nothing to do and no binary is produced or reported. AFAIK, its difficult to know (automatically) when a change is going to affect winetest.exe, so we can't know in advance if a URL will be valid or not. ---- Paul Millar
Paul Millar <paulm(a)astro.gla.ac.uk> writes:
On Fri, 23 Apr 2004, Kevin Koltzau wrote:
If I'm not fundamentally mistaken, I'll start along this route. It can't be that hard. Kevin, Paul, please speak up! Is the URL determined at build time or by the service script? If so, it will have to remain a command line option or be computed when we generate the HTML, only the build tag and the build info could be moved into resources.
I cant speak for Paul, but my URL is determined before build time so could easily be included in the build
In principle, the URLs known in advance, modulo changes that don't affect winetest.exe: if the binary is the same, there's nothing to do and no binary is produced or reported.
AFAIK, its difficult to know (automatically) when a change is going to affect winetest.exe, so we can't know in advance if a URL will be valid or not.
Hi Paul, Sorry, I don't get your conclusion. Is my patch (winetest: move to resources) acceptable or not? See the README to get a quick impression. -- Feri.
participants (4)
-
Dimitrie O. Paun -
Ferenc Wagner -
Kevin Koltzau -
Paul Millar