Comments for The Cliffs of Inanity http://tromey.com/blog Sat, 31 Mar 2012 10:41:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Emacs and Common Lisp by David http://tromey.com/blog/?p=709&cpage=1#comment-157901 David Sat, 31 Mar 2012 10:41:54 +0000 http://tromey.com/blog/?p=709#comment-157901 Rob: There's a lot of subjectivity in the experience of performance. If you have "pretty crappy computers", my guess (and I freely admit this is just a guess) would be that your expectations are low for performance -- and with low expectations, they'll get met. (For more on subjective versus objective performance measurements, see, e.g., http://www.sigchi.org/chi95/proceedings/shortppr/gvk_bdy.htm ) I'm fairly new to emacs myself, but I can definitely say there are times when I find myself waiting for it to do something. To me, that's essentially how I define a case of "experiencing performance issues" -- if I'm waiting for the computer, it's got a performance issue. So, if you've "never ever experienced performance issues with Emacs", I'd like to know what that means. Or, just to have you know that others of us have, and so for Tom, this may well be a "worth it" pursuit. And as for which problems to solve, well, there are a lot of us humans about. You're welcome to go solve others. I'm glad that Tom is working on the ones that *he sees* as a problem. If you're trying to recruit his help on one of yours, that's one thing... though perhaps he'll be more effective at helping if he's not waiting for his editor. ;) Anyway, Mostly what I want to say is Tom: Kudos on working on this. I'm excited to see what comes of it. I hope you'll keep going... This seems like a lot of work, and I hope you have the persistence (and/or help, encouragement, etc.) to stick with it. Rob: There’s a lot of subjectivity in the experience of performance. If you have “pretty crappy computers”, my guess (and I freely admit this is just a guess) would be that your expectations are low for performance — and with low expectations, they’ll get met.

(For more on subjective versus objective performance measurements, see, e.g., http://www.sigchi.org/chi95/proceedings/shortppr/gvk_bdy.htm )

I’m fairly new to emacs myself, but I can definitely say there are times when I find myself waiting for it to do something. To me, that’s essentially how I define a case of “experiencing performance issues” — if I’m waiting for the computer, it’s got a performance issue.

So, if you’ve “never ever experienced performance issues with Emacs”, I’d like to know what that means. Or, just to have you know that others of us have, and so for Tom, this may well be a “worth it” pursuit.

And as for which problems to solve, well, there are a lot of us humans about. You’re welcome to go solve others. I’m glad that Tom is working on the ones that *he sees* as a problem. If you’re trying to recruit his help on one of yours, that’s one thing… though perhaps he’ll be more effective at helping if he’s not waiting for his editor. ;)

Anyway, Mostly what I want to say is Tom: Kudos on working on this. I’m excited to see what comes of it. I hope you’ll keep going… This seems like a lot of work, and I hope you have the persistence (and/or help, encouragement, etc.) to stick with it.

]]> Comment on 9. Scripting gdb by Scripting GDB Links « Constantly Underwhelmed http://tromey.com/blog/?p=548&cpage=1#comment-157896 Scripting GDB Links « Constantly Underwhelmed Fri, 09 Mar 2012 07:07:26 +0000 http://tromey.com/blog/?p=548#comment-157896 [...] http://tromey.com/blog/?p=548 [...] [...] http://tromey.com/blog/?p=548 [...]

]]> Comment on 2. Writing a new gdb command by Robin http://tromey.com/blog/?p=501&cpage=1#comment-157894 Robin Tue, 06 Mar 2012 14:42:23 +0000 http://tromey.com/blog/?p=501#comment-157894 At least with GDB 7.2 I've discovered that the source command shown above does not work. Instead you need to use the .py file extension and emit the -p, i.e. (gdb) source /tmp/example.py I guess things have moved on since this tutorial was written, but I still found it very helpful. At least with GDB 7.2 I’ve discovered that the source command shown above does not work. Instead you need to use the .py file extension and emit the -p, i.e.

(gdb) source /tmp/example.py

I guess things have moved on since this tutorial was written, but I still found it very helpful.

]]> Comment on Quick Multi-process Debugging Update by Björn Carlsson http://tromey.com/blog/?p=790&cpage=1#comment-157886 Björn Carlsson Fri, 02 Mar 2012 18:07:34 +0000 http://tromey.com/blog/?p=790#comment-157886 I have followed gdb blog, and I have just started implementing some pretty printers for our types at work. Very nice over all. But how can I reload my updated printers.py while in a debug sesssion in gdb? I have followed gdb blog, and I have just started implementing some pretty printers for our types at work. Very nice over all.
But how can I reload my updated printers.py while in a debug sesssion in gdb?

]]> Comment on Debugging multiple programs at once by Tom Tromey: Quick Multi-process Debugging Update : Rutweb Technology http://tromey.com/blog/?p=734&cpage=1#comment-157870 Tom Tromey: Quick Multi-process Debugging Update : Rutweb Technology Sat, 18 Feb 2012 12:22:07 +0000 http://tromey.com/blog/?p=734#comment-157870 [...] my last post I mentioned that setting breakpoints is a pain when debugging multiple processes in GDB. While [...] [...] my last post I mentioned that setting breakpoints is a pain when debugging multiple processes in GDB. While [...]

]]> Comment on Quick Multi-process Debugging Update by tom http://tromey.com/blog/?p=790&cpage=1#comment-157868 tom Sat, 18 Feb 2012 02:51:49 +0000 http://tromey.com/blog/?p=790#comment-157868 Hmm, maybe I should write up some tips and tricks. There are a bunch of hacks that are kicked around by gdb developers that maybe aren't generally known. Hmm, maybe I should write up some tips and tricks. There are a bunch of hacks that are kicked around by gdb developers that maybe aren’t generally known.

]]> Comment on Quick Multi-process Debugging Update by tom http://tromey.com/blog/?p=790&cpage=1#comment-157867 tom Sat, 18 Feb 2012 02:51:16 +0000 http://tromey.com/blog/?p=790#comment-157867 Stopping on a SEGV will happen automatically, by default. You can control this with the "handle" command. (Eventually we're going to add a "catch signal" command as well, so you can attach conditions and commands to signals.) You can use "break func if expr" or "cond" to set conditions. Breaking on foo-after-bar is a bit tricky. This can be done with convenience variables and commands attached to breakpoints (see the "commands" command). So, you'd initially "set var $seen_bar=0", then set $seen_bar=1 in bar's breakpoint, then "break foo if $seen_bar". You can make this more programmable by writing convenience functions in Python. E.g., one I use sometimes is a function that looks up the stack to see what the call chain looks like: break foo if $_caller_is("bar") Stopping on a SEGV will happen automatically, by default. You can control this with the “handle” command. (Eventually we’re going to add a “catch signal” command as well, so you can attach conditions and commands to signals.)

You can use “break func if expr” or “cond” to set conditions.

Breaking on foo-after-bar is a bit tricky. This can be done with convenience variables and commands attached to breakpoints (see the “commands” command). So, you’d initially “set var $seen_bar=0″, then set $seen_bar=1 in bar’s breakpoint, then “break foo if $seen_bar”.

You can make this more programmable by writing convenience functions in Python. E.g., one I use sometimes is a function that looks up the stack to see what the call chain looks like: break foo if $_caller_is(“bar”)

]]> Comment on Quick Multi-process Debugging Update by Dave Malcolm http://tromey.com/blog/?p=790&cpage=1#comment-157866 Dave Malcolm Fri, 17 Feb 2012 23:10:48 +0000 http://tromey.com/blog/?p=790#comment-157866 Very nice! Can I get it to easily break on any segfaults that happen in subprocesses? Also, I don't know if this already exists, but is it possible to set conditions on a breakpoint like: only break on function foo() if function bar has already been called? Very nice!

Can I get it to easily break on any segfaults that happen in subprocesses?

Also, I don’t know if this already exists, but is it possible to set conditions on a breakpoint like: only break on function foo() if function bar has already been called?

]]> Comment on Debugging multiple programs at once by The Cliffs of Inanity › Quick Multi-process Debugging Update http://tromey.com/blog/?p=734&cpage=1#comment-157865 The Cliffs of Inanity › Quick Multi-process Debugging Update Fri, 17 Feb 2012 15:12:27 +0000 http://tromey.com/blog/?p=734#comment-157865 [...] my last post I mentioned that setting breakpoints is a pain when debugging multiple processes in GDB. While [...] [...] my last post I mentioned that setting breakpoints is a pain when debugging multiple processes in GDB. While [...]

]]> Comment on Debugging multiple programs at once by Colin Walters http://tromey.com/blog/?p=734&cpage=1#comment-157862 Colin Walters Thu, 16 Feb 2012 15:44:02 +0000 http://tromey.com/blog/?p=734#comment-157862 That is cool. I didn't know gdb could attach to multiple programs. I've been using the following hack for a while for this exact scenario: http://people.gnome.org/~walters/gdbifmatch.c That is cool. I didn’t know gdb could attach to multiple programs.

I’ve been using the following hack for a while for this exact scenario:

http://people.gnome.org/~walters/gdbifmatch.c

]]>