Fork me on GitHub

February 6, 2014

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:

Android Build Diagrarm

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

15 comments:

  1. Thank you for this great blog entry Brian.

    I consider this work proof that the Red project is a Google SoC project worthy.
    Really hope Red gets more attention and even more momentum in the already amazing progress this fine community gives it.

    ReplyDelete
  2. Contributing to Red, the first full-stack language, would be a great asset to anyone's resume. I enjoy using Red because it reminds me of programming in the 80's, back when programming was fun. In those days, we were the masters of our computers. Well, we still can be with the help of Red and Red/System!

    For instance, I think it amazing that it's possible to write a complete surveillance camera solution, from the embedded hardware that captures and processes the video to the user interface running on Windows/Mac/Android that allows review of the captured and processed video.

    ReplyDelete
  3. All listed projects sound interesting! I wish some students will apply!

    ReplyDelete
  4. Red is arguably the most mouth-watering language project out there—drawing from the rich vocabulary of Rebol and applying it to every level of software development, it pries open the murky depths of hardware and OS operations making it accessible to us mere mortals.

    While any one of the above proposals would bring us closer to realizing Red, I fancy that a prospective student would have a field day on whatever aspect of the project captures their imagination.

    ReplyDelete
  5. Were I a younger man.... nice list!

    ReplyDelete
  6. Great work on the ideas list guys! I especially would like to see the aapt/ziptool task taken by some skilled students. Also the Arduino backends would be very cool to have.

    ReplyDelete
  7. It is an exciting opportunity to work on building a beautiful language which has so many remarkably simple and powerful concepts in such a concise and understandable package.

    ReplyDelete
  8. Uh, as a student interested in compiler implementation and low-level programming some of this project are really fascinating. The fact that i don' t know Red ( but i could learn ) could be a decisive malus xD ? How can i try to comunicate with mentors before applying ?

    ReplyDelete
  9. As a child of the 70's and 80's, I find Red promises the same kind of satisfaction you used to get when the number of tools needed to be understood was minimal and the programming environment was comprehensible by mere mortals. On top of this, to get such a flexible (homoiconic, expressive, targeting multiple hardware/software platforms) language as your playground, well, how can anyone who loves programming resist getting involved?

    Contributing to the language at this stage gives so many opportunities to show a wide variety of skills that any serious comp-sci student should seriously consider it, for the future fame, glory, and satisfaction that will come.

    ReplyDelete
  10. @Andrea We won't know for a bit whether Google will choose us as a mentoring organization. Regardless of that, you can come learn about Red and speak to the potential mentors on the StackOverflow chat:

    http://chat.stackoverflow.com/rooms/291/rebol-and-red

    As mentioned above, StackOverflow's anti-spam policy is to require 20 points of reputation. Easy to get if you don't have it, and their Q&A system is the best I know of as of 2014...so definitely worth knowing about!

    ReplyDelete
  11. Unfortunately the Red project was not selected by the Google commission. Maybe next year. If Red development still progresses at its current pace, there will be a complete new list of possible projects needed.
    I think it was a good effort to try this application. Learned a lot and have a set of clear and achievable goals. No time for moarning, time for action!

    ReplyDelete
  12. A plea for rationality, standards, simplicity, minimalism and almost infinite (or close enough) customization for the Red GUI using "one" library . I propose that Scalable Vector Graphics SVG be used for the interface. Why?
    SVG is a World Wide Web Consortium (W3C) since standard 1999.
    Tiny SVG is being used on numerous handheld devices for the GUI and is also a standard. Yeah I know I said one library. You may need the tiny for phones and small handheld devices.
    Tiny SVG being a subset could be used first so as to get something up that works fast and will always be available in the future. SVG full specs could be added later.
    All platforms with a browser have SVG built in. For those that don't, libraries are available. Here's one as an example. A search brings up many and I'll bet many more will be written in the future.

    http://snapsvg.io/

    It's only 1.7MB. I looked at the download for GTK+ for windows and including the dependencies it's a whoppin 29.4 MB zipped. So you go from less than 2MB for Rebol to a huge monster.
    If you use GTK+ what are you going to do for accelerated video drivers? GTK+ will ALWAYS lag behind on driver support and you will always have a slow, dragging interface. How many people do you know that program video drivers for free? I would be surprised if there were a hundred on planet earth that do so. If the computer you use has a browser then it will probably have built in drivers for the video card. The faster the computer industry moves the more important this will become.
    SVG will have tons of free documentation because it's a web standard. Here's a link to a free book. Chapter 1 is great to read to understand my reasoning for using SVG.

    SVG Programming: The Graphical Web by Kurt Cagle
    http://www.perfectxml.com/apress/SVG/

    SVG is based on primitives like the old Rebol AGG library. I know it's not exactly the same but I bet SVG functions will in most cases strongly overlap AGG functions.
    SVG being something like postscript can be truly be versatile. The styles and effects are endless.
    SVG styles could be done by mortals. No need for C++. People of average intelligence could use text files to change their display like XML or HTML.
    SVG is not going to go away or implode. It will always be there. Some minimal SVG will be around at least for the lifetimes of all reading this. GTK+ will change and cause enormous headaches to keep the GUI up to date.
    SVG is designed for links and buttons to be included in the document/GUI, there are event handlers built in for these links.
    Another really big point is it's not "canvas"(canvas is another (W3C) standard for GUI or interactive webpages). People seem excited about canvas but a sore point in canvas is "you" have to keep track of where all the buttons and active elements of your interface are. For example if you change the scale somehow on the GUI and don't take account of it then someone may press a button and nothing happens because your monitoring a different point. Keeping up with all this would get to be a big headache. In SVG the element/button/selector/whatever is tied to the picture representation of it so no matter where it moves you still get the info/click/whatever from it. I think this is extremely important and a huge anti-bug/frustration feature.

    Of course I could be wrong, missed some salient fact and what Red needs is a 50 MB GTK+ and 100MB library for Windows and a 100MB library for Mac and etc...

    Thank you for all the work you're doing. I believe it's important.

    ReplyDelete
  13. Happened to run across the page describing the difference between canvas and SVG.

    http://en.wikipedia.org/wiki/Canvas_element#Canvas_versus_Scalable_Vector_Graphics_.28SVG.29

    ReplyDelete
  14. Hi Sam,

    Thank you for caring enough about Red to write a long proposition. :-)

    First, let me explain that GTK+ is a not what we intend to use for the default Red GUI backend on platforms where it is not part of the OS. The plan is to rely on the native GUI API on each platform.

    We care a lot about our runtime size, so even 1.7MB is just too big for us. Also, that is the size of the zipped JS package for SnapSVG, so it also relies on several MB of libs that, are provided by the browsers. Supporting in Red a SVG parser and renderer is probably more like a 10MB+ cost, so not an option for us. Compared to that, the AGG payload is less than 200KB.

    Another point: standards are good, but a XML-based solution is just too resource-hungry by our own standards.

    I am perfectly aware of the differences between a raster-based engine and a vector-based one. What I would like to find is a vector-based lib, pretty much like AGG, but more modern, with hardware acceleration support in the 100KB-200KB range. If we don't find anything suitable, we might end up building our own one, probably using the native APIs as backends.

    Thanks again for your inputs.

    ReplyDelete
  15. "...I am perfectly aware of the differences between a raster-based engine and a vector-based one..."
    I think you might have misinterpreted my intentions so I will formally state that you are two magnitudes smarter than I am. No intention was meant to troll or in any way say you don't know what your doing. Only added the post to...ehh...complete my thoughts and make the SVG vs. Canvas info complete.

    Thanks for your valiant efforts.

    ReplyDelete