Developers Meeting 2013-01-15¶

This meeting will be held on 2013-01-15 at 15:00 Pacific Time at irc://chat.freenode.net/#ruby-implementers.

EN <=> JA translations will be done on demand in #ruby-ja on ircnet

Attendees¶

MRI¶

tenderlove (Aaron Patterson)
matz
kosaki
eregon
sorah
marcandre (Marc-André Lafortune)
duerst (Martin Dürst)
shugo
emboss (Martin Boßlet)

Rubinius¶

evan
dbussink
brixen

JRuby¶

headius
enebo

MagLev¶

phlebas (Tim Felgentreff)

MacRuby¶

jballanc (Joshua Ballanco)

Moderator¶

drbrain (Eric Hodel)

Agenda¶

We'll keep this meeting to one hour long.

Introduction (tenderlove)
Refinements
- Experimental feature?
- Other issues after scope reduction
Keyword Arguments
- #7662, #7663, and #7664
Isolated binding specifier (jballanc)
Open Floor
Wrap Up

Summary¶

Refinements¶

They are officially an experimental feature (no other impl needs them)
JRuby's current implementation is an earlier form of the spec
Currently refinements can be used without a require
Using refinements will cause a warning (even without -w)

Conclusion¶

Wiki and tests are updated with latest spec

https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/RefinementsSpec

The goal for "non-experimental" status is by Ruby 2.1

Open Questions¶

Can we have a dummy require that enables refinements?

Keyword Arguments¶

Should be documented in doc/syntax (but needs review)
People want non-optional keyword arguments

Conclusion¶

No issues on current kw args from implementers, but people want non-optional args.

Action Items¶

headius opened a ticket for non-optional args, #7701
Add examples of non-optional args "in the wild" to his ticket

Isolated Binding Specifier¶

A new binding specifier defined here: #6710
Binding semantics are not well defined
Some things should not be allowed
- Changing values of locals in someone else's binding
Maintaining MRI compatibility hinders perf, difficult to implement
Secure datastructures can be inadvertently exposed
Maybe we should remove Proc#binding?
Security shouldn't be a motivator (because everything is exposed in ObjectSpace)
Isolated binding could be used for moving Procs between processes
- No binding means we could marshal a proc

Conclusion¶

More than just "isolated" binding is desired

Action¶

Move discussion for more features to "isolated" redmine ticket

Open Floor¶

New "Common Ruby" project
```
https://bugs.ruby-lang.org/projects/common-ruby
```
- Should we actively put new features there?
- We need to publicize it as "where new language features go"
Issue #7564 needs review from matz
- Matz said "I will see"

IRC Log¶

15:00 ferrous26: tenderlove: you did?
15:01 tenderlove: I did!
15:01 drbrain: If you don't have voice and are a ruby
      implementer please /msg me or tenderlove
15:01 ferrous26: cool, thanks!
15:01 tenderlove: :-)
15:01 drbrain: tenderlove will be starting with the
      introduction
15:01 shugomaeda: Is matz here?
15:01 drbrain: if you wish to comment please say "!"
15:01 drbrain: please limit your comments to 2 minutes
15:01 zenspider: waves
15:01 drbrain: I will give priority to people who haven't
      spoken on the topic
15:02 drbrain: see the /topic for the agenda
15:02 headius: might help pacing to prepare your comment in a
      separate buffer and then paste it, btw
15:02 headius: so we're not waiting on typing too much
15:02 tenderlove: I guess we're waiting on matz?
15:02 drbrain: I will cut off new "!" at 45 to 50 minutes
      into the meeting to keep this to one hour
15:04 tenderlove: it seems we have more people participating
      than are in the wiki
15:05 tenderlove: add your name and email address here:
15:05 tenderlove:
      https://gist.github.com/2c3b41ed83e5d062f636
15:05 drbrain: and IRC nick
15:05 tenderlove: I'll send out a survey after we're done so
      that we can improve the meeting!
15:05 tenderlove: yes, and IRC nick
15:05 tenderlove: (I'll add the nick to the attendees list in
      the wiki but not your email address)
15:05 matz_: Sorry to be late
15:06 tenderlove: no problem
15:06 tenderlove: drbrain: shall we start?
15:06 drbrain: tenderlove: please start
15:06 tenderlove: thanks for coming everyone
15:06 tenderlove: like I was saying earlier, it seems we have
      more people attending than in the attendee list on the
      wiki
15:07 tenderlove: so if you're not on this list, please
      comment with your name, email, and IRC:
15:07 tenderlove:
      https://gist.github.com/2c3b41ed83e5d062f636
15:07 tenderlove: (IRC nick)
15:07 tenderlove: I'll add the nicks to the wiki, and use
      your email for a survey afterword
15:07 tenderlove: so we'll stick to 1 hour
15:07 tenderlove: So first on the agenda is refinements
15:08 tenderlove: AFAIK, they are now experimental?
15:08 tenderlove: what are the details of this?
15:08 tenderlove: end
15:08 tenderlove: maybe shugomaeda can talk about it?
15:08 drbrain: oh, and finish your comment with "end"
      please
15:08 shugomaeda: !
15:08 drbrain: shugomaeda: ok
15:08 shugomaeda: I believe they are experimental
15:08 shugomaeda: end
15:08 matz_: It's experimental, so that other implementation
      has no obligation.
15:09 tenderlove: lol
15:09 headius: !
15:09 drbrain: headius: ok
15:09 tenderlove: !
15:09 headius: I went around and around on the refinements
      issue a lot, so I've seen many different forms
15:09 headius: I believe in the end what we decided was that
      there were still too many questions and changes
      happening to force it into 2.0, so it's marked
      experimental
15:09 shugomaeda: !
15:09 headius: I'm not sure which is the current form,
      though…and I have neglected to implement any of the
      later forms in JRuby yet, but that is on my
      roadmap
15:10 headius: end
15:10 drbrain: tenderlove: ok
15:10 tenderlove: when we say experimental, does that mean
      that we have to "opt-in"?  or is there a warning?
15:10 tenderlove: how do users know that it's
      experimental?
15:10 tenderlove: end
15:10 drbrain: shugomaeda: ok
15:10 shugomaeda: headius: currently, refinements are enabled
      by default, but a warning shown. Is it OK?
15:11 shugomaeda: end
15:11 headius: do I answer directly or ! again? :)
15:11 drbrain: headius: ok
15:11 tenderlove: lol
15:11 drbrain: it's ok to answer directly
15:11 headius: That seems acceptable to me…I would have liked
      to have an opt-in like require 'refinements' but I
      understand the difficulty of doing a lexical feature
      that's optional
15:11 headius: is the wiki up-to-date with the current
      impl?
15:12 headius: and tests
15:12 tenderlove: shugomaeda: does that mean you need to run
      with `-w` to see the warning?
15:12 headius: end
15:12 shugomaeda: !
15:12 tenderlove: sorry :(
15:12 drbrain: shugomaeda: ok
15:12 shugomaeda: tenderlove: a warnging is shown without
      -w
15:12 shugomaeda: headius: wiki and tests are up-to-date with
      the current impl
15:12 jballanc: !
15:12 shugomaeda: end
15:12 drbrain: jballanc: ok
15:13 jballanc: would it be possible to have a dummy
      require?
15:13 headius: shugomaeda: (sidebar) thank you…I will base
      JRuby impl on that
15:13 shugomaeda: !
15:13 jballanc: or should we do like we currently do with
      fork and throw?
15:13 jballanc: end
15:13 tenderlove: (here is the refinement page:
      https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/RefinementsSpec)
15:13 drbrain: shugomaeda: ok
15:13 shugomaeda: jballanc: i guess it's possible if
      permitted by matz
15:14 headius: !
15:14 shugomaeda: like marshal.so
15:14 shugomaeda: end
15:14 drbrain: headius: ok
15:14 headius: If anyone has continuing concerns about the
      feature, I strongly reccommend voicing them on the
      bug
15:14 headius: and this means actual reasons why you don't
      like it, things you would like to see changed, etc,
      rather than just "this sucks, don't do it"
15:14 headius: end
15:15 drbrain: is there anything else outstanding for
      refinements?
15:15 headius: oh, I have one ?
15:15 drbrain: headius: ok
15:15 headius: matz_: is the intent to finalize these for
      2.1? or a put a different way…how much time do we have
      to finalize refinements?
15:15 dbussink: !
15:16 drbrain: dbussink: ok
15:16 drbrain: oops, I assume headius is done?
15:16 dbussink: On refinements, since the feature is
15:16 dbussink: experimental does that mean we still keep the
      possibility open of removing them if they don't work
      out?
15:16 headius: yeah just asked the question… end
15:16 dbussink: and if so, what would be criteria we would
      judge the feature on?
15:16 dbussink: end
15:16 drbrain: matz_: ?
15:17 matz_: The 2.0 refinement spec is minimal. I believe we
      have no further issue here.
15:17 matz_: But I admit I am not perfect, so that there
      might be holes in the spec.
15:17 matz_: I'd like to have time to see them.
15:18 zenspider: !
15:18 dbussink: matz_: so that means the answer would be that
      they will not be removed from now on?
15:18 matz_: dbussink: I don't think I am going to remove
      refinement.
15:18 matz_: end
15:18 drbrain: zenspider: ok
15:19 zenspider: I'd like to see the wiki page expanded
      defining backtraces, debugging, and any other means of
      figuring out where behavior is coming from / defined.

15:19 zenspider: end
15:19 drbrain: shugomaeda: matz_: any comment?
15:19 headius: !
15:19 drbrain: headius: ok
15:20 headius: I have not had a chance to review latest
      version of this in wiki, but I stand by assertions that
      refinenements affecting methods not defined in their
      scope like #method, #send, and so on is a bad
      idea
15:20 zenspider: (esp from outside the refinement)
15:20 headius: I believe most of that was backed off for 2.0
      spec
15:20 shugomaeda: !
15:20 headius: I'd support having some additional utility
      methods for reflective stuff from within refinement
      that don't affect existing methods
15:21 headius: mostly because existing methods should behave
      like they do now without having to guess about active
      refinements
15:21 headius: end
15:21 drbrain: shugomaeda: ok
15:21 drbrain: (I think we should move on to the next topic
      soon)
15:21 shugomaeda: The wiki says "Any indirect method access
      such as Kernel#send, Kernel#method, and
      Kernel#respond_to? shall not honor refinements in the
      caller context during method lookup."
15:21 shugomaeda: end
15:21 headius: thank you
15:22 headius: my question about timing of making it
      non-experimental is still open
15:22 drbrain: matz_: ?
15:22 headius: I mostly just want to know how long we have to
      discuss and "refine" the feature
15:22 zenspider: !
15:22 matz_: My goal is 2.1, but you know, we are open
      source.  We don't have exact roadmap
15:22 drbrain: after matz_ answers we will move on to the
      next topic, we can reopen this if time remains
15:23 drbrain: zenspider: please wait
15:23 drbrain: matz_: done?
15:23 matz_: end
15:23 drbrain: tenderlove: next topic please
15:23 zenspider: I vote 2.1 ... sooooo christmas :P
15:23 headius: matz_: ok, acceptable answer
15:23 zenspider: end :P
15:23 tenderlove: OK!  Keyword arguments
15:23 headius: yay kwargs
15:24 tenderlove: I mainly put these on the agenda because
      wycats_ had issues, but I believe he was happy with
      matz_'s responses
15:24 tenderlove: so....
15:24 tenderlove: anyone have questions / issues?
15:24 drbrain: !
15:24 drbrain: drbrain: ok
15:24 headius: hah
15:24 drbrain: I documented keyword arguments in doc/syntax,
      can someone check it to make sure I did it right?
15:24 drbrain: or if I missed anything?
15:24 drbrain: end
15:24 tenderlove: drbrain: where?
15:25 drbrain: in ruby trunk, doc/syntax/methods.rdoc and
      doc/syntax/calling_methods.rdoc
15:25 enebo: claps
15:25 tenderlove: <3<3<3
15:25 zenspider: !
15:25 drbrain: zenspider: ok
15:25 headius: 888888
15:25 zenspider: I STILL WANT OPTIONAL COLON ON THE MESSAGE
      NAME! GIVE ME SMALLTALK KEYWORD MESSAGES! RAWR!
15:25 zenspider: end
15:25 zenspider: :D
15:25 headius: hah
15:25 headius: !
15:26 zenspider: (no really)
15:26 drbrain: headius: ok
15:26 enebo: fillibuster?
15:26 headius: I did have one concern I raised on the main
      issue, but I think matz_ and I will agree to disagree
      here… I wanted to support non-optional keyword args,
      like def foo(a:, b:)
15:26 headius: I'd like to hear thoughts, but I accept it
      isn't matz's plan right now
15:26 headius: end
15:27 tenderlove: !
15:27 drbrain: tenderlove: ok
15:27 tenderlove: I would like non-option kw arguments as
      well
15:27 enebo: !
15:27 tenderlove: I'm afraid we're going to end up with lots
      of code that's like
15:27 tenderlove: def foo(a: raise("omg"), b: raise)
15:28 tenderlove: end
15:28 tenderlove: end
15:28 drbrain: enebo: ok
15:28 enebo: Actually I was just going to ask what the
      use-case is and the only one I have seen to date is
      error reporting
15:28 zenspider: !
15:28 enebo: So I half wonder if there is not a way to deal
      with that aspect somehow
15:28 enebo: end
15:28 drbrain: zenspider: ok
15:28 tenderlove: !
15:28 zenspider: eww? end
15:28 drbrain: tenderlove: ok
15:29 tenderlove: enebo: it's all over the rails codebase
      today
15:29 enebo: !
15:29 tenderlove: we actually have a special method called
      assert_valid_keys 
15:29 tenderlove: that makes sure particular options hashes
      have particular keys
15:29 tenderlove: and raises if those keys are missing
15:29 tenderlove: end
15:29 drbrain: enebo: ok
15:29 matz_: !
15:29 marcandre: !
15:29 enebo: We also have def foo(a); @a = a all over the
      place?
15:30 enebo: end
15:30 drbrain: matz_: ok
15:30 matz_: submit non optional keyword arg to the
      redmine.
15:30 matz_: I don't think we saw it before
15:30 matz_: end
15:30 _ko1: matz_++
15:30 drbrain: marcandre: ok
15:30 marcandre: assert_valid_keys is different
15:30 marcandre: it checks that other keys have not been
      passed.
15:30 marcandre: AFAIK it doesn't require keys
15:31 headius: !
15:31 marcandre: I would like to know the reasons for not
      having mandatory keys.
15:31 marcandre: I think it would be useful
15:31 marcandre: end
15:31 drbrain: headius: ok
15:31 headius: It was a passing comment I made mostly calling
      out consistency with positional args…perhaps it was
      missed; I will submit as a top-level issue
15:31 headius: since matz is interested in having it
      submitted, I'll handle submitting a top-level issue and
      we can discuss all this there
15:31 tenderlove: 8888
15:32 headius: it would be a non-breaking change to add it
      because no code in 2.0 can define non-optional
      keywords
15:32 headius: end
15:32 drbrain: I think we are done with keyword
      arguments
15:32 drbrain: thanks, headius, for taking care of submitting
      the feature request
15:32 drbrain: tenderlove: next topic please
15:32 tenderlove: k
15:33 tenderlove: next up is isolated binding specifier
15:33 tenderlove: which I think _ko1 proposed
15:33 wycats_: tenderlove: I was happy with the responses I
      got on my tickets, yes
15:33 tenderlove: but jballanc was interested
15:33 zenspider: definition or url pls?
15:33 wycats_: tl;dr: *args can take keyword arguments
15:33 wycats_: if **kwargs are not supplied
15:33 wycats_: that was sufficient for me
15:33 drbrain: wycats_: please wait for end of
      discussion
15:33 tenderlove: urgh
15:33 tenderlove: trying to find the link
15:33 tenderlove: jballanc: do you have it handy?
15:34 jballanc:
      http://bugs.ruby-lang.org/issues/6710#change-27897
15:34 jballanc: sorry...had to find it again
15:34 tenderlove: hereis the issue ^^
15:34 tenderlove: I'll hand this over to jballanc since he
      requested the topic
15:34 jballanc: I've also prepared a gist:
      https://gist.github.com/4543026
15:34 jballanc: tenderlove: thanks!
15:35 jballanc: so, I discussed this a bit in my RubyConf
      2011 talk and also informally with a few others
15:35 jballanc: essentially, the semantics of bindings (esp.
      bindings for procs) in MRI are not well defined
15:35 jballanc: there are many things you can do with
      bindings that should probably be disallowed
15:35 headius: (thank you for summary…I was about to
      ask)
15:36 jballanc: such as changing the values of locals not
      actually referenced within a proc/block from the
      binding of that proc/block
15:36 jballanc: essentially, these are accidents of the way
      bindings and procs/blocks are implemented in MRI
15:36 headius: !
15:36 jballanc: unfortunately, keeping the same semantics as
      MRI prohibits any implementation other than one that
      mirrors MRI's
15:37 jballanc: this also means that many optimizations are
      not possible
15:37 jballanc: I have some ideas on how we might proceed,
      but I'll turn over the floor for now
15:37 jballanc: end
15:37 drbrain: headius: ok
15:37 headius: wycats and I have discussed many times over
      the years the perils of bindings that extend their
      reach too far
15:37 headius: optimization is just one of them, and I know
      that's not compelling enough usually
15:37 headius: you can end up holding large graphs of
      objects, keeping objects from GCing, and so on
15:38 headius: you can also inadvertently expose secure data
      to other libraries and calls very easily
15:38 headius: def method; password = get_secure_password();
      do_something { } ....
15:38 _ko1: !
15:38 headius: do_something can basically see everything in
      your environment and even modify it
15:39 headius: I have made arguments against this that were
      accepted wrt the old retry behavior, for example
15:39 headius: I'm not sure how much of this would be fixed
      by isolated binding stuff from ko1 but I wanted to get
      this out there
15:39 headius: end
15:39 drbrain: _ko1: ok
15:39 _ko1: I'm one of criminal to continue Proc#binding.  I
      have no objection to remove it  if matz and community
      say okay.
15:39 _ko1: end
15:39 zenspider: hah
15:40 jballanc: !
15:40 drbrain: jballanc: ok
15:40 zenspider: !
15:40 lrz: !
15:40 jballanc: heh...so, removing entirely is actually a
      possibility I hadn't considered
15:40 jballanc: I think it may actually be for the best...but
      I would need to think more
15:41 jballanc: I'm concerned, though, that the issues are
      not just isolated to procs
15:41 jballanc: procs are just the most obvious
15:41 jballanc: hmm...
15:41 jballanc: end
15:41 drbrain: lrz: ok
15:41 _ko1: !
15:41 lrz: _ko1++
15:41 enebo: ++
15:41 lrz: Proc#binding is a real problem
15:42 tenderlove: [thumbs-up]
15:42 lrz: it makes optimizing local variables very
      hard
15:42 akr_: !
15:42 lrz: i believe headius wrote a blog post about this a
      while ago, anyways, removing it would be a very good
      idea
15:42 lrz: end
15:42 drbrain: zenspider: ok
15:42 zenspider: jballanc: wrt your question in the ticket, I
      think isolated is a fine name. I also like sandbox.
      END
15:42 drbrain: akr_: ok
15:43 akr_: security is not good reason for this issue.
15:43 akr_: There are many way to get objects such as
      ObjectSpace.
15:43 akr_: end.
15:43 drbrain: _ko1: ok
15:43 _ko1: Some others say that isolated binding is frinedly
      for "Proc migration" between processes (advanced
      feature). end
15:44 headius: !
15:44 drbrain: headius: ok
15:44 headius: ObjectSpace is certainly a big security hole,
      but the existence of one hole doesn't mean we shouldn't
      close others
15:44 enebo: !
15:44 jballanc: !
15:44 headius: isolating the binding for a Proc would indeed
      make it easier to migrate/marshal it…that's a pretty
      good case
15:45 headius: if all procs were isolated (no #binding) then
      we could consider the possibility of marshaling procs
      as a top-level standard feature
15:45 headius: end
15:45 drbrain: enebo: ok
15:45 enebo: I just wantd to know how besides OS can you get
      access?
15:45 enebo: end
15:45 enebo: sorry all thumbs
15:45 drbrain: jballanc: ok
15:46 _ko1: !
15:46 jballanc: re: ObjectSpace...my issue with Proc#binding
      is that you can get a hold of locals that are normally
      not available
15:46 jballanc: I don't believe this is possible with
      ObjectSpace
15:46 headius: related to that… OS would also require you to
      recognize an arbitrary string as being the secure data
      you want, as opposed to eval("password",
      proc.binding)
15:46 jballanc: right
15:46 jballanc: also, to _ko1's original proposal, I'd like
      to have more control than just to say "isolated" for
      eval
15:47 jballanc: this could, potentially, eventually replace
      SAFE levels
15:47 jballanc: end
15:47 drbrain: _ko1: ok
15:47 _ko1: Security risk should be discussed separately.  If
      ObjectSpace has, then we need analysis and
      solution.
15:47 _ko1: redmine is nice to discuss.
15:47 _ko1: end
15:47 drbrain: do we need matz_'s opinion?
15:48 drbrain: … I think we are done with this topic,
      though
15:48 jballanc: !
15:48 drbrain: jballanc: ok
15:48 jballanc: ok, so just to close...
15:48 matz_: let us discuss on redmine
15:48 jballanc: yeah, was going to ask...should I make new
      feature proposal?
15:49 jballanc: or continue on _ko1's?
15:49 drbrain: jballanc: yes, please
15:49 headius: +1
15:49 jballanc: will do!
15:49 jballanc: end
15:49 drbrain: ok, now it is open floor time until the end of
      the hour
15:49 zenspider: !
15:49 headius: I want to point out there's a new "Common
      Ruby" project in redmine where this stuff should
      go
15:49 drbrain: zenspider: ok
15:49 enebo: :)
15:49 tenderlove: headius: link?
15:49 zenspider: I'd really like matz to weigh in on a
      backwards incompatibility and change of protocol to
      method_missing / respond_to / respond_to_missing 
15:49 zenspider: I did my best to diagram all of the
      different interactions and how they've changed over
      time.
15:49 zenspider: It seems like this change is intentional,
      but undocumented and has unintended consequences.
15:49 zenspider: Requiring a no-op `def respond_to?(*) super
      end` does NOT make sense.
15:49 zenspider: https://bugs.ruby-lang.org/issues/7564
15:49 zenspider: matz?
15:49 headius:
      https://bugs.ruby-lang.org/projects/common-ruby
15:50 zenspider: end
15:50 _ko1: zenspider++
15:50 mrkn is now known as __mrkn__
15:50 zenspider:  
15:50 drbrain: matz_: ?
15:50 zenspider: (rawr)
15:51 tenderlove: !
15:51 drbrain: tenderlove: ok
15:51 tenderlove: we're getting close to the end, so just as
      a reminder, make sure to add your email here:
      https://gist.github.com/2c3b41ed83e5d062f636
15:51 tenderlove: (if you're not on the list)
15:51 tenderlove: end
15:51 zenspider: maaaaaaaaaaaaaaatz
15:52 matz_: zenspider: I will see
15:52 tenderlove: burn
15:52 zenspider: laughs
15:52 drbrain: is there any other business?
15:52 headius: hah
15:52 _ko1: !
15:52 drbrain: _ko1: ok
15:52 headius: !
15:53 _ko1: next schedule of this meeting
15:53 _ko1: and 2.1 release.
15:53 _ko1: end
15:53 zenspider: christmas!
15:53 zenspider: LIKE ALWAYS
15:53 drbrain: headius: ok
15:53 tenderlove: !
15:53 headius: Yeah I want schedule for next meeting and 2.1
      as well...
15:54 headius: Also, I wanted to ask about the common ruby
      project in redmine and whether we should actively be
      migrating feature issues there
15:54 headius: obviously new features and feature changes
      should start going there…and we probably should make
      people aware of that
15:54 headius: end
15:54 zenspider: !
15:54 drbrain: for meeting schedule, how about 2 weeks for
      ruby 2.0 issues, and 1 month for other issues?
15:54 unak: headius++
15:54 drbrain: tenderlove: ok
15:55 tenderlove: drbrain: that's what I was going to
      say....
15:55 drbrain: zenspider: ok
15:55 zenspider: drbrain: THERE IS PROTOCOL. YOU CUT!
15:55 headius: that sounds good
15:55 zenspider: end
15:55 enebo: +1
15:55 tenderlove: matz_: does that seem acceptable?  Also, if
      we're meeting about Ruby 2.0, we should make sure that
      mame is here
15:56 tenderlove: so I think we need to make sure we schedule
      with mame's time in mind.
15:56 zenspider: and luis lavena and other core windows
      ppl.
15:56 tenderlove: end
15:56 emboss: !
15:56 zenspider: !
15:56 drbrain: emboss: ok
15:57 emboss: sorry, question already answered. hit the key
      accidentally. end 
15:57 drbrain: zenspider: ok
15:57 zenspider: um. tuesdays are hard for me, drbrain, and
      tenderlove. can we do mondays or wednesdays? END
15:57 zenspider: tho... actually I like missing the meeting
      we're currently missing... :)
15:57 drbrain: I can't be moderator tuesday the 29th, I won't
      be able to see
15:57 drbrain: (eye doctor)
15:58 headius: schedule over email thread, perhaps
15:58 tenderlove: headius: yes.
15:58 shugomaeda: mame is not available week days
15:58 drbrain: matz_: is the schedule of two weeks for a ruby
      2.0 meeting acceptable
15:58 headius: I have EU and AU travel in feb
15:58 matz_: Endo-san (mame) has his day job.  So it hard for
      him to attend weekday meeting
15:58 drbrain: I can be moderator on a weekend
15:59 zenspider: what about IU OU and UU?
15:59 headius: required kwargs:
      https://bugs.ruby-lang.org/issues/7701
15:59 drbrain: headius: thank you
15:59 drbrain: ok, let's schedule via an email to
      ruby-core
15:59 sora_h: +1
15:59 matz_: drbrain: acceptable.  Probably we should have
      meeting on weekend
15:59 tenderlove: seems good
15:59 drbrain: ok
15:59 drbrain: this meeting is now closed

Files (0)

Like0

Project

General

Profile

Ruby

Wiki

Developers Meeting 2013-01-15¶

Attendees¶

MRI¶

Rubinius¶

JRuby¶

MagLev¶

MacRuby¶

Moderator¶

Agenda¶

Summary¶

Refinements¶

Conclusion¶

Open Questions¶

Keyword Arguments¶

Conclusion¶

Action Items¶

Isolated Binding Specifier¶

Conclusion¶

Action¶

Open Floor¶

IRC Log¶