Show enters and exits. Hide enters and exits.
| 00:07:27 | brixen | evan: I can't think of one either and everything passes with this diff http://gist.github.com/456581 |
| 00:07:48 | brixen | that sequence is a little different than the one I was working with before I refactored a bit |
| 00:07:54 | evan | if we do that |
| 00:07:56 | brixen | which is why I didn't notice it |
| 00:08:00 | evan | then we don't need the next_local either |
| 00:08:03 | evan | which seems wrong |
| 00:08:06 | evan | let me think about it |
| 00:13:14 | evan | oh oh |
| 00:13:29 | evan | yeah, they'll always go the same place i think |
| 00:13:34 | evan | let me do one more test. |
| 00:13:57 | evan | break uses that code because from the ensure, we might want to get out of the loop, or return to the header |
| 00:14:03 | evan | but with next, you're always returning to the header |
| 00:14:08 | evan | thats why they always point the same place |
| 00:14:11 | brixen | well, I have at least one case in next_spec where check_next is true but g.next is nil |
| 00:14:17 | brixen | i'm trying to figure out which |
| 00:14:59 | evan | that should be in a block |
| 00:15:08 | evan | 1.times { begin; next; ensure; 1; end } |
| 00:15:46 | evan | in that case, the end has |
| 00:15:54 | evan | 0062: push_stack_local 1 |
| 00:15:55 | evan | 0064: goto_if_false 66 |
| 00:15:55 | evan | 0066: ret |
| 00:16:07 | evan | which is clearly redundent. |
| 00:16:21 | evan | we can remove the used_next_local |
| 00:16:23 | evan | and the code that uses it |
| 00:16:31 | evan | because if you make it to the bottom of an ensure because of a block |
| 00:16:53 | evan | then you should just goto g.next or ret |
| 00:17:09 | evan | because you're done with the current iteration if you're in the ensure |
| 00:17:17 | evan | so you just want to go to the next iteration |
| 00:17:30 | evan | which is either going to a header or returning from the current block |
| 00:18:55 | evan | brixen: thoughts? |
| 00:19:09 | brixen | seems right |
| 00:19:35 | brixen | did you try it? |
| 00:19:59 | evan | not yet |
| 00:20:10 | evan | just thinking through it. |
| 00:20:31 | brixen | heh, my thinking is greatly assisted by running code |
| 00:20:53 | evan | :) |
| 00:25:42 | brixen | yep, works for me without used_next_local |
| 00:25:50 | evan | ok |
| 00:25:51 | evan | cool. |
| 00:26:01 | evan | you see the reason? |
| 00:26:08 | brixen | checking the bytecode in my example scripts |
| 00:26:29 | evan | when you're done with next, the 2 things you do are "go to the next iteration" or "go to the next iteration" |
| 00:26:30 | evan | :D |
| 00:26:35 | evan | where as with the break code |
| 00:26:44 | evan | the other option is "exit the loop" |
| 00:26:59 | brixen | yeah, that makes sense |
| 00:27:02 | evan | thus the used_break_local flag |
| 00:27:08 | evan | to figure out which path was used. |
| 00:28:45 | brixen | this is my diff http://gist.github.com/456604 |
| 00:31:03 | brixen | hmm |
| 00:31:47 | evan | seems good |
| 00:31:48 | evan | something up? |
| 00:31:52 | brixen | somethings not right |
| 00:32:00 | evan | oh |
| 00:32:01 | evan | you need |
| 00:32:17 | evan | g.next ? g.goto(g.next) : g.ret |
| 00:32:19 | evan | at the end |
| 00:32:43 | evan | because when next is run inside a block with begin; ensure |
| 00:32:54 | evan | next just jumps to the ensure code |
| 00:33:10 | evan | so you need to handle the case where there is no outer next at the bottom of ensure |
| 00:33:52 | brixen | well, I was looking at the output from your example |
| 00:34:01 | brixen | ack, I need to go to class... |
| 00:34:06 | evan | ok |
| 00:34:08 | brixen | evan: do you want to commit it? |
| 00:34:12 | evan | nah |
| 00:34:15 | evan | i'll let you ponder it. |
| 00:34:18 | brixen | k |
| 04:53:50 | evan | http://itpro.nikkeibp.co.jp/article/NEWS/20100628/349693/ O_o |
| 05:36:33 | dbussink | evan: ah, saw you were able to fix it? :) |
| 05:36:43 | evan | yep |
| 05:36:46 | evan | you had the wrong commit though :D |
| 05:36:48 | evan | it was a few days ago. |
| 05:37:36 | dbussink | evan: that's weird, maybe it triggered it at some other point then |
| 05:37:50 | dbussink | evan: because it failed a lot faster after the last commit |
| 05:37:52 | evan | maybe you hadn't run the specs fully? |
| 05:38:01 | evan | anyway, it's fixed. |
| 05:38:18 | dbussink | would there have been an easier way to find it? |
| 05:42:22 | evan | nah |
| 05:42:30 | evan | it was an ommision on my part. |
| 05:44:21 | dbussink | i guess stuff like this is pretty hard to test / spec too, to prevent regressions etc.? |
| 05:44:41 | evan | yeah |
| 05:47:58 | dbussink | evan: hmm, as comparison, 1.8.7 takes 3 minutes for that spec run, rbx 30 |
| 05:48:15 | evan | yeah, so I noticed. |
| 05:49:04 | evan | you need to dig in there and figure out whats slow |
| 05:49:06 | evan | use -Xprofile |
| 05:49:22 | dbussink | i guess it's pretty killing on the gc, since it creates tons of new shortly lived objects |
| 05:49:35 | evan | guess is nothing. |
| 05:49:36 | evan | know. |
| 05:49:38 | evan | or don't know. |
| 05:49:41 | evan | :) |
| 05:49:58 | slava | but MRI doesn't have a generational GC so you'd see the opposite outcome if that were the case |
| 05:50:00 | evan | btw, go Holland! |
| 05:50:12 | evan | #worldcup |
| 05:51:01 | evan | yeah, if it's swamping the GC, i have to wonder if i have perf bug in there |
| 05:51:09 | evan | and if so, we need to shake it out with some benchmarks |
| 05:51:24 | dbussink | evan: hehe, if they play bad and win, that's only a good thing :P |
| 05:51:34 | dbussink | they're already saying here that we play like germans :P |
| 05:51:37 | dbussink | and they always get far |
| 05:51:50 | evan | hah |
| 05:51:56 | parndt | well they sure whooped england |
| 05:52:12 | evan | well, i'm rooting for you! |
| 05:52:17 | dbussink | good! :) |
| 05:52:42 | dbussink | evan: do you like optical illusions? |
| 05:53:00 | evan | is this the goal one? :) |
| 05:53:06 | dbussink | ah, you saw it :P |
| 05:53:46 | dbussink | the way the fifa is handling it is such a painful way |
| 05:54:09 | dbussink | they showed a press conference on tv, the fifa guy said, no questions about yesterday's game |
| 05:54:18 | dbussink | so every reporter started asking questions about it |
| 05:54:43 | evan | yeah |
| 05:54:49 | evan | fifa is looking pretty fucking poor |
| 05:54:50 | dbussink | evan: but it's churning away with a profile, if i have one, i'll gist it |
| 05:54:57 | evan | yeah |
| 05:55:04 | evan | see if you can isolate it down to a short sequence |
| 05:55:18 | evan | a 10 spec grouping is even better than the current setup |
| 06:00:25 | dbussink | evan: yeah, i'll check the profile to see if anything stands out or that it's across the board |
| 06:00:38 | dbussink | if it's across the board, running a smaller spec set should be fine to perf test too |
| 06:00:47 | evan | right |
| 06:00:53 | evan | if the GC is getting swamped |
| 06:00:57 | evan | then it should be slowing. |
| 06:06:52 | dbussink | evan: is there more english info on that fpga board? |
| 06:07:40 | dbussink | maybe know a few people in our company who'd be interested in that |
| 06:13:01 | parndt | are there any known incompatibilities with rbx and json-pure |
| 06:14:22 | parndt | ah yep - http://github.com/evanphx/rubinius/issues/issue/311 |
| 06:15:30 | evan | dbussink: not that I'm aware of, no. |
| 06:15:39 | evan | parndt: thats not json-pure |
| 06:15:40 | evan | thats json. |
| 06:15:46 | evan | and i've put in a ticket with them |
| 06:15:50 | evan | and they've not fixed it. |
| 06:16:01 | evan | the json gem actually won't build in a lot of scenarios |
| 06:16:05 | evan | rbx is just one of them. |
| 06:17:22 | parndt | yeah it also won't build from rubygems.org from me on 1.8.7 so was kinda expecting it to break.. |
| 06:18:47 | evan | yeah |
| 06:18:53 | evan | you know, fuck this, i'm going to clone their repo and fix this. |
| 06:19:13 | parndt | I actually looked under your account for a fork before ;) |
| 06:20:16 | boyscout | Add ObjectSpace.find_references - dfbad09 - Evan Phoenix |
| 06:20:52 | evan | i'm fixing it now. |
| 06:21:08 | parndt | nice one. |
| 06:21:38 | parndt | I can't even install json_pure gem on OSX under 1.8.7 from rubygems.org -- bad metadata, had to build my own. So many problems just from this one library. |
| 06:23:21 | evan | ok pushed |
| 06:23:27 | evan | if you clone and use evanphx/json |
| 06:23:29 | evan | it will work fine. |
| 06:23:41 | parndt | hot. i'll just pull into my existing fork |
| 06:25:42 | parndt | http://github.com/parndt/json -- mine has a gemspec which means I can use this as my gem source for bundler |
| 06:25:44 | parndt | thanks evan! |
| 06:26:06 | evan | no prob. |
| 06:28:45 | boyscout | CI: rubinius: dfbad09 successful: 3457 files, 13653 examples, 41219 expectations, 0 failures, 0 errors |
| 06:28:57 | evan | dbussink: raw allocations isn't the problem |
| 06:29:33 | evan | on a straight allocation benchmark, 1.8 is 4.12s, rbx is 1.2s |
| 06:34:08 | evan | dbussink: also, try running the specs with -Xgc.show |
| 06:36:42 | brixen | evan: not right yet :( http://pastie.org/1022928 |
| 06:40:11 | postmodern | whats the command to attach to a running rbx process? |
| 06:40:21 | postmodern | rbx seems to take forever when loading Bundler |
| 06:40:24 | brixen | postmodern: in what? gdb or rbx console? |
| 06:40:33 | postmodern | rbx console |
| 06:40:44 | brixen | start the first with rbx -Xagent.start |
| 06:40:54 | brixen | then in another terminal, rbx console |
| 06:41:30 | postmodern | neat, how does rbx know which process to bind to? |
| 06:41:42 | brixen | magic :) |
| 06:41:49 | brixen | it writes a file to tmp |
| 06:41:52 | postmodern | "Unable to find any agents to connect to please specify one" |
| 06:42:05 | brixen | you need to start the first instance with -Xagent.start |
| 06:42:30 | postmodern | yes, i did that |
| 06:42:38 | brixen | hrm, it's working here |
| 06:42:41 | brixen | what platform? |
| 06:42:59 | postmodern | Linux light.lab 2.6.33.5-124.fc13.i686 #1 SMP Fri Jun 11 09:48:40 UTC 2010 i686 i686 i386 GNU/Linux |
| 06:43:12 | evan | try "bin/rbx console --ps" |
| 06:43:12 | brixen | could you be more specific? |
| 06:43:14 | brixen | heh |
| 06:44:18 | postmodern | seems to be a considerable hang with all rbx console commands |
| 06:44:21 | postmodern | Agents found: 0 |
| 06:44:34 | postmodern | I think rubinius might have a bug |
| 06:44:41 | postmodern | shocking propisition i know |
| 06:44:45 | evan | not unless you can show me. |
| 06:45:11 | evan | how long is considerable? |
| 06:45:20 | brixen | evan: well, hum, I'm thinking the check_next_local is require |
| 06:45:20 | evan | and by console commands, do you mean stuff like -v? |
| 06:45:21 | postmodern | ~10 seconds |
| 06:45:23 | brixen | er required |
| 06:45:44 | postmodern | what tmp file name does rbx use for console pipes? |
| 06:45:47 | brixen | evan: my ensure.rb in that pastie passes with my original code |
| 06:45:51 | evan | brixen: yes yes |
| 06:45:55 | evan | ok |
| 06:45:56 | evan | i see why |
| 06:45:59 | evan | go back to your original code |
| 06:46:06 | brixen | I have one fix though |
| 06:46:10 | evan | the case I was missing that you've shown me is this case |
| 06:46:18 | brixen | I forgot the g.ret that you showed me |
| 06:46:21 | evan | when there is code after the 'begin;ensure;end' |
| 06:46:30 | brixen | yeah, I'll add a spec |
| 06:46:33 | evan | thats where post goes to run stuff when there is no next |
| 06:46:41 | brixen | I had so many test files originally |
| 06:46:51 | postmodern | ah wow the performance is just really really bad with Bundler.setup |
| 06:47:00 | postmodern | a couple minutes later, it finally ran the specs |
| 06:47:04 | brixen | postmodern: could you -Xprofile it? |
| 06:47:05 | evan | postmodern: how many seconds to run bin/rbx -v |
| 06:47:13 | evan | postmodern: the bundler specs are very slow |
| 06:47:14 | evan | i'm aware |
| 06:47:18 | evan | don't bother reporting that |
| 06:47:30 | evan | but if it's extremely slow running, that is something i'm interested in. |
| 06:47:37 | evan | the bundler specs shell back out for every it block |
| 06:47:38 | evan | basicalyl. |
| 06:48:11 | postmodern | evan, im running my project's specs after Bundler.setup |
| 06:48:18 | postmodern | evan, to ensure a self contained dev environment |
| 06:48:33 | evan | so |
| 06:48:38 | evan | Bundler.setup just hung? |
| 06:48:40 | evan | basically |
| 06:48:42 | evan | for 10 minutes |
| 06:48:46 | evan | then finally our specs started? |
| 06:48:51 | evan | your specs, rather. |
| 06:49:14 | postmodern | evan, http://pastie.org/1022943 times |
| 06:49:26 | evan | wow. |
| 06:49:29 | postmodern | evan, yeah more like a minute for Bundler.setup |
| 06:49:31 | evan | your system is completely swapped out |
| 06:49:37 | evan | check your cpu |
| 06:50:09 | postmodern | evan, nope, not seeing anything above 10% of CPU |
| 06:50:22 | evan | something is very wrong on your machine |
| 06:50:32 | postmodern | evan, although when i run rbx, it consums 140% of the CPU |
| 06:50:33 | evan | elle :: git/rbx> time bin/rbx -v |
| 06:50:33 | evan | rubinius 1.0.0 (1.8.7 ff84fbf6 2010-05-14 JI) [i686-pc-linux-gnu] |
| 06:50:33 | evan | bin/rbx -v 0.67s user 0.08s system 101% cpu 0.739 total |
| 06:50:39 | evan | thats on a linux machine |
| 06:50:44 | evan | with a lot less CPU than yours |
| 06:50:53 | evan | what about your load? |
| 06:50:56 | evan | is it very high? |
| 06:51:07 | postmodern | load spikes to 0.99 when running rbx |
| 06:51:21 | evan | it's going to consume more than 100% because it makes use of multiple cores with threads |
| 06:51:32 | postmodern | after rbx has exited, it goes back down to 0.20 |
| 06:51:34 | evan | but the times you're seeing aren't anything i've seen before. |
| 06:51:41 | brixen | postmodern: can you give evan access to the box? |
| 06:51:42 | evan | nor have they ever been reported |
| 06:51:59 | postmodern | brixen, im affraid not |
| 06:52:07 | postmodern | brixen, this is my work netbook |
| 06:52:09 | evan | postmodern: how did you build rbx? |
| 06:52:19 | postmodern | evan, ./configure --skip-system && rake |
| 06:52:24 | evan | i wonder if there is something about your system... |
| 06:52:30 | evan | never seen it that bad, ever. |
| 06:52:34 | postmodern | evan, im on a stock FC13 i686 install |
| 06:52:37 | evan | even in the worst of conditions. |
| 06:52:51 | evan | netbook? is that using an SSD? |
| 06:52:57 | postmodern | evan, not an SSD |
| 06:53:05 | evan | what kind of drive? |
| 06:53:25 | evan | is this the first time you've used rbx on this machine? |
| 06:54:30 | postmodern | evan, i've recently got rbx compiled on this system, since the only version of MRI I got to compile against OpenSSL 1.0.0 was 1.9.2-preview3 |
| 06:54:46 | postmodern | evan, and brixen finally got the build-system working under 1.9 |
| 06:54:58 | evan | so is this the first time you're running rbx? |
| 06:55:07 | evan | ie, did it ever work better on this machine? |
| 06:56:58 | postmodern | evan, i did run rbx under Fedora 11 for a while |
| 06:57:03 | postmodern | evan, and it ran fairly snappy |
| 06:57:06 | evan | on this machine? |
| 06:57:08 | postmodern | yes |
| 06:57:18 | evan | something is majorly up. |
| 06:57:21 | postmodern | i recently upgraded to FC13 |
| 06:57:31 | evan | did you recompile when you upgraded? |
| 06:57:50 | evan | recompile rbx |
| 06:58:04 | postmodern | evan, yes i regularly rake clean && rake |
| 06:58:08 | postmodern | evan, http://www.wdc.com/en/products/products.asp?driveid=513 |
| 06:58:20 | postmodern | evan, that's what Acer put in this thing |
| 06:58:25 | evan | hm... |
| 06:58:45 | postmodern | evan, most all netbooks are exactly the same |
| 06:59:02 | evan | well, you've told me it worked fine before |
| 06:59:05 | evan | so it's not the hardware |
| 06:59:09 | evan | it's something about FC13 |
| 06:59:21 | postmodern | im guessing it's a preformance bug due Bundler |
| 06:59:25 | evan | under FC11, did you use 1.9 or 1.8 to compile |
| 06:59:25 | evan | no |
| 06:59:28 | evan | it's not. |
| 06:59:30 | postmodern | rbx -v could be faster |
| 06:59:32 | evan | not if -v takes that long. |
| 06:59:41 | evan | it should be max 2 seconds |
| 06:59:49 | evan | are you setting RUBYOPT? |
| 06:59:51 | postmodern | let me reconfig |
| 06:59:59 | postmodern | yes |
| 07:00:01 | postmodern | -rrubygems |
| 07:00:07 | evan | remove it. |
| 07:00:09 | evan | see what -v does |
| 07:00:27 | postmodern | recompiling rbx |
| 07:00:31 | postmodern | will test that once completed |
| 07:01:47 | parndt | real 0m0.236s :D |
| 07:09:27 | boyscout | Another next with ensure spec. - 79c86f7 - Brian Ford |
| 07:09:27 | boyscout | Fix for next with ensure (pair Evan). - d36b054 - Brian Ford |
| 07:12:43 | evan | ok, well, i should get to bed. |
| 07:12:51 | parndt | night evan |
| 07:12:53 | evan | postmodern: let me know how it goes tomorrow |
| 07:13:15 | postmodern | evan, night |
| 07:18:50 | boyscout | CI: rubinius: d36b054 successful: 3457 files, 13654 examples, 41220 expectations, 0 failures, 0 errors |
| 07:38:13 | dbussink | evan: still there? |
| 07:38:21 | dbussink | probably not though |
| 07:50:10 | dbussink | evan: for when you're back: https://gist.github.com/da780095fe7bdc3f983d |
| 07:53:35 | kronos_vano | dbussink, ^^ which code? |
| 07:53:47 | dbussink | kronos_vano: complete run of the datamapper specs |
| 07:53:55 | kronos_vano | ah. |
| 07:53:55 | dbussink | with an in-memory database |
| 07:54:43 | kronos_vano | And how it is in comparsion with mri? |
| 07:55:36 | dbussink | kronos_vano: around 10x slower |
| 07:55:46 | kronos_vano | er. not good. |
| 08:35:30 | postmodern | well i confirmed that RUBYOPT="-rrubygems" was slowing down rbx -v |
| 08:35:45 | postmodern | but running Bundler.setup in rbx, is *painful* slow |
| 08:35:54 | postmodern | it would seem someone needs some optimization |
| 09:35:40 | dbussink | postmodern: did you profile it? |
| 09:35:52 | postmodern | dbussink, ah right let me do that |
| 09:36:02 | postmodern | rbx -Xprofile ? |
| 09:36:56 | postmodern | ah right |
| 09:59:16 | postmodern | dbussink, http://pastie.org/1023114 |
| 10:00:10 | dbussink | postmodern: current master? |
| 10:00:16 | postmodern | dbussink, yup |
| 10:00:22 | postmodern | dbussink, bundler 0.9.26 |
| 12:06:58 | dbussink | postmodern: could you run that with -Xprofiler.graph added as option too? |
| 12:07:46 | postmodern | dbussink, sure, but it will take like 15 minutes |
| 12:08:10 | dbussink | postmodern: i guess bundler scans all installed gems or something? |
| 12:08:28 | postmodern | dbussink, yeah, and probably does a bunch of Array manipulation |
| 14:27:26 | goyox86 | morning |
| 17:13:52 | dbussink | evan: ping? |
| 17:13:57 | evan | hey |
| 17:14:23 | dbussink | evan: did you see my gist? |
| 17:14:25 | dbussink | also saw you're doing a webinar? |
| 17:14:42 | evan | nope and yep. |
| 17:14:45 | evan | what gist? |
| 17:16:05 | dbussink | evan: this is the dm spec run profile: https://gist.github.com/da780095fe7bdc3f983d |
| 17:16:27 | evan | do you have the flat one too? |
| 17:16:41 | dbussink | nope, haven't run that, i can run it but it takes a while :P |
| 17:16:41 | evan | I should really make it output both |
| 17:16:50 | dbussink | hehe, probably yeah : |
| 17:16:52 | dbussink | :) |
| 17:17:06 | dbussink | i can run a bunch of specs separately |
| 17:17:46 | evan | fuck geez. |
| 17:17:53 | evan | 2725431 Rubinius::VM.reset_method_cache |
| 17:17:56 | evan | wtf rspec. |
| 17:18:07 | dbussink | i guess it's more rspec than datamapper that is to blame here |
| 17:19:58 | brixen | stares at a Hash spec |
| 17:20:12 | dbussink | brixen: stare it down! |
| 17:20:20 | brixen | I should get some of those fake sunglasses with WTF! in the lenses |
| 17:20:20 | dbussink | brixen: make it bend to your will |
| 17:20:29 | brixen | and take pics of myself working on rubyspec |
| 17:20:30 | brixen | :( |
| 17:21:10 | evan | also |
| 17:21:12 | evan | rspec |
| 17:21:13 | evan | fail. |
| 17:21:41 | evan | it creates 271726 Modules. |
| 17:22:18 | evan | dbussink: can you isolate some dm benchmarks outside of rspec? |
| 17:22:25 | evan | rspec completely overwhelms this profile |
| 17:22:33 | dbussink | evan: i can look at that yeah |
| 17:22:45 | dbussink | evan: i guess the rspec performance is pretty killing here yeah |
| 17:22:59 | evan | looks like it did 3M string evals |
| 17:22:59 | evan | also. |
| 17:23:02 | evan | *eyeroll* |
| 17:24:05 | brixen | rspec is the new haskell |
| 17:24:20 | dbussink | evan: this is a small part of the spec run in a flat profile: https://gist.github.com/39f503decb527ee74638 |
| 17:24:31 | evan | and 5.7M calls to Kernel#caller |
| 17:24:33 | evan | 5.7 |
| 17:24:36 | evan | million. |
| 17:24:59 | dbussink | we need to optimize that! |
| 17:25:01 | dbussink | right now! |
| 17:25:12 | dbussink | caller() performance is a major issue of course |
| 17:25:22 | brixen | dbussink: can you try with rspec2 ? |
| 17:25:25 | evan | dbussink: how many exceptations did this run? |
| 17:25:47 | brixen | wow, that is a beauty: exceptations :) |
| 17:25:47 | dbussink | brixen: didn't work last time i tried, but also haven't checked it out further |
| 17:25:53 | brixen | I'm going to use that for rubyspec |
| 17:26:08 | brixen | when you have no idea if this spec is even valid: exceptation |
| 17:26:10 | dbussink | evan: that second flat profile ran 1418 examples, 0 failures, 51 pending |
| 17:26:26 | dbussink | but the whole run is a whole bunch more |
| 17:26:34 | evan | what flat profile? |
| 17:26:47 | evan | oh |
| 17:26:49 | evan | above |
| 17:26:49 | dbussink | evan: that i just gisted |
| 17:26:53 | evan | sorry |
| 17:26:54 | evan | i see. |
| 17:26:56 | dbussink | :) |
| 17:28:02 | dbussink | evan: i can run a graph from that second case too |
| 17:28:06 | dbussink | shouldn't take that long |
| 17:30:16 | evan | k |
| 17:30:27 | evan | i can't believe how long the big profile took :( :( |
| 17:30:40 | dbussink | yeah, pretty sad |
| 17:31:06 | dbussink | evan: i've added it to https://gist.github.com/39f503decb527ee74638 |
| 17:31:14 | dbussink | brixen: rspec2 should be better from what i've heard |
| 17:31:19 | dbussink | but haven't tried |
| 17:31:34 | brixen | dbussink: yeah, I'm curious if you could try it |
| 17:33:42 | evan | our instance_eval is about 3x slower than MRI |
| 17:33:46 | evan | i'm going to poke a little bit. |
| 17:34:28 | brixen | woohoo: http://skitch.com/brixen/dkmk1/gmail-inbox-1305-brixen-gmail.com |
| 17:34:41 | brixen | pretty sure that's the first ad I've seen for rbx |
| 17:34:56 | evan | wow. |
| 17:34:57 | evan | WOW. |
| 17:35:01 | evan | definitely my first! |
| 17:35:10 | BrianRice-work | huh |
| 17:35:38 | brixen | also, I'm shooting for inbox 1500 :) |
| 17:35:45 | brixen | who needs inbox 0 |
| 17:35:52 | brixen | <-- not this guy |
| 17:36:11 | dbussink | i have a read / flagged 0 policy |
| 17:36:32 | brixen | dbussink: you don't read or flag any? :) |
| 17:36:45 | dbussink | brixen: unread :P |
| 17:36:49 | dbussink | brixen: and flagged as done |
| 17:36:56 | dbussink | you get the point :P |
| 17:37:19 | brixen | dbussink: heh |
| 17:40:04 | dbussink | evan: this is the same benchmark that trigger the hash performance stuff spike: https://gist.github.com/c3db2cc6224b9485a839 |
| 17:40:25 | dbussink | some initial numbers at the bottom |
| 17:40:30 | evan | dbussink: ok, well, we're doing better than 1.8 |
| 17:40:33 | evan | try with -Xjit.inline.blocks |
| 17:42:53 | dbussink | evan: updated the gist |
| 17:43:07 | dbussink | evan: quite a bit faster, no 1.9 performance yet though ;0 |
| 17:43:08 | dbussink | ;) |
| 17:43:12 | evan | i was hoping for more |
| 17:43:13 | evan | but yeah, |
| 17:43:15 | evan | not bad. |
| 17:43:32 | evan | ok, so it's not this thats causing the specs to run so slowly. |
| 17:44:20 | dbussink | evan: could write some rspecs that just do 2.should == 2 ;) |
| 17:44:24 | dbussink | and see how much slower that is |
| 17:44:27 | evan | yeah |
| 17:44:29 | evan | i'm going to. |
| 17:45:17 | dbussink | but i have to go, back later |
| 17:45:24 | evan | k |
| 17:45:24 | evan | later. |
| 17:52:20 | evan | things that rspec does that are stupid: requests 40k backtraces to run 10k it blocks |
| 17:52:36 | evan | none of those it's failed |
| 17:52:37 | evan | mind you. |
| 17:52:46 | brixen | ugh |
| 17:53:04 | evan | yeah |
| 17:53:06 | evan | ugh is right. |
| 17:53:46 | evan | i'm considering making Kernel#caller a primitive. |
| 17:59:21 | evan | mm, maybe not 40k |
| 17:59:23 | evan | but at least 10k |
| 18:00:35 | brixen | it's good to always have a bt in your back pocket, never know when you might need it |
| 18:00:54 | evan | "now where did I put that backtrace..." |
| 18:01:07 | evan | i wonder if i could cheat. |
| 18:01:17 | evan | and have Kernel#caller return a lazy array |
| 18:01:23 | brixen | I was wondering that too |
| 18:01:34 | evan | still need to pull in the location objects |
| 18:01:43 | brixen | yeah |
| 18:01:44 | evan | in which case, i think i'd be better off just having a caller primitive |
| 18:01:48 | evan | that outputs the MRI format. |
| 18:01:52 | brixen | probably |
| 18:08:09 | cremes | is there a ruby call i can make to retrieve the amount of heap my running process has consumed? |
| 18:13:00 | evan | cremes: rubinius specific? |
| 18:15:21 | cremes | evan: yes |
| 18:15:54 | evan | there is no single method, you have to sum it up because i provide various ones |
| 18:15:57 | evan | but let me show you. |
| 18:16:14 | cremes | cool... |
| 18:17:19 | evan | cremes: http://github.com/evanphx/rubinius/blob/master/lib/bin/console.rb#L137-164 |
| 18:17:30 | evan | you connect to the agent running in the current process by doing |
| 18:17:33 | evan | require 'rubinius/agent' |
| 18:17:37 | evan | agent = Rubinius::Agent.loopback |
| 18:19:04 | cremes | agent.get "system.memory.young.bytes", etc? |
| 18:19:14 | cremes | very neat |
| 18:20:39 | cremes | it would be nice if all of the runtimes had this kind of functionality |
| 18:22:43 | evan | cremes: read console |
| 18:22:46 | evan | you'll see how to use the agent |
| 18:22:53 | evan | generally, though, yes #get is how you ask for a variable. |
| 18:23:10 | brixen | evan: for you to ponder as you work on hash http://redmine.ruby-lang.org/issues/show/1535 |
| 18:23:15 | brixen | well Hash |
| 18:23:23 | brixen | I hope you do not work "on" hash |
| 18:24:09 | evan | rad. |
| 18:24:19 | evan | no, no, not since college. |
| 18:24:35 | evan | even then, no. |
| 18:37:20 | evan | brixen: thats all crazy sause |
| 18:37:21 | evan | imho. |
| 18:37:44 | evan | i'm happy to see that 1.9.2 has more obvious behavior. |
| 18:38:08 | brixen | well, 1.9.2 should raise on modifying during iteration |
| 18:38:17 | brixen | that ticket is for 1.8.8+ |
| 18:39:00 | brixen | the wacktastic part of it is that if rehash were triggered, you'd get the error in <= 1.8.7 |
| 18:39:16 | brixen | so it's hard to say "bug" or "version difference" |
| 18:40:28 | brixen | it's so damn hard to find issues on the ruby tracker |
| 18:41:21 | evan | yeah, it's definitely completely hit/miss on 1.8 |
| 18:41:31 | evan | because even Hash#[]= could trigger a rehash |
| 18:41:38 | evan | and you'd get an exception |
| 18:42:08 | brixen | well, you shouldn't unless you are iterating |
| 18:42:30 | evan | right |
| 18:42:38 | evan | runpaint only mentions merge! |
| 18:42:38 | evan | but |
| 18:42:53 | evan | hash.each { |k,v| hash[k] = f(v) } |
| 18:42:56 | evan | could trigger a rehash |
| 18:43:15 | brixen | yeah |
| 18:49:32 | evan | wtf.... |
| 18:56:03 | sbryant | ... |
| 18:58:40 | brixen | .... . .-.. .-.. --- |
| 19:01:25 | sbryant | ! |
| 19:02:59 | brixen | oh man http://bash.org/?925050 |
| 19:03:48 | evan | hah |
| 19:03:54 | evan | 14.60 0.94 0.94 20003 0.05 0.05 Rubinius.mri_backtrace |
| 19:04:03 | evan | thats better, but rspec is still a hog. |
| 19:04:13 | evan | i don't see any way to improve on that either. |
| 19:18:06 | Defiler | rspec expects all the slowest parts of ruby to be fast |
| 19:18:54 | evan | yeah |
| 19:19:03 | evan | it's pretty ridiculious |
| 19:25:37 | brixen | heh, funny |
| 19:25:55 | brixen | I put Ruby.check_frozen in Hash#initialize to make this spec pass |
| 19:26:03 | brixen | it's faster with the JIT on! |
| 19:26:12 | brixen | as expected, it's slower with the JIT off |
| 19:26:32 | brixen | but, having that as the first insn is consistently faster |
| 19:30:39 | evan | hehe |
| 19:30:41 | evan | well, lunch time. |
| 19:35:52 | QaDeS | hiyas. just noticed the "How to install" section is missing a note how to install via rvm :o) |
| 19:36:18 | QaDeS | or pik |
| 19:37:43 | brixen | pik runs on windows, rbx does not run on windows |
| 19:37:51 | brixen | rvm has instructions on how to install |
| 19:37:59 | brixen | why would we put rvm instructions in rbx? |
| 19:38:51 | QaDeS | forgot about the windows thing |
| 19:39:07 | QaDeS | well, because it's arguably the easiaest way to install ;o) didn't get 1.0.1 to install on it, tho. that's why i looked |
| 19:39:45 | boyscout | Some fixes for Hash specs. Closes #364. - 2a16a08 - Brian Ford |
| 19:39:45 | boyscout | Check frozen on Hash#initialize. - a63fc1d - Brian Ford |
| 19:39:45 | boyscout | Update Hash CI tags. - e0f7fa7 - Brian Ford |
| 19:39:57 | brixen | well, I would say "arguably" indeed |
| 19:40:20 | brixen | rbx has 3 steps: clone; ./configure --prefix; rake install |
| 19:40:29 | brixen | we document that because that is our system |
| 19:40:34 | brixen | rvm has good documentation |
| 19:40:48 | brixen | I can see mentioning "see rvm" but we're not going to include rvm docs |
| 19:43:34 | QaDeS | umm |
| 19:43:54 | QaDeS | "rvm install rbx-head" would be sufficient, really |
| 19:44:17 | brixen | rvm can also change that anytime |
| 19:44:18 | QaDeS | whatever, i got it running now |
| 19:46:01 | QaDeS | ok, that sounds like you had your fill of rvm already ;o) |
| 19:46:15 | brixen | not at all, rvm is great |
| 19:46:22 | brixen | and comes with great documentation |
| 19:47:44 | brixen | but just like we won't document how to install via apt-get etc |
| 19:47:49 | boyscout | CI: rubinius: e0f7fa7 successful: 3457 files, 13665 examples, 41242 expectations, 0 failures, 0 errors |
| 19:47:53 | brixen | rvm docs are outside the scope of rbx, IMO |
| 19:52:08 | QaDeS | i'm not gonny try to talk you into that ;o) just saw something on, i think, the maglev website and thought it was really nice |
| 19:52:23 | QaDeS | never mind :) |
| 21:27:19 | toulmean | hey guys, so I discussed with Assaf some more |
| 21:27:26 | evan | ok |
| 21:27:31 | toulmean | he told me master was a bit rough, I should try with the 1.3 tag. |
| 21:27:47 | toulmean | with that tag I still had to add a "require "rubygems" instruction at the top of the test_helper |
| 21:28:05 | toulmean | I think it's fair to require rubygems explicitly |
| 21:28:24 | toulmean | I have 6 failures after that over redis communication. |
| 21:28:46 | toulmean | I am going back to meetings today so if you want I can create a gist ? |
| 21:28:53 | toulmean | otherwise feel free to ignore. |
| 21:35:44 | toulmean | actually this looks maybe interesting: |
| 21:35:45 | toulmean | TypeError: Coercion error: #<File:0x28a08 path=tmp/config/redis.yml>.to_str => String failed |
| 21:35:59 | evan | whats the backtrace? |
| 21:36:01 | evan | gist it. |
| 21:36:20 | evan | create a gist of all of them, sure. |
| 21:36:38 | toulmean | http://gist.github.com/457846 |
| 21:36:51 | toulmean | evan: giving a screencast on rubinius soon ? |
| 21:36:58 | evan | next wednesday, yep! |
| 21:37:01 | toulmean | just saw a google ad about that. |
| 21:37:06 | toulmean | cool, good luck! |
| 21:37:52 | evan | wow, that google ad is making it around |
| 21:38:37 | toulmean | :) |
| 21:38:56 | BrianRice-work | not enough ruby content in my gmail, but I am getting a kaazing ad |
| 21:39:02 | BrianRice-work | (websockets) |
| 21:39:14 | toulmean | evan: here are the diffs I had to make to make vanity 1.3 run with rubinius ok http://gist.github.com/457850 |
| 21:39:19 | evan | ok |
| 21:39:34 | toulmean | ok back to my java grind |
| 21:40:23 | Defiler | http://itpro.nikkeibp.co.jp/article/NEWS/20100628/349693/ |
| 21:40:26 | Defiler | ruby on an FPGA |
| 21:40:59 | Defiler | http://www.f-ruby.com/ |
| 21:42:28 | evan | yeaH! |
| 21:42:39 | evan | matz said they're using a generic CPU to run most of ruby |
| 21:42:43 | evan | just the GC is in FPGA |
| 21:42:56 | Defiler | makes sense |
| 21:43:54 | boyscout | Add a primitive to calculate the MRI format backtrace. @perf @rspec - a2470f3 - Evan Phoenix |
| 21:44:52 | BrianRice-work | just to reduce GC pauses? |
| 21:46:09 | evan | BrianRice-work: i guess so? |
| 21:46:24 | evan | not much is known (not in japanese at least) |
| 21:49:10 | BrianRice-work | ok. just seems like too specific a product |
| 21:56:02 | boyscout | CI: rubinius: a2470f3 successful: 3457 files, 13665 examples, 41242 expectations, 0 failures, 0 errors |
| 23:43:38 | toulmean | evan: are you recording the webinar ? curious, it looks like it was not tweeted by engineyard or rubinius |
| 23:43:44 | evan | yep |
| 23:44:51 | evan | it will be recorded |
| 23:44:55 | evan | i need to tweet it was rubinius |
| 23:45:28 | toulmean | evan: thx. |
| 23:49:45 | brixen | evan: you could get kinda verbose with StaticCall.blah a, b |
| 23:50:04 | brixen | codesearch doesn't find any "class StaticCall" in Ruby code |
| 23:51:53 | evan | who is the reciever? a? |
| 23:55:17 | brixen | hmm |
| 23:55:35 | brixen | I guess in that form it would have to be |
| 23:56:17 | evan | I worked around it |
| 23:56:21 | evan | in a very verbose way |
| 23:56:29 | evan | basically, i'm getting rid of the copy_object methad |
| 23:56:31 | evan | method |
| 23:56:36 | evan | and having dup/clone invoke the prim directly |
| 23:56:43 | evan | now that we have .invoke_primitive |
| 23:56:54 | brixen | that's totally reasonable for those cases |
| 23:57:01 | brixen | I thought you meant as a generic extension |
| 23:57:07 | evan | I did |
| 23:57:10 | evan | i was just musing. |
| 23:57:12 | brixen | ok |