Project Ideas for the Google Summer of Code 2014

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 :-) 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...

---

Aapt & Ziptool port for Red Build Chain

Description

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:

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.

Expected outcome

A tested component, written in Rebol/Red, that can provably achieve binary parity with the output of the equivalent Java-tools.

Potential mentor

John Kenyon

Skills and languages required

• Must have a good working familiarity with Java
• Some knowledge of Android development and build process.
• For all Red GSoC projects: Familiarity with a homoiconic language such as Lisp a big plus!

General "difficulty" level

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.

---

Arduino AVR 8-bit / 32-bit Support

Description

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.

Expected outcome

• A new emitter for AVR32, to add to the existing IA32 and ARM emitters.  Would likely build on the current AVR 8-bit prototype code.
• Completion of the AVR 8-bit emitter, if that is determined to be relevant in 2014 (or merely easy enough to keep working).
• An impressive Arduino-based demonstration of the student's choosing, showing Red's dialecting ability (similar to Rebol) applied to the features of the Arduino.

Potential mentor

Bo Lechnowsky

Skills and languages required

• Demonstrated experience in building Arduino-based systems ... documented in webpages or YouTube videos.
• Working understanding of compilers and code generators; ideally having taken a compilers class or would read Compilers: Principles, Techniques, and Tools (the "Dragon Book") in advance of the summer.
• For all Red GSoC projects: Familiarity with a homoiconic language such as Lisp a big plus!

General "difficulty" level

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.

---

Implement Working FreeBSD Build Target

Description

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.

Expected outcome

• First: a version of Red that can run the hello.red application, similar to this demo from Syllable.
• Second: make sure it passes all the 18,000+ unit tests

Potential mentor

Andreas Bolka

Skills and languages required

• Student should preferably be an experienced user of FreeBSD, or be willing to become one prior to starting the project.
• Already basically aware of what PE, Mach-O, and ELF are and how operating systems load program images.
• Comfort with hex editors like fileobj, and a strong stomach for the general ins-and-outs of binary file formats and off-by-4-byte errors.
• Familiarity with FreeBSD's kernel and C library are a plus.
• For all Red GSoC projects: Familiarity with a homoiconic language such as Lisp a big plus...although it would matter a bit less with this than the others.

General "difficulty" level

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.  :-)

---

HTTP and HTTPS Runtime Support for READ and WRITE

Description

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:

    read http://red-lang.org

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.

Expected outcome:

• Red/System code added to the runtime which implemented a handler for when read received something that was url! = type? source.
• Due to the difficulty of writing transport-layer security (TLS) by hand in a C-equivalent language, the expectation would be just to show a basic demo of fetching binary data on Linux, OS/X, Windows, and Android.  (It would be enough to show off retrieving Red's own source from GitHub, which uses HTTPS, for instance.)
• Any time left over after achieving the basic goal could be dedicated to contributing to the design of scheme handlers, as in Rebol.

Potential mentor

Brian Dickens

Skills and languages required

• Must understand Berkeley Sockets, and would not find it too complicated to understand or port an implementation of TLS based in C (which is similar to Red/System)
• Some knowledge of cryptographic hashing, certificates, public key cryptography (hopefully has read Schneier's Applied Cryptography -- or would do so before the project)
• For all Red GSoC projects: Familiarity with a homoiconic language such as Lisp a big plus!

General "difficulty" level

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.

---

JavaScript Emitter and Build Target

Description

While Red will probably continue using bridges to communicate with virtual machines like the JVM and the .NET platform, a native code generator that produces JavaScript is the best idea.  This would be somewhat similar to the way emscripten takes LLVM instructions as input and produces a JavaScript equivalent, but without the need for any external toolchain.

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.

Currently Red/System emitters exist for the ARM architecture and the x86 architecture.  These are embedded into formats like ELF on Linux, Mach-O on OS/X, or PE ("portable executable").  In addition to a JavaScript emitter, there would have to be some kind of packaging produced to get a "runnable" result... such as a webpage with an embedded terminal to interact with the resulting program, or a bridge to node.js.

Expected outcome:

• 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:

    red hello.red -t JavaScript

...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.

Potential mentor

Brian Dickens

Skills and languages required

• JavaScript - the deeper the knowledge, the better
• Working understanding of compilers and code generators; ideally having taken a compilers class or would read Compilers: Principles, Techniques, and Tools (the "Dragon Book") in advance of the summer.
• For all Red GSoC projects: Familiarity with a homoiconic language such as Lisp a big plus!

General "difficulty" level

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

This is a uniquely good opportunity for a student who is well-versed in JavaScript to bring that talent to the Red team.  It is an important task, so much as with the HTTP/HTTPS protocol work, students would need to be prepared for a possible rewrite of the code if deeper design factors needed to be considered.

---

Implement CALL to OS Interface in Red/System

Description

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.

Expected outcome

• The ability to run a CALL command line with implementation parity with Rebol on Linux, Windows, and OS/X.
• Although Android is not particularly shell-based, and antagonistic toward setting executable permissions on files downloaded to /sdcard/, it is possible to run command line programs.  So for bonus points, there could be a story for CALL on Android as well.

Potential mentor

Andreas Bolka

Skills and languages required

• Familiarity with stdin, stdout, stderr and the general nature of what an IOCTL is and what a SYSCALL is.
• The ability to read "Where the printf rubber meets the road" and not want to poke your eyeballs out with a rusty spoon.
• For all Red GSoC projects: Familiarity with a homoiconic language such as Lisp a big plus!

General "difficulty" level

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.

---

UPDATE Mar-2014: 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!