Show enters and exits. Hide enters and exits.
| 00:10:24 | joqueonr | hi all |
| 00:10:44 | joqueonr | I am having some trouble install rubinius with rvm on OS X 10.6 |
| 00:11:03 | Sutto | joqueonr: not on the rubinius side, but on the rvm side - have you got a log? |
| 00:11:25 | joqueonr | yeah |
| 00:12:01 | Sutto | is it to do with it not being able to find rake? |
| 00:12:07 | joqueonr | error: Error running '/Users/joque/.rvm/bin/ruby-1.8.7-p174 -S rake install' |
| 00:12:10 | joqueonr | error mesage |
| 00:12:16 | joqueonr | part of the log says |
| 00:12:53 | joqueonr | I think so |
| 00:13:43 | joqueonr | well I got this at the tail of rake.error.log |
| 00:13:45 | joqueonr | i686-apple-darwin10-g++-4.2.1: invalid version number `' |
| 00:13:46 | joqueonr | make[3]: *** [/Users/joque/.rvm/src/rbx-1.0.1-20100603/vm/external_libs/llvm/Release/lib/LLVMHello.dylib] Error 1 |
| 00:13:59 | Sutto | could you gist the whole log? |
| 00:14:05 | joqueonr | ok |
| 00:18:03 | joqueonr | there you go |
| 00:18:05 | joqueonr | https://gist.github.com/feff783842c905a88ff5 |
| 00:19:52 | Sutto | any chance you can also gist rvm info? |
| 00:19:59 | Sutto | it's a different bug to what I was expecting |
| 00:22:07 | joqueonr | https://gist.github.com/d045a2b56db5325c8a35 |
| 00:23:24 | Sutto | joqueonr: only thing I can think of at the moment is rm ~/.rvm/src/rbx-* ~/.rvm/archives/rubinius-*; rvm update --head; rvm reload; rvm install rbx |
| 00:23:51 | joqueonr | ok |
| 00:23:54 | joqueonr | let me try it |
| 00:36:56 | joqueonr | Nope |
| 00:37:00 | joqueonr | didn't work |
| 00:37:09 | joqueonr | trying to reinstall rake and see |
| 00:38:24 | Sutto | doesn't look like a rake issue, looks like an issue with your system |
| 00:38:38 | Sutto | joqueonr: oh, looking again - what does which sed show? |
| 00:40:33 | Sutto | looks like it's trying to call a wrong sed (the default osx sed on my system supports -E) |
| 00:42:02 | joqueonr | do you mean -e? |
| 00:42:23 | Sutto | no, -E |
| 00:42:31 | Sutto | which is in the log |
| 00:42:55 | Sutto | it's /usr/bin/sed for me + -E turns on extended regexps |
| 00:43:13 | joqueonr | let me check my path |
| 00:43:18 | joqueonr | but it should be fine |
| 00:48:30 | joqueonr | changed the path to /usr/bin/sed |
| 00:48:36 | joqueonr | will try again and see |
| 01:03:00 | joqueonr | Now it went through |
| 01:03:10 | joqueonr | thank a lot |
| 01:07:02 | Sutto | np |
| 13:11:18 | goyox86 | Hi all! |
| 13:17:40 | dbussink | g'day |
| 13:46:06 | cremes | evan: i want to drop you a private email about fixing up my git privileges; should i use the fallingsnow addr? |
| 14:54:36 | dbussink | cremes: all code is on github, fallowsnow is not used |
| 14:55:57 | cremes | dbussink: i think you misinterpreted my message; i want to send evan a private email and want to use the right address |
| 14:56:01 | cremes | has nothing to do with code |
| 14:58:37 | dbussink | cremes: ah ok, sorry :) |
| 14:58:59 | dbussink | cremes: you can check the ml to see what he uses |
| 14:59:21 | cremes | np; i just discovered i have two github accounts (cremes & chuckremes); all of my projects are under the chuckremes account but my |
| 14:59:33 | cremes | rbx commit privileges are attached to the cremes account that i want to delete |
| 14:59:37 | cremes | it's a tiny mess |
| 15:00:10 | cremes | once i get it worked out i am hoping to be a bit more active in contributing |
| 15:10:35 | dbussink | cremes: ah, changing nicks is usually a hairy business :: |
| 15:10:36 | dbussink | :P |
| 16:32:30 | evan | rad new optimization |
| 16:33:02 | evan | Hash#each when inlined with the block avoids creating the array the key, value are in |
| 16:48:29 | dbussink | evan: cool :) |
| 16:49:10 | dbussink | evan: hand crafted optimization? |
| 16:49:22 | evan | on this Hash#each benchmark, rbx is 1.6s, MRI is 7.1s |
| 16:49:25 | evan | yeah |
| 16:49:33 | dbussink | evan: what was rbx before |
| 16:49:33 | dbussink | ? |
| 16:49:34 | evan | i'm detecting this case in the bytecode |
| 16:49:46 | evan | i've done a bunch of optimizations |
| 16:49:49 | evan | lets see on 1.0.1 |
| 16:50:01 | dbussink | i can run it here on latest master |
| 16:50:06 | dbussink | if you have the bench |
| 16:50:14 | evan | on 1.0.1, no block inlining, it's 13s |
| 16:50:31 | evan | so 13s is what people would see now |
| 16:50:39 | evan | and it's going to bump down to 1.6s |
| 16:50:40 | evan | :D |
| 16:50:58 | evan | with jit.inline.blocks on in 1.0.1, it's 12s |
| 16:51:04 | evan | because i've been tuning inline blocks |
| 16:51:09 | evan | it works quite a bit better now. |
| 16:51:17 | dbussink | awesome stuff :) |
| 16:51:30 | dbussink | i'll run it on datamapper too then :P |
| 16:54:34 | dbussink | evan: any other area's that would benefit from the optimizations? |
| 16:54:39 | dbussink | or pretty hash.each specific? |
| 16:54:49 | evan | oh, it's not specific to Hash#each at all. |
| 16:54:52 | dbussink | dunno if that bytecode recognition is generalizable? |
| 16:55:03 | evan | it's detecting the sequence |
| 16:55:07 | evan | yield [k, v] |
| 16:55:14 | evan | the inside of the array can be anything actually |
| 16:56:14 | evan | i'm testing edge cases now. |
| 16:56:18 | evan | since there are so many with block args. |
| 16:59:08 | dbussink | evan: ah, is adding specs for stuff like this hard? |
| 16:59:15 | evan | yes. |
| 17:02:40 | dbussink | i can imagine yeah :P |
| 17:02:50 | dbussink | but otherwise i can imagine a wild array of obscure bugs |
| 17:03:24 | evan | right |
| 17:03:36 | evan | so i have to be careful with my initial testing. |
| 17:03:45 | evan | much more careful than a normal change |
| 17:07:43 | dbussink | evan: yeah, can imagine |
| 17:08:10 | dbussink | anything you're doing by perhaps triggering the optimization explicitly and then see if it's ok? |
| 17:08:44 | evan | but if i do that |
| 17:08:50 | evan | thats not how it's hit for real |
| 17:08:55 | evan | so i'm fabricating a usage |
| 17:09:10 | evan | the only real way is to run code that should use the optimization |
| 17:09:16 | evan | and see that I get the proper output |
| 17:10:53 | evan | thanks! |
| 17:11:00 | brixen | evan: gotta drop my bike off for maintenance |
| 17:11:05 | evan | k |
| 17:11:07 | brixen | should be back in 30 |
| 17:11:21 | evan | brixen: sounds good. |
| 17:11:26 | brixen | evan: almost have next running ensures |
| 17:11:34 | evan | ok |
| 17:11:37 | brixen | I have a bunch of specs |
| 17:11:48 | evan | k |
| 17:11:48 | brixen | it's a nasty lil beotch |
| 17:12:02 | evan | heh |
| 17:12:17 | brixen | but I really needed to wade through to understand it |
| 17:12:25 | brixen | anyway, bbiab... |
| 17:29:02 | dbussink | evan: i could hammer your changes with a bunch of stuff if you want to :) |
| 17:30:06 | boyscout | Add spec for Array#pack('M') with a multibyte set - 4e39f0a - Dirkjan Bussink |
| 17:30:06 | boyscout | Make sure to encode each byte, since it might be multiple bytes if a multibyte is set - 7874be1 - Dirkjan Bussink |
| 17:38:10 | boyscout | CI: rubinius: 7874be1 successful: 3456 files, 13608 examples, 41172 expectations, 0 failures, 0 errors |
| 17:46:33 | dbussink | evan: that should fix those mail errors |
| 17:46:40 | evan | cool |
| 17:46:45 | evan | go ahead and close the ticket. |
| 17:46:53 | evan | oh wait, the other issue is next/ensure |
| 17:48:37 | dbussink | evan: yeah, brixen is looking at that |
| 18:06:21 | dbussink | evan: btw, if you're looking at yielding arrays, #374 might be interesting too |
| 18:06:21 | evan | it's something else |
| 18:06:21 | evan | but yeah. |
| 18:18:47 | brixen | crosses fingers |
| 18:18:57 | brixen | all the language specs pass with new next behavior |
| 18:19:04 | brixen | running all specs now |
| 18:22:10 | evan | k |
| 18:23:09 | brixen | woop! just the compiler specs barfed |
| 18:23:15 | brixen | which is expected atm |
| 18:25:36 | evan | brixen: i'm waiting to see how you handled tihs |
| 18:26:13 | brixen | I'm sure you are! :) |
| 18:26:21 | brixen | sec, I'll give ya a gist |
| 18:26:27 | evan | k |
| 18:26:29 | brixen | lest you have large worries :P |
| 18:26:45 | evan | :D |
| 18:27:08 | brixen | thinks evan thinks he will randomly break things :P |
| 18:27:16 | evan | nah! |
| 18:27:26 | evan | just curious to see which solution you went for |
| 18:27:36 | brixen | I'm going to try a little refactor on Next |
| 18:27:43 | brixen | and a couple more specs I just thought of |
| 18:27:49 | brixen | well, I handled it much like you do break |
| 18:27:57 | brixen | since it's the same kind of deal |
| 18:28:11 | brixen | key point though is slightly adjusting how the body of a loop is emitted |
| 18:28:55 | brixen | the loop needs to have a post that next jumps to, instead of jumping to the "top" directly |
| 18:29:08 | brixen | at least, this is the only way I could get the stack to balance |
| 18:29:19 | brixen | but first, a couple more spec cases... |
| 18:29:52 | evan | yeah |
| 18:29:55 | evan | thats the way to handle that. |
| 18:30:02 | evan | did you use lazy labels? |
| 18:30:06 | brixen | yes! :) |
| 18:30:13 | brixen | they are da bomb |
| 18:30:20 | evan | yeah |
| 18:31:03 | evan | they let us basically do use based peephole optimization |
| 18:31:21 | brixen | ahh yeah |
| 18:50:03 | evan | spastorino: ? |
| 18:51:20 | dbussink | brixen: btw, i pushed a spec for that kcode / pack interaction, if you want to shoot at it, please go ahead :) |
| 18:52:00 | brixen | dbussink: you mean critique it? |
| 18:52:59 | dbussink | brixen: yeah |
| 18:53:17 | brixen | dbussink: ok, I'll take a look |
| 18:53:23 | brixen | dbussink: thanks for working on it |
| 18:53:56 | wycats | spastorino, evan: hello |
| 18:54:09 | spastorino | evan: hi |
| 18:54:11 | dbussink | brixen: np, working on some totally different things is good for getting my mind in shape ;) |
| 18:54:22 | brixen | dbussink: heh, indeed :) |
| 18:54:22 | evan | wycats: hello. |
| 18:54:30 | brixen | spastorino: hi! |
| 18:54:36 | brixen | wycats: hello! |
| 18:54:37 | wycats | spastorino: how many rbx fails are you seeing on Rails 3 master? |
| 18:54:38 | spastorino | brixen: hi!! |
| 18:54:48 | spastorino | let me do a pastie |
| 18:55:09 | spastorino | i'm using rbx 1.0.1 |
| 18:55:10 | wycats | spastorino's vaio is our CI box :( |
| 18:55:18 | spastorino | hahahaha |
| 18:56:59 | spastorino | http://gist.github.com/451865 |
| 18:57:24 | spastorino | <" class=\"fancy\" onclick=\"alert('Hello World');\""> expected to be == to<" onclick=\"alert('Hello World');\" class=\"fancy\"">. this ones are easy :P |
| 18:57:34 | dbussink | spastorino: has ordering dependency :) |
| 18:57:42 | spastorino | yeah |
| 18:57:53 | evan | yeah |
| 18:57:54 | evan | thats easy |
| 18:57:54 | dbussink | guess there are also some mixups for GMT / UTC as TZ names |
| 18:57:56 | evan | thats a testing bug. |
| 18:58:00 | dbussink | that should be easy too |
| 18:58:05 | dbussink | or is there something tricky behind that? |
| 18:58:53 | evan | someone needs to just pull that code out |
| 18:58:58 | evan | and see what rails is doing with it |
| 18:59:05 | evan | i'm betting it's just a missed case of preserving the timezone |
| 18:59:14 | evan | actually, not even |
| 18:59:17 | evan | since UTC == GMT |
| 18:59:21 | evan | it's just a naming issue. |
| 19:00:48 | spastorino | i will be out for a bit guys, i will read later and try fixes and run my CI again :P |
| 19:00:54 | spastorino | seeya |
| 19:01:20 | dbussink | evan: probably just silly naming yeah |
| 19:01:43 | wycats | evan: it would be great if we could say the RC was 100% green on rbx |
| 19:01:43 | evan | spastorino: bye. |
| 19:01:47 | evan | sure |
| 19:01:50 | evan | i'm sure thats doable. |
| 19:02:42 | wycats | we're a short bit of time away from RC :) |
| 19:02:44 | dbussink | cool to see people are more and more doing it |
| 19:03:04 | dbussink | it's part of our release / test process for datamapper too already :) |
| 19:04:04 | wycats | :-D |
| 19:04:11 | wycats | dbussink: if we get solid CI going, we'll put rbx on it |
| 19:04:21 | dbussink | wycats: that's a rubysoc right? |
| 19:04:23 | wycats | anyone who commits to 100% green on Rails is good in my book |
| 19:04:35 | wycats | unfortunately, rbx is the only alternate impl currently dedicated to that :( |
| 19:04:50 | wycats | nicksieger: fix that plz? |
| 19:04:50 | wycats | :P |
| 19:05:28 | nicksieger | wycats: so http://ci.jruby.org/view/Rails/ does not constitute a commitment? |
| 19:05:43 | wycats | nicksieger: just get green |
| 19:05:47 | wycats | and commit to staying green :( |
| 19:06:03 | wycats | nicksieger: I don't like seeing slides where IronRuby and JRuby are like "omg only 10 fails" |
| 19:06:05 | wycats | it makes me sad :( |
| 19:06:30 | wycats | nicksieger: I know you guys are trying... don't mean to start something here |
| 19:36:05 | evan | brixen: i'm ready to push a bunch of stuff |
| 19:36:10 | evan | but i'll wait for you |
| 19:36:14 | evan | sounds like you're almost done. |
| 19:36:32 | evan | i'm going to grab some lunchified food stuffs. |
| 19:37:00 | brixen | I'm lunching sorta |
| 19:37:07 | brixen | push whenever |
| 19:37:16 | brixen | I'm fixing up the compiler specs |
| 19:38:42 | evan | k |
| 19:42:30 | dbussink | evan: i'm curious :) |
| 19:42:45 | evan | pushing |
| 19:42:48 | boyscout | Convert Hash to use #each_entry instead of #to_iter. @perf - f853b86 - Evan Phoenix |
| 19:42:48 | boyscout | Remove extranious cast_array from bytecode - b5eff27 - Evan Phoenix |
| 19:42:48 | boyscout | Fix -Xjit.profile to provide JIT specific output - 8e6293d - Evan Phoenix |
| 19:42:48 | boyscout | Inline policy work and block inlining optimizations - d65ad57 - Evan Phoenix |
| 19:43:08 | evan | -Xjit.inline.blocks is still off by default |
| 19:43:14 | evan | dbussink: run your specs with it on |
| 19:43:17 | evan | let me know how it odes |
| 19:43:18 | evan | goes |
| 19:43:21 | dbussink | evan: ok, will do :) |
| 19:43:26 | evan | bbiab. |
| 19:54:06 | boyscout | CI: rubinius: d65ad57 successful: 3456 files, 13608 examples, 41172 expectations, 0 failures, 0 errors |
| 20:23:48 | dbussink | evan: ok, looks like i've got a failure |
| 20:24:12 | evan | ok |
| 20:24:31 | dbussink | evan: let me find which commit |
| 20:25:01 | evan | k |
| 20:35:47 | brixen | evan: what time do you get into sf? |
| 20:41:00 | evan | double checking... |
| 20:41:17 | evan | 6:20 |
| 20:42:33 | brixen | ok |
| 20:42:49 | brixen | suss said he has the evening free, so I said we reserve it :) |
| 20:43:14 | brixen | I don't get in till 7:40 though |
| 20:43:23 | brixen | y'all will have to start the party without me |
| 20:45:24 | evan | hah |
| 20:45:25 | evan | ok |
| 20:48:15 | evan | brixen: where's the next/rescue fix? |
| 20:48:16 | evan | :) |
| 20:49:32 | brixen | coming |
| 20:49:39 | brixen | are you blocked on it? |
| 20:50:13 | brixen | I'm cleaning up my commits since I started working on this is the middle of my pack spec work |
| 20:50:57 | brixen | git rb -i being the cat's meow |
| 20:51:40 | evan | no, not blocked. |
| 20:51:42 | evan | just curious! |
| 20:52:31 | evan | dbussink: whats the failure? |
| 20:55:33 | dbussink | evan: ok, it's in the last commit |
| 20:55:39 | evan | ok.. |
| 20:55:41 | evan | whats the failure? |
| 20:55:52 | dbussink | An exception occurred running /Users/dirkjan/Documents/projects/rubinius/gems/1.8/gems/rspec-1.3.0/bin/spec |
| 20:55:52 | dbussink | no method 'zero?' on an instance of Object. (NoMethodError) |
| 20:55:58 | dbussink | the object is 0x45 here |
| 20:56:06 | evan | :/ |
| 20:56:09 | evan | object_id? |
| 20:56:16 | evan | or reference? |
| 20:56:27 | evan | please gist me the whole backtrace |
| 20:57:38 | dbussink | evan: https://gist.github.com/607b1b49286412b1666f |
| 20:59:39 | evan | dbussink: ok |
| 21:00:22 | dbussink | evan: i outputted the object there that was passed into timeout, it showed up as Object 0x45 |
| 21:00:27 | dbussink | inspect that is |
| 21:00:58 | evan | output how? |
| 21:01:05 | evan | le sigh. |
| 21:01:35 | evan | i'm feeling like the little errand boy today |
| 21:03:05 | dbussink | evan: just a "p sec" inside lib/timeout.rb:134 |
| 21:03:12 | dbussink | evan: just very dumb debugging |
| 21:03:13 | evan | ok |
| 21:03:16 | evan | thats all I needed to know. |
| 21:03:26 | evan | the issue is whatever is passing sec to Timeout.timeout |
| 21:03:33 | evan | so I have to figure out the inside of rspec now |
| 21:03:34 | evan | YAY! |
| 21:03:36 | evan | O_o |
| 21:04:05 | dbussink | rspec is such fun! |
| 21:04:22 | dbussink | evan: at least it crashes reliable for me here |
| 21:05:08 | evan | that is good. |
| 21:05:37 | evan | that value comes from optparse |
| 21:06:07 | dbussink | evan: the thing is that that timeout is called all the time and only at a later point it breaks |
| 21:06:28 | evan | right |
| 21:06:33 | evan | i figured as much. |
| 21:08:59 | evan | now, how to get this to pop up... |
| 21:10:46 | dbussink | evan: well, i can give you the steps to repro with the datamapper specs |
| 21:10:50 | dbussink | but that's quite a setup to do |
| 21:11:01 | evan | go ahead |
| 21:11:50 | dbussink | ok, i have 1e5398267798862e4a1b641e66f91d1385b26e8c from datamapper/dm-core on github here now |
| 21:12:25 | dbussink | these are the dependencies: https://gist.github.com/559b07ae814fdda82705 |
| 21:12:43 | dbussink | after those are available, just doing rake spec in the dm-core directory should give the repro |
| 21:14:47 | evan | how were you running with -Xjit.inline.blocks? |
| 21:14:50 | evan | or were you not |
| 21:14:56 | dbussink | evan: nope, no additional options |
| 21:15:01 | evan | fuck me. |
| 21:15:14 | evan | : (: (: (: :( |
| 21:15:21 | dbussink | evan: what is it? |
| 21:15:29 | evan | that means i broke normal operations |
| 21:15:38 | evan | not just block inlining weirdness |
| 21:15:45 | evan | which I hate doing. |
| 21:16:22 | evan | dm-core won't run |
| 21:16:26 | evan | it complains about dm-migrations being missing. |
| 21:16:49 | evan | do I need to have that gem installed? |
| 21:17:06 | evan | and if so, why is that in the gemspec dependencies? |
| 21:17:33 | dbussink | evan: for now just install it |
| 21:17:39 | evan | k, i idd. |
| 21:17:46 | dbussink | evan: shouldn't be needed for in memory specs thoiugh |
| 21:17:48 | dbussink | though |
| 21:18:20 | evan | i just ran "rbx -S rake spec" |
| 21:18:29 | evan | was I supposed to run them a different way? |
| 21:18:38 | dbussink | that should be ok, it didn't start running stuff? |
| 21:18:46 | evan | it's running now |
| 21:18:48 | dbussink | ah ok |
| 21:19:00 | evan | seriously wtf is with pending specs? |
| 21:19:00 | dbussink | only blows up after a while for me here |
| 21:19:09 | evan | why do people write them? |
| 21:19:28 | dbussink | mainly because there are a lot of shared specs that are run against different constructs |
| 21:19:37 | dbussink | and m:n relations don't support everything (yet) |
| 21:24:23 | dbussink | evan: any failures for you yet? |
| 21:24:33 | evan | yeah |
| 21:24:34 | evan | i see it |
| 21:24:36 | evan | at the very end. |
| 21:24:43 | evan | going to be a bitch to iterate on. |
| 21:24:57 | dbussink | well, it's not done yet at that moment even (at least not when it crashes here) |
| 21:25:06 | dbussink | but i can imagine that it's a really annoying one |
| 21:25:14 | dbussink | good case for the new debugger? ;) |
| 21:25:48 | evan | not really |
| 21:25:57 | evan | if it's a JIT bug, then the debugger will defeat the JIT. |
| 21:26:10 | evan | running with -Xint to make sure it's a JIT bug. |
| 21:27:32 | dbussink | evan: ok, i'm going to head to bed now though |
| 21:27:36 | dbussink | evan: you need anything more? |
| 21:27:41 | dbussink | besides this torture test? :P |
| 21:27:55 | evan | nope |
| 21:27:55 | evan | nite. |
| 22:38:31 | fr0ste | is it possible to compile rubinius on windows? |
| 22:39:52 | evan | not at the moment, no |
| 22:40:11 | evan | but i'd be happy to get some help from a windows dev on that front |
| 22:47:45 | fr0ste | has anything been started or documented on what it might take to get it to build on windows? |
| 23:09:19 | evan | fr0ste: there has been some work |
| 23:09:34 | evan | I need to fix loading symbols from the current process |
| 23:16:40 | boyscout | Guard for returning undef from a packed object - 1e4bff0 - Evan Phoenix |
| 23:25:00 | boyscout | CI: rubinius: 1e4bff0 successful: 3456 files, 13608 examples, 41172 expectations, 0 failures, 0 errors |
| 23:35:12 | boyscout | Benchmarks for #pack('C<N>'). - e636024 - Brian Ford |
| 23:35:12 | boyscout | Enable passing arguments via be_computed_by matcher. - 88d2c4a - Brian Ford |
| 23:35:12 | boyscout | Begin fixing Array#pack specs. - 73296f3 - Brian Ford |
| 23:35:12 | boyscout | Specs for next running ensure blocks. - 44bd014 - Brian Ford |
| 23:35:12 | boyscout | Fixed next running ensures. - 4808eb1 - Brian Ford |
| 23:35:34 | brixen | evan: there ya go! check it :) |
| 23:35:57 | evan | :) |
| 23:36:09 | evan | Just added ObjectSpace.find_references |
| 23:36:15 | brixen | sweet |
| 23:36:30 | evan | a memory leak you say? we've got tools for that! |
| 23:36:50 | brixen | nice! |
| 23:37:54 | brixen | we should do a series of screen casts in the "there's an app for that" style of commercial |
| 23:38:06 | evan | :D |
| 23:38:09 | brixen | but has to have really good music! :) |
| 23:38:22 | brixen | cus that's what makes those commercials |
| 23:38:29 | brixen | compare M$ Zune commercials |
| 23:38:32 | brixen | <eye roll> |
| 23:38:54 | evan | ok, so you moved where check_interrupts is checked? |
| 23:39:01 | brixen | yeah |
| 23:39:13 | brixen | but it should be the same |
| 23:39:16 | evan | k |
| 23:39:17 | brixen | functionally |
| 23:39:20 | brixen | double check it |
| 23:39:23 | evan | so long as we're doing it once per loop. |
| 23:39:28 | evan | i will in a sec |
| 23:39:28 | brixen | I didn't have to change any specs for it |
| 23:39:31 | evan | going through the diff atm. |
| 23:39:36 | evan | ok |
| 23:39:37 | brixen | yeah, diffs are hard |
| 23:39:56 | brixen | you can just read class Next, class While, and class Ensure in lib/compiler/ast |
| 23:40:19 | brixen | to me, it makes much more sense to have check_interrupts an integral part of loop |
| 23:40:25 | brixen | rather than in multiple places |
| 23:40:34 | brixen | but that was a refactor |
| 23:40:36 | evan | yeah, i am.. |
| 23:40:46 | brixen | the next fix is independent of that |
| 23:40:54 | evan | i'm curious who is consuming the stack value next puts on the stack in the loop case |
| 23:41:07 | evan | oh, you put the post before a pop |
| 23:41:12 | brixen | the loop body |
| 23:41:15 | brixen | yeah |
| 23:41:15 | evan | so you're jump to the bottom of the loop body |
| 23:41:21 | evan | which pops, checks interrupts, and goes on. |
| 23:41:22 | evan | ok |
| 23:41:27 | brixen | yes, to an epilogue as it were |
| 23:41:38 | brixen | that should be computationally idempotent |
| 23:41:45 | evan | yeah |
| 23:41:48 | evan | thats no biggy. |
| 23:41:54 | brixen | the problem otherwise is nested ensures |
| 23:42:01 | brixen | they will make you curse |
| 23:42:04 | brixen | repeatedly |
| 23:42:39 | brixen | note the specs for this bitch^W next w/ ensure thing |
| 23:43:41 | evan | ok, looks good |
| 23:43:45 | brixen | sweet! |
| 23:43:50 | brixen | passes the specs too :D |
| 23:43:56 | evan | yeah, you just had to get the lazy local jump from the ensure to work right |
| 23:43:57 | evan | stack wise |
| 23:43:58 | evan | I suspect. |
| 23:44:32 | brixen | yep |
| 23:44:40 | boyscout | CI: rubinius: a7e8b4b successful: 3457 files, 13653 examples, 41219 expectations, 0 failures, 0 errors |
| 23:44:47 | brixen | that was the key, rearranging how the body of the loop was emitted |
| 23:44:59 | brixen | by body, I mean @body.bytecode(g); g.pop |
| 23:45:15 | evan | yay for having our bytecode compiler in ruby |
| 23:45:21 | brixen | that little g.pop cause me a few hours of joy yesterday |
| 23:45:22 | evan | that has paid off so many times |
| 23:45:23 | evan | i can't count. |
| 23:45:26 | brixen | yep! |
| 23:45:28 | brixen | soo nice |
| 23:45:37 | evan | aah |
| 23:45:45 | evan | we were blindly poping the body, gotcha. |
| 23:45:49 | brixen | yeah |
| 23:46:00 | evan | and yay again for stack locals! |
| 23:46:06 | brixen | oh man, so nice |
| 23:46:12 | evan | so nice to have some state in a method that isn't stack location bound. |
| 23:46:16 | brixen | yep |
| 23:46:29 | brixen | I was pondering a way to abstract the pattern into a utility method in generator |
| 23:46:40 | brixen | utility method/construct |
| 23:46:48 | brixen | but anyway, they are so useful |
| 23:47:58 | evan | we'll figure out a good abstraction eventually |
| 23:48:05 | brixen | sure |
| 23:48:26 | evan | an object for it might be nice |
| 23:48:26 | evan | actually |
| 23:48:38 | evan | sl = g.stack_local "foo" |
| 23:48:45 | evan | you can then do |
| 23:48:50 | evan | sl.push |
| 23:48:57 | evan | and sl.set |
| 23:49:10 | brixen | yeah, nice |
| 23:49:20 | evan | it can either capture it's g |
| 23:49:25 | evan | or require it to be passed in |
| 23:49:56 | brixen | yeah, either works pretty good |
| 23:50:03 | brixen | we capture with labels, which works nice |
| 23:50:09 | evan | yeah |
| 23:50:39 | brixen | so, another thing about the bytecode compiler that I like, it's simple |
| 23:50:54 | brixen | the JIT does all the weird stuff |
| 23:50:56 | evan | ok, so you leave next's argument on the stack the whole time while the ensure code runs |
| 23:51:09 | brixen | so you have a rather pristine IR in a sense |
| 23:51:16 | evan | oh yeah, totally. |
| 23:51:41 | brixen | yeah, I left the arg on there |
| 23:51:47 | brixen | I suppose we could pop it |
| 23:52:29 | brixen | basically ensures next has a value just like any loop body |
| 23:52:54 | brixen | s/ensures/makes sure/ to avoid confusion :) |
| 23:53:40 | evan | there is a funny sequence i'm trying to figure out why it happens |
| 23:54:07 | evan | compile http://gist.github.com/456569 |
| 23:54:22 | evan | check out instructions 50 and 52 |
| 23:54:27 | brixen | k |
| 23:54:38 | evan | I think it's fine |
| 23:54:43 | evan | just tracking it mentally. |
| 23:56:08 | brixen | hm |
| 23:56:37 | evan | thats the bottom of 'if check_next' in exceptions.rb on line 154 |
| 23:56:48 | evan | merging with the bottom of body_bytecode |
| 23:57:03 | evan | i'm trying to work out a case where they don't always go the same place |
| 23:58:51 | brixen | hm yeah |