我们比较忙，我和@vlachoudis
我知道你的 PR #1561，但最近没有检查开发的进展情况……我会尽快合并它，我会审查对公共文件所做的修改（幸运的是，这只是 PR 的一小部分）。

谢谢托马斯。

我知道我们都很忙，我知道你和@vlachoudis和其他一些人一起为这个项目做过。
看来我们很想念开发人员。
也许激励他们的一个好方法是根据@GitHubCaps在#1514中。
也许一个好的方法也是为预期的功能提供一个明确的时间表。

不管怎样，谢谢你所有的作品，祝 皮埃尔
一切顺利

我认为现在最大的任务是解决这个问题：
#591

我们需要克服 Tkinter 造成的限制。我认为我现在无法处理对不同 GUI 工具包的完全重写。但我们可能会尝试慢慢实现一些基于 OpenGL 的编辑器。一旦我们设法将它们集成到 TKinter 中，Glumpy（或 Vispy）似乎是合理的。我认为这对于 bCNC 的进一步生存绝对至关重要，因为 3D 视图/编辑器现在非常慢且丑陋。我们可以创建很棒的插件和新功能，但由于缺少可用的 g 代码预览窗口，我们无法以现代和清晰的方式展示它们的结果。

是的，我会在有空的时候看一看。老实说，自从我上次提交以来，我还没有重新打开代码。
但我并不是在专门谈论“我的”自己的 PR。但是
一般的代码和所有人的贡献。

编辑：是的，同意您在我输入此评论时的最后评论。

同意#591，但我不想干扰你的作品。
顺便说一句，您如何看待将低级库（如 bmath.py 和 bmath.py）重写为 C/C++ 动态库的想法，这些库将通过包装器调用以提高经常调用的核心函数的速度。
为了防止这些回归，我们可以编写单元测试？
不 ？

同意#591，但我不想干扰你的作品。

没有真正的工作，只有想法和用微型 python 脚本进行的实验。真的没想到什么。

顺便说一句，您如何看待将低级库（如 bmath.py 和 bmath.py）重写为 C/C++ 动态库的想法，这些库将通过包装器调用以提高经常调用的核心函数的速度。

bCNC 最慢的部分是 3D 画布/编辑器。它慢了几个数量级，我认为其余的速度没有大问题。

使用 numpy/scipy 可以更快地进行一些计算。（这就是 2D STL 切片器的作用）

用一些现成的库替换 bpath 可能也是有意义的。实际上有一些图书馆在某种程度上实现了类似的目标。当我为 SVG 导入编写代码时，我注意到一些 SVG 库具有与我们的 bpath.py 相似的功能，我相信它是 svgpath，但不确定。当然，有些库能够处理我们 95% 的用例。从头开始写这个是愚蠢的。我们可以在现有库周围使用包装器，甚至可以将需要的功能发送到此类库的上游代码库。这些库通常经过很好的回归测试，并由学术数学家正式验证（与 bpath 不同）。

但我认为当我们未能将其功能包装在合理的 GUI 中时，拥有完美的 bCNC 核心并没有真正的意义。

此外，当我们将核心换成一些用 C 编写的优化几何库后端并将前端换成一些 OpenGL 加速画布时，我们将不再有“bCNC”，因为后端和前端都将被替换:-)

顺便说一句，FreeCAD 中有一些3D CAM 功能。我认为从长远来看它可能会取代 bCNC。
FreeCAD 是用 python 编写的（使用 C 样板），其核心具有最先进的 3D 几何库。性能良好的 3D 查看器/编辑器。添加 python 插件的可能性。

他们的 CAM 工作流程目前相当奇怪，太复杂了，我从来没能用它完成任何有用的事情，但有些人知道如何使用它。但是一旦他们将简化他们的 CAM（“工具路径工作台”）以更加用户友好，我认为它将成为这个街区中最酷的孩子。

FreeCAD 可以完成很多事情，但也相当大，需要大量资源，需要整晚在我的旧 Thinkpad 上编译。
bCNC 将留在这里供喜欢简约解决方案的人使用。