add stub test script #49
Conversation
There was a problem hiding this comment.
The script looks good, There could be refactoring to make it more readable but I don't think that's worth doing at a file this size. It's perfectly understandable even for a noob like me.
I think the thing you could improve is to make this multi threaded. I don't know how multi threading works in python, but if it's anything like Rust it should be easy to partition the clashes in thread_count places and then run the check_stubgen command for each lang in each thread with their own subsample of clashes. That should also avoid having all the "expensive" languages in one slow thread.
scripts/teststub.py
Outdated
| if n is not None: | ||
| clash_ids = random.sample(clash_ids, n) | ||
|
|
||
| GCC_CMD = ["gcc", "-fsyntax-only", "-x", "c", "-"] |
There was a problem hiding this comment.
This could probably be a map of arrays? If every language has a single command.
There was a problem hiding this comment.
That's a great idea, I put the languages into a dict so it's easy to comment out or add languages
|
Is this something intended to be run for every language where we support a template? I just vaguely recall using it only for C and I'm surprised to see that loop over three languages. How fast it fares for both of three if you happen to remember? |
Nah it doesn't need to support every language, just the ones that are easy to check. I skipped interpreted languages for now because I don't really want to actually run the code. Maybe there's some static tooling that could help with those? The more we can test the better.
I've just left it running in the background for a while so I don't know how long it took exactly, but with these 3 languages it does about 5 clashes per second so that should be around 10 minutes for all 2776 clashes. I don't expect it to be ran very often so I'm not too worried about the speed. |
No description provided.