Show enters and exits. Hide enters and exits.
| 00:02:11 | boyscout | CI: rubinius: 8a4758c successful: 3463 files, 13809 examples, 41469 expectations, 0 failures, 0 errors |
| 00:05:50 | brixen | erg, I sigbus'd it |
| 06:15:27 | brixen | marcandre: got it fixed :) |
| 07:09:24 | boyscout | Changed libgdtoa g_dfmt() to emit MRI format for minimal, unique String representation of Float. - b687fb8 - Brian Ford |
| 07:09:24 | boyscout | Added to_s_minimal primitive for Float#to_s. - c2bee83 - Brian Ford |
| 07:09:24 | boyscout | Rewrote Float#to_s specs. - e92cbca - Brian Ford |
| 07:09:24 | boyscout | Removed CI tags for passing String#to_s specs. - de14e67 - Brian Ford |
| 07:09:24 | boyscout | Hack to ensure libgdtoa is rebuilt. - bac27ed - Brian Ford |
| 07:21:06 | boyscout | CI: rubinius: bac27ed successful: 3463 files, 13823 examples, 41473 expectations, 0 failures, 0 errors |
| 07:25:55 | matthewd | brixen: Shouldn't `bin/mspec ci spec/capi` run a subset of the specs that `bin/mspec ci` would run? |
| 07:26:16 | brixen | no |
| 07:26:23 | brixen | but I can see why you'd think that |
| 07:26:31 | brixen | check out spec/default.mspec |
| 07:26:48 | brixen | bin/mspec ci runs :ci_files |
| 07:27:00 | matthewd | Yeah, the help seems to suggest it... "To run a subset of the known good specs" :/ |
| 07:27:03 | brixen | see the ^spec/capi lines |
| 07:27:14 | brixen | the ^ is 'exclude' |
| 07:27:57 | brixen | matthewd: what are you working on with capi? |
| 07:28:48 | brixen | I've got rb_class_new, rb_class_inherited, rb_const_defined_at, rb_const_get_at here |
| 07:28:56 | brixen | working on specs for them |
| 07:28:56 | matthewd | rb_f_global_variables and rb_str_new3 |
| 07:29:00 | brixen | ok |
| 07:29:03 | matthewd | And a missing prototype for rb_apply |
| 07:29:04 | brixen | cool |
| 07:30:16 | boyscout | rb_protect's callback takes a VALUE, not ANYARGS. - 4bdb9cc - Matthew Draper |
| 07:30:16 | boyscout | Add apparently-missed prototype for rb_apply() - 2396aea - Matthew Draper |
| 07:30:16 | boyscout | Add rb_f_global_variables() and rb_str_new3(). - dedae82 - Matthew Draper |
| 07:30:16 | boyscout | Spec rb_f_global_variables() and rb_str_new3(). - cfa7989 - Matthew Draper |
| 07:30:56 | brixen | woot |
| 07:31:03 | brixen | ok, sleep for me |
| 07:39:26 | boyscout | CI: rubinius: cfa7989 successful: 3463 files, 13824 examples, 41475 expectations, 0 failures, 0 errors |
| 11:38:32 | boyscout | Clang doesn't need this hack that fixes a GCC complaint - 806388b - Dirkjan Bussink |
| 11:38:32 | boyscout | Linking with Clang doesn't implicitly add libstdc++ - 69e90e1 - Dirkjan Bussink |
| 11:39:59 | kronos_vano | dbussink, What's the point of clang? |
| 11:45:36 | ddfreyne | what’s the point of gcc if you have clang? |
| 11:46:33 | boyscout | CI: rubinius: 69e90e1 successful: 3463 files, 13824 examples, 41475 expectations, 0 failures, 0 errors |
| 14:48:31 | dbussink | kronos_vano: did you ever see clang error messages compared to gcc? |
| 16:04:09 | matthewd | brixen: The compiler emits push_const in a bunch of places that I'm pretty sure should be push_cpath_top/find_const |
| 16:04:37 | Defiler | probably explains a bug I haven't had time to hunt down |
| 16:05:32 | matthewd | brixen: eg: class A; class Regexp; end; def x; /oops/; end; end; A.new.x |
| 16:08:59 | Defiler | nice test case; working on it now |
| 16:14:54 | bluestorm | hello |
| 16:15:42 | bluestorm | I'm looking for a high-level answer to a simple question : why does rubinius use so much more memory than classical Ruby implementations ? |
| 16:16:51 | Defiler | Two main answers to that question |
| 16:16:58 | Defiler | 1) it is newer than the others |
| 16:17:22 | Defiler | 2) more things are exposed as objects in order to enable introspection, the ability to build powerful extensions of the runtime in ruby, etc |
| 16:17:32 | bluestorm | hm |
| 16:17:38 | Defiler | #1 will improve over time, #2 means that rbx will always use more memory than mri |
| 16:17:44 | bluestorm | so the data representation is more memory-hungry |
| 16:17:47 | Defiler | just the classic memory usage / feature tradeoff |
| 16:18:01 | Defiler | Not the actual objects themselves, at least not by much |
| 16:18:05 | Defiler | but there are more objects allocated |
| 16:18:35 | bluestorm | and do you have an idea of what a reasonable target might be ? |
| 16:18:42 | Defiler | nope! |
| 16:19:09 | bluestorm | (are there still relatively low-hanging fruits just waiting to be optimized ?) |
| 16:20:20 | Defiler | probably; the memory profiler is getting some love and improvement currently |
| 16:20:26 | Defiler | and that will be handy |
| 16:20:39 | bluestorm | ok, thanks |
| 16:21:03 | Defiler | sometime when evan is around, I'm sure he can give you some actual facts |
| 16:21:25 | bluestorm | maybe you should add that information to the FAQ ? |
| 16:22:18 | Defiler | It's been in some versions of such things |
| 16:22:21 | Defiler | must not be on the new site |
| 16:32:39 | brixen | matthewd: yes, the two push_const :Regexp in literals.rb are wrong |
| 16:32:50 | brixen | matthewd: we do it correctly in GlobalVariableAssignment |
| 16:33:12 | brixen | matthewd: evan mentioned adding an insn to put Rubinius on the stack |
| 16:33:19 | Defiler | yeah, running the test suite now after changing those |
| 16:33:26 | brixen | that's probably a good idea |
| 16:33:47 | brixen | Defiler: sweet |
| 16:33:58 | brixen | matthewd: where there other examples you had? |
| 16:35:02 | brixen | grabbing some food, bbiab... |
| 16:35:25 | brixen | Defiler: btw, how do you like the new compiler? |
| 16:35:31 | Defiler | it is jawesome |
| 16:35:35 | brixen | have you poked around it much? |
| 16:35:59 | matthewd | brixen: Basically I just did a grep for push_const in spec/compiler, and was suspicious that any such mention of a well-known constant is likely dangerous |
| 16:36:10 | brixen | matthewd: yep, ok |
| 16:36:37 | matthewd | (The Regexp one was the one I actually hit; it's entirely possible the others are actually all innocuous) |
| 16:37:04 | brixen | the others that I see are all Rubinius |
| 16:37:14 | brixen | and we'll likely add an insn for that |
| 16:37:35 | brixen | the only other is ConstantAccess, and that is right afaics |
| 16:37:46 | brixen | since that is the point of that node |
| 16:38:59 | brixen | Defiler: seen this site? http://www.dalnefre.com/wp/2010/05/composing-actors/ |
| 16:39:02 | brixen | fun stuff |
| 16:39:13 | brixen | the syntax of hummus is pretty terrible |
| 16:39:25 | brixen | but all that is directly applicable to ruby |
| 16:40:19 | brixen | oh, humus has one em |
| 16:40:21 | matthewd | Ah, yes... the others are all legit parsings of the actual code. That'll teach me for not looking closer :) |
| 16:40:32 | brixen | no worries, nice catch |
| 16:44:47 | matthewd | Next bit of fun :) |
| 16:44:50 | brixen | matthewd: oh, heh, grepping lib/compiler/ast is much more instructive |
| 16:44:57 | brixen | I see you grepped spec/compiler |
| 16:45:21 | Defiler | cool, green suite again |
| 16:45:23 | Defiler | will push in a bit |
| 16:45:28 | brixen | Defiler: awesome |
| 16:45:45 | matthewd | Given class A; class B; end; module M; end; end... rb_define_module_under(rb_cB, "M")... doesn't. |
| 16:45:56 | matthewd | Instead, it returns A::M |
| 16:46:42 | brixen | hmm |
| 16:47:30 | matthewd | Because define_module_under uses Helpers::open_module, uses const_get_under, which searches upwards |
| 16:47:42 | brixen | yeah |
| 16:47:53 | brixen | probably not hard to fix |
| 16:48:05 | brixen | but I really must food myself, back in a bit |
| 17:01:46 | matthewd | Yeah, doesn't look to be as tricky as I feared; I'd assumed I'd need to deal with multiple callers with differing requirements |
| 17:02:52 | matthewd | Interestingly, open_class already gets it right |
| 17:06:35 | dbussink | brixen: got rbx to compile and link with clang :) |
| 17:06:40 | dbussink | brixen: also built the extensions |
| 17:06:56 | dbussink | whole slew of warnings in openssl though, but that isn't surprising |
| 17:08:00 | brixen | dbussink: awesome! |
| 17:08:29 | brixen | matthewd: yeah, MRI often has a method that takes flags and alters it's behavior |
| 17:08:36 | brixen | eg rb_const_get_0 |
| 17:08:50 | brixen | matthewd: we probably just did not have enough specs to catch this |
| 17:11:38 | cremes | dbussink: perf difference between gcc/clang when running specs? |
| 17:12:00 | dbussink | cremes: haven't found any real differences, both were clocking in at 100s. for a compiled spec run |
| 17:12:22 | cremes | too bad; was looking for a "free" performance win for ruby |
| 17:23:44 | dbussink | cremes: well, haven't seen any benchmarks where clang is really faster, mostly either the same or slower |
| 17:23:58 | dbussink | gcc has a lot of optimization history over time of course |
| 17:24:31 | cremes | sure, but one of the supposed benefits of the llvm project is a cleaner architecture which allows for *easier* implementation of new optimization techniques |
| 17:24:40 | cremes | i thought maybe they had gotten to some of those by now |
| 17:28:33 | dbussink | cremes: true, but even so, beating a long history is hard :) |
| 17:28:47 | dbussink | cremes: but i really like the way better error messages for one |
| 17:29:31 | cremes | yes, better error messages are a good benefit! i wish ruby had them... ;) |
| 17:30:41 | brixen | cremes: where would you like to see better error messages? |
| 17:30:49 | brixen | cremes: when template expansion fails? |
| 17:30:57 | brixen | oh wait, we don't have that in ruby :) |
| 17:31:01 | cremes | heh |
| 17:31:24 | cremes | i think a lot of the syntax error messages are pretty poor in ruby; i haven't checked rbx to see if they are better/improved |
| 17:31:37 | cremes | oftentimes mri points me in the wrong direction to fix a syntax mistake |
| 17:31:44 | matthewd | brixen: Grepping for rb_define_module_under in spec/ does support your "not enough specs" theory ;) |
| 17:31:45 | brixen | part of that is a consequence of the parser tech |
| 17:31:56 | cremes | struggling to think of a specific example |
| 17:32:13 | brixen | matthewd: I suppose it does, huh :) |
| 17:32:22 | dbussink | cremes: it's better than gcc though :) |
| 17:32:29 | brixen | cremes: evan added better missing end detection for us |
| 17:32:31 | cremes | dbussink: indeed |
| 17:32:54 | dbussink | missing end is probably the only one that frustrating on a semi regular basis |
| 17:32:55 | cremes | brixen: a good start; how about warning about unused variables (which are oftentimes misspellings?) |
| 17:33:00 | dbussink | that i can remember of |
| 17:33:09 | cremes | i know, i know, specs should catch those errors |
| 17:33:11 | brixen | cremes: that is a possibility |
| 17:33:12 | cremes | i don't always write specs |
| 17:33:20 | brixen | cremes: but that is not a parser deal really |
| 17:33:25 | brixen | we could add that to the compiler |
| 17:33:43 | cremes | i'll take your word for it; i don't really know the guts of parsers and/or compilers |
| 17:33:44 | brixen | it's quite complicated though by the fact that a vcall and a local look the same to the parser |
| 17:34:03 | matthewd | ... unless you encounter an eval, or your binding is published, ... ;) |
| 17:34:10 | cremes | perhaps extra checking could be enabled with the -w switch |
| 17:34:26 | cremes | with the knowledge that it make give false positives |
| 17:34:41 | cremes | WWSTD? (what wold smalltalk do?) |
| 17:34:46 | cremes | :) |
| 17:34:54 | brixen | we can require you to put () on every call ;) |
| 17:35:01 | cremes | no! |
| 17:35:05 | brixen | that vastly simplifies it |
| 17:35:08 | cremes | yucky |
| 17:35:15 | brixen | remember power => responsibility |
| 17:35:21 | cremes | yes, yes... |
| 17:35:22 | brixen | where => is 'implies' |
| 17:35:34 | cremes | wants cake and to eat it too |
| 17:35:38 | brixen | yeah |
| 17:36:04 | cremes | i'll let you get back to work; time for my weekend workout |
| 17:36:19 | brixen | heh |
| 17:36:20 | brixen | cool |
| 17:40:14 | boyscout | rb_define_module_under() shouldn't return a parent's module. - 354dc79 - Matthew Draper |
| 17:40:14 | boyscout | Spec rb_define_module_under(). - 9193f9c - Matthew Draper |
| 17:47:47 | boyscout | Ensure the proper Regexp constant is found when processing literals - c853b86 - Wilson Bilkovich |
| 17:48:14 | Defiler | matthewd: That should fix it |
| 17:48:17 | boyscout | CI: rubinius: 9193f9c successful: 3463 files, 13826 examples, 41478 expectations, 0 failures, 0 errors |
| 17:50:05 | Defiler | brixen: interesting 'composing actors' link; I'll keep it open and read it today |
| 17:51:52 | matthewd | Defiler: Great! |
| 17:56:34 | evan | morning gents. |
| 18:03:57 | brixen | morning |
| 18:05:30 | brixen | evan: I type rbx -Xagent.start in one terminal; rbx console in the other; it starts; I type bt in the console and it sigbuses |
| 18:05:44 | evan | rad. |
| 18:05:47 | brixen | heh |
| 18:05:51 | brixen | what am I doing? |
| 18:05:56 | evan | please get a gdb backtrace of the target rbx |
| 18:06:06 | evan | well, wait, which thing sigbuses? |
| 18:06:11 | evan | rbx console or the target? |
| 18:06:12 | brixen | target is? |
| 18:06:17 | brixen | target then |
| 18:06:18 | evan | the target is the other rbx |
| 18:06:22 | evan | the one that ran -Xagent.start |
| 18:06:42 | evan | ok, run the target under gdb and do it again |
| 18:06:45 | evan | and get a backtrace |
| 18:06:51 | evan | you'll probably need backtraces of all the threads |
| 18:06:51 | evan | so do |
| 18:06:55 | brixen | http://gist.github.com/410249 |
| 18:06:58 | evan | `thread apply all bt` |
| 18:07:10 | evan | ah ok. |
| 18:07:12 | evan | got it. |
| 18:07:20 | brixen | k |
| 18:07:24 | evan | i'm refactoring that code a little right now. |
| 18:07:31 | evan | do run it under gdb though |
| 18:07:36 | evan | and find out which source line it's on. |
| 18:07:50 | evan | I'm going to work on the fact taht we're not demangling the symbols also. |
| 18:08:40 | brixen | k |
| 18:08:49 | evan | i've backed out this refactor |
| 18:08:55 | evan | so i can debug this for ya. |
| 18:09:00 | evan | Just need the source line |
| 18:09:11 | matthewd | Exception: `Rubinius::InvalidRBC' kernel/delta/codeloader.rb:122 - /home/matthew/src/rbx/spec/ruby/command_line/fixtures/debug.rbc |
| 18:09:42 | matthewd | In the middle of a spec run. Not the first time I've seen it... goes away if I run again. |
| 18:09:42 | evan | matthewd: yep, thats fine. |
| 18:09:50 | evan | yep, it's actually expected. |
| 18:09:55 | evan | because that spec tests that -d is used |
| 18:10:03 | evan | and since -d causes exceptions to be printed out, that is printed |
| 18:10:09 | evan | because debug.rbc is out of date |
| 18:10:16 | evan | we should probably surpress stderr |
| 18:10:24 | matthewd | Ah, okay |
| 18:11:26 | brixen | evan: http://gist.github.com/410251 |
| 18:11:34 | brixen | want me to build debug? |
| 18:12:02 | evan | oh interesting. |
| 18:12:03 | evan | sure |
| 18:12:05 | brixen | er sec, new past coming |
| 18:12:07 | evan | what is the target running? |
| 18:12:14 | Defiler | brixen: So, I've got some little cases that break due to the cpath_top thing, which I just fixed for Regexp.. |
| 18:12:17 | evan | i'll bet I can repro it. |
| 18:12:28 | brixen | target is running irb |
| 18:12:33 | evan | oh fun! |
| 18:12:34 | evan | ok |
| 18:12:37 | Defiler | I'm fixing the ones that break when you define a 'Rubinius' constant closer to your code than toplevel though |
| 18:12:49 | evan | Defiler: ok, cool. |
| 18:12:53 | Defiler | should I put those in somewhere? or just assert the proper bytecode generation and change it |
| 18:12:58 | brixen | evan: refresh the gist |
| 18:13:13 | Defiler | e.g. https://gist.github.com/08b20f667bd783e9b686 |
| 18:13:14 | boyscout | A Time is not eql? to a non-time. - e966ea0 - Matthew Draper |
| 18:13:14 | boyscout | Spec Time#eql?(non_time_value). - cc9d10f - Matthew Draper |
| 18:13:16 | brixen | evan: we were going to add a push_rubinius insn no? |
| 18:13:28 | evan | yeah, we still should. |
| 18:13:32 | evan | Defiler: you want to do that? |
| 18:13:39 | evan | it's so easy to add a new instruction now. |
| 18:13:50 | evan | I only ask that you add them to the bottom of the .def file |
| 18:13:55 | Defiler | oh, ok.. so make push_rubinius instead of having to do cpath_top etc |
| 18:13:59 | evan | for 2.0, we'll reorganize the file. |
| 18:14:03 | evan | Defiler: yeah. |
| 18:14:11 | Defiler | OK, sure |
| 18:14:45 | evan | brixen: ok, easy! got the crash here. |
| 18:14:47 | evan | debugging now. |
| 18:14:54 | Defiler | what do I need to ensure I re-bootstrap these days? |
| 18:15:08 | brixen | evan: ok, cool |
| 18:15:14 | Defiler | (after adding an instruction) |
| 18:15:20 | evan | oh, we're not demangling in the segv handler... |
| 18:15:23 | brixen | Defiler: you should be able to just build |
| 18:15:25 | evan | hm, i wonder if we should... |
| 18:15:35 | evan | Defiler: just run rake |
| 18:15:39 | brixen | Defiler: everything gens off of instructions.def |
| 18:15:39 | evan | Defiler: we've got everything wired up now. |
| 18:16:01 | Defiler | so rad |
| 18:16:42 | evan | hm, i probably shouldn't demangle in the segv handler |
| 18:16:57 | brixen | probably not |
| 18:17:01 | brixen | that's last ditch |
| 18:18:00 | brixen | put the message in the bottle and hope the archeologists think there was intelligent life before the apocalypse |
| 18:18:45 | evan | i'm betting that abi::__cxa_demangle has a pretty high complexity. |
| 18:19:20 | matthewd | Hrmm... // @todo should coerce other types |
| 18:19:25 | evan | oh, I could exec from the handler |
| 18:19:29 | evan | thats safe to do. |
| 18:19:36 | matthewd | That could explain what I'm seeing :P |
| 18:19:44 | evan | matthewd: where are you looking? |
| 18:19:50 | matthewd | rb_num2dbl |
| 18:20:08 | evan | and what is the thing you're testing? |
| 18:20:28 | matthewd | I've been trying to get Johnson running |
| 18:20:52 | matthewd | This is the last failure :) |
| 18:20:55 | brixen | omg matthewd is playing with his Johnson in public! |
| 18:20:59 | brixen | tenderlove: ^^^ |
| 18:20:59 | evan | hahahah |
| 18:21:02 | evan | matthewd: PUT THAT AWAY |
| 18:21:07 | evan | there are children here! |
| 18:21:14 | brixen | that's why tenderlove named it that after all |
| 18:21:18 | evan | actually, no seydar isn't here right now. |
| 18:21:23 | matthewd | evan: Don't be silly! I'm playing with jbarnette's johnson! :P |
| 18:21:23 | evan | HE'S NOT EVEN HERE ZING |
| 18:21:24 | tenderlove | hahaha |
| 18:21:27 | brixen | hehe |
| 18:21:40 | evan | matthewd: what is being passed to num2dbl? |
| 18:21:46 | matthewd | A bignum |
| 18:21:46 | brixen | I always confuse which Johnson has who |
| 18:21:50 | evan | matthewd: oh ok |
| 18:21:55 | tenderlove | brixen: are you in the same place as matthewd? |
| 18:21:57 | evan | matthewd: you going to make num2dbl smarter? |
| 18:22:01 | matthewd | Sure |
| 18:22:05 | brixen | tenderlove: absolutely not! that's sick |
| 18:22:08 | tenderlove | hahaha |
| 18:22:17 | brixen | heh |
| 18:22:21 | tenderlove | evan: why are you not in NYC? |
| 18:22:22 | tenderlove | :-( |
| 18:22:22 | boyscout | CI: rubinius: cc9d10f successful: 3463 files, 13827 examples, 41481 expectations, 0 failures, 0 errors |
| 18:22:31 | matthewd | Should it just call #to_f ? |
| 18:22:58 | evan | matthewd: sure, thats fine. |
| 18:23:07 | Defiler | evan: You mean literally at the end of instructions.def, right? |
| 18:23:12 | Defiler | like, even after invoke_primitive |
| 18:23:13 | evan | Defiler: I did. |
| 18:23:13 | matthewd | Leaving the special case for Float, obviously |
| 18:23:15 | Defiler | k |
| 18:23:18 | evan | matthewd: sure. |
| 18:23:25 | evan | matthewd: thats the accepted way to handle that. |
| 18:25:01 | matthewd | Of course, this is another function where I've won the chance to write specs for it too :P |
| 18:25:07 | brixen | hehe |
| 18:25:20 | brixen | we try to keep those opportunities around |
| 18:25:27 | brixen | (not really, but hey) |
| 18:33:05 | Defiler | do I need to build clean after adding an instruction? |
| 18:33:13 | Defiler | it looooks like it does it right, but it blows up trying to inline a method |
| 18:33:13 | evan | nope |
| 18:33:26 | evan | Defiler: oh, you need to teach the JIT about the instruction |
| 18:33:33 | evan | you get to change the JIT! |
| 18:33:45 | Defiler | oh, hah, right |
| 18:33:46 | Defiler | cool |
| 18:34:03 | evan | so, the way to do this is to create a function in vm/llvm/jit_utils.cpp |
| 18:34:14 | evan | that returns G(rubinius) |
| 18:34:18 | Defiler | yeah |
| 18:34:20 | Defiler | already there :) |
| 18:34:24 | evan | k :) |
| 18:34:36 | evan | there are some examples of calling a function for other instructions in there for you to copy |
| 18:35:23 | Defiler | why does 'push_cpath_top' not appear in this file? |
| 18:35:35 | evan | thats not a real instruction |
| 18:35:37 | evan | check out generator |
| 18:35:41 | Defiler | oh, right |
| 18:35:46 | evan | it's a psuedo instruction |
| 18:36:23 | Defiler | so, this is an example case where the instruction and the inline function decl are really the same code |
| 18:36:42 | Defiler | (being just G(rubinius) ) |
| 18:36:47 | evan | yeah |
| 18:37:03 | evan | i don't yet have a way for the JIT to handle that cause automatically |
| 18:37:11 | evan | and just use the code from the interpreter version |
| 18:37:24 | evan | because in pretty much every case, we want to do something custom for the JIT |
| 18:37:29 | evan | to exploit it's features |
| 18:38:25 | brixen | did I miss something? how is push_cpath_top not a real insn? |
| 18:38:36 | Defiler | I also need to update jit_visit.hpp, right? |
| 18:38:57 | Defiler | brixen: rbx_push_system_object is called when you visit a cpath_top instruction |
| 18:39:10 | brixen | oh, ok, you mean in the jit |
| 18:39:12 | brixen | gotcha |
| 18:39:47 | evan | Defiler: ah yes! |
| 18:39:50 | evan | Defiler: you can just reuse that |
| 18:39:59 | Defiler | actually, I can JUST define it there, right? |
| 18:40:01 | evan | add a number for Rubinius |
| 18:40:06 | evan | in push_system_object |
| 18:40:10 | evan | and call that with the proper number |
| 18:40:15 | Defiler | oh, well |
| 18:40:24 | Defiler | is that better than G(rubinius)? since we have a named global for it |
| 18:40:33 | evan | either is fine. |
| 18:40:38 | evan | i'll leave the decision to you. |
| 18:40:52 | evan | in push_system_object, you can still just return G(rubinius) |
| 18:40:53 | brixen | Defiler: choose wisely :) |
| 18:41:05 | Defiler | k |
| 18:41:15 | evan | gets his Knight outfit out |
| 18:41:19 | brixen | heh |
| 18:42:37 | matthewd | Oh, so, I had to #ifdef out a use of node.h |
| 18:42:58 | evan | is it just included but never used? |
| 18:42:59 | matthewd | Specifically, it's used to work out whether a method is an attr_reader |
| 18:43:02 | evan | ie, no usage of NODE? |
| 18:43:26 | evan | we can add a stub for node.h |
| 18:43:36 | evan | with nothing in it |
| 18:43:42 | matthewd | Is there something on Rubinius's Method I could use for equivalent understanding? |
| 18:43:53 | evan | huh? |
| 18:43:56 | evan | equiv of what? |
| 18:43:58 | Defiler | man, so close |
| 18:43:59 | Defiler | Exception: `Rubinius::InvalidRBC' kernel/delta/codeloader.rb:122 - /Users/wilson/code/rubinius/spec/ruby/command_line/fixtures/debug.rbc |
| 18:44:04 | evan | Defiler: thats fine. |
| 18:44:06 | evan | thats not an error. |
| 18:44:10 | Defiler | ah |
| 18:44:11 | evan | brixen: we need to fix that. |
| 18:44:22 | brixen | ok |
| 18:44:32 | brixen | gets out his Fixit outfit |
| 18:44:33 | evan | do ya get why it's showing up? |
| 18:44:34 | matthewd | evan: Working out whether a given method is a simple accessor |
| 18:44:47 | evan | matthewd: can you show me the current code johnson uses? |
| 18:44:52 | evan | you can point me to a github url |
| 18:44:59 | matthewd | Yup, I'll find it |
| 18:45:18 | matthewd | It basically checks whether the method's body is a NODE_IVAR |
| 18:45:41 | evan | eww. |
| 18:45:58 | matthewd | subtly points in tenderlove's direction |
| 18:46:01 | matthewd | :) |
| 18:46:13 | tenderlove | O_O |
| 18:47:27 | matthewd | http://github.com/jbarnette/johnson/blob/unstable/ext/tracemonkey/js_land_proxy.cc#L167 |
| 18:48:05 | evan | matthewd: there is definitely no equiv of that. |
| 18:48:13 | matthewd | tenderlove: At least, I think that was yours :P |
| 18:48:16 | evan | nor do I think we'll add something |
| 18:48:21 | tenderlove | matthewd: I thought that was yours!!! |
| 18:48:25 | tenderlove | evan: no, you shouldn't |
| 18:48:27 | matthewd | Nope! |
| 18:48:29 | tenderlove | that is pure evil code |
| 18:48:57 | evan | tenderlove: can we comment out that code safely? |
| 18:49:04 | evan | for now. |
| 18:49:07 | tenderlove | in Johnson? |
| 18:49:13 | matthewd | Yeah, definitely |
| 18:49:13 | evan | yes, in matthewd's working copy |
| 18:49:16 | evan | so he can move on |
| 18:49:23 | tenderlove | ya, he should be able to |
| 18:49:26 | evan | ok |
| 18:49:32 | evan | matthewd: comment it out, move on. |
| 18:49:33 | matthewd | With that in an #ifdef, I have all tests passing |
| 18:49:38 | evan | YAY! |
| 18:49:41 | dwaite | if only there was some tool that could be used to exorcise evil code |
| 18:49:45 | evan | matthewd's Johnson passes inspection! |
| 18:49:50 | brixen | wait, how does tenderlove know so much about jbarnette's Johnson? |
| 18:50:03 | tenderlove | brixen: it's half my project ;-) |
| 18:50:06 | Defiler | inspection and collaboration |
| 18:50:07 | brixen | no wonder I was confused |
| 18:50:08 | brixen | :) |
| 18:50:25 | tenderlove | though, I'm glad it's on jbarnette's repo |
| 18:50:31 | tenderlove | so I don't have to work on it ;-) |
| 18:50:31 | brixen | heh |
| 18:50:39 | dwaite | wait, does everyone have their own Johnson in here? |
| 18:50:53 | brixen | mums the word |
| 18:50:57 | dwaite | is there an agreement on which one is considered authoritative? |
| 18:51:19 | brixen | I defer to those who play with their Johnson a lot |
| 18:51:41 | evan | man, we should take this routine on the road |
| 18:51:50 | dwaite | so you think the one which is authoritative is just the one considered most active? |
| 18:51:50 | brixen | recalls there is a public log of this channel |
| 18:52:12 | brixen | I blame tenderlove |
| 18:53:01 | brixen | ok, last one |
| 18:53:30 | brixen | matthewd: when do you plan to exhibit your Johnson on Rubinius? |
| 18:54:27 | dwaite | seems like the sort of thing that should be shown in front of a bunch of geeks, perhaps at a conference |
| 18:54:42 | matthewd | brixen: I shall push onto jbarnette's johnson shortly! |
| 18:54:49 | evan | then he could whip his dick out. |
| 18:54:51 | brixen | heh |
| 18:54:51 | evan | ... |
| 18:54:53 | evan | too far? |
| 18:54:59 | brixen | probably, yes |
| 18:55:20 | brixen | unless you meant yanking ryan from behind the curtain |
| 18:55:26 | brixen | :) |
| 18:55:38 | matthewd | dwaite: tenderlove and jbarnette gave a presentation at rubyconf, I think |
| 18:55:48 | dwaite | yeah I saw it :) |
| 18:56:17 | dwaite | well worth the price of admission |
| 18:57:11 | dwaite | although when they presented it I thought it was a bit.. funny |
| 18:58:06 | dwaite | I mean, I'm sure it gets the job done |
| 18:58:14 | dwaite | just didn't really have a desire to go play with it |
| 18:58:59 | dwaite | possibly I wasn't the intended audience? |
| 18:59:15 | evan | matthewd: do you have commit rights to jbarnette's johnson repo? |
| 18:59:16 | dwaite | is done |
| 19:00:17 | matthewd | evan: Yep |
| 19:00:23 | evan | rad. |
| 19:00:24 | Defiler | brixen: man, I still see three examples of 'push_const :Rubinius', seemingly produced by TestGenerator |
| 19:00:43 | Defiler | brixen: ..but I have replaced every example of that in testgen, and that pattern of text no longer appears in the working copy at all |
| 19:01:56 | Defiler | all three are in spec/compiler/transforms/assembly_spec |
| 19:02:49 | evan | whats that file... |
| 19:03:02 | evan | oh, inline assembly! |
| 19:03:13 | Defiler | https://gist.github.com/cb30f93e73af7b9f25bb |
| 19:03:29 | Defiler | oh, crap, never mind |
| 19:03:31 | evan | right |
| 19:03:34 | evan | you need to change the spec. |
| 19:03:38 | Defiler | I did |
| 19:03:42 | Defiler | and I think I need to change it back |
| 19:03:49 | Defiler | because that is a regular old Rubinius const reference |
| 19:03:54 | Defiler | not one that will use push_rubinius |
| 19:03:58 | evan | ah yes. |
| 19:04:15 | evan | thats not something internally asking for the Rubinius constant |
| 19:04:19 | evan | this is an explicit request |
| 19:04:23 | evan | which goes the push_const path. |
| 19:04:24 | Defiler | yeah |
| 19:04:36 | Defiler | confusing because test_generator DOES do a push_rubinius |
| 19:04:42 | Defiler | it just isn't that first one in the stream |
| 19:04:51 | evan | right. |
| 19:04:53 | matthewd | Okay, as it's 4:30 AM, I'm cheating... Johnson (unstable) on github now runs with Rubinius... after I fix rb_num2dbl, tomorrow. :) |
| 19:05:07 | brixen | matthewd: woot! |
| 19:05:19 | matthewd | (Which I've obviously fixed locally, but haven't done specs for yet) |
| 19:05:24 | evan | Defiler: we could detect that Rubinius is being accessed in the AST and emit push_rubinius |
| 19:05:44 | brixen | seems like a good idea |
| 19:05:46 | evan | probably best to only do that in kernel mode |
| 19:05:49 | Defiler | yeah |
| 19:08:13 | boyscout | Introduce `push_rubinius` instruction and use it like a rented mule - 3ec71eb - Wilson Bilkovich |
| 19:08:55 | evan | hah |
| 19:09:50 | evan | brixen: ok, i've fixed the crash |
| 19:10:03 | evan | this has enlightened me a little bit to some of our architecture |
| 19:10:17 | brixen | ok |
| 19:10:47 | Defiler | no more 'push_const :SomeSymbol" to be found in lib/compiler |
| 19:11:09 | evan | mainly, when a Thread gives up the GIL, it needs to make sure that it's saved_call_frame_ slot is set properly. |
| 19:11:21 | evan | that was the source of this bug |
| 19:11:25 | brixen | ahh |
| 19:11:37 | evan | before entering a native method, we updated scf_ |
| 19:11:49 | evan | but the native method called out to native methods via rb_funcall |
| 19:12:00 | evan | and those update scf_ to point to their frame |
| 19:12:03 | evan | well, when those things return |
| 19:12:11 | evan | scf_ now points to a CallFrame* that doesn't exist |
| 19:12:18 | brixen | gotcha |
| 19:12:44 | evan | so, I think I'm going to wrap up UnlockGuard with some extra logic |
| 19:12:58 | evan | to handle making sure that scf_ is set properly. |
| 19:13:07 | evan | this could be the source of crashes as well. |
| 19:13:23 | evan | because the GC reads the scf_ of every thread on every GC |
| 19:13:30 | evan | and if it's not updated properly.... |
| 19:13:36 | brixen | hm yeah |
| 19:15:36 | brixen | evan: working on rb_class_new, which needs something like Helpers::add_class, but without the name |
| 19:15:47 | evan | um |
| 19:15:50 | brixen | evan: should I add Helpers function or just synthesize that in rb_class_new |
| 19:15:58 | evan | shouldn't rb_class_new rb_funcall to Rubinius.open_class ? |
| 19:16:05 | evan | why duplicate stuff? |
| 19:16:14 | brixen | well, let me look |
| 19:16:55 | brixen | it has no name |
| 19:17:09 | evan | what has no name? |
| 19:17:11 | evan | i don't follow. |
| 19:17:35 | brixen | no, this won't work |
| 19:17:46 | brixen | open_class calls open_class_under |
| 19:18:00 | evan | so? |
| 19:18:02 | brixen | rb_class_new(super) |
| 19:18:14 | evan | it creates a new anonymous class? |
| 19:18:20 | evan | rb_funcall to Class.new then. |
| 19:18:25 | brixen | can't |
| 19:18:29 | brixen | that calls inherited |
| 19:18:37 | brixen | I already tried the easy ways |
| 19:18:46 | evan | rb_class_new doesn't call inherited? |
| 19:18:49 | brixen | no |
| 19:18:54 | brixen | it basically is... |
| 19:18:56 | brixen | rb_class_boot |
| 19:18:59 | evan | no it doesn't call or no it does call? |
| 19:19:08 | brixen | no, it does not call |
| 19:19:12 | boyscout | CI: rubinius: 3ec71eb successful: 3463 files, 13827 examples, 41481 expectations, 0 failures, 0 errors |
| 19:19:17 | evan | oh MRI... |
| 19:19:29 | brixen | http://gist.github.com/410291 |
| 19:19:39 | evan | ok, so how do you wanna handle it? |
| 19:19:47 | brixen | rjb uses rb_class_new and calls rb_class_inherited directly |
| 19:19:57 | evan | *eyeroll* |
| 19:20:22 | brixen | so, Helpers::add_class is close |
| 19:20:34 | evan | well |
| 19:20:38 | brixen | I could add Helpers::new_class or something, or just do it raw in rb_class_new |
| 19:20:42 | evan | why not create a class like we do in ontology.cpp? |
| 19:20:53 | evan | there are some methods on VM to do it |
| 19:20:54 | brixen | that's what I need to do |
| 19:21:08 | brixen | do it directly, or add Helpers::something ? |
| 19:21:12 | evan | i'd ignore Helpers (i want to get rid of it) |
| 19:21:15 | evan | do it directly. |
| 19:21:18 | brixen | ah ok |
| 19:21:22 | brixen | why get rid of Helpers? |
| 19:21:34 | evan | it's a mismash of random stuff |
| 19:21:40 | brixen | right... |
| 19:21:50 | evan | that need to be refactored out into static methods under the specific classes that concern the functionality |
| 19:21:51 | brixen | we added it to simplify some stuff |
| 19:21:52 | evan | at least. |
| 19:21:57 | brixen | ok |
| 19:22:03 | brixen | so, same idea, better organized? |
| 19:22:04 | evan | like Class::create_stati() |
| 19:22:07 | evan | yeah. |
| 19:22:11 | brixen | ok, got it |
| 19:22:11 | evan | same idea, better organized. |
| 19:43:01 | brixen | dammit, missed alex payne speaking at code camp here today |
| 19:43:18 | brixen | knew I was forgetting something |
| 19:44:59 | evan | oops. |
| 19:45:07 | evan | ok, i've got UnlockGuard cleaned up now. |
| 19:46:50 | brixen | sweet |
| 19:50:24 | evan | zoinks. |
| 19:50:40 | evan | at some point, I appear to have made it so FFI functions run with the GIL unlocked. |
| 19:50:44 | evan | huh. |
| 19:50:50 | evan | thats funny. |
| 19:52:04 | dbussink | evan: some point being very recently? |
| 19:52:08 | brixen | I thought I remember you doing that specifically |
| 19:52:12 | brixen | yeah, recently |
| 19:52:13 | evan | very unlikely recently |
| 19:52:37 | dbussink | because socket stuff using ffi was blocking, or was that different? |
| 19:53:01 | brixen | yeah, that rings a bell |
| 19:53:05 | evan | 2009-02-09 |
| 19:53:16 | brixen | hah, seriously? |
| 19:53:17 | brixen | no way |
| 19:53:19 | evan | yep. |
| 19:53:25 | evan | bb9618cf is the commit. |
| 19:53:47 | evan | well, thats pretty awesome. |
| 19:54:04 | brixen | that's amazisg |
| 19:55:37 | evan | I guess that explains why socket.rb works as well as it does |
| 19:55:49 | brixen | this was the socket stuff I was thinking of 099175bc |
| 19:57:04 | evan | yeah, i did that because I thought that FFI was blocking hard. |
| 19:57:21 | evan | I was wrong. |
| 19:57:21 | brixen | ok |
| 19:57:34 | evan | the reason was likely because i've coded those IO methods to be interruptable |
| 19:57:42 | evan | where as FFI called blocking functions aren't interruptable. |
| 19:58:08 | evan | you can't use Thread#kill to cause accept(2) to return if accept(2) is called via FFI |
| 19:58:52 | evan | ok, lunch! |
| 19:59:12 | brixen | me too! |
| 20:36:16 | slava | evan: http://mitkokostov.info/2010/05/22/ruby-vm-shootout.html |
| 20:36:24 | slava | looks like rbx is doing well on numeric code and such |
| 20:37:52 | Defiler | nice |
| 20:45:52 | brixen | interestingly, I believe bm_hilbert_matrix is Array heavy |
| 20:46:03 | brixen | so, if we are basically 2x 1.9.2, that is awesome |
| 20:46:22 | brixen | and we're pretty much 2x scaling with input size |
| 20:46:54 | brixen | we will eventually run C code faster than MRI :) |
| 20:47:06 | brixen | er, let me rephrase |
| 20:47:20 | brixen | we will eventually run Ruby code faster than MRI does C code |
| 20:50:25 | Defiler | clearly possible, yeah |
| 20:50:35 | cyndis | link with clang and compile/inline ruby exts on the fly and perhaps we will run C code faster than mri ;) |
| 20:54:41 | brixen | cyndis: that is totally doable |
| 20:54:57 | brixen | cyndis: evan already has ideas for loading C ext on the fly where no C compiler is available |
| 20:55:06 | cyndis | oh :) |
| 20:55:20 | brixen | but what this also does is make it so we could get more info in LLVM IR |
| 20:55:28 | brixen | and let LLVM go crazy with more |
| 20:55:45 | cyndis | yes |
| 20:55:47 | brixen | and llvm 2.7 adds the metadata to the IR |
| 20:55:56 | Defiler | vm can load its own code with llvm and emit java bytecode :) |
| 20:55:58 | brixen | so, we basically have a whole new horizon |
| 20:56:17 | brixen | essentially, it's a wonderful time to be using llvm |
| 20:56:54 | brixen | Defiler: http://github.com/brixen/kireru :) |
| 20:58:58 | cyndis | at one point i made a hobby x86 os which just booted into a statically compiled mri; would be cool (and probably quite difficult) to make an os with embedded rbx and code the drivers in ruby |
| 20:58:59 | dwaite | you have a name and a readme |
| 20:59:03 | dwaite | the hard parts are already done |
| 20:59:38 | Defiler | nice |
| 20:59:43 | dwaite | it would be difficult to program OS drivers without a concept of int or bytes |
| 20:59:54 | cyndis | ffi :p |
| 20:59:58 | dwaite | plus you would be unable to use floating point |
| 21:00:36 | brixen | dwaite: we have a world of primitives available |
| 21:00:37 | slava | brixen: how do you guys do out parameters in ffi? |
| 21:00:38 | dwaite | (learned that one the hard way) |
| 21:01:23 | brixen | slava: sorry? |
| 21:01:38 | slava | brixen: int x; foo(&x); blah(x); |
| 21:02:03 | brixen | we have a MemoryPointer type |
| 21:02:34 | slava | its a chunk of memory? |
| 21:02:56 | Defiler | brixen: very interesting point re: funnel |
| 21:03:15 | brixen | Defiler: yeah, I like that analogy |
| 21:03:20 | brixen | thought of it all by myself :) |
| 21:03:30 | brixen | slava: yes, basically |
| 21:03:48 | Defiler | maybe you should call it routo |
| 21:04:33 | brixen | slava: we have a couple different things |
| 21:05:00 | brixen | slava: eg, we can describe a Struct layout, and pass an adress of an instance of that to the C function |
| 21:05:10 | brixen | Defiler: routo? |
| 21:05:14 | Defiler | funnel |
| 21:05:19 | brixen | ahh hehe |
| 21:05:38 | Defiler | æ¼æ |
| 21:05:47 | Defiler | crap, forgot to fix my term settings on new laptop |
| 21:05:51 | brixen | heh |
| 21:06:02 | brixen | I was like wait what? I have utf-8 set |
| 21:06:16 | slava | brixen: so for the case of returning an int, you allocate a struct with a single int field in it? |
| 21:06:20 | Defiler | huh.. actually.. my settings look right |
| 21:06:27 | Defiler | I wonder if I didn't launch screen with -U or something dumb |
| 21:06:43 | Defiler | http://dict.regex.info/cgi-bin/j-e/sjis/FG=r/dokanji?index=t&ivalue=4f33|454d& |
| 21:07:00 | Defiler | (though in the actual word they appear in reverse order from that page) |
| 21:07:12 | Defiler | 'leaky dipper' heh |
| 21:08:43 | brixen | slava: http://github.com/evanphx/rubinius/blob/master/kernel/platform/memorypointer.rb |
| 21:09:39 | brixen | slava: if you grep for :pointer in kernel/platform, you can see various uses of it with libc functions |
| 21:09:49 | slava | brixen: looks reasonable |
| 21:09:53 | brixen | slava: I'm pretty rusty on ffi atm, but hope to refresh soon |
| 21:10:01 | slava | is it always backed by malloced memory? |
| 21:10:02 | brixen | we have to fix up our API to match the heathens |
| 21:10:29 | brixen | yeah, we use FFI::Platform::POSIX.malloc atm |
| 21:10:50 | slava | is autorelease mode like a ghetto finalizer? |
| 21:11:13 | brixen | hm, kinda |
| 21:11:26 | evan | slava: it is a bit, yes. |
| 21:11:30 | evan | it uses finalizers actually. |
| 21:11:33 | brixen | not exactly ghetto |
| 21:11:39 | brixen | yeah |
| 21:11:45 | evan | a builtin finalizer, which is a little more reliable than a ruby finalizer. |
| 21:11:54 | slava | werd |
| 21:13:13 | evan | slava: you saw how to use an out param? |
| 21:13:19 | slava | yeah |
| 21:13:26 | slava | MemoryPointer.new {|p| ... } |
| 21:13:30 | evan | yep |
| 21:13:37 | slava | and read and write the value in the block |
| 21:13:41 | evan | i want to revise the FFI API to add "stack" allocations |
| 21:13:59 | slava | aha |
| 21:14:05 | evan | so that MemoryPointer.new { } can get some thread local memory without using malloc |
| 21:14:09 | slava | I just implemented that, and I'm making a new out parameter mechanism |
| 21:14:10 | evan | and can be released back when the block ends |
| 21:14:43 | evan | I could end up wiring it up in terms of alloca() eventually perhaps |
| 21:14:54 | slava | the thing I made is like your memory pointer with a block form, but stack allocated, so I guess I"m on the right track :) |
| 21:15:33 | Defiler | Somehow I'm not surprised your take on it used the stack :) |
| 21:15:50 | brixen | slava: you're always on the right track, just the wrong side of it :) |
| 21:16:17 | brixen | ok, not really wrong... just, other :) |
| 21:16:19 | slava | oh you guys |
| 21:16:22 | brixen | heh |
| 21:17:02 | evan | slava: hehe |
| 21:18:03 | slava | I want to make 'out' parameters part of the actual FFI binding syntax though |
| 21:18:06 | slava | have you thought of that? |
| 21:18:16 | slava | so you don't need to make the pointer by hand, and dereference it at the end |
| 21:18:39 | slava | it might be more convenient |
| 21:19:11 | evan | that would be nice. |
| 21:19:38 | slava | I like it how you have a 'clear' flag in the MemoryPointer constructor |
| 21:19:54 | slava | its handy not to clear the input if you're going to overwrite it anyway |
| 21:20:07 | evan | yeah, that follows sort of a C best practices vibe |
| 21:20:13 | evan | ie, use calloc, not malloc |
| 21:20:14 | evan | etc. |
| 21:52:18 | boyscout | Revise GIL unlocking to keep Thread::saved_call_frame_ sane - da9d56a - Evan Phoenix |
| 21:52:19 | boyscout | Quit gracefully when the target has already quit - c50eb7a - Evan Phoenix |
| 21:52:19 | boyscout | Discard any output to STDERR to silence any actual debug output - 3753994 - Evan Phoenix |
| 21:52:57 | evan | brixen: I fixed that spec |
| 21:53:07 | evan | that seemed like a decent way to do it |
| 21:53:16 | evan | please advise if there is a better way. |
| 21:53:23 | brixen | ok, le'me take a look |
| 21:57:15 | jarib | hmm, rbx seems to automatically print the result of code piped to it |
| 21:57:16 | Defiler | anyone run the rbx test suite on mac os with the firewall turned on? |
| 21:57:17 | jarib | is that intentional? |
| 21:57:29 | jarib | $ echo true | rbx |
| 21:57:29 | Defiler | Trying to come up with a way to stop getting prompted to allow connections for vm/vm after every build |
| 21:57:30 | jarib | true |
| 21:57:37 | Defiler | because the sha1 changes, the firewall de-allows it |
| 21:58:10 | evan | jarib: yes, thats true. |
| 21:58:15 | evan | thats a very old "feature" |
| 21:58:27 | jarib | ok, just curious :) |
| 22:04:15 | boyscout | CI: rubinius: 3753994 successful: 3463 files, 13827 examples, 41481 expectations, 0 failures, 0 errors |
| 22:09:54 | Defiler | This is interesting http://github.com/danielwellman/bane |
| 22:10:05 | Defiler | maybe some fun tools in there to fuzz the rbx socket implementation |
| 23:16:27 | brixen | evan: could your run: bin/mspec spec/capi/module_spec.rb -tr |
| 23:16:35 | brixen | s/your/you/ |
| 23:16:47 | evan | 4 errors. |
| 23:17:03 | evan | all for |
| 23:17:04 | evan | uninitialized constant SubtendModuleTest::(null) |
| 23:17:18 | brixen | yes, so one issue is those need SYM2ID |
| 23:17:21 | brixen | I got that port |
| 23:17:24 | brixen | er part |
| 23:17:43 | brixen | but you added rb_const_get_from and the specs says it should find Fixnum looking up |
| 23:17:49 | brixen | I don't see it doing that |
| 23:17:55 | brixen | so I'm curious about it |
| 23:18:09 | brixen | I suppose I could build rmagick and see if it runs after I change that |
| 23:18:52 | brixen | I just wondered if I'm missing something |
| 23:19:40 | evan | that rb_const_get_from was from kronos_vano |
| 23:19:48 | brixen | ahh ok |
| 23:20:07 | evan | also, when running the capi tests |
| 23:20:11 | brixen | I'll talk to him about running the specs in mri |
| 23:20:18 | evan | are you making sure to recompile the extensions if -t changes? |
| 23:20:24 | brixen | yes |
| 23:20:26 | evan | k |
| 23:20:36 | brixen | I cache what impl compiled the specs |
| 23:20:49 | brixen | so, if you run it with a different impl, it forces a recompile |
| 23:21:06 | evan | good. |
| 23:21:11 | evan | just wanted to be sure. |
| 23:21:13 | brixen | yep |
| 23:27:43 | evan | hm, only had to change 3 things to get LLVM 2.7 to compile |
| 23:27:45 | evan | lets see if it runs. |
| 23:29:10 | evan | hah |
| 23:29:15 | evan | i crashed CrashReporter |
| 23:29:19 | evan | Error Formulating Crash Report: |
| 23:29:19 | evan | *** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value (key: Identifier) |
| 23:33:34 | brixen | hah, ouch |
| 23:35:40 | brixen | man, sometimes these spec.... |
| 23:36:00 | brixen | a.should == 1; (a != 2).should == true |
| 23:36:05 | brixen | seriously? c'mon |
| 23:36:08 | evan | hahahah |
| 23:36:19 | evan | almost like someone is trying to fuck with you |
| 23:36:25 | brixen | yeah :/ |
| 23:36:38 | brixen | but not, and that's all the more sad |
| 23:52:34 | brixen | takes a long time to do the specs right... |