Checkin #13345

[Chromatic]

This patch:

--- trunk/compilers/imcc/main.c (original)
+++ trunk/compilers/imcc/main.c Tue Jul 18 01:33:59 2006
@@ -369,7 +369,7 @@
exit(EX_USAGE);
}
if (*argc == opt.opt_index ) {
- fprintf(stderr, "Missing option value or program name\n");
+ fprintf(stderr, "Option %s expects an argument\n", (*argv)[*argc -
1]);
usage(stderr);
exit(EX_USAGE);
}

... provides quite misleading results:

$ parrot -o file.pir
Option file.pir expects an argument
parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-O [level]] [-o FILE] <file>

I don't believe there's a working heuristic for guessing which parameter the
user failed to provide. That's why I didn't write the original version that
way.

-- c

[Audrey Tang]

在 2006/7/18 上午 4:49 時，chromatic 寫到：

> I don't believe there's a working heuristic for guessing which
> parameter the
> user failed to provide. That's why I didn't write the original
> version that
> way.

Does r13347 look better? If not, please revert both my changes.

As an aside, regardless of the three changes, this still segfaults:

./parrot -D 1

as does this:

./parrot ''

Thanks,
Audrey

[Chromatic]

On Tuesday 18 July 2006 02:21, Audrey Tang wrote:

Hi Audrey,

> Does r13347 look better? If not, please revert both my changes.

I think it's still misleading. #13364 is probably as accurate as Parrot can
report.

> As an aside, regardless of the three changes, this still segfaults:
>
> ./parrot -D 1
>
> as does this:
>
> ./parrot ''

I'll work on those. Thanks for the report.

-- c

[Jerry Gay]

On 7/18/06, chromatic <chro...@wgz.org> wrote:
> On Tuesday 18 July 2006 02:21, Audrey Tang wrote:
> > Does r13347 look better? If not, please revert both my changes.
>
> I think it's still misleading. #13364 is probably as accurate as Parrot can
> report.
>

and has the distinction of compiling on windows, too :) # audreyt++
~jerry

[Will Coleda]

# New Ticket Created by Will Coleda
# Please include the string: [perl #39866]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39866 >

[Chromatic]

Sorry, I meant #13367. I forgot to push my change.

-- c

[Audrey Tang]

在 2006/7/18 下午 3:55 時，jerry gay 寫到：

Actually, chromatic meant r13344, not r13364.

Chromatic: Your original commit log noted room for possible
improvements with the English
message, which I interpreted as a invitation to help, and acted
accordingly, but probably
was mistaken, and thereby perceived as rude. I'm sorry about the
miscommunication.

I'd like to apologize publicly for saying that you can revert both my
changes if you think
it's stylistically bad English; I should have said "I'd be willing to
revert to r13344 if
you find inaccuracies with it".

I was already committing a revert to r13344, but it clashed with your
r13367 a few minutes
ago; for the record, I think your freshly-committed r13367 gives far
better error message
than either r13344 or r13364.

It's very hard for me to write tests for English parts of a project,
as they are often
subjective calls. In this particular case, please forgive me for
making a change without
submitting as test+patch first to the mailing list, which I should
have done in the first
place. You would be correct to chide me for abusing my Parrot commit
bit; from now on,
I'll learn to avoid committing anything without a clear consensus
from the parrot porters.

Again, very, very sorry for causing your distress. It was not meant
that way, and I'll
learn to adjust my behavior.

Thanks,
Audrey

[Chromatic]

On Tuesday 18 July 2006 13:38, Audrey Tang wrote:

> Chromatic: Your original commit log noted room for possible
> improvements with the English
> message, which I interpreted as a invitation to help, and acted
> accordingly, but probably
> was mistaken, and thereby perceived as rude. I'm sorry about the
> miscommunication.

To be fair, it was one of my tersest and worst commit messages. I should have
noted why I was unhappy with the error message, as well as the problems I had
in creating a better one. (It was also 1 am local time.)

I hope r13376 was much more clear.

-- c

[Matt Diephouse]

chromatic <chro...@wgz.org> wrote:
> ... provides quite misleading results:
>
> $ parrot -o file.pir
> Option file.pir expects an argument
> parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-O [level]] [-o FILE] <file>
>
> I don't believe there's a working heuristic for guessing which parameter the
> user failed to provide. That's why I didn't write the original version that
> way.

I know I'm a little late to the game here, but in the future it would
be useful to mention this sort of info in a comment in the source. :-)
And a comment might be a nice addition even now.

(You mentioned being more clear in the svn log, but a comment would
really be the most useful.)

--
Matt Diephouse
http://matt.diephouse.com

[Chromatic]

On Tuesday 18 July 2006 19:43, Matt Diephouse wrote:

> I know I'm a little late to the game here, but in the future it would
> be useful to mention this sort of info in a comment in the source. :-)
> And a comment might be a nice addition even now.
>
> (You mentioned being more clear in the svn log, but a comment would
> really be the most useful.)

Something like this?

-- c

[Matt Diephouse]

This is what I ended up applying (inlined because it's already ci'd).
I wanted to get more into why having -o means that we can't tell what
the user forgot to pass. (And having not written any of the code, I
could tell what wasn't immediately clear :-)

--
matt diephouse
http://matt.diephouse.com

--- compilers/imcc/main.c (revision 13376)
+++ compilers/imcc/main.c (working copy)
@@ -368,8 +368,17 @@
usage(stderr);
exit(EX_USAGE);
}
- /* reached the end of the option list and consumed all of argv */
+ /* if we reached the end of the option list and consumed all of argv,
+ * we don't have the name of a program to run */

if (*argc == opt.opt_index ) {

+
+ /* If the user passed the -o flag -- the only flag that must take a
+ * parameter -- then we can't be sure that the user forgot the name of
+ * the program. it could be that the user forgot to give the argument
+ * for -o and the rest of argv got slurped up as flags. (If -o appeared
+ * with no argument, the getopt check would have complained earlier.)
+ *
+ * Given that, this was the best error message we could come up with */
if (interp->output_file) {
fprintf(stderr, "Missing program name or argument for -o\n");
}