[2008/06/04 19:02:28] <headius> lots of items tonight
[2008/06/04 19:02:44] <drbrain> my RubyGems item is more of a note
[2008/06/04 19:02:49] <evan> yeah, we'll try and keep things moving
[2008/06/04 19:03:03] <drbrain> so I put it there, doesn't need discussion IMO
[2008/06/04 19:03:14] <evan> ok
[2008/06/04 19:03:50] <matz_> hi
[2008/06/04 19:03:54] <matz_> here I am
[2008/06/04 19:03:58] <evan> hello
[2008/06/04 19:03:59] <brixen> hi matz_
[2008/06/04 19:04:01] <evan> shall we begin?
[2008/06/04 19:04:04] <n0kada> hello
[2008/06/04 19:04:07] <headius> I'm ready
[2008/06/04 19:04:07] <matz_> hi
[2008/06/04 19:04:22] <matz_> evan, could you please start?
[2008/06/04 19:04:28] <evan> sure.
[2008/06/04 19:04:37] <evan> lets do scheduling for the next one quickly.
[2008/06/04 19:04:53] <evan> a number of us will be in japan in nearly 2 weeks time.
[2008/06/04 19:04:55] <headius> maybe we should try to do one live around the kaigi
[2008/06/04 19:05:12] <ko1_> nice :)
[2008/06/04 19:05:24] <evan> well, think about that
[2008/06/04 19:05:27] <headius> do we know which implementers will be there?
[2008/06/04 19:05:32] <evan> we'll poll at the end of this
[2008/06/04 19:05:40] <evan> after people have given it a little thought
[2008/06/04 19:05:43] <headius> ok
[2008/06/04 19:05:44] @ evan set topic "design meeting - Named captures into local variables in 1.9"
[2008/06/04 19:05:49] <evan> this is my item.
[2008/06/04 19:06:00] <evan> I'd heard that
[2008/06/04 19:06:06] <matz_> yes
[2008/06/04 19:06:12] <evan> named captures created locals in 1.9
[2008/06/04 19:06:14] <evan> is that true?
[2008/06/04 19:06:21] <akr_m> in some condition.
[2008/06/04 19:06:24] <matz_> yes, it's akr's idea
[2008/06/04 19:06:41] <evan> "abcddd" =~ /(?<blah>abc)*/
[2008/06/04 19:06:48] <akr_m> literal-regex =~ expression assigns local variables.
[2008/06/04 19:06:50] <evan> p blah # => "abc"
[2008/06/04 19:06:59] <evan> I highly oppose it
[2008/06/04 19:07:01] <akr_m> regexp should be left hand side.
[2008/06/04 19:07:05] <evan> sure
[2008/06/04 19:07:12] <evan> but wouldn't in require significant parser changes
[2008/06/04 19:07:13] <akr_m> why you oppose?
[2008/06/04 19:07:14] <headius> why do you oppose it
[2008/06/04 19:07:15] <evan> and fixups
[2008/06/04 19:07:27] <evan> or would the parser see INTO the regex
[2008/06/04 19:07:32] <evan> to see that blah should be an lvar
[2008/06/04 19:07:35] <evan> rather than a vcall
[2008/06/04 19:07:52] <evan> otherwise, the 'p blah', blah will be a vcall
[2008/06/04 19:07:53] <akr_m> I think, in long-term, ruby should parse regexp in parser.
[2008/06/04 19:07:54] <evan> not an lvar.
[2008/06/04 19:08:31] <headius> when parser encounters regexp it adds local vars based on named captures in it
[2008/06/04 19:08:34] <headius> I presume
[2008/06/04 19:08:35] <MenTaLguY> what happens if you create a named capture in a RegExp.new object, and then pass that object somewhere else?
[2008/06/04 19:08:40] <MenTaLguY> are RegExps now closures?
[2008/06/04 19:08:41] <evan> yes
[2008/06/04 19:08:50] <akr_m> dynamic regexp doesn't assign local variables.
[2008/06/04 19:08:51] <evan> if it's only one particular form of using a regexp that does thins
[2008/06/04 19:08:53] <headius> so parser has to run regexp parser
[2008/06/04 19:08:54] <evan> people will get very confused.
[2008/06/04 19:09:10] <headius> and regexp match method =~ gets to access caller's local variables
[2008/06/04 19:09:15] <akr_m> literal and dynamic regexp is easy to distinguish.
[2008/06/04 19:09:16] <evan> for instance "/(?<blah>abc)*/".match("abcddd")
[2008/06/04 19:09:20] <MenTaLguY> hm, what about a regexp created with // syntax and passed somewhere though?
[2008/06/04 19:09:23] <evan> would not create an lvar of name blah?
[2008/06/04 19:09:32] <akr_m> =~ is actually not a method.
[2008/06/04 19:09:36] <MenTaLguY> while the original scope was around?
[2008/06/04 19:09:43] <MenTaLguY> would it affect the original scope?
[2008/06/04 19:09:43] @ Quit: lrz_: Read error: 110 (Connection timed out)
[2008/06/04 19:09:45] <akr_m> literal-regexp =~ is not overriden.
[2008/06/04 19:10:02] <evan> akr_m: yes, but there are a lot of other ways to use a literal regex
[2008/06/04 19:10:04] <MenTaLguY> ah, I see, so only =~ with a literal regexp does capture-variables
[2008/06/04 19:10:12] <MenTaLguY> as a syntactic thing
[2008/06/04 19:10:12] <evan> and all those ways will not create locals?
[2008/06/04 19:10:15] <akr_m> some one may say it is just a premature optimisation.
[2008/06/04 19:10:15] <evan> thats very confusing.
[2008/06/04 19:10:18] <akr_m> though.
[2008/06/04 19:10:34] <MenTaLguY> I'm still not a fan of the idea
[2008/06/04 19:10:37] <akr_m> this is syntactic feature.
[2008/06/04 19:10:43] @ Quit: nicksieger: brown.freenode.net irc.freenode.net
[2008/06/04 19:10:43] @ Quit: ko1_: brown.freenode.net irc.freenode.net
[2008/06/04 19:11:00] <drbrain> uh-oh, net split
[2008/06/04 19:11:04] @ nicksieger joined channel #ruby-core
[2008/06/04 19:11:04] @ ko1_ joined channel #ruby-core
[2008/06/04 19:11:07] <evan> ack.
[2008/06/04 19:11:10] <evan> ok, good.
[2008/06/04 19:11:14] <akr_m> without this feature, we need to describe the name 3 times.
[2008/06/04 19:11:16] <evan> ko1_: you didn't miss anything
[2008/06/04 19:11:17] <headius> ignoring how it's implemented for now, what is the motivation for doing it
[2008/06/04 19:11:27] <ko1_> hello again
[2008/06/04 19:11:34] <headius> what does it gain over $~['name']
[2008/06/04 19:11:44] <akr_m> /(?<foo>...)/ =~ str and foo = $~['foo']
[2008/06/04 19:12:09] <evan> well
[2008/06/04 19:12:12] <akr_m> key in regexp, key of $~, and local variable.
[2008/06/04 19:12:15] <evan> is this in 1.9?
[2008/06/04 19:12:29] <evan> seems it's something that requires larger and longer discussion
[2008/06/04 19:12:29] <akr_m> it's much longer than /(...)/ =~ str and foo = $1.
[2008/06/04 19:13:18] <akr_m> it is already implemented in 1.9.0-0.
[2008/06/04 19:13:53] <evan> ok.
[2008/06/04 19:13:54] <evan> you know.
[2008/06/04 19:14:03] <evan> i can see it now.
[2008/06/04 19:14:22] <evan> i like it better than $1 actually, mainly because $1 are a major pain to implement correctly in rubinius
[2008/06/04 19:14:36] <headius> how will this be easier?
[2008/06/04 19:14:37] <akr_m> $1 is problematic from users.
[2008/06/04 19:14:45] <akr_m> users need to count parens.
[2008/06/04 19:14:58] <akr_m> the number may be changed later...
[2008/06/04 19:15:14] <headius> name may be changed later as well of course
[2008/06/04 19:15:16] <evan> headius: at compile time, see that the regexp is used with =~, ask the regexp for it's named captures, inject them into the locals table
[2008/06/04 19:15:16] <akr_m> named capture is the way to go.
[2008/06/04 19:15:25] <akr_m> so we should recommend it.
[2008/06/04 19:15:32] <akr_m> it should be shorter than numbered.
[2008/06/04 19:15:39] <evan> named captures are much nicer than number ones.
[2008/06/04 19:15:42] <ko1_> evan: you want to discuss? or want to know 1.9 feature?
[2008/06/04 19:15:43] <akr_m> so, assign it to local variable directly.
[2008/06/04 19:15:52] <evan> for anything beyond a simple regex
[2008/06/04 19:15:57] <evan> ko1_: i was curious how the feature worked.
[2008/06/04 19:15:59] <headius> at compile time you will also have to associated named captures with index into local variables
[2008/06/04 19:15:59] <evan> and worried
[2008/06/04 19:16:00] <MenTaLguY> I agree with everything but the automatic assignment to a local variable
[2008/06/04 19:16:07] <evan> but I get it now
[2008/06/04 19:16:14] <evan> oh
[2008/06/04 19:16:16] <evan> thats a good question
[2008/06/04 19:16:21] <evan> does
[2008/06/04 19:16:30] <evan> blah = nil; /(?<blah>..) =~ str; p blah
[2008/06/04 19:16:34] <evan> blah is overriden, yes?
[2008/06/04 19:16:41] <akr_m> someone proposed /(?<...>)/ = str syntax before.
[2008/06/04 19:16:47] <MenTaLguY> s/overridden/shadowed/ ?
[2008/06/04 19:16:53] <evan> no
[2008/06/04 19:17:00] <akr_m> It's acceptable.
[2008/06/04 19:17:01] <evan> blah is changed by the regexp match
[2008/06/04 19:17:07] <evan> yes?
[2008/06/04 19:17:14] <akr_m> however finaly matz selects =~.
[2008/06/04 19:17:21] <ko1_> evan: you can try it
[2008/06/04 19:17:24] <akr_m> finally or currently.
[2008/06/04 19:17:31] <evan> ok.
[2008/06/04 19:17:38] <evan> i still worry that users will be confused
[2008/06/04 19:17:45] <akr_m> I may propose when /(?<...>) in future...
[2008/06/04 19:17:49] <akr_m> in case statement.
[2008/06/04 19:17:51] <evan> why '// =~ str' makes locals but '//.match(str)' does not
[2008/06/04 19:17:55] <headius> not sure how much we would want to get into impl details, but how does 1.9 associate the named captures with numbered local variables?
[2008/06/04 19:18:01] <headius> or does it do a lookup after the match?
[2008/06/04 19:18:03] <nicksieger> looks like python's named capture is (?P<name>group)
[2008/06/04 19:18:15] <akr_m> .match is overridable.
[2008/06/04 19:18:21] <evan> akr_m: right, i know.
[2008/06/04 19:18:26] <evan> but users will still be confused.
[2008/06/04 19:18:38] <evan> why captures are only inject in one form of a literal regex
[2008/06/04 19:18:44] <evan> i promise they'll be confused.
[2008/06/04 19:18:56] <nicksieger> ah. python uses 'P' to indicate it's a python extension
[2008/06/04 19:19:08] <nicksieger> should ruby similarly denote a ruby-specific extension?
[2008/06/04 19:19:28] <matz_> it's ONIGURUMA extension
[2008/06/04 19:19:29] <akr_m> Ruby's syntax is from .Net.
[2008/06/04 19:19:41] <nicksieger> ok, thx for clarification
[2008/06/04 19:20:26] <headius> I'm trying to think about it without thinking about the implementation
[2008/06/04 19:20:33] <headius> minus impl details I'm indifferent
[2008/06/04 19:20:37] <ko1_> sorry
[2008/06/04 19:20:58] <evan> right
[2008/06/04 19:21:05] <evan> so even if it's a local in the left side
[2008/06/04 19:21:12] <headius> impl details bother me a bit :)
[2008/06/04 19:21:17] <evan> the captures aren't locals
[2008/06/04 19:21:24] <evan> so only one very narrow form
[2008/06/04 19:21:28] <evan> that will definitely confuse users
[2008/06/04 19:21:34] <evan> because it discourages refactoring
[2008/06/04 19:21:35] <akr_m> I don't think so.
[2008/06/04 19:21:41] <evan> they HAVE to keep the regex embedded right there
[2008/06/04 19:21:44] <evan> even if it's big
[2008/06/04 19:21:48] <akr_m> users can distinguish them easily.
[2008/06/04 19:21:49] <evan> otherwise the locals don't work
[2008/06/04 19:22:20] <akr_m> hm. embedded regex may be a problem.
[2008/06/04 19:22:31] <evan> named captures are very useful in large regexps
[2008/06/04 19:22:33] <MenTaLguY> hm, evan's concern about refactoring is a good one
[2008/06/04 19:22:43] <evan> and large regexps are very frequently refactored to exist in a constant
[2008/06/04 19:22:52] <headius> I can also guarantee tool makers will have some concerns
[2008/06/04 19:22:53] <evan> so they don't clutter the code flow
[2008/06/04 19:22:53] <MenTaLguY> we definitely want people to use named captures
[2008/06/04 19:23:03] <headius> since it's going to be nearly impossible to round-trip regular expressions
[2008/06/04 19:23:09] <MenTaLguY> but the automatic assignment will make most common regexp refactorings difficult
[2008/06/04 19:23:18] <headius> round trip + refactor/renaming
[2008/06/04 19:23:31] <evan> lets move on
[2008/06/04 19:23:41] <evan> I just ask that you consider our points
[2008/06/04 19:23:46] <headius> probably should start a thread on it
[2008/06/04 19:23:51] <akr_m> when refactoring, need to switch $~.
[2008/06/04 19:23:55] <headius> it's a longer discussion
[2008/06/04 19:23:56] <evan> if the discussion comes up on ruby-core, i'll discuss
[2008/06/04 19:24:10] <evan> akr_m: and change all locals to use $~
[2008/06/04 19:24:15] <evan> so they wont use it
[2008/06/04 19:24:18] <evan> because it will be a pain later.
[2008/06/04 19:24:26] <evan> lets move on though.
[2008/06/04 19:24:26] <evan> ok?
[2008/06/04 19:24:33] <akr_m> this feature is good for smaller regexp,
[2008/06/04 19:24:42] <akr_m> there are many smaller regexps.
[2008/06/04 19:25:09] <evan> akr_m: lets discuss over email, ok?
[2008/06/04 19:25:13] <akr_m> ok
[2008/06/04 19:25:18] <evan> we have a lot to cover
[2008/06/04 19:25:21] @ evan set topic "design - Adding a formal/official annotation syntax, such as Python has"
[2008/06/04 19:25:25] <evan> headius: this is you.
[2008/06/04 19:25:27] <evan> you have the floor.
[2008/06/04 19:25:35] @ lrz joined channel #ruby-core
[2008/06/04 19:25:45] <matz_> annotations
[2008/06/04 19:25:47] <headius> ok
[2008/06/04 19:25:59] <headius> I know this has been discussed...matz, can you tell us your thoughts on this right now?
[2008/06/04 19:26:20] <matz_> it depends on what we want to do on annotation
[2008/06/04 19:26:25] <headius> this is just annotation syntax for informational purposes...for tools/libs that could use extra metadata attached to methods
[2008/06/04 19:26:40] <headius> rdoc is essentially an annotation format
[2008/06/04 19:26:48] <headius> but not part of the language directly
[2008/06/04 19:27:02] <matz_> Java style annotation, or even Python style, can change the basic semantics on the lnanguage
[2008/06/04 19:27:09] <ko1_> big issue :)
[2008/06/04 19:27:26] <nicksieger> headius: maybe you should explain your use caseeee
[2008/06/04 19:27:28] <matz_> that's what I don't want to see
[2008/06/04 19:27:46] <headius> there are several use cases I can suggest
[2008/06/04 19:28:06] <headius> an rdoc format that can be accessed at runtime, for example, because it becomes part of the metadata of classes and methods
[2008/06/04 19:28:21] <nicksieger> like a docstring?
[2008/06/04 19:28:24] <headius> yeah
[2008/06/04 19:28:55] <headius> of course expanding from that there's the possibility of providing type hinting or recommendations, but I know there's a desire to keep static types out
[2008/06/04 19:29:34] <matz_> appending machine readable info to chunks of code is OK
[2008/06/04 19:29:52] <headius> that's my basic general desire
[2008/06/04 19:30:01] <headius> let me use a type hinting example
[2008/06/04 19:30:02] <nicksieger> even just a docstring would cover a lot of cases, since tools could just require specific tokens inside it
[2008/06/04 19:30:41] <headius> I would like to be able to use a type hinting syntax in some JRuby internals
[2008/06/04 19:30:48] <headius> so more could be implemented with Ruby
[2008/06/04 19:31:00] <headius> but ideally I'd like those hints to be ignored if not used
[2008/06/04 19:31:18] <headius> to do that I've been faking it with literal arrays that go nowhere, like
[2008/06/04 19:31:27] <headius> [String, Integer]
[2008/06/04 19:31:30] <headius> def foo(a, b)
[2008/06/04 19:31:31] <headius> ...
[2008/06/04 19:31:43] <ko1_> return value type?
[2008/06/04 19:31:56] <headius> well in my case I'm inferring return value, but that's another case
[2008/06/04 19:31:58] <ko1_> argument type?
[2008/06/04 19:32:02] @ shugo joined channel #ruby-core
[2008/06/04 19:32:09] <headius> this is a simple example of argument type hinting
[2008/06/04 19:32:20] <headius> docstring would be another
[2008/06/04 19:32:28] <headius> "This is a method for blah blah"
[2008/06/04 19:32:31] <headius> def foo(a, b)
[2008/06/04 19:32:36] <evan> the idea is attaching a small bit of structure data to a method, yes?
[2008/06/04 19:32:38] <headius> but again, another syntax
[2008/06/04 19:33:04] <matz_> like "#@ type: String, Integer"?
[2008/06/04 19:33:04] <headius> evan yes...something that could safely be ignored at parse or compile time, but can have some arbitrarily useful value to tools that care
[2008/06/04 19:33:11] <headius> matz_ yes
[2008/06/04 19:33:20] <evan> matz_: yes, that would be a Hash thats attached to the method
[2008/06/04 19:33:31] <evan> { :type => "String, Integer" }
[2008/06/04 19:33:45] <akr_m> I'd like to hear usages for casual users.  (not types)
[2008/06/04 19:33:45] <headius> %A[ String Integer ]
[2008/06/04 19:34:00] <headius> akr_m perhaps a remoting library:
[2008/06/04 19:34:03] <evan> yes, perhaps using a % expansion would help
[2008/06/04 19:34:14] <headius> %A[ Remote ]
[2008/06/04 19:34:16] <headius> def foo
[2008/06/04 19:34:27] <MenTaLguY> generally, metaprogramming often benefits
[2008/06/04 19:34:41] <headius> yeah, that's a good way to put it
[2008/06/04 19:34:48] <matz_> hmm, I am not a fan of remote method idea.
[2008/06/04 19:34:54] <ko1_> remote?
[2008/06/04 19:35:06] <matz_> I'd rather see, "remote :foo"
[2008/06/04 19:35:22] <headius> in a string? or as a method call?
[2008/06/04 19:35:28] <MenTaLguY> method call
[2008/06/04 19:35:31] <matz_> as a method call
[2008/06/04 19:35:32] <headius> the problem with method syntax is that it's not thread-safe
[2008/06/04 19:35:34] <ko1_> such as private :foo
[2008/06/04 19:35:35] <MenTaLguY> analagous to private-as-a-method and so forth
[2008/06/04 19:35:46] <MenTaLguY> yes, there is an issue with atomicity
[2008/06/04 19:36:03] <headius> a true annotation would be atomically attached to the following code
[2008/06/04 19:36:10] <headius> ideally at parse time
[2008/06/04 19:36:16] <MenTaLguY> it would be nice to have something like the method syntax which was atomically grouped with the method definition itself
[2008/06/04 19:36:20] <evan> plus, I worry that if every application much add class methods to Class
[2008/06/04 19:36:25] <evan> the solution wont scale
[2008/06/04 19:36:29] <akr_m> how atomicity is important?
[2008/06/04 19:36:32] <headius> this would also make it trivial to write an rdoc tool that doesn't depend on the parser
[2008/06/04 19:36:43] <akr_m> ruby has such atomicity in general.
[2008/06/04 19:36:46] <MenTaLguY> well, why do people need to add class methods to class?
[2008/06/04 19:36:57] <ko1_> most of definition is done in boot time, so it's not issue > atomicity
[2008/06/04 19:36:59] <headius> akr_m: the non-parallized ruby implementations may, but not all
[2008/06/04 19:37:01] <akr_m> oops. no such.
[2008/06/04 19:37:03] <evan> MenTaLguY: to implement "remote :foo" in every class, yes.
[2008/06/04 19:37:23] <MenTaLguY> the thing is that remote :foo usually has to make some assumptions about the structure of the object
[2008/06/04 19:37:27] <MenTaLguY> Class is too general
[2008/06/04 19:37:39] <MenTaLguY> will remote :foo work for Fixnum?  probably not...
[2008/06/04 19:37:54] <evan> lets get back on topic
[2008/06/04 19:37:56] <MenTaLguY> granted you're not the person I need to argue with, if people are doing that so much in the wild :)
[2008/06/04 19:38:11] <headius> ok, topic
[2008/06/04 19:38:11] <evan> it was about matz_ adding syntax for attaching structure data to a method
[2008/06/04 19:38:23] <evan> matz_: are you considering it?
[2008/06/04 19:38:29] <evan> or should headius try and sell you via email?
[2008/06/04 19:38:31] <headius> largely I'd like to understand if there's a strong resistance or support for this idea
[2008/06/04 19:38:40] <headius> I know it has come up before
[2008/06/04 19:38:59] <matz_> annotations can be abused
[2008/06/04 19:39:06] <matz_> See python annotation,
[2008/06/04 19:39:11] <matz_> It's fun trick
[2008/06/04 19:39:24] <akr_m> like open class.
[2008/06/04 19:39:25] <matz_> but it is same kind of fun as lisp macros
[2008/06/04 19:39:33] <ko1_> like eval
[2008/06/04 19:39:46] <matz_> no, worse
[2008/06/04 19:39:51] <headius> I don't think the annotation syntax has to do anything more than attach minimally-structured data
[2008/06/04 19:39:56] <matz_> those two does not change the language semantics
[2008/06/04 19:39:57] <headius> no runtime executable logic
[2008/06/04 19:40:31] <headius> rdoc is again a good example
[2008/06/04 19:40:42] <matz_> RDoc should stay being comments
[2008/06/04 19:41:00] <matz_> I don't want to grow process size
[2008/06/04 19:41:01] <headius> with annotation syntax and api (like method(:foo).annotations) rdoc generation for ruby code could be done without parser
[2008/06/04 19:41:32] <matz_> anyway, I am not against having simple annotation
[2008/06/04 19:41:36] <MenTaLguY> with the regular parser, you mean?
[2008/06/04 19:41:53] <headius> MenTaLguY: I mean without exposing any parser to the rdoc code
[2008/06/04 19:42:07] <akr_m> some methods are defined only for some OS...
[2008/06/04 19:42:15] <ko1_> someone will do "eval" with annotation data.
[2008/06/04 19:42:17] <headius> matz_ how could we proceed? email to ruby-core with ideas and use cases?
[2008/06/04 19:42:19] <MenTaLguY> maybe, that does require that rdoc actually load the code in question
[2008/06/04 19:42:29] <matz_> headius:  yes, please
[2008/06/04 19:42:30] <MenTaLguY> which means it must evaluate some of the code
[2008/06/04 19:42:38] <akr_m> how we can get rdoc for non-existing methods?
[2008/06/04 19:42:45] <MenTaLguY> I do think the current situation where rdoc never evaluates any code is preferable
[2008/06/04 19:42:48] <evan> akr_m: we don't.
[2008/06/04 19:42:49] <headius> yes, that's true
[2008/06/04 19:42:52] <evan> as far as I know.
[2008/06/04 19:43:04] <headius> here's one more use case and we can move on
[2008/06/04 19:43:05] <evan> lets move on.
[2008/06/04 19:43:14] <headius> %A[ synchronized ]
[2008/06/04 19:43:15] <MenTaLguY> akr_m: typically today I create stub classes in a separate directory which are read by rdoc, but are never on the library path
[2008/06/04 19:43:15] <headius> :)
[2008/06/04 19:43:19] @ evan set topic "design - IO  buffer behavior is specification or implementation detail"
[2008/06/04 19:43:25] <evan> this is mine.
[2008/06/04 19:43:40] <matz_> I think it's an implementation issue
[2008/06/04 19:43:43] <evan> rubyspecs has a number of IO specs that spec the exact nature
[2008/06/04 19:43:45] <MenTaLguY> headius: hm, that's actually a fairly significant semantic implication
[2008/06/04 19:43:50] <evan> of IO and how they buffer
[2008/06/04 19:44:00] <evan> i think it's an impl. artifact of MRI using FILE
[2008/06/04 19:44:05] <headius> MenTaLguY we can talk more about it later, I agree though
[2008/06/04 19:44:08] <evan> but I need confirmation
[2008/06/04 19:44:13] <matz_> what kind of difference you see?
[2008/06/04 19:44:24] <akr_m> Ruby 1.8 use stdio but Ruby 1.9 doesn't.
[2008/06/04 19:44:24] <evan> matz_: no different, just very specific behaviors
[2008/06/04 19:44:29] <evan> oh
[2008/06/04 19:44:34] <evan> i haven't checked against 1.9
[2008/06/04 19:44:38] <headius> matz_: flushing semantics for example
[2008/06/04 19:44:43] <akr_m> Ruby 1.9 has it's own buffering mechanism.
[2008/06/04 19:44:44] <evan> i'll collect the rubyspecs in question and email ruby-core about them
[2008/06/04 19:44:53] <evan> so that you guys can comment on them, ok?
[2008/06/04 19:44:58] <evan> i don't have the list in front of me now.
[2008/06/04 19:45:08] <headius> also errors/warnings for unbuffered after buffered
[2008/06/04 19:45:14] <evan> yes
[2008/06/04 19:45:44] <headius> I implemented 1.8 semantics in JRuby and had to read glibc code to do so
[2008/06/04 19:45:53] @ akr_m is now known as akr_
[2008/06/04 19:46:13] <evan> matz_: would you and the rest of the core team like to review the specs i mean
[2008/06/04 19:46:18] <evan> matz_: and you can comment on them
[2008/06/04 19:46:19] <akr_> Ruby 1.8 depends on stdio so it depends on libc.
[2008/06/04 19:46:30] <matz_> evan, yes
[2008/06/04 19:46:34] <evan> ok
[2008/06/04 19:46:35] <evan> i'll do that.
[2008/06/04 19:46:51] <headius> akr_ does 1.9 mimic 1.8 behavior for buffers or is it very different?
[2008/06/04 19:47:25] <evan> may we move on?
[2008/06/04 19:47:28] <headius> unbuffered read after buffered write causing an error, for example
[2008/06/04 19:47:39] <akr_> I tried to fix several problems in 1.8.  So somewhat different.
[2008/06/04 19:47:47] <headius> ok
[2008/06/04 19:47:59] <headius> we'll discuss on mailing list, maybe come up with a list of what can be specified behavior and what should not
[2008/06/04 19:48:03] @ evan set topic "design - Standardize the contents of RUBY_PLATFORM"
[2008/06/04 19:48:14] <evan> headius: i'll get the list out tomorrow probably
[2008/06/04 19:48:23] <headius> it can't be entirely unspecified, since read/write are supposed to be buffered
[2008/06/04 19:48:24] <headius> ok
[2008/06/04 19:48:37] <evan> headius: not, but the ones about rewinding into the buffer, and such.
[2008/06/04 19:48:44] <evan> brixen: this is your item
[2008/06/04 19:48:57] <brixen> yes
[2008/06/04 19:49:05] <brixen> next 2 items closely related
[2008/06/04 19:49:09] <headius> evan: yeah, don't remind me...I'm back in that code this evening
[2008/06/04 19:49:17] <brixen> idea is to make ruby code easier to run on any implementation
[2008/06/04 19:49:37] <brixen> matz_: do you think it's a good idea to specify what info RUBY_PLATFORM should contain?
[2008/06/04 19:49:49] <brixen> for example, on jruby, it is always "java"
[2008/06/04 19:50:05] <matz_> for Rubinius?
[2008/06/04 19:50:17] <brixen> we try to follow MatzRuby :)
[2008/06/04 19:50:24] <akr_> config.guess ?
[2008/06/04 19:50:25] <brixen> but there is not standard
[2008/06/04 19:50:34] <brixen> akr_: yeah, we use config.guess
[2008/06/04 19:50:38] <brixen> should that be standard?
[2008/06/04 19:50:47] <drbrain> note that RubyGems uses RbConfig::CONFIG['arch'] to determine platform
[2008/06/04 19:50:48] <brixen> what about for jruby, with not config.guess in build?
[2008/06/04 19:51:03] <akr_> + i686-pc-linux-gnu + some tweak ?
[2008/06/04 19:51:06] <matz_> I am not sure what we want to specify by RUBY_PLATFORM (or RUBY_ENGIN)
[2008/06/04 19:51:10] <akr_> oops. config.sub
[2008/06/04 19:51:25] <evan> matz_: people use RUBY_PLATFORM to detect windows
[2008/06/04 19:51:32] <evan> thats the most common use.
[2008/06/04 19:51:38] <headius> we can't depend on config
[2008/06/04 19:51:41] <evan> 2nd is detecting darwin
[2008/06/04 19:52:25] <headius> if RUBY_ENGINE had existed two years ago we probably would have used that for "jruby" and tried to match RUBY_PLATFORM
[2008/06/04 19:52:32] <TheProkrammer> Oh, forgot this was tonight... IronRuby has it hardcoded atm.
[2008/06/04 19:52:33] <headius> but now there are gems released for -java
[2008/06/04 19:52:51] <brixen> the idea is to make whatever is in RUBY_PLATFORM the same for every implementation on a particular OS + arch
[2008/06/04 19:53:05] <lrz> TheProkrammer: same for me, i thought i was tomorrow :)
[2008/06/04 19:53:07] <headius> also gems for JRuby are very different than gems for RUBY_PLATFORM because the same code runs everywhere
[2008/06/04 19:53:11] <TheProkrammer> + platform
[2008/06/04 19:53:26] <headius> brixen that would break all existing jruby-specific gems you know
[2008/06/04 19:53:35] <TheProkrammer> So like... Windows + 32bit + CLR2.0 or Windows + 64bit + JVM 1.6?
[2008/06/04 19:53:42] <brixen> headius: yes, but we need to address this sooner than later
[2008/06/04 19:53:52] <MenTaLguY> I think it is fair to call CLR or JVM an architecture
[2008/06/04 19:53:58] <MenTaLguY> and a platform
[2008/06/04 19:54:08] <drbrain> RubyGems allows an implementation to have multiple platforms now, Rubinius claims to be both the OS platform and a Rubinius platform
[2008/06/04 19:54:13] <brixen> matz_: I'm suggesting that RUBY_PLATFORM, RUBY_VERSION, and RUBY_PATCHLEVEL be the same for *Ruby* language, not different for any implementation
[2008/06/04 19:54:17] <headius> "java" is a platform
[2008/06/04 19:54:28] <TheProkrammer> true.
[2008/06/04 19:54:29] <akr_> does java hide windows/unix difference completely?
[2008/06/04 19:54:34] <brixen> headius: that would hold if you had the same behavior on every OS
[2008/06/04 19:54:34] <matz_> if they are architecture, you can put them in RUBY_PLATFORM
[2008/06/04 19:54:38] <headius> akr_ almost completely
[2008/06/04 19:54:45] <headius> brixen we do
[2008/06/04 19:54:57] <brixen> headius: not according to VVis
[2008/06/04 19:54:58] <headius> except where we've had to forcibly break that behavior to match matzruby on windows
[2008/06/04 19:55:10] <TheProkrammer> Mono vs .NET doesn't.. but they are both CLR.
[2008/06/04 19:55:13] <brixen> headius: so you would be identical on every platform?
[2008/06/04 19:55:15] <headius> brixen the differences are minor, and we don't require a recompile
[2008/06/04 19:55:27] <brixen> headius: identical for the user code?
[2008/06/04 19:55:31] <headius> yes
[2008/06/04 19:55:44] <headius> except windows, which behaves differently because matzruby does
[2008/06/04 19:56:00] <evan> so
[2008/06/04 19:56:01] <brixen> well, that's the use case for RUBY_PLATFORM, i.e. needing to know how to behave on an OS + arch
[2008/06/04 19:56:01] <headius> mostly people only need to know actual platform for JRuby if they want to call outside the VM
[2008/06/04 19:56:09] <evan> there is a question as to what the standard would be
[2008/06/04 19:56:16] <evan> not just whether we can accept a standard
[2008/06/04 19:56:17] <brixen> headius: yeah, that's a problem
[2008/06/04 19:56:17] <evan> yes?
[2008/06/04 19:56:22] <TheProkrammer> Well.. the windows story in general is something that needs to be fleshed out I think.
[2008/06/04 19:56:25] <brixen> evan: both
[2008/06/04 19:56:25] <evan> lets discuss what that standard should be out over email
[2008/06/04 19:56:34] <evan> because we need lots of people to weigh in
[2008/06/04 19:56:41] <brixen> evan: question is can these be standard?
[2008/06/04 19:56:49] <evan> getting back to what matz_ said, whats the use case?
[2008/06/04 19:56:51] <evan> platform detection?
[2008/06/04 19:56:54] <brixen> yes
[2008/06/04 19:56:59] <evan> there can be simple standards
[2008/06/04 19:57:01] <brixen> so ruby code knows what to do
[2008/06/04 19:57:01] <evan> like rubygems uses
[2008/06/04 19:57:10] <evan> <major>-<minor>
[2008/06/04 19:57:12] <headius> I'd say platform is what lives immediately below the ruby implementation
[2008/06/04 19:57:14] <evan> like
[2008/06/04 19:57:18] <headius> in our case, that's java
[2008/06/04 19:57:19] <evan> i686-darwin
[2008/06/04 19:57:21] <evan> or
[2008/06/04 19:57:22] <evan> java-java
[2008/06/04 19:57:30] <matz_> jvm-java
[2008/06/04 19:57:32] <evan> sure
[2008/06/04 19:57:33] <evan> exactly
[2008/06/04 19:57:36] <evan> sun-java
[2008/06/04 19:57:37] <evan> perhaps
[2008/06/04 19:57:51] <ko1_> ibm-java
[2008/06/04 19:57:56] <evan> right
[2008/06/04 19:58:01] <brixen> headius: except for where ruby code needs to know what the OS provides
[2008/06/04 19:58:02] <evan> something simple like that can be standard
[2008/06/04 19:58:06] <evan> yes?
[2008/06/04 19:58:06] <headius> jruby -rrbconfig -e "p Config::CONFIG['arch']"
[2008/06/04 19:58:07] <headius> "universal-java1.5"
[2008/06/04 19:58:11] <TheProkrammer> clr-win32 or win32-clr ? eh..
[2008/06/04 19:58:21] <lrz> but isn't java supposed to be universal? :)
[2008/06/04 19:58:33] <evan> should Config::CONFIG['arch'] == RUBY_PLATFORM
[2008/06/04 19:58:38] <evan> it should always, yes?
[2008/06/04 19:58:41] <headius> lrz we report whatever we're running on...it's just for the user
[2008/06/04 19:58:46] <headius> we don't need to rebuild
[2008/06/04 19:58:49] <akr_> I think usecase should be listed: rubygem, filename handling, ....
[2008/06/04 19:58:58] <evan> ok
[2008/06/04 19:59:03] <evan> drbrain: any insight rubygems wise?
[2008/06/04 19:59:12] <headius> one jruby build is universal on all java impls
[2008/06/04 19:59:54] <drbrain> in RubyGems platforms, universal means a package works everywhere
[2008/06/04 19:59:55] <matz_> so, universal-java1.5 has no problem
[2008/06/04 20:00:02] <headius> if we had to match RUBY_PLATFORM rubygems would have to look at something else to know how to handle java-based gems
[2008/06/04 20:00:12] <brixen> headius: how does that indicate what the OS provides though
[2008/06/04 20:00:15] <headius> because we'd report whatever OS someone was running on
[2008/06/04 20:00:25] <brixen> headius: ruby code doesn't need to know the jvm, it needs to know OS stuff
[2008/06/04 20:00:40] <headius> brixen for rubygems, it needs to know it to build, which java-based gems don't do
[2008/06/04 20:00:59] <drbrain> headius: that could go in rubygems/defaults/jruby.rb
[2008/06/04 20:01:25] <headius> how would java-based gems be named?
[2008/06/04 20:01:45] <headius> we'd either have to have the "ruby" gem also include the java bits or we'd need another indicator
[2008/06/04 20:01:54] <evan> back on course
[2008/06/04 20:02:06] <brixen> RUBY_PLATFORM should be for general code
[2008/06/04 20:02:08] <brixen> not just gems
[2008/06/04 20:02:17] <evan> lets take this into email, yes?
[2008/06/04 20:02:28] <brixen> yeah
[2008/06/04 20:02:43] @ evan set topic "design - Can all implementations agree to follow MatzRuby on RUBY_VERSION and RUBY_PATCHLEVEL"
[2008/06/04 20:02:47] <evan> brixen: you again
[2008/06/04 20:02:52] <brixen> yep
[2008/06/04 20:03:00] <brixen> so, with rubyspec, we now have version guards
[2008/06/04 20:03:10] <matz_> the answer is simple: yes
[2008/06/04 20:03:11] <brixen> to make this work, every impl has to agree to follow the same numbers
[2008/06/04 20:03:13] <headius> jruby agrees
[2008/06/04 20:03:24] <matz_> but some may feel spec changed for bug fixes
[2008/06/04 20:03:32] <headius> it's not a big deal, we just overloaded patchlevel with our revision number because it didn't mean anything at th etime
[2008/06/04 20:03:47] <headius> but we can make RUBY_VERSION and RUBY_PATCHLEVEL match, and add our own
[2008/06/04 20:03:57] <akr_> it is difficult to determine an old behavior is bug or spec.
[2008/06/04 20:04:20] <brixen> well, specs only exist for 1.8.6 forward
[2008/06/04 20:04:45] <headius> I don't think there's a way to separate out simple bugs from behavior changes, so I feel like patchlevel should part of spec
[2008/06/04 20:04:46] <brixen> ok, we can move on, unless anyone objects
[2008/06/04 20:04:49] <evan> ok
[2008/06/04 20:05:01] @ evan set topic "design - No behavior changes (only bug fixes) in RUBY_PATCHLEVEL"
[2008/06/04 20:05:11] <evan> this is about 1.8.7, right?
[2008/06/04 20:05:16] <brixen> it wasn't
[2008/06/04 20:05:24] <brixen> but with 1.8.7, it is now impossible
[2008/06/04 20:05:31] <brixen> there is no other number to track things
[2008/06/04 20:05:37] <akr_> date
[2008/06/04 20:05:40] <brixen> because 1.8.6 is different from 1.8.7
[2008/06/04 20:05:48] <evan> brixen: when did you add this item?
[2008/06/04 20:05:52] <brixen> so, significant changes will be in patchlevels
[2008/06/04 20:05:54] <evan> 2 weeks ago?
[2008/06/04 20:05:59] <brixen> evan: yeah :P
[2008/06/04 20:06:02] <evan> ok
[2008/06/04 20:06:29] <brixen> rubyspecs has patchlevel (optional) in version string "1.8.6.111", so I guess it's not an issue anymore
[2008/06/04 20:06:33] <headius> I have no preference here, but I will say I am worried about patchlevel being overloaded just to keep the other version numbers single-digits
[2008/06/04 20:06:41] <headius> if we could go to 1.8.10 it would not have to be this way
[2008/06/04 20:06:49] <brixen> imo, 1.8.7 was a bad number to assign
[2008/06/04 20:07:07] <headius> I think patchlevels get too many changes as it is
[2008/06/04 20:07:26] <akr_> I don't understand.
[2008/06/04 20:07:40] <akr_> RUBY_PATCHLEVEL on 1.8.6 is independent from RUBY_PATCHLEVEL on 1.8.7.
[2008/06/04 20:07:45] <headius> if there wasn't a limitation that ruby version number components all be single digits, we could keep behavior-changing alterations in the 0.0.x number
[2008/06/04 20:07:48] <evan> akr_: if people write code for 1.8.7, it wont work on 1.8.6
[2008/06/04 20:07:56] <evan> akr_: because there are new APIs in 1.8.7
[2008/06/04 20:08:05] <brixen> akr_: RUBY_VERSION only has 1.8.6 but major difference could be there
[2008/06/04 20:08:12] <brixen> akr_: so, you have to check RUBY_PATCHLEVEL too
[2008/06/04 20:08:16] <akr_> 1.8.7 is teeny level change.   not patchlevel.
[2008/06/04 20:08:48] <brixen> akr_: yes, but teeny level change that includes big changes
[2008/06/04 20:09:10] <evan> i think that a lot of us are unclear about what can change in a teeny version
[2008/06/04 20:09:10] <brixen> akr_: in 1.8.6 for example, the exception raised by methods changed in patchlevel
[2008/06/04 20:09:20] <evan> we thought it was just for bugs mostly
[2008/06/04 20:09:23] <evan> but it contains syntax changes
[2008/06/04 20:09:29] <evan> and a lot of backported code from 1.9
[2008/06/04 20:09:34] <brixen> akr_: so, code that checked RUBY_VERSION would have to check RUBY_PATCHLEVEL to know the difference
[2008/06/04 20:09:52] <akr_> why not just check RUBY_VERSION?
[2008/06/04 20:10:13] <brixen> akr_: because there were changes made in patchlevel version
[2008/06/04 20:10:21] <matz_> I just don't get it
[2008/06/04 20:10:22] <brixen> akr_: you can't know everything from RUBY_VERSION
[2008/06/04 20:10:37] <lrz> i don't understand either
[2008/06/04 20:10:38] <matz_> backporting happened in 1.8.7, not 1.8.6
[2008/06/04 20:10:47] <matz_> so patchlevel is not related
[2008/06/04 20:11:01] <brixen> matz_: there were numerous changes to the exceptions raised by certain methods in 1.8.6
[2008/06/04 20:11:05] <matz_> during 1.8.6, some changes happened in patchlevels
[2008/06/04 20:11:06] <brixen> matz_: in patchlevel changes
[2008/06/04 20:11:22] <matz_> but it was bug fixes and some mistakes
[2008/06/04 20:11:26] <headius> I don't get it either...other than there being perhaps too drastic changes in 1.8.7 (matter of opinion) 1.8.7 is > 1.8.6 with any patchlevel
[2008/06/04 20:11:57] <headius> 1.8.7 patchlevel 0 is > all 1.8.6 versions
[2008/06/04 20:12:12] <brixen> yes
[2008/06/04 20:12:15] <lrz> and you can check for 1.8.7 using RUBY_VERSION
[2008/06/04 20:12:32] <headius> I'm not sure what this topic is actually about now
[2008/06/04 20:12:36] <brixen> rubyspecs will need to include patchlevel in the version string for some behaviors
[2008/06/04 20:12:37] <evan> me either.
[2008/06/04 20:12:40] <brixen> that's it
[2008/06/04 20:12:43] <brixen> we're finished :)
[2008/06/04 20:12:45] <evan> ok.
[2008/06/04 20:12:48] <evan> lets move on
[2008/06/04 20:12:52] <headius> brixen and that's something you don't like, yes?
[2008/06/04 20:13:02] <brixen> headius: that's a fact of life now
[2008/06/04 20:13:16] @ evan set topic "design - Maintainance benchmark suits"
[2008/06/04 20:13:17] <ko1_> spec should check patchlevel?
[2008/06/04 20:13:19] <brixen> headius: I don't like it because user code can't just check RUBY_VERSION
[2008/06/04 20:13:23] <headius> I think the bottom line is that unless x.x.x version can support > 9 components, patchlevel is going to continue being a part of the version number for specs
[2008/06/04 20:13:51] <headius> brixen agreed...but there have been larger discussions about the problems with a quickly-incrementing 0.0.x, since MRI can't support > 9
[2008/06/04 20:14:15] <headius> certainly not ideal..but I think fixing that is harder than just using patchlevel right now
[2008/06/04 20:14:30] <akr_> i can't understand this problem without actual examples.
[2008/06/04 20:14:47] <matz_> patchlevels are not related single digit version at all
[2008/06/04 20:14:58] <headius> akr_ I will privmsg
[2008/06/04 20:15:19] <brixen> evan: this is ko1_'s item
[2008/06/04 20:15:23] <evan> yes
[2008/06/04 20:15:29] <evan> ko1_: this is your item about benchmarks
[2008/06/04 20:15:33] <ko1_> yes
[2008/06/04 20:15:49] <ko1_> we should maintain common benchmark suits/driver
[2008/06/04 20:15:58] <ko1_> right?
[2008/06/04 20:16:31] <brixen> I think it would be good to have a standard set, yes
[2008/06/04 20:16:32] <ko1_> and brixen told me: 07:49:06 brixen     > ko1_: you've seen? http://groups.google.com/group/ruby-benchmark-suite
[2008/06/04 20:16:52] <ko1_> 7:49 JST :)
[2008/06/04 20:17:07] <ko1_> http://github.com/acangiano/ruby-benchmark-suite/tree/master
[2008/06/04 20:17:16] <evan> ko1_: do you want to work with acangiano on them?
[2008/06/04 20:17:21] <evan> ko1_: we talked about them at railsconf
[2008/06/04 20:17:29] <evan> ko1_: about building up a set a benchmarks that aren't micro
[2008/06/04 20:17:29] <ko1_> his license is MIT.
[2008/06/04 20:17:34] <evan> ko1_: is that a problem?
[2008/06/04 20:17:35] <ko1_> i think Ruby's is more suitable
[2008/06/04 20:17:44] <evan> ko1_: email him
[2008/06/04 20:17:47] <evan> i'm sure he'll change it
[2008/06/04 20:17:52] <matz_> but it doesn't matter as long as it's MIT
[2008/06/04 20:17:59] <evan> ok
[2008/06/04 20:18:08] <evan> the idea is to have bigger benchmarks
[2008/06/04 20:18:10] <evan> like richards
[2008/06/04 20:18:19] <evan> that stress polymorphic performance
[2008/06/04 20:18:24] <evan> the kinds of things you see in applications
[2008/06/04 20:18:26] <ko1_> richards?
[2008/06/04 20:18:52] <evan> richards is an old smalltalk benchmark
[2008/06/04 20:18:56] <evan> search for it
[2008/06/04 20:19:06] <nicksieger> http://fisheye.codehaus.org/changelog/jruby/?cs=6864
[2008/06/04 20:19:06] <ko1_> ok. i'll do
[2008/06/04 20:19:13] <nicksieger> ko1_: ^^^
[2008/06/04 20:19:22] <nicksieger> i added a version to jruby recently
[2008/06/04 20:20:07] <headius> ko1 should join benchmarks project, that's probably where this will all start happening
[2008/06/04 20:20:26] <headius> I wrote most of the jruby benchmarks and I'm fine relicensing any that are suitable
[2008/06/04 20:20:31] <ko1_> if we determine to make common benchmark (it is acangiano's?), we should drop our own benchmarks
[2008/06/04 20:21:03] <ko1_> s/drop/move/
[2008/06/04 20:21:05] <headius> ko1_ it would be nice to have a set of benchmarks other than YARVs used to measure relative performance :)
[2008/06/04 20:21:12] <headius> I'm sure you are frustrated by that too
[2008/06/04 20:22:01] <headius> I think we would contribute benchmarks to the benchmark project, rather than dropping them
[2008/06/04 20:22:02] <ko1_> is acangiano's project suitable place to maintain common benchmarks?
[2008/06/04 20:22:13] <brixen> ko1_: I think yes
[2008/06/04 20:22:25] <headius> I don't have a problem with it
[2008/06/04 20:22:31] <headius> it would not mean you have to delete yours
[2008/06/04 20:22:45] <headius> just that we should try to contribute there as much as possible
[2008/06/04 20:23:03] <brixen> yeah, a standard set is good, but each impl might have particular ones
[2008/06/04 20:23:48] <evan> shall we move on?
[2008/06/04 20:23:50] <headius> the common project probably won't want our java invocation benchmarks
[2008/06/04 20:24:07] <headius> ok...ko1, will you join benchmarks project? we can talk at kaigi too
[2008/06/04 20:24:21] <ko1_> ok. i'll join and discuss on it
[2008/06/04 20:24:39] @ evan set topic "design - Subject prefix of ruby-core ML"
[2008/06/04 20:24:41] <ko1_> i think we should clarify benchmarks
[2008/06/04 20:24:42] <evan> ko1_: this is yours
[2008/06/04 20:24:55] <evan> oops, sorry. i thought we were done.
[2008/06/04 20:25:07] <ko1_> ya.  anyone have objection?
[2008/06/04 20:25:14] <headius> I like prefixes myself
[2008/06/04 20:25:20] <headius> many people hate them
[2008/06/04 20:25:41] <brixen> I'm not clear on what this is
[2008/06/04 20:25:48] <headius> even when I filter to folders I like to see at a glance which emails I'm looking at
[2008/06/04 20:25:57] <brixen> is :xxxx a bug number?
[2008/06/04 20:25:58] <ko1_> last time i heard on this channel, there is no objection.
[2008/06/04 20:25:59] <drbrain> I like prefixes
[2008/06/04 20:26:03] <evan> brixen: no, message number.
[2008/06/04 20:26:07] <evan> i don't mind either way
[2008/06/04 20:26:20] <ko1_> so, i think most of developer like it.
[2008/06/04 20:26:38] <headius> no, eval('yield') {} was the bug
[2008/06/04 20:26:40] <headius> oops.
[2008/06/04 20:27:23] <evan> ko1_: shall we move on?
[2008/06/04 20:27:30] <ko1_> i want to know anyone has objection about it on developers
[2008/06/04 20:27:41] <ko1_> i post again with this result.
[2008/06/04 20:27:50] <headius> ko1_ I bet that all of them won't, but I'd like to have a prefix
[2008/06/04 20:27:52] <matz_> ah, as a list manager, it used to have subject prefix
[2008/06/04 20:27:52] <headius> ko1_  will it be [ruby-core]?
[2008/06/04 20:28:05] <ko1_> headius: yes
[2008/06/04 20:28:22] <matz_> but many complained that prefix cut threads on their readers
[2008/06/04 20:28:37] <matz_> the situation had changed since then?
[2008/06/04 20:28:55] <ko1_> on ruby-talk, i agree to cut it, but we *need* it on ruby-core to write changelog
[2008/06/04 20:29:08] <drbrain> http://rafb.net/p/lTsYlk25.html
[2008/06/04 20:29:25] <ko1_> hehe
[2008/06/04 20:29:35] <drbrain> those are the current mailers being used on the last 1000 or so messages on ruby-core
[2008/06/04 20:29:47] <drbrain> most of those track threads correctly
[2008/06/04 20:29:56] <lrz> thunderbird is popular
[2008/06/04 20:30:16] <drbrain> so is emacs
[2008/06/04 20:30:18] <headius> I use t-bird because Mail.app doesn't thread right
[2008/06/04 20:30:19] <matz_> OK, I will change the subject format for ruby-core, and see what they feel
[2008/06/04 20:30:27] <headius> matz_ excellent
[2008/06/04 20:30:39] <ko1_> thanks!
[2008/06/04 20:30:42] <evan> ok, moving on.
[2008/06/04 20:30:43] <lrz> headius: file a bug :)
[2008/06/04 20:30:46] @ evan set topic "design - Protocol to deal with security issues"
[2008/06/04 20:31:13] <ko1_> i got a message from shugo, the security ML manager
[2008/06/04 20:31:21] <headius> lrz: I think it's been filed a couple thousand times already, so I don't think it's going to change
[2008/06/04 20:31:32] <headius> anyway, off topic
[2008/06/04 20:31:33] <ko1_> shugo said "please mail me" :)
[2008/06/04 20:31:50] <ko1_> to join ML.  but this ML includes Japanese post.
[2008/06/04 20:31:56] <headius> ko1, matz_ sounds like everyone here likes the prefix, so you can proceed how you want to
[2008/06/04 20:32:11] <matz_> done
[2008/06/04 20:32:31] <headius> whose topic is this?
[2008/06/04 20:32:35] <headius> FYI, we're pushing 90 minutes now
[2008/06/04 20:32:55] <brixen> headius: this topic is listed as jruby item
[2008/06/04 20:33:05] <ko1_> please patient of Japanese post
[2008/06/04 20:33:07] <headius> hmm, I don't think it was me
[2008/06/04 20:33:09] <nicksieger> oh,  VVSiz added it
[2008/06/04 20:33:15] <nicksieger> but he's not here :)
[2008/06/04 20:33:27] <headius> OH
[2008/06/04 20:33:28] <brixen> so, we can all join the security ML?
[2008/06/04 20:33:29] <headius> I remember it
[2008/06/04 20:33:30] <headius> I can take it
[2008/06/04 20:33:44] <brixen> "all" == implementers?
[2008/06/04 20:33:44] <headius> so yes, security updates need to go out in english too I think
[2008/06/04 20:33:52] <ko1_> maybe shugo-san or matz decide it
[2008/06/04 20:33:52] <headius> we missed the webrick fix
[2008/06/04 20:33:59] <matz_> security issues
[2008/06/04 20:34:03] <ko1_> FYI. i'm not a member of that ML
[2008/06/04 20:34:07] <headius> security update list would be fine if we can read it
[2008/06/04 20:34:17] <matz_> how about some of you submit security@ruby-lang.org?
[2008/06/04 20:34:26] <evan> if there is a standard lib fix, we just need to be notified
[2008/06/04 20:34:39] <evan> there is a bigger issues on this, i'd like to bring up
[2008/06/04 20:34:42] <headius> security@ruby-lang.org would be just fine with me
[2008/06/04 20:34:53] <evan> that is, putting things like webrick into gems
[2008/06/04 20:34:59] <headius> I'm on three million lists as it is, one more isn't going to hurt
[2008/06/04 20:35:02] <evan> so that security fixes can be used by all
[2008/06/04 20:35:06] <evan> without having to upgrade
[2008/06/04 20:35:10] <matz_> ah, problem is that we talk in Japanese there, headius
[2008/06/04 20:35:24] <matz_> anyway, we will set up some place to notify you gyus
[2008/06/04 20:35:24] <headius> matz_ that could be a problem :)
[2008/06/04 20:35:45] <headius> evan I agree about the gems thing, but that's a pretty big subject
[2008/06/04 20:35:50] <ko1_> security-en@?
[2008/06/04 20:35:57] <drbrain> if you speak in ruby, we can probably get half way there :)
[2008/06/04 20:36:11] <matz_> rather we move to security-ja I guess, ko1_
[2008/06/04 20:36:11] <shugo> security-ja@ may be better
[2008/06/04 20:36:13] <evan> headius: yes, perhaps we should bring it up later
[2008/06/04 20:36:34] <evan> it's been brought up before
[2008/06/04 20:36:34] <headius> evan: agenda for next time...it wouldn't be happening overnight anyway
[2008/06/04 20:36:40] <evan> and I don't think there has been any change
[2008/06/04 20:36:44] <evan> yeah
[2008/06/04 20:36:53] <evan> just trying to solve the root of the problem.
[2008/06/04 20:37:11] <ko1_> next meeting?
[2008/06/04 20:37:21] <evan> yes
[2008/06/04 20:37:23] <matz_> at RubyKaigi?
[2008/06/04 20:37:27] <evan> 8u9hl'i
[2008/06/04 20:37:27] <evan> ack
[2008/06/04 20:37:32] <evan> that was my cat saying hi
[2008/06/04 20:37:41] <headius> it would be *sooooo* nice if we could just preinstall gems during the build
[2008/06/04 20:37:42] <evan> matz_: i'd love that
[2008/06/04 20:37:51] <headius> for most of stdlib
[2008/06/04 20:38:15] @ Quit: shugo: Nick collision from services.
[2008/06/04 20:38:20] <ko1_> 20th-22th JST is RubyKaigi
[2008/06/04 20:38:30] <matz_> I don't have Kaigi's program at hand
[2008/06/04 20:38:32] <headius> I think we're about out of time
[2008/06/04 20:38:41] <evan> shall the next meeting be at kaigi then?
[2008/06/04 20:38:46] <headius> roll call for who will be at kaigi
[2008/06/04 20:38:51] <evan> me
[2008/06/04 20:38:51] <drbrain> headius: I think some changes to RubyGems will be required
[2008/06/04 20:38:51] <matz_> ko1_:  do you think we could have any time to have IRC meeting during kaigi?
[2008/06/04 20:38:52] <ko1_> off-line or on-line/off-line mixing?
[2008/06/04 20:38:53] <headius> tom enebo and I will be there
[2008/06/04 20:39:04] <evan> ko1_: mix if we can
[2008/06/04 20:39:06] <ko1_> matz: we can do it
[2008/06/04 20:39:15] <matz_> on which day?
[2008/06/04 20:39:18] <headius> drbrain I like the idea proposed about a site install process
[2008/06/04 20:39:42] <evan> drbrain: i'm working on the 'preinstall spec' problem right now.
[2008/06/04 20:40:18] <matz_> ko1_:  6/20? 21?
[2008/06/04 20:40:21] <drbrain> if there is a separate "stdlib gems" repo it is easy
[2008/06/04 20:40:32] <ko1_> but matz is very popular so people don't free him
[2008/06/04 20:40:52] <ko1_> 20 is more suitable.
[2008/06/04 20:40:56] <headius> drbrain: a ports/apt-like repository list would probably be a first step, no?
[2008/06/04 20:41:05] @ twbray joined channel #ruby-core
[2008/06/04 20:41:07] <evan> headius: we have that already
[2008/06/04 20:41:10] <drbrain> if the files live in $:, a gem cannot be activated because newer versions will be shadowed
[2008/06/04 20:41:12] <evan> headius: you can have multiple sources
[2008/06/04 20:41:15] <drbrain> ... pre-activated
[2008/06/04 20:41:45] <ko1_> 20th morning is before opning.  can you come this time?
[2008/06/04 20:41:58] <matz_> OK, next meeing will be June 20 11:00 JST
[2008/06/04 20:42:12] <matz_> anyone objection?
[2008/06/04 20:42:23] <evan> none from me!
[2008/06/04 20:42:33] <evan> it will be nice to use my voice in this meeting!
[2008/06/04 20:42:35] <ko1_> pls check flight time
[2008/06/04 20:42:38] <matz_> from Conference plave
[2008/06/04 20:42:50] <evan> I get in on the 19th
[2008/06/04 20:42:58] <headius> tom and I get in on the 19th also
[2008/06/04 20:43:07] <ko1_> good
[2008/06/04 20:43:16] <evan> ok, thats all.
[2008/06/04 20:43:19] <evan> thanks everyone!
[2008/06/04 20:43:25] <matz_> thank you guys
[2008/06/04 20:43:34] <brixen> thanks everyone
[2008/06/04 20:43:37] <n0kada> thanks