简化研究人员的算法测试。
我所在的团队负责大量的研究开发和完整的运输代码。
我一半时间开发在实时系统上运行的流程（介于软实时和硬实时、中实时之间？），
另一半时间我为不一定关心的研究人员编写或优化流程关于代码。
目前我正在开发一个流程，我必须将其分成两个不同的分支。
有一个针对一组的研究版本，以及一个生产版本，偶尔需要与研究代码合并才能将最新和最好的代码投入生产。
要测试这些流程，您需要设置一个半复杂的测试环境，它将在正确的时间（实时系统）将我们分析的数据发送到流程。
我正在考虑如何让
- 进行：想法、
- 实施、
- 测试、
- 转到 #1
我的同事尽可能简单、快速、无痛地
循环。 我的一个想法是在这些长时间运行的进程中嵌入一种脚本语言。 因此，随着流程的运行，他们可以调整实际的算法和算法。 是参数。
我立即查看了嵌入：
这些看起来都是可行的，并且实际上可能完全解决给定的问题。
还有其他好主意吗？
更改 1-2 行后重新编译、重新部署到测试环境并重新启动简直太糟糕了。
这个系统相当复杂，希望我能很好地解释它。
I work in a group that does a large mix of research development and full shipping code.
Half the time I develop processes that run on our real time system ( somewhere between soft real-time & hard real-time, medium real-time? )
The other half I write or optimize processes for our researchers who don't necessarily care about the code at all.
Currently I'm working on a process which I have to fork into two different branches.
There is a research version for one group, and a production version that will need to occasionally be merged with the research code to get the latest and greatest into production.
To test these processes you need to setup a semi complicated testing environment that will send the data we analyze to the process at the correct time (real time system).
I was thinking about how I could make the:
- Idea
- Implement
- Test
- GOTO #1
Cycle as easy, fast and pain free as possible for my colleagues.
One Idea I had was to embed a scripting language inside these long running processes.
So as the process run's they could tweak the actual algorithm & it's parameters.
Off the bat I looked at embedding:
These both seem doable and might actually fully solve the given problem.
Any other bright idea's out there?
Recompiling after a 1-2 line change, redeploying to the test environment and restarting just sucks.
The system is fairly complicated and hopefully I explained it half decently.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
听起来您需要的是 CruiseControl 或类似的东西； 每次您触及基线代码时，它都会重建并重新运行测试。
It kind of sounds like what you need is CruiseControl or something similar; every time hyou touch the baseline code, it rebuilds and reruns tests.
不确定我理解你的系统，但如果构建和部署太复杂，也许你可以自动化它？ 如果部署完全自动化，就能解决问题吗？
我不明白脚本语言如何解决这个问题？ 如果你改变你的算法，你仍然需要从头开始计算，不是吗？
Not sure I understand your system, but if the build and deployment is too complicated, maybe you could automate it? If deployment is completely automatic, would that solve the problem?
I don't understand how a scripting language would solve the problem? If you change your algorithm, you still need to restart calculation from the beginning, don't you?
嵌入Lua比嵌入Python容易得多。
Lua从一开始就是为了嵌入而设计的； Python 的嵌入性是事后嫁接的。
Lua 比 Python 大约小 20 倍，也更简单。
您没有过多介绍您的构建过程，但是通过使用真正强大的 make 版本可以显着简化构建和测试。 我使用 Andrew Hume 的 mk，但您最好花时间掌握 Glenn Fowler 的nmake，它可以动态添加依赖项并消除需要用于单独的配置步骤。 我通常不推荐 nmake，因为它有点复杂，但很明显，Fowler 和他的团队已经在 nmake 中构建了解决很多扩展和可移植性问题的解决方案。 对于您的特定情况，可能值得付出努力来掌握它。
Embedding Lua is much easier than embedding Python.
Lua was designed from the start to be embedded; Python's embeddability was grafted on after the fact.
Lua is about 20x smaller and simpler than Python.
You don't say much about your build process, but building and testing can be simplified significantly by using a really powerful version of make. I use Andrew Hume's mk, but you would probably be even better off investing the time to master Glenn Fowler's nmake, which can add dependencies on the fly and eliminate the need for a separate configuration step. I don't ordinarily recommend nmake because it is somewhat complicated, but it is very clear that Fowler and his group have built into nmake solutions for lots of scaling and portability problems. For your particular situation, it may be worth the effort to master it.
如果您可以通过脚本更改足够多的程序以使其有用，而无需完全重新编译，也许您应该考虑将系统分成更小的部分。 您可以有一个处理数据加载等的“服务器”，然后是执行实际处理的客户端代码。 每次系统加载新数据时，它都会检查客户端代码是否已重新编译，如果是则使用它。
我认为这里有几个优点，其中最大的优点是整个系统的复杂性要低得多。 现在您使用一种语言而不是两种语言工作。 当人们从 python 或 lua 模式转向 C++ 模式时，把事情搞砸的可能性较小。 通过在系统中嵌入一些其他语言，您还面临着依赖它的风险。 如果您使用 python 或 lua 来调整程序，那么这些语言要么在部署时成为依赖项，要么您需要将内容退回到 C++。 如果您选择将内容移植到 C++，则在切换过程中还有可能出现错误。
If you can change enough of the program through a script to be useful, without a full recompile, maybe you should think about breaking the system up into smaller parts. You could have a "server" that handles data loading etc and then the client code that does the actual processing. Each time the system loads new data, it could check and see if the client code has been re-compiled and then use it if that's the case.
I think there would be a couple of advantages here, the largest of which would be that the whole system would be much less complex. Now you're working in one language instead of two. There is less of a chance that people can mess things up when moving from python or lua mode to c++ mode in their heads. By embedding some other language in the system you also run the risk of becoming dependent on it. If you use python or lua to tweek the program, those languages either become a dependency when it becomes time to deploy, or you need to back things out to C++. If you choose to port things to C++ theres another chance for bugs to crop up during the switch.