I have.

[core] Automatic-selection mechanism of data structure

MRI use traditional data strucuture. However, we don't need to keep
using them, if compatibility is not broken (Ruby and C level).

Step zero is to consider data structure and computation complexity for
each operations.

Step one is to implement using different data structure and measure it.
There is no data structure to fit everything, so that we can observe
advantages and disadvantages.

Step two is to introduce auto-selection mechanism for programs. We can
change data strucuture dynamically.

(1) Introduce Rope into Sting data

Rope is well-known algorithm to represent String like data structure.
There are advantages and disadvantages.

  s = '....'
  s << x
  s << y # Rope is nice

(2) Array as List/Tree and so on

Ruby doesn't provide List data because Array class has several methods
to use as List. However, we can implement Array class with List data
structure.

  a = [...]
  b = [...]
  c = a + b # making [a, b] is lieghtweight (without copying everything)

(3) Hash data structure

Ruby use st (old-well maintained Hash data structure implementation).
However, many of data structure are known.

This topic is nice for CS students who know algorithms well.


[core] File location data base support

Loading libraries is overhead for invoking ruby interpreter. There are
some bottoleneck. (a) finding file (b) read and parsing file (c)
compiling file (includes optimization).

This project aims to improve performance of (a) by making file location DB.

# pre-compilation for (b) and (c) is nice idea, but they are difficult
# because we need to know iseq data structure deeply and
# I believe that we need to modify it for this purpose.
# Maybe I will touch this area soon.

[core/just idea] improve coverage tool

Improve coverage tool.
Not sure 2 month is enough or not.

I can't be a mentor.

Making continuous coverage site is nice.
mame-san did for ruby 1.9.


[lib] Add Queue features

Queue is a key feature to communicate between threads.

However, there are more space to improve.

  (1) wait for multiple Queues
  (2) Zero sized Queue
  (3) Observe other endpoint
  (4) and more

Maybe implementation is not so difficult. However, considering API is
difficult. At first, they need to survey other langauges.


[lib] Consider non-blocking API

Python 3.4 introduce asyncio suport
<http://www.drdobbs.com/open-source/the-new-asyncio-module-in-python-34-even/240168401>.
Consider how to introduce it in Ruby way.

# but this theme is very difficult, because it
# needs political power to cordinate developers who have opinions.

I can't become a mentor.


----

Just now, I wrote above ideas. When is the deadline for idea proposals?



On 2015/03/10 15:27, Tony Arcieri wrote:
> Hi ruby-core,
> 
> Ruby (via RubyCentral) has been accepted as a Google Summer of Code 2015
> mentoring organization:
> 
> - GSoC site:
> https://www.google-melange.com/gsoc/org/logo/edit/google/gsoc2015/ruby#
> - Mailing List: https://groups.google.com/forum/#!forum/rubygsoc
> 
> We are looking for interesting open source Ruby projects that interested
> students can work on this summer. One very important project for Ruby is
> MRI!
> 
> We are very interested in what ruby-core has to say about the following:
> 
> - Ideas: There is a Google Summer of Code Ideas list where we are
> tracking potential projects. We have posted some ideas for MRI on it,
> but I'm sure you have many more:
> 
> https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List#mri-matz-ruby-interpreter
> 
> - Advice: For MRI projects, we are really interested in ones that
> actually have the potential of being merged into MRI. We do not want to
> make students work on a project that ruby-core thinks is a bad idea,
> because that just wastes everyone's time. If you have any critique of
> the existing ideas on the list and think certain ideas are bad and will
> be rejected from MRI, it would be great to know sooner than later.
> 
> - Mentors: If anyone from ruby-core is willing to mentor students, that
> would be great. Many of these projects require expert-level
> contributions that only members of ruby-core can potentially provide. We
> also think that if ruby-core mentors the projects, it will improve the
> chances of these projects actually being merged into MRI.
> 
> - Students: Last but certainly not least, we are looking for interested
> students to participate in the Ruby Google Summer of Code organization.
> I am guessing some of you know some interested students who might be
> interested in participating, so if you can help recruit them, that'd be
> great!
> 
> Just as an example, we have a student who is interested in working on a
> JIT for MRI/YARV based on LuaJIT. This seems like a project we wouldn't
> accept without an expert-level mentor, and perhaps there is someone on
> ruby-core willing to work with him:
> 
> https://groups.google.com/forum/#!topic/rubygsoc/Qht-GccNTRQ
> 
> -- 
> Tony Arcieri


-- 
// SASADA Koichi at atdot dot net