REBOL3-不同分支之间有什么区别? [英] REBOL3 - what is the difference between the different branches?

问题描述

不同的Rebol 3分支(特别是新的REN分支)之间有什么区别?

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

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

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

推荐答案

这是注定要过时的答案，因此将其设置为

This is an answer destined to become outdated, hence set to Community Wiki. This information is as of Sep-2015. So if updating this answer after some time has passed, please modify the date as well.

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

• Last build was 5-Mar-2011 and pre-dates the open source release.

不支持GUI，不支持HTTPS，不支持串行端口，不支持UDP，不支持智能控制台...

No GUI support, no HTTPS support, no serial port support, no UDP support, no smart console...

没有64位版本.二进制文件适用于Windows x86，OS/X(PPC或x86)，Linux(x86或PPC)，FreeBSD x86.

No 64-bit builds. Binaries are for Windows x86, OS/X (PPC or x86), Linux (x86 or PPC), FreeBSD x86.

虽然Rebol2二进制文件已存档对于许多神秘"系统 (BeOS，AIX，Windows DEC Alpha，QNX，Solaris ...)没有为Rebol3提供类似的二进制文件.唯一的怪异"构建是针对Amiga的，而仅适用于OS4 PowerPC Amiga.尚无成功的用于Amiga模拟器的Rebol3构建报告.

While Rebol2 binaries are archived for many "esoteric" systems (BeOS, AIX, Windows DEC Alpha, QNX, Solaris...) similar binaries were not provided for Rebol3. The only "weird" build is for Amiga, and only an OS4 PowerPC Amiga. No successful builds of Rebol3 for Amiga emulators have been reported.

• 开放源代码于2012年12月12日.

rebol.com二进制下载未作为此发行版的一部分进行重建.但是，社区成员(@earl在SO上有此信息)在rebolsource.net 上创建了一个构建农场，该农场遵循了此GitHub大师.每当它更新.鉴于自2014年3月以来GitHub的rebol/rebol master尚未更新，这种动力目前未得到充分利用.

The rebol.com binary downloads were not rebuilt as part of this release. However, a community member (@earl here on SO) created a build farm at rebolsource.net that follows this GitHub master whenever it updates. Given that GitHub's rebol/rebol master hasn't been updated since March 2014, this dynamism is currently underused.

在发布时构建源代码得到的可执行文件与2011年3月5日的版本在功能上没有区别(?).这表明除了进行一些清理和Apache许可编辑以准备发布之外，对源代码所做的更改很少.

Building the source at time of release got an executable not distinguishable (?) in functionality from the builds on 5-Mar-2011. This suggests few changes to the source were made besides some cleanup and Apache-licensing edits to prepare for publication.

次要补丁和错误修正是偶尔集成的，大多数PR都处于闲置状态.撰写本文时接受的最后一个PR是 2014年3月3日以前.

Minor patches and bugfixes were integrated sporadically, with most PRs sitting idle. Last PR accepted at time of writing was Mar 3, 2014, which is over a year ago.

获得批准的最引人注目的破坏性"公关是改变功能的用途名称.认为值得破坏旧的arity 3形式被认为是更有用的实现，如本地人聚集FUNCT. (这也使Rebol 保持一致与Red (其功能为2且功能相似). FUNCT保留了原有代码的原样.

The most noticeable "breaking" PR that did get approved was to repurpose the FUNCTION name. It was considered to be worth breaking the old arity 3 form to let the word be taken for the much more useful implementation as locals-gathering FUNCT. (This also brought Rebol in alignment with Red, whose FUNCTION is arity 2 and acts similarly.) FUNCT was kept around as-is for legacy code.

所采取的最主要的不间断公关可能是if [condition] [...]少了一个速度提升，实际上，似乎几乎没人知道添加了此功能，因此它一定不会对任何人造成伤害. (如果有人可以在Red上弯腰以确保获得IF和IF/ON，那将是理想的选择.)

The most major non-breaking PR that was taken is probably not requiring blocks around IF, UNLESS, or EITHER bodies. This has been received well among those who know it's there, as fitting the freeform and non-boilerplate philosophy of the language. It allows some code constructs to get "prettier" and gives programmers more choice, while it doesn't seem to cause any more problems than anything else. It's certainly less of a speedbump than if [condition] [...], in fact it seems almost no one knows this feature got added, so it must not be biting anyone. (If anyone can bend ears over at Red to make sure it gets IF and IF/ONLY then that would be ideal.)

返回/重做已删除.理由是它允许函数在可变Arity条件下有效运行，并且这是不必要的，并且不再使terra firma消失了.能够根据其规格预测功能的优缺点.也许这种立场值得再次关注...因为迫切希望添加Lisp样式宏的Lisp用户似乎并不太担心. (在StackExchange世界中，这引起了Programmers.SE问题

RETURN/REDO was removed. Rationale was that it permitted functions to effectively behave with variable arity, and that this was unnecessary and took terra firma away by no longer being able to predict a function's arity from its spec. Perhaps this stance warrants a second look...as Lisp users who are pressuring for the addition of Lisp-style macros seeming aren't worried about that very much. (Here in the StackExchange universe, this provoked a Programmers.SE question Would Rebol (or Red) benefit from Lisp-style Macros?, which hasn't gotten much in the way of answers yet.)

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

• Prior to the open-sourcing of Rebol, Saphirion AG had a special relationship with Rebol technologies. They had access to the source and were taking responsibility for most of the development work for Rebol3 GUI features. They also added several other things like HTTPS.

Saphir可从其网站上以二进制下载的形式获得，但仅提供32位Windows.曾经有一次适用于Android的实验性APK.来自Saphirion.

Saphir is available as a binary download from their website, but only provided for 32-bit Windows. There was at one time an experimental .APK for Android from Saphirion.

部分(但不是全部)在开放源代码发布后，Saphir的来源被释放 .明显的遗漏是android版本和包住 ... a的Rebol3代码将压缩的脚本和资源注入到解释器的二进制文件中而无需重新编译的方式.

Some (but not all) of Saphir's source was released after the open-sourcing. Notable omissions were the android build and some Rebol3 code for encapping...a way of injecting compressed scripts and resources into binaries of the interpreter without needing to recompile it.

(注意:根据Apache2许可，不需要发布其衍生作品的源代码.)

• 通过GitHub rebol/rebol进行集成，在rebolsource/r3上建立了一个分叉，作为可以进行工作的社区构建".

• With the GitHub rebol/rebol being held up on integrations, a fork at rebolsource/r3 was established to be a "community build" where work could be staged.

Rebolsource的更改是保守的，似乎旨在显示GitHub的rebol/rebol如何按照Rebol构思的精神"采用更改的过程，前提是将存储库委派给社区. (出于这种精神，参见.) 因此，它集成了无争议的错误修正和调整，而不是用于实现HTTPS的大型第三方加密库.另外:除了C编译器(例如，没有GNU自动工具)之外，不允许添加构建依赖项.

Rebolsource changes were conservative, seemingly aimed toward showing process for how GitHub's rebol/rebol might adopt changes "in the spirit in which Rebol was conceived" should that repository be delegated to the community. (For that spirit, see this.) Hence it integrated non-controversial bugfixes and tweaks, instead of large third-party cryptography libraries for implementing HTTPS. Also: no allowance for adding build dependencies besides a C compiler (no GNU autotools, for instance).

用于社区构建的二进制文件是按需要为那些无法自己构建的二进制文件提供的.

Binaries for the community build were produced on an as-needed basis for those requesting them who could not build it themselves.

• Atronix 是使用Rebol的工业自动化解决方案提供商. 工程总监戴维·登·哈林(David den Haring) ，而他们的 ZOE软件是基于他们的Rebol版本构建的.

• Atronix is an industrial automation solutions provider that uses Rebol. How they do so is described in a video here by David den Haring, director of Engineering, and their ZOE software is built on their version of Rebol.

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

After the open sourcing, Atronix partnered with Saphirion to port the GUI to Linux. Atronix publishes their source publicly as it is developed, and David den Haring notes in the video above that they have only one proprietary component they developed (an industrial control driver). Other than that they are happy to share the source for all Rebol development they do.

Atronix集成了Rebolsource的64位补丁程序，创建了Windows 64位目标，并提供了 Windows和Linux x86/x64以及Linux ARMv7的开发分支的最新二进制文件.

Atronix integrated the 64-bit patches from Rebolsource, created a Windows 64-bit target, and offer up-to-date binaries of their development branch for Windows and Linux x86/x64, as well as Linux ARMv7.

除了具有Saphir的功能外，Atronix构建还增加了对 CALL的支持带有/INPUT，/OUTPUT，/ERROR.它还添加了外部功能接口，实现了LIBRARY！，ROUTINE！和STRUCT！与非Rebol动态库进行通信.它在Windows和Linux上也提供了封装支持.

Besides having the features of Saphir, the Atronix build added support for CALL with /INPUT, /OUTPUT, /ERROR. It also added a Foreign Function Interface, implementing LIBRARY!, ROUTINE! and STRUCT! for communicating with non-Rebol dynamic libraries. It brings in encapping support as well on Windows and Linux.

Rebol的宗教"有时与权宜之计不符，因此在需要时，手动编辑的makefile和Visual Studio项目取代了基于Rebol的构建过程. FFI库引入了对GNU自动工具的依赖关系.

Rebol's "religion" was at times at odds with expedience, so the Rebol-based build process was replaced when needed by hand-edited makefiles and Visual Studio projects. The FFI library introduced a dependency on GNU autotools to build.

所有Atronix构建都包括GUI，因此没有"Core"构建.同样，只有Linux和Windows.

All Atronix builds include the GUI, so there is no "Core" build. And again, only Linux and Windows.

(偏见注:此fork是 @HostileFork 的创举，它最了解并且会做最热烈地谈论.)

(Bias Note: This fork is the initiative @HostileFork started, knows the most about, and will speak most enthusiastically about.)

• Ren-C最初是从Atronix的代码库中提取的Core构建的一部分.这样，它就为Rebolsource能够为其构建的所有平台提供了诸如HTTPS，增强的CALL和外部功能接口"之类的功能. 更新2015年7月7日 Ren/C支持控制台中的行继续，用户中缀功能，多个错误修复...

• Ren-C started as an an extraction of a Core build out of Atronix's codebase. That gave it features like HTTPS, the enhanced CALL, and Foreign Function Interface to essentially all the platforms that Rebolsource was able to build for. Updates Jul/Sep-2015 Ren/C supports line continuations in the console, user infix functions, several bugfixes...

Ren-C进行了大规模更改，并修复了R3-Alpha中的基本问题，即 FAQ 作为GitHub Wiki.诸如定义范围内的回报之类的关键问题已得到解决，并在其他悬而未决的问题上不断开展工作.

Ren-C makes large-scale changes and fixes fundamental issues in R3-Alpha, which are tracked on a Trello that provides more information. There is a new FAQ as a GitHub wiki. Critical issues like definitionally-scoped returns have been solved, with continuous work on other outstanding problems.

尽管Atronix的R3/View需要一些附加的依赖关系，但Ren/C推迟了除了使用C编译器之外无需构建任何东西的可能性，并消除了所有手工的makefile/项目.

Though Atronix's R3/View required some additional dependencies, Ren/C pushed back to being able to be built with nothing besides a C compiler, and eliminated all handmade makefiles/projects.

除了Windows，Linux和Mac(具有32位和64位版本)之外，Ren/C一直是专为HaikuOS 和.这对于演示C89代码的交钥匙构建工作原理(简称为make -f makefile.boot)与那些特定操作系统的特别庞大的用户群是相反的更有趣！

Beyond Windows, Linux and Mac in both 32-bit and 64-bit variants, Ren/C has also been built for smaller players like HaikuOS and yes, even Syllable. This is interesting more for the demonstration of how broadly turnkey builds of the C89 code work (simply as make -f makefile.boot) as opposed to there being a particularly large userbase of those particular OSes!

从语言严谨性的角度来看，Ren/C正在推动现代技术的发展.尽管它仍然可以像C89一样构建，但是也可以像C99和C11一样构建.它也已经过验证，可以通过C ++ 14构建为C ++ 98，并且在#ifdef __cplusplus下进行了一些战略性修改，可以利用现代C ++作为C代码上的一种静态分析工具.引发警告，修复所有类型错误，并且它是"const正确的".仔细考虑了必要的更改，以使Rebol的基线C代码不仅更正确，而且更加清晰全部来源.

From the point of view of language rigor, Ren/C is pushing on modern techniques. Although it can still build as C89, it can be built as C99 and C11 as well. It has also been verified to build as C++98 through C++14, and with some strategic modifications under #ifdef __cplusplus it can take advantage of modern C++ as a kind of static analysis tool over the C code. Warnings are raised, type errors all fixed up, and it's "const correct". The necessary changes were carefully considered to make Rebol's baseline C code not just more correct but cleaner and clearer source across the board.

从C开发人员的角度来看，Ren/C应该足够稳定，有条理，并提供足够的注释，以便任何了解C的人都可以自信地进行修改"并尝试新功能.这意味着能够实现明确界定范围的回报 (实际上，但未推送)，或尝试开发 NewPath 一个>.

From a point of view of C developers, Ren/C should be stable, organized, and commented enough for anyone who knows C to "modify with confidence" and try new features. That means being able to implement definitionally scoped returns (actually written, but not pushed), or try developing features like NewPath.

从体系结构的角度来看，Ren/C旨在根本不具有可执行文件...而是一个用于将Rebol解释器嵌入其他程序的库.现在，它已经成为Ren/C ++的基础，Ren/C ++的目的是也可以预期与Red一起使用.

From a point of view of architecture, Ren/C is intended to not have an executable at all...but to be a library for embedding a Rebol interpreter into other programs. It is now the basis for Ren/C++, which was designed to anticipate working with Red as well.

从测试的角度来看，Ren/C打算将所有内容都捏造为工程严谨性和零错误容忍度.这意味着要使用 Address Sanitizer ，<一个href ="http://valgrind.org/" rel ="nofollow noreferrer"> Valgrind ，以及一个可以同时通过两者最高设置的测试套件.

From a point of view of testing, Ren/C intends to whip everything into shape for engineering rigor and zero bug tolerance. This means avoiding practices like zero-filling memory to obscure uninitialized memory accesses, using Address Sanitizer, Valgrind, and a test suite that can pass the highest settings on both.

虽然启用了所有额外功能，但使Ren/C的可执行文件的大小几乎是Rebolsource的两倍，但尚未进行任何审核以查看如何降低它.已经确认存在Zlib和PNG编码/解码的重复副本，例如(包含的蓝宝石 LodePNG ，它可能会解决现有PNG中的一个错误，因为它比修复它更容易...但尚未将先前的代码放在首位.).此外，能够选择性地仅集成您要使用的编解码器的构建也已列入议程.

While enabling all the extra functionality has made Ren/C's executable nearly twice the size of Rebolsource's, there's not yet been any audit to see how this can be brought down. It has been confirmed that there are duplicate copies of Zlib and PNG encoding/decoding--for instance (Saphirion included LodePNG, likely to work around a bug in the existing PNG because it was easier than fixing it...yet did not mothball the previous code). Also, being able to do a build which selectively integrates only the codecs you want to use is on the agenda.

Ren/C目前有Atronix和Rebolsource的利益相关者参与其开发和发展方向，这增加了它可能演变为"the" Rebol Core的可能性.现在，它已作为代码支持 Ren Garden 链接起来，并且使用了类似的方法它可能被设置为Atronix的R3/View使用的库...然后是Rebolsource ...，甚至最终是rebol/rebol本身.

Ren/C currently has the stakeholders from Atronix and Rebolsource participating in its development and direction, which strengthens the likelihood that it may evolve into "the" Rebol Core. It is now being linked in as the code backing Ren Garden, and using a similar approach it may be set up as the library used by Atronix's R3/View...then Rebolsource...and perhaps ultimately rebol/rebol itself.

(Bias注意:该编辑由Oldes本人于2019年2月28日添加)

• 从 community 分支派生.

与 Ren-C 不同，此版本未尝试引入新的语法，而是更接近原始的Rebol2和新的

Not like Ren-C, this version is not trying to introduce new syntax, but rather be closer to the original Rebol2 and new Red language

这篇关于REBOL3-不同分支之间有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！