Show enters and exits. Hide enters and exits.
| 08:40:12 | dbussink | morning ppl |
| 08:42:50 | dwaite | morning! |
| 08:54:05 | dwaite | goes to bed; its 1:53 in the morning here |
| 09:05:26 | dbussink | dwaite: hehe, also morning then :) |
| 11:17:53 | rue | Morning |
| 11:18:16 | dbussink | rue: afternoon :) |
| 17:14:33 | dwaite | good morning |
| 17:18:15 | rue | *wave |
| 17:22:03 | evan | morning. |
| 17:22:15 | evan | it's raining here. |
| 17:22:38 | brixen | hmm, freezing here :) |
| 17:23:04 | brixen | around 22 deg, no precip thankfully |
| 17:24:14 | evan | it's a drizzle really |
| 17:24:49 | evan | put it does call for today to be a Neko Case / Rilo Kiley music day |
| 17:25:06 | brixen | heh |
| 17:30:22 | dwaite | 8 here brix, but not currently snowing |
| 17:31:10 | dwaite | I hope the temp gets above freezing at some point this week :) |
| 18:11:12 | dbussink | evan: http://redmine.ruby-lang.org/issues/show/2454 |
| 18:27:20 | dbussink | evan: good chance to swoop in some cleanups ;) |
| 18:27:27 | evan | yep |
| 18:28:23 | dbussink | evan: what's the main issue you are seeing? |
| 18:28:31 | evan | in? |
| 18:28:42 | dbussink | evan: in your getting openssl to run work |
| 18:28:50 | dbussink | evan: any specifics, or a lot of small things? |
| 18:29:01 | evan | some small things |
| 18:29:09 | evan | and removing all uses of GetOpenFile |
| 18:29:11 | evan | which was easy |
| 18:29:20 | evan | there were only a few places. |
| 18:35:04 | dbussink | evan: ah ok, i see it uses RFILE |
| 18:36:18 | dbussink | evan: btw, i also fixed generating backtraces on os x on a segfault :) |
| 18:36:27 | evan | fixed? |
| 18:36:35 | evan | i wasn't aware it was broken. |
| 18:37:14 | dbussink | evan: you didn't get the backtrace on os x, just on linux |
| 18:37:19 | evan | oh |
| 18:37:20 | dbussink | evan: when not using gdb |
| 18:37:21 | evan | don't commit that. |
| 18:37:38 | dbussink | evan: oh, what's the issue with that then? |
| 18:37:41 | evan | unless you also check that crashreporter is enabled |
| 18:37:51 | dbussink | evan: this is the change: http://github.com/evanphx/rubinius/commit/8a21d5032b2dbdd83f621bfeb85eba30367457ec |
| 18:37:52 | evan | i didn't do that because if you catch SIGSEGV or SIGBUS |
| 18:37:58 | evan | then crashreporter doesn't fire |
| 18:37:59 | evan | ok |
| 18:38:02 | evan | going to have to remove it |
| 18:38:07 | evan | or make it conditoinal in some way |
| 18:38:22 | dbussink | evan: ah ok, when does crashreporter fire then? since i've never seen that launch actually |
| 18:38:35 | evan | go into crashreporterpref |
| 18:38:41 | evan | and you can enable developer mode |
| 18:38:51 | evan | so it fires when a command line program crashes |
| 18:38:54 | evan | which is what I do. |
| 18:40:01 | dbussink | evan: ah ok, you installed a preference pane for that? |
| 18:40:09 | evan | no |
| 18:40:10 | evan | it's already there |
| 18:40:14 | evan | it's not a pref pain |
| 18:40:15 | evan | pane |
| 18:40:19 | evan | it's a standalone program |
| 18:42:07 | dbussink | evan: ah ok, found it |
| 18:42:35 | dbussink | evan: isn't dumping it to the console easier for people, as in, that works straight away without having to change that setting? |
| 18:42:44 | evan | imho no. |
| 18:42:58 | evan | the details crashreporter reports is much better than we can generate with backtrace() |
| 18:43:17 | rue | On SL only? |
| 18:43:24 | evan | perhaps. |
| 18:43:26 | evan | i don't recall. |
| 18:43:35 | rue | No program by that name on Leopard, at any rate. |
| 18:43:52 | dbussink | evan: well, i didn't know of the option at all, is it documented somewhere (also in the rubinius code? ) |
| 18:43:58 | evan | brixen has it enabled on Leopard. |
| 18:44:07 | evan | which option? |
| 18:44:10 | evan | using crashreporter? |
| 18:44:14 | dbussink | since pointing people at would be very critical in order for people to be able to properly report it |
| 18:44:14 | dbussink | yeah |
| 18:44:21 | evan | not sure |
| 18:44:24 | evan | i don't think we documented it. |
| 18:44:42 | dbussink | evan: well, that's probably the reason i thought, hey, this isn't working, let's fix this |
| 18:45:01 | evan | probably not, unless the documentation was right above the code you changed :) |
| 18:45:35 | evan | since that code didn't indicate there was anything special about OS X |
| 18:45:41 | evan | so you wouldn't have known to go look for it. |
| 18:49:01 | dbussink | evan: could also write a custom crash handler that automatically posts an issue ;) |
| 18:49:10 | evan | considered that. |
| 18:49:19 | evan | there is a google project to build something that odes that |
| 18:49:24 | evan | but the code is super complicated |
| 18:49:29 | evan | i couldn't figure out how to wire it up right. |
| 18:49:35 | rue | /Developer/Applications/Utilities/CrashReporterPrefs.app here |
| 18:49:57 | rue | So, yeah, this is unlikely to be something that most people have enabled unless we tell them to |
| 18:50:16 | dbussink | evan: well, could also write the most basic c code possible to do that, so it works on all platforms |
| 18:50:33 | evan | yeah |
| 18:50:45 | evan | code to take the output from backtrace() and post it is fine |
| 18:51:00 | evan | the issue is that it's hard to do much work in a SIGSEGV handler |
| 18:51:44 | dbussink | evan: yeah |
| 18:51:59 | dbussink | evan: btw, if you want a fresh segfault to start the week, i have one here: http://github.com/evanphx/rubinius/issues/#issue/115 ;) |
| 18:52:08 | evan | k |
| 18:52:21 | evan | i'll take a look once this stupid sexual harrasement thing is doen. |
| 18:52:23 | evan | done. |
| 18:52:41 | dbussink | evan: which harrasement thing ? |
| 18:52:55 | evan | this thing for work |
| 18:54:00 | dbussink | evan: like promising you never going to do it? |
| 18:54:09 | evan | pretty much |
| 18:54:13 | evan | it's an education thing |
| 18:54:23 | evan | what is and is not workplace harassement |
| 18:54:33 | evan | not just sexual |
| 18:56:13 | dbussink | evan: ah ok, i should really show this to a colleague of mine :P |
| 18:56:31 | evan | :( |
| 18:56:58 | dbussink | evan: hehe, meant it in a fun way, he's also a really good friend of mine, so we just joke around a lot |
| 18:57:07 | dbussink | and he's gay, that might have something to do with it too :P |
| 18:57:09 | evan | gotcha. |
| 18:58:27 | dbussink | evan: but then again, we also sometimes just start singing or dancing, which might count as harassement actually... |
| 18:58:48 | evan | probably not |
| 18:58:56 | Zoxc | most things can count as harassement |
| 18:58:58 | evan | though, if someone came to work dressed as black pete in the US |
| 18:59:05 | evan | that would be racial harassement probably. |
| 18:59:28 | dbussink | evan: haha |
| 18:59:53 | dbussink | evan: here companies usually organize something for the kids of employees with sinterklaas and some petes :P |
| 19:00:08 | evan | yep |
| 19:00:40 | dbussink | but that was last weekend, so the christmas madness has started now |
| 19:03:04 | evan | hehe |
| 19:03:06 | evan | here too. |
| 19:22:41 | agardiner | evening! |
| 19:23:03 | dbussink | agardiner: evening :) |
| 19:23:31 | agardiner | haha! One of the few for him it is evening! :-D |
| 19:23:55 | brixen | agardiner: another 2 hrs of sunlight here and it will be like evening :) |
| 19:24:05 | dbussink | agardiner: finally glad to see someone in the same tz :P |
| 19:24:09 | brixen | has little love for winter |
| 19:24:12 | dbussink | agardiner: or almost the same i think |
| 19:24:19 | agardiner | hehe |
| 19:24:20 | dbussink | brixen: how cold is it over there? |
| 19:24:22 | agardiner | GMT here |
| 19:24:38 | agardiner | not too cold, probably in the 50s is my guess |
| 19:24:54 | agardiner | but the temp drops rapidly when the sun goes |
| 19:24:55 | brixen | dbussink: oh, only about -5 C |
| 19:25:03 | dbussink | agardiner: what's that in normal people temperature? ;) |
| 19:25:10 | dbussink | brixen: ah, refreshing :P |
| 19:25:11 | agardiner | low teens |
| 19:25:12 | brixen | dbussink: actually, probably abou -3 C now |
| 19:25:17 | agardiner | 10-12 say |
| 19:26:01 | dbussink | still above 0 here at night now, so not that cold yet |
| 19:26:17 | dbussink | i love my new apartment, haven't turned on the heat at all :) |
| 19:26:40 | agardiner | yeah, we get the same here - everyone below is heating our apartment for us! :-) |
| 19:26:57 | agardiner | only need the heat for an hour or two in the morning mostly |
| 19:27:19 | agardiner | just as well, since our electricity bill is out of this world! |
| 19:27:25 | dbussink | agardiner: we have people left right, top and bottom |
| 19:27:35 | agardiner | we don't have anything except electric |
| 19:27:38 | dbussink | agardiner: mostly old people, they usually warm it up a lot |
| 19:27:49 | agardiner | so hot water, heating all adds up |
| 19:28:09 | agardiner | hehe, old folks don't like the cold |
| 19:28:14 | dbussink | agardiner: ah, we still have gas too, a lot cheaper for heating |
| 19:28:23 | dbussink | and i prefer it for cooking too :) |
| 19:28:29 | agardiner | yeah, we'd have that if we had the choice |
| 19:28:42 | agardiner | seems crazy - this place is only 10 yrs old |
| 19:28:46 | agardiner | what were they thinking? |
| 19:28:57 | dbussink | well, they also don't put it in a lot of new places here |
| 19:29:11 | dbussink | they have central heating systems and then just electricity in the houses |
| 19:30:33 | dbussink | agardiner: you're in london? |
| 19:30:40 | agardiner | yep |
| 19:32:43 | dbussink | agardiner: ah, cool, nice city :) |
| 19:32:58 | agardiner | yeah, its not bad |
| 19:33:13 | agardiner | looking forward to getting back to Oz for Xmas though |
| 19:33:25 | agardiner | warm weather, sun, bbq |
| 19:33:28 | agardiner | bring it on |
| 19:35:37 | dbussink | agardiner: i think i would find that really weird :) |
| 19:35:50 | dbussink | agardiner: christmas == cold and long nights for me :) |
| 19:36:09 | agardiner | yeah, its not the traditional white xmas, but its what i grew up with! |
| 19:36:35 | agardiner | and it beats a wet and cold xmas in London! |
| 19:37:26 | dbussink | agardiner: i prefer really cold & white christmas over the usually rainy / grey christmas :) |
| 19:38:24 | agardiner | yeah, a white xmas is a lot better than grey! But with London, its normally grey... |
| 19:40:51 | dbussink | agardiner: yeah, sadly that's usually the case here too |
| 19:41:15 | agardiner | dbussink: "here" is belgium? |
| 19:41:41 | dbussink | agardiner: netherlands |
| 19:42:04 | agardiner | Ah, close then! |
| 19:44:36 | dbussink | agardiner: hehe, yeah |
| 19:44:51 | dbussink | agardiner: my hostname has .nl in it :P |
| 19:45:30 | agardiner | ah, yes, but i didn't think to check that... |
| 20:15:19 | rue | dbussink: Heey, I am equally close, just more futuristic... |
| 20:20:45 | dbussink | rue: but your biorythm is weird ;) |
| 20:20:51 | evan | man, our String#split is sloooow. |
| 20:21:53 | rue | Biowhat? |
| 20:21:59 | rue | Oh, oh, yes |
| 20:22:25 | rue | I have a b-i-orhythm just like all organic bipedals |
| 20:22:39 | rue | Perfectly ordinary |
| 20:28:38 | evan | FAIL |
| 20:28:54 | evan | wasted my whole morning on this stupid workplace harassement webinar thing |
| 20:29:00 | evan | and then it didn't register that I even did any of it |
| 20:29:10 | evan | i'm not doing it again. |
| 20:29:12 | agardiner | disaster! |
| 20:30:04 | Defiler | evan: You forgot to install the special harassment plugin first |
| 20:30:23 | Defiler | a technician will be along soon to prep you for the surgery |
| 20:30:29 | evan | because requiring me to install it constitutes OS harassement on their part |
| 20:30:59 | agardiner | i see harassment coming as a result of this fiascoe! |
| 21:55:04 | dbussink | brixen: small thing, but the rubinius website doesn't specify any encoding, so it fallbacks to people's default |
| 21:56:16 | brixen | dbussink: website is being updated soon |
| 21:58:32 | rue | Mm, someone had a ticket about a typo |
| 22:22:50 | dwaite | I was very disappointed by the sexual harassment training at work |
| 22:23:05 | dwaite | I don't feel like it taught me how to do it right at all |
| 22:23:24 | evan | hah |
| 22:23:37 | dwaite | I figured it would be like, lesson 1: self confidence |
| 22:23:41 | dwaite | lesson 2: objectifying women |
| 22:24:22 | dwaite | instead, I swear they spent the whole time trying to make me reevaluate whether I wanted to commit sexual harassment at all |
| 22:24:58 | Defiler | It's easy once you get started though, don't worry |
| 22:25:08 | dwaite | I took a two step process for my employee training (which happened after I had worked here four years) |
| 22:25:23 | dwaite | 1. fill out the test, answering 'a' for every question |
| 22:25:51 | dwaite | 2. save their corrections, and submit the test again answering the right answer for every question |
| 22:26:29 | dwaite | I apparently did significantly better the second time around |
| 22:26:59 | Defiler | diff is so handy |
| 22:27:58 | dwaite | apparently you are allowed to discriminate people based on pizza topping preference |
| 22:32:08 | evan | thats correct |
| 22:32:14 | evan | to anchovey people on my teams. |
| 22:39:01 | evan | why does String#split convert the arg into a regexp.. |
| 22:39:09 | evan | there is a better way to do this. |
| 22:43:44 | agardiner | evan: i started looking at the debugger again over the weekend. Have you got some time to discuss? |
| 22:44:31 | evan | sure |
| 22:44:50 | agardiner | not sure where to start... |
| 22:45:07 | agardiner | its a long way from working as things stand |
| 22:45:18 | evan | yeah, I suspected as much. |
| 22:45:23 | agardiner | hehe |
| 22:46:14 | agardiner | with shotgun, i had stepping working over branches, into method calls, and back to the caller |
| 22:46:23 | agardiner | none of that works at the moment |
| 22:46:40 | evan | ok |
| 22:46:53 | agardiner | and i'm wondering if the plans i had are the best approach |
| 22:46:56 | evan | i'd prefer we get step instruction working |
| 22:47:04 | agardiner | that's working |
| 22:47:25 | agardiner | i got that sorted again, except if the instruction is any kind of control flow change |
| 22:47:29 | evan | ok, next-ing into a method was pretty hairy before |
| 22:47:36 | evan | so i wanna get it righter this time |
| 22:47:48 | agardiner | yeah, that's what i wanted to discuss |
| 22:47:57 | agardiner | the approach for each problem |
| 22:48:33 | agardiner | maybe we should go over some old ground first though - i'm not sure how well you remember some of the issues |
| 22:48:37 | agardiner | ? |
| 22:48:54 | evan | a little bit |
| 22:48:58 | evan | feel free to refresh me |
| 22:49:11 | agardiner | ok - might help my thought processes too! :-) |
| 22:49:31 | agardiner | so, initially we built the debugger on the basis of opcode replacement |
| 22:49:39 | agardiner | but the issues with that were: |
| 22:50:18 | agardiner | 1) easy to install a breakpoint, but hard to step due to the need to revert the breakpoint. |
| 22:50:39 | agardiner | 2) handling multiple threads is tricky |
| 22:51:15 | evan | yeah |
| 22:51:19 | evan | opcode replacement is cute |
| 22:51:20 | agardiner | 3) opcode replacement only works when you know where control flow is going to go next if you are stepping |
| 22:51:23 | evan | but hard to get right. |
| 22:51:41 | evan | yep yep |
| 22:52:11 | agardiner | so, next up i started work on using unused bits in the opcode as debug flags |
| 22:52:49 | agardiner | this had the advantage of not having to replace instructions, which made it more robust for a number of cases |
| 22:53:06 | Defiler | old-school way is to emit control flow hints along with the rest of the opcodes |
| 22:53:07 | agardiner | but you still have to address the flow control challenge |
| 22:53:41 | agardiner | i think there are four or five control flow types: |
| 22:53:54 | agardiner | 1) simple branches in the same method (goto etc) |
| 22:53:59 | agardiner | 2) method send |
| 22:54:02 | agardiner | 3) return |
| 22:54:04 | agardiner | 4) yield |
| 22:54:09 | agardiner | 5) exceptions |
| 22:54:49 | evan | yep |
| 22:54:49 | evan | ok |
| 22:54:58 | evan | so we've tried to make it very streamline |
| 22:55:07 | evan | what if we turn away from that for a second. |
| 22:55:18 | evan | we've got the debugging interpreter |
| 22:55:25 | evan | so what if we wire it up so that on every instruction |
| 22:55:45 | evan | control is handed to a debugging thread |
| 22:55:50 | evan | and it can decide what to do |
| 22:55:51 | evan | for each ip |
| 22:55:56 | evan | thats obviously not very performant |
| 22:56:09 | agardiner | it doesn't need to be |
| 22:56:15 | evan | but it vastly simplifies the control flow picture |
| 22:56:22 | evan | and for things like method calls |
| 22:56:23 | agardiner | you only have breakpoints on one or a handful of methods at any time |
| 22:56:32 | evan | we can wire it up so that the debugger is called after the lookup |
| 22:56:34 | Zoxc | isn't yield just a call? |
| 22:56:37 | evan | but before the dispatch |
| 22:56:54 | agardiner | yeah, that's what i was planning to do |
| 22:56:57 | evan | that would allow you to next into a method |
| 22:57:02 | agardiner | but it strikes me as a bit messy |
| 22:57:13 | evan | well, i'm open to other ideas |
| 22:57:21 | evan | other things we've tried have been equally messy |
| 22:57:25 | agardiner | we need special handling in the send machinery and the exception machinery |
| 22:57:32 | evan | we could write a dispatcher entirely in ruby |
| 22:57:45 | evan | and execute a debugged method entirely in a meta-circular interpreter |
| 22:57:50 | agardiner | i had a way out there thought earlier tonight |
| 22:58:14 | agardiner | would it be possible to have a special jit for debugging? |
| 22:58:49 | evan | if we wanna build one sure |
| 22:58:51 | evan | what would it do? |
| 22:59:15 | agardiner | well, i figured you'd know!? :-) |
| 22:59:37 | agardiner | it seemed to me (without knowing *anything* about the jit) |
| 22:59:43 | Defiler | it would emit a version of the method with a bunch of calls out to the debugger? dunno heh |
| 23:00:01 | agardiner | that the problem with bytecode replacement is that our bytecodes do so much |
| 23:00:07 | Defiler | I wonder if llvm could be taught to gdb-itize some code |
| 23:00:32 | agardiner | but if you are jitting down to machine code by visiting these opcodes, it might be easier to add callbacks at certain points |
| 23:00:39 | Defiler | probably already does that |
| 23:01:08 | Defiler | it would be nice to be able to do both |
| 23:01:14 | evan | agardiner: ok.. but whats the point? |
| 23:01:16 | evan | why bother? |
| 23:01:16 | agardiner | both? |
| 23:01:18 | Defiler | to step through high-level 'ruby' instructions |
| 23:01:27 | evan | how is that less complicated than a debugging interpreter? |
| 23:01:27 | Defiler | and then down into the code the JIT emitted |
| 23:01:41 | agardiner | i'm not sure it is... |
| 23:01:46 | agardiner | i don't know enough |
| 23:01:55 | evan | it likely is not. |
| 23:02:12 | agardiner | but it seemed it might be more self-contained |
| 23:03:03 | agardiner | at the moment, we have another interpreter for the debugger, but it cant handle any of the control flow changes |
| 23:03:19 | agardiner | so we'd need to mess with a number of different areas |
| 23:03:35 | evan | there is nothing self contained about a magical jit'd function |
| 23:03:36 | agardiner | in a way that didn't cause performance to suffer when not debugging |
| 23:03:42 | evan | that requires the debugger to work |
| 23:03:50 | evan | the jit doesn't magically solve problems |
| 23:04:20 | evan | i can't see any reason to try and do this with the JIT |
| 23:04:25 | evan | it's lots more complicated |
| 23:04:31 | evan | with almost no benefit. |
| 23:06:03 | agardiner | i won't argue with you - like i said, it was an idea i wanted to float without knowing much about what was involved |
| 23:06:35 | evan | ok |
| 23:06:43 | evan | i just can't see how it makes this easier |
| 23:06:50 | agardiner | so then... |
| 23:07:02 | agardiner | back to the oringal plan? |
| 23:07:11 | agardiner | well, previous plan |
| 23:07:12 | evan | i don't know which was the original. |
| 23:07:16 | agardiner | :-P |
| 23:07:40 | agardiner | if we stick with using bits in the opcode rather than replacing the opcode |
| 23:07:55 | agardiner | i still need ways to handle all the control flow changes |
| 23:08:01 | agardiner | branches should be easy |
| 23:08:12 | evan | no |
| 23:08:26 | evan | i don't think we should replace the bits. |
| 23:08:31 | agardiner | ok |
| 23:08:39 | evan | that has exactly the same problem as opcode replacement. |
| 23:08:52 | evan | wrt reading, setting the bits |
| 23:08:59 | agardiner | i think its somewhat simpler, but the problems are the same, agreed |
| 23:09:28 | evan | any idea I had awhile ago is this |
| 23:09:40 | evan | when you enable debugging for a method |
| 23:09:58 | evan | you pass in a mask |
| 23:10:06 | evan | the mask is an array of Fixnums |
| 23:10:19 | evan | where the position in the mask indicates some action on the ip at that number |
| 23:10:24 | evan | so if you wanna break on ip = 3 |
| 23:10:26 | evan | you'd pass in |
| 23:10:32 | evan | [0, 0, 0, 1, ... ] |
| 23:10:50 | evan | the debugging interpreter will check the mask before each instruction |
| 23:10:53 | evan | to figure out what to do |
| 23:11:00 | agardiner | ok... |
| 23:11:35 | agardiner | like the bit setting in the opcode, but off to the side |
| 23:11:44 | agardiner | instead |
| 23:11:45 | evan | right |
| 23:12:08 | evan | that solves the issue of changing any instructions |
| 23:12:22 | agardiner | yep |
| 23:13:00 | evan | so, another issue |
| 23:13:10 | evan | perhaps when you setup a method to be debugged |
| 23:13:18 | evan | you have to pass in a Thread object |
| 23:13:30 | evan | which will indicate which Thread the method will be debugged for |
| 23:13:36 | agardiner | ah, well |
| 23:13:39 | evan | that would mean that only one thread would be debugged at a time |
| 23:13:46 | evan | but it would solve the Threading issue |
| 23:13:54 | agardiner | yes if you are stepping, not if you are creating a global breakpoint |
| 23:14:07 | evan | hm. ok. |
| 23:14:12 | evan | a good point. |
| 23:14:12 | agardiner | i agree, only one thread at a time can be debugged |
| 23:14:26 | agardiner | but you can't necessarily know which one will hit first |
| 23:14:44 | agardiner | so you set a global breakpoint |
| 23:15:04 | agardiner | when hit, you step with a thread specific breakpoints |
| 23:15:08 | evan | we could simply enforce that |
| 23:15:17 | evan | that only one Thread can be debugged at a time |
| 23:15:32 | evan | the debugging interpreter can simple check if the current thread is the one being debugged |
| 23:15:34 | agardiner | absolutely - just don't force us to know which one ahead of time! |
| 23:15:37 | evan | if not, it will ignore the mask |
| 23:15:42 | agardiner | yeah, exactly |
| 23:15:53 | evan | so when a breakpoint is tripped |
| 23:15:56 | agardiner | that was the plan i had for bit setting in the opcode |
| 23:16:02 | evan | the current thread is set as the debugged thread |
| 23:16:15 | evan | and now everything except for events on that thread are ignored. |
| 23:16:17 | agardiner | this is the big advantage either approach has over opcode replacement |
| 23:16:53 | agardiner | i definitely like this better than bit setting though |
| 23:16:58 | evan | RAWR. |
| 23:17:28 | evan | String#split from 2.8s to 0.31s |
| 23:17:34 | agardiner | woot! |
| 23:17:47 | evan | by NOT converting a string pattern to a regex |
| 23:17:56 | agardiner | OoM improvement |
| 23:17:58 | evan | instead using a simple C style index from the left mechanism |
| 23:19:29 | agardiner | so, the opcode mask approach still needs to deal with control flow changes... |
| 23:19:47 | evan | yes |
| 23:19:58 | agardiner | simplest case first |
| 23:20:04 | agardiner | branches in the same method |
| 23:20:21 | agardiner | when i'm stepping, and the next instruction is a goto_if_tre/false |
| 23:20:46 | evan | you mean when you're steping at the current one is a goto_if |
| 23:20:55 | agardiner | yea |
| 23:20:58 | evan | ie, where are you going to go next |
| 23:21:15 | agardiner | can probably solve that with a break after, rather than break before |
| 23:21:16 | evan | well |
| 23:21:25 | agardiner | so do the branch and then break |
| 23:21:31 | agardiner | to the debugger |
| 23:21:41 | evan | one easily solution is to simply pretend that there is always a temporary break on a goto target |
| 23:21:56 | evan | so we can change goto_if in the debugging interpreter to do the test |
| 23:22:04 | evan | change the ip |
| 23:22:08 | evan | then always call out to the debugger |
| 23:22:22 | agardiner | yeah, thats what i meant by break after |
| 23:22:39 | evan | ok |
| 23:22:40 | agardiner | normally we set the break flag on the instruction we want to break before |
| 23:22:50 | evan | so we'll have the debugger return a command |
| 23:22:50 | agardiner | here we'd set it on the instruciotn we want to break after |
| 23:22:53 | evan | that can manipulate the mask |
| 23:23:01 | evan | in this case, the command would just be "break after" |
| 23:23:20 | agardiner | yeah, sounds good |
| 23:23:46 | agardiner | that solves the problem of looking at the stack from the debugger to know where to set the next breakpoint |
| 23:23:57 | evan | yep |
| 23:24:00 | agardiner | which seems ugly |
| 23:24:20 | agardiner | and handles the whole class of gotos in the same simple way |
| 23:24:28 | evan | right |
| 23:24:31 | evan | so, here's one |
| 23:24:35 | evan | another one |
| 23:24:48 | evan | we're on a send |
| 23:24:50 | evan | and we do next |
| 23:24:56 | evan | ie, don't break into the destination method |
| 23:25:06 | agardiner | ok |
| 23:25:14 | evan | and an exception is raised |
| 23:25:18 | agardiner | ooh |
| 23:25:27 | evan | because thats basically a goto. |
| 23:25:28 | agardiner | er, ew! |
| 23:25:52 | evan | we can easily have the debugger file automatically when an exception enters the stop |
| 23:25:56 | evan | s/stop/scope/ |
| 23:25:59 | evan | s/file/fire/ |
| 23:25:59 | agardiner | exceptions i figure are the hardest case, and you want to jump right into it! :-) |
| 23:26:03 | evan | stupid hands. |
| 23:26:18 | evan | well, setup_unwind takes an ip |
| 23:26:27 | evan | which is basically a branch target |
| 23:26:38 | evan | seems like if an exception is beind unwound through a debugged method |
| 23:26:43 | evan | the debugger should always be told |
| 23:26:47 | evan | that makes it pretty simple |
| 23:26:51 | agardiner | i'd go further i think |
| 23:26:55 | evan | because the debugger can just be told all the info |
| 23:27:03 | evan | the exception object, the list of handler ips, etc. |
| 23:27:06 | agardiner | i'd like the debugger to fire at the point the exception is about to be raised |
| 23:27:13 | agardiner | not after it starts unwinding |
| 23:27:21 | evan | sure |
| 23:27:22 | evan | thats easy. |
| 23:27:34 | agardiner | then you can inspect state |
| 23:27:40 | agardiner | etc |
| 23:27:42 | evan | but that likely won't be in a method thats currently being debugged |
| 23:27:47 | evan | so lets save that as a different case |
| 23:27:57 | evan | i'm looking mainly at the control flow of an existing debugged method |
| 23:28:05 | agardiner | yeah, there are multiple scenarios for exceptions |
| 23:28:26 | evan | so if the debugger is fired when an exception enters a debugged method |
| 23:28:30 | agardiner | hey, you brought iit up! :) |
| 23:28:32 | evan | the debugger can issue "break after" |
| 23:28:46 | evan | to have it break on the handler |
| 23:29:00 | evan | I did, I brought it up. |
| 23:29:06 | evan | this way |
| 23:29:13 | evan | when I type "next" on a send |
| 23:29:28 | evan | i'll jump straight to the exception handler code |
| 23:29:29 | agardiner | ah, i get you |
| 23:29:38 | agardiner | i hadn't even considered the case your describing |
| 23:29:46 | evan | ah! |
| 23:29:48 | evan | this is the case I care about |
| 23:29:54 | evan | because it's the case of debugging a singular method |
| 23:29:55 | agardiner | :-D |
| 23:29:59 | evan | and tried to figure out what it does |
| 23:30:09 | evan | so you need to follow the control flow precisely |
| 23:30:33 | agardiner | that's the challenge |
| 23:30:45 | agardiner | knowing all the places where control flow changes |
| 23:30:51 | agardiner | some are expected, others not |
| 23:31:16 | agardiner | i'll bet there are many cases i haven't considered |
| 23:31:17 | evan | thats why having the event tell the debugger |
| 23:31:26 | evan | without having to have the debugger know ahead of time |
| 23:31:28 | evan | is easier. |
| 23:31:36 | agardiner | it *has* to be that way |
| 23:31:42 | evan | right |
| 23:31:52 | agardiner | it simply isn't possible for the debugger to know what will happen in called methods etc |
| 23:32:04 | evan | right |
| 23:32:41 | agardiner | so going back to you next->exc case |
| 23:32:54 | evan | yep |
| 23:33:14 | agardiner | if you were hitting next, what should happen? |
| 23:33:36 | evan | what instruction am I on? |
| 23:33:38 | evan | a send? |
| 23:33:44 | evan | that raises an exception |
| 23:33:45 | evan | ? |
| 23:33:46 | agardiner | yeah |
| 23:33:52 | evan | when I hit next |
| 23:34:01 | evan | i'm told that an exception was raised |
| 23:34:06 | evan | and i'm put at the top of the handler code |
| 23:34:16 | agardiner | seems to me there is an argument for invoking the debugger at both the point of the exception and at the point of return |
| 23:34:46 | evan | i think you're getting way ahead of yourself. |
| 23:34:55 | agardiner | probably! |
| 23:35:02 | evan | i'm not saying this is the only place an exception is handled |
| 23:35:10 | evan | i'm ONLY specifying the behavior of this one case |
| 23:35:14 | agardiner | no, i know |
| 23:35:14 | evan | we can deal with other things later. |
| 23:36:02 | agardiner | but i guess what i'm asking is: how is hitting an excpetion when you hit next on a send different from when you hit an exception elsewhere? |
| 23:36:32 | agardiner | wouldn't you want the option in all cases of either breaking at the point of the excpetion, or breaking at the excpetion handler? |
| 23:40:25 | evan | you mean |
| 23:40:29 | evan | why a send specificly? |
| 23:40:54 | agardiner | well, i guess i'm thinking more about it from a ui point of view |
| 23:41:07 | evan | i think thats getting ahead of the issue |
| 23:41:10 | agardiner | all i hit was 'n' for next - i didn't know an exception would be raised |
| 23:41:23 | evan | but it did get raised |
| 23:41:27 | evan | so you better know |
| 23:41:54 | agardiner | well, sure, i want to know when the exception occurred |
| 23:42:16 | evan | you're hung up on this "when the exception occured" case |
| 23:42:19 | evan | i'm ignoring that entirely |
| 23:42:28 | evan | get myopic |
| 23:42:33 | evan | you're in a single method |
| 23:42:41 | evan | and because of something you're not aware of |
| 23:42:47 | evan | an exception is being delivered to this method |
| 23:42:49 | evan | what do you do? |
| 23:43:06 | evan | i say you tell the user and show them that they're now in the exception handler code |
| 23:43:10 | evan | i can't think of any way else it should work. |
| 23:43:14 | agardiner | well, i'd say if i was debugging the method, that shouldn't happen |
| 23:43:34 | agardiner | i'd want to know: you stepped over a method, but that method has raised this exception here |
| 23:43:40 | agardiner | in this method |
| 23:43:46 | evan | huh?! |
| 23:43:59 | agardiner | do you want to a) look at the exception at the point it occurred |
| 23:44:04 | evan | you're confusing the fuck out of me. |
| 23:44:13 | agardiner | or b) return to your method and see how it is handled |
| 23:44:27 | agardiner | let me put it another way |
| 23:44:34 | evan | wait wait wait |
| 23:44:37 | agardiner | i don't want to frustrate you |
| 23:44:39 | evan | what is "next" for you? |
| 23:44:48 | evan | what does that do in your mind. |
| 23:44:59 | agardiner | next means step to the next instruction/line after the current one |
| 23:45:06 | agardiner | in the same method |
| 23:45:12 | evan | don't follow a method out |
| 23:45:14 | evan | right? |
| 23:45:15 | agardiner | yes |
| 23:45:17 | evan | ok |
| 23:45:22 | agardiner | but... |
| 23:45:22 | evan | i don't get your point at all then. |
| 23:45:39 | agardiner | if an exception occurred in method i didn's step into |
| 23:45:50 | agardiner | i'd want the option to look at it |
| 23:45:55 | evan | ok fine |
| 23:46:06 | agardiner | i may choose to step right back out |
| 23:46:08 | evan | i don't see how thats related at all to what happens in the method you were in when you hit next |
| 23:46:14 | agardiner | but if i don't look at it, i can't go back |
| 23:46:28 | evan | what is "step right back out"? |
| 23:46:39 | evan | you mean mean see how the exception was raised? |
| 23:46:40 | agardiner | i'm in method A and i hit next |
| 23:46:43 | agardiner | A calls B |
| 23:46:50 | agardiner | B raises an exception |
| 23:47:03 | agardiner | I want to know an exception has occurred in called method B |
| 23:47:07 | evan | fine |
| 23:47:14 | agardiner | and be asked do i want to debug there, or return to A? |
| 23:47:19 | evan | thats unrelated entirely to what happens when the exception hits A! |
| 23:47:36 | evan | you're talking about 2 completely seperate features |
| 23:47:54 | evan | 1) auto-break when an exception is raised |
| 23:48:07 | evan | 2) moving to exception handler code when an exception enters a debugged method |
| 23:48:13 | evan | 2 completely different things |
| 23:48:14 | evan | completely. |
| 23:48:17 | agardiner | yeah, ok |
| 23:48:55 | agardiner | you threw me because it sounded to me like we would ignore exceptions at the point of raise if the user hit next |
| 23:49:01 | evan | le sigh. |
| 23:49:02 | evan | no no no |
| 23:49:02 | agardiner | but i get what you mean now |
| 23:49:15 | evan | i'm not dictating that anything exists |
| 23:49:18 | agardiner | IRC is not the best medium sometimes |
| 23:49:28 | evan | except for going over the specific set of actions i'm discussing |
| 23:49:34 | evan | IRC blows actually. |
| 23:49:35 | evan | it's terrible. |
| 23:49:47 | agardiner | :-) |
| 23:49:53 | evan | i get more frusterated by text chat of all kinds |
| 23:50:00 | evan | than any other way of communicating |
| 23:50:06 | evan | morse code would probably be a little worse |
| 23:50:07 | agardiner | oh yeah, definitely |
| 23:50:07 | evan | but not much. |
| 23:50:17 | agardiner | actually, i think it may be better |
| 23:51:19 | agardiner | so, back to your case |
| 23:51:35 | agardiner | assuming the exception gets delivered back to the method you were in |
| 23:51:47 | evan | on the phone |
| 23:51:48 | evan | bbiab. |
| 23:51:55 | agardiner | 'k |
| 23:52:18 | dwaite | you got preempted by a more interactive medium, agardiner |
| 23:52:28 | agardiner | :-D |
| 23:52:57 | agardiner | i was probably due some pre-emption |
| 23:53:25 | dwaite | btw, back when we were making Jabber, people would keep telling us that we were going out of our way to make this useless XML thing, and that we should not need to do protocol work since IRC already existed as a RFC. "Those that refuse to learn from IRC are doomed to repeat it" |
| 23:53:54 | agardiner | hehe |
| 23:54:02 | dwaite | my response was that we used what IRC did as a factor in every choice we made. Whatever IRC did, we would do the opposite |
| 23:54:11 | agardiner | ha! |
| 23:54:54 | dwaite | hey, should we make everyone known by their computer's IP address? hmm, what did IRC do? |
| 23:55:43 | dwaite | should we make it so that a user getting too much traffic should bump them off the server? How about, should we make it so that nicknames and channels are first-come, first-serve? |
| 23:56:22 | dwaite | (yeah, I was a bit of a punk, there were a lot of people who left the channel really disliking me) |
| 23:56:50 | agardiner | too wedded to the old ways... |
| 23:56:54 | dwaite | I also wrote a script that let me select part of someone's question and turn it into a google.com "I'm Feeling Lucky" link |
| 23:57:11 | rue | Defiler: GDB 7 has support for JITted code |
| 23:57:13 | dwaite | I had to stop that because those links started finding their way into official documentation |
| 23:58:02 | agardiner | yeah, i'm feeling lucky can be a crapshoot |
| 23:58:26 | dwaite | well no, I did it as a kinda passive-aggressive joke |
| 23:58:29 | dwaite | like, let me google that for you |
| 23:58:41 | dwaite | I didn't intend them to link to say other projects' homepages :) |
| 23:59:01 | agardiner | :-) |