Show enters and exits. Hide enters and exits.
| 01:17:29 | brixen | ok, exception on -rprofile -e is because we've got a block env with a nil name somewhere |
| 01:17:50 | evan | ok |
| 01:17:50 | brixen | and we need something more sophisticated than return nil unless @locations |
| 01:17:55 | evan | maybe a for look |
| 01:17:56 | evan | loop |
| 01:17:58 | evan | or someting |
| 01:18:03 | evan | the name on a block env is pretty useless |
| 01:18:16 | brixen | since that gets e.backtrace.show -> no method show on nil |
| 01:18:32 | evan | hm. ok. |
| 01:18:38 | brixen | I've got a check in the profiler results so nil BE names don't cause an exception |
| 01:18:51 | brixen | it's Object#<nil> {} |
| 01:18:59 | brixen | so, top level block env? |
| 01:19:01 | evan | well |
| 01:19:07 | evan | that name shouldn't be used |
| 01:19:12 | brixen | k |
| 01:19:17 | brixen | what should I use? |
| 01:19:20 | evan | where are you checking? |
| 01:19:22 | evan | i wanna see |
| 01:19:26 | evan | so we're talkinga bout the same thing |
| 01:19:31 | brixen | sec.. |
| 01:20:21 | brixen | vm/instruments/profiler.cpp:71 is where it was hitting the nil name |
| 01:20:39 | brixen | blockenvironment.cpp:71 was were it was calling the profiler |
| 01:21:07 | brixen | builtin/block_environment.cpp |
| 01:21:15 | brixen | well 79 |
| 01:21:53 | evan | yeah |
| 01:21:59 | brixen | I'm inserting the "<nil>" for the method name |
| 01:22:00 | evan | the name of method_ is meaningless |
| 01:22:03 | evan | you shouldn't use it. |
| 01:22:10 | brixen | what should it be? |
| 01:22:19 | evan | it should be the name of the method that created the block |
| 01:22:51 | evan | which would be |
| 01:22:55 | evan | top_scope_->method() |
| 01:22:58 | evan | in there |
| 01:23:00 | rue | Should really just set stuff in the constructors and worry about optimising it later |
| 01:23:01 | brixen | k |
| 01:23:04 | evan | top_scope_->method()->name() |
| 01:23:28 | brixen | evan: in all the BE::call_xx to profiler? |
| 01:23:37 | rue | And probably change method_ to defined_in_ if that is the case (defined, not called from, right?) |
| 01:24:15 | evan | brixen: likely, yes. |
| 01:24:23 | evan | rue: no |
| 01:24:25 | evan | it's method_ |
| 01:24:49 | evan | just happens that BE uses it to know what method it was defined in |
| 01:29:01 | rue | I am not sure I follow that explanation |
| 01:33:53 | brixen | evan: why is frame->name set to name_ in those BE calls? |
| 01:34:08 | evan | for completeness |
| 01:34:15 | evan | could be just nil |
| 01:34:16 | brixen | k |
| 01:34:50 | brixen | well, I'm confused about it |
| 01:35:00 | brixen | since changing this gives mostly the same results |
| 01:35:06 | brixen | except for that one block |
| 01:35:14 | brixen | which had a nil name |
| 01:35:54 | evan | right |
| 01:35:56 | evan | thats what you should get |
| 01:36:01 | evan | i don't know what your asking. |
| 01:36:50 | brixen | it was using name_ before, so why was name_ mostly the same as top_scope_->method()->name()? |
| 01:37:20 | evan | i guess the compiler was setting the name field of CompiledMethods for blocks correctly |
| 01:37:25 | evan | but something is missing one |
| 01:37:39 | evan | correctly == the name of the method the block as defined in |
| 01:37:43 | brixen | ok |
| 01:37:46 | brixen | should it be fixed? |
| 01:37:49 | evan | yes. |
| 01:38:07 | evan | i actually want to refactor CompiledMethod into CodeBlock or something |
| 01:38:10 | evan | that doesn't have an ame |
| 01:38:12 | evan | a name |
| 01:38:15 | brixen | ok |
| 01:38:24 | evan | and blocks will reference CodeBlocks instead of CompiledMethods |
| 01:38:50 | evan | but the long and short is that the name field on a CompiledMethod used for a block is useless. |
| 01:39:45 | brixen | ok, this is where I'm confused |
| 01:39:54 | brixen | I was using the name_ field on a BE |
| 01:40:05 | brixen | not the method_ |
| 01:40:37 | evan | ok |
| 01:40:40 | evan | well |
| 01:40:44 | evan | check how be->name is set |
| 01:40:52 | evan | it's set to call_frame->name |
| 01:41:30 | evan | why do we have a name_ on BE anyway... |
| 01:41:36 | brixen | heh |
| 01:41:42 | evan | there is no reason to |
| 01:41:43 | brixen | that's what I'm wondering |
| 01:41:50 | evan | get rid of it. |
| 01:41:59 | brixen | k |
| 01:56:58 | brixen | evan: could you help me track this down? |
| 01:56:59 | brixen | http://gist.github.com/95524 |
| 01:57:14 | brixen | top_scope_->method()->name() is nil |
| 01:57:31 | evan | hrm. |
| 01:58:00 | brixen | so, I'm looking at fileutils.rb 1533 |
| 01:58:04 | evan | add that same assert to under_call_frame |
| 01:58:12 | brixen | k |
| 01:58:17 | evan | then it will blow up creating the Be |
| 01:58:21 | evan | rather than calling |
| 01:58:28 | evan | then you can figure out where it's at |
| 01:58:48 | brixen | ok |
| 02:05:33 | brixen | well, appears to be the block at fileutils.rb 1534 |
| 02:05:49 | brixen | inside class << self |
| 02:06:45 | brixen | so that should be __metaclass_init__ right? |
| 02:06:54 | evan | hrm |
| 02:07:06 | evan | i'll bet we aren't setting the name |
| 02:07:09 | evan | yeah |
| 02:07:13 | evan | thats a fine name. |
| 02:19:22 | brixen | how the hell does __metaclass_init__ get into the call_frame->name if it's not in the CM |
| 02:19:29 | brixen | I need diagrams :/ |
| 02:22:54 | evan | if whats not a CM? |
| 02:23:21 | brixen | sec.. |
| 02:24:07 | brixen | http://pastie.org/446845 |
| 02:25:13 | brixen | previous frame is __module_init__ |
| 02:25:18 | evan | oh |
| 02:25:19 | evan | hehe |
| 02:25:22 | evan | thats the name it's called AS |
| 02:25:36 | evan | it just doesn't know what to call itself |
| 02:25:51 | evan | call_frame->name is supposed to be the name it was called as |
| 02:25:59 | evan | thats how we show aliased methods |
| 02:26:04 | brixen | ok |
| 02:26:07 | evan | when call_frame->name is different than method->name |
| 02:26:15 | brixen | so I'm looking at SClass#bytecode |
| 02:26:42 | evan | so |
| 02:26:49 | evan | on line 566 |
| 02:26:54 | evan | do |
| 02:26:56 | evan | meth.name = name |
| 02:27:37 | brixen | k |
| 02:27:48 | brixen | I finally got a profile from a spec run |
| 02:28:04 | brixen | it's really long |
| 02:28:34 | brixen | all the mocks |
| 02:29:00 | evan | cool! |
| 07:01:48 | evan | brixen: you around? |
| 07:02:00 | brixen | yep |
| 07:02:24 | evan | brixen: ever seen ruby_strtod crash? |
| 07:02:31 | evan | i'm trying to get some new jit code patched in |
| 07:02:34 | evan | and it's not running yet |
| 07:02:46 | evan | but suddenly ruby_strtod is crashing |
| 07:02:52 | evan | and I can't figure out why |
| 07:02:59 | brixen | hm, I haven't seen it crash |
| 07:03:11 | brixen | what's the ruby code look like? |
| 07:03:37 | evan | one sec |
| 07:04:02 | evan | http://gist.github.com/95640 |
| 07:05:11 | brixen | hrm that is odd |
| 07:05:56 | evan | i've been trying to step through it |
| 07:05:59 | evan | figure out what happened |
| 07:06:02 | evan | no luck so far |
| 07:07:12 | brixen | I wonder if it is bstring and not strtod |
| 07:07:34 | brixen | I would trust strtod more |
| 07:08:26 | evan | hm. |
| 07:08:27 | evan | well |
| 07:08:32 | evan | the string input seems fine |
| 07:08:39 | evan | it's null terminated. |
| 07:09:04 | evan | the only other argument is a char** rest |
| 07:52:38 | brixen | the top part of a profile run of the specs, sorted by self seconds, calls |
| 07:52:39 | brixen | http://gist.github.com/95653 |
| 07:56:55 | evan | wowzers |
| 07:56:56 | evan | thats awesome! |
| 07:57:10 | evan | lets us know EXACTLY where to spend time |
| 07:58:07 | evan | thats pretty crazy |
| 07:58:11 | evan | how much time Array#each takes up |
| 07:58:22 | brixen | yeah |
| 07:58:40 | brixen | over 8sec in sydney_rewriter too |
| 07:58:45 | brixen | I'll be glad to gut that |
| 07:59:00 | evan | was that a cold run? |
| 07:59:01 | brixen | how's that Hash#[] for ya :) |
| 07:59:03 | brixen | yeah |
| 07:59:06 | brixen | compiling |
| 07:59:11 | evan | do a compiled run |
| 07:59:16 | evan | to compare and contrast |
| 07:59:18 | evan | oh oh |
| 07:59:20 | brixen | yeah |
| 07:59:22 | evan | I completely forgot to tell ya! |
| 07:59:27 | evan | i wrote a cuckoo hash impl |
| 07:59:30 | evan | in both ruby and C++ |
| 07:59:32 | evan | for us to use |
| 07:59:35 | brixen | cool! |
| 08:00:15 | evan | whats Buffer#fill? |
| 08:00:20 | evan | oh, thats IO::Buffer#fill |
| 08:00:27 | evan | reading all the files |
| 08:00:29 | evan | to compile them |
| 08:00:34 | brixen | yeah |
| 08:00:43 | evan | looks like the name of that class is wrong |
| 08:00:45 | evan | need to fix that |
| 08:01:09 | evan | wow, the stack depth calculator took 6s |
| 08:01:13 | evan | thats crazytown |
| 08:01:17 | brixen | yeah |
| 08:01:26 | brixen | great idea on sorting btw |
| 08:01:31 | evan | yeah |
| 08:01:35 | evan | this is some AWESOME info |
| 08:01:42 | evan | it's a fucking gold mine |
| 08:01:47 | evan | now as i'm working on the JIT |
| 08:01:53 | brixen | cool |
| 08:01:55 | evan | i know what methods to make fast first! |
| 08:02:04 | brixen | it profiles capi and ffi calls too |
| 08:02:27 | evan | who's the man? |
| 08:02:30 | evan | points to brixen |
| 08:02:31 | evan | :D |
| 08:02:32 | evan | brb |
| 08:02:33 | brixen | hah you are |
| 08:06:01 | brixen | evan: btw, that profile run was with a debug build |
| 08:12:40 | boyscout | Added :sort option to profiler. - e763463 - Brian Ford |
| 08:12:40 | boyscout | Added custom --profile option for mspec. - d9c3af1 - Brian Ford |
| 08:12:40 | boyscout | Added with_profiler guard for specs. - a1c57bc - Brian Ford |
| 08:12:40 | boyscout | Pass the correct name to enter_block. - bea4cdc - Brian Ford |
| 08:12:40 | boyscout | Ensure a CompiledMethod has a name. - 32d67fd - Brian Ford |
| 08:15:38 | evan | brixen: ah, ok. |
| 08:19:37 | brixen | http://gist.github.com/95665 |
| 08:19:43 | brixen | normal build |
| 08:19:50 | brixen | compiling at the top |
| 08:21:27 | boyscout | CI: 32d67fd success. 1502 files, 7234 examples, 23646 expectations, 0 failures, 0 errors |
| 08:21:37 | brixen | finally |
| 08:21:46 | brixen | need to feed boyscout some wheaties |
| 08:22:27 | brixen | sleeps |
| 08:22:49 | evan | nite |
| 08:23:28 | brixen | nite |
| 09:14:56 | rue | Morning |
| 15:33:34 | helozjisky | evan: ever tried systemtap with rubinius ? |
| 17:16:54 | evan | morning. |
| 17:17:02 | evan | brixen: i figured out the crash |
| 17:17:05 | evan | it's pretty darn weird. |
| 17:23:21 | rue | Hi |
| 17:23:44 | evan | hello |
| 17:25:05 | helozjisky | evan: ever tried systemtap with rubinius ? |
| 17:25:09 | brixen | evan: what was it? |
| 17:25:11 | evan | whats that? |
| 17:25:14 | evan | helozjisky: whats that? |
| 17:25:22 | evan | brixen: it's pretty fucking weird |
| 17:25:30 | evan | brixen: strtod calls s2b |
| 17:25:48 | helozjisky | dtrace on linux |
| 17:25:55 | evan | which, the header file has externed, and #define'd to a __s2b_D2A |
| 17:26:31 | evan | i think, strangly enough, that llvm's libraries have that same symbol |
| 17:26:38 | brixen | ahh |
| 17:26:40 | evan | so strtod was calling the wrong one |
| 17:26:46 | brixen | whoa |
| 17:26:49 | evan | so i changed the #define to __s2b_rbx_D2A |
| 17:26:52 | evan | and it went away |
| 17:27:11 | brixen | what a crazy symbol to clash |
| 17:27:15 | evan | seriously |
| 17:27:33 | evan | i'm not sure why it's got all it's private functions externed |
| 17:27:41 | evan | i think NOT externing them would fix the problem probably |
| 17:27:50 | brixen | yeah, libgdtoa is some funky code |
| 17:27:52 | evan | maybe not though. |
| 17:27:55 | evan | anyway, it's fixed. |
| 17:27:57 | evan | it's pretty weird. |
| 17:27:59 | brixen | cool |
| 17:28:04 | brixen | nice detective work |
| 17:28:37 | evan | to make it weirder |
| 17:28:43 | evan | i can't find an s2b symbol in llvm |
| 17:28:45 | evan | :/ |
| 17:29:59 | evan | helozjisky: no, no experience, sorry. |
| 17:30:02 | evan | helozjisky: you trying to? |
| 17:30:25 | helozjisky | evan: trying it |
| 17:31:44 | evan | helozjisky: well, if there is anything we can help with, let us know |
| 17:32:12 | helozjisky | evan: thanks, buddy |
| 17:32:53 | helozjisky | evan: have any progress on the document ? |
| 17:33:03 | evan | what document? |
| 17:33:54 | helozjisky | i am new to rubinius, trying reading the documents |
| 17:34:22 | helozjisky | but I think it's still the old version |
| 17:34:33 | evan | whats still the old version? |
| 17:34:59 | helozjisky | shotgun is missing |
| 17:35:29 | evan | there are likely out of date docs, yes. |
| 17:35:40 | helozjisky | this is ok, i can find it in git comments |
| 17:35:54 | evan | what are you looking for? |
| 17:36:40 | helozjisky | can i build with debug option ? |
| 17:36:48 | evan | sure |
| 17:36:51 | evan | rake DEV=1 |
| 17:38:51 | brixen | helozjisky: also rake build:help |
| 17:39:59 | helozjisky | it works |
| 17:40:41 | brixen | helozjisky: if you find stuff in the docs that is incorrect, let us know and I'll update it |
| 17:41:09 | helozjisky | of course |
| 17:41:29 | helozjisky | thanks for your help, I have to go to bed, this is China :) |
| 17:41:36 | brixen | ok |
| 18:12:47 | brixen | evan: so in removing name_ from BE, in BE::call (and variants) frame->name should be top_scope_->method()->name() ? |
| 18:13:15 | evan | or just nil |
| 18:13:21 | brixen | really? |
| 18:13:22 | brixen | ok |
| 18:13:24 | evan | sure |
| 18:31:05 | boyscout | Removed name slot from BlockEnvironment. - e6dad43 - Brian Ford |
| 18:37:00 | boyscout | CI: e6dad43 success. 1502 files, 7234 examples, 23646 expectations, 0 failures, 0 errors |
| 22:48:28 | evan | this... is a weird way to work. |
| 22:49:20 | agardiner | whatcha up to? :-) |
| 22:49:49 | evan | well |
| 22:49:56 | evan | the display on my macbook was being wierd |
| 22:50:06 | evan | and it appears to have finally given up life. |
| 22:50:16 | evan | so i'm using it via screen sharing |
| 22:50:19 | evan | from abby's macbook |
| 22:50:23 | evan | which works surprising well. |
| 22:50:36 | agardiner | oh... neat, i guess |
| 22:50:45 | agardiner | but it sucks that the screen is dead |
| 22:50:52 | agardiner | i recently had to replace mine |
| 22:50:59 | agardiner | after i put a keyboard into it! |
| 22:51:06 | agardiner | :-D |
| 22:51:49 | evan | nice |
| 22:51:53 | evan | hows things btw? |
| 22:51:59 | agardiner | pretty good |
| 22:52:07 | agardiner | getting my life back! |
| 22:52:15 | evan | yay! hows London? |
| 22:52:18 | evan | probably starting to get nice |
| 22:52:19 | agardiner | just started looking at the debugger again |
| 22:52:29 | evan | oh cool. |
| 22:52:31 | agardiner | yeah, we had a nice easter |
| 22:52:38 | agardiner | good weather, surprisingly |
| 22:52:45 | evan | i think we should discuss how stepping-into-a-method should work |
| 22:52:57 | agardiner | yeah, that's high on my list |
| 22:53:09 | agardiner | but there's a lot to be done :-( |
| 22:53:14 | evan | yeah |
| 22:53:21 | agardiner | sadly, much has changed and no longer workds |
| 22:53:26 | evan | yeah |
| 22:53:37 | evan | you saw that I got basic breakpoints and next working though, yes? |
| 22:54:11 | agardiner | i saw that you had got it working... |
| 22:54:17 | agardiner | but not clear on the specific |
| 22:55:01 | agardiner | this was after the stackfull changes right? |
| 22:55:21 | drbrain | RubyGems 1.3.2 is out |
| 22:56:00 | evan | agardiner: yeah |
| 22:56:07 | evan | agardiner: i did this.. oh, 2 weeks ago |
| 22:56:08 | evan | or so. |
| 22:57:47 | evan | drbrain: alrighty. probably should sync it in soon then. |
| 22:58:02 | evan | hopefully i'll get to it tomorrow |
| 22:58:34 | drbrain | lots of bug fixes |
| 22:58:35 | slava | hi evan |
| 22:58:43 | evan | drbrain: awesome. |
| 22:58:45 | evan | slava: allo |
| 23:00:54 | agardiner | evan: how does the lines tuple work now in CM? |
| 23:01:03 | evan | it's easier |
| 23:01:19 | evan | it's |
| 23:01:23 | evan | ip, line, ip, line, ip, line |
| 23:01:33 | evan | the line is valid for the the ip extend on either side of it |
| 23:01:48 | agardiner | ah, ok |
| 23:01:54 | agardiner | cool - that is easier |
| 23:02:11 | evan | the algo in ruby and C++ to calculate the line is working |
| 23:02:36 | agardiner | 100%? |
| 23:02:47 | evan | yeah |
| 23:02:51 | agardiner | if i recall, there were some issues way back in some corner cases |
| 23:02:58 | agardiner | neat! |
| 23:03:00 | evan | i haven't seen any troubles with in |
| 23:03:15 | evan | well, i also fixed up how the line table is populated |
| 23:03:19 | evan | it should be a lot more accurate now |
| 23:20:48 | agardiner | hmm |
| 23:21:07 | agardiner | seems like the lines tuple is not totally accurate |
| 23:21:34 | evan | oh? |
| 23:21:46 | agardiner | I'm looking at Kernel#binding |
| 23:22:11 | evan | oh |
| 23:22:15 | agardiner | the source runs from line 35 to 38, but lines only shows line 36-38 |
| 23:22:18 | evan | i'll bet it's not emitting lines for args |
| 23:22:35 | evan | thats going to be a little tricky |
| 23:22:42 | agardiner | line 35 is not the args |
| 23:22:52 | evan | because later ips are actually on earlier lines |
| 23:23:00 | evan | right |
| 23:23:11 | evan | the only line table entry it's outputting is for the call itself |
| 23:23:17 | evan | or rather |
| 23:23:23 | evan | the search is stopping there |
| 23:25:42 | agardiner | it seems the new arrangement can't handle cases where instructions on a single source line end up at multiple ip locations... |
| 23:26:08 | evan | hm |
| 23:27:02 | evan | well, it doesn't use the lines for comparison |
| 23:27:04 | evan | just the ip |
| 23:27:09 | evan | so it should be able to handle it |
| 23:27:23 | evan | in this case |
| 23:27:30 | evan | it might look like |
| 23:28:25 | evan | 0 36 4 37 8 38 12 35 17 |
| 23:28:44 | evan | thats assuming each arg takes 4 args |
| 23:28:51 | evan | and the receiver is 4, plus 1 for ret |
| 23:28:59 | evan | which is totally wrong, but you get the idea |
| 23:30:46 | agardiner | so are the ip fields are inclusive on the left, and exclusive on the right for the line number they surround? |
| 23:31:13 | evan | should be inclusive on the left, exclusive on the right |
| 23:31:53 | agardiner | ok, and it is always in ip ascending order, right? |
| 23:31:59 | evan | yeah |
| 23:32:00 | evan | has to be |
| 23:32:07 | brixen | evan: is lgpl'd code ok to use? |
| 23:32:11 | agardiner | yeah, just wanted to be sure |
| 23:32:13 | evan | for this case, i suspect that the entries are being spit out wrong |
| 23:32:24 | evan | brixen: i think it's case by case |
| 23:32:26 | evan | what do you want to use? |
| 23:32:44 | brixen | was looking at http://www.mpfr.org/ |
| 23:33:16 | evan | to use for what? |
| 23:33:28 | brixen | replace bigdecimal eventually |
| 23:33:49 | evan | doesn't need to be part of rubinius then |
| 23:34:02 | evan | in which case, can be whatever |
| 23:34:02 | brixen | could ffi it, huh |
| 23:34:10 | evan | well, could be a generic extension |
| 23:34:23 | evan | but yes, could FFI it. |
| 23:34:33 | brixen | just a thought |
| 23:34:38 | evan | i've got some ideas on how to make FFI pretty damn fast in the presense of teh JIT |
| 23:34:46 | brixen | cool |
| 23:35:03 | slava | evan: just by generating stubs for every function? |
| 23:35:16 | evan | stubs is part of it, yes. |
| 23:35:18 | evan | for the slow path |
| 23:35:21 | slava | what else? |
| 23:35:48 | evan | but the fast path will move the code to convert the arguments and call out directly into the JIT'd methods machine code stream |
| 23:36:06 | slava | so inlining the FFI stub |
| 23:36:06 | evan | so if the code does |
| 23:36:18 | evan | i = POSIX.atoi("1") |
| 23:36:46 | headius | like john rose's scheme VM |
| 23:36:47 | evan | the JIT will strip away everything, leaving just converting the Ruby string into a char* |
| 23:36:56 | evan | and calling directly to atoi |
| 23:37:05 | evan | and code to convert the int to a Fixnum |
| 23:37:09 | evan | so yeah, inlining the stub |
| 23:37:10 | slava | that's pretty much what factor does |
| 23:37:13 | evan | yep |
| 23:37:15 | evan | i know. |
| 23:37:16 | evan | :D |
| 23:37:23 | slava | I have some more speedups planned |
| 23:37:46 | slava | FFI calls participating in float unboxing is the main one |
| 23:37:56 | slava | and generating all the argument conversion code inline |
| 23:37:58 | evan | ah nice |
| 23:38:16 | slava | do you have callbacks? |
| 23:38:23 | evan | in FFI? not yet. |
| 23:38:28 | evan | but i'm going to add them. |
| 23:46:55 | rue | I wonder if unicorn poop is considered a sustainable construction material |
| 23:47:23 | slava | can I have a toke of what you're smoking, sir? |
| 23:54:02 | rue | hands over unicorn poop |