Forum: Ruby Recipients of Google Summer of Code awards

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 Ziegler

Gregory Brown: Ruby Reports
Mentor: David Pollak

Kevin Clark:  mkmf for Rake
Mentor: Caleb Tennis

Robert Figueiredo: A Ruby Rule-based toolkit
Mentor: Kirk Haines

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

Florian Gross: ruby-breakpoint GUI client
Mentor: Patrick Hurley

Ilmari Heikkinen: Pure-Ruby OpenGL GUI widget systemMentor: Ryan
Leavengood

Jeffrey Hughes: Port Ruby to Symbian OSMentor: Dibya Prakash

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

From: dblack@rubypal.com [mailto:dblack@rubypal.com] On Behalf Of
dblack@wobblini.net
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 (dblack@wobblini.net)

Victor.

On 5/24/06, Victor Shepelev <vshepelev@imho.com.ua> wrote:
> From: dblack@rubypal.com [mailto:dblack@rubypal.com] On Behalf Of
> dblack@wobblini.net
> 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 Brown 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.

From: Gregory Brown [mailto:gregory.t.brown@gmail.com]
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.

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

On Wednesday 24 May 2006 16:47, Victor Shepelev 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

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

On 5/24/06, A. S. Bradbury <asbradbury@tekcentral.org> 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 ;) Then he came back with alternatives like
GlitR and GlamR, hehehe. You could do this all day.

It worked for Flickr.

RyanR

On 5/24/06, Victor Shepelev <vshepelev@imho.com.ua> 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

Ilmari Heikkinen wrote:
> On 5/24/06, Victor Shepelev <vshepelev@imho.com.ua> 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.

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

T.

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?

On 5/26/06, Simen <toalett@gmail.com> 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 :)

Ilmari

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?

Kevin Clark 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 :)

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

About License term,I could find this

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

--Dibya

On 5/27/06, Dibya Prakash <prakash.dibya@gmail.com> 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

Kevin Clark 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?

I'd be happy just to have mkmf not pollute the global space, so it can
be called cleanly from code generators (without using a subprocess).

Going to rake sounds like the right thing to do, but it will require
that rake be installed before you can build extensions. Will rake soon
become part of ruby?

Also, does rake have good enough makedepend functionality yet? ISTR it
does, but that could be an issue...

On 5/27/06, Kevin Clark <kevin.clark@gmail.com> 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

Hi --

On Sat, 27 May 2006, Curt Hibbs 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" :-)


David

Victor Shepelev ha scritto:
> From: dblack@rubypal.com [mailto:dblack@rubypal.com] On Behalf Of
> dblack@wobblini.net
> 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.


for what is worth, I started a blog to keep track of my work, which at
the moment just has a rephrasing of the proposal[1].

Oh, and sorry for answering late, I just resubscribed to ruby-talk, I've
always used c.l.r and I'm experimenting the sadness of the mirror/gw
death :(

Anyway, Being one of the lucky ones, I want to send a big hug to those
left out, I know for sure that there were great people and ideas in the
queue, I hope all of you can get this chance in the next years.
And whenever you come around Rome, You've got a beer waiting.


[1]
http://www.riffraff.info/articles/2006/05/26/summer-of-code-project-blogging

> Oh, and sorry for answering late, I just resubscribed to ruby-talk, I've
> always used c.l.r and I'm experimenting the sadness of the mirror/gw
> death :(

You should be able to pick it up via ruby-talk-google now.

T.

On 5/28/06, gabriele renzi <surrender_it@yahoo.it> wrote:
> for what is worth, I started a blog to keep track of my work, which at
> the moment just has a rephrasing of the proposal[1].
>
> [snip]
>
> [1]
> http://www.riffraff.info/articles/2006/05/26/summer-of-code-project-blogging

On the same note, here's my dev blog:
http://glimr.blogspot.com

transfire@gmail.com ha scritto:
>>Oh, and sorry for answering late, I just resubscribed to ruby-talk, I've
>>always used c.l.r and I'm experimenting the sadness of the mirror/gw
>>death :(
> 
> 
> You should be able to pick it up via ruby-talk-google now.

using gmane.comp.lang.ruby.general and set the mail delivery off, now.
I think it is a nice solution :)