From: Chulju Hong Date: 2015-03-24T01:55:57+09:00 Subject: [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 > . > > 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