On 4 August 2017 at 00:23, Mike Stump <mikest...@comcast.net> wrote:
> On Jul 27, 2017, at 2:07 AM, Pierre-Marie de Rodat <dero...@adacore.com> 
> wrote:
>> On 07/27/2017 09:52 AM, Richard Biener wrote:
>>>> I'm fine with the direction if a reviewer wants to go in that
>>>> direction.  I wish python didn't have a built-in speed penalty,
>>>> that's the only downside I don't like about it.  Aside from that,
>>>> even switching all of the testsuite to be python based isn't a
>>>> terrible idea.
>>> But is it worse than TCL?
> python is likely 2x faster than tcl, if you have one instance per testsuite 
> run.  The problem is, for the work required, it's cheaper to do the work once 
> to cut over to a new language.  I'd rather switch to some other language that 
> can come closer to the speed of compiled C code, yet in the scripting family. 
>  I don't have a pointer to a better solution than python at this time.  I'd 
> not be opposed to switching to python, it should be faster, just as safe, a 
> bit easier for new people to code in, and more people who know it and use it. 
>  I think python is funner to code in than tcl.  Cutting the entire testsuite 
> over at once, might well be more than any one person can contribute, but, we 
> could cut over subtrees, as people donate time; if people want to go in that 
> direction.  This can't be a 1 person decision, but rather a consensus 
> building type decision.  What do others think?

Sounds good to me.  Having recently done quite a bit of writing in tcl
for the D testsuite recently, there are certainly many gotchas that I
ran into.  Not sure whether you would rather take an existing testing
framework, or write one internally, but I can imagine something that
makes heavy use of python decorators for the simple cases.

Reply via email to