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).
New compilation targets have been provided for Linux and derivative OS running on ARM:
Android support is using the same code as Linux-ARM, only differing in libc and dynamic linker names.
Currently, as Red/System only works on command-line in Android, you need a special loader to download the executable and run it. This can be achieved using the NativeExe app. You will need to allow temporary installing apps from non market sources (Settings > Applications > Unknown sources). Also, your local 3G provider might be filtering out executables downloaded this way, you can workaround that by either manually loading the NativeExe-0.2.apk file with adb, or share a wired Internet connection with your mobile device.
You can easily install NativeExe app by just typing the following URL in your Android web browser:
or by scanning this QR-code instead:
Once done, input in the second field:
http://sidl.fr/red/hello and hit [Run].
Here are a few screenshots of HelloWorld tests:
Andreas has also reported that it’s working fine on Nokia N9 devices.
The next steps to enable building full apps on Android and iOS are:
Such approach will allow us to build easily Android or iOS apps without having to write a single line of Java or Objective-C code, while providing the full power of Red. At least, that’s the theory, we’ll see in practice if it’s up to our expectations. Also, cross-compilation should be fully available for Android (producing Android apps from any OS), but code signing and app publishing requirements might make it impossible for iOS and require a MacOS X with Xcode for producing apps (if you know workarounds, let us know).
The PIC support should be doable in a few days, the support for shared library generation might take a bit more time. Anyway, theses tasks will need to be multiplexed with Red runtime & compiler implementation, so don’t expect significant progress before a month.
In the meantime, you are welcome to test the ARM port of Red/System and hack Android and upcoming Raspberry Pi devices using it. ;-)
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.5% of closed tickets out of a total of 794 tickets so far! We really do care about bug reports.
The first runtime lexer (wrapped by
load function) was implemented a year ago, as a quick hack for the console addition to Red. It was coded in Red/System and supported ASCII inputs only. It was not meant to stay more than a few weeks, but as often in the software world, temporary code lifespan exceeds by far the wishes of the author. The addition of Parse dialect in previous release has opened the possibility of rewriting the Red runtime lexer using the Unicode-aware
parse function. It turned out to be a great design choice and opens even more interesting future options like I/O streaming support (when
parse will support it) or dynamically extending the lexical rules (when loading custom datatypes for example).
The new runtime lexer is now powering the Red console, so we finally have proper Unicode input support!
A help system has also been provided, including the following functions:
source. Try them from the console!
From the console code, the line editing features have been extracted in a different source file that can be now included in your Red programs when you need user input support. For that, two new functions have been provided (working like in Rebol):
Moreover, a new branch was started in order to provide cross-platform line editing capabilities without the burden of external dependencies that have proved to be problematic and limited. The new vt100 version should work fine, but it is unfinished. Contributors with deep terminal coding experience are welcome to help improve the current code. We are aiming at a cross-platform console engine that could be used both in CLI and GUI apps.
absolute, remainder, complement, power, odd’, even’, and, or, xor, reverse
complement’, positive’, negative’, min, max, shift, to-hex
<<, >>, >>>
A new option was added to the
system/interpreted’, that will return
true if the code is run by the interpreter (remember that
do invokes the interpreter until we get JIT-compilation abilities).
load have been extended to accept a
Infix operators can now be created from existing functions or routines.
call function implementation has been contributed by Bruno Anselme with support for both Red and Red/System.
Yes, we got it now! :-) All thanks to Richard Nyberg who kindly provided us with the low-level patches required to make Red work on FreeBSD.
The Red/System lexer used to be simply the
load native from Rebol, which was a great way to speed up the development at the beginning, but was also limitating the syntax to only what Rebol2 accepts. Now the Red/System lexer uses the same code as the Red lexer (the compiler version, not the runtime one), freeing the Red/System syntax from the limitations and making it truly a dialect of Red!
Literal arrays support has been added also in order to facilitate initialization of arrays of value (until we get a first class array! datatype).
CPU registers read/write access has been added. It will be extended in the future to support special registers (like status flags register).
The maximum number of function local variables supported by Red/System was limited to 16, this was limitating also the number of local words that could be used in a Red function. This limitation has now been raised much higher, at least 512 local variables are now allowed.
Object support is already present in this release, but is it not official yet, as it is supported by the interpreter only and not the compiler. Expect quick progress on this front.
The Android GUI support is also under heavy work in the android branch. In order to implement a proper GUI API, the implementation of a VID-like dialect has started, with Android as first back-end. Windows support should follow shortly, then Linux (most probably using GTK+) and finally MacOSX (once we implement the objective-c bridge).
I am not made of rubber, but I can go gear second too! ;-) You may have not noticed, but the project is rapidly growing up in the last months. It is moving faster and on a larger scale as more contributors are joining. We also get better organized. This is the github stats for just this month:
The most important power-up we got was the addition of Xie Qingtian (aka qtxie) to the Red core team. Xie is an amazingly skilled young programmer from China, who is contributing to Red since more than a year now. But the thing is that he is working full time on Red project now, thanks to the kind sponsoring of CSDN and his CEO, Jiang Tao. Xie is the one who implemented all the new functions listed above and in a short amount of time! So consider that from now on, Red will be advancing twice faster thanks to him! ;-)
In order to organize better the work on Red, we are now using extensively Trello as our main task manager tool. The Red tasks board contains three main lists:
Last but not least, the number of visitors on this site and the github repo has, at least, doubled since new year, thanks to an article on CSDN about Red, our Google Summer of Code campaign and the successful StackOverflow ad campaign (finished earlier this month) run by HostileFork, that brought us more than 10k new visitors who clicked the ad, making it the most clicked ad on SO since the new year! The ad is still visible here.
Big thank to all the people that have contributed to this (big) release. Enjoy it! :-)
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. I have spent a great time in Montréal and met with lot of Red and Rebol coders, it was great to meet you IRL and spend a few days with you guys!
Since this version, Red is now able to interface with a 32-bit Java Virtual Machine through JNI, using a dedicated bridge written in Red, including a very small part in Java. This bridge allows Red programs to instantiate Java objects and call their methods from Red directly at run-time.
Instructions for using this bridge and compiling the hello example are given on this page.
Here are some screenshots of the resulting AWT hello app done with the Red/Java bridge:
Red/System runs on Android since more than a year, but we were unable to access the Android API….until now. Thanks to the Red/Java bridge, an Android specific bridge has been made, in order to allow Red to call the whole Android API in Java. This is still alpha stuff, but it works really well, allowing you to build true native Android app in Red, without having to touch any Java code!
This is the hello Red/Android app screenshot, called eval, which simply shows a multiline input field where you can type any Red valid code and run it with the [Do] button. The last expression value gets printed below the button.
You can download the APK file (116KB) with the QR code on the right.
This is a proof of concept. Now that we know that this way works fine, we will continue to improve the bridge and add new layers of abstraction, in order to keep the low-level Java objects hidden as much as possible for the Red coders and replace them with DSLs and Red ports.
In order to build the eval demo app from the sources, just run the build script from a Rebol2 console.
Since a year, we were working on bringing shared library generation, now it is available in the main branch. New features were added to support library generation like a way to declare the exported symbols and special callback functions when loading and freeing the library. Here is a simple example of a Red/System library:
Red/System [ File: %testlib.reds ] inc: func [n [integer!] return: [integer!]][n + 1] #export [inc] You compile such shared library using the new -dlib command-line option: >> do/args %rsc.r "-dlib testlib.reds"
The output binary name will have a platform-specifc suffix (.dll, .so or .dylib).
You can then load this shared library from Red or any other programming language having a good enough FFI. For example, from Red/System, it could be done as simply as:
Red/System [ File: %loadlib.reds ] #import [ "testlib.dll" stdcall [ inc: "inc" [n [integer!] return: [integer!]] ] ] print inc 123
This will print
124 when run.
, any-series', replace, zero'
Functionkeyword now collects counter words from: repeat, foreach, forall.
#callcompilation directive to enable calling Red functions from Red/System.
Red/System got also several improvements:
Android is becoming the dominant OS, so we need to have Red support it as best and as soon as possible. This remains a priority, so improved Android bridge and new sample apps will be available in the next releases. At the same time, we still miss some core features in Red, so these are the new features that you can expect in the next releases of Red:
We are now heading towards the end of the alpha tunnel, if you look well enough, you’ll see the light already. ;-)