[2008/04/30 19:00:26] well I suppose we can get started [2008/04/30 19:00:33] yes, is everyone ready? [2008/04/30 19:00:37] any objections to starting? [2008/04/30 19:00:39] I can moderate if nobody else wants to [2008/04/30 19:00:48] @ crafterm_ joined channel #ruby-core [2008/04/30 19:01:00] 9pm means go in MN [2008/04/30 19:01:08] ok [2008/04/30 19:01:22] so anyone who wasn't here last time and feels like they oughta, please introduce yourselve [2008/04/30 19:01:38] and if there is any such person, maybe we should reintroduce as well [2008/04/30 19:01:52] barring that we'll jump right in [2008/04/30 19:02:16] ok...we'll take that as a no [2008/04/30 19:02:25] so, scheduling is first up [2008/04/30 19:02:30] matz_: last time you should Tanaka might be here? [2008/04/30 19:02:32] i'll keep notes again. [2008/04/30 19:02:51] maybe this is a good time to discuss europe too [2008/04/30 19:03:04] @ headius set topic "http://ruby-design.pbwiki.com/Design20080430 - Scheduling discussion" [2008/04/30 19:03:06] ? [2008/04/30 19:03:16] @ ryan_a joined channel #ruby-core [2008/04/30 19:03:18] olabini: you wanna plead your case quick? [2008/04/30 19:03:21] .chan [2008/04/30 19:03:27] yes, 3AM is maybe too late/early for olabini :) [2008/04/30 19:03:32] it will be worse in sweden [2008/04/30 19:03:42] nah. 3am is prtty ok. =) [2008/04/30 19:03:55] @ crafterm_ is now known as crafterm [2008/04/30 19:04:00] if you can deal with it, we'll stick with the time, so now's your chance :) [2008/04/30 19:04:03] I realize we can't have a time that suits everyone. I guess I'm in a minority. unless we want to have rotation scheme [2008/04/30 19:04:04] i used to work til 3am when i was living in europe :) [2008/04/30 19:04:05] this time is pretty good for me [2008/04/30 19:04:09] anyone else around GMT want to plead their case? [2008/04/30 19:04:16] olabini: maybe you meant Akinori. 1.8 branch maintainer [2008/04/30 19:04:17] headius: me too. [2008/04/30 19:04:28] znz: can you stop the biff bot for a while? [2008/04/30 19:04:32] nicksieger: yeah, sorry. [2008/04/30 19:04:34] whatever rotation we'd do I think .jp would have to be when matz + rubycore can attend [2008/04/30 19:04:49] so it would either be odd hours for US or EU [2008/04/30 19:04:55] it's in the morning here. [2008/04/30 19:05:05] headius: yup. well. I can deal with this. [2008/04/30 19:05:07] ok [2008/04/30 19:05:08] so we can shift afterwards for some hours [2008/04/30 19:05:10] so lets go on [2008/04/30 19:05:14] we'll move on to figuring out next meeting then [2008/04/30 19:05:32] ok, let's decide the date. [2008/04/30 19:05:35] everyone from JRuby will be at JavaOne next week...we can probably find someplace to jump in, but it won't be all of us [2008/04/30 19:05:35] ok, 2 weeks from today is the 14th [2008/04/30 19:05:48] do we like this Thursday morning/Wednesday evening schedule? [2008/04/30 19:05:58] I do [2008/04/30 19:06:02] yeah [2008/04/30 19:06:17] 15th is not convenient for me [2008/04/30 19:06:19] @ dje joined channel #ruby-core [2008/04/30 19:06:24] what works for you matz [2008/04/30 19:06:41] 7,8,14,16 [2008/04/30 19:06:47] JST [2008/04/30 19:07:03] ok, shall we push it forward one day [2008/04/30 19:07:10] to the 15th/16th [2008/04/30 19:07:13] same time of day [2008/04/30 19:07:36] so that would be thursday US, friday EU/JP [2008/04/30 19:07:42] next time, yes [2008/04/30 19:07:46] works for me [2008/04/30 19:07:49] 16 Japan 15, US [2008/04/30 19:07:54] ok [2008/04/30 19:08:02] any opposed? [2008/04/30 19:08:08] I'll opt out of that one, it's a fly-day [2008/04/30 19:08:23] is two week interval OK? [2008/04/30 19:08:24] but I won't veto [2008/04/30 19:08:40] oh, i have a team meeting late afternoon, i may not be able to join, but it's not a big deal [2008/04/30 19:08:46] two week works well for me [2008/04/30 19:08:47] matz_: maybe two week by default, but we can decide based on other schedules [2008/04/30 19:08:51] like not during railsconf [2008/04/30 19:08:58] OK [2008/04/30 19:08:59] meeting by meeting [2008/04/30 19:09:38] ok then, same time (11AM JST) on the 16th [2008/04/30 19:09:41] (15th US [2008/04/30 19:09:42] ) [2008/04/30 19:10:04] we'll move on [2008/04/30 19:10:12] @ headius set topic "http://ruby-design.pbwiki.com/Design20080430 - Action item review" [2008/04/30 19:10:13] ok. [2008/04/30 19:10:26] I'll go first, since I punted mine to vladimir [2008/04/30 19:10:37] vladimir posted the list of 1.8.7 spec failures [2008/04/30 19:11:08] I think akira was able to finally get specs to run? [2008/04/30 19:11:09] ok, is there a next step needed by us? [2008/04/30 19:11:19] @ MenTaLguY joined channel #ruby-core [2008/04/30 19:11:22] @ brixen_ is now known as brixen [2008/04/30 19:11:23] I'm sure knu saw that message [2008/04/30 19:11:27] hello [2008/04/30 19:11:38] matz_: are the failures being discussed on ruby-dev at all? [2008/04/30 19:11:47] not much discussion yet on ruby-core [2008/04/30 19:12:13] We talked about segv on Kernel method [2008/04/30 19:12:15] we would like to start adding 1.8.7 features but we worry about failures and don't want to waste effort [2008/04/30 19:12:21] and merged Guy's patch [2008/04/30 19:12:54] there are obviously a lot of failures [2008/04/30 19:13:00] maybe just good behavior changes [2008/04/30 19:13:09] but we don't know for certain [2008/04/30 19:13:13] I have not heard about the roadmap to make 1.8 to adopt spec [2008/04/30 19:13:34] let me talk with knu [2008/04/30 19:13:40] ok [2008/04/30 19:13:45] I asked him to attend this meeting [2008/04/30 19:13:56] but he couldn't make it I guess [2008/04/30 19:13:57] so action item for matz: talk to knu about plans for specs and failures? [2008/04/30 19:14:08] yeah [2008/04/30 19:14:09] we are all willing to help too [2008/04/30 19:14:36] ok, what else...checking items [2008/04/30 19:14:47] headius: spec split off update if you want [2008/04/30 19:15:02] ok, and you can talk about your action item too [2008/04/30 19:15:23] headius: are you going to change topic of channel for each item like last time? [2008/04/30 19:15:24] so, we have a slice for rubyspec.org and I'll have redmine up there hopefully tomorrow [2008/04/30 19:15:32] oh yes [2008/04/30 19:15:39] well it's just action item review now [2008/04/30 19:15:50] brixen: ok, continue [2008/04/30 19:15:54] I've got repos ready at github, and I just reorg'd the dir structure of mspec so it can be a gem [2008/04/30 19:16:10] I haven't announced yet because I want to avoid some confusion with these last touch ups [2008/04/30 19:16:19] plan to announce and split off in the next couple days [2008/04/30 19:16:24] wow [2008/04/30 19:16:26] really split off? [2008/04/30 19:16:29] or split off mspec? [2008/04/30 19:16:42] both, barring any unforeseen messes :) [2008/04/30 19:16:58] that's great [2008/04/30 19:17:00] ahead of the last schedule I heard [2008/04/30 19:17:30] so I didn't see an update from you to ruby-core...was that basically because of this work? [2008/04/30 19:17:37] yes [2008/04/30 19:17:43] seems fair to me :) [2008/04/30 19:17:49] trying to avoid prematurely getting people confused [2008/04/30 19:18:14] well, that's great news to me :) [2008/04/30 19:18:34] ok, we'll move on from action items to agenda [2008/04/30 19:18:44] also, we've had a little pickup in traffic on rubyspec ML and some conversations in #rubyspec [2008/04/30 19:18:52] just to remind folks that those resources are there [2008/04/30 19:19:05] yeah, can we just bump forward your action item from last week then? [2008/04/30 19:19:13] yes, please do [2008/04/30 19:19:14] that info would all come out, and we'd all blog it and spread the word too [2008/04/30 19:19:21] sounds good [2008/04/30 19:19:32] ok...anything else? [2008/04/30 19:19:42] nope, unless there are questions [2008/04/30 19:20:06] Was someone going to make a make target for MRI? [2008/04/30 19:20:23] there wasn't an item for it yet...but that's probably part of knu discussion [2008/04/30 19:20:30] yeah ok [2008/04/30 19:21:10] ok, we'll move on now [2008/04/30 19:21:20] all items are addressed [2008/04/30 19:21:48] huzah [2008/04/30 19:21:49] I think continuous integration is going to depend on specs somewhat [2008/04/30 19:22:02] anyone want to try discussing that without knu here? might be no point [2008/04/30 19:22:13] hi [2008/04/30 19:22:21] knu! welcome [2008/04/30 19:22:21] here he is! [2008/04/30 19:22:39] I'm on the to office now... [2008/04/30 19:22:49] on the way [2008/04/30 19:23:04] should we wait to talk to you until later? [2008/04/30 19:23:17] this tiny keyboard is killing me but it's ok [2008/04/30 19:23:34] please move on [2008/04/30 19:23:35] we'll wait, it's ok [2008/04/30 19:23:41] so then [2008/04/30 19:23:42] MacRuby [2008/04/30 19:23:52] @ headius set topic "http://ruby-design.pbwiki.com/Design20080430 - MacRuby syntax discussion" [2008/04/30 19:23:59] lrz: it's all yours [2008/04/30 19:24:31] ok, i didn't add this point to the agenda [2008/04/30 19:24:41] what do you want to know? [2008/04/30 19:24:43] ok, can you give us an overview though? [2008/04/30 19:24:44] i rolled it from last time [2008/04/30 19:24:49] it as my item. [2008/04/30 19:24:53] it [2008/04/30 19:24:56] er ok [2008/04/30 19:25:03] evan: overview ok? [2008/04/30 19:25:10] ah okay [2008/04/30 19:25:21] mainly concerning discussion of keeping everyone on the same page in terms of syntax [2008/04/30 19:25:43] perhaps that means putting the MacRuby syntax into 1.9 [2008/04/30 19:25:53] ok, I see what you're saying [2008/04/30 19:25:56] ok, so macruby extends the parser to allow the definition of methods using named parameters [2008/04/30 19:25:57] i don't know, thats why I put it on the list. [2008/04/30 19:26:06] it is the only syntax change [2008/04/30 19:26:20] lrz: using : assoc syntax? [2008/04/30 19:26:40] when using this path, macruby will determine the method name to be registered according to the "named parameters" [2008/04/30 19:26:45] tom made a similar change to our parser for duby (experimental ruby-like language) using tassoc [2008/04/30 19:27:11] what does the macruby syntax for named parameters look like? [2008/04/30 19:27:15] yes, for example: def do_something(arg1, with:arg2) # will register do_something:with: [2008/04/30 19:27:33] and the syntax for calling them? [2008/04/30 19:27:34] I see [2008/04/30 19:27:40] I still feel little against having dynamically determined calling syntax [2008/04/30 19:27:50] it is briefly documented in http://trac.macosforge.org/projects/ruby/wiki/MacRubyTutorial#SendingMessages [2008/04/30 19:27:54] the duby change was def do_something(arg1 => whatever) [2008/04/30 19:27:59] no : tassoc in 1.8 parser [2008/04/30 19:28:06] headius: this syntax is also supported [2008/04/30 19:28:21] One idea for the tASSOC modification is the concept of metadata ala P3K [2008/04/30 19:28:23] matz_: i am still thinking about it, i may change it [2008/04/30 19:28:25] very interesting [2008/04/30 19:28:47] matz_: can you explain? I don't understand [2008/04/30 19:29:08] well, if you see "foo(1, bar: 2)" [2008/04/30 19:29:31] it might mean "foo(1, {:bar => 2})" or [2008/04/30 19:29:52] invoke "foo:bar:(1,2)" objective-c method [2008/04/30 19:29:54] foo:bar:(1,2) [2008/04/30 19:30:01] depending on having foo method [2008/04/30 19:30:01] yes [2008/04/30 19:30:04] right...I understand [2008/04/30 19:30:05] matz_: thats not so much the syntax, but instead what the syntax means [2008/04/30 19:30:10] can't we just have objective-c methods take their arguments as foo(1, {:bar => 2}) always? [2008/04/30 19:30:21] evan is correct [2008/04/30 19:30:21] in tom's duby parser change Ruby just ignored the syntax if it saw it [2008/04/30 19:30:23] we cannot use hashes [2008/04/30 19:30:24] it was only annotation data [2008/04/30 19:30:26] so the syntax is unambiguous [2008/04/30 19:30:27] for a few reasons [2008/04/30 19:30:53] what are the reasons against using hashes? [2008/04/30 19:30:56] does it allow duplicated named ones? [2008/04/30 19:31:01] key ordering (fixed in 1.9) and multiple keys (cannot be fixed) [2008/04/30 19:31:05] yes [2008/04/30 19:31:08] ordering shouldn't be a problem anymore [2008/04/30 19:31:16] ah [2008/04/30 19:31:17] what about separating named arguments with ; [2008/04/30 19:31:22] for example, performSelector:withObject:withObject: [2008/04/30 19:31:26] foo(a ; b:1) [2008/04/30 19:31:31] Smalltalk has value:value method for example [2008/04/30 19:31:45] I'm not sure we want to go too far down syntax discussion here [2008/04/30 19:31:51] is there a need for mixing named and unnamed arguments? [2008/04/30 19:31:52] but you can do [2008/04/30 19:31:54] agreed [2008/04/30 19:31:55] [foo bar] [2008/04/30 19:32:01] foo(1, {:bar => 1, :bar => 2}) [2008/04/30 19:32:08] the node tree for that will have both bars [2008/04/30 19:32:13] it's not until later than there is only one [2008/04/30 19:32:17] true [2008/04/30 19:32:20] it would take too much time to make up ideas here [2008/04/30 19:32:21] yeah but this is not a hash anymore [2008/04/30 19:32:23] you don't actually have to *instantiate* the hash [2008/04/30 19:32:24] I guess it's obvious that everyone feels there is a need for it. [2008/04/30 19:32:25] perhaps we need an action item to have a longer discussion on ruby-core...though there was one thread already [2008/04/30 19:32:31] from a syntax point of view, it's ordered and have have duplicates [2008/04/30 19:32:54] (named parameters, not a syntax discussion) [2008/04/30 19:32:55] I would plan to participate in a thread on this [2008/04/30 19:33:07] i could start a discussion on ruby-core [2008/04/30 19:33:12] hm, OTOH the arguments are going to get evaluated long before any call-related decisions are made [2008/04/30 19:33:16] back slightly to the reason i put on [2008/04/30 19:33:20] which was not what the syntax means [2008/04/30 19:33:21] lrz: you are open to changing, yes? based on discussions? [2008/04/30 19:33:24] but rather the syntax itself [2008/04/30 19:33:29] headius: maybe [2008/04/30 19:33:36] sounds like a good idea to take it to ruby-core [2008/04/30 19:33:38] obviously it would be ideal if the change could fit into other plans for ruby 1.9+ [2008/04/30 19:33:49] matz_: do you think that the MacRuby syntax is the same as 1.9's syntax? [2008/04/30 19:33:52] or is it different? [2008/04/30 19:33:59] evan: I guess your idea would also delay implicit hash instantiation until the method call is resolved? [2008/04/30 19:34:00] if it's different, can they be sync'd up? [2008/04/30 19:34:01] syntax rules are same [2008/04/30 19:34:09] semantics different [2008/04/30 19:34:11] yes [2008/04/30 19:34:13] yes. [2008/04/30 19:34:25] ok, lets put an action item to discuss method call semantics [2008/04/30 19:34:25] the only syntax change is very simple [2008/04/30 19:34:35] i'd rather add new syntax for new semantic [2008/04/30 19:34:43] if it could be agreed that existing ruby foo method would take priority, perhaps it's not quite as bad [2008/04/30 19:34:45] though, i would argue that since lrz using this to interface with another system, he can make up his own semantics anyway [2008/04/30 19:34:49] since it's already not Ruby. [2008/04/30 19:34:50] i thnk that matz doesn't plan to implement this until ruby 2.0, right? [2008/04/30 19:34:58] any possibility to change 1.9 semantics? [2008/04/30 19:35:14] not in 1.9 [2008/04/30 19:35:18] evan: perhaps true...but we interface with Java without new syntax, even with overloaded methods [2008/04/30 19:35:24] by using typical ruby tricks [2008/04/30 19:35:38] of course, it's not great...we'd probably like to be able to extend it [2008/04/30 19:35:45] matz: do you said about keyword arguuments? [2008/04/30 19:35:50] same here, unless for method definition [2008/04/30 19:36:05] method call semantics are a very large topic [2008/04/30 19:36:11] we could have an entire conference on it alone [2008/04/30 19:36:15] :) [2008/04/30 19:36:24] i move that we table this, and move on. [2008/04/30 19:36:27] well, I think we can constrain this to the semantics of argument passing [2008/04/30 19:36:29] if lrz starts a thread on method call stuff I will participate [2008/04/30 19:36:39] akr: basically I`m thinking about using hash [2008/04/30 19:36:44] because we have similar trouble integrating with Java we could probably address in the same discussion [2008/04/30 19:36:58] and this will come up for ironruby too [2008/04/30 19:36:58] the problem here is that macruby has different needs than mri [2008/04/30 19:37:08] how to deal with duplicated keys matz? [2008/04/30 19:37:14] because of the objc semantics [2008/04/30 19:37:41] shyouhei: duplication is not allowed for "our" keyword arguments [2008/04/30 19:37:43] lrz: as do we, with overloaded methods [2008/04/30 19:37:55] semantic mapping of foreign (objc, java) concepts to ruby syntax is a large topic [2008/04/30 19:38:01] right [2008/04/30 19:38:19] well, I say start the thread [2008/04/30 19:38:23] it will go where it goes [2008/04/30 19:38:24] I guess keywords arguments would be mapped to the formal parameters. [2008/04/30 19:38:27] okay, i will [2008/04/30 19:38:42] so they can't duplicate [2008/04/30 19:38:50] in the case of macruby, the argument names are composing the method name [2008/04/30 19:38:55] or the message that will be sent [2008/04/30 19:39:31] so action item for lrz to start the discussion thread on ruby-core [2008/04/30 19:39:42] lrz: yes, they are little bit different from simple "keyword arguments" [2008/04/30 19:40:03] matz_: yes, they are not really keyword/named arguments [2008/04/30 19:40:15] part of the selector [2008/04/30 19:40:15] headius: okay, i will do that [2008/04/30 19:40:21] maybe we could use the wiki also [2008/04/30 19:40:32] anyone else have anything on this? [2008/04/30 19:40:42] if not we can move on to MenTaLguY's item [2008/04/30 19:40:55] go ahead. [2008/04/30 19:41:04] it should be pretty brief [2008/04/30 19:41:10] ok, go for it [2008/04/30 19:41:20] basically, the current impementation of Ruby's select loop doesn't give stable sleep times across system clock changes [2008/04/30 19:41:31] @ headius set topic "http://ruby-design.pbwiki.com/Design20080430 - Scheduling: sleep, system clock" [2008/04/30 19:41:46] ah, yes [2008/04/30 19:41:50] the system select() is fine, but wakeups due to IO or other things mean that gettimeofday() is used to compute the delta [2008/04/30 19:42:41] as I noted in the minutes, using clock_gettime(CLOCK_MONOTONIC) instead of gettimeofday() when the former is available is basically sufficient to solve the problem [2008/04/30 19:42:59] there's a roughly equivalent call on Windows which escapes me at the moment [2008/04/30 19:43:13] do you have a patch to fix? [2008/04/30 19:43:31] for the sake of user libraries which implement their own select loops based on Ruby's select, it'd also be nice to expose the monotonic time to Ruby, but that's a separate issue [2008/04/30 19:43:46] I believe zimbatm submitted one to the mailing list a while back, but nobody responded [2008/04/30 19:43:51] submitted a patch, I mean [2008/04/30 19:44:05] MenTaLguY: change is needed in both 1.8 and 1.9? [2008/04/30 19:44:12] probably I have missed that one [2008/04/30 19:44:27] I believe it is required for both, yes [2008/04/30 19:44:31] I think JRuby is okay [2008/04/30 19:44:32] you have the ML reference? [2008/04/30 19:44:35] I need to check Rubinius though [2008/04/30 19:44:41] nokada: http://rubyforge.org/tracker/?func=detail&atid=1698&aid=13460&group_id=426 [2008/04/30 19:44:54] MenTaLguY: rubinius uses libev for all time related things [2008/04/30 19:44:58] which uses the monotonic clock [2008/04/30 19:45:00] JRuby would depend on whatever guarantees we get from System.currentTimeMillis [2008/04/30 19:45:05] libev! [2008/04/30 19:45:09] headius: which is really none. [2008/04/30 19:45:11] what license? [2008/04/30 19:45:13] ko1_: yep [2008/04/30 19:45:18] olabini: is nanos better? [2008/04/30 19:45:23] slightly. [2008/04/30 19:45:29] but not many guarantees there either [2008/04/30 19:45:30] we'll need to explore it then [2008/04/30 19:45:34] ko1_: it has a custom one, basically BSD. [2008/04/30 19:45:35] nanos is betterer though [2008/04/30 19:45:44] headius: specifically, all Java times are known to drift in VMs, for example [2008/04/30 19:45:44] evan: i see [2008/04/30 19:45:45] there's not much reason not to use it instead of millis [2008/04/30 19:45:48] no attached files there. [2008/04/30 19:46:15] I think I hear an action item...MenTaLguY, can you chase down a patch? [2008/04/30 19:46:22] for 1.8/1.9 I mean [2008/04/30 19:46:37] sure, I'll chase down the patch [2008/04/30 19:46:57] if it is a simple patch, I'd love to merge [2008/04/30 19:46:58] it doesn't seem so hard. [2008/04/30 19:47:14] if it requires to link new libraries, we have to discuss [2008/04/30 19:47:18] matz_: if I remember correctly, it is. the main difficulty is the autoconf test [2008/04/30 19:47:23] no libraries required [2008/04/30 19:47:30] and we need a bug filed against jruby [2008/04/30 19:47:33] 1.9 already use clock_gettime for nano second Time. librt is checked [2008/04/30 19:47:36] olabini, MenTaLguY....someone [2008/04/30 19:47:38] headius: for what? [2008/04/30 19:47:42] akr: excellent! [2008/04/30 19:47:48] for using currentTimeMillis to time out selects [2008/04/30 19:47:52] among other things [2008/04/30 19:48:17] headius: actually, selects is better in guarantee than currentTimeMillis [2008/04/30 19:48:19] but yeah [2008/04/30 19:48:34] yeah, but I think we still have it waking up and checking currentTimeMillis when a timeout is specified [2008/04/30 19:48:40] ah [2008/04/30 19:48:51] [ruby-core:15066]? [2008/04/30 19:48:52] I know we do for other things, at any rate [2008/04/30 19:48:56] so it needs an audit [2008/04/30 19:48:57] hm [2008/04/30 19:49:16] I wonder whether a DelayQueue ought to be used for JRuby sleeps, rather than trying to compensate with selector delays [2008/04/30 19:49:33] we can have that discussion, yes :) [2008/04/30 19:49:57] moving on. [2008/04/30 19:50:06] submit a patch to ruby-core (without autoconf test). [2008/04/30 19:50:10] we will merge it [2008/04/30 19:50:16] excellent [2008/04/30 19:50:21] without base64 [2008/04/30 19:50:38] ok [2008/04/30 19:50:42] I think this one is all set [2008/04/30 19:50:53] anything else on scheduling item? [2008/04/30 19:50:53] ok, I'll make a note in the minutes [2008/04/30 19:50:58] already done. [2008/04/30 19:51:13] alright then...moving on [2008/04/30 19:51:19] evan / MenTaLguY: looks like ruby-core:15066 [2008/04/30 19:51:24] as nokada said [2008/04/30 19:51:27] @ headius set topic "http://ruby-design.pbwiki.com/Design20080430 - String class in 1.9 & bytestrings" [2008/04/30 19:51:34] yeah [2008/04/30 19:51:37] I don't know whose this is...lrz? [2008/04/30 19:51:51] ah yes, this one is me [2008/04/30 19:52:05] any concern? [2008/04/30 19:52:13] okay, i have a concern about the String class in 1.9 [2008/04/30 19:52:25] which can hold encoded strings but also bytestrings [2008/04/30 19:52:49] minor correction: it's always a byte[] but encoding modifies method behavior, yes? [2008/04/30 19:52:54] i wonder if it wouldn't be better for a design point of view to have a separate class for byte strings [2008/04/30 19:53:00] i think that python3 is going into that direction [2008/04/30 19:53:11] (i may be wrong, i don't know python so well) [2008/04/30 19:53:15] ahh :) that is a big thing to wonder [2008/04/30 19:53:21] rbx has ByteArray [2008/04/30 19:53:46] this has been discussed before, during M17N work in 2007 [2008/04/30 19:53:57] lrz: I advocated as you do [2008/04/30 19:54:11] oh, this was already discussed [2008/04/30 19:54:19] sorry about that [2008/04/30 19:54:30] this needs looong discussion. [2008/04/30 19:54:42] I understand your reasons, but maybe you can explain so they're out there [2008/04/30 19:55:13] as I said headius then, I think it's better not to disclose internal representation of strings [2008/04/30 19:55:34] but in 1.9 the encoding is disclosed [2008/04/30 19:55:44] ...but also mutable [2008/04/30 19:56:25] yes, but basically forget about mutablility. [2008/04/30 19:56:37] ok [2008/04/30 19:56:40] say that you receive a string from an API, how do you know if it's a bytestring or a character string? [2008/04/30 19:57:04] that's not always distinguishable I think [2008/04/30 19:57:06] you can at runtime verify this, but by looking at the code, it may not be easy [2008/04/30 19:57:27] you can? [2008/04/30 19:57:35] and some byte string may contains ASCII sequences [2008/04/30 19:57:38] you can check encoding, but that's not the same [2008/04/30 19:57:39] byte strings have nil encoding or something? [2008/04/30 19:57:50] shyouhei: i guess you can check the encoding and bytesize [2008/04/30 19:57:51] so you might want some string operations on it [2008/04/30 19:57:53] it needs some high level knowledge. [2008/04/30 19:57:56] you can't know what the correct encoding is at least [2008/04/30 19:57:59] to some extent byte string versus encoded string is a question of intent [2008/04/30 19:58:01] matz_: correct [2008/04/30 19:58:20] that's the reason we don't have separate bytesting class [2008/04/30 19:58:28] MenTaLguY: it was decided that byte string is just another encoding [2008/04/30 19:58:36] "RAW", "PLAIN" or whatever [2008/04/30 19:58:40] ok [2008/04/30 19:58:56] lrz: is your concern made clear? [2008/04/30 19:59:07] headius: Except when it is just binary data [2008/04/30 19:59:20] matz_: yes, i can also read the m17n past discussions [2008/04/30 19:59:33] good [2008/04/30 19:59:35] is there a seperate ascii encoding from raw encoding? [2008/04/30 19:59:38] lrz: do that...I'm available to talk about it too [2008/04/30 19:59:43] @ bitsweat joined channel #ruby-core [2008/04/30 20:00:04] yes, does ascii == raw? [2008/04/30 20:00:13] some discussion was in ruby-dev [2008/04/30 20:00:18]