Project

General

Profile

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

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

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: