From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] MI: new timing command
Date: Sun, 31 Dec 2006 06:55:00 -0000 [thread overview]
Message-ID: <17815.23981.229049.700927@kahikatea.snap.net.nz> (raw)
In-Reply-To: <E1H0d1a-0006vS-Ec@zigzag.lvk.cs.msu.su>
> Do you have a *strong* preference to context diff as opposed to unified?
> If yes, I think I can try to cope with context diffs, but unified diffs
> are much more readable.
I always use context diffs because that's what Richard Stallman insists on for
Emacs. However, it's no big deal because if you save the patch as a file and
view it in Emacs in diff-mode (certain names like timings1.diff will
automatically open in this mode), you can toggle between context and unified
diffs from the menu bar.
> > + /* This is used to pass the current command timestamp
> > + down to continuation routines. */
>
> Two spaces after dot. No, I personally don't think this coding style
> guideline makes any sense, but Dan will notice it anyway and you'll
> have to change ;-)
OK.
> More seriously, this comment only says what this variable is
> used for, not what it is. For example, the comment might read:
>
> /* The timestamp of the moment when the current
> command started executing. Used to ... */
>
> Ah, and looking at the code this variable is used *only* so that
> 'run' and friend can output the timestamp despite the fact that
> they don't emit '^done', so I think this is better
> represented in the comment.
In Apple's code its used for the asynchronous continuation functions. It's
of type mi_timestamp and called current_command_ts: I think it's better to
let the code speak for itself.
>...
> > + if (strcmp (argv[0], "yes") == 0)
> > + do_timings = 1;
> > + else if (strcmp (argv[0], "no") == 0)
> > + do_timings = 0;
> > + else
> > + goto usage_error;
>
> Something looks wrong with indentation above.
It's just the way tabs are handled by the diff.
>...
> > + if (do_timings)
> > + current_command_ts = context->cmd_start;
>
> I wonder if it's better, instead of having global current_command_ts,
> add new global
>
> struct mi_parse* current_context;
>
> set it here to context:
>
> current_context = context;
>
> And the user 'current_context' later. That seems to be a more
> future-proof solution -- if mi_execute_async_cli_command will
> later need something more from mi_parse structure, we won't
> need to add yet another global variable.
This is a good solution if mi_execute_async_cli_command does eventually need
something more from mi_parse structure later but I don't see why it's needed
now. But perhaps you have something in mind?
>...
> > args->rc = mi_cmd_execute (context);
> >
> > + if (do_timings)
> > + timestamp (&cmd_finished);
> > +
> > if (!target_can_async_p () || !target_executing)
> > {
> > /* print the result if there were no errors
> > *************** captured_mi_execute_command (struct ui_o
> > *** 1068,1073 ****
> > --- 1118,1127 ----
> > fputs_unfiltered ("^done", raw_stdout);
> > mi_out_put (uiout, raw_stdout);
> > mi_out_rewind (uiout);
> > + /* Have to check cmd_start, since the command could be
> > + "mi-enable-timings". */
>
> Haven't you named the command 'enable-timings' without 'mi-'?
Duh! Yes. Apple call it -mi-enable-timings but the mi seems implicit to me.
>...
> > + static long
> > + wallclock_diff (struct mi_timestamp *start, struct mi_timestamp *end)
> > + {
> > + return ((end->wallclock.tv_sec - start->wallclock.tv_sec) * 1000000) +
> > + (end->wallclock.tv_usec - start->wallclock.tv_usec);
> > + }
> > +
> > + static long
> > + user_diff (struct mi_timestamp *start, struct mi_timestamp *end)
> > + {
> > + return
> > + ((end->rusage.ru_utime.tv_sec - start->rusage.ru_utime.tv_sec) * 1000000) +
> > + (end->rusage.ru_utime.tv_usec - start->rusage.ru_utime.tv_usec);
> > + }
> > +
> > + static long
> > + system_diff (struct mi_timestamp *start, struct mi_timestamp *end)
> > + {
> > + return
> > + ((end->rusage.ru_stime.tv_sec - start->rusage.ru_stime.tv_sec) * 1000000) +
> > + (end->rusage.ru_stime.tv_usec - start->rusage.ru_stime.tv_usec);
> > + }
>
> Perhaps the last three functions can be replaced with
>
> static long
> timeval_diff (struct timeval* start, start timeval *end)
> {
> return (end->tv_sec - start->tv_sec) * 1000000 .....
> }
>
> That 'user_diff' seems rather low level on non-reusable.
>
> > + /* Timestamps for current command and last asynchronous command */
Sounds reasonable. I'll do this in my next patch.
> Dot at the end of the sentence. The above sounds like this
> structure hold two separate timestaps -- for current command
> and the last async command. Maybe replacing "and" with "or" will help.
There are *many* instances of one line comments in this file without a full
stop. Perhaps the practice is just to give multi-line comments a full stop
(maybe one liners are regarded as phrases).
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2006-12-31 6:55 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-30 8:52 Nick Roberts
2006-12-30 12:09 ` Vladimir Prus
2006-12-30 16:10 ` Eli Zaretskii
2006-12-31 3:26 ` Nick Roberts
2006-12-31 4:26 ` Eli Zaretskii
2006-12-31 6:55 ` Nick Roberts [this message]
2006-12-31 15:10 ` Daniel Jacobowitz
2007-01-01 4:11 ` Nick Roberts
2007-01-03 18:01 ` Daniel Jacobowitz
2007-01-03 21:50 ` Nick Roberts
2007-01-03 22:59 ` Daniel Jacobowitz
2007-01-04 2:50 ` Nick Roberts
2006-12-31 15:33 ` Vladimir Prus
2006-12-30 16:09 ` Eli Zaretskii
2006-12-30 22:10 ` Nick Roberts
2006-12-31 4:22 ` Eli Zaretskii
2006-12-31 4:25 ` Daniel Jacobowitz
2006-12-31 5:18 ` Nick Roberts
2006-12-31 5:49 ` Daniel Jacobowitz
2006-12-31 7:47 ` Nick Roberts
2006-12-31 15:15 ` Daniel Jacobowitz
2006-12-31 15:24 ` Mark Kettenis
2006-12-31 15:39 ` Vladimir Prus
2006-12-31 16:09 ` Mark Kettenis
2006-12-31 16:21 ` Vladimir Prus
2006-12-31 19:29 ` Daniel Jacobowitz
2006-12-31 22:08 ` Eli Zaretskii
2007-01-01 4:24 ` Nick Roberts
2007-01-01 6:06 ` Eli Zaretskii
2007-01-01 4:07 ` Nick Roberts
2007-01-01 5:58 ` Eli Zaretskii
2007-01-01 22:07 ` Nick Roberts
2007-01-02 4:20 ` Eli Zaretskii
2007-01-16 5:57 ` Nick Roberts
2007-01-16 22:17 ` Eli Zaretskii
2007-01-16 22:30 ` Nick Roberts
2007-01-16 23:01 ` Eli Zaretskii
2007-01-20 17:27 ` Eli Zaretskii
2007-01-20 20:58 ` Nick Roberts
2007-01-27 14:53 ` Eli Zaretskii
2007-01-27 15:10 ` Eli Zaretskii
2007-01-27 22:12 ` Nick Roberts
2007-01-27 22:19 ` Nick Roberts
2007-01-27 22:08 ` Nick Roberts
2007-01-28 4:17 ` Eli Zaretskii
2007-01-28 5:31 ` Nick Roberts
2007-02-02 13:33 ` Eli Zaretskii
2007-02-02 23:28 ` Nick Roberts
2007-02-03 11:10 ` Eli Zaretskii
2007-01-01 9:18 ` Nick Roberts
2007-01-01 16:21 ` Daniel Jacobowitz
2006-12-31 15:34 ` Vladimir Prus
2006-12-31 11:58 ` Mark Kettenis
2006-12-31 7:50 ` Nick Roberts
2006-12-31 18:33 ` Vladimir Prus
2007-01-01 4:18 ` Nick Roberts
2006-12-31 22:10 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17815.23981.229049.700927@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=gdb-patches@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox