T3D Commitee: What needs to happen to get TS Optimizations in 4.0?

#1 It needs to be extensively tested under as many conditions as possible. The changes made by James aren't something that should just be merged in and hope for the best. Because there's a huge possibly it'll break horribly and then would effectively make the project and Committee look bad for accepting untested complicated code. It doesn't help that James himself even stated several times on IRC that he hasn't even thoroughly tested his own code.

#2

Quote:It needs to be extensively tested under as many conditions as possible.

This is not concise enough. We need hard acceptance criteria especially for something this crucial to the engine.

Is there some sort of language testing spec in computer science software development standards/theory? I have nothing to go on here. If there is something out there I will happily adapt it to thoroughly test the engine scripting and I would be happy to include that with the project.

Maybe later this week I will see how V8 does its own testing. I might be able to find something useful there. Also, I may need to develop some testing between the engine the C++ via the TS function macros. There could still be issues there.

#3 I guess it depends on what's likely to go wrong. A TS unit testing suite wouldn't be a bad idea - i.e. make a bunch of functions that exercise every feature of the language (and possibly builtin functions as well?), test them before and after and compare results.

EDIT: FRANK! MAKE YOUR PROTOTYPE! ;)

#4 Did someone say unit tests!?!? Ok, Melv did some extra work over a weekend to integrate unit testing into Torque 2D. He used the Google test lib. I feel horribly guilty, because I have not made the effort to write tests or encourage others to do so. However, it works great! I think I'm going to use what little spare time I have to create a few more unit tests for Torque 2D. I highly suggest it.

What we have in T2D is perfect for testing all the core systems on multiple platforms. After reviewing the code from James, I would definitely recommend adding a unit test system like what we have in T2D. For everything else, the T2D team uses our existing modules. We have a module for every basic feature, such as Sprites, CompositeSprites, several Box2D tests, and so on. If a pull request is accepted into our development branch, we go through each of our modules to see if they function as expected.

#5 @Michael,
It looks like there is some unit testing code in T3D, but it mainly tests the C++ side. I am not even sure how well it does that. Thanks for the heads up on the Google test lib. I will have to see how you are using it to get some ideas. If it would work for testing T3D maybe that can be a library shared between the engines.

#6 @Demolishun: I didn't reply to that other thread because it should've been evident from the issues mentioned throughout the thread what we would need resolved before merging those changes in. Dave and I both are adamant that neither of us merges any code that contains "known issues".

Have a little patience in the future. We've waited 6 months for the community to help test that branch -- only one person did so! So I feel that you can wait a few days for the committee to discuss the particulars at least once with the new members and then present a codified response.

#7

should've been evident from the issues mentioned throughout the thread

It was not evident as I don't know what was fixed versus what was mentioned in the thread. I did not want to make any assumptions as to what were "known issues".

Quote:Have a little patience in the future.

I can't read anybody's mind. It is hard to tell what people are doing in regard to an issue when there is no response. So a "let me get back to you on that" would be great in the future. I appreciate you letting me know you are working on it. That helps a lot.

In the meantime I have started looking at the unit test library called Google Test. It looks like it is quite a bit more sophisticated than the testing code already in T3D. I think it might be useful for testing TS code via callbacks. I am also looking into how other people test their code bases in C++, C, and scripting environments. So I don't think I have spun my wheels too much.

Again, thanks for letting me know you are coming up with some criteria for inclusion. I apologize if I jumped too quickly on looking for a response, but part of the reason was to let you know I wanted to work on this.

#8 To be clear: we are unaware of anyone who is currently working with that particular branch with the intentions of resolving the known issues or any others that may arise. If there has been no mention of a fix for an issue related to this, then there has been no fix -- there has certainly not been any fixes submitted.

If this is something you would like to be tasked with then we are more than happy to assign this task to you.

#9 @Michael,
Task me away on this. I want to make this happen before 4.0 if possible.

#10 "For those of you about to die in the inards of Torque - we salute you!"

I'll get the bodybag ready
;)