January 16, 2018

RED Token Sale Success!

Dear RED supporters,

We did it!

I’d like to thank you, and the entire Red community, for supporting us throughout this token sale process. We know that you've waited patiently for new features and releases while we worked on it. We’re thrilled that so many of you are excited about using Red, the upcoming tools we'll build together, and using RED tokens in the community. Blockchain based "tokenomics" is a new and exciting world of possibilities that we can help create, together.

In the past month, since RED’s debut, there has been overwhelming interest in our token sale. We deeply appreciate that support, from all parts of the world.

We can now confidently embark on the next steps in Red's development, thanks to each and every one of you. The establishment of the Red Foundation and the development of Red/C3 are top priorities, but this doesn't mean all the other work stops. The success of the RED token sale means we can redouble our efforts, moving forward in greater strides, knowing we're on solid ground. Your support means more opportunities for the Red community to contribute and be properly acknowledged. Yes, we have a lot of work and planning to do, but we have a strong, clear vision and deep desire to see it through. The wheels are already in motion and I look forward to letting you know each time we complete a major milestone.

We are so grateful, more than we can say, to have such a supportive (and growing) community around us. On behalf of the entire RED team, I want to share our appreciation for you all, and I personally want to thank each of you for loving and believing in Red.

To Red's future, our future!

January 13, 2018

Registration Special Offer

Dear Red users and followers,

Thank you all for your genuine interest in Red, we greatly appreciate it.

We have received overwhelming requests and a very high number of documents for the registration.

It is the contributions from each and every one of you that makes Red great, and we thank you very much for your strong support. During that time, I was giving a speech at the FINWISE 2018 conference in Macau, as part of our road show for introducing Red to the blockchain community.

We set up strict rules for the acceptation process in order to secure it as best as possible. So we want to take the time to carefully review each provided document.

This is what we propose for those of you who submitted valid KYC verification information before UTC 7:30am, January 12th 2018, and could not participate to early bird round:

    1. We will send you a confirmation email informing you about your successful registration.

    2. You will then be whitelisted (all at once) and be able to buy the remaining RED tokens from the early birds supply, and at the upcoming open round.

   3. For those of you who could not participate to early bird round, but submitted the valid KYC before UTC 7:30am, January 12th 2018, and who will be buying during the open round, we will refund you 10% of the ETH amount you sent (you will be keeping all the RED tokens you will get), effectively giving you the same conversion ratio as during the early birds round.

We hope this is a satisfying solution and will make things right for those who could not participate yesterday.

The open round starts on UTC 8am January 16th. Get ready! ;-)

January 9, 2018

RED: here we go!

After long weeks of hard work, we are finally ready and happy to announce the opening of the token sales! We had to rename the token to RED (all caps), as an RCT token was deployed by another project a few days ago. Its purpose is still unchanged: powering the decentralized apps and Red community tokenomics!

This process will be held starting from January 8th to January 31st 2018, in three stages:
  Private Angel Investors       : Jan  8th - Jan 11th
  Early Bird round              : Jan 12th - Jan 15th
  Open round                    : Jan 16th - Jan 31th
The total fixed supply of RED tokens is 200,000,000. The allocations are:
  Private investors             : 10% (20,000,000) with a 3 months lockup period.
  ICO (earlybird + open rounds) : 30% (60,000,000)
  Red team                      : 15% (30,000,000) with a 12 months lockup period.
  Red Foundation                : 35% (70,000,000)
  Marketing/Strategic           : 10% (20,000,000)
Exchange ratios with Ethers (ETH) are set as:
  Private Investors             : 1 ETH => 3400 RED
  Early Birds                   : 1 ETH => 2750 RED
  Open round                    : 1 ETH => 2500 RED
Only Ethers are accepted, with a minimum of 1 ETH. Private angel investors also benefit from a 20% unlocking at the closing date of the token sales process.

In order to participate, you will need to go through an online registration process (KYC), and provide the required credentials. Citizens of countries that have banned or posed heavy regulations on such token sales are not allowed to participate.

For more information about the token sales:

This is the culminating point of many months of hard work and preparation. Many thanks to the teams and partners who have worked over the clock to make this happen. This is the dawn of new era for Red and its community of contributors, users and followers. Help us make it happen now!


January 3, 2018

Overview of Red development history

This video shows a fast-paced timelapse of the Red source code changes in the main repository over last 6 years, 9000 commits. You can see the avatars of all contributors, flashing commits on the files over time.

Here are a few stats showing the changes between Jan 1st 2017 and Dec 31th 2017:
  • Github stars: 1214 to 2970
  • Github programming languages ranking: #34 to #22
  • Page views on red-lang.org: 1.06M to 1.65M
As you can see, 2017 has been a great year, with interest in Red growing for some stats, faster than in all the previous years put together!

Short history of Red

Given that many newcomers arrived in Red community in the last two years, some might be confused about past Red history and timeline, so I would like to write it down now, and add some comments in retrospect on some of the choices made in the past.

The Red project was officially launched in March 2011, with the first public announcement and the release of the version 0.1.0, which was developed in 3 months. That early version provided a fully working Red/System toolchain, with a compiler and linker, all in 60KB of source code. That was just for Red/System, the low-level DSL of Red.

The Red language had different goals at that time, it was meant to be a statically typed sub-set of Rebol, with static scopes and no dynamic binding. That Red would have been only compiled, so no interpreter, and would eventually had a REPL after 1.0, once a JIT was available. Given my old work on an experimental Rebol clone in C a few years ago (implemented in 9 months), I estimated that a 1.0 for such Red could be doable in a year. Such a version would only support Windows and x86 architecture, would have most, but not all of Rebol datatypes, no DSL, no GUI nor floating point support.

During 2011, a community of users and followers started forming around this early Red version, the daily interactions with the community had some influence on the goals I had initially set for Red, and at some point during that year, I realized that what I really wanted was a more dynamic language, closer to Rebol, rather than a crippled static version. I decided then to trace a new longer road to a different design for Red, more in line with my personal desires and community expectations.

The scope extended as we kept adding new features (sometimes initiated by contributors), like ARM support, floating point support and Parse dialect. We then replaced the early low-level lexer with a much more capable version using Parse. The community was pressuring for a more "production-ready" version, which meant adding more features, like extra datatypes, postponing the 1.0 milestone further away up to 2014.

I have been working full-time on the project since 2011, and invested all my personal money to fund it, helped by individual donations from community members. Frankly, without those extra donations, I wouldn't have made it. In late 2013, I was contacted by a China-based VC (Innovation Works) who was interested by Red project. They offered me the chance to join them in Beijing. I initially politely refused, as I thought that doing so would consume too much time and accepting investments never has a guaranteed outcome. But thinking more about it, I also considered that raising a seed round would allow some talents in the community to work full time on Red, speeding it up. So, I accepted the offer and relocated to Beijing in 2014, settling for a new life there.

Red in its command-line form was not good enough to attract any investor, nor make any good business plan. So I made a major decision to incorporate the GUI module in the roadmap as soon as possible. The original plan was to only add it after Red had reached version 1.0. I also thought that Android support would be a key element for Red's future, so I also move it forward too. It took me about 7 months to raise a seed round, and 4 more months to effectively get the money into the bank account of the newly formed company in mid-2015. Work on Red during that time went more slowly. It never stopped though as we could hire our first developers (using a loan) and the number of contributors from the community was increasing.

A new roadmap was set and a 1.0 was planned for 2016 focusing on Android GUI support. Though, the early prototype on Android showed that developing a cross-platform GUI engine starting with Android (as we wanted it asap) along with the VID DSL was not a good way to achieve it, as the development cycle with Android was too long, and debugging at low-level there was very limited and painful. It was way more convenient to do it on a desktop OS like Windows, which was also the platform of roughly half of our users. So we switched the GUI development to Windows first, as it would be much faster to design and polish the cross-platform parts there, then make an Android back-end for it after.

The GUI engine with the VID dialect and back-end for Windows was released in early 2016. We initially planned only a minimal support and just a few (5-6) widgets for the Windows back-end, but the community wanted more (and still does). At the same time, we were also working in parallel on a Red IDE engine based on Scintilla. We needed more widget support, so we spent extra months doubling the initial number of widgets and polishing the features of VID, Draw dialect and View engine. The Scintilla IDE prototype was not as promising as we expected, some limitations with Scintilla were disappointing to say the least. They included awkward Unicode support and UI limitations. A Red GUI based IDE was a better option, allowing us to support any feature we could think of. We ran out of resources for such a side-project, so we put it to sleep until we can fund it (hint hint, the ICO would help there a lot too!).

After the initial GUI release, before we went back to Android support, we had to do some promotion about Red and our new shiny GUI system, in order to increase our userbase  (growth is a constant concern for VC-backed startups). Though, the competition was rough, as the new state of the art (on the web) was reactive frameworks which were providing a more powerful and simpler way to operate GUIs. Such reactive GUI was also something I had on my wish-list since 2010 for Red, and it seemed like the right time to add it, so that's what we did and released it in mid-2016. That enabled the production of some pretty impressive demos I think, for a cross-platform native GUI system.

We went back to Android development after that, starting by adding a preprocessor to Red lexer, in order to move a lot of costly work done at runtime to resolve Java method signatures, to compile-time. This work consumed around a couple of months, especially as we also took that opportunity to add an experimental macro system. The preprocessor is currently used by the Red runtime to reduce code size, though, we late figured out a better way to handle the Java method signatures  without relying on the preprocessor. So, we could have saved some time there, even if it's always easier to come to such conclusion when looking back in time.

As we continued on Android support, we stumbled upon new unexpected issues. All the features added in the last releases significantly increased the runtime size, resulting in very long compilation times. Moreover, the GUI system and newest object features broke the ability for the Red compiler to produce functioning shared library files for Red programs (Red/System shared libraries were fine, it was a limitation of the Red runtime library and compiler). We then decided to launch the "libRed" branch, in order to solve all those issues by enabling the compilation of the Red runtime as a shared library in two different forms: one is libRedRT, used only for speeding up the compilation process, the other is libRed, which provides an external API for embedding Red into external software (which was on our todo-list anyway and in the Red initial goals). That work took more time than expected, roughly 7 months, as I had to travel across the globe many times (for personal reasons) going offline for a total of 2 months during that period, which made it harder to properly focus on some of the complex issues that needed solving. That is where we lost the most time in the last couple of years, although the macOS GUI branch was still advancing at the same time in parallel.

After macOS release earlier this year, we could finally continue the work on Android, and guess what, we could develop a GUI backend on par with Windows one in about a month and half only! All the preparation work done before was paying off in the end! Still, that is not enough for acceptable Android support, as mobile devices have many features which need first-class support, and we are working on them for 0.6.5 release (delayed by the ICO preparations and process). We will provide more info about Android support very soon.

Another important consequence of adding GUI support for macOS, was the need to have a GUI console there too (identical to the Windows one), as we have great plans for the GUI console itself. As a side-project, we started working on a new GUI console engine in early 2017, replacing the low-level OS-specific Red/System bindings with the Red/View engine, enabling cross-platform support out of the box, and adding some key features we needed on the Red roadmap, like rich-text support. Those features are available in our 0.6.4 branch, and will be part of the next release shortly after the ICO (though probably after Chinese New Year in february).

One thing I have greatly underestimated during all those years (especially at the beginning), was the amount of time that would be spent interacting with the community, as I tried to be as present as possible online to answer questions, welcome newcomers and help them get started. My public posts are just the tip of the iceberg, as many people just contacted me on direct channels (email, private messages on AltME, Gitter, skype, ...), and that consumed a lot of time too. But, I think it was a necessity anyway, just unaccounted for. Nowadays it is much easier for me, as we have community managers and many other members who are doing a great job handling newcomers, wave after wave. Another thing I didn't consider at the beginning was also how much impact and influence the community would have on the features that we would put into Red (especially pre-1.0). As old-timers from Rebol community were used to have a great amount of feature available out of the box, they expected Red to be on par with that, often without much concern about the costs involved in supporting the desired features. I think I should have said "no" more often than I did, or just postponing them after 1.0.

All in all, despite the bumpy road sometimes, the current version of Red is better in many ways than what I hoped for in 2011. We still have the option to rename the 0.7.0 or 0.7.1 upcoming milestones to a 1.0 candidate, as they would have all the features we initially planned for a 1.0, though there are pros and cons about pushing the other planned features post-1.0, but I understand that Red users nowadays are more interested in reaching a 1.0, than having a more feature-complete one. We can discuss about that on our Gitter channels.

This is a (very) short version of the Red history, there is so much more to say about it, maybe someday when I will have some spare time, I'll write down the whole thing in a book, including my views on language design, and all the non-tech related side stories. ;-)


January 1, 2018

Answers to community questions

After our announcement, we already answered on Gitter some questions related to this new sub-project of Red that we are launching. The remaining new questions are answered below.

ICO-related questions

Do you have an estimate how long establishing that foundation will take, couple weeks?

We expect it to be officially set up before the end of January (if not delayed by extra paperwork). We are setting it up in Paris, France.

Why choose ICO instead of traditional funding schemes (Patreon, donations, etc)?

That's a good question. In 2015, we already raised a seed round for the company supporting the development of Red (Fullstack Technologies), though that is far from enough in order to move faster, as the scope of the project keeps growing. Individual donations were enough 5 years ago, when the project was in its infancy, but that level of funding is not capable of sustaining the project in its current form since a long time.

What is plan B if the ICO is not successful?

In such case, Red/C3 will drop low in priority as we won't be able to fund the work on it, and the Red foundation will have no mean to operate and help Red project and community. We would then focus on our core roadmap and unroll our business plan for the Red core technology only. The ICO is a better path, not just for funding the whole Red project further, but because the blockchain market is a big new opportunity for the Red stack, and we should seize it in order to grow up faster and much bigger. Moreover, introducing a token-based economy in the Red platform would open many new business opportunities, both for our company, and for the Red users.

All other ICO-related questions will be answered once we set up the landing page for the ICO, with the published whitepaper and adequate communication channels. All that is under heavy work right now, we should be ready in about a week from now.


Any plans to run a private NEO blockchain?

That is something we are considering, yes. Though we have many other possible choices. We should meet with the NEO council in 2018, so we will be able to investigate that option deeper with them.

Are there plans for Red to support IPFS?

Clearly yes. That can happen just after 0.7.0 release with full I/O support, though this could be contributed by the community (with sponsoring from the Red foundation), it doesn't need to be implemented by the core team.


How is Red sustained, who currently supports it?

Red is sustained by its supporting company, Fullstack Technologies, who received a seed investment in 2015, and by contributors on a daily basis. Previously, Red was funded by my personal money and donations from users.

Is stuff like concurrency also required to reach 1.0, and be used on blockchains? 

We plan to have a form of async tasks support for 1.0. There are several models we could use, Actor is our prefered model so far, but the final choice is not done yet. For parallelism, that will be for a 1.x.

Is interop with other mainstream libraries/languages (java, python, c#, go,...) planned?

LibRed can be used for that. We have a few bindings already. For Java, we have built a bridge a few years ago. That bridge has been improved in our new Android branch (currently private). For Python, Go and other languages, it's up to the community to plug libRed there, if needed.

You said that the current Red roadmap will be delayed by a few weeks. You don't think it will be much more with all activities created by this big move?

We plan to resume on our normal roadmap as soon as the ICO is done, so by finishing and releasing Red 0.6.4. The new branch of development will have its own roadmap and dedicated resources (hopefully paid by the money raised through the ICO). My personal time will be split between the core parts (including Android) and the blockchain branch.

Giving recent announcement, it seems that Red drifts further and further from initial idea of Carl. Building blockchain tech without proper GC, or 64 bit support and just basic I/O. And it's worrisome that "full-stack language" and its community may lock itself in one niche. Can you comment on that?

On the contrary, Red goes closer to the original idea of Carl, of a "messaging" language and distributed computing through IOS reblets (the X-internet), as explained by our announcement article. The blockchain technology helps improve such architecture, by allowing it to operate in a decentralized way. For the rest, the GC branch is almost finished and should be available in 0.6.4 release. 64-bit support is not a top priority right now, as 32-bit apps can run on all our current target platforms, so it is more of a convenience for some users. We know that some OS vendors are planning to restrict their platform, so we will set up a path to go 64-bit, though it will take some time to get there. For the record, "blockchain tech" and GC/64-bit are totally unrelated features and are not even on the same roadmap.

About "locking itself in one niche", that makes no sense, the announcement article says "in a new branch of the Red project". So the project is expanding to cover more domains, and not restricting itself in a niche.

Following both planned Red roadmap and doing Red/C3 in one project... isn't it too ambitious?

As explained in previous answers, Red/C3 is a sub-project of Red, with dedicated resources. There is a great opportunity for Red in the blockchains right now, targeting smart contracts and Dapps. Red is a great fit for the needs in that market. That is a great opportunity to expand Red userbase and spread Red around.

That is all for now, if you have more questions, please ask them in red/red or red/blockhain rooms.

Happy New Year to all the Reducers in the World! 2018 will be an exciting year for all of us! ;-)

December 25, 2017

Leaping into the future: Red goes blockchain!

Here we are, ready to leap into the future. This is a new page opening in the Red history book. It is a great day for us to finally be able to share with everyone some great news for Red and its community. Fasten your seat belts and enjoy the ride! ;-)

Why the blockchain?

Unless you just woke up from prolonged hibernation under Artic ice crust, you cannot miss the hype around blockchains and their related coins. If you are new to cryptocurrencies and blockchains, let me give you the simple bird view on that: speculation on cryptocurrencies is currently very high, but whether it is a bubble or not, bursting soon or never, is not really relevant. The important part, shadowed by the coins market hype, is that the blockchain technologies are a new infrastructure that should help solve many issues we have. It is a missing piece that we need in order to rebalance the modern Internet landscape, and bring back the decentralization that was once promised in the early Internet days.

Though, the impact of such disruptive change goes way beyond just Internet infrastructure (for example, IPFS or Storj), it has the potential to reshape many industries (see the Brave browser and its Basic Attention Token, bringing a saner alternative to online advertisement) and human activities, including in our daily lives. We are currently still just seeing the first generation of blockchains. Those pioneers have inefficiencies, like scalability and power consumption issues, though, after following and studying the evolution of blockchains during a year, I am now confident enough that those issues will be solved in a not-too-distant future by the next wave of blockchains (or upgraded versions of existing ones). For example, zero-knowledge proof and especially the non-interactive variant are really impressive and promising approaches.

So, how does Red fit there?

As Red aims to be a fullstack programming solution, we naturally look at what are the potential next big platforms we should support. Since last year, we are watching and studying the various blockchains, especially focusing on the ones supporting smart contracts, Ethereum being the leading chain in that domain. Basically, it is like a distributed computer, where you can run arbitrary sandboxed code, using the distributed ledger as its database. There are a few programming languages which can be used to implement those smart contracts, but Solidity is the default one now for such tasks. If you are a Red follower, you know how much we care about simplicity and efficiency in our programming tools. Well, those concerns do not seem to be shared by people who created the existing tools for smart contracts coding and testing. Let's put it bluntly, the current state is a nightmare. It takes several hours, up to a full day to just figure out and set up a development environment the first time, even for a senior developer. The sheer complexity in such toolchains is really high. The Remix initiative is still young, but it is a lifesaver compared to other existing toolchains. Still, you have to put up with a language that has many questionable design choices, for coding contracts which could handle billions of dollars worth of assets. Guess what happens under such conditions.

So, there is a huge need for a better, much simpler and safer contract development tool. We know that Red can deliver such solution, because that's our fight and our mission since the first release of Rebol 20 years ago. Still, people who work with me know how skeptical I am. So it took me several months of studying and discussions to figure out where and how Red could help in that domain.

Why now?

We are at an early point of a new revolution.We do know that much better development tools are needed, and the current offer is poor and disappointing to say the least. We know that we can provide a great solution based on Red, in an acceptable timeframe. This is an amazing opportunity, like we haven't seen since late 90's and the rise of the world wide web. This is our time now.

So this is what we will build, in a new branch of the Red project:


A new Red dialect (DSL) whose code-name is Red/CCC (Cross Chain Code) or just Red/C3, for smart contracts programming. Such dialect will compile to the Ethereum VM (EVM) bytecode directly as first target, and more backends will be added later to support other chains, like NEO. We are at the design stage, the first alpha (prototype) is planned for end of Q1 2018. Our current design involves a combination of two small languages:
  • A very high-level layer: a symbolic and highly declarative language with restricted computing semantics and restricted control flow (turing-incomplete), reading mostly like natural language (compared to mainstream languages). Coarse-grained code produced at this level by the compiler will exhibit higher safety, close to the level provided by templates, while still providing much greater flexibility. An intelligent visual program builder will also be considered for pre-generating such code.
  • A lower-level layer: a general-purpose, statically typed, subset of Red language.

Moreover, for testing such contracts, we plan to create:
  • a simulator for the EVM (and later for other chains VM) coded in Red/System for fast performances.
  • a generative testing environment, for auto-testing user contracts extensively in addition to manually written tests using a simple testing framework we will provide too.
  • a GUI interface to handle all that in an easy way, without requiring deep knowledge of the blockchain infrastructure.
The toolchain will be an extension of the current Red toolchain, so it will be a standalone binary of 1-2MB.

Red Dapps

Smart contracts are used to power what is called Decentralized Apps (Dapps)-- Basically a user-facing application operating on blockchains through smart contracts. Currently such Dapps are built using web stacks, but still need to connect to a blockchain node in order to interact with it. Light nodes could help solve that, but they break the decentralization model. So, in order to facilitate the deployment of the required blockchain nodes, such apps are often wrapped in a standalone native installer using an Electron framework. This results in big downloads (50-150MB) and big memory usages inherent to web stacks.

The Red stack, with its ~1MB runtime (~300KB if compressed) can provide a much better alternative, and Red GUI capabilities can lower drastically the entrance barrier and costs for coding apps and Dapps. In order to achieve that, we need to add a blockchain node connector in our runtime library, preferably wrapping a node in C library form, though using JSON-RPC is also an option.

For old Rebolers, maybe you remember Rebol/IOS in early 2000's, for handling the X-Internet? Well, guess what? Carl was right all along (as usual). ;-) You can look at the Red Dapps as a modern blockchain-powered incarnation of that concept!

What about the existing Red roadmap?

The Red core language development continues with the same roadmap, we are just delaying a bit the 0.6.4 and 0.6.5 releases, in order to pass the big wave of changes in the incoming weeks. In order to achieve that, while opening a new branch of development, we need to grow bigger and structure the whole thing differently. Here are the plans to move the whole project to the next stage:

Red Foundation

We were thinking about that since last year, but now is the right time to do it for many reasons. We need a dedicated organization to handle the community and contributors' efforts for the work on Red core language. We also have plans for business activities, and it would be easier to separate the teams working on the open-source project and the ones working on commercial products and services. It is not an unseen set up, the Clojure project structured itself in a similar way.

So, we have filed an application to set up a Red Foundation in France, and will transfer to it the rights and governance for the open source parts of Red. The managers of that structure will be: Gregg Irwin, Peter W A Wood, François Jouen and myself, for starting. The foundation has a complex job and will require resources to operate, hence:

Red community 2.0: RCT token

We are embracing the blockchain philosophy fully and will empower the Red users and community using a decentralized organization (DAO), supported by a new ERC20 token called Red Community Token (RCT). There is no other programming language or tool that I have heard of, attempting to move their existing community to a DAO, so we will be exploring uncharted territories there, and setting an example for others to follow. The foundation will be setting up the rules with the help of the community, for the usages of the RCT token. Some of the target usages for the token holders, will include:
  • voting rights: influence the Red roadmap, vote for features and issue tickets.
  • tipping: useful chat posts, code contributions, learning materials providers, etc.
  • intra-community cryptoeconomics (or rather tokenomics): selling/buying services from other community members (coding tasks, consulting, learning help, bug fixing, decentralized gaming, etc.)
  • paid Dapps, or in-app purchases.

In addition to that, the foundation will hold a significant amount of RCT, which will be used for rewarding:
  • code contributions
  • Red-related online learning or presenting materials (blog, documentations, etc.)
  • promotional actions (presenting Red at a conference)
  • any other actions that will help spread Red and make the community grow up. 

There will be an initial distribution of RCT tokens to the existing Red contributors (once the foundation defines the rules and allocation amounts), that will retro-actively cover existing contributions (like merged PR, tickets resulting in code changes, past donations, etc.).

Last but not least, the RCT might be used in the future as a gas token, to pay for cross-chain different gas currencies, or to power a future Red's own blockchain.

Those are just scratching the surface of the possibilities that such token and DAO (powered by smart contracts) could open. This gives you an idea of the disruptive potential of blockchains, when rightly used. It is not yet clear how far we can go into the decentralized model, it is something we will explore all together (we'll set up dedicated chat rooms on Gitter and other sites for that).

This will be our greatest challenge, but I trust we have enough brain power in the Red foundation and community to figure out the best rules for a healthy organization.

Initial coin offering

In order to kickstart the RCT token, and fund all the resources needed to accomplish the above tasks and roadmap, we need to raise some money. Initial Coin Offering (ICO) are the new way to achieve that. I have been reluctant to do that for a while, given how young and controversial it can be (the amount of scams in that domain is really high), but after studying many other ICO, I am convinced now that this is not just a short-lived fad, but a real new model to fund projects, and especially open-source projects related to blockchains.

We have produced a whitepaper earlier this year in October (co-authored by Tamas Herman and myself), to describe with more details and context what we are building. We will release it publicly in a few days.

The ICO itself should be held in early January 2018, starting with an angel round, then pre-sale and open rounds following right after. A new website will be available in a few days, giving the full information required for the ICO.

The ICO should provide us with enough funds to cover all the needs for this ambitious roadmap. A job list will be available after it, as we hope to hire the best profiles from the Red community, so update your CV and clean-up the source code of your Red apps. ;-)

Final words

These are intense and exciting days for us and the Red community, I wish you all a Merry Christmas, and have a good beer, maybe someday you'll pay it on your smartphone with a Red Dapp powered by RCT tokens. ;-)


July 17, 2017

0.6.3: macOS GUI backend

This new Red release contains ~830 commits, closes 86 issues, and brings a large number of  new features. The main one is official support for the macOS GUI, through a new backend for the View engine.

For readers not familiar with our GUI system, you can get a quick overview in a previous article.

In a nutshell, it is a dynamically-built reactive object tree, with:
  • pluggable backends (full support for Windows and prototype for GTK and Android)
  • full 2D vector graphics support (a large subset of SVG)
  • direct reactive programming support (not FRP style for now)
  • a declarative DSL for GUI building and layout management
  • a declarative DSL for 2D graphics

The macOS backend supports all the same features as the Windows backend, except the following, yet to be implemented:
  • fill-pen pattern, fill-pen bitmap and diamond gradient in Draw.
  • matrix transformations on pen and fill-pen in Draw.

The GUI console for macOS will be available in the 0.6.4 branch, so is not part of this release. The View module, though, is compiled in the CLI console by default on macOS, so no show-stopper there.

Here are a few short examples, starting with a GUI Hello World!:
    view [text "Hello Mac World!"]

A tiny demo script (hopefully, it should get us an office at Station F, right? ;-)):
    view [
        t: text "French Touch! " on-time [move t/text tail t/text]
        base 21x15 draw [
            pen off
            fill-pen blue  box 0x0  6x14
            fill-pen white box 7x0  14x14
            fill-pen red   box 14x0 20x14
        ] return
        button "Start" [t/rate: 10]

A small reactive text size measuring tool (one of our test scripts):
    view [
        style txt: text right
        txt "Text" f: area 200x80 
            font [name: "Comic Sans MS" size: 15 color: black]

        txt "Size in pixels" text "0x0"
            react [[f/text f/font] face/text: form size-text f]
        txt "Font name" drop-list 120
            data  ["Arial" "Consolas" "Comic Sans MS" "Times"]
            react [f/font/name: pick face/data any [face/selected 3]]
        txt "Font size" s: field "15" react [f/font/size: s/data]
        button "+" bold 40 [s/data: s/data + 1]
        button "-" bold 40 [s/data: max 1 s/data - 1]

Generating macOS bundle apps is made simple by our toolchain, just use the -t macOS target when compiling, for example using our SVG Tiger demo:
   $ red -o ~/Desktop/ -t macOS tiger.red
This will produce a tiger.app bundle on the Desktop:

Cross-Platform GUI Metrics

In order to cope with different UI guidelines across GUI platforms, this release also introduces an experimental rule-oriented GUI rewriting engine, capable of modifying a face tree dynamically according to pre-set rules. It is integrated as a last stage in VID (Visual Interface Dialect) processing. The currently implemented rules are per-platform for now (more general, cross-platform rules are also planned):

Windows rules:
  • color-backgrounds: color the background of some colorless faces to match their parent's color
  • color-tabpanel-children: Like color-backgrounds, but tab-panel specific
  • OK-Cancel: buttons ordering rule, puts Cancel/Delete/Remove buttons last
macOS rules:
  • adjust-buttons: use standard button sub-classes when buttons are narrow enough
  • capitalize: capitalize widget text according to macOS guidelines
  • Cancel-OK: buttons ordering rule, puts Ok/Save/Apply buttons last

To give you a quick grasp about why that feature matters and what it is capable of, here is a simple example, which leverages the buttons ordering and capitalization rules:
    view [
        text "Name" right 50 field return
        text "Age"  right 50 field return
        button "ok" button "cancel"

You can see, side-by-side, the macOS and Windows generated forms. Notice the button text and ordering, yes, they differ from the source code! The GUI rules have ensured that:
  • the buttons are ordered according to each platform's guidelines, "Ok" last on macOS, "Cancel" last on Windows.
  • the button's labels are properly capitalized on macOS.

This small example just demonstrates the concept, but actually, there is no limit on how much it could alter the UI and how far it could go with the post-processing.

As it is still experimental, if it causes you any trouble, you can easily disable it using:
    system/view/VID/GUI-rules/active?: no
You can also remove rules selectively, by modifying the content of the following lists:
    == [

    == [
This allows you total control where needed, but also helps you conform to UI guidelines with no effort, saving everyone time. Not only do you not have to tweak your code for each platform when you write it, when a new platform is added, you won't have to change your code to support it. In a world where getting one detail wrong may keep you out of an app store, or prevent you from being a "certified" app, this is huge. It should also be possible to use the rule engine to write a guideline linter, where you could get a report of what rules will be applied to your VID code on each platform. By "report", we don't mean just a text listing, but it could highlight elements in the UI that were processed by rules. Having a system that helps you is great. Having a system that tells you how it helped you is even better.

There are tons of possible rules we could implement, if you have ideas for great ones, please let us know by joining us in our online chat room on Gitter or, if you prefer, by posting on our mailing-list.

Other changes in 0.6.3

Core language

The biggest addition to the core language in this release is the date! datatype, which supports all Rebol's date! datatype features and more. The additions include support for a large range of ISO 8601 date formats. About 350 unit tests have been written so far. The full documentation is available here.

Here are a few examples of accepted input formats:
    >> 1999-10-5
    == 5-Oct-1999

    >> 5-October-1999
    == 5-Oct-1999

    >> 5/9/2012/6:00
    == 5-Sep-2012/6:00:00

    >> 4/Apr/2000/6:00+8:00
    == 4-Apr-2000/6:00:00+08:00

    >> 2017-07-07T08:22:23Z
    == 7-Jul-2017/8:22:23

    >> 2017-W23-5
    == 9-Jun-2017

    >> 2017-153T105000-4:00
    == 2-Jun-2017/10:50:00-04:00
Math and other operations are fully supported:
    >> d: now
    == 14-Jul-2017/16:04:07+08:00

    >> d + 10
    == 24-Jul-2017/16:04:07+08:00

    >> d + 100
    == 22-Oct-2017/16:04:07+08:00

    >> d - 24:00
    == 13-Jul-2017/16:04:07+08:00

    >> d - 01/01/2010
    == 2751

    >> d/month: d/month - 5
    >> d
    == 14-Feb-2017/16:04:07+08:00

    >> d/yearday: random 365
    >> d
    == 1-Aug-2017/16:04:07+08:00

    >> sort [1/2/2018 1999-5-3/10:30:28 29-2-1980]
    == [29-Feb-1980 3-May-1999/10:30:28 1-Feb-2018]

    >> random 01/01/2018
    == 15-Dec-1248
Red also adds three new accessors:
  • /timezone: changes the zone and adjusts time accordingly (UTC-invariant)
  • /week: gets/sets the week of the year, starting on Sunday.
  • /isoweek: gets/sets the ISO week of the year, starting on Monday.

Conversions to/from Unix epoch time are also built-in:
    >> to-integer 1/1/1970
    == 0

    >> to-integer now
    == 1500020743

    >> to-date 1000000000
    == 9-Sep-2001/1:46:40

Other Core Additions

New functions were added to the existing simple IO API:
  • delete: deletes a file or an empty folder.
  • size?: returns the size in bytes of a file.

The do native now accepts a URL argument. For example:
   do https://raw.githubusercontent.com/red/code/master/Showcase/eve-clock.red
Run-time error reports now include a compact call stack trace:
    foo: does [1 / 0]
    bar: does [foo]

    *** Math Error: attempt to divide by zero
    *** Where: /
    *** Stack: bar foo

A set of new functions for disk-cached remote file access is now available: do-thru, exists-thru?, load-thru, read-thru, path-thru. They work in the same way as their normal counterparts, except that the retrieved file is cached locally, so on their next access, the locally cached copy will be used.

The system object has been extended with:
  • system/options/cache: points to the cache folder used by the Red toolchain.
  • system/options/thru-cache: points to the cache folder used by *-thru functions.
  • system/catalog/accessors: Path accessors available, per datatype.

The browse native can now work on macOS (it opens the default browser on a given URL).

Rudolf Meijer did a huge job, gathering currently implemented rules for math operations on mixed datatypes. This has resulted in documenting and improving those rules, better defining the resulting datatype for all math operations.

More changes:
  • Now is now fully operational and can return current date and time.
  • Wait now accepts a time! value argument
  • Improved make and to url! construction when the spec argument is a block.
  • Auto-detect older Intel CPU on Windows platform when building the console.
  • Even? and odd? now support time! values as argument.
  • R/S compiler can now output a function address map for verbosity >= 3
  • Improved min and max natives support for pair! and tuple!(now min/max is applied per dimension to pair! and tuple!, and can work with a number! as second argument).
  • -t compilation option does not force release mode anymore if target is the same OS.
  • Source file name in now displayed on syntax errors at compile-time.


LibRed has been improved, thanks to the work of Joa-quim on a libRed binding for the Julia language, providing Julia with the full power of Red's native GUI system. Several new functions were added to libRed API:
  • redBinary(): constructs a binary! value from an external byte array.
  • redImage(): constructs an image! value from various possible external byte arrays.
  • redGetField(): gets the value of an object's word.
  • redSetField(): sets the value of an object's word.
There is more info about them in the libRed documentation.

LibRed's robustness has also been vastly improved. LibRed API functions can now catch null pointer arguments, and even invalid pointers passed to the libRed API. In these situations, libRed returns a Red error! value.

View engine

In addition to the macOS backend, a new test backend is included in this release. This backend works by simulating a GUI backend for testing purposes. It is still experimental but works fine so far. We should be able to write a whole suite of unit tests for the View engine and VID dialect now and run them on a headless Linux server (like our Travis CI). In the same way, this backend enables Red users to unit test their GUI apps with minimal effort (though more tooling on top of the current backend is welcome).

The working principle is simple: use view/no-wait to produce your GUI without starting the event loop, then form your tests using the following model:
  • Set the focus on the face where you want to simulate an event (using set-focus).
  • Trigger an event (using do-event).
  • Test if the result of the event conforms to your expectations.

Here is an extract from a short test script:
    view/no-wait [
        hello: button "Hello" [print "ok"]
        name: field

    set-focus hello
    do-event 'click

    set-focus name
    do-event/with 'key #"4"
    do-event/with 'key #"2"
    do-event/with 'key 'enter

    probe name/text
    probe name/data
Using this test backend requires setting some options in the header (see the linked script's header), and compilation in release mode.

Another notable addition is the foreach-face function, which powers our GUI rewriting rules engine. It allows easy traversal of a face tree (depth-first), selecting only the faces you need to process. The syntax is:
    foreach-face <root> [<actions>]
    foreach-face/with <root> [<actions>][<conditions>]
    <root>       : root face of the tree.
    <actions>    : actions to perform on matched faces.
    <conditions> : optional conditions for selecting faces.
The first version applies the actions block to all faces, while the second one (/with) will select only faces matching the conditions block (which needs to return a true value to act on the current face). Both the actions and conditions blocks have an implicit face word defined, which refers to the current face in the tree. For example:
    do %tests/vid.red
    collect [foreach-face/with win [keep face/text][find face/text #"i"]]
will return:
    == ["China" "in panel" "option 1" "option 2" "option 3" "option 4"]
Here is a more sophisticated example using foreach-face to dynamically localize labels and adjust buttons size and position accordingly, so that they fit the text nicely:

    langs:  ["English" "French" "中文"]
    labels: [
        ["Name" "Age" "Phone #" "Cancel" "Submit"]
        ["Nom" "Age" "Tél." "Abandon" "Envoyer"]
        ["名字" "年龄" "电话" "取消" "提交"]
    set-lang: function [f event][
        root: f/parent
        condition: [all [face/text face/type <> 'drop-list]]

        list: collect [foreach-face/with root [keep face/text] condition]
        forall list [append clear list/1 labels/(f/selected)/(index? list)]

        foreach-face/with root [
            pads: any [metrics?/total face 'paddings 'x 0]
            prev: face/size/x
            face/size/x: pads + first size-text face
            face/offset/x: face/offset/x + ((prev - face/size/x) / 2)
        ][face/type = 'button]
    view [
        style txt: text right 45
        drop-list data langs select 1 on-change :set-lang return
        group-box [
            txt "Name"  field return
            txt "Age"   field return
            txt "Phone" field
        ] return
        pad 15x0 button "Cancel" button "Submit"

You can also detect window resizing events, and use the current window size to resize and position faces dynamically.

It is now also possible to change the mouse cursor shape, using pre-defined values, setting a custom image to face/options/cursor, or using the cursor keyword in VID, followed by an image! value or one of the following keywords: arrow, I-beam, hand, cross.

Here is an example:

Other changes:
  • Lit-words are now accepted in flags facet blocks.
  • New Shape dialect command: close.
  • Changed default background color to white in tab-panel (Windows).
  • Added system/view/metrics (used mostly by VID, for more accurate sizing/positioning).
  • Added accelerated? option in face, when set to true, for faster/smoother face rendering (only base faces). Z-ordering is then only honored between accelerated faces.
  • When a button has the focus, pressing enter key will trigger a click event.
  • Renamed enable? facet to the more correct enabled?.
  • New function: set-focus (sets the focus on a given face, important for GUI testing).
  • New class option in face/options, allows setting a sub-class of a native control.
  • text-list now accepts a data keyword and any-string! values as input. This lets you to feed the list with values from VID. For example:
    view [
        text-list data parse
            read https://api.github.com/repos/red/red/events
            [collect [any [thru "message" 3 skip keep to ["\n" | {"}]]]]

The above script is just a single expression using two DSLs. I let you meditate on that. ;-)

VID dialect

VID has received many enhancements too. The most significant are:
  • more accurate sizing and positioning of native widgets using OS metrics
  • addition of alignment control, extending across/below layout modes.

So, it is now possible to add optional alignment keywords for the two linear layout modes:
  • across: top, middle, bottom
  • below: left, center, right
Those keywords can also follow the return command, if changing the alignment mode of the next row/column is required. The defaults are top and left. Here is a short example:
    view [
        style chk: check "Option" data yes
        style vline: base 2x60 red
        across top    vline button "Ok" text "Text" field chk return
        across middle vline button "Ok" text "Text" field chk return
        across bottom vline button "Ok" text "Text" field chk

Other changes:
  • New on-created event, triggered just after a face has been shown for the first time.
  • New strike option for faces: sets the strikethrough font style.
  • New init [<body>] styling option allows you to define a block of code to run when the style is instantiated.
  • later option added to react keyword.
  • Allows data and at keyword argument to be an arbitrary Red expression (see the above text-list example).
  • More robust face options parsing.
  • The default actor for h1 to h5 and text widgets is now on-down.
  • VID now saves the style name for each face in face/options/style.

Parse dialect

A new case command has been added to Parse dialect. Case temporarily changes the case matching mode, for the next rule only.

  case <mode> <rule>

  <mode>: TRUE (case-sensitive matching) or FALSE (case-insensitive) (logic!, word!)
  <rule>: rule on which the local case matching mode is applied to.

Red/System dialect

For newcomers, Red/System is Red's built-in system programming dialect, offering a Red-like syntax with C-level semantics (and many improvements over C, like namespaces, exceptions, RTTI,...).

This release brings an important improvement: structures can now be passed and returned by value on internal and external function calls. They can also now be inlined in other structures. This is achieved by putting the value keyword after a struct! type declaration:
 name [struct! [<fields>] value]
Passing structs by value is sadly not formally specified in C language, resulting in incompatible compiler-specific ABIs. Moreover, those ABIs are not documented, or only partially, so gathering all the right information was painful and time consuming. Just to illustrate how bad the situation is, after spending days researching all the various C compilers ABI, I was able to answer a stackoverflow question about returning C structs by value, which was left unanswered for 6 years... I might write a synthetic article about those C ABIs someday, from my notes, as I could not find such documentation online. Anyway, the hard work has been done for you. Red/System now implements the most common ABI for each platform:
  • Windows: Microsoft Visual C ABI
  • Linux: gcc/Clang ABI (with support for ARM-specific ABI) 
  • macOS: Clang ABI

In addition, more stack-oriented features are now supported:

The new use feature allows you to create local variables anywhere in a function body. It is useful for splitting long functions and creating local variables in macros.

The ARM backend has also been enhanced significantly in this new release:
  • fixes and improvements to soft integer division routine.
  • fixes non-passing unit tests on floats.
  • better AAPCS conformity and various bug fixes.
  • improved accuracy of overflow detection in multiplication.


ANSI escaping sequences are now supported in the Red CLI console, thanks to Oldes. See this pull request for more info and a screenshot.

Other console changes:
  • improved auto-completion, now completes the longest common substring.
  • auto-detect older Intel CPU (non-SSE3) on Windows platform when building console.
  • system/console/size now provides the size of the console in columns and rows

What's Next?

The 0.6.4 version will mostly focus on the GUI console, not only bringing it to macOS, but also extending it greatly. It should be merged into the master branch in the next few days, as the new GUI console is almost finished.

The 0.6.5 version is for Android, and is already being worked on in a separate, private repo. We will merge it with the red/red public repo once it's ready, because we need control on the PR timing and the Android release. It will be a big one, unlike what you've seen so far. ;-)

In the meantime, and as usual, enjoy and have fun!
Fork me on GitHub