[ruby-core:68618] Re: Looking for MRI projects for Ruby Google Summer of Code 2015

On 2015-03-10 08:12:47 +0000, SASADA Koichi said:

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

Hi. I'm a fourth year student of Department of Computer Science. I'm 
interested in contributing to ruby-core regardless of Google Summer of 
Code (GSoC), but GSoC can be a good motivation to me.

Indeed I would like to dig and to get detail of 'Automatic-selection 
mechanism of data structure'. or where can I get information? (opened 
issue, paper if exists?) If you are okay, can I also get detail of 
'file location database support'?  FYI, Mentees should submit a project 
proposal due to March 27 at 19:00 UTC if ruby-core team accepts these 
ideas as GSoC project.

regards, 
--
Chulju Hong