Daniel Stenberg writes:
> 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?
There are certainly plans of building and testing the command line
client on Windows. Portability can be an issue if the selected
language does not run natively on a given platform. As far as I know
both Python and Perl run natively on Windows. I don't know about Mac.
> I have two minor (totally unrelated to the above) ideas for the test suite:
> 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.
I would like to see what Karl and Ben think about this. Offhand, it
sounds to me like you are really talking about functions internal to
the client to be called by a command line (--mem-debug or --mem-trace)
So part of the test suite I will be writing can certainly parse the
output log files of this debug mode. On the other hand, the actual
tracing functions need to be coded and included in the client itself,
not the test suite.
Am I understanding you correctly, Daniel?
> 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.
This is outside of the scope of the client test suite, I think. But I
don't want to discourage the idea.
> 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
Lee P. W. Burgess <<!>> Manipulate eternity. Power is a symphony:
Programmer <<!>> elaborate, enormous, essential.
Red Bean Software <<!>> Dream the moment with a fiddle in summer
email@example.com <<!>> and a knife in winter.
Received on Sat Oct 21 14:36:25 2006