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. There’s an opportunity to start getting involved before the summer, and hopefully the students will have a good experience and stay involved after the summer ends!
Though Nenad will be too busy in the [new Beijing Red headquarters](year of horse) :-) to mentor, several members of the Red team have stepped up to volunteer if we are selected. There is of course around-the-clock support in the [Rebol and Red] chat room, but Google needs commitments from specific people to fill out paperwork and reviews. As the project “admin” Nenad should only have to be consulted if there was a disagreement between the student and the mentor (which would not happen!) Of course he would be reviewing any pull request, as with any other code submission.
Google says the best project ideas come from students, which sounds like a good idea. Still, they require a “starter list” of example projects to originate from the potential mentoring organizations. So here is the one we came up with…
The under one-megabyte Red toolchain can output to the ARM instruction set, package an .APK, and soon will have its own JarSigner…requiring no installation of the JDK. Yet two additional pieces will be needed for a completed standalone Red Android toolchain: that is the Android Asset Packaging Tool (“aapt”) and “zipalign” optimization tool:
Android Build Diagrarm
From the Android documentation for zipalign:
Zipalign is an archive alignment tool that provides important optimization to Android application (.apk) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.
Some extended information on the usage of AAPT is available on eLinux.org. Note that we will not be needing the R.java branch of the above diagram in our implementation. But we will be needing to encode the AndroidManifest.xml file into the binary format expected by the APK, as well as the resources.asc file generation.
A tested component, written in Rebol/Red, that can provably achieve binary parity with the output of the equivalent Java-tools.
Although at some level this is “just porting” existing code, it’s a fairly complex piece of code to translate into a language one is to pick up as they went along. Any student undertaking this should be ambitious enough to begin learning the Rebol and Red languages in advance of the summer period.
Preliminary support exists to build Red code to AVR 8-bit, allowing executables to run on Arduino boards. This was largely abandoned, in part because of the belief that 8-bit AVR may not be a relevant focus given AVR32. But also because Red is focused on ARM architectures and Android…so when it comes to embedded boards, favors the Raspberry Pi.
However, the goal is to spread everywhere; and Arduino is still relevant for PWM tasks or handling a lot of inputs and outputs, along with A/D and D/A converters. So this project would be fairly specific for a student who is an Arduino enthusiast, who wants to show what they can make it do with Red.
Getting the AVR32 backend to work is likely not the difficult part of this project, and given the prior work to build on should be achievable in the first month or month and a half.
The harder component is to design a compelling application, and this comes from the student’s choices. Ideally it would be a demonstration of something that an Arduino can do that would not be better done with a Raspberry Pi, justifying the investment in AVR.
Red can compile executables for the major desktop operating systems: Linux, OS/X, Windows. (It also supports some smaller players like Syllable.)
Even though the Red compiler itself is able to run on FreeBSD platforms (due to the properties of its host language), the executables it generates cannot yet do so.
On the one hand, FreeBSD has been an ELF platform for a while and Red already contains emitters for ELF targets. This should require only some minor extension. On the other hand, there’s a few select runtime requirements on the platform’s kernel and/or C library which will need to be adapted for FreeBSD.
There are no FreeBSD users or experts currently among the Red developers, but being able to target FreeBSD would open up Red programs to new audiences and applications.
Certainly it’s possible, since the x86 codegen works in Linux ELF and other compilers generate binaries for FreeBSD.
It might not be that much work, especially for a FreeBSD expert. It would be nice to assume that getting hello.red working would imply passing the test suite would just work. From experiences in the Rebol 3 port, that is not necessarily the case.
Should this turn out to be easy, that’s great. The same skills would probably help making Red build for HaikuOS… so that could be a stretch goal if the BSD port were tied up in the first month. :-)
Rebol-derived languages apply the “code-as-data” paradigm of Lisp, but with a richer set of datatypes. Douglas Crockford (of JSLINT, JSON fame) said of Rebol:
Rebol’s a more modern language, but with some very similar ideas to Lisp, in that it’s all built upon a representation of data which is then executable as programs. But it’s a much richer thing syntactically.
One of those richer pieces of syntax are the multiple string subclasses. e.g. any source code literal starting foo:// will register as a type known as a URL!. The resulting value has the same abilities as a string, but reflection can distinguish it as a distinct subclass. READ and WRITE are polymorphic when sensing their parameter is a URL!, so:
That dispatches to a scheme handler, which returns a binary of the resource at that URL.
The Red runtime needs to have cross-platform implementations of READ (an http “get”) and WRITE (an http “post”). This support should be done for both HTTP and HTTPS, and mimic the basic support of TCP/TLS in Rebol.
Hard – particularly because the importance of this component means it will be under high scrutiny. A working implementation may wind up being treated as exploratory work, possibly receiving a complete overhaul afterward.
Even the basics could be highly challenging for a 3 month project, especially to get it working on all the platforms Red targets. Scaled-back goals–such as seeing it working on Linux only for starters–would be made if progress seemed to be stalled.
On the other hand, due to the fact that the task is mission-critical, it would command a lot of attention from the team to help make it happen. A talented contributor could wind up becoming an integral part of the project after GSoC, if they stayed on to enhance it.
The Red compiler generates code into an IL (intermediate language) called Red/System. Red/System has a compatible syntactic structure to Red, but with lower-level semantics… more similar to C than Rebol. It is possible to embed Red/System code into a Red program, or to code in it directly without using the higher-level Red at all.
Another emitter JS added to the directory where there is currently an ARM and IA32. (Note: AVR is experimental, not in main branch): https://github.com/red/red/tree/master/system/targets A new cross-compilation target. Existing targets are MSDOS, Windows, Linux, Linux-ARM, Darwin, Syllable, Android, Android-x86.
Users should be able to type:
…and be given back a runnable result. For starters this could be invoked via node.js, but if time remained it could be enhanced and packaged as a complete webpage.
Medium. Making this task somewhat easier than it might otherwise be is that emitters for the ARM and x86 architectures already exist to study and model after. Also, since compiling to JS is a hot topic right now, there is the ability to borrow from prior art used in things like asm.js
In Rebol, it is possible to call out to the OS shell:
USAGE: CALL cmd /input in /output out /error err /wait /console /shell /info /show DESCRIPTION: Executes a shell command to run another process. CALL is a native value. ARGUMENTS: cmd -- The shell command or file (Type: string file block) REFINEMENTS: /input -- Redirects in to stdin in -- (Type: any-string port file url none) /output -- Redirects stdout to out out -- (Type: string port file url none) /error -- Redirects stderr to err err -- (Type: string port file url none) /wait -- Runs command and waits for exit /console -- Runs command with I/O redirected to console /shell -- Forces command to be run from shell /info -- Return process information object /show -- Show the output in a console window
The Red runtime needs a similar mechanism that works cross-platform. Because the Red runtime is written in Red/System (a C-like language which has access to–among other things– syscall on Linux) it should be possible to mimic the behavior.
Probably not too hard to achieve in 3 months for either the POSIX Linux+OS/X or Win32. Yet to do both in three months could be a challenge. Priority would be given to POSIX in that case… then Windows. As mentioned, finding a story for Android as deemed applicable would be an interesting bonus.
We unfortunately weren’t selected this year. That’s understandable as a relatively new project without high profile organizational usage. But we thank Google for their consideration, and for their sponsorship of open-source development.
On the plus side, the work of putting these ideas together wasn’t time wasted. What was the “GSoC Ideas Trello” has been renamed and is now the Ideas For Red Contributors Trello! We’re going to be expanding it with projects that might range longer or shorter than 3 months of summer, and which may require skills a college student wouldn’t be expected to have.
So go take a look at that! And if you haven’t gotten a chance to look at our contributions page, please do… and hopefully you can make time to watch the overview video (now subtitled!) It may inspire you to think of a part of the project that you find interesting that we did not come up with.
Also, do come talk to us on StackOverflow chat or tweet us at @red_lang with your ideas!