winetests.exe with tests from CVS 2003-09-26 can be found here:
http://vmlinux.org/~jakov/Wine/
(The bigger EXE size is due to tests generated from MSVC instead of MinGW.)
This winetests.exe should not pop up various error requesters any more, so if you click past any, please note it in the comment text box.
regards, Jakob
Jakob Eriksson jakob@vmlinux.org writes:
winetests.exe with tests from CVS 2003-09-26 can be found here:
http://vmlinux.org/~jakov/Wine/
This winetests.exe should not pop up various error requesters any more, so if you click past any, please note it in the comment text box.
Great, it looks really good. Since no test failed (MSVC build rulez), I could not exercise that new functionality, though. What would be the output if a test crashed, did not start or timed out? You could simply add some text at the end of the output which explains what happened exactly, and this would not require any changes to the parser. Also, the Tester= field should be given slightly more emphasis, and the comment could be perhaps part of the report?
It also seems like one architectural change will be necessary: when you build a test suite, the names of the included tests, their source directories and CVS revision numbers should be written into a separate file, and copied straight onto the processing site. This is necessary for setting up links in the output, and probably not worth including in the package itself. Hope it is not a big problem.
Feri.
On Sat, Sep 27, 2003 at 02:29:48PM +0200, Ferenc Wagner wrote:
Jakob Eriksson jakob@vmlinux.org writes:
This winetests.exe should not pop up various error requesters any more, so if you click past any, please note it in the comment text box.
Great, it looks really good. Since no test failed (MSVC build rulez), I could not exercise that new functionality, though. What would be the output if a test crashed, did not start or timed out? You could simply add some text at the
Currently, if it crashes, I don't know what happens. Either the the entire program skips the test or the program dies altogether.
If it does not start, I don't remember what happens, but I think you can tell from the log somehow.
If it times out - well, I do not yet have any timeout functionality. Sorry.
end of the output which explains what happened exactly, and this would not require any changes to the parser. Also, the
Yes, will do when I solve the timeout issue.
Tester= field should be given slightly more emphasis, and
How can I add more emphasis to it? *sorry, I do not understand*
the comment could be perhaps part of the report?
Ahh.. ok, I'll fix that. I will probably fix it in a few days, unless current situation is OK: I made a temporary fix by putting the comment at the bottom of the report, but I guess you want it at the top.
(I will have to recompile the EXE to put it at top and I can not do it from here.)
It also seems like one architectural change will be necessary: when you build a test suite, the names of the included tests, their source directories and CVS revision numbers should be written into a separate file, and copied
Names... ok, these are known. Source directories? Ahh, that is harder. Could be done though, with some trickery.
CVS revision number? How do I even find that? I suppose you do not mean CVS "2003-09-26" but the specific version number for each test file "file.c ver 1.21".
straight onto the processing site. This is necessary for
And now I am lost again. What is the processing site? Do you want a second file generated apart from the mail sent to wine-tests-report? (If yes, where should this file be sent?)
If you give a specification, as exact as possible, I can probably create the file.
setting up links in the output, and probably not worth including in the package itself. Hope it is not a big problem.
Probably not, once I understand exactly what you want. :-)
Jakob Eriksson jakob@vmlinux.org writes:
On Sat, Sep 27, 2003 at 02:29:48PM +0200, Ferenc Wagner wrote:
Tester= field should be given slightly more emphasis, and
How can I add more emphasis to it?
Sorry for my vague language, is reflects my vague thoughts.
Currently, it is amongst cryptic looking lines with a strong don't-touch-me feel. This is right, nobody should tinker with most of the output, which should probably be static for this reason. But let's not care about the submission form for now. What I mean is the tester name and contact address should be explicitly asked for (with a warning that it will appear on the Web, munge if you want). Like the comment.
the comment could be perhaps part of the report?
Ahh.. ok, I'll fix that. I will probably fix it in a few days, unless current situation is OK: I made a temporary fix by putting the comment at the bottom of the report, but I guess you want it at the top.
I do not care too much, but the top would be nicer, really. Close it with something distinctive.
It also seems like one architectural change will be necessary: when you build a test suite, the names of the included tests, their source directories and CVS revision numbers should be written into a separate file, and copied
Names... ok, these are known. Source directories? Ahh, that is harder. Could be done though, with some trickery.
Strange, the source directories were the first thing I determined when I built my test package. First of all, I could not collect the tests short of this...
CVS revision number? How do I even find that?
It is in the CVS directory, look at the Entries file.
straight onto the processing site. This is necessary for
And now I am lost again. What is the processing site?
WineHQ.org. See my response to Dimi.
Do you want a second file generated apart from the mail sent to wine-tests-report? (If yes, where should this file be sent?)
Yes, but this second file is generated when you build and publish the new tests binary, and sent straight to WineHQ, possible together with some other information, like build error logs.
If you give a specification, as exact as possible, I can probably create the file.
It should be something along
build unit directory (excuse if not built) test revision test revision [...]
unit directory (excuse if not built) test revision test revision [...]
etc. Maybe something more expandable, I am rather poor at designing file formats. But do not be too fast, Dimi opposes the whole idea, let's see what comes out at the end.
Feri.
-
Ferenc Wagner -
Jakob Eriksson