[2008/04/21 18:59:19] ok, I think we can probably get going [2008/04/21 18:59:27] morning. [2008/04/21 18:59:29] all declared attendees are here [2008/04/21 18:59:35] matz_: still with us? [2008/04/21 18:59:49] olabini: good morning. [2008/04/21 18:59:55] headius: bang the gavel [2008/04/21 18:59:59] hi everyone :) [2008/04/21 19:00:01] I didn't write up as an attende, but I'll be here anyway. [2008/04/21 19:00:02] *bang* [2008/04/21 19:00:05] lrz: hi there. [2008/04/21 19:00:12] lrz: evening [2008/04/21 19:00:14] so then, introductions....everyone name and impl [2008/04/21 19:00:17] OK, here I am [2008/04/21 19:00:24] hi matz_! [2008/04/21 19:00:25] hi matz! [2008/04/21 19:00:26] matz_: good morning [2008/04/21 19:00:27] implementation please :) [2008/04/21 19:00:32] <= Evan Phoenix / rubinius [2008/04/21 19:00:33] morning [2008/04/21 19:00:40] * olabini is Ola Bini, the JRuby Swedish Chef [2008/04/21 19:00:46] <= MenTaLguY / JRuby + Rubinius [2008/04/21 19:00:47] Matz / Ruby (MRI / YARV) [2008/04/21 19:00:49] <= Thomas Enebo / jruby [2008/04/21 19:00:51] Charles Oliver Nutter, JRuby [2008/04/21 19:01:00] Laurent Sansonetti, macruby [2008/04/21 19:01:29] ko1_: still with us? [2008/04/21 19:02:01] headius: it would probably be useful to change append the agenda item to the channel topic as we start in on something [2008/04/21 19:02:06] tr('mr', 'MR') [2008/04/21 19:02:12] mmm I need oppage for that [2008/04/21 19:02:13] change/append [2008/04/21 19:02:18] or somesuch [2008/04/21 19:02:33] i don't think you do, there is no protected topic in here [2008/04/21 19:02:37] oh, ok then [2008/04/21 19:02:45] @ evan set topic "http://ruby-design.pbwiki.com/Design20080421 - Introductions / scheduling" [2008/04/21 19:02:46] <= nobu nakada / Ruby [2008/04/21 19:02:47] Eric Hodel, Rubinius, RubyGems and stuff [2008/04/21 19:03:01] Tanaka Akira / Ruby [2008/04/21 19:03:13] brixen: Brian Ford, Rubinius, RubySpecs [2008/04/21 19:03:24] Koichi Sasada / Ruby/YARV [2008/04/21 19:03:25] * brixen talks to himself :) [2008/04/21 19:03:32] ok...John Lam will be unable to attend per his email [2008/04/21 19:03:45] and I think that's pretty much everyone [2008/04/21 19:03:55] so we should probably figure out scheduling first [2008/04/21 19:04:03] it was mentioned that next two tuesdays are holidays in Japan [2008/04/21 19:04:20] @ rue joined channel #ruby-core [2008/04/21 19:04:25] I have a ruby group meeting next week that would conflict as well [2008/04/21 19:04:40] but it would be nice to keep this a weekly thing...maybe we could move it a day forward? [2008/04/21 19:04:47] point of order: at 2 week intervals, the next time we would have this meeting is May 5th [2008/04/21 19:04:49] is it tuesday in japan now? [2008/04/21 19:04:57] yes [2008/04/21 19:05:00] ah yes [2008/04/21 19:05:07] May 5th/6th [2008/04/21 19:05:08] all that week tom and I will be at JavaOne...but there's no way around that [2008/04/21 19:05:11] evan: that would be JavaOne [2008/04/21 19:05:21] maybe john lam will be here instead :) [2008/04/21 19:05:24] hehe [2008/04/21 19:05:36] I have no particular preference for days [2008/04/21 19:05:39] he won't probably attend javaone :) [2008/04/21 19:05:40] It is still feasable we can attend, it will just be busy [2008/04/21 19:05:44] yes [2008/04/21 19:05:59] people in .jp, what are your feelings on date? [2008/04/21 19:06:05] perhaps this is something we want to work out on mailing list [2008/04/21 19:06:07] so john lam can jump in too [2008/04/21 19:06:10] how about May 1st? [2008/04/21 19:06:17] may 1st works for me [2008/04/21 19:06:18] @ zaki joined channel #ruby-core [2008/04/21 19:06:22] same time [2008/04/21 19:06:25] fine with me [2008/04/21 19:06:30] yeah good [2008/04/21 19:06:34] any objections? [2008/04/21 19:06:38] works for me [2008/04/21 19:06:41] I have no problem in 1st,5th [2008/04/21 19:06:42] ok. [2008/04/21 19:06:43] works for me. [2008/04/21 19:06:48] btw, i'll be updating the wiki as we go along [2008/04/21 19:06:50] with notes and such [2008/04/21 19:06:56] action item for someone: post meeting time to ruby-core [2008/04/21 19:06:59] who gets it [2008/04/21 19:07:00] 1st in PDT? [2008/04/21 19:07:04] what timezone? [2008/04/21 19:07:11] nokada: oh, good catch. [2008/04/21 19:07:12] nokada: good point [2008/04/21 19:07:17] matz_: 1st in .jp? [2008/04/21 19:07:17] JST please [2008/04/21 19:07:20] japan zone i guess [2008/04/21 19:07:29] ok, April 30th PDT. [2008/04/21 19:07:44] ok, 1st in JP, EU, 30th in US [2008/04/21 19:08:08] same hour? [2008/04/21 19:08:09] sorry for our EU friends [2008/04/21 19:08:17] same time? [2008/04/21 19:08:18] midnight? [2008/04/21 19:08:32] same time, if no one objects [2008/04/21 19:08:43] works for me [2008/04/21 19:08:54] 3 AM in EU? [2008/04/21 19:08:56] matz_: works. it's going to be impossible to find something that works for everyone [2008/04/21 19:09:04] nokada: yeah. =) [2008/04/21 19:09:07] unfortunately for EU most implementers are in jp and us [2008/04/21 19:09:31] olabini: so I guess you have to move to SF [2008/04/21 19:09:31] i'll add an agenda item for next meeting [2008/04/21 19:09:32] Softwares are made in night. [2008/04/21 19:09:34] to reconsider timing [2008/04/21 19:09:44] if eu people speak up between now and then [2008/04/21 19:09:50] @ macournoyer joined channel #ruby-core [2008/04/21 19:09:58] evan: ok, good idea [2008/04/21 19:10:13] action item for announce on ruby-core still up for grabs! [2008/04/21 19:10:45] OK, let's move on [2008/04/21 19:10:46] matz_: can you announce the next meeting on ruby-core when we're done? [2008/04/21 19:10:52] yes [2008/04/21 19:10:54] just want to make sure someone does it [2008/04/21 19:10:55] ok [2008/04/21 19:11:12] I suppose we can just go down the list if nobody objects [2008/04/21 19:11:45] @ headius set topic "http://ruby-design.pbwiki.com/Design20080421 - Constant lookup in Object from modules" [2008/04/21 19:11:53] evan: this is your item [2008/04/21 19:11:59] you have the ball [2008/04/21 19:12:07] thank you. [2008/04/21 19:12:23] i believe we resolved this earlier today [2008/04/21 19:12:26] we should write down the author of items [2008/04/21 19:12:32] but I wanted to double check with matz. [2008/04/21 19:12:35] yes, everyone do that in the future [2008/04/21 19:12:52] explain [2008/04/21 19:12:54] constant lookup in the form [2008/04/21 19:12:58] A::B [2008/04/21 19:13:14] if A is a class, B can be picked up from toplevel via the superclass chain [2008/04/21 19:13:20] @ cremes_ joined channel #ruby-core [2008/04/21 19:13:23] there is a warning in rb_const_get_0 [2008/04/21 19:13:56] is there i desire to remove lookup from the toplevel, or is the warning simply to let the programmer know it is doing something they might not want [2008/04/21 19:14:00] ? [2008/04/21 19:14:03] er. is there a desire [2008/04/21 19:14:11] class B; end; class A; end; A::B [2008/04/21 19:14:14] could you give a small code snippet? [2008/04/21 19:14:25] evan: correct? [2008/04/21 19:14:31] yes, enebo has it. [2008/04/21 19:14:32] this came up because module A; end; module B; end; A::B produces a const missing error [2008/04/21 19:14:41] (irb):1: warning: toplevel constant B referenced by A::B [2008/04/21 19:15:00] some warnings are to indicate that things will change in the future [2008/04/21 19:15:04] is this one of them? [2008/04/21 19:15:08] the difference in behavior is in question, and the warning seems to indicate it's deprecated behavior [2008/04/21 19:15:09] @ yugui joined channel #ruby-core [2008/04/21 19:15:20] hmm [2008/04/21 19:15:36] 1.9 doesn't warn about it now. [2008/04/21 19:15:44] I didn't think about removing it [2008/04/21 19:15:50] @ mlins joined channel #ruby-core [2008/04/21 19:15:52] but it's useless anyway [2008/04/21 19:16:16] evan: 1.9 appears to allow A::B to work with modules too [2008/04/21 19:16:33] ~/NetBeansProjects/jruby ➔ ../ruby1.9/ruby -e "module A; end; module B; end; A::B" [2008/04/21 19:16:34] ~/NetBeansProjects/jruby ➔ ruby -e "module A; end; module B; end; A::B" [2008/04/21 19:16:34] -e:1: uninitialized constant A::B (NameError) [2008/04/21 19:16:59] odd. [2008/04/21 19:17:02] quite [2008/04/21 19:17:14] 1.8 does, 1.9 don't [2008/04/21 19:17:22] I have no idea why 1.9 don't [2008/04/21 19:17:26] :) [2008/04/21 19:17:43] a bug? [2008/04/21 19:17:48] a feature? [2008/04/21 19:17:50] we learned why 1.8 does, but this is now confusing new behavior [2008/04/21 19:17:52] bug [2008/04/21 19:17:57] the difference between class's and module's is clear, because of the superclass chain [2008/04/21 19:18:05] 1.8 constant lookup for modules ignores Object but doesn't for classes. Did that change? [2008/04/21 19:18:10] matz: pls add tests [2008/04/21 19:18:18] why 1.9 allows toplevel lookup through modules is strange. [2008/04/21 19:18:21] @ jicksta joined channel #ruby-core [2008/04/21 19:18:45] just a bug, not strange. [2008/04/21 19:18:54] wonderful. [2008/04/21 19:19:02] matz_: so officially, the module failure is correct? [2008/04/21 19:19:15] A::B with modules should not fine toplevel B, yes? [2008/04/21 19:19:20] fine=find [2008/04/21 19:19:50] Do some issues like this just need to be tabled pending investigation? [2008/04/21 19:19:57] evan: if there aren't specs for this already we'll certainly want to add them [2008/04/21 19:20:01] agreed. [2008/04/21 19:20:08] yes, I think we can table this [2008/04/21 19:20:11] should be [2008/04/21 19:20:13] @ njh joined channel #ruby-core [2008/04/21 19:20:18] We found another YARV bug [2008/04/21 19:20:25] evan: action item for you to bring it up on list for a deeper discussion? [2008/04/21 19:20:31] @ chop3 joined channel #ruby-core [2008/04/21 19:20:34] I think we've found it warrants more attention [2008/04/21 19:20:56] headius: ok. [2008/04/21 19:21:04] @ lstoll joined channel #ruby-core [2008/04/21 19:21:07] any objection to moving on? [2008/04/21 19:21:13] i will post an account of the behaviors in 1.8, 1.9, jruby and rubinius [2008/04/21 19:21:16] to ruby-core [2008/04/21 19:21:31] and we can continue the discussion there [2008/04/21 19:21:35] @ headius set topic "http://ruby-design.pbwiki.com/Design20080421 - Multi-VM API" [2008/04/21 19:21:36] and give matz_ time to consider it [2008/04/21 19:21:42] ok [2008/04/21 19:21:46] sounds good [2008/04/21 19:22:11] ok, this is my item, but it involves jruby, rubinius, and yarv-based impls [2008/04/21 19:22:15] OK, they are bugs. I'll fix them [2008/04/21 19:22:18] let's move on [2008/04/21 19:22:23] @ SenorProg joined channel #ruby-core [2008/04/21 19:22:27] MVM support [2008/04/21 19:22:43] is there any issue? [2008/04/21 19:22:49] API? [2008/04/21 19:22:58] Sun and U Tokyo are officially cooperating on this...unofficially we obviously want all implementers to sign on too [2008/04/21 19:23:14] I would like to discuss next steps for us to get this under way [2008/04/21 19:23:15] headius: what does it involve? [2008/04/21 19:23:18] it's been "sleeping" mostly [2008/04/21 19:23:26] API? shared Ruby libraries? [2008/04/21 19:23:29] Ruby level common API, right? [2008/04/21 19:23:32] olabini: well, that's part of what we're trying to define [2008/04/21 19:23:42] a reasonable API seems the most important thing [2008/04/21 19:23:43] what MVM actually will mean, and then what the API should look like [2008/04/21 19:23:50] at least a basic idea of what we want to aim for [2008/04/21 19:24:06] evan: can you describe what you have for MVM now in rubinius, and then I'll describe JRuby [2008/04/21 19:24:11] certainly. [2008/04/21 19:24:24] the implementation in Rubinius is a quick hack, but works to a certain degree [2008/04/21 19:24:53] the API is simple [2008/04/21 19:25:04] vm = Rubinius::VM.spawn argv_for_new_vm [2008/04/21 19:25:13] the new VM shares nothing with the current VM [2008/04/21 19:25:35] the new VM is 'booted' from scratch, passing the Array given as ARGV to the new VM [2008/04/21 19:25:52] there is a simple mechanism to communicate between VMs [2008/04/21 19:26:01] then, communicates thru pipe? [2008/04/21 19:26:01] using a single mailbox per VM [2008/04/21 19:26:13] in rubinius they're all in the same process [2008/04/21 19:26:17] one native thread per MVM [2008/04/21 19:26:21] There are some resources depend on process such as current directory. [2008/04/21 19:26:37] akr: libc current directory, yes [2008/04/21 19:26:39] yes, it doesn't do anything with current directory [2008/04/21 19:26:41] errno, etc. [2008/04/21 19:26:43] @ wifelette_ joined channel #ruby-core [2008/04/21 19:26:50] @ Quit: macournoyer: Read error: 104 (Connection reset by peer) [2008/04/21 19:26:54] it has the same 'problems' as pthread in other words. [2008/04/21 19:27:05] signal is sent to a process, not vm [2008/04/21 19:27:10] I can describe JRuby's approach now also [2008/04/21 19:27:13] headius: it seem like this ties in with our problems in handling of system/` too. [2008/04/21 19:27:17] yes, signals are a big question mark [2008/04/21 19:27:26] because signals and threads behave so badly together [2008/04/21 19:27:28] @ macournoyer joined channel #ruby-core [2008/04/21 19:27:39] akr: we have some ideas for these issues [2008/04/21 19:27:42] so JRuby has very complete and full-features MVM support..everything works, and this is how people deploy Rails on JRuby now [2008/04/21 19:27:46] evan: any applications using mvm feature? [2008/04/21 19:27:53] stdin, stdout, stderr, rlimit, umask, ... [2008/04/21 19:28:03] ko1_: no. no application using Rubinius yet. :) [2008/04/21 19:28:07] the API is not simple, and very JRuby-specific [2008/04/21 19:28:11] evan: :) [2008/04/21 19:28:19] require 'java'; ruby = org.jruby.Ruby.new_instance ... [2008/04/21 19:28:23] the rubinius API can be completely changed [2008/04/21 19:28:33] no one depends on it [2008/04/21 19:28:41] it's all through Java integration...you can call any Java object, so you can instantiate and call JRuby instances [2008/04/21 19:28:42] headius: your API should not shared :) [2008/04/21 19:28:57] and the API will fall into line with the API we all decide on [2008/04/21 19:28:58] ko1_: we definitely want to standardize [2008/04/21 19:29:05] JRuby also have support for Sandbox, if that API is more pleasent. [2008/04/21 19:29:10] evan has a good start on a pretty clean API [2008/04/21 19:29:15] headius: sure, only joke [2008/04/21 19:29:16] yes, ola implemented _why's sandbox for JRuby [2008/04/21 19:29:19] but it's not being used [2008/04/21 19:29:39] headius: why? [2008/04/21 19:29:44] headius: unstable? [2008/04/21 19:29:50] quick point of order: I believe that one discussion about MVM was the API for communicating between VMs [2008/04/21 19:29:55] in fact, any usage of `ruby something.rb` will usually start a new JRuby in the same process. [2008/04/21 19:29:56] no need really...all rails apps mostly need a full runtime, so we just give them a full runtime [2008/04/21 19:30:11] i'd push us to make that API very simple [2008/04/21 19:30:13] yes, we catch backquote and system calls to stay in the same JVM [2008/04/21 19:30:16] olabini: That is one major use-case [2008/04/21 19:30:22] and allow us to layer things such as DRb on top of the API [2008/04/21 19:30:26] @ mrneighborly joined channel #ruby-core [2008/04/21 19:30:32] the inter-VM API is entirely missing in JRuby [2008/04/21 19:30:40] as are control APIs [2008/04/21 19:30:41] I believe ko1_ Also wanted MVM for preventing namespace-pollution [2008/04/21 19:31:02] JRuby handles current directory by keeping it as state on the VM instance [2008/04/21 19:31:05] for the namespace issue you really start needing some more of the Sandbox facilities [2008/04/21 19:31:09] rather than using process-level current dir [2008/04/21 19:31:10] VM.spawn seems simple and good enough. [2008/04/21 19:31:18] nokada: agreed. [2008/04/21 19:31:36] nokada: some small communication efforts sounds reasonable, though. a mailbox like evan has. [2008/04/21 19:31:51] I think a top-level VM module to host this and other APIs would be good to have [2008/04/21 19:31:59] the APIs as defined in rubinius are a good start [2008/04/21 19:32:03] I'm not sure about that mailbox [2008/04/21 19:32:08] we can support sharing methods in some levels [2008/04/21 19:32:12] to wrap up the last couple parts about the rubinius API: [2008/04/21 19:32:22] a Rubinius::VM object has stdin, stdout, stderr [2008/04/21 19:32:30] which are pipes for the sub-VMs main IO [2008/04/21 19:32:34] @ Quit: SenorProg: [2008/04/21 19:32:45] there is a Rubinius::VM.get_message, which gets any message sent to the current VM [2008/04/21 19:32:57] ko1_: sharing methods ... Can you describe that more? [2008/04/21 19:32:58] and Rubinius::VM#<< sends a message to another VM [2008/04/21 19:33:07] evan: what about life time? can a sub-vm keep the process alive after that "main" Rubinius has died? [2008/04/21 19:33:09] 1. no share, 2. send marshal object, 3. send reference like dRuby [2008/04/21 19:33:16] << understand Array, String, Symbol, Numbers, and thats all [2008/04/21 19:33:18] via stdin? [2008/04/21 19:33:30] 2.1 using Mailbox, 2.2 using pipe, ... [2008/04/21 19:33:45] olabini: currently, no, but thats only because i never fleshed out the semantics for that. [2008/04/21 19:33:49] evan: how do you handle synchronization on the mailbox? are there any order guarantees? [2008/04/21 19:33:53] nokada: inter-VM messages use internal message queues in Rubinius [2008/04/21 19:34:05] ko1_: 3. seems like it could be implement via druby no? [2008/04/21 19:34:07] olabini: no order guarantee [2008/04/21 19:34:09] the major difference between pipe and mailbox would be....? [2008/04/21 19:34:11] ok [2008/04/21 19:34:21] headius: avoiding the need to unpack primitives? [2008/04/21 19:34:24] but syncronized for mailbox safety using a mutex inside the VM [2008/04/21 19:34:27] evan: well, messages from the same sender are guaranteed to be in order with respect to one another, but that's all [2008/04/21 19:34:30] enebo: yes [2008/04/21 19:34:34] what would be the difference vs druby? [2008/04/21 19:34:42] Are file descriptors in other VMs closed for child process by system? [2008/04/21 19:34:43] MenTaLguY: correct. [2008/04/21 19:34:43] MenTaLguY: good enough for me. =) [2008/04/21 19:34:50] ko1_: So that may not need to be explicitly part of VM design since it would just work [2008/04/21 19:35:01] akr: in Rubinius? no, because there is only one file descriptor table per process. [2008/04/21 19:35:01] enebo: but more efficiently [2008/04/21 19:35:06] ko1_: Ah I see [2008/04/21 19:35:37] at least, we need 1 and 2 level sharing methods [2008/04/21 19:35:44] ko1_: a druby like protocol could be build upon 1. and 2. [2008/04/21 19:35:44] having a higher level API than a simple pipe is good [2008/04/21 19:35:53] evan: +1 [2008/04/21 19:36:00] headius: yes [2008/04/21 19:36:03] because it allows the implementation to marshal in whatever form is easiest for it [2008/04/21 19:36:16] I also agree with providing an API for sending integral message types directly [2008/04/21 19:36:21] tony and I have been looking at wiring in actors to the inter-VM messaging [2008/04/21 19:36:22] array, string, fixnum [2008/04/21 19:36:23] have a pipe means all impl's might have the same byte protocol [2008/04/21 19:36:28] but thats not important [2008/04/21 19:36:28] evan: i'm not sure that pipe is good enough [2008/04/21 19:36:33] If there are long running processes, some pipe may have problem with EOF. [2008/04/21 19:36:34] MenTaLguY: that shouldn't be hard. [2008/04/21 19:36:35] headius: hash [2008/04/21 19:36:37] ko1_: i agree, i don't think it is. [2008/04/21 19:36:51] it rubinius, they don't actually use a pipe [2008/04/21 19:37:00] but good for primitive common api [2008/04/21 19:37:00] there is a single mutex that protects each mailbox [2008/04/21 19:37:07] olabini: there are some subtle details around what you marshal and what you don't; you need to catch actor references and rewrite them when they are passed across VM boundaries, for example [2008/04/21 19:37:10] which a VM uses to receive messages [2008/04/21 19:37:13] mm. [2008/04/21 19:37:22] right- [2008/04/21 19:37:41] as headius said, i don't think that the API should support sending objects [2008/04/21 19:37:48] it should only support simple types [2008/04/21 19:37:56] Array, String, Hash, Symbol, Number [2008/04/21 19:37:57] composite types :) [2008/04/21 19:38:00] agreed [2008/04/21 19:38:11] so one question about MVM communication is basically, should we have a new byte format, use an existing, or have simpler means. [2008/04/21 19:38:18] the core types would be enough to implement any protocol on top [2008/04/21 19:38:19] Objects can simply be modeled then [2008/04/21 19:38:31] olabini: I think that can be implementation-dependent [2008/04/21 19:38:35] yes [2008/04/21 19:38:41] olabini: yes, implementation dependent [2008/04/21 19:38:41] totally impl dependent [2008/04/21 19:38:42] MenTaLguY: sure. as long as we have a base level of compatibility. [2008/04/21 19:38:45] olabini: that should be up to impl shouuldn't it] [2008/04/21 19:38:52] the API defines that you can pass a set of core object types and expect same out [2008/04/21 19:38:53] there is another issue unrelated to MVM which is marshal format [2008/04/21 19:38:55] the capabilities should match, but the transport need not [2008/04/21 19:39:06] which we can discuss some othertime. [2008/04/21 19:39:12] +1 [2008/04/21 19:39:13] event driven guy may want select-like mechanism for the communication [2008/04/21 19:39:27] i do [2008/04/21 19:39:36] akr: like "after" in Erlang? [2008/04/21 19:39:37] I like select [2008/04/21 19:39:40] Rubinius actually uses pipes for notification that a mailbax has data [2008/04/21 19:39:45] ko1_: can you share the URL for mvm work? [2008/04/21 19:39:48] @ wycats joined channel #ruby-core [2008/04/21 19:39:51] the pipe is sent '!' [2008/04/21 19:39:53] sure [2008/04/21 19:39:57] which the other VM can use to know there is data ready [2008/04/21 19:40:09] I think there's a larger discussion we should have on the MVM list [2008/04/21 19:40:15] agreed. [2008/04/21 19:40:18] we've brought out a lot of points here [2008/04/21 19:40:26] yes [2008/04/21 19:40:29] we need more experiments on each impls, don't we? [2008/04/21 19:40:34] so to summarize, rubinius has a pretty good API but the MVM impl has not been used heavily [2008/04/21 19:40:39] new action item: summerize this and post to the wiki [2008/04/21 19:40:43] JRuby has a very complete and heavily used MVM but no API [2008/04/21 19:41:06] YARV could support MVM and ko1 or someone at U Tokyo will work with Sun to help implement it [2008/04/21 19:41:10] complete except for inter-vm communication, which is non-existent [2008/04/21 19:41:11] and we'll all work to coordinate API [2008/04/21 19:41:11] Simple types communication...select-based? [2008/04/21 19:41:18] to embed JRuby into Java apps? [2008/04/21 19:41:23] ko1_: yes, that all works now [2008/04/21 19:41:35] nicksieger: not really. you just have to do it by calling methods or setting values explicitly. [2008/04/21 19:41:36] headius: i see [2008/04/21 19:41:53] olabini: yes, not in the way we're discussin here [2008/04/21 19:42:03] and some sharing of data across VM instances, but we can talk about that more on mailing list too [2008/04/21 19:42:07] JITed code, etc [2008/04/21 19:42:09] we need sample apps using MVM to determin APIs [2008/04/21 19:42:13] it would be nice to have parity on the Ruby API with a JRuby Java API that does the same thing. [2008/04/21 19:42:15] point of order: non english speakers, if we are going too fast, please tell us. [2008/04/21 19:42:17] I think there's one obvious sample app [2008/04/21 19:42:20] Rails [2008/04/21 19:42:22] we had another API: VM.fork { ... } [2008/04/21 19:42:36] an idea [2008/04/21 19:42:36] the killer app for MVM is running N rails instances in one process [2008/04/21 19:42:45] yes, i want to support VM.fork in Rubinius [2008/04/21 19:42:54] VM.fork inherits some state? [2008/04/21 19:43:05] closed variables? [2008/04/21 19:43:06] Do we like fork? [2008/04/21 19:43:08] it seems like VM.fork would need to share AST and block structure information. [2008/04/21 19:43:09] inherits all state, then they diverge [2008/04/21 19:43:12] N rails instance doesn't need inter-VM communication, right? [2008/04/21 19:43:16] it would, as like Process.fork [2008/04/21 19:43:18] being same process not not does not matter really, right? [2008/04/21 19:43:19] no, no sharing. [2008/04/21 19:43:23] should VM.fork imply copy-on-write? [2008/04/21 19:43:23] akr: "we" do not...but it depends on the definition of fork :) [2008/04/21 19:43:34] matz_: no, I don't think it does [2008/04/21 19:43:34] a complete copy of the current VM [2008/04/21 19:43:41] 1.8 could implement MVM as spawning subprocesses [2008/04/21 19:43:48] fork causes many problem. [2008/04/21 19:43:49] which would help make it ubiquitous [2008/04/21 19:43:58] so we shouldn't have both spawn and fork, I guess [2008/04/21 19:44:00] "we" meant ko1 and me. [2008/04/21 19:44:04] VM.fork may have similar problems. no? [2008/04/21 19:44:24] but it seemed difficult [2008/04/21 19:44:30] depending on what's shared, it would be difficult in JRuby...very much state to clone [2008/04/21 19:44:33] it's more complicated than .spawn [2008/04/21 19:44:35] nokada: I said VM.fork{} is difficult to impl [2008/04/21 19:44:36] some of it impossible [2008/04/21 19:44:37] consider [2008/04/21 19:44:41] io = File.open(path) [2008/04/21 19:44:43] does Windows support fork? [2008/04/21 19:44:46] VM.fork { io.read } [2008/04/21 19:44:47] headius: Though I wonder how exensive [2008/04/21 19:44:50] znmeb: no, does not [2008/04/21 19:44:58] @ jkh joined channel #ruby-core [2008/04/21 19:44:58] was the descriptor for io duped? [2008/04/21 19:45:01] though cygwin fakes it somehow I believe [2008/04/21 19:45:05] lock? [2008/04/21 19:45:06] do they point to the same kernel object? [2008/04/21 19:45:06] I am not a fan of VM.fork {} [2008/04/21 19:45:12] enebo: Java call stacks [2008/04/21 19:45:21] do threads fork? [2008/04/21 19:45:23] evan: in Jruby it could not be dupped at all since NIO structures are opaque. [2008/04/21 19:45:24] continue running? [2008/04/21 19:45:28] Are threads is copied? [2008/04/21 19:45:42] olabini: even dup'ing in C doesn't work well [2008/04/21 19:45:47] fork vs forkall [2008/04/21 19:45:47] ah.h [2008/04/21 19:45:48] akr: no [2008/04/21 19:45:50] ok, VM.fork needs to be considered further. [2008/04/21 19:45:51] headius: Yeah I was just thinking of class state...not execution state...which I guess would be less than the fork being considered [2008/04/21 19:46:04] lets continue the VM.fork discussion on the ML [2008/04/21 19:46:05] in the JRuby case, you can't necessarily know which threads you would even need to copy [2008/04/21 19:46:08] class state and starting with a fresh new main thread, perhaps [2008/04/21 19:46:09] we need more concrete examples. right? [2008/04/21 19:46:12] yes [2008/04/21 19:46:14] ko1_: yes. [2008/04/21 19:46:15] JRuby can "adopt" any native thread [2008/04/21 19:46:19] so, mailing list [2008/04/21 19:46:21] even into multiple Ruby VMs at once [2008/04/21 19:46:21] evan: even more interesting. would a fork actually fork all MVM instances then? =) [2008/04/21 19:46:24] yeah mailing list [2008/04/21 19:46:26] there are more topics to discuss [2008/04/21 19:46:36] ko1_: post the URL any time [2008/04/21 19:46:42] olabini: exactly. [2008/04/21 19:46:48] http://qwik.atdot.net/ruby-mvm [2008/04/21 19:46:48] olabini: the semantics are hard to model well. [2008/04/21 19:46:59] http://qwik.atdot.net/ruby-mvm/ [2008/04/21 19:47:01] "adopt" was another topic which we discussed. [2008/04/21 19:47:04] very. I guess that's the reason the message passing model is gaining popularity. [2008/04/21 19:47:06] excellent [2008/04/21 19:47:16] ok, we should move on [2008/04/21 19:47:25] feel free to stick around after we're done and discuss more, but the mailing list would be best [2008/04/21 19:47:36] RubySpec is next [2008/04/21 19:47:39] brixen: are you still here? [2008/04/21 19:47:42] yep [2008/04/21 19:47:51] @ headius set topic "http://ruby-design.pbwiki.com/Design20080421 - RubySpec specs and wiki" [2008/04/21 19:48:02] I added the wiki thing, but the specs are are more important [2008/04/21 19:48:10] so perhaps you could give a status update [2008/04/21 19:48:15] sure [2008/04/21 19:48:19] what's done, what's left, 1.8/1.9 [2008/04/21 19:48:30] @ Quit: njh: "Leaving" [2008/04/21 19:48:58] still working on getting an idea of completeness, but roughly 6600 examples, 23000+ expectations for 1.8 [2008/04/21 19:49:09] not yet sure how to handle 1.9, needs to be discussed [2008/04/21 19:49:25] is there a 1.9 version of (some) specs? [2008/04/21 19:49:30] what's the issues? [2008/04/21 19:49:32] ruby-core folks: do you have any count of assertions in your test suite? [2008/04/21 19:49:33] biggest question is: how can we work more directly with ruby core folks [2008/04/21 19:49:45] blessing would be nice. [2008/04/21 19:49:51] lrz: none, yet [2008/04/21 19:49:51] blessing is the thing I'm looking for [2008/04/21 19:50:01] @ gioext joined channel #ruby-core [2008/04/21 19:50:12] headius: +1 [2008/04/21 19:50:15] official blessing that the ruby-core team will use and add to the specs so we can all cooperate [2008/04/21 19:50:21] I think blessing is commitment to regularly run and contribute [2008/04/21 19:50:21] matz_, nokada, ko1_: what do you think about blessing? [2008/04/21 19:50:22] ah, what do you mean by "blessing" here? [2008/04/21 19:50:26] brixen: in macruby, i plan to use the specs very soon and would be happy to contribute 1.9 changes [2008/04/21 19:50:29] JRuby already does, IronRuby does, Rubinius does [2008/04/21 19:50:35] lrz: sounds good [2008/04/21 19:50:42] lrz: I would *love* to see 1.9 specs [2008/04/21 19:50:51] matz_: official support for the specs, possible inclusion, continious integration against specs. [2008/04/21 19:50:56] I should add, rubyspec.org will have a ticket system for specs, and I plan on having spec repo at github [2008/04/21 19:51:06] spec, not test/? [2008/04/21 19:51:07] currently i'm more concerned about the encoding changes, which are not really tested yet [2008/04/21 19:51:08] brixen: nice. [2008/04/21 19:51:10] matz_: I think all that's really needed (aside from making rubyspecs a separate, top-level project) is for you and ruby-core to agree we can all work together on them [2008/04/21 19:51:15] for 1.8, it's upto knu (Musha-san) [2008/04/21 19:51:27] knu0? [2008/04/21 19:51:28] basically 1.8/1.9 developers become comitters and run rubyspecs as part of development process [2008/04/21 19:51:33] yes [2008/04/21 19:51:41] ko1_: spec rather than runit, yes [2008/04/21 19:51:52] brixen: pick out a nice example and post URL [2008/04/21 19:51:56] for anyone that has not seen them before [2008/04/21 19:52:05] The dialogue for behavior can then be concretely represented by a piece of code which is easily run by all implementors [2008/04/21 19:52:07] mental: what's difference? [2008/04/21 19:52:07] headius: k [2008/04/21 19:52:15] @ zaki_ joined channel #ruby-core [2008/04/21 19:52:16] ko1_: you will see example [2008/04/21 19:52:27] headius: only notation? [2008/04/21 19:52:34] one problem I see is they have english descriptions [2008/04/21 19:52:41] but they are very readable in general [2008/04/21 19:52:52] ko1_: not an important difference besides the notation: spec is more of a DSL [2008/04/21 19:52:54] ko1_: the big difference is it seems a lot of effort has been put into making them as complete as possible, while doing the rubinius dev. [2008/04/21 19:52:55] i prefer the test/unit syntax, but well :) [2008/04/21 19:53:09] it's mostly notation, but also the ability to generate a specification document out of the whole suite [2008/04/21 19:53:15] ko1_: and we have many more specs written in the rspec DSL than as runit tests at this point [2008/04/21 19:53:19] I would say the notation is less important, actually. [2008/04/21 19:53:32] MenTaLguY's point is the real nice thing. [2008/04/21 19:53:33] I know it's two months away, but we would be happy to help you when we're in Japan [2008/04/21 19:53:42] pastie [2008/04/21 19:53:43] not necessarily the best example, but see: http://pastie.org/184632 [2008/04/21 19:53:53] Japanese DSL is ugly... [2008/04/21 19:54:06] hehh [2008/04/21 19:54:16] I'm afraid that [2008/04/21 19:54:30] RSpec needs more complete Ruby [2008/04/21 19:54:40] it does [2008/04/21 19:54:43] ko1_, headius: the multiVM link requires registration, which doesn't seem to work if you're not part of the mailing list for ruby-mvm. [2008/04/21 19:54:45] ko1_: we have a impl of spec [2008/04/21 19:54:46] i mean that bare (growing) ruby can't use it [2008/04/21 19:54:47] what are the requirements, brixen? [2008/04/21 19:54:58] ko1_: it's less than needed for test/unit though [2008/04/21 19:54:58] ko1_: we have our own very small rspec [2008/04/21 19:55:01] ko1_: called mspec [2008/04/21 19:55:02] ko1_: it is minimal, Object, classes, methods [2008/04/21 19:55:11] ko1_: blocks [2008/04/21 19:55:12] which can run on young ruby's [2008/04/21 19:55:17] mspec = mostly API-compatible, but much lighter [2008/04/21 19:55:22] ko1_: and procs if you want to do specs with before/after (setup/teardown) [2008/04/21 19:55:44] we wrote mspec and have been using it for about 1 year [2008/04/21 19:55:50] olabini: email me or ko1 and we'll set you up [2008/04/21 19:55:51] so it's definitly friendly to beginning impls [2008/04/21 19:56:03] * twbray thinks trans-Pacific co-operation on test suites would be a big step forward for Ruby. [2008/04/21 19:56:03] blocks are very difficult spec to impl. :) [2008/04/21 19:56:08] @ Quit: JamesKilton: "Leaving." [2008/04/21 19:56:36] ko1_: test/unit before zenspider always required a lot of functionality [2008/04/21 19:56:41] brixen: have you sent any introduction, howto, etc to ruby-core about the specs? [2008/04/21 19:56:42] <_why> if rspec can convert to a specification, couldn't it output unit/test [2008/04/21 19:56:51] ko1_: and that is why we wrote our own, very small version of rspec [2008/04/21 19:56:52] headius: not yet, no [2008/04/21 19:56:56] if not, that ought to be an action item [2008/04/21 19:57:00] ko1_: but you don't need most of blocks for mspec. just the smallest invocation part. no arguments or so [2008/04/21 19:57:12] _why: yes, but the result would not necessarily look nice [2008/04/21 19:57:13] * antares seconds twbray [2008/04/21 19:57:24] _why: if it also read the code bodies, which it tosses out for specdocs right now [2008/04/21 19:57:40] headius: mspec tosses it out. rspec doesn't. [2008/04/21 19:57:46] does someone have an online link to the mspec source? [2008/04/21 19:57:47] not totally. [2008/04/21 19:57:53] _why: a lot of the rspec DSL would have to remain, most likely [2008/04/21 19:57:59] lrz: yes, sec.. [2008/04/21 19:58:00] _why: unless you want to do deep rewriting of the AST [2008/04/21 19:58:02] i don't reject rspec, only afraid [2008/04/21 19:58:09] _why: to replace those with asserts [2008/04/21 19:58:12] MenTaLguY: that sounds fun. [2008/04/21 19:58:16] you want to replace current "test/" ? [2008/04/21 19:58:17] ko1_: we want to help you :) [2008/04/21 19:58:23] ko1_: not at all [2008/04/21 19:58:29] ko1_: no, we want to add to it. [2008/04/21 19:58:30] this is just a separate specification test suite [2008/04/21 19:58:34] lrz: http://rubyurl.com/8HRP [2008/04/21 19:58:46] it could be added to ruby-core's test, or run in addition [2008/04/21 19:58:48] ruby has 3 test suite already... [2008/04/21 19:58:49] brixen: thanks! [2008/04/21 19:58:52] in JRuby, we run it in addition [2008/04/21 19:58:56] lrz: np :) [2008/04/21 19:59:00] akr: which three [2008/04/21 19:59:06] JRuby has seven [2008/04/21 19:59:11] i agree to add 1.9 rspec [2008/04/21 19:59:12] bootstraptest, sample/test.rb test/ [2008/04/21 19:59:13] akr: JRuby has 7 [2008/04/21 19:59:15] =) [2008/04/21 19:59:26] ko1_: IronRuby, rubinius, jruby, matzruby all run the specs [2008/04/21 19:59:31] <_why> MenTaLguY: okay, just a thought [2008/04/21 19:59:34] but test/ is not very complete [2008/04/21 19:59:34] ko1_: and ruby.net is wanting to [2008/04/21 19:59:51] (we run the specs on matzruby, more specifically) [2008/04/21 19:59:57] @ Quit: macournoyer: [2008/04/21 20:00:00] brixen: Though matzruby is not being run by the developers of matzruby yet [2008/04/21 20:00:07] oh should have waited :) [2008/04/21 20:00:09] does mri 1.8 pass all tests? [2008/04/21 20:00:10] enebo: yes, that's our question :) [2008/04/21 20:00:11] brixen: i don't think it has problem to commit rspec (mrspec?) if "spec is correct" :) [2008/04/21 20:00:18] s/tests/specs [2008/04/21 20:00:28] lrz: MRI is considered the gold standard for the 1.8 specs [2008/04/21 20:00:35] it must pass them for specs to be included [2008/04/21 20:00:42] cool > gold standard [2008/04/21 20:00:46] @ rubyring left channel #ruby-core ("Leaving...") [2008/04/21 20:00:53] but this begs to question - how to handle both 1.8 and 1.9 [2008/04/21 20:00:53] currently standard is 1.8.6 p114 [2008/04/21 20:00:55] right, as headius said, we are writing them to describe what 1.8 does [2008/04/21 20:00:56] i was just wondering, sometimes a revision breaks compatibility [2008/04/21 20:01:00] can we discuss 1.8.7 then? [2008/04/21 20:01:02] Though interestingly there are 1.8 specs which fail which can be marked as "is this a bug" [2008/04/21 20:01:03] 1.8.7 does not pass specs [2008/04/21 20:01:05] ok, p114 [2008/04/21 20:01:09] it fails 60 of them. [2008/04/21 20:01:09] and if you have any concern about 1.8 behavior, just tell us. [2008/04/21 20:01:11] headius: afaik for Rubinius development it is still p111 [2008/04/21 20:01:13] olabini: there's a 1.9 subdir in the specs, but deciding on what's "correct" for 1.9 is harder [2008/04/21 20:01:24] evan: that many? I saw the enumerator failures. [2008/04/21 20:01:39] i'd have to check, but we saw a lot. [2008/04/21 20:01:42] headius: 1.9 is silver standard ? :) [2008/04/21 20:01:43] and some segfaults. [2008/04/21 20:01:49] =) [2008/04/21 20:01:50] ko1_: platinum! [2008/04/21 20:01:51] ko1_: platinum [2008/04/21 20:01:54] doh [2008/04/21 20:02:02] ko1_: the specs can only be correct if we all work together, is how we see it. [2008/04/21 20:02:09] ko1_: 1.9 is the true one :) [2008/04/21 20:02:12] on Rubinius, we try to figure out 1.8 behavior [2008/04/21 20:02:20] ok, let's consider 1.8.7 and regression testing next [2008/04/21 20:02:22] and these meetings will make doing that a lot easier [2008/04/21 20:02:23] @ Quit: twbray: [2008/04/21 20:02:25] since we're going into that [2008/04/21 20:02:42] brixen: action items to post an overview to ruby-core and could you post rubyspec mailing list info here now? [2008/04/21 20:02:50] we should have knu (knu0?) active here. [2008/04/21 20:02:54] headius: yes [2008/04/21 20:02:56] headius: added to the agenda already [2008/04/21 20:03:00] I will ask him personally next time [2008/04/21 20:03:04] how about to commit specs to MRI? [2008/04/21 20:03:06] ok [2008/04/21 20:03:06] great. [2008/04/21 20:03:07] ML for rubyspecs: http://groups.google.com/group/rubyspec [2008/04/21 20:03:12] @ cremes joined channel #ruby-core [2008/04/21 20:03:17] ko1_: we will email instructions [2008/04/21 20:03:22] it is very easy. [2008/04/21 20:03:31] nice [2008/04/21 20:03:51] since we were already going there let's talk about 1.8.6 and regression issues [2008/04/21 20:03:52] eavn: you mean spec should separate between MRI? [2008/04/21 20:03:53] er [2008/04/21 20:03:56] 1.8.7 [2008/04/21 20:04:01] was the spec suite designed to support multiple versions of ruby? [2008/04/21 20:04:09] lrz: major versions, yes [2008/04/21 20:04:20] lrz: yes [2008/04/21 20:04:23] ko1_: i misunderstood, sorry. [2008/04/21 20:04:27] cool, sorry for the stupid questions [2008/04/21 20:04:29] not really minor versions [2008/04/21 20:04:30] lrz: we have a bunch of guards that make everything play well together [2008/04/21 20:04:36] ko1_: we have all 1.8 specs together, not seperated by minor version [2008/04/21 20:04:43] er [2008/04/21 20:04:44] ko1_: but 1.8 specs are seperate from 1.9 specs [2008/04/21 20:04:45] tiny versions [2008/04/21 20:04:47] whatever [2008/04/21 20:04:51] nice :) [2008/04/21 20:04:53] lrz: spec/ruby/1.8/** (I imagine a spec/ruby/1.9 will come into being) [2008/04/21 20:04:57] sorry, yes, tiny version. [2008/04/21 20:05:06] seems like a good design [2008/04/21 20:05:08] this doc is going on rubyspec.org, but for now: http://rubinius.lighthouseapp.com/projects/5089/specs-overview [2008/04/21 20:05:34] evan: i only think that it is easy to check spec with "make check-spec" on trunk [2008/04/21 20:05:35] @ Quit: saronpasu: Remote closed the connection [2008/04/21 20:05:43] ko1_: we track the latest stable version of 1.8.x [2008/04/21 20:05:53] ko1_: exactly [2008/04/21 20:06:06] ko1_: we can integrate the rubinius specs into your make task [2008/04/21 20:06:07] with jruby, it's "ant spec" to download and run latest stable specs [2008/04/21 20:06:08] so that [2008/04/21 20:06:10] ko1: there's no reason the specs couldn't be pulled periodically [2008/04/21 20:06:19] "make check-spec" runs all specs suites [2008/04/21 20:06:20] python for example keeps python spec tests separate [2008/04/21 20:06:27] but they're pulled on checkout or build or something [2008/04/21 20:07:06] @ saronpasu joined channel #ruby-core [2008/04/21 20:07:14] so, we only need making "make" task, right? [2008/04/21 20:07:22] someone write it for MRI/trunk? [2008/04/21 20:07:22] ko1_: yes [2008/04/21 20:07:27] yes [2008/04/21 20:07:36] ant? not rake? ;) [2008/04/21 20:07:45] we can automate checking in a copy of the rubinius specs to MRI/trunk to make it simple for you. [2008/04/21 20:07:52] znmeb: rumored to be moving to rake ;) [2008/04/21 20:07:57] great :) [2008/04/21 20:08:06] ko1_: or a make task can download the latest tar.gz of specs to run [2008/04/21 20:08:10] so the specs would be hosted on svn.ruby-lang.org then? [2008/04/21 20:08:12] ko1_: the decision is up to you. [2008/04/21 20:08:33] lrz: we could make a svn version available, but I'd lobby for github [2008/04/21 20:08:45] Is there rubyspec tar.gz? [2008/04/21 20:08:49] lrz: to enable more/better participation [2008/04/21 20:08:56] ok [2008/04/21 20:08:58] akr: not right now [2008/04/21 20:08:59] akr: not yet, but we can make one [2008/04/21 20:09:00] stepped away for a moment [2008/04/21 20:09:01] akr: but will make one. [2008/04/21 20:09:10] is there a svn:externals thing to connect git to svn? [2008/04/21 20:09:16] no [2008/04/21 20:09:20] not from git to svn. [2008/04/21 20:09:22] evan: matz will decide it :) [2008/04/21 20:09:25] within git though. [2008/04/21 20:09:25] time to move on to the next subject? we could probably hash out the specifics on the list. [2008/04/21 20:09:32] ko1_, matz_, others....we want to make it as easy as possible for ruby-core to share the same specs [2008/04/21 20:09:42] olabini: yes, we will move on now [2008/04/21 20:09:43] how to add/correct spec? [2008/04/21 20:09:52] we can discuss on rubyspec list, please join there [2008/04/21 20:09:55] it would be really nice if you were also committers [2008/04/21 20:10:04] @ Quit: zaki: Read error: 110 (Connection timed out) [2008/04/21 20:10:11] I really want to get to the 1.8.7 thing [2008/04/21 20:10:18] yes. [2008/04/21 20:10:19] ko1_: we can make it easy for you, i promise. [2008/04/21 20:10:26] ko1 and I had been planning to setting up Redmine to host MRI. [2008/04/21 20:10:28] http://github.com/evanphx/rubinius/tarball/master gives all of rubinius.tar.gz, once rubyspecs becomes its own project it will be easy to get a tarball [2008/04/21 20:10:30] from github [2008/04/21 20:10:34] @ headius set topic "http://ruby-design.pbwiki.com/Design20080421 - 1.8.7 and regression testing" [2008/04/21 20:10:45] yugui: I was planning to use Redmine on rubyspec.org too [2008/04/21 20:10:46] i guess the easiest way would be to download a tarball from a make rule [2008/04/21 20:11:00] nicksieger: oh, thanks, still learning github :) [2008/04/21 20:11:19] I'm modifying redmine to integerate it with ruby-list and ruby-core. [2008/04/21 20:11:24] ok, great discussion [2008/04/21 20:11:32] So, [2008/04/21 20:11:38] brixen: action item to get rubyspecs split off :) [2008/04/21 20:11:41] so yes [2008/04/21 20:11:43] headius: check [2008/04/21 20:11:44] 1.8.7 regressions [2008/04/21 20:11:51] @ Quit: fbuilesv: "Leaving" [2008/04/21 20:12:01] I added this one [2008/04/21 20:12:12] there are numerous changes to 1.8.7 that regressed test and specs [2008/04/21 20:12:18] some are simple failures, others are segfaults [2008/04/21 20:12:24] so it will be able to integrate ruby-spec list with its the spec issue tracking. [2008/04/21 20:12:25] Should the failing specs just be put to ruby-core for discussion? [2008/04/21 20:12:30] lots of back ports from 1.9 [2008/04/21 20:12:39] rubinius folks found some of them, jruby folks found some of them...but there should be a process in place to notify everyone automatically [2008/04/21 20:13:02] I'm not really concerned about the backported features as much as the regressions..the backports are a separate debate [2008/04/21 20:13:02] brixen, evan: i'm looking forward to use it [2008/04/21 20:13:09] brixen: which redmine is suitable for ths spec [2008/04/21 20:13:10] ko1_: wonderful! [2008/04/21 20:13:11] just post the report to ruby-core [2008/04/21 20:13:11] shouldn't this be fixed once the specs will be part of the 1.8 makefile? [2008/04/21 20:13:13] ? [2008/04/21 20:13:22] lrz: theoretically, yes [2008/04/21 20:13:23] assuming they would be ran [2008/04/21 20:13:25] matz_: what about CI? [2008/04/21 20:13:26] exactly [2008/04/21 20:13:37] there is no process for regression testing and keeping tests green [2008/04/21 20:13:42] olabini: CI? [2008/04/21 20:13:45] can we have the 1.8.7 discussion w/ knu? [2008/04/21 20:13:48] continous integration. [2008/04/21 20:13:49] without rather [2008/04/21 20:13:50] matz_: does 1.9 pass all its tests righ tnow? [2008/04/21 20:13:56] no [2008/04/21 20:13:58] nicksieger: I think it's a general thing too [2008/04/21 20:14:04] yugui: I'm not understanding the question, should we discuss on ML? http://groups.google.com/group/rubyspec [2008/04/21 20:14:11] we have 3 errors in test/ruby [2008/04/21 20:14:20] quick point: zenspider and I have been building a simple setup to run all rubinius specs against all platforms and implementations [2008/04/21 20:14:23] and 11 errors from bootstrap tests [2008/04/21 20:14:25] matz_: this is very difficult for most of us to understand [2008/04/21 20:14:29] I also want to have CI for performance [2008/04/21 20:14:34] JRuby does not ship a release without all tests passing [2008/04/21 20:14:38] ko1_: that would be nice. [2008/04/21 20:14:39] ko1_: as do we [2008/04/21 20:14:49] headius: you do? [2008/04/21 20:14:51] it will run rubinius, 1.8, and jruby on platforms to report breakage automatically [2008/04/21 20:14:53] test/openssl blocks forever :-) [2008/04/21 20:14:53] we don't yet [2008/04/21 20:14:57] We want to though [2008/04/21 20:15:01] JRuby and rubinius also have continuous integration running that reports errors immediately [2008/04/21 20:15:07] akr: openssl is evil [2008/04/21 20:15:07] enebo: i see [2008/04/21 20:15:07] akr: nice. [2008/04/21 20:15:19] headius: totally agreed. [2008/04/21 20:15:33] akr: with 1.8.7? :) [2008/04/21 20:15:40] 1.9 http://www.rubyist.net/~akr/chkbuild/debian-sarge/ruby-trunk/log/20080422T042906.txt.gz [2008/04/21 20:15:40] it's not due to openssl. [2008/04/21 20:15:45] headius: not for mri? [2008/04/21 20:15:54] but yeah. having continous integration against the test suites would be very nice. but also against applications. Rails didn't even start with 1.8.7-preview1. [2008/04/21 20:15:55] nokada: doe to what? [2008/04/21 20:15:58] on the same framework? [2008/04/21 20:16:03] but 1.8.7 is still a preview [2008/04/21 20:16:05] ko1_: separate CI servers, we each set up our own [2008/04/21 20:16:11] after Thread#join timed out, next #join blocks. [2008/04/21 20:16:34] again this is more of a methodology question [2008/04/21 20:16:40] we can put regression testing in place [2008/04/21 20:16:42] we can report errors [2008/04/21 20:16:46] lrz: True, but not a preview for Rails users [2008/04/21 20:16:51] but we need to understand if those failures will be fixed [2008/04/21 20:16:52] enebo: =) [2008/04/21 20:17:27] @ aok joined channel #ruby-core [2008/04/21 20:17:32] what about sending knu a list of the failing specs [2008/04/21 20:17:34] Ruby users want a guarantee of stability on 1.8 for sure [2008/04/21 20:17:35] someone need to understand and report a problem. [2008/04/21 20:17:45] akr: yes, we can do that [2008/04/21 20:17:56] sure. [2008/04/21 20:18:06] I think most of this starts to point back to rubyspecs [2008/04/21 20:18:09] yes [2008/04/21 20:18:23] largely it does [2008/04/21 20:18:25] ideally, the specs could be ran after every 1.8 commit and failures could be reported on the ruby core list [2008/04/21 20:18:27] So for now we mail failures to ruby-core until rubyspecs is evaulated? [2008/04/21 20:18:35] lrz: that would be ideal [2008/04/21 20:18:47] how long to run rupyspec? [2008/04/21 20:18:51] one of our two CI systems could probably be set up to do that [2008/04/21 20:18:53] seconds [2008/04/21 20:18:59] on 1.8, 30 i believe. [2008/04/21 20:19:02] lrz: that would be nice. one thing that happened on Rails-core though, is that people started ignoring it and failures were not fixed. [2008/04/21 20:19:32] on this topic, issue is "who do it" ? [2008/04/21 20:19:41] ko1_: yes [2008/04/21 20:19:47] ko1_: but also, "did they want this?" [2008/04/21 20:19:54] for things like the Enumerator change [2008/04/21 20:20:06] action items: 1. get a complete list of spec failures on 1.8.7p2 to ruby-core/knu [2008/04/21 20:20:15] evan: exactly. it's sometimes hard to see what is conscious changes, and what is not. [2008/04/21 20:20:19] akr: about 20 seconds [2008/04/21 20:20:22] 2. work with ruby-core to set up a continuous integration service? [2008/04/21 20:20:27] i would say 1. manage to get the specs in the 1.8 branch, with a make rule [2008/04/21 20:20:39] 20/30 seconds is very good. [2008/04/21 20:20:48] lrz: that's going to be longer term than getting 1.8.7 released [2008/04/21 20:20:49] if only 20-30 secs to run spec, we should include it in ``make all'', I think. [2008/04/21 20:20:54] lrz: +1 [2008/04/21 20:20:55] we need an answer for 1.8.7 breakage now [2008/04/21 20:20:58] akr: actually, for me 1.8ghz macbook pro, ~15 sec [2008/04/21 20:21:14] unak: yes, that would be good [2008/04/21 20:21:16] akr: 1946 files, 6643 examples, 22072 expectations, 1 failure, 0 errors [2008/04/21 20:21:16] unak: +1 [2008/04/21 20:21:21] anyway it's much faster than test-all [2008/04/21 20:21:26] is it difficult to move specs repository to MRI repository? [2008/04/21 20:21:44] ko1_: it would be nice to keep them separate though. [2008/04/21 20:21:59] ko1_: so people can contribute to specs without MRI commit rights. [2008/04/21 20:22:04] ko1_: we would like to have rubyspec be "official" but independent [2008/04/21 20:22:06] ko1_: many more contributors to rubyspecs than to matzruby or yarv [2008/04/21 20:22:09] it seems like something that automatically pushes latest version would be better. [2008/04/21 20:22:12] ko1_: One question is right now many committers adding rubyspecs...Having it seperate means more spec writers can be involved in process [2008/04/21 20:22:25] the rubyspec copy in 1.8 could be read only (a tarball downloaded automatically, as evan suggested) [2008/04/21 20:22:32] ok :) [2008/04/21 20:22:36] lrz: right. [2008/04/21 20:22:54] brixen: how long until rubyspecs are in their own repo? [2008/04/21 20:23:07] nicksieger: I can put them on github tonight [2008/04/21 20:23:07] nicksieger: we're discussing it right now. [2008/04/21 20:23:11] I can take an action item to run the specs against 1.8.7 and put together a report [2008/04/21 20:23:16] headius: 10-4 [2008/04/21 20:23:21] probably with Vladimir's help [2008/04/21 20:23:21] nicksieger: I'm waiting on a slice to put up rubyspec.org, which is ticket + docs [2008/04/21 20:23:28] I think he may have the list already [2008/04/21 20:23:31] let's send a copy of this discussion to knu [2008/04/21 20:23:37] headius: would you prefer headius or CON in the wiki to denote you? [2008/04/21 20:23:43] CON [2008/04/21 20:24:09] @ drbrain left channel #ruby-core ("Leaving...") [2008/04/21 20:24:11] do we have time for more? [2008/04/21 20:24:13] @ drbrain joined channel #ruby-core [2008/04/21 20:24:21] anyone have an item they really want to get in? [2008/04/21 20:24:28] macruby syntax? [2008/04/21 20:24:30] 1.5 hours is pretty good amount of time [2008/04/21 20:24:30] maybe 1.8.7 will be delayed then, until all the failing specs will be fixed [2008/04/21 20:24:38] we could probably cut it off and start in next week [2008/04/21 20:24:42] yes [2008/04/21 20:24:44] it will go faster [2008/04/21 20:24:45] 6 more MINUTES! [2008/04/21 20:24:46] we shouldn't go longer than 1.5 hours [2008/04/21 20:24:55] ok [2008/04/21 20:25:00] matz_: agree? [2008/04/21 20:25:07] next meeting will be Apr. 30 [2008/04/21 20:25:18] please set up wiki agenda [2008/04/21 20:25:24] This has been very productive from my viewpoint [2008/04/21 20:25:29] me too. [2008/04/21 20:25:37] yes, thank you everyone [2008/04/21 20:25:38] very. [2008/04/21 20:25:38] thank you everyone [2008/04/21 20:25:39] matz_: thank you very much for setting this up [2008/04/21 20:25:43] thanks. [2008/04/21 20:25:45] thanks everyone! [2008/04/21 20:26:05] yes, thank you all [2008/04/21 20:26:06] please add action items and log to the wiki page. [2008/04/21 20:26:11] @ Quit: znmeb: [2008/04/21 20:26:12] drbrain will get a log file pulled and sent somewhere...ruby-core? [2008/04/21 20:26:19] thank you [2008/04/21 20:26:20] ahh, yes [2008/04/21 20:26:20] next meeting i would like to discuss 1.9 String [2008/04/21 20:26:21] log on wiki [2008/04/21 20:26:23] can pbwiki handle it? [2008/04/21 20:26:26] I'll put it on the wiki [2008/04/21 20:26:26] lrz: add an item [2008/04/21 20:26:27] matz_: Evan has been as meeting went along [2008/04/21 20:26:27] i will write an action item [2008/04/21 20:26:28] @ evan set topic "http://ruby-design.pbwiki.com/Design20080421 - See Notes and Action Items" [2008/04/21 20:26:38] lrz: agenda item, not action item :) [2008/04/21 20:26:46] i'll transfer the item missed this time to next time [2008/04/21 20:26:53] ah, sorry i'm not used to that jargon :) [2008/04/21 20:27:13] evan: Please include a continuation of rubyspecs since it will be brought again [2008/04/21 20:27:17] ok...everyone can feel free to go their own ways or stay and talk, whatever :) [2008/04/21 20:27:20] can I see MacRuby syntax extension? [2008/04/21 20:27:20] enebo: very well. [2008/04/21 20:27:24] headius: wiki access? [2008/04/21 20:27:32] ko1_: I'm also curious [2008/04/21 20:27:41] lrz: action item == something already decided, and someone has agreed to do it [2008/04/21 20:27:50] olabini: email ko1 with the address you want added [2008/04/21 20:27:57] there is ~ 1000 lines [2008/04/21 20:28:05] ok. [2008/04/21 20:28:23] yeah, rubyspec update would be good [2008/04/21 20:29:02] thank you again everyone [2008/04/21 20:29:02] if i missed anyone that needs access to the ruby-design wiki [2008/04/21 20:29:05] please give me your email [2008/04/21 20:29:15] added agenda item :) [2008/04/21 20:29:20] nicksieger: thanks for the description [2008/04/21 20:29:23] see you next week [2008/04/21 20:29:23] ola: plz send to evan :) [2008/04/21 20:29:36] matz_: thank you Matsumoto-san