Apr 2019 Meeting

calendar_today April 21, 2019 Source English

DevelopersMeeting before/after RubyKaigi2019

RubyKaigi 2019 will be at Fukuoka, Apr 18th to 20th 2019. It should be good time to gather Ruby interpreter developers. I keep the meeting space at Fukuoka city, near to the Hakata station (the central station in Fukuoka) before and after RubyKaigi.

  • Date:
    • 2019/04/17 (Wed), before RubyKaigi2019
    • 2019/04/21 (Sun), after RubyKaigi2019
  • Location
    • Fukuoka Ruby Content Industry Promotion Center, Fukuoka Higashi Sougouchousha 5th floor, 1 Chome-17-1 Hakataekihigashi, Hakata Ward, Fukuoka
    • 福岡県Ruby・コンテンツ産業振興センター (in Japanese) http://frac.jp/about/ (Japanese page)

There are two days but Matz can only attend Wednesday.

Maybe on Wednesday we can have a meeting with agenda, for example about Ruby 3.

I’m not sure we need Sunday meetup, but I keep a room for people who want to continue development. If nobody attend Sunday meetup, I’ll cancel room reservation.

I hope we can discuss topics on Wed and continue to discuss RubyKaigi days, and make a progress on Sunday.

Travel support

Same as last RubyKaigi, Cookpad Inc. will support travel fee (except hotel room fee) so please consider to attend this dev-meeting. Also please invite people who are not a MRI committer but who are important person to talk with us. I’ll announce about this travel support soon.

Registration

  • Sign-up on https://rubyassociation.doorkeeper.jp/events/85108

Call for Topics

  • Please comment discussion topics on Wed meeting.
  • We have limited time to discuss, so that I’ll ask Matz which topics we should talk with, and make time schedule in advance if there are many topics.
  • Meeting room has a projector so you can bring your slides.
  • Maybe attendee’s topics will be prioritize.

Conclusion

Anyway, please keep your schedule. FYI: Fukuoka city does not have enough hotel rooms so I recommend you to keep your rooms as soon as possible.

Thanks, Koichi

Before

Log

Date: 2019/04/17 (Wed)

Time: 13:00-18:30 (JST)

Place: Fukuoka Ruby Content Industry Promotion Center (Fukuoka, Japan)

https://bugs.ruby-lang.org/issues/15459

Logs

Next dev-meeting

About 2.7 timeframe

Agenda

  • 13:30-14:00 (1) keyword arguments progress report [#14183] (mame)

  • Mame: Presentation of problems and issues. Testing of strict implementation shows many incompatibilities.
  • Jeremy Evans: More compatible proposal, same as mame, but backwards compatible for methods that don’t accept keyword arguments.
  • Mame: We need a gradual migration path for Ruby 3.0 with appropriate warnings in 2.x.

  • Eregon: What is the value of having “strings” as keyword argument keys?

  • ActiveRecord/Sequel could use it.

  • It’s only valid as part of a splat, there is no syntax for accepting a “string” key as an explicit keyword argument.

  • Matz: Is there any way to specify that we don’t accept any keyword arguments?

  • What should the syntax be?

  • Headius: How do we handle mixed symbols and strings?

  • Currently it’s split - symbol keys become keywords and string keys become positional hash argument. We don’t think that’s good behaviour.

  • The model for keyword arguments is difficult for JRuby to replicate because there are too many edge cases. (headius)

  • Agreed it’s very complex logic to handle them (eregon)

  • 14:00-14:30 (2) static checking progress report [#?????] (mame)

  • Mame: Add side-car file for type annotations (.rbi)

  • Single implementation “type profiler” made by mame.

  • Provide type warnings by analysing library code and application code for incompatibilities.

  • Should the type annotations be edited by human or only generated by program?

  • Mame: So far it’s only generated by computer program.

  • Jeremy: Could the type profiler be used to generate the type signature of the application code?

  • Mame: It depends on use case.

  • Jeremy: Can we write test to check for error conditions? E.g. can we test that type errors occur?

  • Mame: Yes it should be possible but needs more work.

  • Can you handle “Integer String”

  • Mame: Yes it’s possible [demo from slides].

  • How should we use type profiler?

  • Mame: By using type profiler you can find more errors than testing alone [e.g. typo in untested branch].

  • Can we test refinements? What other limitations are there?

  • ko1: It’s not possible to test refinements and there are other edge cases that are impossible, e.g. singleton class. But it does support class method.

  • What about anonymous classes and e.g., Struct subclasses? (eregon)

  • 14:30-15:00 (3) pattern matching [#14912] (k_tsj)

  • Kazuki: Presentation of general idea and implementation.

  • Matz: I think this feature is useful for future of Ruby language, and even there are some corner cases, but those issues can be resolved.

  • When I give a presentation about pattern matching at RubyHack keynote, some people want to have the pattern matching in method overloading. Considering that, we might need to think about the method overloading syntax w.r.t. The “in” keyword in pattern matching. That’s my only concern about the current proposal.

  • ioquatix: What happens if you have “when” clause in the same case statement?

  • Kazuki: It is a syntax error.

  • ioquatix: What is the execution order? Is it from top to bottom?

  • Kazuki: It’s top to bottom.
  • ioquatix: Will this make it hard to optimize in the future? Can the compiler/interpreter generate an efficient tree structure for matching?

  • headius: There are too many side effects by method execution.

  • 15:00-15:30 break

  • 15:30-16:00 (4) new built-in class/method definition (ko1)

  • Koichi: Presentation of problems and implementation. Introduction of new FFI features to call C functions, including “invokecfunc” opcode. Discussion of optimisation strategies. Startup time overhead mitigated by improved lazy loading of compiled Ruby code.

  • Eregon: Similar to Rubinius and TruffleRuby “primitives”

  • headius: Doesn’t the JIT do this? Where do the C names come from?

  • The names are manually defined right now but perhaps it can be defined by “comment” in C source code.

  • Eregon: If we have more of the core written in Ruby, we can share more of it between implementations.
  • Eregon: a nice improvement over current __foo methods in prelude.rb :)

  • Do we need to be concerned about MRI specific code being used in an unorthodox way?

  • Koichi: We can add a warning comment at the top of the file?

  • NOTE (eregon): TruffleRuby already does presizing of method tables by require-ing all core library Ruby files ahead-of-time, and serializing the (Java) heap in the produced binary.

  • Re adding context to C API, is it an occasion to clean up the API? (eregon)

  • 16:00-16:30 (5) concurrency (matz)

  • Matz: Presentation about CPU bottleneck and I/O bottleneck. JIT address CPU bottleneck.

  • What about providing a lower level construct such as “Thread.selector” rather than a high level implementation (AutoFiber). Trade-off between proposing unified high-level model and flexibility of multiple ways to do IO concurrency (eregon, TODO: comment on the issue tracker).

  • https://github.com/ruby/ruby/pull/1870

  • On JRuby, with parallelism, is there any point to implement Guild or is it a no-op?

  • We did implement it using Thread on JRuby and it just worked.

  • Matz: It is not for the VM implementation but for the users.

  • 16:30-17:00 break

  • 17:00-18:00 (6) RubyVM [#15752] + numbered parameters [#15708] (eregon)

  • Presentation about RubyVM namespace issues. How to handle experimental features.

  • Many new methods are implemented directly. What should go under proposed “ExperimentalFeatures”?

  • Where should we put RubyVM.resolve_feature_path(path)?

  • Should a.map{ e e.sum} behave the same as a.map{@1.sum}?

  • Matz: We need more time to consider it.

  • 18:00- other remaining topics