Da
Show enters and exits. Hide enters and exits.
| 00:00:09 | brixen | nice |
| 00:00:32 | evan | i don't know if I should go "yay fast blocks" or "boo slow allocation" |
| 00:00:52 | goyox86 | last time i've followed ingalls he was working for SUN at research, on something called the lively kernel |
| 00:01:08 | brixen | hmm, well yay fast blocks since the jit is kicking ass basically |
| 00:01:28 | evan | goyox86_: he probably got the ax from oracle. |
| 00:01:34 | evan | a lot of fellows did. |
| 00:01:49 | goyox86 | evan: agree |
| 00:01:54 | brixen | if oracle axed them, they are stupid as hell |
| 00:02:07 | brixen | if they quit, woot for them |
| 00:02:58 | brixen | judging from the little tim wrote, I'm guessing oracle is stupid as hell |
| 00:03:05 | goyox86 | evan: probably oracle guys,didn't read "Design Principles Behind Smalltalk" lol |
| 00:03:16 | evan | hell |
| 00:03:21 | evan | you just have to listen to dan's stories |
| 00:03:26 | evan | he's worth every penny just for the fucking stories. |
| 00:03:31 | brixen | hehe |
| 00:05:54 | postmodern | oracle fired someone? |
| 00:05:59 | goyox86 | that lively kernel project, was really nice, dan bringing a lot of his VM knowledge, to web browsers, as he stated "Web programming was more complex that it should be" |
| 00:06:33 | goyox86 | than it should be* |
| 00:07:10 | goyox86 | the guy implemented that stuff if JS |
| 00:09:48 | brixen | goyox86_: are you following the vpri work? |
| 00:10:08 | evan | woop! |
| 00:10:13 | slava | evan: I got GC maps working |
| 00:10:23 | goyox86 | brixen: nope what is this about? |
| 00:10:41 | brixen | goyox86_: vpri.org |
| 00:10:42 | evan | brixen: http://gist.github.com/450772 |
| 00:10:46 | evan | slava: oh rad. |
| 00:11:15 | slava | evan: each code block now has a list of return addresses and a bitmap associating each return address with a set of spill slots in the stack frame that are GC roots |
| 00:11:38 | evan | ah rad. |
| 00:11:40 | slava | before I couldn't spill tagged values across subroutine calls and had to shuffle them onto the operand stack instead |
| 00:11:55 | slava | this is going to make a lot of things much cleaner and more efficient |
| 00:12:06 | evan | brixen: each_key_block == 1.43s with block inlining |
| 00:12:11 | evan | each_key_to_iter == 3.2s |
| 00:12:16 | slava | the operand stack will only be used for parameter passing, and not temporary value storage |
| 00:12:18 | evan | each_key_direct == 1.40s |
| 00:12:28 | goyox86 | brixen: kay and his folks nice! |
| 00:12:41 | evan | slava: very cool. |
| 00:13:00 | evan | slava: so, all GC pointers are always spilled |
| 00:13:09 | evan | and the GC uses the map to fix up the stack positions |
| 00:13:21 | slava | everything is spilled at a call site |
| 00:13:24 | evan | and post GC point, they're unspilled |
| 00:13:28 | slava | I don't have non-volatile registers |
| 00:13:29 | slava | right |
| 00:13:32 | evan | gotcha |
| 00:13:33 | evan | sweet. |
| 00:13:34 | slava | so in the IR, its one SSA value |
| 00:13:48 | evan | aaah |
| 00:13:59 | evan | you're doing it all at the lowest layer |
| 00:13:59 | evan | nice! |
| 00:14:04 | slava | yeah, in the register allocator |
| 00:15:03 | evan | slava: say you have a GC ref in SSA variable $a |
| 00:15:04 | evan | and you do |
| 00:15:32 | evan | $b = position_of_class($a) |
| 00:15:39 | evan | call(...) |
| 00:15:43 | evan | $c = load($b) |
| 00:16:11 | evan | or does your SSA not have variables that would reflect on the memory of another variable |
| 00:16:13 | evan | LLVM does that |
| 00:16:34 | slava | ok, so the way things work right now, I don't create pointers into the middle of objects like that |
| 00:16:45 | evan | gotcha |
| 00:16:46 | slava | but eventually, this will be supported |
| 00:16:54 | evan | thats a fundemental way LLVM works |
| 00:17:00 | evan | which is why i'm worried about this kind of stack mapping |
| 00:17:16 | slava | usually, you only support a small subset of all possible pointer arithmetic expressions |
| 00:17:35 | evan | LLVM only really supports one |
| 00:17:41 | slava | for example, if $a and $b are GC pointers, and you do |
| 00:17:43 | slava | $c = $a - $b |
| 00:17:45 | slava | call(...) |
| 00:17:46 | slava | blah($c) |
| 00:17:50 | slava | then you just suck. |
| 00:17:59 | evan | which is the ability to ask for a pointer to a struct member |
| 00:18:01 | slava | there's no meaningful way to fix up $c |
| 00:18:04 | evan | that you can then load |
| 00:18:14 | slava | but this is easy to handle: |
| 00:18:19 | slava | $c = $a + 0x123 |
| 00:18:20 | slava | call(...) |
| 00:18:22 | slava | blah($c) |
| 00:18:48 | slava | what you do is record that $c's base pointer is $a |
| 00:18:58 | slava | then the GC computes $c - $a before GC |
| 00:19:06 | slava | and sets $c to $a plus the saved difference after GC |
| 00:19:56 | slava | so in addition to a set of spill slots which are GC roots, you also have a hashtable mapping spill slots to base pointers, and treat those by saving the differences and adding them on again after |
| 00:21:02 | slava | evan: the hard case is if you have |
| 00:21:05 | slava | $a = $x + 123 |
| 00:21:06 | slava | ... |
| 00:21:09 | slava | $b = $x + 321 |
| 00:21:10 | slava | ... |
| 00:21:13 | slava | $c = phi($a,$b) |
| 00:21:20 | slava | call(...) |
| 00:21:21 | evan | yeah |
| 00:21:51 | slava | I don't understand the trick for this to be honest, but I know hotspot server does it properly |
| 00:22:06 | slava | the paper I'm reading that describes GC maps is about Modula 3 and their compiler was not SSA. |
| 00:22:54 | evan | we should get to the bottom of that. |
| 00:23:00 | evan | i'd like to know. |
| 00:23:09 | slava | are you thinking of going with a similar approach? |
| 00:23:11 | evan | because eventually i want to work on this in the LLV codebase. |
| 00:23:16 | evan | i'd like to |
| 00:24:15 | evan | because it properly express something I can't express now |
| 00:24:55 | evan | namely: This thing might have moved, but all other knowledge you had about it is still valid |
| 00:25:27 | slava | yeah, since in our VMs, 'knowledge' does not include 'the 5th bit of the pointer value is 1' |
| 00:27:24 | evan | yep. |
| 00:27:35 | evan | stuff like "the class was a String" |
| 00:27:39 | evan | "it's got 15 fields" |
| 00:27:40 | evan | etc. |
| 00:27:52 | evan | the class was String, rather. |
| 00:28:22 | slava | so far I'm only using GC maps at FFI call sites |
| 00:28:32 | brixen | slava: hmm, that seems like: x + y == f(x) + f(y) where f is the delta applied to addr(x) and addr(y) |
| 00:29:06 | brixen | ok, that's not exactly right |
| 00:29:22 | brixen | I can see this in functions though, hrm |
| 00:30:21 | evan | brixen: see my gist? |
| 00:30:26 | brixen | f (GC) is a structure preserving transform |
| 00:30:31 | brixen | evan: yeah |
| 00:30:32 | evan | using each_entry{} is faster than #to_iter |
| 00:30:36 | brixen | yep |
| 00:30:44 | brixen | because to_iter has an allocation cost |
| 00:30:44 | evan | yaypants! |
| 00:31:03 | brixen | there's no way to beat a pure inlined loop :) |
| 00:31:12 | evan | well, interestingly enough |
| 00:31:15 | evan | so does each_entry {} |
| 00:31:25 | evan | because it's got the block allocation without block inlining |
| 00:31:34 | evan | and without block inlining, it's still faster. |
| 00:31:39 | evan | which is weird. |
| 00:31:48 | brixen | I don't see each_entry doing a n allocation |
| 00:31:57 | evan | n? |
| 00:32:02 | evan | when you call it |
| 00:32:06 | evan | you pass a block |
| 00:32:11 | evan | passing a block in an allocation |
| 00:32:24 | evan | it's lowlevel, but it's an allocation. |
| 00:32:36 | brixen | ahh, and this is faster even without inlining? |
| 00:32:39 | brixen | interesting! |
| 00:33:31 | brixen | I'd like to know why that is |
| 00:33:48 | evan | as would I |
| 00:33:51 | evan | i'm going to poke a bit. |
| 00:33:55 | brixen | ok |
| 00:34:19 | evan | side note: |
| 00:34:39 | evan | in the back of my mind, i'm still wondering about the ability to have "constant" blocks |
| 00:34:44 | evan | like in each_key_block |
| 00:34:51 | brixen | yeah |
| 00:34:51 | evan | the block doesn't capture any locals. |
| 00:35:21 | brixen | seems like we should be able to analyze that |
| 00:36:33 | brixen | like a block has an attribute about the outermost scope it actually closes over |
| 00:37:41 | evan | brixen: elsewhere i'm discussing http://coderoom.wordpress.com/2010/06/23/criminal-overengineering/ |
| 00:37:58 | evan | and i came up with a good way to sum things up, code complexity wise. |
| 00:38:04 | evan | simple is harder than complex |
| 00:38:11 | evan | anyone can bang on keyboard and output 1000 pages |
| 00:38:20 | evan | it takes skill to sum up the human condition in a 20 word poem. |
| 00:39:27 | brixen | indeed |
| 00:39:39 | evan | in science, I believe they say that if you can't explain something simply to a lay person, you don't understand it well enough. |
| 00:39:56 | brixen | to quote Einstein, yes :) |
| 00:40:02 | evan | :) |
| 00:40:08 | brixen | also interesting in that post is the reference to fear |
| 00:40:18 | brixen | people are inordinately motivated by fear |
| 00:40:38 | brixen | or, motivated disproportionately by fear |
| 00:40:38 | evan | i think that partly comes from managers not know how to judge the output of a programmer |
| 00:40:49 | evan | everyone has heard of being paid per line of code |
| 00:40:51 | evan | even if they're not. |
| 00:40:58 | brixen | ie, they do not have the ability to distinguish how much their fear should motivate them |
| 00:41:27 | brixen | yeah, but also the "oh god, what if Bob thinks this code sucks" |
| 00:41:34 | brixen | insert your own Bob |
| 00:41:56 | evan | yep. |
| 00:42:22 | evan | thats why i'm motivated to show praise on obvious solutions |
| 00:42:27 | evan | s/show/shower/ |
| 00:42:32 | evan | obvious solutions are awesome |
| 00:42:33 | brixen | yeah |
| 00:42:44 | evan | they're obvious because they're simple. |
| 00:42:54 | brixen | I also think that moving the fear burden to tests helps |
| 00:43:01 | evan | totally. |
| 00:43:11 | brixen | you can code simple because the tests help you control your irrational fears |
| 00:43:13 | evan | it helps quell the "but what if!" |
| 00:43:22 | brixen | tests incomplete? no problem, write a new case |
| 00:43:35 | evan | in fact, the same is true of managed languages |
| 00:43:52 | evan | missed cases doesn't mean crashing and coming in on a sunday |
| 00:44:45 | evan | because that is stress |
| 00:44:51 | brixen | yeah |
| 00:45:03 | evan | and humans feel stress as fear and fear as stress. |
| 00:45:58 | evan | we are but mearly clinging to sanity in a sea of emotions anyway |
| 00:46:12 | brixen | I think the most productive question is often "what's the worst that can happen?" |
| 00:46:38 | brixen | one has to realistically evaluate that |
| 00:46:43 | brixen | repeatedly |
| 00:46:49 | evan | and be honest with the answer |
| 00:46:54 | brixen | yeah |
| 00:47:42 | evan | brixen: so, i'm looking at the difference between each_entry and to_iter |
| 00:47:45 | evan | with -Xprofile, so no JIT |
| 00:47:55 | evan | i'll show ya the profile output |
| 00:47:58 | evan | i have a hunch. |
| 00:48:04 | brixen | ok |
| 00:48:46 | evan | http://gist.github.com/450809 |
| 00:48:53 | evan | check the file names for which is which |
| 00:48:58 | evan | though you can see by the methods called |
| 00:49:11 | evan | 3s difference in runtime when profiling |
| 00:49:24 | evan | which can easily be accounted to the calles to #allocate and #next |
| 00:50:32 | evan | but when running without profiling |
| 00:50:47 | evan | each_entry == 1.8s, to_iter == 3.9s |
| 00:51:08 | evan | so my hunch is that the shape of each_entry is much easier to JIT |
| 00:51:35 | evan | it's a self call, and keeps the index and entries in locals |
| 00:51:37 | brixen | hmm, there are 1M more calls in the #to_iter case |
| 00:51:52 | evan | yes |
| 00:51:55 | brixen | yeah, that makes sense |
| 00:52:00 | evan | because you have #next as the condition as well |
| 00:52:06 | brixen | locals are screaming fast |
| 00:52:09 | evan | so there is a final call to find out there are no more |
| 00:52:11 | brixen | when I benched them |
| 00:52:25 | brixen | yeah, that extra call is a lot |
| 00:53:09 | brixen | it will be an interesting project to make these equivalent in the jit |
| 00:53:46 | slava | that's basically how I developed my compiler, figuring out how to make various high level idioms compile faster |
| 00:53:53 | brixen | slava: do you know what I mean by a structure preserving transform (in graphics terms) |
| 00:54:05 | slava | more generally that's called an isomorphism |
| 00:54:13 | brixen | slava: seems like the jit should see GC as a f() of this form |
| 00:54:20 | brixen | yes, an isomorphism |
| 00:56:06 | brixen | slava: basically, f() is pure |
| 00:56:24 | slava | I think there's a way to tell LLVM that a function call won't mutate any memory cells |
| 00:56:32 | slava | and alias analysis will have more precise information around this call as a result |
| 00:56:45 | evan | there is |
| 00:56:47 | evan | and i've done that |
| 00:56:53 | evan | also you can write your own AA pass |
| 00:57:01 | slava | does it help if you mark the actual GC call in this manner? |
| 00:57:01 | evan | to provide that info using whatever knowledge you want. |
| 00:57:14 | evan | it crashes the program. |
| 00:57:19 | brixen | :( |
| 00:57:21 | slava | I'll take that as a "no" :) |
| 00:57:31 | evan | because LLVM doesn't reload things it must |
| 00:57:41 | evan | because you've told it "nothing you can see right now will change" |
| 00:57:44 | evan | even though it does change. |
| 00:57:57 | brixen | yes, addr(x) != f(addr(x)) |
| 00:58:07 | brixen | but every thing else is the same |
| 00:58:12 | brixen | -\s |
| 00:58:13 | evan | right |
| 00:58:18 | evan | so my plan is to build things on top of that |
| 00:58:20 | slava | right, the addresess might change, you just can't observe the difference without breaking abstractions |
| 00:58:21 | evan | in 2.7 |
| 00:58:25 | evan | using metadata and our own AA |
| 00:58:35 | brixen | ahh cool |
| 00:58:44 | evan | which is, imho, hte right way to go away |
| 00:58:51 | evan | because that gives us all the flexibility we want. |
| 00:59:12 | evan | LLVM becomes our lowlevel IR (OH WAIT, ISN'T THAT THE NAME?) |
| 00:59:15 | evan | :D |
| 00:59:18 | brixen | hehe |
| 00:59:30 | slava | my high level IR can 'see' values across calls |
| 00:59:31 | brixen | those jokesters |
| 00:59:35 | slava | but in LLIR the operand stack ops become explicit |
| 00:59:45 | slava | so a constant defined before a call is not known to be a constant after the call in the later stages |
| 00:59:47 | evan | brixen: i know! it's almost like Chris got the ACM award for a reason! |
| 00:59:53 | brixen | heh |
| 01:00:02 | slava | by moving the GC stuff to register allocation, more passes will 'see' across calls |
| 01:00:04 | evan | slava: exactly, i've thought about having a high level IR for a while now |
| 01:00:09 | evan | that can do exactly this. |
| 01:00:30 | evan | see things and not worry about address |
| 01:00:50 | evan | the high level concept of a reference |
| 01:00:59 | evan | rather than the lowlevel concept of a pointer. |
| 01:01:33 | brixen | seems like metadata gives you that |
| 01:01:47 | evan | it does |
| 01:01:49 | slava | the two IRs are a bit of a historical accident though |
| 01:01:58 | slava | LLIR represents control flow with a graph of basic blocks |
| 01:01:58 | evan | the metadata is basically another layer of info |
| 01:02:07 | slava | HLIR is more like an AST, it has an #if node with two children |
| 01:02:15 | evan | that we can propagate based on high level reference concepts |
| 01:02:25 | evan | slava: aah. |
| 01:02:32 | evan | your HLIR is like our bytecode. |
| 01:02:40 | slava | yes |
| 01:03:07 | slava | and optimization passes that operate on it primarily do inlining or replacing subroutine calls to known words with cheaper operations |
| 01:03:16 | evan | cheating! |
| 01:03:21 | evan | :D |
| 01:03:31 | slava | ideally everything would operate on one IR |
| 01:03:39 | slava | but it would mean rewriting a ton of code |
| 01:03:57 | brixen | slava: when are you writing the book on dynlang vms? :) |
| 01:04:06 | slava | and there wouldn't be a practical benefit, it would just make the code more elegant |
| 01:05:16 | evan | slava: I suspect you'll do it eventually. |
| 01:05:18 | evan | :) |
| 01:05:30 | slava | yeah :) |
| 01:11:59 | evan | arg. |
| 01:12:03 | evan | JIT bug |
| 01:12:06 | evan | it JIT'd a script body |
| 01:12:09 | evan | oops. |
| 01:12:17 | brixen | ock |
| 01:12:22 | evan | </waste of time> |
| 01:19:15 | evan | rad, the mexicali quake over easter moved the crust by 31 inches |
| 01:19:58 | evan | 10 feet in some places! |
| 01:22:29 | brixen | seems like a lot, but I wonder what that is by % of size of the plate |
| 01:23:03 | brixen | probably less than me moving this 4ft table < 1mm |
| 01:23:12 | brixen | oops mixing units there :) |
| 01:26:40 | evan | hehe |
| 01:27:07 | jakedouglas | hi rubinius |
| 01:27:30 | brixen | hey jakedouglas |
| 01:27:37 | jakedouglas | been a while :p |
| 01:27:42 | brixen | heh |
| 01:27:48 | brixen | do you bring us good tidings? |
| 01:28:27 | jakedouglas | just congrats on 1.0 and beyond :) |
| 01:28:42 | brixen | sweet, thanks! :) |
| 01:29:18 | jakedouglas | my conscience is still haunted occasionally by a spec i said i would write but never did |
| 01:29:23 | jakedouglas | i might actually do it one of these days |
| 01:29:30 | brixen | hah |
| 01:29:57 | brixen | you should, lest your troubled soul haunts you indefinitely |
| 01:29:58 | brixen | :) |
| 01:30:01 | jakedouglas | i remember fixing the bug but the spec looked like a real bitch so i told myself i would do it later.. |
| 01:30:26 | jakedouglas | yea, i know :) |
| 01:32:26 | brixen | I'm going to grab dinner, lest my stomach growls at me indefinitely :) |
| 01:33:25 | jakedouglas | heh |
| 02:08:52 | bakkdoor | hello |
| 05:32:48 | dbussink | evan: i went to bed yeah |
| 05:32:57 | evan | :D |
| 05:34:45 | dbussink | evan: did see you found some surprising benchmark results :) |
| 05:34:52 | evan | yeah |
| 05:35:09 | evan | some 2x speed ups in Hash iteration |
| 05:35:24 | evan | working on speeding it up more now. |
| 05:35:32 | evan | got an idea while running today |
| 05:35:34 | dbussink | evan: i wonder, would the 0 entries be worth optimizing by returning directly? |
| 05:35:39 | evan | i've fixed up some old profiling code I did for the jit |
| 05:35:57 | evan | and made it so that -Xjit.profile turns on this profiling code in the JIT |
| 05:36:06 | evan | so that with that option, methods can show up twice in the profiling |
| 05:36:08 | brixen | dbussink: evan is making deals with the devil, at your prompting |
| 05:36:11 | evan | Hash#each_entry |
| 05:36:12 | evan | and |
| 05:36:14 | evan | Hash#each_entry <jit> |
| 05:36:18 | evan | 2 seperate entries |
| 05:36:23 | dbussink | ah ok, cool :) |
| 05:36:26 | evan | so you can see exactly what the JIT caused. |
| 05:36:31 | brixen | that's nice |
| 05:36:34 | dbussink | so you could see difference there too |
| 05:36:40 | evan | so that when it says "oh, I inlined that thing" |
| 05:36:48 | evan | i can actually check if it used the inline version |
| 05:36:55 | evan | beacuse if so, then that method disappears from the profiling |
| 05:37:07 | evan | because no inline method contributes profiling info. |
| 05:38:06 | evan | thats confusing to a normal user |
| 05:38:09 | evan | but it tells me a lot. |
| 05:39:14 | evan | check it |
| 05:39:14 | evan | http://gist.github.com/451031 |
| 05:39:33 | evan | note the 2 entries for Hash#each_key |
| 05:39:44 | evan | one jit, one not. |
| 05:40:16 | evan | additionally, Hash#each_key_block {} count stopped increasing |
| 05:40:26 | evan | though, i don't have block inlining on |
| 05:40:29 | evan | need to look into that. |
| 05:40:33 | brixen | heh |
| 05:41:02 | evan | wowzers. |
| 05:41:04 | evan | check this shit. |
| 05:41:17 | evan | wait wait |
| 05:41:23 | evan | i'm missing some data.. |
| 05:42:20 | brixen | I thought block inlining was enabled by default again? |
| 05:43:09 | evan | did I? |
| 05:43:14 | evan | no not yet |
| 05:43:53 | evan | reload the gist |
| 05:44:45 | evan | i'm missing some block data |
| 05:44:46 | evan | I think. |
| 05:45:18 | evan | because my guess is that everything got inlined into the block passed to #times |
| 05:45:23 | evan | but that row is missing. |
| 05:47:05 | brixen | evan: could you gist hash_create.rb |
| 05:47:44 | evan | reload |
| 05:47:47 | evan | it's not creating hashing anymore |
| 05:47:51 | evan | but i didn't change the file name |
| 05:48:12 | evan | ah, I see why. |
| 05:49:05 | evan | i've wired and rewired block invocation so many times |
| 05:49:07 | evan | i confused myself! |
| 06:23:29 | evan | rab |
| 06:23:31 | evan | rad |
| 06:23:32 | evan | fixed it. |
| 06:24:13 | evan | brixen: http://gist.github.com/451031 |
| 06:24:18 | evan | check out the 2nd file there |
| 06:24:27 | evan | the jit'd block now shows up |
| 06:24:46 | evan | and we can see that pretty much all the code got inlined into it |
| 06:25:00 | brixen | yeah |
| 06:26:44 | evan | thats good knowledge. |
| 06:28:07 | brixen | block inlining in this case certainly is a win |
| 06:28:15 | evan | yeah |
| 06:28:31 | evan | though, i think there is still a bug in block inlining here |
| 06:28:35 | evan | it's inlining more than I expect it to. |
| 06:28:48 | evan | i thought I made block inlining more restrictive |
| 06:28:55 | evan | maybe this is actually ok.. |
| 07:08:03 | dbussink | evan: is it inline too much so that it hurts performance? |
| 07:08:16 | evan | i'm headed to bed |
| 07:08:18 | evan | but real fast |
| 07:08:24 | evan | yes, but thats not the case i'm worried about here |
| 07:08:28 | evan | block inlining is quite tricky |
| 07:08:33 | evan | because the control flow is very strange. |
| 07:08:54 | evan | so i'm worried it inlined too much and would make the control flow weird |
| 07:08:58 | evan | i'll debug it more tomorro |
| 07:08:59 | evan | w |
| 07:09:05 | evan | i'm off to bed |
| 07:09:08 | dbussink | evan: ah, sleep well :0 |
| 07:09:09 | dbussink | :0 |
| 07:09:11 | dbussink | :) |
| 07:09:13 | dbussink | i can't type :S |
| 14:37:20 | manveru | evan: around? |
| 19:58:53 | spastorino | I've just run the Rails tests on Rubinius http://gist.github.com/451865 impressive results guys |
| 19:59:45 | Defiler | cool, yeah, all those failures except memcache look like bad tests |
| 19:59:51 | Defiler | e.g. ones that rely on the order of keys in a Hash |
| 20:00:00 | Defiler | or ones that assert things about platform-specific date formats |
| 20:00:43 | Defiler | hehe, you should see if PPC Process Gearbox works on rbx |
| 20:00:50 | Defiler | assuming you guys still have the code |
| 20:01:52 | spastorino | yeah i have seen this tests i will fix them ;) |
| 20:14:31 | eventualbuddha | I'm getting the same error message described at http://gist.github.com/405422: "Could not find RubyGem rake" while installing rbx with rvm on osx. anyone know what that's about? |
| 20:15:35 | Defiler | are you using rvm head? |
| 20:15:40 | dbussink | eventualbuddha: that's a pretty old rvm |
| 20:15:48 | Defiler | not his output |
| 20:15:49 | dbussink | eventualbuddha: i suggest updating first :) |
| 20:15:50 | Defiler | he's linking to an old gist |
| 20:15:59 | dbussink | ah ok, sorry |
| 20:16:04 | Defiler | rvm update --head |
| 20:16:07 | Defiler | and see if you get the same error |
| 20:16:27 | eventualbuddha | dbussink: well, that wasn't my gist |
| 20:16:29 | Defiler | if you do, you may want to ask in #rvm, though wayne definitely hangs out here too |
| 20:16:31 | eventualbuddha | but I'll try updating |
| 20:21:34 | eventualbuddha | Defiler, dbussink: https://gist.github.com/d8d8bcc37259a4d812be |
| 20:21:39 | eventualbuddha | my actual output |
| 20:22:27 | jarib | i'm still having trouble building on arch linux with 1.9; anyone know how to solve this? http://gist.github.com/451926 |
| 20:26:52 | cyndis | jarib: try removing lib/ext/openssl/Makefile and then try again |
| 20:27:01 | jarib | ok |
| 20:37:41 | Defiler | eventualbuddha: ok.. do "rvm implode" and then install it from head |
| 20:37:53 | Defiler | e.g. bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) |
| 20:48:08 | eventualbuddha | Defiler: thanks. imploded, reinstalled, did `rvm install rbx` and got this: https://gist.github.com/fbd909bb7ac1faa8e3c6 |
| 20:53:08 | Defiler | eventualbuddha: rbx-copy wtf is that |
| 20:53:17 | Defiler | eventualbuddha: sorry, never ever seen that.. I recommend asking in #rvm :( |
| 21:01:33 | eventualbuddha | Defiler: thanks for the help |
| 21:01:36 | eventualbuddha | I am ;) |
| 21:01:41 | Defiler | cool |
| 21:01:48 | Defiler | let me know what fixes it if it gets fixed |
| 21:01:55 | eventualbuddha | will do |
| 22:04:14 | bougyman | oi |
| 22:05:11 | bougyman | i'm getting a 404 on the git clone |
| 22:05:21 | bougyman | you have an alternate repo? |
| 22:05:44 | bougyman | nm, i got it |