rebol - REBOL3-不同分支之间有什么区别？

Question

Rebol 3的不同分支（特别是新的REN分支）之间有什么区别？

它们将在其上运行的平台，功能集，代码组织，C标准合规性吗？

Answer 1

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

Binary download of Rebol3 from rebol.com


最新版本是2011年3月5日，并且早于开源版本。
没有GUI支持，没有HTTPS支持，没有串行端口支持，没有UDP支持，没有智能控制台...
没有64位版本。二进制文件适用于Windows x86，OS / X（PPC或x86），Linux（x86或PPC），FreeBSD x86。
当Rebol2二进制文件被存档为for many "esoteric" systems（Be​​OS，AIX，Windows DEC Alpha，QNX，Solaris ...）时，没有为Rebol3提供类似的二进制文件。唯一的“怪异”构建是针对Amiga的，而仅适用于OS4 PowerPC Amiga。没有成功的用于Amiga模拟器的Rebol3构建报告。


Open source release of Rebol3 on Github rebol/rebol


开源was on 12-Dec-2012。
rebol.com二进制下载未作为此发行版的一部分进行重建。但是，只要此GitHub主机更新，就会有一个社区成员（@earl在SO上为此处）created a build farm at rebolsource.net。考虑到自2014年3月以来GitHub的rebol / rebol master尚未更新，这种动力目前未得到充分利用。
在发布时生成源代码得到的可执行文件与2011年3月5日的版本在功能上没有区别（？）。这表明，除了进行一些清理和Apache许可编辑以准备发布之外，对源代码所做的更改很少。
次要补丁和错误修正被偶尔集成，大多数PR处于闲置状态。在撰写本文时，上一次接受的PR是Mar 3, 2014，它是一年多以前的。
确实获得批准的最引人注目的“破坏” PR是repurpose the FUNCTION name。人们认为有必要打破old arity 3 form来使用该词来作为更有效的本地实现功能，如FUNCT。 （这也带来了Rebol in alignment with Red，其功能为2，其功能类似。）FUNCT保留了原有代码的原样。
采取的最主要的不间断PR可能是not requiring blocks around IF, UNLESS, or EITHER bodies。这与该语言的自由形式和非模板式语言相吻合，在那些知道它的人中受到了好评。它允许某些代码构造变得“更漂亮”，并为程序员提供更多选择，而这似乎并没有引起更多的问题。它肯定比if [condition] [...]少了一个速度提升，实际上，似乎几乎没人知道添加了此功能，因此它一定不会对任何人造成伤害。 （如果有人可以在Red上弯腰以确保获得IF和IF / ON，那么那将是理想的选择。）
RETURN/REDO was removed。理由是它允许功能to effectively behave with variable arity，并且这是不必要的，并且由于不再能够从其规格中预测功能的重要性而使terra firma消失了。也许这种立场值得重新审视……因为迫切希望添加Lisp样式宏的Lisp用户似乎并不太担心。 （在StackExchange领域中，这引发了Programmers.SE问题Would Rebol (or Red) benefit from Lisp-style Macros?，但尚未获得太多答案。）


The fork by Saphirion: "Saphir"


在Rebol开源之前，Saphirion AG与Rebol技术有着特殊的关系。他们可以访问源代码，并负责Rebol3 GUI功能的大部分开发工作。他们还添加了其他一些东西，例如HTTPS。
Saphir在其网站上以a binary download的形式提供，但仅适用于32位Windows。有一次来自萨菲隆的an experimental .APK for Android。
开源后的某些（但不是全部）Saphir's source was released。明显的遗漏是android构建和encapping的一些Rebol3代码...一种将压缩的脚本和资源注入到解释器的二进制文件中而无需重新编译的方法。


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

"Community" Integration at Rebolsource on GitHub


随着GitHub rebol / rebol停止集成，在rebolsource / r3上建立了一个分支，作为可以进行工作的“社区构建”。
Rebolsource的更改是保守的，似乎旨在展示GitHub的rebol / rebol如何“按照Rebol的构想精神”采用更改的过程，如果该存储库委托给社区。 （出于这种精神，see this。）因此，它集成了无争议的错误修正和调整，而不是用于实现HTTPS的大型第三方加密库。另外：除了C编译器（例如，没有GNU自动工具）之外，不允许添加构建依赖项。
社区构建的二进制文件是按需要为那些无法自己构建的二进制文件提供的。


Atronix Engineering's Rebol "3.0" at Github zsx/r3


Atronix是使用Rebol的工业自动化解决方案提供商。 David den Haring, director of Engineering在此处的视频中描述了它们的操作方式，并且ZOE software是基于其Rebol版本构建的。
开源之后，Atronix与Saphirion合作将GUI移植到Linux。 Atronix在开发过程中会公开发布其资源，David den Haring在上面的视频中指出，他们只有一个开发的专有组件（工业控制驱动程序）。除此之外，他们乐于分享他们所做的所有Rebol开发的资源。
Atronix集成了Rebolsource的64位补丁程序，创建了Windows 64位目标，并为Windows和Linux x86 / x64以及Linux ARMv7提供了up-to-date binaries of their development branch。
除了具有Saphir的功能外，Atronix构建还通过/ INPUT，/ OUTPUT，/ ERROR添加了对CALL的支持。它还添加了Foreign Function Interface，实现LIBRARY！，ROUTINE !！和STRUCT！与非Rebol动态库进行通信。它还在Windows和Linux上引入了封装支持。
Rebol的“宗教”有时与权宜之计不符，因此在需要时，基于Rebol的构建过程被手动编辑的Makefile和Visual Studio项目所取代。 FFI库引入了对GNU自动工具的依赖。
所有Atronix构建都包括GUI，因此没有“ Core”构建。同样，只有Linux和Windows。


Ren-C

（Bias注意：此分叉是@HostileFork发起的倡议，最了解，并且会最热情地谈论。）


Ren-C最初是从Atronix的代码库中提取的Core构建的一部分。这为Rebolsource基本上能够构建的所有平台提供了HTTPS，增强的CALL和外部功能接口等功能。更新时间：2015年7月7日，Ren / C支持控制台中的行继续，用户中缀功能，多个错误修复...
Ren-C进行了大规模更改，并修复了R3-Alpha中的基本问题，这些问题tracked on a Trello可提供更多信息。有一个新的FAQ作为GitHub Wiki。诸如definitionally-scoped returns的关键问题已得到解决，并在其他悬而未决的问题上进行了不懈的努力。
尽管Atronix的R3 / View需要一些附加的依赖关系，但Ren / C退回到除了使用C编译器之外不能构建任何东西的方式，并消除了所有手工的makefile /项目。
除了32位和64位版本的Windows，Linux和Mac外，Ren / C均为built for smaller players like HaikuOS和yes, even Syllable。这对于演示C89代码的交钥匙构建的工作方式（简称为make -f makefile.boot）的广泛意义（而不是那些特定OS的特别庞大的用户群）更加有趣！
从严格的语言角度来看，Ren / C正在推动现代技术的发展。尽管它仍然可以像C89一样构建，但是也可以像C99和C11一样构建。它也已经过验证，可以通过C ++ 14构建为C ++ 98，并且在#ifdef __cplusplus下进行了一些战略性修改，可以利用现代C ++作为C代码上的一种静态分析工具。发出警告，修复所有类型的错误，并且它是“ const正确的”。仔细考虑了必要的更改，以使Rebol的基准C代码不仅更正确，而且cleaner and clearer source across the board。
从C开发人员的角度来看，Ren / C应该保持稳定，有条理，并给予足够的评论，以便任何认识C的人都可以“自信地进行修改”并尝试新功能。这意味着能够实现definitionally scoped returns（实际上已编写但未推送），或尝试开发NewPath之类的功能。
从体系结构的角度来看，Ren / C旨在完全不具有可执行文件……而是一个用于将Rebol解释器嵌入其他程序的库。现在，它是Ren / C ++的基础，Ren / C ++的目的是也可以预期与Red一起工作。
从测试的角度来看，Ren / C打算将所有东西都调整为形状，以达到工程严谨和零错误容忍的目的。这意味着要避免使用Address Sanitizer，Valgrind和可以通过这两个设置中的最高设置的测试套件来避免零填充内存来掩盖未初始化的内存访问等做法。
尽管启用了所有额外功能，Ren / C的可执行文件几乎是Rebolsource可执行文件大小的两倍，但尚未进行任何审核以查看如何减少该文件。已经确认存在Zlib和PNG编码/解码的重复副本-例如（Saphirion包含LodePNG，可能会解决现有PNG中的错误，因为它比修复它更容易...但还没有之前的代码）。同样，能够仅选择性地集成您要使用的编解码器的构建也已列入议程。
Ren / C当前有Atronix和Rebolsource的利益相关者参与其开发和发展方向，这增强了其发展成为“ the Rebol Core”的可能性。现在，它被链接为代码支持Ren Garden，并且可以使用类似的方法将其设置为Atronix R3 / View使用的库...然后是Rebolsource ...，甚至最终是rebol / rebol本身。


The fork by Oldes

（Bias注意：此编辑由Oldes本人添加于2019年2月28日）


从社区分支分支。主要侧重于保持代码接近原始Carl的发行版，而不会盲目地从Atronix / Saphirion那里获取所有内容，但仍要尝试从这些分支中缓慢地获取好的东西。
与Ren-C不同，此版本未尝试引入新语法，而是更接近原始Rebol2和新的Red language