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.
