No one was really using the "FAQ" on GitHub, and I doubt I would have noticed had anyone added a question (they hadn't). It was out of date, and I don't feel like updating it or correcting it, so I figured I'd delete it and just store a copy here.
While a lot has changed in the years since it was written, this point is still very much relevant:
"One driving mantra of the project is to be at a level of quality and improvement that it simply can't not be used."
Ren-C FAQ circa 2015 (nearly entirely outdated!)
Are Rebol and Ren-C different languages?
The goal of Ren-C is not to be a language at all, but a temporary fork of the Rebol codebase to redesign its core, which is taken back and re-incorporated into a formal release plan for "The Rebol 3" (non-alpha, non-beta, etc.)
It is ambitious to suggest that Ren-C's direction would be adopted by a majority of self proclaimed "software rebels". Yet signs from stakeholders point to the idea that Rebol 3 could very well emerge from something derived from Ren-C's codebase.
One driving mantra of the project is to be at a level of quality and improvement that it simply can't not be used.
What does the name "Ren-C" mean?
Given the decision for Rebol 3 files to be called .reb and with Red coming up with .red, an effort emerged to try and name the common LOADable file format that both languages used. Ren was proposed, that it would be the language-agnostic form of the file (sort of like "JSON" or "XML"). It was suggested that there be loaders for the data format in other languages, similar to the list available on json.org.
Since Red was calling its lower-level system implementation language "Red/System", the idea of calling the lower level library for processing Rebol data structures "Ren/C" arose. The slash is somewhat problematic in file paths, and so it just became called Ren-C.
Ultimately the goal is that Ren-C will not be something Rebol end-users will be aware of, but a library facing those building software that links to the evaluator. So whether the name is catchy or not isn't very relevant.
Is Ren-C compatible with R3-Alpha?
Update: R3-Alpha compatibility is no longer a goal, but compatibility through usermode emulation with Rebol2/Red is. See "REDBOL"
The goal of Ren-C is to produce the best and most correct experience in the native code. If a decision in R3-Alpha is questioned and reversed, it will be wrappers in usermode code which simulate the old behavior. For aiding in porting, wrappers exist and can be invoked by running:
do <r3-legacy>
(In Ren-C, DO of a TAG! is planned to be handled as looking up that tag in the module library, to be converted into a URL to run.)
Ren-C's ability to run much R3-Alpha code is a testament to Rebol's bendability as a language--to be able to undergo a deep restructuring yet still be made to run old code. However, there are some changes that are part of evaluation and will not be able to be addressed in this way. Fortunately there aren't that many changes in this category, and (for instance) an experimental R3-GUI is already running under Ren-C in the compatibility mode.
Yet philosophically, the belief of many is that Rebol 3 was not yet finished as a standard, and that the process of change picked up by the community was the beginning of that work. Most clients requiring stability stuck with Rebol2, and there are very few "R3-Alpha only" projects of scale. The ones that do exist are partners in developing Ren-C, so it really is the case that R3-Alpha compatibility is framed as a porting tool only.
So there is no long term support plan for R3-Alpha on Ren-C. Though the changes are #ifdef'd in the code at locations that could be selectively reversed by someone with the time or incentive to do it.
Where did the code for Ren-C come from?
The Atronix/Saphirion build diverged from Rebol at a point in time prior to its release as an Apache-licensed open-source project. Their build had a graphical user interface and several other additional features, but was only available for Windows and Linux.
Ren-C split out a "Core" build from the Atronix/Saphirion branch, which runs as a console process and does not require GUI support. Consequently, Ren-C brought all the non-GUI features added by Atronix and Saphirion to core builds for other systems (OS/X 32-bit and 64-bit, HaikuOS, Raspberry Pi, etc.) It also allowed users who are not interested in the GUI to use lighter builds on Windows and Linux.
What features does Ren-C have that R3-Alpha didn't?
Update: This list is now too hilariously long to enumerate in one place; Ren-C is light-years more advanced.
Generally speaking, it's hoped that the Rebol3 "Ren-C" porting Trello can serve as the main place for documentation and notes on the changes. Improvements range from the mundane to the profound--and from finished to unfinished. But the biggest feature is hopefully a codebase that can be read, understood, and modified with confidence...due to systemic audits and rewrites.
(However, the multi-faceted solution to definitional returns is a personal favorite of @HostileFork, as being critical to the language's model working.)
Not covered in the Trello are some of the things that came "for free" by virtue of the effort starting from an extraction of other projects.
-
HTTPS support as a protocol written in Rebol code, empowered by underlying cryptography libraries incorporated the C code. (Originally contributed by Saphirion.)
-
A foreign function interface ("FFI"), which allows Rebol to load a shared library and then directly call functions in it. This implementation is based on libffi, and brings new datatypes for interfacing with native libraries, such as LIBRARY!, ROUTINE!, and STRUCT!. (Originally contributed by Atronix.)
Note: Building Ren-C with the FFI currently requires additional steps or package installation as the FFI library has not been extracted into code following Rebol's build process.
-
CALLwith support for standard input/output redirection (also known as/INPUT,/OUTPUT, and/ERROR). (Originally contributed by Atronix.) -
UDP Network Scheme (Originally contributed by Atronix.)
-
Serial port support on Linux and Windows. (Originally written by Carl Sassenrath, completed & integrated by Joshua Shireman, extended by Atronix.)
-
Ability to make use of native 64-bit math builtins provided by the compiler/math library, where available. (Originally contributed by Atronix.)
What platforms does Ren-C run on?
Update: It still runs on all platforms it used to, but a very important new one: WebAssembly with JavaScript integration!
In theory Ren-C can be built for any platform that has support for ANSI C89 (with the caveat that the compiler also support C++ style // comments... though one could easily strip all the comments out if one wanted to and then build).
As of 16-Jul-2015, Ren-C has been verified as reaching the goal of building across the standards-compliant spectrum of C or C++ without warnings on these desktop platforms:
- Linux 32-bit x86 (
OS_ID=0.4.04) - Linux 64-bit x86 (
OS_ID=0.4.40) - Windows 32-bit x86 (
OS_ID=0.3.01) - Windows 64-bit x86 (
OS_ID=0.3.40) - OS/X 32-bit x86 (
OS_ID=0.2.05) - OS/X 64-bit x86 (
OS_ID=0.2.40) - Android-ARM (
OS_ID=0.13.1) - Android5-ARM (
OS_ID=0.13.2)
It has additionally been built for:
- Linux 32-bit ARM, on Raspberry Pi (
OS_ID=0.4.20) - OS/X 32-bit PowerPC (
OS_ID=0.2.04) - HaikuOS 32-bit x86 (
OS_ID=0.5.75) - SyllableOS Desktop 32-bit x86 (
OS_ID=0.14.01)
What is Ren-C written in?
Update: The decision to support C89 in building the core was dropped, and it now requires C99. However the API can still be used with C89. Reasoning behind the decision is given here, as well as how a tiny preprocessor could still make it build in C89 if someone were motivated to build it for an old system with no C99 compiler.
R3-Alpha was published as a codebase that could build under ANSI C89, with some warnings. It was then audited to build under strict ANSI C89, C99, and C11. It also added the option to build as strict ISO C++98, C++11, and C++14. The goal was to take advantage of stronger type-checking and metaprogramming, while still retaining the ability to do a complete build on very old compilers when __cplusplus is not defined.
Besides building under these ranges of languages, Ren-C can do so under both GCC and Clang with zero warnings (with as strict warnings as reasonable). Significant changes were required from R3-Alpha's code to do this. which are being given heavy thought on how to make things simpler, clearer, and better-checked. Across the board the code is more readable than what came in, with notable simplifications and improved checks.
Here are the warnings enabled (manually in the makefile, at the moment):
--pedantic -Wextra -Wall -Wchar-subscripts -Wwrite-strings
-Wdeclaration-after-statement -Wundef -Wformat=2 -Wdisabled-optimization
-Wcast-qual -Wlogical-op -Wstrict-overflow=5 -Wredundant-decls -Woverflow
-Wpointer-arith -Wall -Wparentheses -Wmain -Wsign-compare -Wtype-limits
-Wpointer-sign
These warnings are disabled (manually in the makefile, at the moment):
-Wno-unused-variable -Wno-unused-parameter -Wno-long-long -Wno-switch
If Ren-C is a library, why does it have an R3 console?
Update: There is a complex and configurable usermode console now, which is an extension you can build with or without!
Having a console built as part of the Ren-C process is an interim situation. It's not clear how long it will be there, yet still it was enhanced with line continuations...because they were a user contribution which it seemed there was no harm in accepting. (Though it does then mean responding to bug reports in that code, but it's not much code.)
Keeping the familiar R3-Alpha console alive helps make existing users more able to see the benefits of the work and use it as a replacement. Having it as part of the build process keeps the turnkey build working and letting people clone/download only one repository instead of building the library and then the console. But as a glimpse of future direction, consider that it has been shown that a basic multi-line editor can be written as tersely as:
forever [
do rejoin collect [
while [not empty? keep input] [
keep newline
]
]
]
Combine that with Ren-C offering an ability to fully transport all raw bytes (not just UTF-8) to the standard output...which could be used to do cursor control on terminals that required it. And with FFI (or just a few specialized hooks) the Windows console code could be called too. A good text console could be mostly all Rebol, with little to no C.
More hefty IDEs like Ren Garden will use Ren-C's linkage to build a different environment, leveraging existing UI libraries. R3/View will continue to exist as well. But the future direction for mainline text console development will be to push as much of it as possible away from the C, and this will hopefully be the "Rebol" branded console experience.
I'm seeing "assertion" crashes in Ren-C that were never in R3-Alpha, is it more brittle?
While to a casual observer it may seem that Ren-C has more kinds of crashes and strange outputs, this is due to a good thing: unlike R3-Alpha, Ren-C has a debug build. This adds extra code that brings both size and slowness. And for now, you SHOULD be using it--that's why it's on by default.
It is requested at this time that stakeholders do not turn off these additional alarms, checks, and reporting. Leaving it in means that while you run, you are helping to give valuable feedback about anything suspicious going on. These assertions help the big picture of making it easier to "Modify with Confidence".
But even if things that were working in R3-Alpha get broken now and again, it should be mentioned that Ren-C is not a "mere bugfix" build. It is a large scale rewrite of the core portions, making foundational changes. The assertions are a reason why the changes can be made at all. They're also a ballast for the future, so that developers who wish to modify the C code will be quickly warned if they make mistakes and have the "living rules" of the system feed back to them on their designs.
Users can confirm that not only has Ren-C fixed many outstanding issues from R3-Alpha, but that new crashing issues can be diagnosed and handled much more quickly. This is because the asserts pinpoint the problem as close to the source as possible.
What explains the increase of the size of the R3 executable?
UPDATE: Size optimization is mostly only focused on for the webassembly build at this time. The issue mentioned below about duplicate PNG libraries was resolved long ago.
On the same OS (for example windows) R3 binaries size are increasing.
- From rebolsource.net: 552kb
- From ren-c (10-DEC-2015): 905kb
- From ren-c (13-JAN-2016): 1308kb
If you noticed a recent change that drastic, check your makefile for optimization settings. If you changed it to -O0 at one point and didn't change it back to -O2, that would explain the difference between those sizes.
But on a more general point: there is nothing intrinsic to the methods of Ren-C that will make its core portions larger than R3-Alpha. It is actually anticipated to not only correct foundational flaws and be more reliable, but be faster and smaller as well. Yet today's Ren-C is intrinsically bigger than R3-Alpha because it was extracted from Atronix Engineering's codebase...which in turn had come from Saphirion AG's codebase. While some GUI code could be taken out, not all of it could--there still are some services which are awaiting factorization from core, but still there so that things like Atronix's ZOE can run on Ren-C in the near term.
Beyond a few of the "R3-View" GUI parts that couldn't be factored out entirely yet, some increases in size were simply unavoidable. For instance: the inclusion of cryptography libraries needed for HTTPS...where HTTPS was considered a non-negotiable feature by basically everyone. But one known "bad" situation is that there are two PNG-decoding codebases and consequently two zlib decompression methods--this arose from a bug in R3-Alpha's PNG decoding that led Saphirion to add another library without unhooking the old one from where it was being used. That could be addressed by a motivated individual with some time, who would decide which is the better library to be kept and how to make the cuts. But it is not on the critical path of issues being addressed (feel free to volunteer, though!)
Also, see the question about the debug build. You should be running a basic debug build, but there's little limits to how big a debug build can get, if you keep adding in instrumentation. On one Kubuntu 64-bit machine on hand, r3 is 14944640 bytes. But that includes debug symbols, a zero optimization level (-O0) to aid in variable inspection and debugging, linking in the "address sanitizer" and "undefined behavior santitizer" from Google, and the FFI. After turning all those things off, the r3 that comes back is 818024 bytes, FWIW.
In any case, this question brings up an important point--which is that Ren-C is a developer oriented library in a state of development. At present, one must know a bit about makefiles and C to really get into evaluating it. By all means do feel free to gather data, but please DO ask questions before making assumptions (that's what this list is for). If you are going to compare size or speed, do not do it without knowing what you're looking at.
How do Ren-C (and Rebol) relate to Red?
The Red language project has users in common with Ren-C, but no roadmap in common. In particular, Red is focused on the turnkey experience for building GUIs on emerging platforms. Its "full stack" agenda centers on implementing a Rebol2-like toolchain without C, but instead bootstrapped to a new systems-level language that is inspired by Rebol syntax.
Discussion on the Red project takes place on gitter.im.