Show enters and exits. Hide enters and exits.
| 00:03:13 | wdperson enters the room. | |
| 00:04:30 | seydar | so you don't happent to be well versed in the ways of generating C code, do you? |
| 00:04:58 | lstoll enters the room. | |
| 00:05:15 | djwhitt | seydar: read the logs headius has been talking about that a bit |
| 00:05:42 | seydar | not cool! _I_ wanted to do that |
| 00:05:45 | lstoll leaves the room. | |
| 00:05:55 | seydar | my life is meaningless |
| 00:05:58 | lstoll enters the room. | |
| 00:06:47 | djwhitt | seydar: I think he's just working on proof of concept stuff right now |
| 00:06:57 | djwhitt | seydar: I'm sure there will be plenty for you to do |
| 00:07:19 | seydar | still, i can't even get the proof of concept down |
| 00:07:27 | seydar | i feel like i need to know more C |
| 00:07:37 | seydar | so in the car today, i was like "Ruby -> Haskell!" |
| 00:07:49 | djwhitt | proof of concept might be the hardest part |
| 00:07:58 | djwhitt | once you have code to work with I imagine it'll be easier |
| 00:08:11 | headius | this is doing most of the typing logic for you |
| 00:08:50 | headius | pastie |
| 00:09:02 | pastie | http://pastie.org/170029 by headius. |
| 00:10:01 | headius | there's much better abstraction to be done, but that's basically what you implement for a given backend |
| 00:10:15 | seydar | waitwaitwait |
| 00:10:28 | seydar | since when has duby produced legitamite Java code? |
| 00:11:16 | headius | well it always has, but the first prototype produced JVM bytecode directly |
| 00:11:34 | wmoxam enters the room. | |
| 00:11:34 | headius | this is new work now with better type inference logic |
| 00:11:39 | seydar | i absolutely fail |
| 00:11:43 | MenTaLguY enters the room. | |
| 00:12:00 | headius | producing C or Java code is harder than producing bytecode though...lots of text juggling |
| 00:12:44 | seydar | although to make myself feel better, i DID come up with the idea to piggy back on jruby and then get something stable to use to build the rest |
| 00:13:11 | MenTaLguY | hello |
| 00:13:41 | lstoll leaves the room. | |
| 00:13:54 | evan | MenTaLguY: allo |
| 00:14:41 | headius | this only depends on JRuby for the parser at the moment |
| 00:14:58 | headius | though obviously the JVM compiler backend will also depend on JRuby/JVM |
| 00:15:25 | mark___ enters the room. | |
| 00:15:27 | seydar | hmm.... jruby + java llvm? |
| 00:16:36 | seydar | nevermind. useless idea |
| 00:18:25 | tarcieri | there's a java frontend to llvm? |
| 00:18:40 | seydar | so headius, that's SERIOUSLY almost all that needs to be done? |
| 00:19:18 | headius | well, other than additional work on the inference logic and plugins to support various types and calls, yeah |
| 00:19:56 | headius | this isn't valid C or Java code yet either since there's some missing semicolons and no return keywords |
| 00:20:01 | headius | but it's along the right lines |
| 00:20:55 | seydar | beautiful |
| 00:22:03 | seydar | i pretty much love you now |
| 00:23:12 | rubuildius_amd64 | Federico Builes: cb69bdade; 1780 files, 6201 examples, 20475 expectations, 0 failures, 0 errors; http://rafb.net/p/UB7Tzk38.html |
| 00:23:13 | rubuildius_amd64 | Michael S. Klishin: 7131328bc; 1780 files, 6200 examples, 20474 expectations, 0 failures, 0 errors; http://rafb.net/p/bgMnpC37.html |
| 00:23:45 | headius | well, I don't know how much time I'll spend on the C stuff |
| 00:24:02 | headius | I'm tossing in one more change now to show the modified type decl syntax |
| 00:24:23 | fbuilesv | rubuildus times keep climbing, yesterday it was at 1800 |
| 00:24:47 | djwhitt | fbuilesv: well, those are probably extra slow because there were two running at once |
| 00:25:14 | fbuilesv | djwhitt: true |
| 00:26:31 | djwhitt | so, how can I profile a ci run? |
| 00:26:32 | seydar | also, there are like 6200 tests |
| 00:26:43 | seydar | time bin/mspec ci? |
| 00:26:52 | djwhitt | that's not profiling |
| 00:27:04 | djwhitt | I want to see what functions are chewing up all that time |
| 00:27:05 | brixen | djwhitt: bin/mspec ci -T -p |
| 00:27:09 | seydar | oh right. profile != time |
| 00:27:39 | djwhitt | brixen: thanks, |
| 00:27:55 | brixen | djwhitt: if you want to use the -ps -pss, you need to give it an arg, e.g. bin/mspec ci -T '-ps 10' |
| 00:28:00 | seydar | grrr safari 3.1 has literally broken nearly every application of my computer. thank god terminal still works. must fix prebinding |
| 00:28:02 | seydar leaves the room. | |
| 00:30:43 | djwhitt | brixen: what does the arg do? |
| 00:31:36 | headius | pastie |
| 00:32:03 | pastie | http://pastie.org/170034 by headius. |
| 00:32:22 | headius | that's the current modified syntax for arg decl |
| 00:32:42 | headius | not ruby-compatible, but the transform will use whichever syntax |
| 00:35:56 | brixen | djwhitt: it limits the results to that many entries. without it, you'll just get an irb prompt |
| 00:36:08 | djwhitt | brixen: ah, ok |
| 00:46:15 | headius | http://pastie.org/170037 |
| 00:46:22 | headius | so there it is working with the altered syntax |
| 00:46:32 | headius | dunno if that's interesting outside JRuby or not, but it's nicer than the hash |
| 00:47:21 | cored enters the room. | |
| 00:47:36 | evan | does that work normally? |
| 00:47:38 | evan | ie, parse |
| 00:48:06 | headius | no |
| 00:48:17 | headius | but it's not a complicated change |
| 00:48:19 | evan | def fib(n = Type(:fixnum)) |
| 00:48:23 | evan | is a syntax I like |
| 00:48:28 | headius | I want to support optional args |
| 00:48:36 | headius | probably not with the arrow though |
| 00:48:40 | headius | maybe with colon |
| 00:48:55 | headius | def fib(a: :fixnum = 1) |
| 00:49:06 | evan | too many colons |
| 00:49:13 | evan | actually... |
| 00:49:17 | evan | i wonder if |
| 00:49:19 | headius | it can be def fib(a:fixnum = 1) right now as well |
| 00:49:23 | evan | def fib(a::fixnum) |
| 00:49:25 | evan | parses... |
| 00:49:38 | evan | darn. |
| 00:49:38 | headius | the parser just inserts that type of node into the AST as a child of TypedArgumentNode |
| 00:49:55 | headius | a => <whatever> works in tom's modified parser already |
| 00:50:18 | headius | def foo(a => :fixnum, b => a) |
| 00:50:24 | evan | you should let colon2 appear as an arg |
| 00:50:26 | headius | not that you'd want most of those to work |
| 00:50:31 | evan | thats an easy change |
| 00:50:38 | evan | then you can do a::fixnum |
| 00:50:52 | headius | perhaps |
| 00:51:08 | headius | it makes typed optional args easier for sure |
| 00:51:17 | headius | a::fixnum = 1 |
| 00:51:21 | evan | yep |
| 00:51:31 | evan | it looks nice because it appears to decorate the arg name |
| 00:51:36 | headius | a => :fixnum = 1 is a little cumbersome |
| 00:51:43 | evan | rather than standing apart from it |
| 00:51:47 | evan | which is what the => does |
| 00:52:20 | enebo | p3k is adding an annotation system and I wonder if this could be Ruby 2 annotation system |
| 00:52:37 | enebo | Just a way to store additional stuff about a parm |
| 00:52:42 | evan | using the old [] before the method syntax? |
| 00:52:47 | enebo | What people do with it would be limited by the API |
| 00:53:01 | headius | the p3k syntax isn't really limited to the args though |
| 00:53:17 | headius | it would be more like annotate( ..... ); def fib(a) ... |
| 00:53:22 | enebo | yeah true...it perhaps could be expanded in some way |
| 00:53:35 | enebo | you can already do that in Ruby but it is ad-hoc of course |
| 00:53:44 | headius | with some parser tweaks we could make it explicit |
| 00:54:01 | headius | @( anno1, anno2, anno3); def fib(a) .. |
| 00:54:09 | enebo | class Foo < Bar => :some_annotations |
| 00:54:10 | headius | I don't think that parses now |
| 00:54:42 | enebo | actually that has the same problem as trying to use aSSOC for return type values |
| 00:54:47 | enebo | without massive changes |
| 00:54:59 | headius | evan: [] before method would work too |
| 00:55:02 | headius | [] or {} |
| 00:55:21 | headius | requires a little more tree-walking than in-body or in-args-list |
| 00:55:47 | headius | enebo had the idea that you could do this too... |
| 00:56:07 | headius | def foo(a); 1; end; def bar(b => foo); .... |
| 00:56:34 | headius | the args-list foo would be compiled as a vcall node, and basically this would mean "make b's type whatever foo returns" |
| 00:56:46 | tmornini leaves the room. | |
| 00:56:56 | headius | that also parses with this change, and would just require transformation logic to wire up |
| 00:56:59 | headius | bbiab, dinner |
| 01:12:18 | jrun enters the room. | |
| 01:13:55 | lstoll enters the room. | |
| 01:16:22 | rue | evan, drbrain: I am adding external lib loading back to FFI. Separate method from #attach_method for now |
| 01:21:50 | evan | ok |
| 01:23:34 | imajes_ enters the room. | |
| 01:25:11 | djwhitt | argh! my ci run finally finished and I got this: http://pastie.org/170054 |
| 01:26:16 | rue | Oo, that sucks. You are still trying to find the 64-bit issue? |
| 01:27:00 | djwhitt | rue: yeah, I'm trying to track down why it's running so slowly now on Gentoo 64 |
| 01:27:25 | rue | evan: I dunno if you saw it in scrollback but it looks like a completely unrelated change caused a huge regression in a first-time CI run (which might imply a compiler issue) |
| 01:27:36 | lachie enters the room. | |
| 01:27:41 | imajes__ leaves the room. | |
| 01:27:43 | evan | when? where? |
| 01:28:06 | rue | evan: Eep, *on 64-bit* |
| 01:28:19 | cremes | it's running slow on osx ppc as well; running the latest on osx intel completes in a reasonable time period though |
| 01:28:33 | djwhitt | evan: it appears to have started here: http://git.rubini.us/?p=code;a=commit;h=7f47287846fa4b7327639139068cce370bbf56f9 |
| 01:28:55 | evan | pretty strange place to start |
| 01:28:57 | djwhitt | evan: I have no idea why that commit would make any difference at all, but everything is nice on snapping on the previous commit |
| 01:28:59 | djwhitt | yeah |
| 01:29:02 | agile enters the room. | |
| 01:29:15 | djwhitt | I'll check again just to make sure I'm right about that |
| 01:29:20 | rue | Yep, and everything seems normal on all other platforms |
| 01:29:29 | brixen | djwhitt: I get 800-3300 times on the commits before the be_empty matcher commits |
| 01:29:33 | brixen | fwiw |
| 01:29:41 | evan | whats the error? |
| 01:29:52 | evan | or is it just taking a long time? |
| 01:29:59 | djwhitt | evan: just taking a long time |
| 01:30:02 | brixen | I'll give $20 to the person who shows that the problem is in be_empty matcher :) |
| 01:30:03 | djwhitt | like 1900 secs |
| 01:30:05 | evan | how long? |
| 01:30:34 | rue | Oh, I thought you guys triangulated it |
| 01:30:41 | femtowin enters the room. | |
| 01:30:42 | brixen | rue: I could not, no |
| 01:30:53 | anony | Did someone need me? the window was going crazy with notifications from this channel |
| 01:31:14 | rue | anony: Have you seen my mouse? :D |
| 01:31:24 | anony | rue, no :( |
| 01:31:24 | brixen | heh |
| 01:31:38 | imajes leaves the room. | |
| 01:31:43 | rue | anony: I do not think anyone has been pinging you in all seriousness though |
| 01:32:01 | anony | I gotcha |
| 01:32:08 | anony | bank time |
| 01:34:02 | femtowin | for this, shotgun/rubinius -dc -e "Ruby.asm ..." , why doesn't it work? |
| 01:34:03 | brixen | awesome, finally some headway: bm_so_count_words ~18 sec -> 4.22 sec |
| 01:34:13 | evan | nice |
| 01:34:19 | evan | femtowin: it's been removed. |
| 01:34:28 | evan | it was a compiler1-ism |
| 01:34:57 | evan | femtowin: the new form is |
| 01:34:59 | femtowin | so it I want to debug something, do I have a way? |
| 01:35:19 | evan | Rubinius.asm { push :true } |
| 01:35:28 | evan | the code in the block is executed at compile time |
| 01:35:35 | evan | with self as the code generator object |
| 01:35:48 | evan | femtowin: why would you use Ruby.asm to debug something? |
| 01:36:10 | ezmobius | brixen: what made that speed improvement? |
| 01:36:17 | femtowin | Just a ask, because I run into the Rubinius.asm something |
| 01:36:35 | evan | femtowin: i don't follow ou. |
| 01:36:36 | evan | you |
| 01:36:40 | femtowin | So I ran into this post, http://donttreadonme.co.uk/rubinius-irc/archive/2007_Feb_03.html |
| 01:36:49 | brixen | ezmobius: a number of things, some better ruby and 3 new primitives that can be composed for a number of different methods |
| 01:36:50 | femtowin | this post says something about Ruby.asm |
| 01:37:01 | ezmobius | cool |
| 01:37:06 | femtowin | but maybe that's not matter, |
| 01:37:07 | antares | evan: by the way may I get rights to edit LH pages? I want to maintain literature references page |
| 01:37:14 | evan | sure |
| 01:38:03 | evan | femtowin: thats quite old now |
| 01:38:22 | brixen | ezmobius: http://pastie.org/170058 |
| 01:38:42 | brixen | ezmobius: I'm rewriting #tr and friends now |
| 01:39:11 | brixen | ezmobius: mostly, we were relying on Regexp way to much, and hence doing a bunch of expensive method calls when simple loops would do |
| 01:39:23 | ezmobius | sweetness |
| 01:39:28 | antares | brixen: how do you usually profile Ruby code run by Rubinius? |
| 01:39:58 | brixen | antares: these are just benchmarks |
| 01:40:08 | brixen | antares: but I use the -p option to shotgun, usually |
| 01:40:30 | antares | brixen: thanks, will investigate |
| 01:40:36 | ezmobius | brixen: is this stuff commited already? |
| 01:40:41 | rue | brixen: Nice perf |
| 01:40:54 | brixen | antares: e.g. shotgun/rubinius -p some_script.rb |
| 01:41:09 | brixen | ezmobius: not yet, hopefully tonight after #tr is done |
| 01:41:13 | brixen | rue: thanks :) |
| 01:41:14 | ezmobius | cool |
| 01:41:18 | antares | brixen: gotcha |
| 01:41:38 | brixen | ezmobius: I know tom runs that one bench, I want to see him double take the monitor :) |
| 01:41:44 | ezmobius | ;) |
| 01:42:05 | femtowin | yes, from the documentation, you said you the bytecode generation, is from Sexp-->AST-->bytecode |
| 01:42:12 | djwhitt | brixen: I just got a first ci run after compile to complete in 138secs on the commit right before the be_empty matcher was committed |
| 01:42:20 | femtowin | but, from the grammar.y, I see a lot of code, directly creating node |
| 01:42:34 | femtowin | it seems, the parser --> AST |
| 01:42:38 | evan | femtowin: thats for creating the sexp |
| 01:42:40 | femtowin | directly |
| 01:42:43 | brixen | djwhitt: well, I could get ~120, but often got > 800, so I couldn't isolate it |
| 01:42:43 | evan | thats opaque to the rest of the system |
| 01:42:50 | rue | Ugh, I wish LH finally started making sense |
| 01:43:02 | brixen | djwhitt: and, I kept getting "Killed" output after the Generator specs ran |
| 01:43:05 | evan | the node's in grammar.y are never seen by anything outside of grammar.y and grammar_runtime.c |
| 01:43:14 | rue | So we need to add antares to the account, I think |
| 01:43:16 | djwhitt | brixen: I doubt it's the be empty matcher that caused the problem but it definitely pushed something over the edge on my machine |
| 01:43:20 | brixen | djwhitt: also, if I only rm'd the spec .rbc, I got fast runs |
| 01:43:42 | djwhitt | brixen: I did rake distclean followed by rebuild + ci run |
| 01:43:54 | brixen | djwhitt: I tried leaving the spec .rbc and rm'ing the mspec .rbc, but I got "Killed" on that and didn't have more time to look at it |
| 01:44:01 | femtowin | you mean, outside the grammar.y and grammar_runtime.c, the other parts sees the parser result as a Sexp? |
| 01:44:06 | evan | antares: ok, you have access to pages now |
| 01:44:09 | femtowin | and the grammar. |
| 01:44:16 | antares | evan: thank you |
| 01:44:19 | djwhitt | brixen: I never see "Killed" |
| 01:44:28 | evan | femtowin: yeah, but just as Array instances |
| 01:44:33 | djwhitt | brixen: how much memory do you have available on the system you're running on |
| 01:44:33 | evan | there is no Sexp object in rubinius |
| 01:44:34 | femtowin | and grammar.y translates node to Sexp |
| 01:44:44 | evan | yes |
| 01:44:52 | evan | and the ruby code takes over from there |
| 01:45:00 | djwhitt | brixen: I mean the gentoo system you were testing on |
| 01:45:01 | brixen | djwhitt: it certainly could be cause by the method defined for be_empty. have you tried just commenting that def and running? |
| 01:45:13 | brixen | djwhitt: hmm, 1gb I think |
| 01:45:23 | femtowin | yes, evan, thanks for the explanation |
| 01:45:29 | evan | femtowin: no problem. |
| 01:45:29 | brixen | evan: how much mem is on the ey slice I have access to? |
| 01:45:34 | evan | um. |
| 01:45:38 | evan | what does free() say? |
| 01:45:50 | femtowin | actually, I see the grammar.y a lot of resemlance to c ruby's parse file |
| 01:46:00 | evan | brixen: looks like 640m |
| 01:46:07 | evan | femtowin: it is c ruby's parse.y |
| 01:46:08 | brixen | evan: yep, thanks |
| 01:46:20 | evan | femtowin: I extracted it a few years ago |
| 01:46:21 | femtowin | because c ruby's parse file, that file, generating a lot of nodes, so I assume rubinius doing the same thing |
| 01:46:30 | evan | and made it standalone |
| 01:46:34 | evan | so we could import it into rubinius |
| 01:46:51 | evan | it generates Node struct's, yes, but thats all internal to it |
| 01:47:06 | evan | the tree of Node structs are passed to add_to_parse_tree, to create the sexp |
| 01:47:14 | djwhitt | brixen: you mean the be_empty method on Object? |
| 01:47:36 | brixen | djwhitt: this is what I was seeing going back a bunch of commits and doing "rake clean build; bin/mspec ci": http://pastie.org/170065 |
| 01:47:40 | femtowin | yes, and for Sexp, is yourself's sexp different from the ruby_parser project (or the ParseTree project it uses) |
| 01:47:49 | brixen | djwhitt: yeah, just the method def for #be_empty |
| 01:47:57 | evan | femtowin: no, same sexp |
| 01:48:06 | femtowin | because what I seen is, from your guys Sexp output, it has newline node, and ruby_parser project doesn't have that one |
| 01:48:07 | brixen | djwhitt: i.e. leave all of the commit except for that method def |
| 01:48:07 | evan | femtowin: there are very minor differences, but it's almost exactly the same |
| 01:48:07 | djwhitt | brixen: ok, I'll give that a try |
| 01:48:15 | djwhitt | brixen: yeah, gotcha |
| 01:48:15 | brixen | k |
| 01:48:16 | femtowin | doesn't have that newline node |
| 01:48:23 | evan | femtowin: it's an option to turn them on in ruby_parser and parse_tree |
| 01:48:40 | evan | or, if they're not in ruby_parser, it's because zenspider hasn't added them yet |
| 01:49:39 | mark___ leaves the room. | |
| 01:52:21 | enebo leaves the room. | |
| 01:52:32 | femtowin | I was trying to follow the Exception sequence |
| 01:52:42 | femtowin | in kernel.rb |
| 01:52:51 | femtowin | things like this |
| 01:52:52 | femtowin | exc.set_backtrace MethodContext.current.sender unless exc.backtrace |
| 01:52:58 | lstoll_ enters the room. | |
| 01:53:02 | femtowin | Rubinius.asm(exc) { |e| e.bytecode(self); raise_exc } |
| 01:53:08 | evan | yep |
| 01:53:29 | femtowin | so actually, MethodContext.current.sender is already an array? |
| 01:53:40 | femtowin | and I don't understand { |e| e.bytecode(self); raise_exc } |
| 01:53:42 | evan | no |
| 01:54:06 | evan | Rubinius's Exception#set_backtrace is smarter than MRI's |
| 01:54:22 | evan | it sees if the argument is a MethodContext object, and will generate a backtrace from it |
| 01:54:59 | evan | the Rubinius.asm part emits raw bytecode, to access stuff you can't get access to otherwise |
| 01:55:25 | evan | in this case, it's pushing the exception on the stack, then emitting the raise_exc bytecode |
| 01:55:30 | evan | so that the VM raises the exception |
| 01:56:29 | djwhitt | brixen: it is that be_empty method that does it |
| 01:56:31 | femtowin | yes |
| 01:58:02 | evan | thats it |
| 01:58:21 | brixen | djwhitt: heh, ok. what's it doing? |
| 01:58:31 | femtowin | evan, can I add your contact? preferly IM, |
| 01:58:58 | djwhitt | brixen: what do you mean? what is that method doing? |
| 01:59:00 | evan | i'd prefer to use IRC |
| 01:59:22 | evan | unless there is some specific thing you want to talk about |
| 02:00:16 | femtowin | yes, maybe |
| 02:00:25 | brixen | djwhitt: no, how does defining that method make it go haywire? especially compilation since we both saw normal times if all the spec files were compiled |
| 02:00:32 | evan | lets use IRC for now then. |
| 02:00:52 | djwhitt | djwhitt: oh, heh, no idea yet |
| 02:01:03 | djwhitt | oops |
| 02:01:06 | evan | heh |
| 02:01:06 | brixen | heh |
| 02:01:13 | brixen | talking to oneself in channel, nice :D |
| 02:01:23 | djwhitt | yeah, I'm getting counseling for it... |
| 02:01:24 | djwhitt | hehe |
| 02:01:57 | brixen | djwhitt: I commented out the require in mspec/matchers.rb, waiting for it to compile now |
| 02:01:59 | lstoll leaves the room. | |
| 02:03:40 | mark___ enters the room. | |
| 02:04:31 | wycats | is there a way to do an eval without the overhead of a binding? |
| 02:05:26 | evan | in normal ruby or in rubinius only? |
| 02:05:51 | femtowin leaves the room. | |
| 02:06:10 | wycats | either |
| 02:06:15 | wycats | both, ideally |
| 02:06:23 | evan | no |
| 02:06:32 | evan | the overhead of the binding isn't really in the eval |
| 02:06:34 | evan | it's in everything else |
| 02:06:38 | evan | keeping the binding available |
| 02:07:42 | cored leaves the room. | |
| 02:07:48 | wycats | damn |
| 02:07:58 | wycats | I want to be able to make a proc out of a string that doesn't care about its bindings |
| 02:09:07 | evan | and you're worried about the overhead of a binding? |
| 02:09:26 | wycats | I guess I'm worried about the overhead of eval too :P |
| 02:09:27 | evan | trust me, thats not where your performance is going. |
| 02:09:31 | jrun leaves the room. | |
| 02:09:57 | wycats | what I want to be able to do is take a string and make it a lambda (like the interpreter does) as fast as possible |
| 02:10:09 | evan | and the string is always ruby code? |
| 02:10:14 | evan | of any flavor? |
| 02:10:20 | wycats | right |
| 02:10:23 | evan | coming from where? |
| 02:10:24 | mark___ leaves the room. | |
| 02:10:24 | VVSiz_ enters the room. | |
| 02:10:26 | wycats | it's fine for it to even be a C string |
| 02:10:38 | wycats | it comes from a symbol |
| 02:10:42 | evan | no no |
| 02:10:46 | wycats | ;) |
| 02:10:48 | evan | why do you have a string full of code |
| 02:10:56 | evan | than you have to eval quickly over and over again |
| 02:10:59 | wycats | I'm trying to optimize Symbol#to_proc |
| 02:11:06 | evan | huh? |
| 02:11:11 | evan | that has zilch to do with eval |
| 02:11:19 | wycats | eval is one technique |
| 02:11:32 | evan | dear zeus, i hope not! |
| 02:11:41 | wycats | it's much faster than the alternatives |
| 02:11:49 | evan | that can't be |
| 02:11:54 | evan | it can't be faster than using send |
| 02:12:10 | wycats | lemme pull up a benchmark |
| 02:12:27 | antares | evan: opcodes question. Blue book says there are four special return instructions for self, nil, true and false. I guess they do not operate on top of the stack? Does this apply to Rubinius as well? |
| 02:12:43 | evan | no |
| 02:12:53 | evan | rubinius doesn't use the bluebook instruction set at all |
| 02:13:09 | antares | evan: ok, thanks |
| 02:13:19 | evan | there are similaries, but it's not a reimplementation of it's opcode set |
| 02:14:14 | femtowin enters the room. | |
| 02:14:16 | wycats | weird... send is actually only 50% slower than making it by hand |
| 02:14:35 | brixen | djwhitt: fwiw, after commenting out the require (hence, #be_empty shouldn't be defined), I'm still seeing the super slowdown. head for me is 21b07c9d |
| 02:14:53 | brixen | djwhitt: but I'm gonna grab some food, bbiab... |
| 02:14:57 | djwhitt | brixen: k |
| 02:15:16 | evan | wycats: if you absolutely must, write an C function for Symbol#to_proc |
| 02:15:35 | evan | that returns a special MRI C proc |
| 02:15:43 | wycats | evan: that is what I'm going to do |
| 02:15:55 | wycats | I just can't quite figure out how to write an MRI C proc ;) |
| 02:16:10 | wycats | can you convert a C func into a proc? |
| 02:16:42 | evan | yep |
| 02:16:44 | evan | rb_proc_new |
| 02:16:52 | femtowin leaves the room. | |
| 02:18:19 | VVSiz leaves the room. | |
| 02:30:43 | nicksieger leaves the room. | |
| 02:31:19 | nicksieger enters the room. | |
| 02:31:41 | wycats leaves the room. | |
| 02:32:11 | imajes enters the room. | |
| 02:33:59 | jrun enters the room. | |
| 02:36:34 | brother_rspec enters the room. | |
| 02:46:04 | lachie leaves the room. | |
| 02:49:08 | nicksieger leaves the room. | |
| 02:50:28 | jrun leaves the room. | |
| 02:51:05 | antares leaves the room. | |
| 02:51:07 | radarek leaves the room. | |
| 02:55:26 | headius | back again |
| 02:57:18 | headius | good lord, you're not really going to implement to_proc as a C extension are you? |
| 02:57:27 | djwhitt | is send site profiling broken for anyone else? |
| 02:57:50 | djwhitt | see: http://pastie.org/170110 |
| 02:58:49 | headius | I don't see what's wrong with def to_proc; eval "proc {|x, *args| x.#{to_s}(*args)}"; end if you want to avoid the send |
| 02:59:07 | MenTaLguY | that's sarcasm, right? :) |
| 02:59:22 | headius | well you'd want to cache them of course |
| 02:59:31 | headius | there's nothing in the binding that would be in danger |
| 02:59:54 | headius | def to_proc @@proc_cache = {}; @@proc_cache[self] = eval ... |
| 03:00:01 | brixen | djwhitt: yeah, I get the same error doing that |
| 03:00:05 | headius | ||= rather |
| 03:00:09 | headius | anyway |
| 03:00:10 | MenTaLguY | personally I'd like to see something like Kernel.__send_to__(symbol, object, *args, &block) |
| 03:00:21 | MenTaLguY | then it could get optimized by JIT |
| 03:00:28 | MenTaLguY | if symbol is known/fixed |
| 03:00:42 | headius | only if you allowed the jit to treat __send_to__ specially |
| 03:00:46 | MenTaLguY | sure |
| 03:00:47 | djwhitt | brixen: interestingly it works with simpler code: http://pastie.org/170114 |
| 03:00:51 | headius | I think rubinius is doing that already, but we aren't in JRuby at the moment |
| 03:01:35 | MenTaLguY | if we can get Ruby methods inlined by hotspot, and could prove to hotspot that symbol was constant, that might be enough |
| 03:01:39 | brixen | djwhitt: odd |
| 03:02:02 | headius | MenTaLguY: yes, I've toyed with adding a special send-aware call site in JRuby for just that purpose |
| 03:02:12 | headius | so far send appears to be faster than in MRI though, so I didn't do it for 1.1 |
| 03:02:25 | MenTaLguY | nods |
| 03:06:42 | imajes__ enters the room. | |
| 03:06:47 | srbaker enters the room. | |
| 03:06:59 | imajes leaves the room. | |
| 03:15:05 | jtoy enters the room. | |
| 03:17:50 | fbuilesv leaves the room. | |
| 03:21:26 | ezmobius leaves the room. | |
| 03:21:49 | fbuilesv enters the room. | |
| 03:23:45 | chop3 leaves the room. | |
| 03:29:02 | djwhitt | brixen: right now I'm running ci on the lastest code with -ps 10 (-ps seems to work fine) perhaps that will shed some light on what's happening |
| 03:34:03 | headius | is something wrong? |
| 03:35:02 | djwhitt | yeah, I see huge slowdowns running ci on the latest code |
| 03:36:03 | djwhitt | also, I just noticed that send site profiling is broken |
| 03:36:37 | djwhitt | it seems to have been that way for a long time though |
| 03:36:40 | loincloth_ enters the room. | |
| 03:37:02 | brixen | djwhitt: 866.49 is what I got after rake clean build and commenting the require be_empty line |
| 03:37:09 | brixen | djwhitt: I'll comment the method and do it again |
| 03:37:40 | djwhitt | brixen: weird, why would it be different for you I wonder |
| 03:38:34 | brixen | no idea, other than there are rarely 2 identical gentoo systems in the universe :) |
| 03:39:46 | djwhitt | heh, yeah, that's true |
| 03:51:56 | codpiece leaves the room. | |
| 03:54:38 | lachie leaves the room. | |
| 03:55:07 | brixen | djwhitt: after commenting out the method, "rake clean build; bin/mspec ci -fs" was killed in Generator specs. running bin/mspec ci -fs again (i.e. up to Generator already compiled), took 334 sec but finished |
| 03:55:10 | lachie enters the room. | |
| 03:56:11 | djwhitt | brixen: interesting, I'm still waiting for my ci run with -ps to finish |
| 03:57:21 | jayWHY leaves the room. | |
| 03:57:22 | djwhitt | brixen: do you know on which commit the problem started appearing for you? |
| 04:02:46 | djwhitt | bleh, -ps is broken to when I try to use it on a complete ci run |
| 04:03:07 | djwhitt | it worked for a subset of the specs though |
| 04:04:06 | AndrewO leaves the room. | |
| 04:07:17 | djwhitt | oh well, gotta sleep now |
| 04:07:28 | brixen | djwhitt: I'm seeing similar behavior at least 10-20 commits back from the be_empty matcher |
| 04:08:06 | brixen | I'm going to look into the memory consumption with Generator soon |
| 04:10:18 | xif | ingenious piece of Ruby code: http://pastie.caboo.se/170024 |
| 04:12:36 | MenTaLguY | that's beautiful |
| 04:12:50 | xif | MenTaLguY: my thoughts exactly. |
| 04:14:00 | whatevan enters the room. | |
| 04:21:09 | loincloth_ leaves the room. | |
| 04:21:27 | whatevan | MenTaLguY, that compliment you gave the bouncing module is going on my resume :) |
| 04:22:37 | MenTaLguY | I'm flattered that my compliments are resume-worthy. :) |
| 04:22:40 | dewd leaves the room. | |
| 04:24:09 | whatevan | well then everybody is happy :) |
| 04:25:12 | whatevan | i think its cool that it is appreciated. i showed it to some non-coders today, and after a brief period of complete rejection, they read it and thought it was weird |
| 04:25:17 | whatevan | which was something, anyway |
| 04:29:06 | imajes | evan: ping |
| 04:29:48 | whatevan | imajes: don't know your irl.. but pong |
| 04:30:13 | imajes | well evan knows me |
| 04:30:16 | whatevan | chris? |
| 04:30:33 | imajes | nah, i'm after evan p |
| 04:31:18 | whatevan | haha. i am dumb. evan is also my name, in my list of highlight words. i have no business here right now. you guys have a nice night :) |
| 04:31:23 | srbaker leaves the room. | |
| 04:32:02 | MenTaLguY | lots of evans |
| 04:32:32 | imajes | heh |
| 04:32:50 | srbaker enters the room. | |
| 04:33:40 | MenTaLguY | perhaps evan's experiments with implementing Kernel.fork in Rubinius went horribly wrong |
| 04:34:57 | womble leaves the room. | |
| 04:35:41 | mutle enters the room. | |
| 04:35:46 | dkubb enters the room. | |
| 04:38:48 | brixen | MenTaLguY: I'm getting the performance of #tr up, we'll just start renaming them |
| 04:43:53 | dewd enters the room. | |
| 04:48:53 | wmoxam leaves the room. | |
| 04:51:58 | headius | "evan".tr 'an', 'il' |
| 04:52:15 | mediogre enters the room. | |
| 04:54:02 | imajes leaves the room. | |
| 04:55:43 | lopex leaves the room. | |
| 04:56:01 | womble enters the room. | |
| 04:56:10 | brixen | headius: heh, if I were evan, that would be the title of my blog |
| 04:56:17 | headius | heheh |
| 05:06:05 | brother_rspec enters the room. | |
| 05:09:33 | lachie leaves the room. | |
| 05:13:44 | MenTaLguY leaves the room. | |
| 05:15:46 | d2dchat enters the room. | |
| 05:17:58 | imajes enters the room. | |
| 05:22:07 | lstoll_ leaves the room. | |
| 05:36:56 | jp_tix_ leaves the room. | |
| 05:41:44 | evan | thtas a good one! |
| 05:42:05 | brixen | indeed |
| 05:43:01 | jtoy leaves the room. | |
| 05:53:54 | jartz enters the room. | |
| 06:00:18 | rby enters the room. | |
| 06:17:39 | srbaker leaves the room. | |
| 06:18:18 | srbaker enters the room. | |
| 06:21:25 | _martinS_ leaves the room. | |
| 06:24:49 | imajes leaves the room. | |
| 06:25:49 | rby leaves the room. | |
| 06:28:42 | benburkert_ enters the room. | |
| 06:28:42 | benburkert leaves the room. | |
| 06:29:02 | mae leaves the room. | |
| 06:34:20 | jtoy enters the room. | |
| 06:41:16 | rby enters the room. | |
| 06:43:37 | dewd leaves the room. | |
| 06:48:55 | imajes enters the room. | |
| 06:54:02 | benburkert_ leaves the room. | |
| 06:54:11 | crafterm leaves the room. | |
| 06:58:11 | wycats enters the room. | |
| 06:59:41 | jartz_ enters the room. | |
| 07:00:08 | jartz leaves the room. | |
| 07:16:06 | rby leaves the room. | |
| 07:20:08 | Skip enters the room. | |
| 07:52:16 | jinjing enters the room. | |
| 08:10:44 | jptix enters the room. | |
| 08:13:25 | thehcdreamer enters the room. | |
| 08:30:13 | imajes leaves the room. | |
| 08:31:02 | imajes enters the room. | |
| 08:35:36 | zf leaves the room. | |
| 08:42:16 | imajes leaves the room. | |
| 08:42:44 | qwert666 enters the room. | |
| 08:42:51 | w1rele55 enters the room. | |
| 08:42:52 | imajes enters the room. | |
| 08:46:56 | jartz_ leaves the room. | |
| 08:49:14 | VVSiz_ enters the room. | |
| 08:57:32 | VVSiz leaves the room. | |
| 08:59:05 | jartz enters the room. | |
| 09:01:04 | brother_rspec enters the room. | |
| 09:07:11 | womble | Has anyone else noticed that when an error occurs when there is an ensure block, that the line number of the exception is the first line of the ensure, rather than the line that the exception occured on? |
| 09:09:17 | jptix leaves the room. | |
| 09:11:04 | Cu9YpD enters the room. | |
| 09:17:14 | Arjen_ enters the room. | |
| 09:18:25 | GMFlash leaves the room. | |
| 09:18:50 | lachie leaves the room. | |
| 09:24:04 | lachie enters the room. | |
| 09:33:41 | brother_rspec leaves the room. | |
| 09:42:30 | crafterm enters the room. | |
| 09:42:39 | crafterm leaves the room. | |
| 10:04:24 | imajes leaves the room. | |
| 10:09:45 | fbuilesv leaves the room. | |
| 10:11:46 | boyscout | 1 commit by Matt Palmer |
| 10:11:47 | boyscout | * Some specs for the timeout library; c39f2cb |
| 10:14:50 | jtoy leaves the room. | |
| 10:18:42 | olabini leaves the room. | |
| 10:23:32 | womble leaves the room. | |
| 10:25:51 | rubuildius_ppc | Matt Palmer: c39f2cb70; 1781 files, 6208 examples, 20508 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/170200 |
| 10:34:37 | brainopia enters the room. | |
| 10:35:15 | headius leaves the room. | |
| 10:38:23 | Arjen | rue, seen this: http://www.modrails.com ? |
| 10:39:40 | olabini enters the room. | |
| 10:50:44 | zf enters the room. | |
| 10:53:48 | imajes enters the room. | |
| 10:56:06 | womble_ enters the room. | |
| 11:00:43 | aotearoa leaves the room. | |
| 11:02:02 | rubuildius_amd64 | Matt Palmer: c39f2cb70; 1781 files, 6205 examples, 20479 expectations, 0 failures, 0 errors; http://rafb.net/p/dPnljJ78.html |
| 11:03:46 | octopod enters the room. | |
| 11:20:39 | ctennis leaves the room. | |
| 11:26:11 | radarek enters the room. | |
| 11:27:07 | brother_rspec enters the room. | |
| 11:36:04 | ctennis enters the room. | |
| 11:37:36 | wdperson enters the room. | |
| 11:40:11 | brother_rspec_ enters the room. | |
| 11:40:38 | hassox leaves the room. | |
| 11:43:23 | lachie leaves the room. | |
| 11:44:44 | BlackEdder enters the room. | |
| 11:46:52 | lstoll enters the room. | |
| 11:48:40 | brother_rspec leaves the room. | |
| 11:52:54 | womble leaves the room. | |
| 11:53:12 | lachie enters the room. | |
| 12:04:47 | brother_rspec_ leaves the room. | |
| 12:10:16 | brother_rspec enters the room. | |
| 12:19:40 | lachie leaves the room. | |
| 12:21:08 | wycats leaves the room. | |
| 12:21:39 | wycats enters the room. | |
| 12:46:15 | lachie leaves the room. | |
| 12:58:38 | jinjing leaves the room. | |
| 13:06:40 | webmat enters the room. | |
| 13:41:35 | antares enters the room. | |
| 13:44:31 | wycats leaves the room. | |
| 13:54:57 | wmoxam enters the room. | |
| 13:56:57 | gdagley enters the room. | |
| 14:00:46 | rtsuk enters the room. | |
| 14:01:49 | tim_w enters the room. | |
| 14:01:59 | moofbong enters the room. | |
| 14:08:32 | AndrewO enters the room. | |
| 14:10:06 | tim_w leaves the room. | |
| 14:32:23 | GMFlash enters the room. | |
| 14:36:47 | antares leaves the room. | |
| 14:38:49 | agile leaves the room. | |
| 14:44:54 | wycats enters the room. | |
| 14:45:56 | enebo enters the room. | |
| 14:48:27 | joel_c leaves the room. | |
| 14:49:22 | jtoy enters the room. | |
| 14:49:37 | jartz leaves the room. | |
| 14:53:01 | skaar enters the room. | |
| 14:54:18 | KirinDave enters the room. | |
| 14:54:59 | mae enters the room. | |
| 14:56:06 | jinjing enters the room. | |
| 15:09:18 | lachie enters the room. | |
| 15:10:03 | pat1 enters the room. | |
| 15:10:18 | pat1 | hiya. |
| 15:10:22 | pat1 | rue: awake? |
| 15:15:26 | menator enters the room. | |
| 15:16:34 | menator leaves the room. | |
| 15:18:08 | VVSiz_ enters the room. | |
| 15:18:08 | womble enters the room. | |
| 15:18:26 | womble_ enters the room. | |
| 15:23:45 | VVSiz leaves the room. | |
| 15:24:28 | menator enters the room. | |
| 15:26:44 | rtsuk leaves the room. | |
| 15:26:55 | KirinDave leaves the room. | |
| 15:28:29 | dewd enters the room. | |
| 15:28:33 | therealadam enters the room. | |
| 15:28:35 | wmoxam leaves the room. | |
| 15:29:01 | wmoxam enters the room. | |
| 15:29:07 | KirinDave enters the room. | |
| 15:36:20 | brother_rspec enters the room. | |
| 15:40:19 | womble_ leaves the room. | |
| 15:40:56 | womble leaves the room. | |
| 15:44:45 | lachie leaves the room. | |
| 15:44:47 | agile enters the room. | |
| 15:45:59 | jlindley enters the room. | |
| 15:50:26 | jtoy leaves the room. | |
| 16:05:49 | wycats leaves the room. | |
| 16:07:40 | KirinDave leaves the room. | |
| 16:23:54 | antares enters the room. | |
| 16:25:35 | macournoyer enters the room. | |
| 16:30:21 | menator leaves the room. | |
| 16:33:31 | Defiler | Anyone tried to use -ps and/or -pss recently? |
| 16:33:31 | macournoyer leaves the room. | |
| 16:33:40 | djwhitt | yes |
| 16:33:47 | Defiler | Did it work? Heh |
| 16:33:57 | macournoyer enters the room. | |
| 16:33:58 | djwhitt | -ps works better than -pss |
| 16:34:04 | djwhitt | but they're both somewhat broken for me |
| 16:34:14 | Defiler | OK. Glad it isn't just me |
| 16:34:37 | pat1 | hey, if anyone sees rue, please ask him to respond to the mod_rubinius/gsoc post on the mailing list (anyone else is welcome to respond as well) |
| 16:34:54 | eventualbuddha enters the room. | |
| 16:35:29 | djwhitt | pat1: ok, I'll let him know next time I see him on |
| 16:36:08 | djwhitt | Defiler: -pss seems to have been broken for quite a while too |
| 16:36:21 | djwhitt | Defiler: I checked all the way back before brixen's lookuptable changes |
| 16:36:27 | Defiler | Aah |
| 16:37:35 | djwhitt | oh, and another interesting thing |
| 16:37:39 | djwhitt | it's not completely broken |
| 16:38:10 | djwhitt | this works for example ./shotgun/rubinius -pss 10 -e "puts 'test'" |
| 16:38:11 | evan | pat1: do you need me to do anything to get rubinius projects on the list? |
| 16:39:23 | pat1 | let me know what you want on there |
| 16:39:28 | pat1 | I grabbed the whole EY list |
| 16:40:01 | evan | well, for now, i guess just have it listed |
| 16:40:18 | evan | we'll try and put together a list of ideas |
| 16:41:15 | pat1 | http://rubycentral.com/projects/gsoc-2008/ideas-for-gsoc-2008 is the list we have so far |
| 16:41:49 | pat1 | I see 5 Rubinius related projects there |
| 16:42:43 | evan | yep |
| 16:42:56 | evan | when do you students start submitting proposals? |
| 16:44:17 | pat1 | yesterday |
| 16:44:23 | evan | heh |
| 16:44:23 | evan | ok |
| 16:44:25 | pat1 | and mentors can start signing up now too |
| 16:45:16 | KirinDave enters the room. | |
| 16:45:27 | dodecaphonic enters the room. | |
| 16:56:37 | jartz enters the room. | |
| 17:03:21 | macournoyer leaves the room. | |
| 17:03:33 | macournoyer enters the room. | |
| 17:04:30 | mutle leaves the room. | |
| 17:05:45 | lopex enters the room. | |
| 17:06:33 | jptix enters the room. | |
| 17:09:03 | macournoyer leaves the room. | |
| 17:12:41 | TheVoice enters the room. | |
| 17:29:25 | imajes__ enters the room. | |
| 17:29:36 | Defiler | -fallow-undecidable-instances is the most Haskelly compiler option ever |
| 17:31:26 | evan | heheh |
| 17:32:14 | Defiler | "You can go this time, but let this be a warning." |
| 17:32:28 | evan | "next time, we're writing a note to your mother." |
| 17:33:22 | thehcdreamer leaves the room. | |
| 17:37:08 | rue | Morning |
| 17:37:38 | pat1 | hiya rue |
| 17:38:01 | rue | Hallo |
| 17:38:05 | Arjen_ leaves the room. | |
| 17:38:43 | pat1 | rue, are you on the mailing list? |
| 17:40:41 | rue | pat1: 4,296,476 mailing lists to be exact.. which one? :) |
| 17:40:55 | pat1 | rubinius development |
| 17:41:13 | pat1 | should've been more specific |
| 17:41:24 | rue | Mm, nothing in RSS, sec |
| 17:41:51 | pat1 | there was an email about the mod_rubinius gsoc project |
| 17:42:00 | pat1 | (a potential student asking for more info) |
| 17:44:35 | imajes leaves the room. | |
| 17:49:29 | rue | pat1: Got it, thanks |
| 17:52:57 | rue | pat1: Getting everything finalised for the conf there? |
| 17:53:34 | pat1 | yeah ... meals are planned, shirts are coming in tomorrow, I think the schedule is ready to go to print |
| 17:53:45 | pat1 | it's a busy/exciting week |
| 17:54:49 | rue | Heh, I can imagine. |
| 18:10:01 | loincloth leaves the room. | |
| 18:10:39 | loincloth enters the room. | |
| 18:14:49 | loincloth leaves the room. | |
| 18:16:57 | boyscout | 9 commits by Brian Ford |
| 18:16:58 | boyscout | * Added String#copy_from primitive. Reworked String justify methods.; 52d81e0 |
| 18:16:59 | boyscout | * Added Tuple.template and reworked String#tr and friends.; 1aabda5 |
| 18:17:01 | boyscout | * Added String#dup to bm_string1 benchmarks.; 258260d |
| 18:17:01 | boyscout | * Rework methods that behave like String#count.; bc7d9cc |
| 18:17:02 | boyscout | * Fixed bm_string1 to not mutate template string.; 3029dbb |
| 18:17:03 | boyscout | ... |
| 18:17:10 | djwhitt | wow, nice! |
| 18:17:35 | brixen | there's some status info here: http://rubinius.lighthouseapp.com/projects/5089/tickets/359 |
| 18:18:07 | brixen | still working on it, but things don't look like they visited a blender anymore, so I figured I should push |
| 18:19:50 | brixen | I should add that the results posted in that ticket are from bm_string1, not bm_string |
| 18:20:11 | brixen | eventually, I'll replace bm_string with bm_string1 |
| 18:20:29 | rue | WoOoOooOOoo |
| 18:22:01 | brixen | rue: making progress, stub your toe, or was that for me? :) |
| 18:23:06 | rue | I was imitating a crowd making the Wave |
| 18:23:44 | brixen | heh |
| 18:24:28 | loincloth enters the room. | |
| 18:26:34 | cremes leaves the room. | |
| 18:26:38 | evan | brixen: check pm |
| 18:26:50 | olabini leaves the room. | |
| 18:26:51 | evan | i wonder if IRC is being odd |
| 18:26:58 | evan | ok, nm. |
| 18:27:23 | brixen | one thing I really wish I had, a C-style for loop |
| 18:27:28 | brixen | it's so nice and concise |
| 18:27:31 | evan | heh |
| 18:28:39 | thehcdreamer enters the room. | |
| 18:28:40 | brixen | wouldn't it be awesome to have a composable grammar and require e.g. type annotations and C-for loop |
| 18:28:48 | brixen | (rhetorical question) |
| 18:29:21 | cremes enters the room. | |
| 18:30:34 | rubuildius_ppc | Brian Ford: 52d81e059; 1787 files, 6232 examples, 22084 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/170420 |
| 18:38:26 | imajes__ enters the room. | |
| 18:46:09 | imajes leaves the room. | |
| 18:48:31 | rue | Yeah, that would be, like, totally awesome |
| 18:50:08 | headius enters the room. | |
| 18:51:39 | cris_kiev enters the room. | |
| 18:54:59 | antares | rue: I see there's a student who want to help with mod_rubinius for GSoC (on rubinius-dev). Maybe we should add a page on mod rubinius to LH? |
| 19:00:48 | rue | Typing up a reply now |
| 19:06:35 | dgtized enters the room. | |
| 19:18:00 | thehcdreamer leaves the room. | |
| 19:19:10 | fbuilesv enters the room. | |
| 19:19:17 | fbuilesv | hola |
| 19:20:10 | rue | A-hoy |
| 19:20:13 | fbuilesv | I'm seeing on the current GSoC ideas that there's one for improving stdlib's specs, which happens to be what I'm [trying] to do right now. Any idea of who's responsible for this or a contact I can discuss the idea with? |
| 19:20:41 | pat1 | we don't currently have mentors assigned to specific projects |
| 19:20:52 | benburkert enters the room. | |
| 19:21:09 | fbuilesv | pat1: I see |
| 19:21:16 | pat1 | talking about it in general here or on the rubinius-dev list would both be appropriate |
| 19:21:44 | fbuilesv | Well, anyone has any ideas of where should the efforts focus? I'm currently working on REXML, but besides that, what are the most important libraries that need work right now? |
| 19:22:45 | drbrain | fbuilesv: whichever parts of the stdlib that don't work in rubinius properly are most important to write specs for |
| 19:22:49 | drbrain | lunches |
| 19:22:55 | drbrain | (sorry it's so arbitrary) |
| 19:23:32 | fbuilesv | drbrain: I understand it, I just felt like asking since there are some libraries that don't have anything spec'd yet while there are other ones that have stuff but are more important (net, cgi, yaml, etc). |
| 19:23:46 | fbuilesv | by important I mean more generally used |
| 19:23:53 | drbrain | yeah |
| 19:23:57 | brixen | fbuilesv: iirc, Defiler is doing some work on BigDecimal, other than that, anything that Rails uses would be at the top of the list |
| 19:24:22 | drbrain | I've largely encouraged people to work on something *they* think is important |
| 19:24:23 | dbussink | hi people |
| 19:24:24 | brixen | yaml specs in particular would be great |
| 19:24:33 | brixen | dbussink! |
| 19:24:34 | dbussink | brixen: wanted to suggest yaml too |
| 19:24:40 | drbrain | since that will motivate them more than telling them to work on something they think is boring |
| 19:24:50 | pat1 | the JRuby guys would love to see IO get more coverage |
| 19:24:51 | brixen | yeah, what drbrain said :) |
| 19:24:54 | fbuilesv | brixen: did you guys managed to see what was wrong with the builds and be_empty yesterday? |
| 19:24:57 | drbrain | I think there are RbYAML specs/tests that I didn't import |
| 19:25:16 | drbrain | it would be a good starting point if you wanted to do YAML |
| 19:25:18 | brixen | fbuilesv: unfortunately no, however, on my system be_empty matcher is not implicated |
| 19:25:18 | pat1 | but drbrain is right ... as usual |
| 19:25:19 | drbrain | ok, later |
| 19:25:38 | fbuilesv | brixen: at least, I was a bit worried about freaking out the system with my first commit :) |
| 19:25:47 | djwhitt | fbuilesv: the be_empty commit is where I started seeing the problem but it probably didn't cause it |
| 19:25:47 | brixen | fbuilesv: heh, no worries |
| 19:26:28 | fbuilesv | djwhitt, brixen: only happens on 64 bits gentoo, right? I wasn't able to reproduce on Ubuntu32/64 or Intel Mac |
| 19:26:34 | dbussink | brixen: nice work on the string stuff |
| 19:27:13 | olabini enters the room. | |
| 19:27:24 | brixen | dbussink: thanks |
| 19:27:35 | djwhitt | fbuilesv: not sure, I'm going to try on my Gentoo 32 laptop right now |
| 19:27:45 | fbuilesv | Well, what would you guys think of covering YAML, finishing up REXML, try to do as much as possible on IO for the JRuby guys and one or two of the libraries that Rails depends on? Would that be too much or too little? |
| 19:27:47 | brixen | dbussink: still a wip |
| 19:27:48 | dbussink | i've been really busy these days, not really any time to contribute something |
| 19:28:25 | dbussink | i think subtend is a good one to work on too, but dunno about the state it's in now |
| 19:28:27 | brixen | fbuilesv: that sounds like quite a bit, but you'll have to judge based on your familiarity |
| 19:28:45 | dbussink | plus that it's there's a lot more c voodoo required there |
| 19:28:52 | fbuilesv | brixen: It's like 2-3 months, right? I don't see a problem with time, IO does scare me tho |
| 19:28:58 | brixen | subtend is pretty solid for what is done. I'm going to fix up the spec structure for it |
| 19:29:25 | dbussink | any ideas on the array problems there? or is it waiting for a new mri approach there? |
| 19:29:52 | headius | someone's going to have to suck it up and really hit IO hard...honestly the idea that libraries are more important than finishing the process of spec'ing out key core classes is rather absurd |
| 19:29:58 | brixen | fbuilesv: I don't know how long GSoC runs, but you can propose that and see how far you get |
| 19:30:12 | headius | IO is absolutely crucial, and Socket stuff only slightly less so...but they're very thin as far as specs |
| 19:30:27 | brixen | dbussink: array problems in subtend? |
| 19:30:48 | dbussink | brixen: well, i read the discussion on the ruby core mailing list |
| 19:30:54 | dbussink | and i thought i applied to subtend too |
| 19:30:58 | dbussink | it applied |
| 19:31:03 | brixen | fbuilesv: as far as core class specs go, I think IO and Kernel are the last 2 that have pretty sparse specs |
| 19:31:12 | headius | I'm not saying that needs to be the sole focus for anyone, especially GSoC, but it's an inconvenient truth |
| 19:31:22 | fbuilesv | headius: that's true, I just say that IO might scare me a bit because I've never gone in there and my "C-fu" is not as strong as it should but I still think I could give it a try |
| 19:31:38 | brixen | dbussink: link? I didn't read it |
| 19:31:47 | headius | you shouldn't need much C-fu, but it would help |
| 19:32:02 | headius | writing specs for IO will almost certainly require reading the Ruby impl |
| 19:32:34 | fbuilesv | headius: I felt comfortable going through socket.c, haven't checked out the IO operations yet |
| 19:32:45 | headius | socket.c is no uglier than io.c |
| 19:32:50 | headius | which isn't saying much :) |
| 19:32:54 | fbuilesv | heh |
| 19:33:19 | dbussink | brixen: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/15909 |
| 19:33:35 | fbuilesv | I think I'll send it as: Finishing up REXML, write whatever's missing from yaml and then going into socket or io, whatever's more needed |
| 19:35:26 | brixen | dbussink: thanks |
| 19:36:03 | brixen | dbussink: oh yes, that. #418 |
| 19:36:30 | djwhitt | that slowdown issue appears to be 64bit specific |
| 19:36:31 | brixen | dbussink: it's complicated in subtend, yes. and we have to support the old semantic for a bunch of old C ext, e.g. openssl |
| 19:36:48 | brixen | djwhitt: I concur dr. :) |
| 19:37:35 | dbussink | brixen: well, do you have any idea on how to solve it then? |
| 19:38:05 | brixen | yeah, it's in the ticket |
| 19:39:18 | brixen | so, RSTRING() would be a function that creates a C struct and add that to a table. when you transition back from subtend, something will need to update the objects registered in the table on the shotgun side |
| 19:39:33 | dbussink | ah yeah, reading up on it now |
| 19:39:35 | brixen | in the C ext, you'll work with a C string in that struct |
| 19:39:43 | dbussink | probably the only way to do it indeed |
| 19:40:04 | djwhitt | I wonder if there's something in the system that still isn't quite 64 bit clean |
| 19:40:11 | djwhitt | I mean, something that never got fixed in the first place |
| 19:40:35 | benburkert leaves the room. | |
| 19:40:44 | brixen | djwhitt: could be, but isolating that is the problem. I don't see the issue if only the specs need to be compiled |
| 19:40:56 | brixen | so, it's hard to say it's something in the compiler |
| 19:41:40 | headius | fbuilesv: another big help for the specs would be doing a sweep of other test suites, making sure one by one their cases are represented in the specs, and then officially getting that word out to anyone using them |
| 19:41:57 | headius | for example, if we could know that most of the Rubicon suite is already covered in the specs, we'd chuck it in the bin |
| 19:41:59 | headius | but we don't know that yet |
| 19:42:10 | dkubb enters the room. | |
| 19:42:14 | brixen | djwhitt: could be something in the parser |
| 19:42:33 | djwhitt | brixen: yeah, I'm just at a loss how to track it down |
| 19:43:37 | brixen | djwhitt: heh, I know. I think looking at the mem consuption in the Generator specs is the thing to do |
| 19:44:03 | fbuilesv | headius: I thought of doing that from MRI to Rubinius but then I realized that it'd be far more helpful to do the other way around. I'll to mix up all the ideas and present something good. |
| 19:45:00 | headius | sounds good |
| 19:45:12 | mediogre leaves the room. | |
| 19:45:40 | brixen | djwhitt: I get ~90 sec if specs compiled, ~116 if specs are not compiled |
| 19:45:55 | brixen | djwhitt: I'll try with specs compiled but not mspec |
| 19:46:59 | octopod leaves the room. | |
| 19:47:24 | rubuildius_amd64 | Brian Ford: 52d81e059; bin/ci failed! http://rafb.net/p/KkFehI27.html |
| 19:47:32 | djwhitt | ignore that |
| 19:48:04 | djwhitt | spec run was still going after 80min so I killed it |
| 19:49:06 | djwhitt | brixen: I'll try taking a look at the Generator specs tonight, I can't right now (at work) |
| 19:55:45 | cris_kiev | Hi all, i'm trying to run last thread-ring test on rubinius and fails on Thread.run operations |
| 19:56:27 | cris_kiev | Is Thread.run doesn't implemented currently? |
| 19:56:56 | Gerardo enters the room. | |
| 19:57:29 | Gerardo | I'm trying Rubinius on OpenBSD |
| 19:58:04 | Gerardo | and found the first problem |
| 19:58:05 | fbuilesv leaves the room. | |
| 19:58:10 | Gerardo | any developer here? |
| 19:58:24 | brixen | cris_kiev: can you pastie what you're running and what the error you get is? |
| 19:58:34 | brixen | Gerardo: pastie your problem, please |
| 19:58:41 | Gerardo | ok brixen |
| 19:59:13 | Gerardo | I've just cloned the source with git, the error is pretty simple: I don't have bash installed and configure calls it explicitly |
| 19:59:23 | brixen | oh sure |
| 19:59:24 | Gerardo | I have changed bash with sh and works fine |
| 19:59:26 | cris_kiev | brixen: http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadring&lang=ruby&id=2 |
| 19:59:47 | brixen | Gerardo: ok, you could submit a patch to http://rubinius.lighthouseapp.com/projects/5089/tickets/ |
| 19:59:49 | Gerardo | so, I'd suggest to use sh, since mkconfig.sh doesn't have bash specific code |
| 20:00:02 | Gerardo | ok brixen, thanks |
| 20:00:36 | benburkert enters the room. | |
| 20:00:47 | cris_kiev | An exception has occurred: |
| 20:00:47 | cris_kiev | killed thread (ThreadError) |
| 20:00:47 | cris_kiev | Backtrace: |
| 20:00:47 | cris_kiev | Thread#run at kernel/bootstrap/thread.rb:24 |
| 20:00:47 | cris_kiev | Object#__script__ {} at thread_r.rb:30 |
| 20:00:48 | cris_kiev | Array#each at kernel/core/array.rb:573 |
| 20:00:50 | cris_kiev | Object#__script__ at thread_r.rb:28 |
| 20:00:52 | cris_kiev | CompiledMethod#as_script at kernel/core/compiled_method.rb:210 |
| 20:00:54 | cris_kiev | Compile.single_load at kernel/core/compile.rb:240 |
| 20:00:56 | cris_kiev | Compile.load_from_extension at kernel/core/compile.rb:312 |
| 20:00:58 | cris_kiev | Object#__script__ at kernel/loader.rb:189 |
| 20:00:59 | brixen | cris_kiev: pastie.org ! |
| 20:01:04 | rue | Use a pasteboard, pwees |
| 20:01:05 | cris_kiev | sorry |
| 20:01:26 | brixen | cris_kiev: have you taken a look at the Thread specs? |
| 20:01:28 | rue | You might break Freenode otherwise :) |
| 20:01:44 | brixen | cris_kiev: if you could, see if that case is covered. if not, you could write a spec for it |
| 20:02:55 | antares | rue: if one pastes too long piece of code (s)he gets banned as flooder btw ;) |
| 20:03:04 | Gerardo | it will be a single line patch brixen :) |
| 20:03:23 | brixen | Gerardo: ok, or even just a ticket, so we know we need to address it :) |
| 20:03:30 | Gerardo | ok |
| 20:03:31 | ezmobius enters the room. | |
| 20:03:58 | brixen | lunch, bbiab... |
| 20:05:38 | cris_kiev | brixen: ok, i'm try to find specs and check what is wrong with Thread-lib |
| 20:06:41 | antares | cris_kiev: don't forget to check up spec tags |
| 20:09:11 | cris_kiev | brixen: thread/run_spec.rb is empty, i'll write specs for it |
| 20:10:02 | cris_kiev | antares: don't understand what you mean. is it some spec-related tag on git? |
| 20:10:26 | antares | cris_kiev: read a page on CI at LightHouse |
| 20:10:39 | cris_kiev | antares: ok, thanks |
| 20:11:29 | antares | cris_kiev: some spec are known to fail at the moment; they are tagged as failing using mspec tags. If you see an example failing make sure it is not tagged as such, otherwise you found a known failure |
| 20:12:21 | cris_kiev | antares: is Cl - core library or what? |
| 20:12:44 | antares | what CI stands for you mean? |
| 20:13:02 | cris_kiev | antares: CI - continuous integration? |
| 20:13:06 | antares | it is "cee eye", not CL ;) Continuos integration |
| 20:16:45 | jlindley_ enters the room. | |
| 20:18:47 | jlindley_ leaves the room. | |
| 20:24:54 | jayWHY enters the room. | |
| 20:28:21 | jlindley leaves the room. | |
| 20:33:06 | skaar leaves the room. | |
| 20:34:38 | w1rele55 leaves the room. | |
| 20:35:40 | w1rele55 enters the room. | |
| 20:39:36 | imajes__ leaves the room. | |
| 20:43:56 | thehcdreamer enters the room. | |
| 20:46:05 | ctennis enters the room. | |
| 20:46:35 | dodecaphonic leaves the room. | |
| 20:53:10 | Gerardo leaves the room. | |
| 20:53:26 | probablycorey enters the room. | |
| 20:54:30 | octopod enters the room. | |
| 20:58:17 | thehcdreamer leaves the room. | |
| 20:59:08 | djwhitt | does ./bin/mspec ci -T -p work for anyone? |
| 20:59:34 | hassox enters the room. | |
| 21:00:03 | imajes enters the room. | |
| 21:04:02 | brixen | djwhitt: it's worked in the past, getting EBADF now |
| 21:04:48 | djwhitt | right now I get: Attempted to access field of non-reference |
| 21:04:56 | djwhitt | followed by a segfault when I try it |
| 21:08:23 | brixen | djwhitt: this works for me: bin/mspec ci -T -p spec/ruby/1.8/core |
| 21:08:32 | brixen | there must be some bad specs |
| 21:12:13 | brixen | djwhitt: cat bin/mspec. if I run everything together except 1.8/library, -T -p works fine |
| 21:12:38 | djwhitt | brixen: yeah, it works fine for me too on subsets of the specs |
| 21:13:29 | imajes leaves the room. | |
| 21:15:52 | brixen | djwhitt: try this: bin/mspec run -G fails -G unstable -T -p -E "Generator" spec/ruby/1.8/core spec/ruby/1.8/language/ spec/compiler/ spec/core/ spec/debugger/ spec/subtend spec/parser/ |
| 21:15:59 | brixen | that works for me |
| 21:19:58 | lstoll leaves the room. | |
| 21:20:24 | djwhitt | yeah, it's definitely the library specs that mess it up |
| 21:21:05 | djwhitt | I just ran ci on only the library specs and that segfaulted too |
| 21:21:10 | djwhitt | ci + profiling I mean |
| 21:23:21 | brixen | doh, forgot to add spec/ruby/1.8/library to above command |
| 21:23:41 | brixen | yeah, library specs are it, but excluding specs with "Generator" doesn't help |
| 21:23:57 | djwhitt | yeah, I'm running all the dirs individually to see if I can isolate it |
| 21:26:01 | loincloth leaves the room. | |
| 21:26:36 | brixen | djwhitt: try: bin/mspec -G fails -G unstable -T -p spec/ruby/1.8/library/[a-r]* spec/ruby/1.8/library/[t-z]* |
| 21:27:01 | rby enters the room. | |
| 21:27:24 | brixen | bets on socket specs? |
| 21:27:25 | djwhitt | excluding socket right |
| 21:27:28 | djwhitt | yep |
| 21:27:42 | djwhitt | yeah, that passes |
| 21:27:55 | brixen | bin/mspec -G fails -G unstable -T -p spec/ruby/1.8/library/[a-r]* spec/ruby/1.8/library/s[ity]* spec/ruby/1.8/library/[t-z]* |
| 21:28:28 | brixen | ok, this gives me EBADF: bin/mspec -G fails -G unstable -T -p spec/ruby/1.8/library/socket/ |
| 21:30:21 | nicksieger leaves the room. | |
| 21:30:34 | djwhitt | http://pastie.org/170530 |
| 21:32:14 | nicksieger enters the room. | |
| 21:32:26 | brixen | djwhitt: yeah, that's what I'm seeing |
| 21:32:55 | drbrain | "filedes is not a valid file descriptor open for writing" |
| 21:33:01 | drbrain | did somebody close STDOUT? |
| 21:33:10 | drbrain | (without duping it) |
| 21:33:10 | brixen | seems like it |
| 21:33:53 | headius | closed descriptor is the typical reason for ebadf |
| 21:34:02 | evan | where is it showing up? |
| 21:34:10 | evan | because i did fix something just like this |
| 21:34:22 | evan | that headius's accept specs caused |
| 21:34:28 | brixen | bin/mspec ci -T -p spec/ruby/1.8/library/socket |
| 21:34:37 | headius | poppycock |
| 21:34:43 | brixen | is as far down as I've looked |
| 21:34:44 | evan | ie, the threading waiting was killed/raised |
| 21:34:54 | evan | and the VM didn't unregister the socket it was waiting on |
| 21:34:58 | evan | then that socket got closed |
| 21:35:37 | brixen | djwhitt: are you still seeing the slowness on HEAD on your 64bit box? |
| 21:35:42 | djwhitt | yes |
| 21:36:07 | djwhitt | I killed the last rubuildius run when it got up to 80 minutes |
| 21:36:37 | djwhitt | that doesn't include compile time either |
| 21:36:40 | djwhitt | that was just running the specs |
| 21:36:41 |