[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...
Issue #14723 has been updated by ko1 (Koichi Sasada).
13 messages
2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
ko1@atdot.net wrote:
[#86791] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:18, Eric Wong wrote:
[#86792] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86793] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:47, Eric Wong wrote:
[#86794] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86814] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
[#86815] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/02
Koichi Sasada <ko1@atdot.net> wrote:
[#86816] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
On 2018/05/02 11:49, Eric Wong wrote:
[#86847] [Ruby trunk Bug#14732] CGI.unescape returns different instance between Ruby 2.3 and 2.4 — me@...
Issue #14732 has been reported by jnchito (Junichi Ito).
3 messages
2018/05/02
[#86860] [Ruby trunk Feature#14723] [WIP] sleepy GC — sam.saffron@...
Issue #14723 has been updated by sam.saffron (Sam Saffron).
6 messages
2018/05/03
[#86862] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/03
sam.saffron@gmail.com wrote:
[#86935] [Ruby trunk Bug#14742] Deadlock when autoloading different constants in the same file from multiple threads — elkenny@...
Issue #14742 has been reported by eugeneius (Eugene Kenny).
5 messages
2018/05/08
[#87030] [Ruby trunk Feature#14757] [PATCH] thread_pthread.c: enable thread caceh by default — normalperson@...
Issue #14757 has been reported by normalperson (Eric Wong).
4 messages
2018/05/15
[#87093] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
3 messages
2018/05/17
[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
9 messages
2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/17
ko1@atdot.net wrote:
[#87166] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/18
Eric Wong <normalperson@yhbt.net> wrote:
[#87486] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/06/13
I wrote:
[ruby-core:86901] [Ruby trunk Feature#14683] IRB with Ripper
From:
aycabta@...
Date:
2018-05-05 10:53:36 UTC
List:
ruby-core #86901
Issue #14683 has been updated by aycabta (aycabta .). I discussed this issue with @hsbt, @matsuda, and @matz . In the present day, IRB needs compatibility completely. - Bundler generates template files of new RubyGems with example console as "bin/console" for development. It uses IRB. Developers of gems can edit the file because it's just template file of customized IRB console. - All Ruby on Rails applications have "rails console" command. - Many users customize .irbrc deeply includes me. Ruby needs a simple REPL as IRB with perfect compatibility. And @matz said that IRB should not be replaced without compatibility in the discussion with me. IRB is still contributing greatly to Ruby's system and we must continue to maintain IRB's compatibility in the future. I think that you'd better develop new Ruby REPL(or shell) without the weighty responsibility of heavy compatibility. If you can provide perfect compatibility for the new version of IRB, please publish the source code of it because I want to contribute. If not, please discuss this issue without the new version of IRB. At RubyKaigi 2018, I'll talk about IRB's new features. http://rubykaigi.org/2018/presentations/aycabta.html So I need a source code of IRB that I can contribute. @keiju san, I watched all your presentations of Ruby shell in RubyKaigi 2014, 2015, and 2017. I'm looking forward to living on your Ruby shell. ---------------------------------------- Feature #14683: IRB with Ripper https://bugs.ruby-lang.org/issues/14683#change-71863 * Author: aycabta (aycabta .) * Status: Assigned * Priority: Normal * Assignee: keiju (Keiju Ishitsuka) * Target version: ---------------------------------------- I replaced lexical analyzer with Ripper. It's important for supporting new syntax. I explain what I did. ## Replace with Ripper I talked with @matz about it and I decided to use mirb of mruby as a reference. https://github.com/mruby/mruby/blob/1905091634a6a2925c911484434448e568330626/mrbgems/mruby-bin-mirb/tools/mirb/mirb.c#L118-L217 The mirb uses compile error messages and token information such as token type and lex_state for that whether or not inputted code continues(and PROMPT_N). I used RubyVM::InstructionSequence#compile and Ripper for the same action. ref. IRB#each_top_level_statement, IRB#lex and IRB#check_code_block ## Continue(PROMPT_N), literal type(PROMPT_S), nesting level(%NNi) IRB needs statuses of code snippets. @nobu implemented it as Ripper's features at irb-ripper branch on GitHub. https://github.com/nobu/ruby/commits/feature/irb-ripper I implemented by pure Ruby because I heard what @nobu thinks pure Ruby implementation for it. I think that it's the best way for that Ripper keeps simple. ref. IRB#process_continue, IRB#process_nesting_level, IRB#check_string_literal and IRB#process_literal_type ## Erase --irb_debug option Because this is just for pure Ruby lexical analyzer. ---Files-------------------------------- irb.patch (51.8 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>