8

What are the differences between the different Rebol 3 branches, especially with the new REN branch?

Is it the platforms they'll run on, the feature set, code organization, the C standard compliance?

4

1 回答 1

13

这是一个注定会过时的答案，因此设置为Community Wiki。此信息截至2015 年 9 月。因此，如果在一段时间后更新此答案，请同时修改日期。

从 rebol.com 下载 Rebol3 的二进制文件

  • 最后一次构建是 2011 年 3 月 5 日，早于开源版本。

  • 不支持 GUI，不支持 HTTPS，不支持串口，不支持 UDP，不支持智能控制台……

  • 没有 64 位版本。二进制文件适用于 Windows x86、OS/X（PPC 或 x86）、Linux（x86 或 PPC）、FreeBSD x86。

  • 虽然 Rebol2 二进制文件是为许多“深奥”系统 （BeOS、AIX、Windows DEC Alpha、QNX、Solaris...）存档的，但没有为 Rebol3 提供类似的二进制文件。唯一“奇怪”的版本是针对 Amiga 的，而且只有 OS4 PowerPC Amiga。没有报告为 Amiga 仿真器成功构建 Rebol3。

Rebol3 在 Github rebol/rebol 上的开源版本

  • 开源是在 2012 年 12 月 12 日。

  • rebol.com 二进制下载未作为此版本的一部分进行重建。但是，社区成员（@earl here on SO）在 rebolsource.net 上创建了一个构建农场，该构建农场在更新时跟随此 GitHub 主服务器。鉴于 GitHub 的 rebol/rebol master 自 2014 年 3 月以来没有更新，这种活力目前未被充分利用。

  • 在发布时构建源代码的可执行文件与 2011 年 3 月 5 日的构建版本在功能上无法区分（？）。这表明除了一些清理和 Apache 许可编辑以准备发布之外，对源代码进行了很少的更改。

  • 零星地集成了小补丁和错误修复，大多数 PR 都处于闲置状态。在撰写本文时，最后一次接受 PR 是 2014 年3 月 3 日，那是一年多以前。

  • 获得批准的最引人注目的“破坏性”公关是重新利用 FUNCTION 名称。它被认为值得打破旧的 arity 3 形式，让这个词被认为是更有用的实现，如 locals-gathering FUNCT。 （这也使 Rebol与 Red 保持一致，它的 FUNCTION 是 arity 2 并且行为相似。） FUNCT 保持原样用于遗留代码。

  • 采取的最重要的非破坏性PR 可能不需要围绕 IF、UNLESS 或 EITHER 主体的块。这在那些知道它的人中很受欢迎，因为它符合该语言的自由形式和非样板哲学。它允许一些代码结构变得“更漂亮”并为程序员提供更多选择，而它似乎并没有比其他任何东西造成更多的问题。它肯定不是一个减速带if [condition] [...]，事实上似乎几乎没有人知道这个功能被添加了，所以它一定不会咬任何人。 （如果有人可以在 Red 上弯下耳朵以确保它得到 IF 和 IF/ONLY，那将是理想的。）

  • RETURN/REDO 被删除。基本原理是它允许函数有效地以可变的 arity 运行，而这是不必要的，并且由于不再能够从其规范中预测函数的 arity 而使 terrafirma 消失了。或许这种立场值得重新审视……因为向添加 Lisp 风格宏施加压力的 Lisp 用户似乎并不十分担心这一点。 （在 StackExchange 的世界中，这引发了 Programmers.SE 的一个问题，Rebol（或 Red）会从 Lisp 风格的宏中受益吗？目前还没有太多的答案。）

Saphirion的叉子：“Saphir”

  • 在 Rebol 开源之前，Saphirion AG与 Rebol 技术有着特殊的关系。他们可以访问源代码并负责 Rebol3 GUI 功能的大部分开发工作。他们还添加了其他一些东西，比如 HTTPS。

  • Saphir 可以从他们的网站下载二进制文件，但只提供给 32 位 Windows。Saphirion曾经有一个用于 Android 的实验性.APK。

  • Saphir 的一些（但不是全部）源代码是在开源之后发布的。值得注意的遗漏是 android 构建和一些用于封装的 Rebol3 代码......一种将压缩脚本和资源注入解释器的二进制文件而无需重新编译它的方法。

（注意：在 Apache2 许可下，不需要发布衍生作品的源代码。）

GitHub 上 Rebolsource 的“社区”集成

  • 随着 GitHub rebol/rebol 的集成被搁置，rebolsource/r3 的一个分支被建立为一个“社区构建”，可以在其中进行工作。

  • Rebolsource 的更改是保守的，似乎旨在展示 GitHub 的 rebol/rebol 可能如何“本着 Rebol 的构思精神”采用更改的过程，如果该存储库被委派给社区。 （对于这种精神，请参阅此内容。） 因此，它集成了无争议的错误修复和调整，而不是用于实现 HTTPS 的大型第三方密码库。另外：除了 C 编译器之外，不允许添加构建依赖项（例如，没有 GNU 自动工具）。

  • 用于社区构建的二进制文件是根据需要为那些无法自行构建的人制作的。

Atronix Engineering 在 Github zsx/r3 上的 Rebol “3.0”

  • Atronix是一家使用 Rebol 的工业自动化解决方案提供商。工程总监 David den Haring在此处的视频中描述了他们如何做到这一点，他们的ZOE 软件是基于他们的 Rebol 版本构建的。

  • 开源之后，Atronix 与 Saphirion 合作将 GUI 移植到 Linux。Atronix 在开发过程中公开发布他们的源代码，David den Haring 在上面的视频中指出，他们只有一个他们开发的专有组件（工业控制驱动程序）。除此之外，他们很乐意分享他们所做的所有 Rebol 开发的源代码。

  • Atronix 集成了来自 Rebolsource 的 64 位补丁，创建了一个 Windows 64 位目标，并为 Windows 和 Linux x86/x64 以及 Linux ARMv7提供其开发分支的最新二进制文件。

  • 除了具有 Saphir 的功能外，Atronix 版本还增加了对带有 /INPUT、/OUTPUT、/ERROR的CALL的支持。它还添加了一个外部函数接口，实现了 LIBRARY!、ROUTINE! 和结构！用于与非 Rebol 动态库进行通信。它在 Windows 和 Linux 上也带来了封装支持。

  • Rebol 的“信仰”有时与权宜之计不一致，因此基于 Rebol 的构建过程在需要时被手动编辑的 makefile 和 Visual Studio 项目所取代。FFI 库引入了对 GNU 自动工具的依赖来构建。

  • 所有 Atronix 构建都包含 GUI，因此没有“核心”构建。再说一次，只有 Linux 和 Windows。

任丙

（偏见说明：这个分叉是@HostileFork发起的倡议，最了解，并且会最热情地谈论。）

  • Ren-C 最初是从 Atronix 的代码库中提取的核心构建。这使其具有 HTTPS、增强的 CALL 和外部函数接口等功能，基本上适用于 Rebolsource 能够构建的所有平台。 更新 2015 年 7 月/9 月Ren/C 支持控制台中的行延续、用户中缀功能、几个错误修复......

  • Ren-C 在 R3-Alpha 中进行了大规模更改并修复了基本问题，这些问题在提供更多信息的 Trello 上进行了跟踪。有一个新的常见问题解答作为 GitHub wiki。定义范围的回报等关键问题已得到解决，并继续致力于解决其他悬而未决的问题。

  • 尽管 Atronix 的 R3/View 需要一些额外的依赖项，但 Ren/C 退回到能够仅使用 C 编译器构建，并消除了所有手工制作的 makefile/项目。

  • 除了 32 位和 64 位版本的 Windows、Linux 和 Mac 之外，Ren/C 还为像 HaikuOS和是的，甚至 Syllable等小型播放器而构建。这对于展示 C89 代码的交钥匙构建如何广泛地工作（简称为make -f makefile.boot）更有趣，而不是那些特定操作系统的特别大的用户群！

  • 从语言严谨性的角度来看，Ren/C 正在推动现代技术。虽然它仍然可以构建为 C89，但它也可以构建为 C99 和 C11。它也已被验证可以构建为 C++98 到 C++14，并且通过一些策略性修改，#ifdef __cplusplus它可以利用现代 C++ 作为一种 C 代码的静态分析工具。发出警告，类型错误全部修复，并且它是“const 正确的”。对必要的更改进行了仔细考虑，以使 Rebol 的基线 C 代码不仅更正确，而且更清晰、更清晰。

  • 从 C 开发人员的角度来看，Ren/C 应该是稳定的、有组织的、有足够的评论的，任何了解 C 的人都可以“放心地修改”并尝试新的特性。这意味着能够实现定义范围的返回 （实际上是编写的，但不是推送的），或者尝试开发像NewPath这样的功能。

  • 从架构的角度来看，Ren/C 的目的是根本没有可执行文件……而是作为一个库，用于将 Rebol 解释器嵌入到其他程序中。它现在是 Ren/C++ 的基础，旨在预测与 Red 的合作。

  • 从测试的角度来看，Ren/C 打算将所有东西都打造成形状，以实现工程严谨性和零错误容忍度。这意味着避免使用诸如零填充内存来掩盖未初始化的内存访问等做法，使用Address Sanitizer、Valgrind和可以通过两者的最高设置的测试套件。

  • 虽然启用所有额外功能使 Ren/C 的可执行文件大小几乎是 Rebolsource 的两倍，但目前还没有任何审计来了解如何降低这一点。已经确认存在 Zlib 和 PNG 编码/解码的重复副本——例如（Saphirion 包括LodePNG，可能会解决现有 PNG 中的一个错误，因为它比修复它更容易......但没有封存以前的代码）。此外，能够进行有选择地仅集成您想要使用的编解码器的构建已提上日程。

  • Ren/C 目前有来自 Atronix 和 Rebolsource 的利益相关者参与其开发和指导，这增强了它可能演变为“Rebol Core”的可能性。它现在被链接为支持Ren Garden的代码，并且使用类似的方法，它可以设置为 Atronix 的 R3/View 使用的库......然后是 Rebolsource......也许最终是 rebol/rebol 本身。

奥尔德斯的叉子

（偏见说明：此编辑由奥尔德斯本人于 2019 年 2 月 28 日添加）

  • 从社区分支分叉。主要关注保持代码接近原始 Carl 的版本，而不是盲目地从 Atronix/Saphirion 中获取所有内容，但仍然试图慢慢地从这些分支中获取好东西。

  • 不像Ren-C，这个版本不是试图引入新的语法，而是更接近原来的 Rebol2 和新的Red 语言

于 2015-07-20T13:13:57.580 回答