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
on 24.05.2006 17:41
on 24.05.2006 17:48
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 24.05.2006 18:08
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.
on 24.05.2006 18:24
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.
on 24.05.2006 20:49
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 24.05.2006 22:57
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
on 24.05.2006 23:04
These all sound like really cool projects. I can't wait until the fall :)
on 25.05.2006 01:31
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 25.05.2006 17:35
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
on 25.05.2006 23:33
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.
on 26.05.2006 05:04
Have you back read mail archives on the topic or Ruby GUI? Things like Wise, Alph, Rouge and GUtopIa may be of interest. T.
on 26.05.2006 12:45
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 26.05.2006 18:53
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
on 27.05.2006 04:53
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?
on 27.05.2006 16:19
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 :)
on 27.05.2006 16:48
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
on 27.05.2006 16:57
About License term,I could find this http://code.google.com/soc/mentorfaq.html#licenses --Dibya
on 27.05.2006 19:59
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
on 27.05.2006 20:36
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 27.05.2006 20:55
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
on 27.05.2006 23:34
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
on 28.05.2006 02:13
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
on 28.05.2006 11:13
> 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 28.05.2006 11:22
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
on 29.05.2006 23:47
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 :)