Index

Show enters and exits. Hide enters and exits.

05:52:05aemoncannonHi all, quick question. Is rubinius able to generate code coverage statistics?
16:15:25brixenaemoncannon: no, rcov does not yet work with rbx and we don't have an alternative
16:16:00brixenaemoncannon: however, evan has said we will add some hooks that would enable an rcov-like tool
16:29:07khaasercov does use a trace_func, right?
16:29:32khaaseevan said there's no way rbx will have a trace func feature
16:30:52Defilerkhaase: there are two rcov modes; one is a C extension, and then it uses trace func if that can't be used
16:30:54brixenkhaase: yes, not set_trace_func, but some kind of hook lke it
16:31:06brixenthe C ext we would not support for sure
16:31:27brixenrbx looks nothing like MRI inside
16:31:34Defilerprobably there will just need to be an rbx version of the extension
16:31:38brixen(thankfully)
16:31:50khaasebut set_trace_func is like the ideal entry point for debugging
16:31:58khaaseand jruby has it, too
16:32:03DefilerIt's also impossibly slow
16:32:07brixenexactly
16:32:13brixenwe have a blazing full speed debugger
16:32:22brixenit just needs some work for the native threads
16:32:42brixenlast discussion was running the debugger interpreter always on the main thread I believe
16:33:11brixenkhaase: anyway, fret not, we have and will have a top-notch debugger
16:33:21khaaseyay!
16:33:57brixenour debugger steps through bytecode
16:34:04brixentry that with set_trace_func ;)
16:34:33khaaseactually, what i really want are smalltalk debuggers for ruby
16:34:43brixenand with clang integration, we might be able to seemlessly step into machine code for primitives
16:34:47DefilerWelcome to the proper channel to find that
16:34:48brixenthat would be freakin awesome :)
16:35:03khaaseyes, indeed
16:35:24brixenI meant stepping into machine code, not smalltalk debuggers :)
16:35:32khaaseme too
16:35:35brixen:)
16:37:04khaasei so can't wait for my bachelor project to be over. i'm doing so little ruby lately :(
16:37:23brixenwell, hurry up already :)
16:37:42BrianRice-workspeaking of smalltalk, does the ruby debugger act from a separate process/thread on the stack it's debugging?
16:37:45brixenhm, we already have the machinery to disassemble a jitted method too
16:38:12brixenBrianRice-work: there is no "ruby debugger" as a single entity
16:38:18brixenBrianRice-work: do you mean rbx's debugger?
16:38:42BrianRice-workbrixen: yes, rbx-specific is what I meant. surely MRI is not worth asking about
16:38:47brixenheh
16:39:00brixenwell, we have a debug interpreter
16:39:15khaasei think mri runs in the stack's thread but halts all other threads.
16:39:22brixenyou set a bit in the opcode and the debug interpreter looks at those bits
16:39:22khaasenot sure, though
16:39:31brixenthe issue is which thread to run it on
16:39:40brixenI think that needs to be resolved
16:39:54brixenright now it would run on any thread I think
16:40:54brixenit's not like the debugger is some thing that monitors this other thing running
16:41:11brixenit's just a version of the interpreter that checks higher order bits for flags set
16:41:26BrianRice-workok
16:41:40brixenwe used to do insn replacement for the debugger
16:41:56brixenbut we have all these extra bits in the opcodes
16:43:08brixenBrianRice-work: do you want to look at the code for it?
16:43:40BrianRice-worknah, that's okay
16:44:10BrianRice-workI'm about to set out on vacation. maybe when I return I should try a little cafe session again with you
16:44:23brixenah sure, anytime
16:44:43brixenI will shortly know much more about the debugger
16:44:49brixenI haven't done any work on it yet
16:44:58brixenbut I'm going to try to get it into 1.0
16:47:04BrianRice-workok
16:47:38BrianRice-workours is in userland (and a REPL subtype!) so it messes up sometimes and we'll benefit from process isolation
16:48:11brixenahh
17:32:32DefilerHey, if I'm looking for the current darwin version of a Mac OS box..
17:32:53Defilerin the form of; x86_64-apple-darwin10.x.y
17:33:13asap183.0 i think
17:33:14BrianRice-workuname?
17:33:16DefilerI thought I could get that from gcc -v or uname -a, but not exactly
17:33:28asap18uname -v ?
17:33:36Defilergcc -v shows the default target, which ends at the '10' without the minor and teeny
17:33:46DefilerDarwin Kernel Version 10.3.1: Mon Mar 22 15:13:15 PDT 2010; root:xnu-1504.3.52~1/RELEASE_I386
17:34:01Defilerbut I know that not every release changes the 'target' string
17:34:08asap18are you on a new mbp?
17:34:38BrianRice-workhttp://www.opensource.apple.com/release/mac-os-x-1063/ ?
17:34:49DefilerYes, but I've wondered about this numerous times
17:34:50BrianRice-work(listing xnu-1504.3.12)
17:34:57asap18Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386
17:35:38asap18apple always ships a special build with the new computers with new graphics/driver support that is incorporated in the next point release
17:35:53Defilerit looks like '10.3.0' is the correct target string, despite uname saying 10.3.1
17:36:15brixenDefiler: did you try rakelib/config.guess ?
17:36:28Defilernot building rubinius; that all works fine
17:36:38brixenI mean, just to get the value
17:36:45brixeninstead of gcc -v or whatever
17:37:15DefilerI'll check. good idea.
17:37:25Defilerwill ./configure generate that, or do I need to let it perform more steps
17:37:38brixenjust do rakelib/config.guess
17:37:40brixenit's a script
17:38:25Defilerx86_64-apple-darwin10.3.1
17:38:26Defilerinteresting
17:39:21DefilerOK, so config.guess assumes that 'uname -r' always maps onto to darwin target name