Da
Show enters and exits. Hide enters and exits.
| 00:06:11 | jarib | there are other problems here as well, #call, #location, and #to_proc all fail if it's not a CompiledMethod |
| 00:06:22 | jarib | perhaps i'm barking up the wrong tree |
| 00:06:27 | evan | no no |
| 00:06:32 | evan | you're right on track. |
| 00:06:40 | evan | we need to fix all those things |
| 00:06:50 | jarib | ok, good |
| 00:07:02 | evan | this is just a neglected corner |
| 00:07:19 | jarib | i'm happy i found something i could almost understand ;) |
| 00:07:54 | evan | yay! |
| 00:13:14 | jarib | i'll do some specs first |
| 00:15:13 | evan | good call. |
| 00:15:28 | evan | it's pretty rare for people to use method() on accessors |
| 00:15:32 | evan | that's why we haven't hit this |
| 00:15:49 | jarib | right |
| 00:16:46 | jarib | i ran into the other day trying to pass all of Array.instance_methods to Rubinius.jit :) |
| 00:16:58 | evan | ah! |
| 00:16:59 | evan | hehe |
| 00:17:10 | evan | you were being adventerous! |
| 00:17:17 | jarib | yep :) |
| 00:18:47 | evan | heh, yep |
| 00:18:51 | evan | by the time rbx exists |
| 00:19:03 | evan | 21 of 88 jit queued methods have been completed |
| 00:27:09 | boyscout | Adding rb_rescue{2} to capi, specs included. - 21fb94d - Cezar Sa Espinola |
| 00:27:39 | headius | evan: did you add anything to jit all methods? |
| 00:28:00 | evan | add anything? |
| 00:28:06 | evan | like chocolate sauce? |
| 00:28:11 | evan | perhaps gummy bears? |
| 00:28:13 | headius | I don't think there was any way to trigger that before |
| 00:28:22 | evan | oh |
| 00:28:22 | evan | no |
| 00:28:27 | evan | still no way to jit all methods |
| 00:28:30 | headius | ok |
| 00:28:35 | evan | thats an interesting case, but it's not as useful |
| 00:28:42 | evan | because you'd jit methods that haven't ever been run |
| 00:28:49 | evan | so the JIT can't make a very good decision |
| 00:28:53 | headius | well, without heuristics for when to jit it's a little cumbersome to test anything nontrivial |
| 00:28:55 | slava | if you don't have a way to save machine code to disk, then compiling everything really sucks |
| 00:29:14 | headius | did you add heuristics? |
| 00:29:21 | evan | headius: locally, yes |
| 00:29:22 | brixen | evan: step 2, list the methods that jit completed and those it didn't |
| 00:29:27 | evan | headius: a simple call counter |
| 00:29:30 | headius | ok |
| 00:29:37 | evan | going to commit shortly. |
| 00:29:58 | evan | oh woops! |
| 00:29:59 | evan | haha |
| 00:30:10 | evan | just realized a flaw in how the background thread processes requests |
| 00:30:28 | evan | it isn't emptying the queue |
| 00:30:35 | evan | it's doing one, waiting to be signalled |
| 00:30:38 | evan | doing one, waiting again |
| 00:33:30 | boyscout | CI: 21fb94d success. 2682 files, 10327 examples, 32876 expectations, 0 failures, 0 errors |
| 00:39:08 | rue | Mm, related to dumping object code to disk, what about dumping an "image" from a training run? Say, running some web server with some artificial requests until stuff has gotten JITted, then dumping that data out so that production can run straight off the object code where previously deemed necessary? |
| 00:39:28 | rue | ('Course you could always just have a list of methods but that seems much less fun) |
| 00:39:57 | evan | well, we could dump out the pre-trained LLVM IR |
| 00:40:14 | evan | and compile and link that offline |
| 00:40:19 | evan | then dlopen it back in |
| 00:40:51 | evan | i've discussed with the LLVM guys a little about the ability for the JIT to report relocation info |
| 00:41:06 | evan | so that we could save machine to disk in a simple format |
| 00:41:10 | evan | machine code |
| 00:47:51 | rue | Yes, it would be a pretty handy feature to have for many use cases |
| 00:49:26 | headius | is llvm that slow to compile? |
| 00:51:04 | rue | Depends on how much you are compiling? |
| 00:52:52 | headius | that makes no sense |
| 00:53:07 | headius | that's like saying whether or not a car is slow depends on how far you're driving |
| 00:55:59 | evan | headius: i'd imagine it's probably about the same speed as hotspots optimizing compiler |
| 00:56:32 | headius | well, we could check that...it's possible to force hotspot to compile up front |
| 00:59:22 | headius | I was just wondering if it's worth the hassle of dumping native code to disk and having to validate it all the time |
| 00:59:44 | evan | *shrug* |
| 00:59:45 | evan | dunno. |
| 00:59:55 | evan | headius: when hotspot compiles up front |
| 01:00:15 | evan | i guess that means it's compiling without many optimizations? |
| 01:00:18 | headius | that's the main reason JVM folks have given me for not dumping stuff...security, validation, avoiding staleness |
| 01:00:22 | headius | yeah |
| 01:00:42 | headius | no inlining, etc, except where it's possible to statically analyze |
| 01:01:12 | evan | whats the use in that? |
| 01:01:19 | evan | i mean, does anyone do that? |
| 01:01:22 | headius | no |
| 01:01:27 | headius | nobody does that |
| 01:01:46 | headius | but there's knobs for everything |
| 01:02:05 | headius | so here's a fairly unscientific measurement |
| 01:02:31 | evan | sure, knobs knobs galore |
| 01:04:02 | headius | generating a rails app with default settings, JRuby compiling everything in advance, hotspot compiling all methods immediately (threshold 0), no background compilation = 1m27s |
| 01:04:29 | evan | wow. |
| 01:04:32 | evan | thats pretty darn good. |
| 01:05:00 | evan | when is it compiling them then? |
| 01:05:00 | headius | same generation with jruby compilation off and default settings in hotspot (probably mostly interpreted) = 5.5s |
| 01:05:08 | evan | when a class loader imports them? |
| 01:05:23 | headius | no, first invocation |
| 01:05:27 | headius | I'm not sure there's a setting to compile on load |
| 01:05:29 | evan | AH |
| 01:05:32 | evan | so it's not all methods |
| 01:05:42 | headius | all invoked methods, sure |
| 01:05:48 | evan | by all methods, I thought you meant ALL methods |
| 01:05:50 | headius | but that's still thousands |
| 01:05:51 | evan | regardless of running. |
| 01:05:58 | headius | tends of thousands counting jruby internals |
| 01:06:04 | evan | sure |
| 01:06:24 | headius | not that we wouldn't love to have a native code cache |
| 01:06:28 | headius | save that warmup time |
| 01:06:34 | evan | i can't give a speed on LLVM really |
| 01:06:43 | evan | i'm sure if you look around, you can get some info |
| 01:07:06 | headius | I just remember you saying it was slow |
| 01:07:24 | evan | there were a number of factors then |
| 01:07:33 | evan | 1) we were compiling all methods when they we imported to the system |
| 01:07:44 | evan | 2) we were leaning on LLVM's inliner WAY too much |
| 01:07:59 | evan | 3) complication was inline with execution |
| 01:08:11 | evan | we're trying to eliminate all 3 of those |
| 01:08:44 | headius | cool |
| 01:09:07 | evan | 1) use call counters and explicit complication |
| 01:09:20 | headius | hey, did you fix that float issue? |
| 01:09:32 | evan | 2) drive IR generation more explicitly, using specific code for every opcode |
| 01:09:39 | evan | 3) use a background complication thread |
| 01:09:45 | evan | headius: yeah, thats solved |
| 01:09:49 | evan | jit'd code wasn't calling the GC |
| 01:09:51 | evan | oops. |
| 01:09:51 | evan | :D |
| 01:11:15 | headius | oops |
| 01:11:47 | headius | hmph, I need to get your build working in jruby |
| 01:12:06 | headius | building rubinius is the only thing I have to use MRI for |
| 01:12:21 | headius | bbiab |
| 01:12:28 | evan | later. |
| 01:45:22 | jarib | brixen: so the ci run seems to be a subset of all known good specs, is that right? |
| 01:46:19 | jarib | it's not actually all of them? |
| 01:49:59 | brixen | just bin/mspec ci run spec/default.mspec :ci_files |
| 01:50:04 | brixen | a subset, yes |
| 01:50:17 | brixen | rake runs bin/mspec ci -B full |
| 01:50:28 | brixen | which is spec/full.mspec :ci_files |
| 01:50:42 | brixen | which is still a subset if you consider the exclusions |
| 01:50:51 | brixen | but it's a fuller subset :) |
| 01:51:11 | jarib | i see |
| 02:11:25 | headius | evan: hey, I did a rebuild and .jit doesn't seem to be jitting |
| 02:11:29 | headius | still need a property set somewhere? |
| 02:12:30 | headius | also, evan or brixen: is it still possible to turn on ruby_parser? |
| 02:13:47 | headius | or anyone that knows, I suppose :) |
| 02:17:51 | brixen | yeah, you can enable ruby_parser from the cmd line |
| 02:18:06 | brixen | --ruby_parser |
| 02:18:19 | brixen | we try to keep things cryptic :) |
| 02:18:35 | brixen | as for the jit, dunno, I haven't even gotten to play with it yet |
| 02:20:16 | headius | brixen: actually I meant in the build |
| 02:20:26 | headius | I want to be able to build rubinius with JRuby so I don't have to keep switching to MRI |
| 02:20:35 | headius | I think the PT dependency is the only thing keeping it from working |
| 02:20:54 | brixen | we use pt in the build? |
| 02:21:00 | headius | ok, for jit it still needs RBX_LLVM=1 for build |
| 02:21:04 | headius | so that's one question answered |
| 02:21:26 | headius | brixen: for compiling kernel, I thought that's what it did |
| 02:21:34 | brixen | it uses ruby_parser |
| 02:21:37 | brixen | from MRI |
| 02:21:47 | headius | hmm |
| 02:22:12 | headius | ~/projects/rubinius ➔ /Users/headius/projects/jruby/bin/jruby vm/instructions.rb |
| 02:22:19 | headius | /Users/headius/projects/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require': no such file to load -- parse_tree (LoadError) |
| 02:22:25 | headius | I call BS |
| 02:22:26 | headius | :) |
| 02:22:34 | brixen | ok |
| 02:22:37 | brixen | what file? |
| 02:22:43 | headius | vm/instructions.rb |
| 02:22:53 | brixen | well, that's the only one |
| 02:22:59 | brixen | and that is not kernel ;) |
| 02:23:00 | headius | cool |
| 02:23:05 | headius | I just said build |
| 02:23:08 | brixen | I assure you kernel is built with ruby_parser |
| 02:23:09 | headius | and "or something" |
| 02:23:22 | headius | looking at instructions.rb now |
| 02:24:07 | headius | seems to be codegen/instructions_gen |
| 02:25:07 | headius | hmmm |
| 02:25:21 | headius | it doesn't appear to be possible to run this with ruby_parser anymore |
| 02:27:49 | headius | dang |
| 02:27:55 | headius | I was hoping it was just a simple switch I could throw |
| 02:28:24 | brixen | well, we'll be removing that requirement anyway |
| 02:28:31 | brixen | just suffer with mri for a bit longer |
| 02:28:51 | headius | well, I'll see if I can fix it |
| 02:37:23 | headius | hmm, I just thought of a way we could support parsetree in a limited way |
| 02:38:31 | headius | ➔ jruby -X-C -rjruby/ext -e "def foo; [1,2].each {|a| puts a}; end; p method(:foo).sexp" |
| 02:38:40 | headius | "(newline (callnoargblock each (array (fixnum 1) (fixnum 2)) (iter (dasgn a (nilimplicit)) (newline (fcallonearg puts (array (dvar a)))))))" |
| 02:39:22 | headius | that's an internal sexp we build for jit purposes |
| 03:04:52 | evan | headius: i haven't committed it. |
| 03:05:01 | headius | committed what? |
| 03:05:12 | headius | I was using .jit still |
| 03:05:22 | headius | just didn't realize it still needed RBX_LLVM set |
| 03:07:08 | evan | oh |
| 03:07:18 | evan | i thought you meant it was doing it automatically |
| 03:07:25 | evan | which it's not. |
| 03:07:30 | headius | no |
| 03:07:45 | evan | that PT dep in instructions.rb can easily go away |
| 03:07:51 | headius | yeah, I'm working on it |
| 03:07:54 | evan | it was just to generate nice #line entries |
| 03:08:00 | evan | which I think we disabled a while ago anyway |
| 03:08:04 | evan | so it's just cruft. |
| 03:09:59 | headius | mmm, yeah, does seem to only be doing that |
| 03:11:13 | evan | headius: when you JIT a method |
| 03:11:21 | evan | how does that get installed? |
| 03:12:10 | headius | there's another layer of indirection that encapsulates InterpretedMethod when running in jit mode |
| 03:12:20 | headius | when it jits, the reference flips to a JittedMethod |
| 03:12:40 | headius | jit execution is a bit slower than precompiled execution as a result of the indirection right now as well |
| 03:13:52 | boyscout | Small compatibility change in capi's ruby.h - 60f62b7 - Cezar Sa Espinola |
| 03:13:52 | boyscout | Adding rb_gc_start() to capi. - 84e6679 - Cezar Sa Espinola |
| 03:13:52 | boyscout | Adding rb_exc_raise() to capi, with specs. - bf5ccd9 - Cezar Sa Espinola |
| 03:15:02 | headius | hmm |
| 03:15:15 | headius | the array that decode_methods produces is used for other things afterwards |
| 03:15:16 | headius | with the sexp in it |
| 03:15:48 | headius | grumble |
| 03:16:04 | headius | the output of RubyParser.parse appears to not be completely compatible with parse_tree_for_method |
| 03:16:44 | evan | cezarsa: if you wanna, would ya do rb_ensure too? |
| 03:17:24 | evan | headius: yeah, it's not. |
| 03:17:43 | evan | headius: because zenspider changed it to be the unified_ruby format |
| 03:17:51 | cezarsa | evan: sure, i'll take a look into it |
| 03:17:51 | headius | and you aren't using the unified format |
| 03:18:08 | evan | we're not? |
| 03:18:10 | evan | i thought we were. |
| 03:18:25 | headius | well something's preventing it from being compatible, right? |
| 03:18:30 | headius | I don't know, you tell me :) |
| 03:18:35 | evan | not that I know of. |
| 03:18:48 | evan | i'm not aware of any troubles. |
| 03:18:53 | cezarsa | evan: it took a while until I figured out how to make rb_rescue, things a clearer now :) |
| 03:18:53 | headius | my first attempt was to parse instructions.rb offline and put all the methods in hashes |
| 03:19:01 | headius | so you have the parse trees available |
| 03:19:02 | cezarsa | s/a/are |
| 03:19:20 | headius | but there's no flatten, for example |
| 03:19:40 | evan | i don't follow. |
| 03:19:59 | evan | well, cavs game is back on. |
| 03:20:07 | evan | bbial |
| 03:20:07 | headius | instructions_gen pulls sexps out of all the methods defined in instructions.rb |
| 03:20:18 | headius | flattens them, monkeys with lines, and then builds the structure |
| 03:20:26 | headius | bah |
| 03:20:38 | evan | oh that |
| 03:20:41 | evan | it's crap code |
| 03:20:48 | evan | we should just remove it entirely |
| 03:20:51 | evan | it's really crufty |
| 03:20:57 | evan | format wise, i've got NO clue what it does |
| 03:20:59 | headius | well, then I tried to just noop the sexp+line stuff and now it doesn't generate a valid.cpp |
| 03:21:05 | evan | it's a complete hack. |
| 03:21:10 | headius | I'll fiddle with it a bit more |
| 03:21:29 | boyscout | CI: bf5ccd9 success. 2682 files, 10328 examples, 32877 expectations, 0 failures, 0 errors |
| 03:59:36 | headius | hmm |
| 03:59:46 | headius | where are these #ruby directives in the instructions template handled? |
| 04:08:46 | headius | hey, I think I have it |
| 04:14:26 | headius | evan: got up to the point of compiling .rb files |
| 04:14:36 | headius | then it hit your oniguruma match_start call |
| 04:26:48 | headius | hmm, getting there |
| 04:26:52 | headius | implemented something pretty close to match_start and got further |
| 04:30:45 | headius | yakischloba: looks like wayne just landed your get_array_of_strings in jruby |
| 04:31:12 | yakischloba | headius: yeah, that's what he said. i've been slacking on getting him the specs and a few other fixes he wanted. suppose i should do that now. |
| 04:31:19 | headius | yes :) |
| 04:31:26 | yakischloba | not slacking. busy rather :) |
| 04:32:13 | headius | busy schmusy |
| 04:33:03 | yakischloba | heh. we just got 3 months worth of commits on eventmachine released *finally* |
| 04:34:34 | headius | nice |
| 04:34:44 | headius | jruby stuff being kept up to date too? |
| 04:35:04 | yakischloba | it hasn't been, but in the last month has received some special attention (even a cash bounty, heh) |
| 04:35:16 | yakischloba | so I think it'll be worked up pretty good in the next release |
| 04:35:34 | headius | wow, cash bounty? |
| 04:35:50 | yakischloba | yeah. couple guys put up $250 bucks for work on the java reactor. |
| 04:36:34 | yakischloba | I think EM runs some serious production systems, that most of us never hear too much about |
| 04:36:47 | headius | sounds familiar |
| 04:36:54 | headius | I think jruby runs a lot more stuff than we ever hear about too |
| 04:37:03 | yakischloba | yeah, which is unfortunate |
| 04:37:08 | headius | truly |
| 04:37:14 | yakischloba | people think they're shit because 'no one big is using it' |
| 04:37:40 | headius | hopefully there will be a couple big names coming out with jruby stuff soon |
| 04:38:23 | yakischloba | heh. it would be nice if the heavy users would come forward and say it, so everyone doesn't think ruby or project Foo is simply a toy |
| 04:39:56 | headius | yeah, I think it takes a good year or two of steady progress and quiet users for things to start coming out |
| 04:40:17 | headius | we've had production users for three years now but most people still don't come out and say it |
| 04:44:11 | yakischloba | yup. |
| 04:44:33 | headius | so hey, answer me a quick question |
| 04:44:45 | headius | someone told me EM couldn't host a multi-threaded server...why is that? |
| 04:44:59 | headius | I think events and I think asynchronous and I think threading |
| 04:45:14 | yakischloba | it certainly can. there were reasons not to, up until recently, but it should be pretty safe now. |
| 04:45:28 | headius | because it seems like that could be the server to beat all servers with jruby |
| 04:45:51 | yakischloba | I know precisely nothing about how the java reactor works |
| 04:45:52 | headius | makes it very similar to the best http servers in Java then |
| 04:46:05 | yakischloba | so if that's what you're asking about, I have no idea heh |
| 04:46:07 | headius | but in C...if the impl had parallel threads, would it work? |
| 04:46:15 | headius | or what would be required to make it work? |
| 04:46:32 | yakischloba | so you're saying the C++ reactor? |
| 04:46:36 | headius | yes |
| 04:46:46 | yakischloba | hooked up to jruby somehow? or to mri as it normally is |
| 04:47:02 | headius | just MRI but imagining an MRI with real parallel threading |
| 04:47:21 | headius | I'm just trying to understand what the current state is and what it would take to make it work with a real threaded impl |
| 04:48:02 | yakischloba | the current MRI implementation just has a thread-safe EM.next_tick(&blk) method that schedules a proc to be executed on the next reactor turn |
| 04:48:25 | yakischloba | so you just use that to do shit from threads |
| 04:48:52 | headius | well that's easy enough |
| 04:50:12 | yakischloba | so what *is* the deal right now with mri and real parallel threads? i've been trying to grasp this. just the stdlib/core/whatever you want to call it (array, string etc) is not thread safe? |
| 04:53:49 | headius | everything in C is not thread safe |
| 04:54:10 | headius | and they only have since global locations for VM state |
| 04:54:14 | headius | since=single |
| 04:54:36 | yakischloba | hmm |
| 04:54:48 | headius | so the entire execution engine would have to be rewritten and fine-grained locks or bounds checks put around all data mutating methods |
| 04:55:05 | headius | YARV comes a bit closer with execution engine, but does nothing for core classes |
| 04:55:25 | yakischloba | sorry, YARV is what I was referring to. my bad |
| 04:55:28 | headius | yeah |
| 04:55:37 | headius | yarv handles runtime state a bit more sanely |
| 04:55:42 | headius | but not core class data |
| 04:55:57 | yakischloba | which is a super pain in the ass to do? |
| 04:56:07 | headius | jruby kinda gets a free pass...we don't guarantee core classes are thread-safe, but the worst that happens is a single thread might raise a concurrency or array out of bounds exception |
| 04:56:22 | headius | because the JVM makes certain guarantees for us |
| 04:56:28 | headius | yeah, super pain in the ass |
| 04:56:29 | yakischloba | i see. |
| 04:57:06 | headius | it could still be done, certainly, but not without a lot of work |
| 04:57:16 | yakischloba | so we were all debating this a bit the other day. obviously you have significant interest in jruby and consider it a viable long term prospect |
| 04:57:26 | yakischloba | but what is a good concurrency plan for ruby? |
| 04:57:51 | headius | for the C impls? beats me...seems way too hard for me to contemplate a solution |
| 04:58:18 | yakischloba | hmm |
| 04:58:19 | headius | if I were to make a harsh recommendation...rewrite on top of a real VM |
| 04:58:37 | headius | not necessarily JVM |
| 04:58:53 | headius | just anything that's solved parallel threading for userland code already |
| 04:59:21 | yakischloba | i see |
| 04:59:47 | yakischloba | i learned to program on EM, with reactor pattern, so threading is somewhat foreign to me |
| 05:00:08 | yakischloba | but I am pretty interested in seeing ruby not be constrained to 1 processor |
| 05:00:19 | headius | well, in jruby there's not a whole lot to it if you keep data structures pretty isolated and use something safe to communicate between them |
| 05:00:22 | headius | threads just work |
| 05:00:54 | yakischloba | right |
| 05:01:22 | yakischloba | so i guess this leads into another thing that i've been meaning to ask you about for a while |
| 05:01:53 | yakischloba | i often see you seem a little exasperated that more people aren't using jruby |
| 05:02:01 | yakischloba | and logically i understand the reasons why it is good |
| 05:02:10 | yakischloba | but for whatever reason, I have never used it |
| 05:02:20 | yakischloba | so i guess i'm just curious how you can interest more people |
| 05:02:28 | headius | heh, does it show? |
| 05:02:40 | yakischloba | hah, does it ever |
| 05:02:43 | yakischloba | ;) |
| 05:02:48 | headius | I know I grouse about it a lot |
| 05:03:07 | headius | it's an uphill battle to make JRuby's coolness overcome Java's ultra uncooleness |
| 05:03:11 | yakischloba | which is fine. you have a large personal investment in it, and it has a disproportionately small following (that i am aware of, anyway) |
| 05:03:32 | headius | I think there's going to be a tipping point |
| 05:03:51 | headius | enough of the native gems ported over, enough visible users, enough of the little gotchas finally ironed out |
| 05:04:24 | headius | I don't think I'm too far off saying it's a superior implementation to the other production impls right now...maybe not the most advanced out of all the impls, but darn good |
| 05:04:46 | yakischloba | sure, i don't doubt it. and i don't really think thats what keeps people from using it |
| 05:04:58 | headius | there's just enough pain points and enough association with Java that we haven't hit that tipping point |
| 05:05:01 | yakischloba | yeah, i think a lot of it is just that it's related to java |
| 05:05:04 | headius | startup time for example |
| 05:05:12 | headius | those native extensions |
| 05:05:22 | headius | occasional bugs |
| 05:05:29 | headius | all of which improve release on release |
| 05:05:38 | yakischloba | is FFI the only way to access C libraries? |
| 05:05:42 | headius | it is |
| 05:05:50 | yakischloba | (not saying there should be another way) |
| 05:06:19 | yakischloba | so I think maybe you need to do a little more fanboy appeal intensive stuff maybe? |
| 05:06:46 | yakischloba | show me how easy it is to install and setup, show me its the ruby i know |
| 05:06:47 | headius | I guess part of our problem is that everyone interested in jruby right now is a pragmatist, not a fanboy :) |
| 05:06:51 | headius | so we don't really have those kinds of people |
| 05:06:59 | headius | they get their job done and keep pretty quiet |
| 05:07:11 | yakischloba | yeah |
| 05:08:16 | headius | I guess we don't really know what else we can do |
| 05:08:22 | headius | but keep improving, keep bridging the gap |
| 05:08:35 | headius | keep working 14 hours a day :) |
| 05:08:44 | yakischloba | heh |
| 05:09:30 | yakischloba | the website is not very approachable |
| 05:09:44 | yakischloba | looking at it now, i remember i've looked at it before and havent gotten past the landing page |
| 05:09:57 | headius | website is frigging horrible |
| 05:10:04 | yakischloba | well, theres your first place heh |
| 05:10:07 | yakischloba | make it easy for me to get started |
| 05:10:08 | headius | truly |
| 05:10:16 | headius | we'd be better off dropping them on a damn wiki |
| 05:10:19 | yakischloba | dont make my eyes bounce 30 different places before I find the "getting started" link :) |
| 05:10:24 | yakischloba | well |
| 05:10:26 | headius | confluence is the ugliest thing ever |
| 05:10:30 | yakischloba | that's where I end up after the landing page, heh |
| 05:10:50 | headius | in contrast, look at rubinius or macruby's pages |
| 05:11:01 | headius | million times better |
| 05:11:39 | yakischloba | shrug. i have recently developed an appreciation for extreme simplicity on web pages. rubinius gets it, macruby is still even a little cluttered |
| 05:12:49 | yakischloba | though, they do put it pretty well in your face |
| 05:12:57 | headius | it's definitely better than ours though |
| 05:13:04 | yakischloba | 1. 2. 3. |
| 05:13:05 | headius | ours has had a handful of edits in the past 3 years |
| 05:13:08 | yakischloba | bam, thats how i do it |
| 05:13:10 | yakischloba | with jruby im like |
| 05:13:37 | headius | we should put up a radiantcms or something |
| 05:13:40 | yakischloba | do i have to install some crazy java shit? is it like when i was working on an android app and i had to battle my package manager to get the right versions of everything? what the fuck am i doing? |
| 05:13:42 | headius | so we can have it be easly editable by users |
| 05:13:56 | headius | yeah |
| 05:14:07 | headius | for almost everyone it's like a two-step process |
| 05:14:16 | headius | unpack ; add to $PATH |
| 05:14:25 | headius | on some linuxes it's just a package install |
| 05:14:36 | yakischloba | okay, well show people that |
| 05:14:53 | yakischloba | i guarantee you fix that shit website, advertise it for a day or two, and you'll get a bunch of users |
| 05:15:14 | headius | perhaps that's better than me spending another day improving performance 5% |
| 05:15:42 | yakischloba | performance is important, but remember everyone is still running on mri 1.8.6 or 1.8.7 even though YARV is way faster |
| 05:15:49 | yakischloba | and it's just because ruby peopel are silly sometimes |
| 05:15:50 | headius | very true |
| 05:16:08 | headius | I've been wanting to put up more information on gem equivalencies and stuff too |
| 05:16:15 | yakischloba | and that can be solved by providing clarity |
| 05:16:16 | headius | if you use A on MRI, you can switch to B |
| 05:16:33 | headius | like imagescience versus imagevoodoo |
| 05:16:37 | yakischloba | I'm pretty sure if you made up a screencast of "here are the things that 1.9.1 breaks, and here's how to fix them" then people would start using it |
| 05:16:47 | headius | rmagick versus rmagick4j |
| 05:17:03 | yakischloba | but everyones like err uhhh but isnt there that thing that doesnt work? im not sure. i heard it wasnt that much faster anyway. this other thing doesnt work |
| 05:17:32 | headius | heh, yeah, I think I've heard that exact conversation :) |
| 05:17:47 | yakischloba | 1.9.1 isn't production, blah blah |
| 05:17:59 | headius | it's like the 1.8.7 thing |
| 05:18:09 | headius | it broke some stuff initially, and now it's forever tainted |
| 05:18:19 | yakischloba | yeah |
| 05:18:28 | headius | even though nobody can now say what it breaks, probably because there's nothing anymore |
| 05:18:46 | yakischloba | for fucks sake, users of this language that is the most dynamic thing to ever be created, are scared shitless of changes to it |
| 05:18:52 | headius | we've only recently gotten people to realize we run rails |
| 05:18:55 | headius | I mean, seriously |
| 05:19:14 | headius | "So, JRuby is neat, but can I run Rails on it?" |
| 05:19:18 | headius | bizarre |
| 05:19:25 | yakischloba | stop crying about how YARV doesn't work, change all your calls to String#each to String#each_line, and enjoy the fucking benefits |
| 05:19:51 | yakischloba | yeah that's another great example |
| 05:20:08 | yakischloba | but that's something I barely even knew |
| 05:20:20 | yakischloba | so resolving those murky things is key |
| 05:20:39 | headius | yeah |
| 05:20:45 | yakischloba | lay it out real simple for those people that develop and get hung up on the stigma |
| 05:20:57 | headius | if only sun's marketing dept weren't totally clueless |
| 05:21:01 | headius | we might have some real help |
| 05:21:49 | yakischloba | true, though i think it's not as hard as you think |
| 05:22:05 | headius | probably not...it's just not my thing |
| 05:22:16 | yakischloba | conveying truth, dispelling rumor, and making it approachable |
| 05:22:16 | headius | neither evan nor lrz did the rbx pages |
| 05:22:17 | headius | er |
| 05:22:19 | headius | rbx/macruby |
| 05:22:48 | headius | but of course I'm just making excuses at that point |
| 05:23:25 | yakischloba | right. there are plenty of design-er-ish people who would be happy to contribute a weekend of their time to getting jruby a nice website |
| 05:23:37 | headius | yeah, we need to just pull the trigger on that |
| 05:23:42 | yakischloba | so find one you like and do it heh |
| 05:23:51 | headius | we've had offers but never followed up...so damn busy |
| 05:24:07 | yakischloba | yeah well, you have a great impl now, so make it a priority |
| 05:24:38 | headius | you know, you're right...I think it's long past due |
| 05:25:11 | yakischloba | i'm certain that's why you don't have the user base you want |
| 05:26:20 | headius | yeah, it could be that simple |
| 05:26:23 | yakischloba | i'm a nerd so i'll spend time going through other peoples code to figure out how to use it etc, but a lot of people will turn straight away if they don't see immediately how it will benefit them and how little work they have to do to achieve it |
| 05:28:11 | headius | yeah, some of my best-received blog posts have been step-by-step instructions to do X with jruby |
| 05:28:15 | headius | seems obvious in retrospect |
| 05:28:46 | yakischloba | yup |
| 05:28:55 | headius | hell, even maglev has a better site than us, and theirs has nothing at all |
| 05:30:46 | slava | headius: remember the pointless tree benchmark? |
| 05:31:01 | headius | I remember lots of pointless tree benchmarks |
| 05:31:05 | slava | haskell's compiler makes it linear-time by doing common subexpression elimination |
| 05:31:23 | slava | make_node(x-1) and make_node(x-1) are pure functions right? :) so you don't have to compute it twice |
| 05:31:33 | slava | it was that ironpython -vs- jython blog post |
| 05:32:15 | headius | heh, doesn't surprise me |
| 05:32:44 | yakischloba | part if me wishes there weren't so many ruby impls. it makes it hard for someone to decide which one they might want to learn about and work on :p |
| 05:33:10 | headius | yakischloba: well, there's only one alternative impl that's actually used in production |
| 05:33:34 | yakischloba | yeah, but that's not what I mean |
| 05:33:34 | headius | so at least for usage, the choice isn't too hard |
| 05:33:44 | headius | yeah, I know :) |
| 05:33:55 | headius | if I weren't working on jruby I'd probably work on rubinius |
| 05:34:02 | yakischloba | why? |
| 05:34:20 | headius | I think it's the most likely to be open and community-driven |
| 05:35:14 | yakischloba | do you think it will achieve good performance and beyond? |
| 05:35:26 | headius | should I give my honest opinion on #rubinius? :) |
| 05:35:35 | yakischloba | depends on what it is :) |
| 05:35:42 | headius | I just realized we've been talking about all this in here instead of in #jruby |
| 05:35:53 | headius | everything hoped for rubinius is possible |
| 05:35:57 | headius | it just hasn't even been done yet |
| 05:35:59 | yakischloba | shrug. it's applicable. |
| 05:36:42 | yakischloba | of course. i'm not someone who looks at a project and says "it isn't done, therefore it's shit and i won't look at it" |
| 05:36:49 | slava | headius: who cares if maglev has a better web site |
| 05:36:54 | slava | they don't have a product |
| 05:37:03 | headius | if I were going to work on rubinius I'd be building it atop java 7 |
| 05:37:18 | slava | If I was working on java 7, I'd build it on top of llvm |
| 05:37:19 | headius | with the upcoming dynamic language support |
| 05:37:28 | headius | slava: well, that's already under way :) |
| 05:37:31 | yakischloba | it's a tough thing I guess. people have different goals for ruby. |
| 05:37:49 | slava | headius: so did people figure out how to do inline caching with llvm? |
| 05:37:57 | headius | beats me, I don't follow llvm |
| 05:38:39 | headius | yakischloba: truly |
| 05:42:52 | yakischloba | btw I hate kenai. its slower than molasses |
| 05:43:09 | headius | hmm, it never seems very slow to me |
| 05:43:10 | yakischloba | ffi has the approachability issue as well :p |
| 05:43:32 | headius | no slower than any other site anyway |
| 05:44:34 | headius | though I'm probably biased...kenai is a jruby on rails site |
| 05:44:46 | yakischloba | heh |
| 05:45:11 | headius | any perf concerns are not jruby's fault, I assure you |
| 05:45:24 | yakischloba | of course not! |
| 05:50:33 | headius | well, I've spent enough time yapping tonight |
| 05:50:41 | headius | yakischloba: thanks for the insight |
| 05:50:53 | yakischloba | haha same. am just finally getting started on the ffi thing. |
| 05:51:43 | yakischloba | headius: sure man. i hope i'm right and changing those things will help :) |
| 05:52:20 | headius | me too :) nite |
| 05:52:24 | yakischloba | night |
| 15:24:39 | boyscout | Adding rb_ensure() to capi, with specs. - ce4fe4e - Cezar Sa Espinola |
| 15:31:10 | boyscout | CI: ce4fe4e success. 2682 files, 10332 examples, 32881 expectations, 0 failures, 0 errors |
| 21:11:51 | marcandre | Anyone has clues on to reason with Matz? |
| 21:12:03 | slava | what did Matz do? |
| 21:12:35 | marcandre | Well, in 1.8.7, I noticed that str.each_char returns str.dup and not str. |
| 21:12:49 | marcandre | Now he wants me to _justify_ my patch. |
| 21:13:00 | slava | why should each_char return anything? |
| 21:13:07 | rue | I agree, it does need justification |
| 21:13:08 | slava | iterating over characters is something you'd do for side-effect |
| 21:13:10 | tarcieri | marcandre: be part of the Japanese ruby-core in-group |
| 21:13:12 | slava | map-char would return a new string |
| 21:13:18 | rue | slava: Ruby is all expressions |
| 21:13:34 | marcandre | Yeah, the discussion is on ruby-core. |
| 21:13:40 | slava | rue: sure, but that doesn't mean everything has to evaluate to something arbitrary |
| 21:13:49 | tarcieri | marcandre: otherwise you are no good gaijin out-group person |
| 21:13:51 | rue | marcandre: You cannot just drop a patch without any reason for the change |
| 21:14:10 | rue | That said, the consistency argument is simple |
| 21:14:36 | marcandre | OK. Can I respond, without sounding too arrogant: |
| 21:14:43 | slava | I think at some point once JRuby and Rubinius gain enough momentum you can stop trying to remain compatible with MRI braindamage |
| 21:14:45 | marcandre | Please name one single method that returns a dupped copy of self |
| 21:14:50 | marcandre | Please name one single reason why each_char should return a dupped copy of self instead of self |
| 21:15:12 | tarcieri | slava: hopefully... 1.8.7+ sounds like it's going to be a train wreck |
| 21:15:29 | marcandre | Please bet $10k against me that a survey of rubyists would find that a third or more would expect each_char to return a dupped copy of str? |
| 21:15:34 | tarcieri | slava: the Python people totally had it figured out with from __future__ import |
| 21:15:45 | rue | marcandre: Um, why be snotty about it? |
| 21:16:18 | marcandre | Because, last time I checked, I was not compensated for my time spent arguing about things that shouldn't be arguable! |
| 21:16:30 | tarcieri | want some 1.9 feature in your 1.8 program? then elect to turn it on |
| 21:16:59 | rue | I am not aware of any international agreements that require #each must return self, not a copy |
| 21:17:02 | marcandre | I'm gladly issuing a patch for what is clearly a bug, and instead of thanks, that has been committed, I get a "please justify" |
| 21:17:27 | marcandre | rue: can you name me one method (apart for each_char) that returns self.dup. |
| 21:17:52 | marcandre | rue: alternatively, please name one single reason why each_char should return a dupped copy of self instead of self |
| 21:17:54 | rue | No. So why not give that reason? |
| 21:18:02 | rue | And not be an asshole about it |
| 21:18:59 | rue | "This change was made to bring #each_char in line with all the other #each* methods which all return self, not a copy. It should follow the same pattern unless there is a crucial reason not to, and in that case it must be clearly documented." |
| 21:19:00 | marcandre | If _nobody_ can see a _single_ reason why the current behavior is correct, and _nobody_ can show me another method with the behavior I'm calling a bug... |
| 21:19:10 | marcandre | Then why do I have to justify it? |
| 21:19:15 | rue | Seriously, I do not understand the attitude |
| 21:20:37 | marcandre | It probably has something to do with my perception of an enormous entropy on ruby-core. |
| 21:20:56 | marcandre | See for instance my 1 line patch submitted 3 months ago (#1165) |
| 21:21:28 | marcandre | Recalled 2 or 3 times to n0kada. |
| 21:22:01 | marcandre | I have the feeling I am fighting with ruby-core to improve Ruby, while I should be feeling I am collaborating with ruby-core. |
| 21:22:35 | slava | time to make your own language |
| 21:22:38 | rue | You cannot do much about the other people, but I would recommend you stop "fighting" |
| 21:22:40 | slava | :) |
| 21:22:51 | marcandre | slava: :-) |
| 21:23:01 | rue | It really is not much to ask to provide a reason for making a change |
| 21:23:09 | marcandre | rue: Do you mean I should stop submitting patches? |
| 21:23:22 | slava | contribute to rbx instead, evan is a very reasoanble guy |
| 21:23:35 | rue | No, you should stop "fighting" |
| 21:23:57 | marcandre | slava: I am :-) And it's been a really enjoyable experience, contrary to the really frustrating experience of contributing to ruby-core |
| 21:24:40 | marcandre | rue: I don't want to fight! But I don't feel respected when asked unreasonable questions and when my humble contributions are not being addressed in a reasonable fashion. |
| 21:24:51 | tarcieri | slava: YES! |
| 21:24:53 | tarcieri | HEHE |
| 21:25:12 | rue | marcandre: Addressing this one instance only, there is just the patch. No comment why it was made and what it was intended to do |
| 21:26:17 | marcandre | rue: I did address talk with n0kada and tought I had addressed his questions about it. Moreover, this is another case where I don't see why a discussion is needed. |
| 21:26:25 | marcandre | Or how about #1385. |
| 21:26:47 | marcandre | It took 3 weeks for Matz to say "I confirm". Ticket still opened, change to the doc not made. |
| 21:27:44 | rue | Seriously, man, *I* would reject the patch if you could not tell me why you made the change |
| 21:27:53 | rue | But you can! |
| 21:29:03 | marcandre | I thought I had given the example for the bug in 1165. The fact that the == doesn't do what the official documentation states, in addition to common sense, should be justification enough, no? |
| 21:29:59 | marcandre | I guess what I don't understand is: isn't the goal of ruby-core to improve Ruby and MRI? |
| 21:31:07 | tarcieri | yes, but the culture/process is a bit... jacked |
| 21:31:15 | rue | OK, I am done talking about this. |
| 21:31:27 | tarcieri | rue's message was great |
| 21:31:30 | tarcieri | you should send them that |
| 21:32:18 | marcandre | I agree rue's message is very good, and I'll answer that then. |
| 21:32:43 | marcandre | I'm still wondering why I have to. |
| 21:32:59 | tarcieri | to be diplomatic |
| 21:33:03 | tarcieri | to their in-group |
| 21:33:03 | tarcieri | heh |
| 21:33:10 | yakischloba | marcandre: if it is this frustrating, perhaps it would be more healthy for you to concentrate your efforts elsewhere |
| 21:34:01 | marcandre | maybe I should. My real wish though would be that the (very small) issues I'm raising would be resolved! |
| 21:37:43 | marcandre | Thanks to everyone for the discussion. |
| 21:39:33 | tarcieri | hey slava |
| 21:39:42 | tarcieri | you implement eval using a metacircular evaluator? |
| 21:39:57 | tarcieri | Erlang does the same thing, except their eval is a ginormous hack |
| 21:40:00 | rue | I *think* the reason for the current implementation is what Matz is intimating; if there is a modification to the string, returning the dup is the only way to get both (as dumb as I think the overall idea of protecting against mutation there is) |
| 21:40:05 | slava | tarcieri: no, I don't have a metacircular interpreter |
| 21:40:07 | tarcieri | o |
| 21:40:23 | tarcieri | because iiuc rbx just compiles a temporary bytecode object thing |
| 21:40:27 | slava | eval parses and compiles the code using the various runtime APIs for this purpose, its just a convenience library |
| 21:40:28 | tarcieri | and that's what I'd like to do as well |
| 21:40:34 | tarcieri | cool |
| 21:40:48 | slava | its slower though |
| 21:40:51 | tarcieri | yeah I'd like to just build a temporary module and call a function on it then unload it |
| 21:40:55 | slava | I don't really care about eval at all |
| 21:40:58 | tarcieri | heh |
| 21:41:01 | tarcieri | well you have a repl right? |
| 21:41:15 | slava | yeah, but it doesn't matter if repl input takes an extra millisecond or two to compile |
| 21:41:20 | tarcieri | Zyeah exactly |
| 21:41:25 | slava | javascript people really abuse eval so badly |
| 21:41:27 | tarcieri | I mean, I *need* eval for a repl |
| 21:41:33 | slava | V8 and SquirrelFish have an LRU cache to map string -> AST even |
| 21:41:41 | slava | and they fast-path some forms of eval where its just getting a local variable value or something |
| 21:41:46 | tarcieri | yeah |
| 21:41:46 | slava | and they don't JIT eval'd code |
| 21:41:53 | tarcieri | i c |
| 21:41:59 | tarcieri | I just want eval to like... work properly |
| 21:42:01 | slava | its just a pain in the ass and its only needed because of all the shitty web designer javascript coders |
| 21:42:15 | slava | for a REPL you'd be OK by compiling the string to bytecode and running that |
| 21:42:27 | tarcieri | my eval is broken in all sorts of places because I'm thunking to another language's metacircular interpreter which is already wonky to begin with |
| 21:42:33 | slava | a metacircular interpreter specially for eval would be faster sure but its not worth the effort IMO |
| 21:42:51 | slava | like you can skip the compilation step and just walk the AST |
| 21:42:59 | slava | but now you have to ensure the semantics match 100% |
| 21:43:03 | tarcieri | yes |
| 21:43:05 | tarcieri | that's the problem |
| 21:43:30 | tarcieri | that's why I like the compiled solution |
| 21:43:34 | tarcieri | there's no impedence mismatch |
| 21:43:39 | slava | eval of an empty string takes 0.000153 seconds heh |
| 21:43:48 | slava | in factor |
| 21:43:51 | tarcieri | nice |
| 21:43:58 | slava | that's pretty slow if you're a webtard doing eval in a loop |
| 21:44:28 | tarcieri | heh |
| 21:44:50 | slava | if you expose the AST then most uses of eval for meta-programming go away |
| 21:44:56 | tarcieri | yes |
| 21:45:01 | slava | eval is really string -> AST -> bytecode/native code |
| 21:45:04 | tarcieri | my main interest is the repl |
| 21:45:18 | slava | in common lisp, the AST -> code step is the 'compile' function |
| 21:45:23 | tarcieri | that's why I don't compile to core erlang right now |
| 21:45:27 | marcandre | rue: That argument would hold for any other method. My 5 cent bet is simply that it's an oversight (and in my mind that should not be insulting at all!). In any case, I have responded with your very diplomatic phrase (and I tried not to talk in your place) |
| 21:45:32 | slava | and that's a generally more useful thing to have than eval |
| 21:45:56 | slava | it sounds like rbx has a good separation of concerns here too, which is nice to hear |
| 21:46:07 | tarcieri | slava: yeah, that's why I was wanting to copy rbx's approach |
| 21:46:24 | tarcieri | right now I'm basically creating my own equivalent of CompiledMethod |
| 21:46:43 | tarcieri | and as I understand rbx uses CompiledMethod to implement eval |
| 21:48:23 | tarcieri | slava: I think my general roadmap is something like... implement my CompiledMethod equivalent, add a few more language features, then rewrite the compiler in Reia itself, and have it output Core Erlang |
| 21:48:46 | slava | just don't lose your only working copy of the bootstrapped compiler |
| 21:48:51 | tarcieri | heh |
| 21:48:53 | tarcieri | yeah definitely |
| 21:49:10 | slava | imagine if all copies of gcc in the world just stopped working |
| 21:49:20 | slava | oh noes! time to write new C compiler in asm |
| 21:49:25 | tarcieri | heh |
| 21:49:31 | tarcieri | yeah |
| 22:30:52 | evan | allo kids |
| 22:31:45 | evan | been buying beer and cleaning up the loft |
| 22:36:11 | evan | as it applies to the return value of #each and friends |
| 22:36:22 | yakischloba | nice |
| 22:36:22 | evan | i'd say that if consistence is a worry |
| 22:36:26 | evan | they should return nil |
| 22:36:48 | evan | and require the user to use the more explicit methods to define the behavior |
| 22:39:09 | marcandre | Thanks evan. I just noticed that the patch has been applied by Matz. :-) |
| 22:39:25 | marcandre | I've updated my older tickets too. |
| 22:39:32 | yakischloba | marcandre: maybe the world is not stacked against you after all :) |
| 22:39:57 | marcandre | lol |
| 22:41:04 | marcandre | Actually, I doubt I'm the only one who would like changes to ruby-core applied more easily! |
| 22:41:09 | marcandre | I'll try to get my patches applied one by one :-) |
| 22:41:40 | evan | marcandre: oh? he changed each_char back to returning self? yay. |
| 22:42:06 | evan | i didn't like the change mainly because it's an overhead burdon |
| 22:42:20 | evan | ie, if each_char can function without having to make an internal opy |
| 22:42:21 | evan | copy |
| 22:42:32 | marcandre | Oh, the dup is still there. |
| 22:42:32 | evan | it shouldn't be burdoned with having to make on just to mean the API definition |
| 22:42:43 | evan | as long as the dup is completely internal |
| 22:42:44 | evan | thats fine. |
| 22:42:47 | evan | thats an impl detail |
| 22:42:49 | marcandre | Exactly |
| 23:50:11 | evan | doing phase 2 of GIL removal |
| 23:50:22 | evan | the ability to communicate the intend to stop the world |
| 23:50:26 | evan | intent |
| 23:55:43 | marcandre | evan: I'd love some help... |
| 23:56:07 | marcandre | I noticed that a couple of String methods have arg = nil, when it should be arg = Undefined. (e.g. gsub, initialize, ...) |
| 23:56:23 | marcandre | But changing them creates really funky problems. |
| 23:56:40 | marcandre | rbx |
| 23:56:41 | marcandre | irb(main):001:0> 1+1 |
| 23:56:42 | marcandre | => 1 |
| 23:56:44 | marcandre | [18:55][~]$ |
| 23:56:48 | marcandre | Any clue? |
| 23:57:04 | marcandre | Note that it quits after any input |
| 23:58:12 | rue | One thing is you must be sure that Undefined is not getting returned |
| 23:59:28 | rue | And you changed the checks to be against Undefined specifically, right? |
| 23:59:45 | marcandre | Yes,' |
| 23:59:56 | marcandre | I'm doing them one by one to see which one causes that. |