[2008/05/15 18:32:11] <ko1_> i can't attend today's meeting
[2008/05/15 18:33:10] <MenTaLguY> I'm sorry to hear; we'll miss you there.
[2008/05/15 18:33:11] <matz_> do you have any idea about next snapshot?
[2008/05/15 18:39:32] <ko1_> 1.8? 1.9?
[2008/05/15 18:39:51] <matz_> 1.9
[2008/05/15 18:40:00] <matz_> 1.8 is upto knu
[2008/05/15 18:49:56] @ lrz joined channel #ruby-core
[2008/05/15 18:57:07] @ jflam joined channel #ruby-core
[2008/05/15 18:57:52] <TheProkrammer> jflam: heyya!
[2008/05/15 18:57:58] <brixen> jflam: glad you could make it
[2008/05/15 18:58:32] <jflam> hey brian - happy to be here
[2008/05/15 18:59:06] <jflam> we're syncing up to the latest ruby specs hopefully tomorrow
[2008/05/15 18:59:20] <brixen> ahh really?
[2008/05/15 18:59:24] <lrz> hi jflam & all :)
[2008/05/15 18:59:31] <jflam> hey laurent
[2008/05/15 18:59:40] <brixen> jflam: from the github rubyspecs?
[2008/05/15 18:59:45] <jflam> yep
[2008/05/15 18:59:48] <brixen> sweet!
[2008/05/15 19:00:10] <jflam> we had jim deville join our team as an SDET and he's making it happen
[2008/05/15 19:00:30] <lrz> brixen: good idea about the 1.9 specs btw
[2008/05/15 19:01:01] <brixen> lrz: cool, we really need to get some concrete code to look at
[2008/05/15 19:01:57] <brixen> jflam: there's more mspec internal docs coming, but feel free to have folks ask questions in #rubyspec if you run into problems
[2008/05/15 19:02:30] <jflam> brixen: cool - will do. btw- do the latest specs still have the optparse dependency for the target?
[2008/05/15 19:02:48] <TheProkrammer> looking forward to digging me teeth into IronRuby + rubyspecs as soon as I'm done helping with Cleveland Day of .NET :)
[2008/05/15 19:03:30] <brixen> jflam: yeah, but very simple runner script that just orchestrate the MSpec module are super easy to write
[2008/05/15 19:03:47] <brixen> jflam: we could include a simple runner
[2008/05/15 19:03:49] <jflam> TheProkrammer: awesome - i think showing testing of .NET code from Ruby will be stuff that .NET folks would like to see
[2008/05/15 19:04:23] <jflam> brixen: we're running optparse just fine now, but it would be nice to simplify that some more
[2008/05/15 19:04:53] <brixen> jflam: ah good to know. yeah, if someone needs it, we can do it
[2008/05/15 19:05:26] <brixen> evan: you going to chair the meeting?
[2008/05/15 19:06:03] @ nokada joined channel #ruby-core
[2008/05/15 19:06:14] <rue> The Options lib might be lighter-weight but it is very limited too. I think we just manually parsed until optparse ran though.
[2008/05/15 19:07:40] <brixen> jflam: out of curiosity, what sorts of things were rough to get going for optparse (helps understand hard to implement parts) ?
[2008/05/15 19:09:39] <jflam> brixen: i don't really remember all the details, but the code isn't particularly simple ...
[2008/05/15 19:09:54] <rue> And there is a lot of it :)
[2008/05/15 19:09:54] <brixen> heh, yeah I understand how that goes
[2008/05/15 19:09:57] <jflam> brixen: we've been at this for over a year now and just recently got it to work
[2008/05/15 19:10:20] @ drnic joined channel #ruby-core
[2008/05/15 19:10:33] <jflam> brixen: i think the specs could be very useful much more early in an implementation
[2008/05/15 19:10:48] <brixen> definitely
[2008/05/15 19:11:19] <lrz> yeah ideally the specs should not require too much logic such as optparse
[2008/05/15 19:11:20] <brixen> I could write a simpler version of MSpec module itself that does not use procs, just yields to blocks
[2008/05/15 19:11:39] <evan> sorry. one the phone.
[2008/05/15 19:11:41] <brixen> optparse is entirely optional from mspec
[2008/05/15 19:11:48] <evan> be there shortly.
[2008/05/15 19:12:47] <jflam> brixen: you could imagine a layered set of runners, with more features enabled as the implementation matures
[2008/05/15 19:13:04] <brixen> yep
[2008/05/15 19:13:34] <jflam> brixen: one thing that would be cool is codifying the ruby implicit conversion protocols in the specs
[2008/05/15 19:13:47] <jflam> brixen: would eliminate a whole lot of redundant specs
[2008/05/15 19:14:52] <jflam> we're thinking about putting much of the implicit conversion logic into our method binder
[2008/05/15 19:14:54] <brixen> jflam: could you post an example of that to http://groups.google.com/group/rubyspec ?
[2008/05/15 19:15:06] <jflam> and adding attributes to point out the 'exceptional cases'
[2008/05/15 19:15:22] <jflam> the 'exceptional cases' could be thought of as bugs ... eventually
[2008/05/15 19:15:23] <jflam> brixen: sure
[2008/05/15 19:15:29] <brixen> cool
[2008/05/15 19:17:39] <brixen> jflam: if you just harded coded the options in this http://pastie.org/197986 and use what's in the #run method, you'd have a simple runner
[2008/05/15 19:17:59] <brixen> most of mspec is pretty composable small bits
[2008/05/15 19:19:27] <evan> i'm here now.
[2008/05/15 19:19:38] <brixen> jflam: this is also basically just methods and instance vars http://pastie.org/197987
[2008/05/15 19:19:43] <lrz> hi evan!
[2008/05/15 19:19:45] <brixen> evan: welcome :)
[2008/05/15 19:19:50] <evan> hi guys!
[2008/05/15 19:20:02] <matz_>  so shall we start subjects on agenda?
[2008/05/15 19:20:13] <brixen> evan: you want to chair?
[2008/05/15 19:20:16] <evan> sure.
[2008/05/15 19:20:18] <lrz> i guess so
[2008/05/15 19:20:41] <evan> ok, have we been talking about item one?
[2008/05/15 19:20:50] <brixen> nope
[2008/05/15 19:21:05] <brixen> I can give background on it
[2008/05/15 19:21:06] <evan> ok, lets move to item 1
[2008/05/15 19:21:25] @ evan set topic "design - communicating ruby spec bugs"
[2008/05/15 19:21:26] <lrz> is someone logging?
[2008/05/15 19:21:33] <evan> is
[2008/05/15 19:21:39] <lrz> cool
[2008/05/15 19:21:42] <evan> drbrain will cut the log later
[2008/05/15 19:21:58] <brixen> ok, so this is an example: http://rubyspec.org/wiki/rubyspec/Bugs_found_while_writing_specs
[2008/05/15 19:22:15] <brixen> we'd like to talk about the easiest way to communicate these issues and be able to follow up on them
[2008/05/15 19:22:29] <evan> mailling list?
[2008/05/15 19:22:47] <brixen> well, from what I hear, part of the concern is followup when a bug is reported
[2008/05/15 19:23:00] <brixen> is ruby-core going to be using a bug tracker, or just mailing list?
[2008/05/15 19:23:20] <jflam> would be much better to use a bug tracker
[2008/05/15 19:23:51] @ nicksieger joined channel #ruby-core
[2008/05/15 19:23:54] <jflam> too much gets lost in my email
[2008/05/15 19:24:02] <brixen> we also do not want to deluge folks with a bunch of individual bugs when there are classes of them
[2008/05/15 19:24:14] <brixen> for example, the complex methods changing the way Math methods behave
[2008/05/15 19:24:29] <brixen> those could be reviewed and fixed as a single batch is the thought
[2008/05/15 19:25:11] <jflam> i don't think that the wiki is a very scalable way of dealing with bugs - would each lib / class / method get its own page?
[2008/05/15 19:25:15] <evan> something else to consider is how to deal with MRI changes
[2008/05/15 19:25:17] <TheProkrammer> brixen: You have a rubyforge project setup, right?  Why not use the trackers there?
[2008/05/15 19:25:21] <evan> for instance, r114 changes
[2008/05/15 19:25:24] <evan> or 1.8.7 changes
[2008/05/15 19:25:42] <evan> if the specs differ from those, are they bugs? or bugs in MRI?
[2008/05/15 19:25:43] <brixen> jflam: that wiki page is just to collect them while this is discussed. we're hoping for a bug tracker
[2008/05/15 19:26:05] <brixen> TheProkrammer: the bugs are for ruby 1.8/1.9, not the rubyspecs
[2008/05/15 19:26:06] @ _why joined channel #ruby-core
[2008/05/15 19:26:48] <jflam> evan: there are also x-plat differences to consider as well - windows doesn't get a lot of love :)
[2008/05/15 19:26:59] <matz_> we are going to setup redmine for 1.8/19 soon
[2008/05/15 19:27:01] <evan> jflam: yep
[2008/05/15 19:27:02] <TheProkrammer> brixen: Right, but it's not totally unapropos, you could set up a category for MRI say.
[2008/05/15 19:27:07] <lrz> matz_: cool!
[2008/05/15 19:27:09] <matz_> until then use ruby-core mailing list
[2008/05/15 19:27:09] <brixen> matz_: oh, that is good news!
[2008/05/15 19:27:11] <_why> apologies for tardiness
[2008/05/15 19:27:18] <brixen> _why: welcome
[2008/05/15 19:27:19] <TheProkrammer> nvm :)
[2008/05/15 19:27:34] <_why> i'm here representing unholy
[2008/05/15 19:27:50] <brixen> _why: you will not have my bytecodes
[2008/05/15 19:28:03] <brixen> matz_: ok, we'll look forward to the bug tracker
[2008/05/15 19:28:19] <evan> _why: we shall you consider the heathen of python
[2008/05/15 19:28:22] <brixen> matz_: we'll likely not post bugs like the (suggested) complex ones until that is set up
[2008/05/15 19:28:25] <jflam> _why: can we hire you as our new branding guy? we sure could use the help :)
[2008/05/15 19:28:38] <nokada> it seems like a bug that Mat.log accepts a string.
[2008/05/15 19:28:45] <nokada> Math.log
[2008/05/15 19:28:52] <brixen> nokada: yes, it seems odd
[2008/05/15 19:28:57] <NoKarma> Math.log uses Float internally
[2008/05/15 19:29:19] <nokada> I see, but it seems odd.
[2008/05/15 19:29:37] <NoKarma> when you load Complex, it breaks the whole duck typing inside of Math
[2008/05/15 19:29:40] <_why> evan: and with any luck, the pythonistas consider me much worse :)
[2008/05/15 19:29:49] <evan> _why: :)
[2008/05/15 19:30:06] <evan> so
[2008/05/15 19:30:08] <brixen> evan: so, we can consider this topic resolved I think
[2008/05/15 19:30:10] <nokada> Complex is too complex for me.
[2008/05/15 19:30:24] <evan> to summerize #1, MRI is going to use their own tracker for bugs found via rubyspec
[2008/05/15 19:30:28] <evan> correct?
[2008/05/15 19:30:29] <jflam> fixing Math.log to accept string over here now ...
[2008/05/15 19:30:48] <brixen> btw, we're using redmine on rubyspec.org, it's nice so far :)
[2008/05/15 19:30:51] <nokada> evan: true
[2008/05/15 19:31:00] <evan> ok, on to #2
[2008/05/15 19:31:17] <matz_> evan: correct
[2008/05/15 19:31:18] @ evan set topic "design - memory leak, http://rubyforge.org/tracker/?func=detail&atid=1698&aid=15425&group_id=426"
[2008/05/15 19:31:25] @ twbray joined channel #ruby-core
[2008/05/15 19:32:21] <evan> who's item is this?
[2008/05/15 19:32:33] <MenTaLguY> mine
[2008/05/15 19:32:38] * evan makes a note to have people put their name next to agenda items in the future
[2008/05/15 19:32:40] <MenTaLguY> I was asked to bring itup
[2008/05/15 19:33:07] <MenTaLguY> briefly I'm wondering if the fix given is correct
[2008/05/15 19:33:18] <matz_> IIRC, Guy Decoux told me the simple patch introduces another bug
[2008/05/15 19:33:49] <nokada> Isn't he here?
[2008/05/15 19:34:34] <matz_> no, Guy never come to public, except for mailing list
[2008/05/15 19:34:35] @ helgy joined channel #ruby-core
[2008/05/15 19:34:47] <lrz> i don't think so, it's too late in france :)
[2008/05/15 19:35:11] <nokada> indedd.
[2008/05/15 19:35:12] <brixen> NoKarma is here from germany :)
[2008/05/15 19:35:27] <NoKarma> it's 4:35 am here, yay!
[2008/05/15 19:35:50] @ helgy left channel #ruby-core ()
[2008/05/15 19:36:02] <evan> ok
[2008/05/15 19:36:07] <evan> do we need to defer this one then?
[2008/05/15 19:36:30] <evan> MenTaLguY?
[2008/05/15 19:37:03] <matz_> OK, I will check the problem.
[2008/05/15 19:37:08] <matz_> wait until next meeting
[2008/05/15 19:37:16] <MenTaLguY> yes, I think that's good
[2008/05/15 19:37:18] <evan> matz_: ok, i'll note you're going to look into it
[2008/05/15 19:37:56] <evan> ok, #3
[2008/05/15 19:38:08] @ evan set topic "design - rational/complex added in 1.9"
[2008/05/15 19:38:14] <MenTaLguY> yes, action item for matz and we can table it for now
[2008/05/15 19:38:14] <evan> who's item is this?
[2008/05/15 19:39:02] <MenTaLguY> dunno
[2008/05/15 19:39:10] <lrz> i think it's matz's?
[2008/05/15 19:39:50] <evan> anyone?
[2008/05/15 19:40:39] <matz_> yes, it's mine
[2008/05/15 19:41:06] @ olegt joined channel #ruby-core
[2008/05/15 19:41:12] <matz_> recently Japanese developers discuss a lot about rational/complex
[2008/05/15 19:42:03] <matz_> I'd like to hear opinions from others if any
[2008/05/15 19:42:06] <evan> ok, i see them on ruby-dev
[2008/05/15 19:42:09] <evan> but I can't read the messages.
[2008/05/15 19:42:10] <evan> :)
[2008/05/15 19:43:26] <brixen> matz_: could you summarize the issues?
[2008/05/15 19:43:28] <evan> matz_: could you summerize?
[2008/05/15 19:43:28] <matz_> the point is how to design complex
[2008/05/15 19:43:30] <brixen> briefly?
[2008/05/15 19:43:34] <matz_> yes
[2008/05/15 19:44:01] <matz_> we haven't got consensus about complex
[2008/05/15 19:44:02] <brixen> I think MenTaLguY has some thoughts on design of Rational
[2008/05/15 19:44:15] @ dje_ joined channel #ruby-core
[2008/05/15 19:44:24] <matz_> * C implementation of complex.rb (current)
[2008/05/15 19:44:26] <MenTaLguY> I do?
[2008/05/15 19:44:45] <matz_> * the pair of float values (ComplexFloat)
[2008/05/15 19:44:59] <matz_> * add both complex and complexfloat
[2008/05/15 19:46:53] <brixen> matz_: ComplexFloat is a new class ?
[2008/05/15 19:46:53] <evan> matz_: what is the debate about?
[2008/05/15 19:47:45] <matz_> each of three options above have their pros and cons
[2008/05/15 19:47:56] <matz_> and we just don't have consensus
[2008/05/15 19:48:09] <nokada> ComplexFloat is a new particular class
[2008/05/15 19:48:18] <brixen> matz_: I was curious about reason for moving to C implementation, is that just for speed?
[2008/05/15 19:48:32] <matz_> I personally don't want to have two separate classes for complex numbers
[2008/05/15 19:48:42] <evan> matz_: i don't want that either
[2008/05/15 19:48:44] <brixen> I do not like separate classes either
[2008/05/15 19:48:44] <evan> it's too confusing
[2008/05/15 19:48:47] <matz_> brixen:  performance, yes
[2008/05/15 19:48:50] <MenTaLguY> agreed
[2008/05/15 19:49:24] <brixen> matz_: what is the reason for ComplexFloat?
[2008/05/15 19:49:42] <matz_> complex (C translation of complex.rb) is more general
[2008/05/15 19:50:01] <matz_> but most of users just use float for complex calculation
[2008/05/15 19:50:12] <matz_> so some want have them both
[2008/05/15 19:51:01] <brixen> I don't see how Complex would differ than ComplexFloat, since a complex number is real + real * img
[2008/05/15 19:51:20] <brixen> matz_: the ComplexFloat is not in 1.9 sources, right? (I'm not seeing it)
[2008/05/15 19:51:27] <matz_> no
[2008/05/15 19:51:30] <lrz> i do not see it either
[2008/05/15 19:52:18] <brixen> I think having ComplexFloat is asking for much headache
[2008/05/15 19:52:25] <nokada> agree.
[2008/05/15 19:52:42] <evan> but complex.rb allows for Complex.new(1.0)
[2008/05/15 19:52:47] <evan> but the C Complex does not, correct?
[2008/05/15 19:52:57] <matz_> I guess so
[2008/05/15 19:53:06] <evan> looking at the source, I'd expect so
[2008/05/15 19:53:26] <matz_> OK, I am glad to hear opinion against having them both
[2008/05/15 19:53:29] <nokada> Complex.new is a private method.
[2008/05/15 19:53:32] <evan> can people who want to use float's with Complex load in complex.rb?
[2008/05/15 19:53:48] <evan> overriding the C one
[2008/05/15 19:53:53] <evan> so they can use floats
[2008/05/15 19:53:55] <evan> ?
[2008/05/15 19:54:12] <nokada> Complex(1.0) yeilds Complex(1.0, 0.0).
[2008/05/15 19:54:19] <evan> nokada: sorry, Complex.new!(1.0)
[2008/05/15 19:54:22] <evan> yes
[2008/05/15 19:54:27] @ Quit: twbray: 
[2008/05/15 19:54:29] <nicksieger> (came in late, hi) this seems like a trade-off of interface simplicity vs. implementation simplicity
[2008/05/15 19:54:47] <nokada> new! was removed
[2008/05/15 19:54:59] <brixen> 1.5.to_c => Complex.new(1.5,0.0)
[2008/05/15 19:55:09] <evan> anyway
[2008/05/15 19:55:10] <matz_> nicksieger:  hmm.  If it really so, it's a easy decision
[2008/05/15 19:55:13] <nokada> current complex.c doesn't take care of the elments.
[2008/05/15 19:55:24] <nokada> elements' classes.
[2008/05/15 19:55:52] <nicksieger> matz_: agree. but i could be over-simplifying.
[2008/05/15 19:56:49] <evan> matz_: do you have some opinions?
[2008/05/15 19:56:53] <evan> can we move on?
[2008/05/15 19:57:03] <evan> matz_: if you bring it up on ruby-core
[2008/05/15 19:57:10] <evan> we can email in opinions as well.
[2008/05/15 19:57:19] <nokada> the restriction that real and imaginary parts should belong to a same class seems reasonable.
[2008/05/15 19:57:23] <matz_> evan:  no, I am happy
[2008/05/15 19:57:27] <matz_> let's move on
[2008/05/15 19:57:30] <evan> ok.
[2008/05/15 19:57:31] <brixen> nokada: agreed
[2008/05/15 19:57:57] @ evan set topic "design - int/int -> rational ? migration path"
[2008/05/15 19:58:02] <evan> matz_: is this the same as the last one?
[2008/05/15 19:58:40] <matz_> I am not sure which "last one".
[2008/05/15 19:58:52] <evan> sorry, the one about complex
[2008/05/15 19:59:03] <evan> the agenda item for complex talks about rational too
[2008/05/15 19:59:04] <matz_> yes, it's related
[2008/05/15 19:59:19] <evan> matz_: is this your item too?
[2008/05/15 19:59:25] <matz_> yes
[2008/05/15 19:59:35] <matz_> currently int/int returns int
[2008/05/15 19:59:44] @ mtodd joined channel #ruby-core
[2008/05/15 19:59:52] <matz_> but it's kinda against polymorphism
[2008/05/15 20:00:16] <evan> do you want to go the math / python 3k route and have it return a float?
[2008/05/15 20:00:31] <nokada> rational.
[2008/05/15 20:00:48] <matz_> but I don't like "import from future" thingy
[2008/05/15 20:00:58] <evan> and rational would be a new Numeric type?
[2008/05/15 20:01:00] <evan> matz_: :)
[2008/05/15 20:01:08] <brixen> matz_: me neither :)
[2008/05/15 20:01:24] <evan> Smalltalk I believe had a Fraction class
[2008/05/15 20:01:25] <nokada> rational.c is there already.
[2008/05/15 20:01:37] <matz_> yes, rational would be new built-in numeric class
[2008/05/15 20:01:41] <brixen> int / int => rational breaks our core classes that depend on ints
[2008/05/15 20:01:41] <evan> which is what 1 / 2 would return
[2008/05/15 20:01:47] <matz_> it already is in 1.9
[2008/05/15 20:01:52] <evan> ok
[2008/05/15 20:02:02] <matz_> right
[2008/05/15 20:02:04] <evan> as long as there is a method that returns an int
[2008/05/15 20:02:15] <matz_> compatibility is my concern
[2008/05/15 20:02:18] <evan> 4.div(2) # => 2
[2008/05/15 20:02:22] <evan> a lot of code will break
[2008/05/15 20:02:28] <evan> is my guess
[2008/05/15 20:02:38] <matz_> some proposes integer division operator like //
[2008/05/15 20:02:42] <evan> unless rational can ducktype itself like a Fixnum
[2008/05/15 20:02:55] <nicksieger> evan: but still save the fractional component? yeah
[2008/05/15 20:03:07] <nicksieger> so that if you coerce it retains precision
[2008/05/15 20:03:24] <nokada> 1/2+1/2 should differ.
[2008/05/15 20:03:37] <evan> differ how?
[2008/05/15 20:03:49] <nokada> currently, it returns 0
[2008/05/15 20:04:05] <evan> ah, yes.
[2008/05/15 20:04:12] <evan> would 1/2 + 1/2
[2008/05/15 20:04:13] <nicksieger> would a lot of code break if it suddenly returned 1?
[2008/05/15 20:04:18] <evan> return a Fixnum or Rational?
[2008/05/15 20:04:20] <nicksieger> that's kind of broken already
[2008/05/15 20:05:00] <nokada> even a Fixnum or a Rational, it cannot be 0.
[2008/05/15 20:05:27] <brixen> integer division truncating and returning an integer is well-ingrained, but unfortunate I think
[2008/05/15 20:05:38] <brixen> I'd love to have ruby have a more realistic numeric tower
[2008/05/15 20:05:43] <brixen> that behaves like math
[2008/05/15 20:05:45] <TheProkrammer> seems like if mod = 0 it should be an Int (fixnum) if mod != it should be a rational/float
[2008/05/15 20:07:32] @ NoKarma_ joined channel #ruby-core
[2008/05/15 20:07:36] <brixen> it seems though that we would need something like require "newmath" to prevent breaking lots of code
[2008/05/15 20:07:57] <lrz> so to be clear, what should 1/2+1/2 return then, if not 0?
[2008/05/15 20:08:07] <evan> lrz: Fixnum 1
[2008/05/15 20:08:07] <brixen> 1
[2008/05/15 20:08:12] <matz_> currently we have mathn library to make it happen
[2008/05/15 20:08:29] <nokada> and some libraries don't consider about it.
[2008/05/15 20:08:31] <evan> yes, we know as it breaks the rubinius kernel. :)
[2008/05/15 20:08:32] <brixen> matz_: so the idea is to make mathn the standard?
[2008/05/15 20:08:41] <NoKarma_> wüst happens with 1.5/3?
[2008/05/15 20:08:46] <evan> mathn also breaks a lot of things
[2008/05/15 20:08:49] <brixen> evan: but it wouldn't break if we had //
[2008/05/15 20:08:58] <NoKarma_> *what
[2008/05/15 20:08:59] <brixen> we could do all integer math explicitly
[2008/05/15 20:09:00] <evan> because most things do not expect to get a Rational object
[2008/05/15 20:09:02] <brixen> that's a big plus
[2008/05/15 20:09:06] <evan> brixen: yes.
[2008/05/15 20:09:39] <brixen> matz_: what about leaving / integer division and // => Rational?
[2008/05/15 20:09:51] <nokada> it is hard to distinguihs from an emptly Regexp literal.
[2008/05/15 20:09:58] <brixen> ahh, indeed
[2008/05/15 20:10:05] <evan> i thought brixen typed an empty regexp actually
[2008/05/15 20:10:06] <matz_> brixen:  I didn't think about it
[2008/05/15 20:10:07] <evan> at first
[2008/05/15 20:10:08] <TheProkrammer> yeah.. an another operator seems clunky..
[2008/05/15 20:10:11] <akr> we have quo but quo is not used well
[2008/05/15 20:10:19] <TheProkrammer> Rational#to_i works no?
[2008/05/15 20:10:23] <brixen> well, something that is an operator but not an empty regexp :)
[2008/05/15 20:10:39] <brixen> 1 \\ 2 ?
[2008/05/15 20:10:40] <matz_> Rational has to_i, TheProkrammer
[2008/05/15 20:10:43] <nokada> to_i works
[2008/05/15 20:10:51] <nokada> but it is too late
[2008/05/15 20:10:53] <evan> but it breaks things because they expect Fixnum
[2008/05/15 20:10:57] <brixen> but (1/2).to_i is ugly
[2008/05/15 20:10:58] <evan> like Array#[]
[2008/05/15 20:11:17] <TheProkrammer> Ah.. hmm, was hoping the to_i would make it appear like a Fixnum for things that expected it.
[2008/05/15 20:11:42] <brixen> having an operator for integer division is important imho
[2008/05/15 20:12:08] <evan> 1 ~/ 1
[2008/05/15 20:12:09] <evan> ?
[2008/05/15 20:12:10] @ jflam2 joined channel #ruby-core
[2008/05/15 20:12:22] <matz_> brixen:  we already have a.div(b) for integer division
[2008/05/15 20:12:24] <nokada> it would be possible
[2008/05/15 20:12:28] <nokada> evan:
[2008/05/15 20:12:36] <brixen> matz_: yes, but something that looks like an operator
[2008/05/15 20:12:37] <evan> just an idea
[2008/05/15 20:12:56] <matz_> OK, let's stop endless discussion
[2008/05/15 20:12:59] <evan> ok.
[2008/05/15 20:13:00] <akr> div is floor, not truncate.  bit incompatible with current fixnum#/
[2008/05/15 20:13:01] <evan> :)
[2008/05/15 20:13:09] <matz_> if you have any operator idea, post to ruby-core please
[2008/05/15 20:13:16] <evan> matz_: ok.
[2008/05/15 20:13:20] <evan> lets move to the last item
[2008/05/15 20:13:27] <evan> since it is Numeric related
[2008/05/15 20:13:37] @ evan set topic "design - Singleton methods on Float and Bignum"
[2008/05/15 20:13:41] <evan> this is mine
[2008/05/15 20:13:57] <evan> matz_: you still think you should not be able to define singleton methods on these classes?
[2008/05/15 20:14:03] <evan> sorry, instance of these classes
[2008/05/15 20:14:22] <matz_> currently Numeric instances in general, yes
[2008/05/15 20:14:34] <matz_> just because Fixnum can't
[2008/05/15 20:14:54] <evan> can Rational or Complex?
[2008/05/15 20:15:06] <matz_> I don't want to
[2008/05/15 20:15:07] <evan> ok
[2008/05/15 20:15:13] <evan> just so long at it is consistent
[2008/05/15 20:15:21] <evan> that all Numeric subclasses can not have singleton methods
[2008/05/15 20:16:11] <evan> ok. last item.
[2008/05/15 20:16:19] <matz_> 1.9 snapshot date
[2008/05/15 20:16:21] @ evan set topic "design - next 1.9 snapshot milestone"
[2008/05/15 20:16:29] <lrz> yes, this is mine
[2008/05/15 20:16:34] <matz_> But we don't have ko1 among us
[2008/05/15 20:16:44] <lrz> i was just wondering if there is a plan for the next 1.9 snapshot
[2008/05/15 20:16:58] <matz_> ko1 will decide
[2008/05/15 20:17:02] <lrz> ah :)
[2008/05/15 20:17:13] <lrz> we can discuss this in the ml then
[2008/05/15 20:17:13] <matz_> IIRC, he was planning somewhere in June
[2008/05/15 20:17:18] <matz_> before RubyKaigi
[2008/05/15 20:17:24] <lrz> that's excellent
[2008/05/15 20:17:33] <nokada> or during it?
[2008/05/15 20:17:46] <matz_> like two years ago?
[2008/05/15 20:17:52] <matz_> perhaps
[2008/05/15 20:17:59] <matz_> but I don't recommend ;)
[2008/05/15 20:18:05] <evan> heh
[2008/05/15 20:18:26] @ ko1_ is now known as ko1_away
[2008/05/15 20:19:17] <evan> ok.
[2008/05/15 20:19:20] <evan> that is all we have.
[2008/05/15 20:19:25] <evan> lets plan next time.
[2008/05/15 20:19:50] <evan> the 29th is the first day of railsconf, many will be busy
[2008/05/15 20:19:55] <matz_> 1 week or 2 week interval?
[2008/05/15 20:20:02] <evan> i think 2 week.
[2008/05/15 20:20:09] <brixen> after railsconf sounds good
[2008/05/15 20:20:11] <evan> that is what we had been doing, yes?
[2008/05/15 20:20:12] <brixen> that would be 3 weeks
[2008/05/15 20:20:39] <matz_> 28, 30 (JST) is not convenient for me
[2008/05/15 20:20:59] <brixen> matz_: is first week of june sometime ok?
[2008/05/15 20:21:02] <evan> June 4th?
[2008/05/15 20:21:11] <evan> June 4th / 5th
[2008/05/15 20:21:18] <matz_> unless June 6th, any day OK
[2008/05/15 20:21:27] <lrz> works for me
[2008/05/15 20:21:31] <jflam2> me too
[2008/05/15 20:21:37] <matz_> OK, June 4th
[2008/05/15 20:21:44] <matz_> how about time?
[2008/05/15 20:21:48] <matz_> same time OK?
[2008/05/15 20:21:52] <evan> ok, same time of day, June 4th PDT, June 5th JST
[2008/05/15 20:21:53] <evan> yes?
[2008/05/15 20:21:56] <evan> er. PST
[2008/05/15 20:21:59] <nokada> OK
[2008/05/15 20:22:03] <jflam2> yep
[2008/05/15 20:22:16] <evan> ok, i'll put up the next wiki page for that date
[2008/05/15 20:22:32] <matz_> OK, next time we have to set up agenda little bit earlier
[2008/05/15 20:22:50] <matz_> thank you for input
[2008/05/15 20:22:50] <evan> yes
[2008/05/15 20:22:53] <evan> matz_: thonk you.
[2008/05/15 20:22:56] <evan> thank.
[2008/05/15 20:23:00] <evan> i don't know what a thonk is.
[2008/05/15 20:23:05] <brixen> thanks everyone
[2008/05/15 20:23:14] @ Quit: jflam: Read error: 110 (Connection timed out)
[2008/05/15 20:23:34] <lrz> thanks everybody!
[2008/05/15 20:23:38] <jflam2> thanks
[2008/05/15 20:24:11] <matz_> thank you!
[2008/05/15 20:24:51] @ Quit: NoKarma_: Remote closed the connection
[2008/05/15 20:25:06] <nokada> thanks.