Re: We *really* need a development model change !
At 04:44 PM 08/01/2002 -0500, you wrote: <snip>
(Another Pythoner, cool :) )
This has given me an idea - while I don't expect it to be used in Wine, I will try to write my own test progs with it : use the *windows* python interpreter under Wine.
From the doc, it's possible to call any win32 api from it using a 'calldll' interface. If it works well, I won't need a 'test framework' - just use the standard, available tool.
Gerard
On Tue, 8 Jan 2002, Gerard Patel wrote:
This has given me an idea - while I don't expect it to be used in Wine, I will try to write my own test progs with it : use the *windows* python interpreter under Wine.
From the doc, it's possible to call any win32 api from it using a 'calldll' interface. If it works well, I won't need a 'test framework' - just use the standard, available tool.
And that's a very cool idea. In fact, we don't need a test harness. What we need is to say: 'A test is an executable. The exit status is 0 on success, and non-zero on error. If the test fails, it should explain why on stderr. Verbose output (if any) goes on stdout.' Now, from the POV of Wine, we don't care (just like the kernel), if the executable is a native binary or a #! executable. Everything else are a few Makefile rules, which are conditional on the given compiler/interpreter being available (which can be checked quite easily by configure). -- Dimi.
On Tue, 8 Jan 2002, Dimitrie O. Paun wrote: [...]
Now, from the POV of Wine, we don't care (just like the kernel), if the executable is a native binary or a #! executable. Everything else are a few Makefile rules, which are conditional on the given compiler/interpreter being available (which can be checked quite easily by configure).
That's true on Unix because sh, perl, and C executables will just work. But if some of your tests are sh scripts you will have trouble running them on Windows. We probably won't often need to run all the tests in Windows, but I can imagine that it would still be necessary to check behavior on different setups: in 16bpp vs. 32bpp, in the english vs. the russian vs. chinese version, with IE 5 installed or not installed, etc. So we need a framework that makes it easy to run all the tests on Windows. Since sh scripts tend to invoke a ton of Unix tools like expr, awk, sed, perl, this seems not to be a good basis for writing tests. But I agree with the approach: a test is an executable that returns 0 if successfull and non-zero if not. It's pretty much the foundation of my proposal except that all tests should either be of the same type: perl or C (or whatever). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.
On Wed, 9 Jan 2002, Francois Gouget wrote:
That's true on Unix because sh, perl, and C executables will just work. But if some of your tests are sh scripts you will have trouble running them on Windows.
Yes, but nobody really proposes writing tests in Bourne-shell. In fact, you can't easily do it wether you run under Unix or Windows. What I was saying is that the execution engine should not really matter, generally speaking. In practice, there are only 3 choices: 1. Native executable (most likely C based) 2. Perl script 3. Python script In all this cases we can package things such that the *exact* same tests run under both Wine & Windows. In all this cases, it is possible to make it trivial for the tester to run the tests, without them knowing what language has been used to write the actual tests.
We probably won't often need to run all the tests in Windows, but I can imagine that it would still be necessary to check behavior on different setups: in 16bpp vs. 32bpp, in the english vs. the russian vs. chinese version, with IE 5 installed or not installed, etc. So we need a framework that makes it easy to run all the tests on Windows. Since sh scripts tend to invoke a ton of Unix tools like expr, awk, sed, perl, this seems not to be a good basis for writing tests.
Again, you will not be able to easily invoke Win32 APIs from sh anyway, so this is not really an option. -- Dimi.
--- Gerard Patel <gerard.patel(a)nerim.net> wrote:
At 04:44 PM 08/01/2002 -0500, you wrote:
<snip>
(Another Pythoner, cool :) )
This has given me an idea - while I don't expect it to be used in Wine, I will try to write my own test progs with it : use the *windows* python interpreter under Wine. From the doc, it's possible to call any win32 api from it using a 'calldll' interface. If it works well, I won't need a 'test framework' - just use the standard, available tool.
Could you, please, port my or Alexandre's Perl samples to Python, so we'll be able to easy compare them? It will be interesting to see differences. There is no big difference between Perl and Python for this application. IMHO they have the same problems: a) you have no C compiler support. We need to define manually constants, types of parameters, returning values, sizes of structures, etc. Even with C I saw on this list discussions about correct sizes of the structures, leave alone scripting languages. b) developer skills. C the most familiar language to those who knows/learns Win32. About my backround - I know Perl pretty well, know and like Python too. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
participants (4)
-
Andriy Palamarchuk -
Dimitrie O. Paun -
Francois Gouget -
Gerard Patel