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>
>> 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.