On Wed, 7 Mar 2001, Lee Burgess wrote:
> Now, I have volunteered to take on the task of cleaning up the client
> test suite.
> The way I see it, I have two choices: Perl or Python. I am more fluent
> in Perl, but I like Python more. I would just as soon use Python, but I
> wanted to put it to the list before acting. So I am looking for
> *constructive* feedback regarding what other people think is the Right
> Tool For This Job.
Without being a bigot of either camp, I consider both languages quite capable
of the task. We've already heard both Perl and Python advocates speak up so I
don't think there's a lack of either kind here.
Is portability an issue? I mean, is there any plans of ever bringing this to
something like windows and is that then an issue when selecting language?
I have two minor (totally unrelated to the above) ideas for the test suite:
1.
I say we add some kind of very simple memory tracing functions. So when we
compile with some weirdo debug define, all malloc/free (and other resource
using functions) log their activity to a file. When the client is done, a
script analyzes the resource usage. This is neat in memory usage measuring,
but most of all it helps us track memory/resource leaks at a very early state
at a very low cost. We do make libraries that hopefully will be used by other
applications, we want them to be nice.
2.
An even more minor detail: we add a switch so that when running a single
test case, we can have the client (or server) run with gdb using the same
options the test case otherwise has (by generating a gdb command file that
sets command args). It makes it very conveniant when a test case
fails/crashes and you wanna rerun it with a debugger.
Just my thoughts.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Received on Sat Oct 21 14:36:25 2006