改进组件加载失败时的“halcmd loadusr”消息 #98

这仍然是实时拉取请求吗？我不清楚 cradek 的强制推动是做什么的。

force-push 归功于 cradek，因为这可以追溯到我们运行自己的 git 服务器时。据我所知，这个 PR 还是做了一些 master 没有做的事情。

我试图用这个来解决合并冲突，但它与05a37cf结合起来真的很乱

一晚上尝试的结果在这里：
https ://github.com/LinuxCNC/linuxcnc/tree/andypugh/jepler_98

只是为了好玩，我看了一下这个补丁。我没有尝试将最新的更改合并到 master 中，而是将它重新定位在 master 之上，最后得到了一个相当小的补丁，可以在https://github.com/petterreinholdtsen/linuxcnc/tree/halcmd-cplusplus中找到。这个改动还有意思吗？在代码中提供更好的错误消息和某种类型安全性似乎是一个有用的目标。

我想我担心在 HAL 的强制性部分中使用 C++ 存在阻力，但如果那真的是一个问题，我觉得它不再是了。感谢您对此进行现代化改造！

更改为 C++ 似乎只是一个小的改进。
我喜欢 HAL 只有 C。
我的 2 美分。

新错误消息 – 小改进。

试图避免“最佳语言”之战，但恕我直言：

如果我们可以在使用某种语言的良好特性代码或不具有良好特性之间做出选择——很可能会接受该代码。

但如果决定使用哪种代码，我们应该使用通用的 linuxcnc 代码（C、C++ 和 python）
，然后应该尽量保持最低的编程标准，但仍能获得所需的功能。

我们可以用 C 或 C++ 等编写所有linuxcnc，但项目可能会终止。
偶尔我听到有人抱怨 GUI 是用 python 编写的，速度很慢，这是事实。
但是如果你用 C++ 编写它们，那么（在这个项目中）只有几个人可以/愿意开发它们。正确的答案是在需要它的地方使用 C/C++，在其余部分使用 python/编译的 python，这样编程门槛就低了。

另一个是 TCL 编程，有几个人喜欢它，我们在 linuxcnc 中有相当多的代码。
但他们是唯一适用于该代码的人。如果我们不添加更多，我会更喜欢它，因为它会使维护问题变得更糟。

S0 HAL 是 John K 故意用 C 语言编写的，我想是因为他喜欢 C。C
是这种用途的一种很棒的语言。网上有很多示例/教程。使用它编写接口 Python 模块相对容易。HAL 是 linuxcnc 基础设施中非常重要的一部分，我们应该将编程门槛保持在较低水平，以便尽可能多的人能够理解并可能扩展它。

如果有一天我们认为 C 在很大程度上阻碍了 HAL 的发展，那就另当别论了。
尽管在这个项目中我们几乎从未计划过任何事情——它是有机增长的。

但后来我只是 linuxcnc 中的一个小轮子，主要是 GUI 代码，我只涉足 motion/HAL 代码，所以这只是我觉得很重要的个人观点。

谢谢

当 John K 写 HAL 时，C++ 还有些不成熟，我很高兴他当时没有使用它。但从那时起，C++ 已经取得了长足的进步。我是现代 C++ 的粉丝，我很高兴看到它在 LinuxCNC 中得到更多适当的使用。

也许这个拉取请求可以使用我的 rebased 补丁集或类似的 rebased 补丁集来更新以修复合并冲突，以使 master 分支的当前监护人更容易测试它？

我已经用由提供的版本强制更新了这个分支@petterreinholdtsen. 谢谢你。

我添加了一个修复在 64 位平台上运行的提交。