Kenneth Boyd <zaimoni at zaimoni.com> writes:>>> I've been thinking of constructing a mirror test suite coordinated >>> using shell scripts (bash) >> >> Please no, pick a real language. I love bash and it is fine for any >> 200 line or less program, but for much beyond that, something else. >> Python?c? C++? >> > If I thought C was an appropriate choice to get this done, I'd be > patching the expect source code instead to deal with Microsoft's > non-implementation of POSIX. > > If a language conceals the differences between POSIX and Microsoftian C > for interprocess control, hides badly non-POSIX filepaths from me, and > has a reasonable track record of forward compatibility, and has a > reasonably universal build process, I'll consider crash-learning the > language if I'm not already working in it.For my test suite I use Tcl (with TclX, no Expect). It watches stdout and stderr, gets exit codes and has a timer for killing hanged processes. Process control works the same on Windows and Unix and takes a less than 30 lines of code. What else do you need? -- Oscar
Óscar Fuentes wrote:> For my test suite I use Tcl (with TclX, no Expect). It watches stdout > and stderr, gets exit codes and has a timer for killing hanged > processes. Process control works the same on Windows and Unix and takes > a less than 30 lines of code. > > What else do you need? >Testing historical forward compatibility will be routine, as well. Kenneth
On Friday 01 August 2008 00:22, Óscar Fuentes wrote:> Kenneth Boyd <zaimoni at zaimoni.com> writes: > >>> I've been thinking of constructing a mirror test suite coordinated > >>> using shell scripts (bash) > >> > >> Please no, pick a real language. I love bash and it is fine for any > >> 200 line or less program, but for much beyond that, something else. > >> Python?c? C++? > > > > If I thought C was an appropriate choice to get this done, I'd be > > patching the expect source code instead to deal with Microsoft's > > non-implementation of POSIX. > > > > If a language conceals the differences between POSIX and Microsoftian C > > for interprocess control, hides badly non-POSIX filepaths from me, and > > has a reasonable track record of forward compatibility, and has a > > reasonably universal build process, I'll consider crash-learning the > > language if I'm not already working in it. > > For my test suite I use Tcl (with TclX, no Expect). It watches stdout > and stderr, gets exit codes and has a timer for killing hanged > processes. Process control works the same on Windows and Unix and takes > a less than 30 lines of code. > > What else do you need?A way to examine asm output and compate to expected patterns. A way to run performance regression tests (i.e. looking at CPU time and allowing for fuzz between test runs). In my experience Tcl is very hard to work with due to the non-existence of any reasonable debugging tools on all platforms. -Dave
David Greene <dag at cray.com> writes:>> For my test suite I use Tcl (with TclX, no Expect). It watches stdout >> and stderr, gets exit codes and has a timer for killing hanged >> processes. Process control works the same on Windows and Unix and takes >> a less than 30 lines of code. >> >> What else do you need? > > A way to examine asm output and compate to expected patterns.This is a text manipulation task, isn't it? No problem.> A way to run performance regression tests (i.e. looking at CPU time > and allowing for fuzz between test runs).Do you mean that you want a language with that feature built-in?> In my experience Tcl is very hard to work with due to the > non-existence of any reasonable debugging tools on all platforms.For one reason or another, my Tcl code never grows so large that I miss a debugger. A `puts' here and there plus the repl is enough :-) -- Oscar
David Greene wrote:> On Friday 01 August 2008 00:22, Óscar Fuentes wrote: > >> Kenneth Boyd <zaimoni at zaimoni.com> writes: >> >>>>> I've been thinking of constructing a mirror test suite coordinated >>>>> using shell scripts (bash) >>>>> >>>> Please no, pick a real language. I love bash and it is fine for any >>>> 200 line or less program, but for much beyond that, something else. >>>> Python?c? C++? >>>> >>> If I thought C was an appropriate choice to get this done, I'd be >>> patching the expect source code instead to deal with Microsoft's >>> non-implementation of POSIX. >>> >>> If a language conceals the differences between POSIX and Microsoftian C >>> for interprocess control, hides badly non-POSIX filepaths from me, and >>> has a reasonable track record of forward compatibility, and has a >>> reasonably universal build process, I'll consider crash-learning the >>> language if I'm not already working in it. >>> >> For my test suite I use Tcl (with TclX, no Expect). It watches stdout >> and stderr, gets exit codes and has a timer for killing hanged >> processes. Process control works the same on Windows and Unix and takes >> a less than 30 lines of code. >> >> What else do you need? >> > > .... > > In my experience Tcl is very hard to work with due to the non-existence of > any reasonable debugging tools on all platforms. >That is as much a matter of preferred techniques as anything. For any given language, not having debugging tools on any platform doesn't bother me exactly as long as I can enact design-by-contract. What I haven't seen yet in any language (but think would be easier to add to CLang than GCC; I'm not familiar enough with the other open-source competition to say), is reliably intercepting undefined behavior at compile-time. This pretty much requires whole-program analysis. Kenneth