Recipients of Google Summer of Code awards


#1

Hello everyone –

On behalf of Ruby Central, the mentoring organization, I am very
pleased indeed to announce the students who have been
awarded grants through the Google Summer of Code program for 2006.

First, I’d like to express our deep thanks to all the students who
applied, and to all the mentor volunteers. Everyone put in a lot of
time on preparing and/or ranking applications, and the pool of
applications as well as the roster of mentors was impressive. I hope
that those of you who did not receive funding this year will
nonetheless come back next year and apply.

The students who have been awarded grants by Google, along with their
project titles and names of their mentors, are:

Alexander Stephen Bradbury: Automated Wrapper Generation
for Information Extraction
Mentor: Austin Z.

Gregory B.: Ruby Reports
Mentor: David P.

Kevin C.: mkmf for Rake
Mentor: Caleb T.

Robert Figueiredo: A Ruby Rule-based toolkit
Mentor: Kirk H.

Benjamin G.: Improved style and extendable interactive
documentation system for Ruby and Rails
Mentor: James Edward G. II

Florian G.: ruby-breakpoint GUI client
Mentor: Patrick H.

Ilmari H.: Pure-Ruby OpenGL GUI widget systemMentor: Ryan
Leavengood

Jeffrey Hughes: Port Ruby to Symbian OSMentor: Dibya P.

Jason Morrison: Code Completion with Type Inference
for Ruby Development Tools project
Mentor: Christopher Williams

Gabriele Renzi: New Administration subsystem for nitro
Mentor: Bryan Soto


#2

From: removed_email_address@domain.invalid [mailto:removed_email_address@domain.invalid] On Behalf Of
removed_email_address@domain.invalid
Sent: Wednesday, May 24, 2006 6:39 PM

The students who have been awarded grants by Google, along with their
project titles and names of their mentors, are:

Are somewhere detailed description for all those projects? Some sound a
bit
confusingly.

David A. Black (removed_email_address@domain.invalid)

Victor.


#3

On 5/24/06, Victor S. removed_email_address@domain.invalid wrote:

From: removed_email_address@domain.invalid [mailto:removed_email_address@domain.invalid] On Behalf Of
removed_email_address@domain.invalid
Sent: Wednesday, May 24, 2006 6:39 PM

The students who have been awarded grants by Google, along with their
project titles and names of their mentors, are:

Are somewhere detailed description for all those projects? Some sound a bit
confusingly.

Here is my full proposal, for those interested:

anyone with further questions is invited to carry discussions over to
the ruport mailing list:
http://lists.stonecode.org/listinfo.cgi/ruport-stonecode.org

Proposal for the continued development of Ruby Reports.

Project Background:

The Ruby Reports library has been actively developed since July
2005. The goal is to build a high quality reporting engine for Ruby
applications. It currently provides tools for data acquisition,
database interacting, formatting, and parsing/munging. Though it has
progressed over the last 10 months, work on it has been part time at
best, thus making growth of the library rather slow.

Developer Background:

Gregory B. has been active in the Ruby community since late 2004
and has worked on the HighLine library (http://highline.rubyforge.org)
and the Gambit library (http://gambit.rubyforge.org) [ Made possible
by ruby central ]

Previous to working in Ruby, Gregory was working in Perl throughout hi
highschool years.

He is currently an O’ReillyNet Ruby blogger, a member of the Artima
Ruby Code & Style Advisory Board, and an active member of the RubyTalk
community.

Gregory is a member of the NYC.rb and the new_haven.rb groups, the
latter of which he helped establish.

Goals:

Though Ruby Reports (Ruport) is still in alpha status, it has
acquired thousands of downloads and a surprising amount of developer
feedback. One of the most common requests is integration with the
Ruby on Rails framework, and with sufficient resources, this would be
a top priority for Ruport.

Another major priority for Ruby Reports is unifying the many
excellent formatting toolsets available in the Ruby community into a
single toolset. It is very common to require reports in a number of
formats, be they html, pdf, plain text, csv, excel, or many others.
Ruport will be expanded to make this easy for the developer to deal
with. Work has already begun to integrate with RedCloth, PDF::Writer,
and FasterCSV, with expansions of these formats and new format support
on the horizon.

Still, the most important part of Ruby Reports is data manipulation.
The goal is to be able to compare data from an eclectic set of data
sources with minimal headaches. Implementing data structures which
will support things like calculated fields in tabular data, summary
reports of datasets, combinations of data from different sources, and
other advanced manipulations are a very high priority.

Summary:

Ruby Reports does not aim to re-invent the many wonderful libraries
and frameworks which already exist in the Ruby community. It simply
aims to bring the sort of integration techniques which caused Ruby on
Rails to be such a success on the web development front to the
reporting world. Through linking an easily extendable formatting
toolset with strong data manipulation tools, and then providing
integration with one of the most popular frameworks in the Ruby
community, Ruport can become a very helpful piece of software for
those who are building reporting applications, be they ad-hoc or
robust.


#4

Gregory B. wrote:

Here is my full proposal, for those interested:

I’ve attached mine to this mail as well. I hope we can get all this
information organized somewhere. Some of the other projects sound very
interesting and I’d really like to read about them in more detail.


#5

From: Gregory B. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday, May 24, 2006 7:08 PM

Here is my full proposal, for those interested:

anyone with further questions is invited to carry discussions over to
the ruport mailing list:
http://lists.stonecode.org/listinfo.cgi/ruport-stonecode.org

[skip]

Thanks Gregory!

V.


#6

These all sound like really cool projects. I can’t wait until the fall
:slight_smile:


#7

On 5/24/06, A. S. Bradbury removed_email_address@domain.invalid wrote:

What would you call a wrapper generator/information extractor written in Ruby?
the name shouldn’t indicate the library is (x)html/web-specific (it won’t be,
although I think that is one of the most compelling use cases), and anything
about wrapper generation is probably going to make most people think of SWIG.

I consider myself good at naming, so I’ll bite. How about MineR?
FiltR? ScanR? DeduceR?

Mines are used to extract stuff (like rubies.) Filters are used to
extract coffee and tea. Of course filters already have a connotation
in computing which may not exactly match up with this project.
Scanning can involve extracting information. Deducing as well.

Hmm, there is already a miner project on RubyForge…grrr. Filtr,
scanr and deducer are available though.

FYI, I’m really into these end in R names. I’m the mentor for Ilmari
Heikkinen who is writing an OpenGL widget system for SoC, and I just
suggested he call it GlimR :wink: Then he came back with alternatives like
GlitR and GlamR, hehehe. You could do this all day.

It worked for Flickr.

RyanR


#8

On Wednesday 24 May 2006 16:47, Victor S. wrote:

Are somewhere detailed description for all those projects? Some sound a bit
confusingly.
Victor.

My snappily titled proposal “Automated Wrapper Generation for
Information
Extraction” has been accepted. I hope you’ll find it’s a lot more
interesting
than it might sound. A potentially suitable description would be “a web
scraper that writes itself”. Tools like RubyfulSoup go a long way
towards
making it easy to extract data from the web, but I believe in many cases
we
can go one step further. My library will take labeled examples, and
generate
extraction rules.

This is actually a topic that has received quite a lot of attention in
academic circles (search for some of the keywords from my proposal
title).
Despite the existence of several excellent papers detailing useful and
highly
successful approaches to the problem, the FOSS community doesn’t seem to
have
any libraries that make it easy to extract data in this way. Clearly,
I’m
hoping to harness existing research and apply it to improve that
situation.
I’ll write detailed documentation of my approach later on, it’s
important
people can understand what’s going on behind the scenes. For now, my
first
problem is what to name the project. Has anyone any smart ideas?

What would you call a wrapper generator/information extractor written in
Ruby?
the name shouldn’t indicate the library is (x)html/web-specific (it
won’t be,
although I think that is one of the most compelling use cases), and
anything
about wrapper generation is probably going to make most people think of
SWIG.

Alex


#9

Ilmari H. wrote:

On 5/24/06, Victor S. removed_email_address@domain.invalid wrote:

Are somewhere detailed description for all those projects?

Here’s my project description:

Sounds really interesting, good luck with that. I’ve been hoping someone
would do something like this.


#10

Have you back read mail archives on the topic or Ruby GUI? Things like
Wise, Alph, Rouge and GUtopIa may be of interest.

T.


#11

On 5/24/06, Victor S. removed_email_address@domain.invalid wrote:

Are somewhere detailed description for all those projects?

Here’s my project description:

What am I proposing?

Writing a pure-Ruby GUI widget system using OpenGL with the
following goals:
- usable on its own (using GLUT or SDL to create windows)
- embeddable in other OpenGL applications written in Ruby (e.g.
games)
- cross-platform
- extendable using Ruby
- usable API
- themeable

The widget system would be usually used as an overlay layer, drawn
on top of the underlying frame[1].

Why do I feel this is important?

Problems this project aims to solve:
- There is no Ruby widget set that would work inside your OpenGL
application and provide decent building blocks for writing GUIs.
- Writing new widgets usually requires hacking in C, and you don’t
get the graphics power of OpenGL.
- If you want to add a menu or a couple of options checkboxes and
tabs to an OpenGL game written in Ruby, you either need to write
your own widgets, embed your game engine into a system like GTK,
or create bindings to a GUI library like CEGUI[2].

So, in a nutshell, this project would:
- create a vehicle for GUI research
- provide a simple cross-platform GUI toolkit
- speed up game development with Ruby

What am I going to deliver?

A documented set of basic widgets, a layout manager and a theming
system. The widget set would be tested to work on Linux, Windows and
Mac OS X, and packaged as a gem.

The basic widget set would include windows, text inputs, scroll
bars, menus, lists, checkboxes, radio buttons and pushbuttons.

The layout manager would have an absolute positioning mode, and
horizontal and vertical layouts.

Themes would be done by changing the bitmap images of the theme,
with more extensive customization if there is time. To test the
theming functionality, there is need to make a couple of themes.

How am I planning to do this?

If this proposal is accepted, I’m going to work full-time on it for
the full duration of Summer of Code.

I’m planning to extract the basic rendering bits from my librend[3]
rendering library, then create scenegraph nodes for doing the layout
and widget drawing. This should take roughly 2-3 weeks, including
tests and documentation. By the end of the first week, I should have
the simplest widgets together (toggles, buttons, labels, lists.) The
second week would be doing a simple text editing widget, scroll
bars, and windows. Third week or the end of the second week would go
to extracting the functionality from librend and making it into a
stand-alone system.

After having the functionality nailed down, the next phase would be
making it portable, which will likely take a week or two. This would
include testing the library on Windows and Mac OS X, and working
around the inevitable differences in their preferred ways of getting
texture data.

Creating a gem and making it install correctly on the different
platforms should take from a day to a week. Since I haven’t created
gems before, this phase may well gravitate towards the one week
mark.

The remaining time would go to some combination of: making up for
delays in the previous phases (most likely), making the API
friendly, writing better documentation, polishing the test themes,
optimizing the slowest parts of the rendering path (e.g. redraw only
when changed, cache windows to textures), and extending the
functionality (one can always hope).

Time permitting, I would also like to explore automatically
generating GUI forms for objects and method calls, perhaps aiding
efforts to create a Morphic-like GUI in Ruby[4,5]. This will have to
wait until completing the widget set project, though.

References:

[1] Overlay GUI:
http://librend.rubyforge.org/screenshots/prelim_widgets.png
[2] CEGUI: http://www.cegui.org.uk/
[3] Librend: http://librend.rubyforge.org/
[4] Morphic: http://minnow.cc.gatech.edu/squeak/30
[5] The Inertia project: http://www.mike-austin.com/inertia/index.html


#12

On 5/26/06, Simen removed_email_address@domain.invalid wrote:

transfire wrote:

Have you back read mail archives on the topic or Ruby GUI? Things like
Wise, Alph, Rouge and GUtopIa may be of interest.

T.

I have. I got the impression they were all noble projects that never
resulted in anything. Are any of those projects still alive?

That was my thought as well.
What I’m doing isn’t that big or ambitious, just something for writing
quick apps, game menus and new GUI widgets.

But, writing a library before apps is a bit like trying to make reality
fit math. So I’m trying to be boring with it until I can use it to write
some
small app and get a reality check :slight_smile:

Ilmari


#13

unknown wrote:

Have you back read mail archives on the topic or Ruby GUI? Things like
Wise, Alph, Rouge and GUtopIa may be of interest.

T.

I have. I got the impression they were all noble projects that never
resulted in anything. Are any of those projects still alive?


#14

Hi guys,
I’m Kevin. I haven’t been active on ruby-talk in the past, but you might
know me from my blog, http://glu.ttono.us.

Anyway, mkmf is a pain. It’s ugly and can’t be reused easily. I want to
write the equivalent for Rake in a clean, well tested, modular fashion
so that it can be reused by other projects like RubyGems.

Since it will use rake instead of make, longer term goals include adding
support for generating RDoc.

I could use suggestions for what people want out of this. What do you
hate about mkmf? What do you like about it? What sort of things could be
improved?


#15

One the SoC project page for Ruby it states that the prefered license
for
these projects was GPL. What is the reason for this, was it required by
Google?

I would have expected the prefered license to be the Ruby license, or
MIT,
or BSD, or some such.

Curt


#16

Kevin C. wrote:

I could use suggestions for what people want out of this. What do you
hate about mkmf? What do you like about it? What sort of things could be
improved?

Cross-compiling support for one would be awesome.
Basicly it should be as easy as pointing a different rbconfig.rb file
for it, like rake CONFIG=otherconf.rb build …

Good luck with the project :slight_smile:


#17

About License term,I could find this

http://code.google.com/soc/mentorfaq.html#licenses

–Dibya


#18

On 5/27/06, Dibya P. removed_email_address@domain.invalid wrote:

About License term,I could find this

http://code.google.com/soc/mentorfaq.html#licenses

–Dibya

http://www.opensource.org/licenses/mit-license.php

OSI says MIT is fine. I prefer MIT myself. Is there a problem with me
using it instead of the GPL?
Kev


#19

On 5/27/06, Kevin C. removed_email_address@domain.invalid wrote:

using it instead of the GPL?
I have discussed this with my student and we are either going to
choose an MIT-style license or the Ruby license terms.

-austin


#20

Hi –

On Sat, 27 May 2006, Curt H. wrote:

One the SoC project page for Ruby it states that the prefered license for
these projects was GPL. What is the reason for this, was it required by
Google?

I would have expected the prefered license to be the Ruby license, or MIT,
or BSD, or some such.

The reason was that it was the closest thing I could find to the Ruby
license (i.e., it’s one of the options in the dual license) on the
drop-down menu from which I had to choose… So it’s really
shorthand for “the Ruby dual license, of which only this half was
available to me to select” :slight_smile:

David