Simplification of algorithm testing for researchers.
I work in a group that does a great combination of research and complete delivery code.
Half the time I develop processes that run on our real-time system (somewhere between soft real-time and hard real-time, medium real-time?)
In the other half, I write or optimize processes for our researchers who don't care about code at all.
I am currently working on a process that I have to develop on two different branches.
There is a research version for one group and a production version that sometimes needs to be combined with research code to get the latest and greatest in production.
To test these processes, you need to set up a semi-simple test environment that will send the data that we analyze at the correct time (real time system).
I was thinking about how I can do:
- Idea
- Execute
- Test
- GOTO # 1
Cycle as fast, fast, and painful as possible for my colleagues.
One idea I had was to embed a scripting language into these lengthy processes. Thus, like the process, they can tweak the actual algorithm and its parameters.
From the bat I looked at the attachment:
Both seem to be doable and can actually solve the problem entirely.
Any other bright idea?
Re-compiling after changing line 1-2, redeploying to a test environment and restarting just sucks.
The system is quite complex and I hope I have explained it halfway well.
a source to share
If you can modify enough of the program in a script to be useful without a complete recompilation, you might want to consider breaking the system down into smaller pieces. You can have a "server" that handles loading data, etc., and then client code that does the actual processing. Every time the system loads new data, it can check and check if the client code has been recompiled, and then use it in that case.
I think there will be several advantages here, the biggest of which would be that the whole system would be much less complex. Now you are working in one language instead of two. There is less chance people can mess things up by going from python or lua mode to C ++ mode in their heads. By embedding any other language in the system, you also risk becoming dependent on it. If you're using python or lua to tweek a program, those languages either become dependent when it's time to deploy, or you need to go back to C ++. If you choose to port things to C ++, there is another chance of errors occurring during the switch.
a source to share
Embedding Lua is much easier than embedding Python.
-
Lua was designed from the beginning to be embedded; Python embedding was grafted after the fact.
-
Lua is about 20 times smaller and simpler than Python.
You don't say much about your build process, but building and testing can be greatly simplified using a really powerful version of make. I'm using Andrew Hume mk , but you'd probably be even better off investing the time to master Glenn Fowler nmake , which can add dependencies on the fly and eliminate the need for a separate configuration step. I generally don't recommend nmake because it is somewhat complicated, but it is very clear that Fowler and his team have built in nmake solutions to address many of the scaling and portability issues. For your particular situation, it might be worth the effort to deal with it.
a source to share
Not sure if I understand your system, but if the build and deployment is too complex, perhaps you can automate it? If the deployment is fully automatic, does that solve the problem?
I don't understand how a scripting language will solve the problem? If you change your algorithm, you still need to restart the computation from the beginning, right?
a source to share
It looks like you need CruiseControl or something similar; every time hyou touches the underlying code, it rebuilds and reruns the tests.
a source to share