不同的Rebol 3分支之间有什么区别,特别是对于新的REN分支?
是否是他们运行的平台,功能集,代码组织,C标准合规性?
答案 0 :(得分:11)
这是一个注定要过时的答案,因此设置为Community Wiki。此信息为 2015年9月。因此,如果在一段时间后更新此答案,请同时修改日期。
最后一次构建是2011年3月5日,并且是开源版本的预定日期。
没有GUI支持,没有HTTPS支持,没有串口支持,没有UDP支持,没有智能控制台......
没有64位版本。二进制文件适用于Windows x86,OS / X(PPC或x86),Linux(x86或PPC),FreeBSD x86。
虽然Rebol2二进制文件已归档for many "esoteric" systems (BeOS,AIX,Windows DEC Alpha,QNX,Solaris ...)但未为Rebol3提供类似的二进制文件。唯一的#34;怪异的" build适用于Amiga,只有OS4 PowerPC Amiga。没有成功为Amiga模拟器构建Rebol3。
rebol.com二进制下载未作为此版本的一部分重建。但是,一个社区成员(@earl here on SO)created a build farm at rebolsource.net,只要它更新就会跟随这个GitHub主人。鉴于GitHub的rebol / rebol大师自2014年3月以来一直没有更新,这种活力目前尚未得到充分利用。
在发布时构建源代码在2011年5月5日的版本中获得了可执行程序无法区分(?)的可执行文件。这表明除了一些清理和Apache许可编辑以及准备发布之外,对源代码的更改很少。
小补丁和错误修正是偶尔整合的,大多数PR都处于空闲状态。写作时接受的最后公关是Mar 3, 2014,这是一年多以前的事。
最引人注目的"打破"获得批准的公关是repurpose the FUNCTION name。人们认为有必要打破old arity 3 form让这个词作为本地人收集FUNCT更有用的实施。 (这也带来了Rebol in alignment with Red,其FUNCTION是arity 2并且行为类似。) FUNCT原样保留在遗留代码中。
最重要的非破坏性 PR可能是not requiring blocks around IF, UNLESS, or EITHER bodies。这一点在那些知道它的人中得到了很好的接受,因为它符合该语言的自由形式和非样板哲学。它允许一些代码结构变得更漂亮"并为程序员提供了更多选择,而它似乎不会引起任何问题。它确实不如if [condition] [...]
那么快,但实际上几乎没有人知道这个功能被添加了,所以它一定不能咬人。 (如果有人可以在Red处弯腰以确保它获得IF和IF / ONLY那么这将是理想的。)
RETURN/REDO was removed。理由是它允许函数to effectively behave with variable arity,并且这是不必要的,并且由于不再能够根据其规范预测函数的特性而使其变得不那么重要。也许这个立场值得再看一下......因为正在向Lisp风格的宏添加压力的Lisp用户似乎并不担心这一点。 (这里在StackExchange中,这引发了一个Programmers.SE问题Would Rebol (or Red) benefit from Lisp-style Macros?,它还没有得到很多答案。)
在开源Rebol之前,Saphirion AG与Rebol技术有着特殊的关系。他们可以访问源代码,并负责Rebol3 GUI功能的大部分开发工作。他们还添加了其他一些内容,如HTTPS。
Saphir可从其网站获得a binary download,但仅适用于32位Windows。 Saphirion曾一度an experimental .APK for Android。
开源后的一些(但不是全部)Saphir's source was released。值得注意的遗漏是android构建和encapping的一些Rebol3代码......一种将压缩脚本和资源注入解释器二进制文件的方法,无需重新编译。
(注意:在Apache2许可下,不需要发布源代码的源代码。)
随着GitHub rebol / rebol在集成上被阻止,rebolsource / r3的一个分支被建立为一个"社区构建"哪些工作可以上演。
Rebolsource的变化是保守的,似乎旨在展示GitHub的rebol / rebol如何采取变革的过程"本着Rebol构思的精神和#34;应该将该存储库委派给社区。 (对于这种精神,see this。)因此,它集成了无争议的错误修正和调整,而不是用于实现HTTPS的大型第三方加密库。另外:除了C编译器之外,不允许添加构建依赖项(例如,没有GNU autotools)。
社区构建的二进制文件是根据需要为那些无法自己构建它们的人生成的。
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。
< / LI>除了具有Saphir的功能外,Atronix构建还添加了对带有/ INPUT,/ OUTPUT,/ ERROR的CALL的支持。它还添加了Foreign Function Interface,实现了LIBRARY!,ROUTINE!和STRUCT!用于与非Rebol动态库通信。它还在Windows和Linux上引入了支持。
Rebol&#34;宗教&#34;有时与权宜之计不一致,因此在需要时,手工编辑的makefile和Visual Studio项目会替换基于Rebol的构建过程。 FFI库引入了对GNU autotools的依赖来构建。
所有Atronix版本都包含GUI,因此没有&#34; Core&#34;建立。而且,只有Linux和Windows。
(偏见注意:这个分支是@HostileFork启动的,最了解的,并且会最热情地说。)
Ren-C最初是从Atronix的代码库中提取Core构建的。这给了它像HTTPS,增强的CALL和外部函数接口这样的功能,基本上是Rebolsource能够构建的所有平台。 更新2015年7月/ 9月 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
)而不是那些特定操作系统的特定大用户群而言更有趣!
从语言严谨性的角度来看,Ren / C正在推动现代技术的发展。虽然它仍然可以构建为C89,但它也可以构建为C99和C11。它已经被验证构建为C ++ 98到C ++ 14,并且在#ifdef __cplusplus
下进行了一些战略性修改,它可以利用现代C ++作为C代码上的一种静态分析工具。警告被引发,类型错误全部修正,并且#const; const correct&#34;。仔细考虑了必要的更改,使Rebol的基线C代码不仅更正确,而且cleaner and clearer source across the board。
从C开发人员的角度来看,Ren / C应该是稳定的,有条理的,并且对于任何知道C的人来说都要有足够的评论,以便自信地修改。并尝试新功能。这意味着能够实现definitionally scoped returns (实际编写但未推送),或尝试开发NewPath等功能。
从架构的角度来看,Ren / C的目的是根本没有可执行文件......但是要成为一个将Rebol解释器嵌入其他程序的库。它现在是Ren / C ++的基础,它旨在预测与Red合作。
从测试的角度来看,Ren / C打算将所有内容都打造成工程严谨和零容忍的形状。这意味着使用Address Sanitizer,Valgrind以及可以在两者上传递最高设置的测试套件,避免使用零填充内存等操作来模糊未初始化的内存访问。
虽然启用了所有额外的功能,但Ren / C的可执行文件几乎是Rebolsource的两倍,但是还没有进行任何审核以了解如何实现这一点下。已经确认存在Zlib和PNG编码/解码的重复副本 - 例如(包括Saphirion LodePNG,可能解决现有PNG中的错误,因为它比修复它更容易。 ..yet没有后来的代码)。此外,能够进行有选择地仅集成您想要使用的编解码器的构建还在议程上。
Ren / C目前有来自Atronix和Rebolsource的利益相关者参与其发展和方向,这增强了它可能演变为&#34;&#34; Rebol Core。它现在被作为代码支持Ren Garden链接,并且使用类似的方法,它可以被设置为Atronix的R3 / View ...然后Rebolsource使用的库......也许最终rebol / rebol本身。
(偏见注:此编辑由Oldes本人于2019年2月28日添加)
从社区分支分叉。主要关注的是保持代码接近原始卡尔的释放,而不是盲目地从Atronix / Saphirion那里拿走所有东西,但仍然试图慢慢地从这些分支中获取好东西。
不像 Ren-C ,这个版本不是试图引入新的语法,而是更接近原始的Rebol2和新的Red language