It has been almost a year since our last blog post. Sorry about that. It’s one of those things that falls off our radar without a person dedicated to it, and we run lean so don’t have anyone filling that role right now. We know it’s important, even if we have many other channels where people can get information. So here we are. Last year was a tough year all around, even for us.
Posts categorized as "update"
In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to solve that. They act as the GOSUB directive from Basic language. They are defined as a separate block of code inside a function’s body and are called like regular functions (but without any arguments).
A programming language lexer is the part in charge of converting textual code representation into a structured memory representation. In Red, it is accomplished by the load function, which calls the lower-level transcode native. Until now, Red was relying on a lexer entirely written using the Parse dialect. Though, the parsing rules were constructed to be easily maintained and not for performance. Rewriting those rules to speed them up could have been possible, but rewriting the lexer entirely in Red/System would give the ultimate performance.
It’s been a busy start to the year for the team. Work has continued on many fronts, and we have some new team members helping us to keep the momentum going. We announced in January that GTK and the Fast Lexer were close, and they are even closer now. The hard part about making announcements is that some of this work is unpredictable and changes in scope after we do. Or the world steps in and a pandemic throws a wrench into your plans.
Hello and happy new year, friends of Red! We have some exciting projects we’ve been working on that will be available this year, including a new product. Let’s talk a little about what the team has been working on behind the scenes. (TL;DR: A cool new product with Red in 2020…plus, a robust preliminary draft of Parse documentation can now be previewed…CLI library…fast-lexer to merge soon…GTK on the horizon…and a new native OS calendar widget!
Welcome to December, friends of Red. It's an intent and focused time of year as we wind down 2019, and the core team is making important moves (sometimes literally!) to set us up for an ambitious 2020. But first, here are just a few things that happened in November. First and foremost, it's always great when community members help compile resources for use by others, and we'd like to acknowledge @rebolek for his excellent compendium of historic automatic builds: https://rebolek.
What made the fast-lexer branch a priority? Several things. It started when @dockimbel looked into ticket #3606, which was impossible to fix currently, and we didn't want to give up on the auto-syncing between /text and /data facets. So he had to consider bigger options, including how to make the lexer instrumentable. It was not easy, because the current lexer is not re-entrant, so having the lexer emit events to a callback function could have caused serious problems.
Over the last few weeks the Red Lang core team drilled down to make some truly great progress on Red's fast-lexer branch--while we also gained valuable support from the contributions of Red doers and makers as they consolidate a world of useful information and resources. Fast-Lexer Benchmarks In the fast-lexer branch of Red, you can see lots of new work from Red creator @dockimbel (Nenad Rakocevic) and core teammate @qxtie.
Hello to all the great makers, doers and creative people who are using Red, helping the Red Language grow and improve! As always, there's a standing invitation for you to join us on Gitter, Telegram or Github (if you haven't already) to ask questions and tell us about your Red-powered projects. Here are some recent highlights we’d like to share with you: 1. Tickets Get Priority In the last month, our core team has closed a large number of tickets.
We are releasing today the version 0.4.0 of the RED Wallet with several major new features. As a reminder, the RED Wallet aims to be a simple and very secure wallet for the major cryptocurrencies (BTC, ETH, and ERC-20 tokens). Safety is enforced through the mandatory use of a hardware key (Ledger or Trezor keys), which protects against any failure of the wallet app (being it a bug or an attacker).
As part of the R&D work on port! datatype in port-type branch, we have implemented a GPIO driver for Raspberry Pi boards, as a gpio:// scheme (no third-party library needed). This work helped define the low-level API for ports written in purely Red/System or a mix of Red and Red/System. The Raspberry Pi is a very popular board with millions of units sold, so this is a market where Red could be potentially helpful to developers.
If you are an active member of the Red community, you will have likely been keeping track of Red's progress through our Gitter rooms and Github repositories, but we wanted to officially bring everyone up to speed with a shiny new blog post. The team has been busy since January on many fronts, multiplexing its efforts on many different branches of development. Here is an overview of what we have been cooking and what is coming.
Stepping-up 2019 started with continued advances in the main development branch, implementation of features, and triage of pending tickets. For example, smart merging of a style's actors with the actors of a particular face instance was introduced in the VID dialect. Example: view [ style my-button: base on-down [face/color: face/color / 2 do-actor face event 'click] on-up [face/color: face/color * 2] my-button "Say hi!" red on-click [print "hi"] ] But this is just a tiny drop in the January ocean, and nothing special in the grand scheme of things.
It’s been a long time coming. While work on Red has progressed every day, work on the blockchain aspects of the project, and their associated logistics, came at a time when that workload temporarily prevented us from making new, formal/stable releases. There was a key feature that needed to be in place, and it wasn’t a small one. Thanks for bearing with us! Fixes and features kept rolling out on a regular basis, so most active community members were not affected by the lack of a fresh new “official” release.
Happy November, Red community! We’ve been very busy. Beginning in September, Nenad and Qingtian joined Gregg in Idaho for 6 weeks, in preparation for Ethereum DevCon 4, and to set some things in motion for a possible U.S. Red presence. Challenges continued to appear at every turn, which kept us on our toes. By the end of October, we were ready to hit Prague for the DevCon, and to have our first Mini RedCon with some of the team.
Hello REDucers! Our mission to fight software complexity is going to be showcased alongside Ethereum’s Devcon IV in Prague. If you’re in the neighborhood, stop by Redcon! What’s Redcon about? Redcon is for anyone interested in open-source, full-stack, domain-specific languages built using Red Language or any of its dialects. We’ll be having a casual meetup-style event, with food and adult beverages. Who will be there? Red’s designer, Nenad Rakocevic, will discuss the language and its capabilities.
Thank you for your patience. With all the other work going on, we’ve been juggling priorities. But now, at long last, it’s time for an updated Red Wallet. There are still a lot of pieces in progress for future releases, but this version adds some key upgrades. If you missed the original wallet announcement, here’s a short feature list from that: Secure ETH and RED token transactions. Support for the world’s leading hardware key: the Ledger Nano S.
Happy Tuesday everyone! @lucindamichele here. I’d like to thank everyone who responded on-list and off to our questions about yourselves. It is a big help for us, because our goal is to make Red as responsive to your needs as possible. While our due date has passed, you can still send your responses to myself or Gregg privately, and I can append them to our sheets. Our set of questions is appended at the end of this update.
Here is a short video overview of the implemented features so far for Red/View backend on Android: The source code for that Android test app is available here. Implemented features so far: New java bridge for Android Full set of Red/View widgets supported (some still require extra work) Draw & Shape dialects fully supported Compatibility with Android GUI themes Device-independent coordinate system Updated APK building toolchain for targeting API 23+ Android systems Improved ARM backend, support for ARMv7+ Android OS support ranges from 5.
RED Wallet: the tiny, simple, fast and secure wallet! We are proud to announce the release of the first alpha of the RED Wallet, our secure wallet app for the Ethereum network! The source code was released more than two months ago, and since then, the wallet has been used daily by the Red Team and contributors. We are now providing prebuilt binaries for easier access by the general public. The RED Wallet is one of the most secure crypto-wallets in the world, as it requires a hardware key to run.
As you know already, the RED token (Red Community Token) has been listed on some exchanges (KKcoin, Xstar, ddex.io), so far using a RED/ETH pair, but those exchanges are small and do not provide a lot of liquidity. We now have the opportunity to get the RED token listed on a bigger reputable exchange, Bibox, which ranks 17th on CoinMarketCap. In this case, listing approval is a crowd voting process, that will be used for the first time by Bibox.
After our successful token sale, we are making some changes to our old Red development roadmap. 0.6.4 release We are merging the 0.6.4 branch into master today. There are still some features to add and polish, so we plan to release it in about a week. We are still considering a 0.6.5 milestone for swapping the REPL and the toolchain thus making the Red console the new Red executable. If we cannot fit the required changes for that into 0.
We set up the Red Foundation structure at the beginning of January in Paris, France. The Red Foundation is kindly hosted by the EPHE, at the Human and Artificial Cognition research unit led by François Jouen (author of the famous RedCV framework, among other image-processing related projects for Red). For a brief overview, the Red Foundation structure is composed of several teams: an administrative team: Nenad Rakocevic, President
Another goal of our trip in California was to visit Carl Sassenrath, creator of Rebol, and spiritual grandfather of Red, as Red is the offspring of the Rebol language. We had a great time with Carl and his wife Cindy, discussing Red and Rebol syntax & semantics, the blockchain industry, smart contracts and the opportunities it presents for our technologies, while enjoying a good Italian restaurant and excellent red wine (selected by Carl, of course!
For those eager to get some fresh news from Red, here are some great news items that we are sure you will appreciate a lot. As there are many different topics to talk about, we are splitting the news over several articles that we will publish over several days. This is the first part. Together with Gregg Irwin, the Red community leader, who joined us from Idaho, we had a memorable time in SF, and the trip was successful beyond our wildest expectations!
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.
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.
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:
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
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.
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.
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](red gui system). 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](eve style clock demo) 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:
It is with great pleasure that we announce the 0.6.2 release of the Red programming language and toolchain. This release is the second heaviest one we have ever made (after the 0.6.0), weighing about 1200 commits! It was intended initially to be a minor one, but the needs for preprocessing support for Red runtime code arose, so it was the right time to make a first iteration into the land of macros.
A few days ago, Nicky Case released an amazing piece of work in form of an interactive guide to alternative voting systems. This work follows the track of Brett Victor’s famous research on explorable explanations and immediately caught our eyes because it is a very good match for the capabilities of our reactive native GUI system. We decided to replicate some of Nicky’s interactive explanations in Red and see how it goes.
In Rebol languages family, macros have been a topic every now and then, and despite one implementation offered, they never became mainstream. Rebol language, being homoiconic, comes already well-equipped for code transformations at run-time with minimal effort. For example, this short script: code: [print "hello"] code: reduce [code] insert code [loop 2] probe code do code when evaluated will output: [loop 2 [print "hello"]] hello hello For a more sophisticated example, see our GUI live-coding in just a few lines.
Like many others, we are fans of Chris Granger’s work on Lighttable and more recently on Eve. The Eve project shares some similar goals with Red, though taking a different road by giving a new try at visual programming, while Red still tries to push further the limits of textual representation. A few days ago, the Eve team tweeted a nice small clock demo using their framework. Here is our own version of that demo using Red and our native reactive GUI (Eve relies on a web engine):
After the release of our reactive framework a few days ago, we though it would be a good idea to implement the, often mentioned, spreadsheet model as a small demo, just to see how much it would take to do it in Red, with its current feature-set. Well, despite not having a grid component, it turns out that 17 LOC (of packed, but still readable code; down to 14 LOC and 1053 bytes if minified) is enough to make a spreadsheet-like demo with native widgets and realtime updating of dependent cells as-you-type!
Despite being a minor release, 0.6.1 still weighs a heavy 588 commits with a big number of fixes and many additions, among which the new reactive framework is the most notable. Last release introduced, for the first time in the Rebol world, a reactive programming framework, as a part of the GUI engine. While working on improving it, we realized that it could actually be easily generalized beyond GUIs, with just minor changes to its design and implementation.
Five years ago, when I started writing the first lines of code of what would become later the Red/System compiler, I had a pretty good picture already of what I wanted to achieve with Red, and all the ideal features that should be included, just not sure how much time and efforts it would require to have them. Two years and half ago, baby Red printed its first output. And today, we celebrate a major step forward with the addition of a brand new GUI system entirely written in Red itself!
Features, future directions Will Red get lisp like macros? The short answer is: yes, but…. We first need to define how we want the API for macros to look like and how to prevent users from shooting themselves in the foot too easily using them. Also, macros are challenging for a visual debugger, we also need first to have a clear vision of how an IDE would handle that (I have not yet looked into how top Lisp IDE managed that, though I hope they have solved it elegantly).
This new version turned out to be a major release, given the vast number of new features which made their way into it. Hope it was worth the waiting. ;-) In preparation for the GUI support and the DSL that will come with it, a new range of datatypes has been implemented. Pair! datatype A pair is a couple of integer! values used to represent mainly dimensions and coordinates. Its literal representation separates the two integers by an x character.
The main point of this minor release is to speed up compilation time by introducing a new way for the compiler to store Red values required for constructing the environment during the runtime library startup. Introducing Redbin Red already provides two text-oriented serialization formats, following the base Rebol principles. Here are the available serialization formats now in Red with some pros/cons: MOLD format provides a default readable text format, very close to the source code version cannot properly encode many values MOLD/ALL format
This is minor release mainly motivated by the need to fix some annoying issues and regressions we have encountered in the last release: the help function was displaying an error when used with no arguments, preventing newcomers from seeing the general help information the console pre-compilation issue with timezones was back. Some significant new features managed to sneak into this release too, along with some bugfixes.
This new release brings many new features, improvements and some bugfixes that will make Red more usable, especially for newcomers. The initial intent for this release was just to replace the existing console implementation, but it looked like the right time to finally implement also proper general error handling support. New console engine The old console code we were using so far for the Red REPL was never meant to last that long, but as usual in software development, temporary solutions tend to become more permanent than planned.
Today is a big day for the Red team and all the Red followers. After four years of hard work on building our dream tool, I announce today the creation of a new company, Fullstack Technologies. The company has raised $500,000 from InnovationWorks and GeekFounders, Chinese VC early-stage investors. This money will help us fuel the launch of Red this year, and spread it everywhere, especially in the mobile market. The mission of Fullstack Technologies is to provide to individual developers and corporations, a simpler and much more productive software creation solution, reducing drastically both costs and development time.
I would like to share some notes about how some of the object features were implemented in the Red compiler. As these are probably the most complex parts in the Red toolchain right now, I thought that it would be worth documenting them a bit, as it can be useful to current and future code contributors. Shadow objects and functions Reminder: the Red toolchain is currently written entirely in Rebol.
We are bumping the version number up higher as we are bringing a new foundational layer and important construct to Red: object! datatype and contexts support. Supporting objects in the Red interpreter is relatively easy and straightforward. But adding those features in the compiler has proven to be more complex than expected, especially for access-path support, paths being especially tricky to process, given their highly dynamic nature. Though, I have pushed Red beyond the edges I was planning to stop at for objects support, and the result so far is really exciting!
After a long time having only partial floating point support in Red/System, it comes now to Red with a broader support, thanks to the terrific work from Qtxie and Oldes, who managed to push Red further while I was busy moving from Europe to China (though, this might be the topic for another blog entry, as requested by many of you). The new float! datatype implements IEEE-754 64-bit floating point format.
This long awaited new release is now available. As I have been travelling a lot in the last months, this release has been delayed much more than I wanted. Anyway, we managed to achieve a really big amount of work, as shown by the 500+ commits since previous release and the 75 fixes over 210 new tickets opened. As usual, we strive to keep the number of opened tickets (especially bug reports) as low as possible, achieving 97.
Red has been ramping up its recruiting efforts in 2014. So far in January, we’ve done very well with our open-source recruitment campaign on StackOverflow. Now in February, we are throwing our hat into the ring to be a mentoring organization for Google’s Summer of Code: If you haven’t heard about Summer of Code, it pairs college students with mentors who represent an open source project. The students work remotely and are paid a stipend… and they are expected to complete a measurable goal in the 3 months that they have.
One of the greatest feature of the Rebol language has always been its parsing engine, simply called Parse. It is an amazing piece of design from Carl Sassenrath, that spared all Rebol users for the last 15 years, from the pain of having to use the famously unmaintainable regexps. Now, Parse is also available to Red users, in an enhanced version! So, in short, what is Parse? It is an embedded DSL (we call them “dialects” in the Rebol world) for parsing input series using grammar rules.
What’s that?! As we are getting closer to the end of the alpha period, we are now moving to a more convenient way to use and distribute the Red toolchain. So far, you needed to download a Rebol interpreter and the sources from Github separately, and run it using, a bit verbose, command-lines. This is fine for developping Red with contributors that are interested in the inner workings of the toolchain, but for the end users, the goal has always been to provide a simpler and much more convenient way, like Rebol teached us in the past.
This new release took a while, first because a lot of work was done since the last release, about 390 new commits were added and 44 issues were fixed over 80 new tickets opened since the last release. But it was also delayed because, a month ago, I was invited at Recode 2013 developer conference to give a talk and present the latest advancements on Red. I would like to thank again people that donated to cover the costs of my trip, Brian “HostileFork” Dickens and Coginov in the first place, and all the others that have contributed.
Time has finally come to release the new REPL for Red. A preview version has been pushed last Christmas, since then a lot of work has been done on several fronts (about 310 new commits, excluding merges): interpreter (DO), runtime lexer (LOAD) and console. But before going into details for the REPL, here is an overview of the changes in this new release: New datatypes: routine!, issue!, file!
At the beginning of this new year, I took a moment to look at the work we did since the first public commit of Red. Even if I am a perfectionist that is never satisfied with its own work, I must admit we did a quite incredible job so far. In two years we built not one but two programming languages: Red/System which is in beta state and usable to make real world apps, and Red which is in alpha state and evolving at very fast pace.
We have all waited long for this to happen, but it is finally there: first Red alpha release! This is the biggest milestone since the initial release of Red System, as it marks the entrance of the higher layer of the Red software stack. There’s still another layer pending, the JIT compiler, but that’s for 2013, when Red will be self-hosted. What Red can do so far? So what happened since the first Red compiler release a little more than a month ago?
Red is growing up fast, even if just born two weeks ago! It is time we implement basic string support so we can do our first, real, hello-word. ;-) Red strings will natively support Unicode. In order to achieve that in an efficient and cross-platform way, we need a good plan. Here is the list of Unicode native formats used by our main target platforms API: Windows : UTF-16 Linux : UTF-8 MacOSX/Cocoa : UTF-16 MacOSX/Darwin : UTF-8 Java : UTF-16 .
Yesterday, I finally got my first real Red program compiling and running: Red  print 1 This doesn’t look like much but it proves that the whole current Red stack is working properly. Red compiler generates Red/System code in memory, that is then compiled to native code and linked in a 14KB executable file (contains the full Red runtime with currently 9 datatypes partially implemented). The baby needs a few more days in the nursery before I commit the new code to the v0.
The need for more structured code support has arisen with the addition of bigger and more sophisticated bindings like GTK one or the (soon to be released) work on alpha version of Red compiler (which emits Red/System code). So, v0.2.6 introduces namespaces support using a very simple, but efficient model. For example, to encapsulate some variables and functions in a local context: b: 1 a: context [ b: 2 inc: func [i [integer!
EDIT (March 8, 2014): Updated for the 1.6.0 QEMU version. The recent release of the Raspberry Pi board raised a new wave of interest for the ARM platforms. As Red/System is already running on ARMv5+ platforms, a number of Red followers might want to test it on these platforms, so this article aims at giving you a quick way to setup a QEMU emulator for ARM and install a Debian GNU/Linux on top of it.
This is a mainly a bug fixing release with several issues and bugs in float numbers handling solved. In addition to that: Libc is now much better integrated with Red/System, the __libc_start_main C internal initialization function is now correctly handled by Red/System on all supported platforms. This ensures that all libraries relying heavily on C will now work as well as if called from a C program. Thanks to Andreas for the nights spent on digging and debugging that.
New Red/System version 0.2.4 is out. The main new feature is floating point numbers support. This feature was not planned, but as users were strongly pushing for having it now, we have added partial support for floats. Users can now wrap and use libraries like OpenGL. New floating point datatypes Two new IEEE-754 datatypes were added: float64! datatype implements double precision (64-bit) floating point numbers. It has an alias named float!
We are pleased to announce that Red/System v0.2.3 is out, extending Red to the mobile world with a complete support for Linux on ARMv5+ processors. The new port supports 100% of Red/System features and passes successfully the 8537 unit tests. For those of you interested in more details, our ARM port targets the v5 family, with 32-bit instructions (no Thumb support) and optional literals pools (use -l or –literal-pool command-line option when compiling) that implement a global allocation strategy (unlike gcc’s function-local allocations).
This release is mainly a bugfix release that solves several old issues. It is also now correctly synchronized with all the current bindings done for Red/System. The main changes are: Internal compiler refactoring of: expressions compilation, type casting and ANY/ALL support. Greatly improved runtime error reporting: now it reports both source line number and source file name where the error occured. It works in debug mode only (-g command-line option).
I have been invited at the Software Freedom Day 2011 (September 14th) to give a talk about Red. Here are the presentation slides and the video. I am not a great speaker, so you might want to go through the slides first, and eventually have a look at my corresponding comments in the video (it is too long anyway). I need to make shorter and faster presentations in the future.
This new release is bringing a lot of important bug fixes and some new features for Red/System. The new PRINT function might break some existing scripts, but should be easily fixable. New features Variable-arguments function support RTTI function limited support Polymorphic and variadic PRINT function Command-line arguments access Added stack low-level manipulation native functions: push, pop Access to stack pointer and stack frame pointer (reading/writing)
Red/System Mac OS X port is now completed and on par with Windows and Linux ports. The new Mach-O file emitter supports all current Red/System’s features including #syscall and #import directives. Now that all major 3 OS are supported, I can say that the Mac OS X file ABI and function call ABI are really the most complicated one to support from scratch, the Windows one (PE/COFF) being the simplest (with its own set of oddities, but simpler) and Linux’s ELF somewhere in between.
This is a major milestone reached on the Red roadmap. Red/System is now in a beta state, which means that it is good enough, both in design and implementation to be used for building applications. A huge collective effort has been made by all contributors to reach that state during June, in a single month, we produced: 190 new commits (total = 354 now), more in a month than in the three previous ones!
Three months have passed since Red has gone public. It seems short, but a lot happened since then and I wanted to sum up the work accomplished for the people interested in Red that don’t have the time to follow the progress daily on every channel. Development Red/System is implemented at 98% ~2600 unit tests were created (thanks to Peter WA Wood) Red/System language specification draft added, now close to 95% of completion Code base almost doubled: 60KB to 110KB (~3200 LOC) 164 commits on Github, 44 by contributors 4600+ page views on Github’s Red repository Main new features New datatypes: byte!
I will present Red language and the Cheyenne Web Server at Lille (France) on May, 28 to a group of REBOL and Red users. The presentations will be done in french, but if some none-french speakers want to come, I will try to do it both in french and english. Detailed information to get there are available in this thread from RebelBB forum. See you there on Saturday!
Source Navigation As requested by several users, I am giving a little more insights on the Red/System compiler inner workings and a map for navigating in the source code. Current Red/System source tree: red-system/ %compiler.r ; Main compiler code, loads everything else %emitter.r ; Target code emitter abstract layer %linker.r ; Format files loader %rsc.r ; Compiler's front-end for standalone usage formats/ ; Contains all supported executable formats %PE.r ; Windows PE/COFF file format emitter %ELF.
Here is a quick update on Red/System progress. Specifications Draft Draft has gone through several revisions. Several decisions mainly regarding pointers handling have been taken with simplification and disambiguation as main goals: Struct! values are now passed by reference (a syntax for passing by value will be added in future), simple arithmetic (+, -) can be used on struct references. String! was renamed to c-string! to avoid possible future collision with a Unicode-aware string!
I have published yesterday the first draft of Red/System’s specifications. It is amazing how much time and energy writing such formal description can take. It is a working draft, so expect it to be updated often during next weeks. The document source is in MakeDoc format and stored on github, so feel free to fix typos and errors directly there. As all features in the specifications are not yet implemented (I would say 85% is already done), I have added a todo-list on github’s wiki to track the missing parts.
A week after the first alpha release of Red/System compiler for Windows, we now have a working Linux/ELF support, thanks to Andreas help in deciphering the ELF format. Currently only syscalls are available, the dynamic library linking part is pending, it should be added before the end of March. The following Red/System “hello world” script: Red/System [ Purpose: "hello world script" ] print "Hello World!" compiles to a 162 bytes ELF binary, while a similar C code would produce a 5-6KB binary using Gcc…pretty good, no?