Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov writes: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. As long as we're spending time on this, why not just write our own version of getopt_long()? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump.options.diff
Tom Lane writes: As long as we're spending time on this, why not just write our own version of getopt_long()? Seems like a fine idea to me ... who's volunteering? Doing it now... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump.options.diff -- Take III
hmmm... hate to resend it, but i have never seen this passing through...
re-attempt
- Original Message -
From: Serguei Mokhov [EMAIL PROTECTED]
Sent: January 02, 2003 6:37 PM
Subject: Re: [HACKERS] pg_dump.options.diff -- Take III
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Sent: January 02, 2003 6:16 PM
static void
usage(void)
{
#if defined(HAVE_GETOPT_LONG)
#define xo(longOption,shortOption,desc) printf(%s %s\n, longOption, desc)
#else
#define xo(longOption,shortOption,desc) printf(%s %s\n, shortOption, desc)
#endif
... lots of xo() calls ...
#undef xo
}
This gives us the convenience of a very short name within the usage()
subroutines, while not polluting the namespace for everyplace else in
these utilities.
Revised patch attached as per above.
-s
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump.options.diff
On Thu, 2 Jan 2003 01:44:21 -0500, Serguei Mokhov [EMAIL PROTECTED] wrote:
Either way, something has to be donw about this...
Just another way to do it:
#if defined(HAVE_GETOPT_LONG)
#define PARMPREFIX '='
#else
#define PARMPREFIX ' '
#endif
static void
explain_option(char *shortform, char *longform, char *parm, char *desc)
{
int pos = 0;
printf( -%s, shortform);
pos += 3 + strlen(shortform);
#if defined(HAVE_GETOPT_LONG)
printf(, --%s, longform);
pos += 4 + strlen(longform);
#endif
if (parm) {
printf(%c%s, PARMPREFIX, parm);
pos += 1 + strlen(parm);
}/*if*/
printf(%*c, 27 - pos, ' ');
printf(%s\n, desc);
}/*explain_option*/
#define xo explain_option
xo(f, file, FILENAME, output file name);
xo(F, format, c|t|p, output file format (custom, tar, plain text));
xo(i, ignore-version, NULL, proceed even when server version mismatches\n
pg_dump version);
xo(v, verbose, NULL, verbose mode);
xo(Z, compress, 0-9, compression level for compressed formats);
This is only a quick hack, I didn't care for _() and
explain_option() could be smarter about multi line descriptions,
but you get the idea ...
Servus
Manfred
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] pg_dump.options.diff
Manfred Koizar [EMAIL PROTECTED] writes: Just another way to do it: #define xo explain_option xo(f, file, FILENAME, output file name); Perhaps better would be: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%-27s %s\n, long, desc) #else #define xo(long,short,desc) printf(%-27s %s\n, short, desc) #endif xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name)); which avoids putting a lot of smarts (read: restrictions) into the subroutine, but still keeps most of the other benefits, including: * keeping the segments of the description together in the source code, and rationally organized from a translation standpoint; * only one place to change to adjust the column width. Although it occurs to me that with the existing setup, it's possible for the translator to unilaterally alter the column width for the switches, which is something he'd definitely like to be able to do. Maybe we should not try to be cute, but just do #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name)); so that the column spacing remains under control of the translator. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump.options.diff
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: January 02, 2003 9:29 AM Maybe we should not try to be cute, but just do #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name)); so that the column spacing remains under control of the translator. Looks good to me, but there is still a little inconvenience of multiline option descriptions, and the above won't handle it nicely. If people agree with the above, can I go ahead and make corresponding changes? OR may be a whole generic option-formatting routine should be created; one for all the tools? ;-) Similar to explain_option() of Manfred, which will handle the mulitline, padding, and other stuff? (am being half serious here, but it could be an option) -s ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov [EMAIL PROTECTED] writes: Looks good to me, but there is still a little inconvenience of multiline option descriptions, and the above won't handle it nicely. True, a multiline description would have to look like xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name\n more description)); Which is not great, but it doesn't seem completely unworkable either. And the translator can still adjust the column spacing without any code changes. may be a whole generic option-formatting routine should be created; one for all the tools? ;-) Similar to explain_option() of Manfred, which will handle the mulitline, padding, and other stuff? (am being half serious here, but it could be an option) The trouble I see there is that the layout --- in particular the column width --- would be embedded in such a routine and not alterable by simply replacing message texts. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_dump.options.diff
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: January 02, 2003 1:58 PM Serguei Mokhov [EMAIL PROTECTED] writes: Looks good to me, but there is still a little inconvenience of multiline option descriptions, and the above won't handle it nicely. True, a multiline description would have to look like xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name\n more description)); Which is not great, but it doesn't seem completely unworkable either. And the translator can still adjust the column spacing without any code changes. Well, it's better than before and solves *my* (and other translators') problem. Now, this: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. I searched for 'util' the source tree to see a more or less logical place to put it. I got a whole bunch of .*util.* files, but none of them seems appropriate enough because they all specific to some other tool or smth else. Is pushing it up to c.h an option, or it'll become too polluted? Where should I place it? may be a whole generic option-formatting routine should be created; one for all the tools? ;-) Similar to explain_option() of Manfred, which will handle the mulitline, padding, and other stuff? (am being half serious here, but it could be an option) The trouble I see there is that the layout --- in particular the column width --- would be embedded in such a routine and not alterable by simply replacing message texts. True, but what would be wrong by having an argument for the column width? -s ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov [EMAIL PROTECTED] writes: Now, this: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. But there's no good place to put it. I'd say just stick it into each tool; it's no worse than repeating the existence of a usage() subroutine in each tool. Is pushing it up to c.h an option, I'd vote against that. The trouble I see there is that the layout --- in particular the column width --- would be embedded in such a routine and not alterable by simply replacing message texts. True, but what would be wrong by having an argument for the column width? The translator would have no control over such an argument --- at least not without some mechanism outside the .po files. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump.options.diff
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: January 02, 2003 3:20 PM #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. But there's no good place to put it. I'd say just stick it into each tool; it's no worse than repeating the existence of a usage() subroutine in each tool. It ended up being in dumputils.h Attached a patch for pg_dump(all) and pg_restore eliminating dupes in option descriptions as per above xo technology. Please review and apply if there are no too many objections. thank you, -s pg_dump.options2.diff Description: Binary data ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov [EMAIL PROTECTED] writes:
But there's no good place to put it. I'd say just stick it into each
tool; it's no worse than repeating the existence of a usage()
subroutine in each tool.
It ended up being in dumputils.h
I really don't like putting a macro with a name as short as xo into a
header file, even one of relatively narrow scope. It's too likely to
create weird conflicts. My inclination is to make the coding be more
like
static void
usage(void)
{
#if defined(HAVE_GETOPT_LONG)
#define xo(longOption,shortOption,desc) printf(%s %s\n, longOption, desc)
#else
#define xo(longOption,shortOption,desc) printf(%s %s\n, shortOption, desc)
#endif
... lots of xo() calls ...
#undef xo
}
This gives us the convenience of a very short name within the usage()
subroutines, while not polluting the namespace for everyplace else in
these utilities.
As I said before, duplicating the definition of xo() in each file that
uses it doesn't bother me a bit; it's too simple for that to be a
significant objection.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] pg_dump.options.diff
Hello, Happy New Year everyone, Attached is an attempt to eliminate duplicate pg_dump option descriptions, and have a single description for both short and long options. For me, as for a translator, this eliminates the need to maintain the two, exactly same, sets of 24 sentences. If this is accepted, using the same approach I'll go through pg_dumpall and other tools, which suffer from the same exact problem. If it's rejected, please advise of a better way to approach the problem. Needless to say, it is a pain for a translator to properly maintain the two sets of messages for every tool PG got. After all that is settled, I'll send translation patches in. Thank you, -s pg_dump.options.diff pg_dump.options.diff Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov [EMAIL PROTECTED] writes: Attached is an attempt to eliminate duplicate pg_dump option descriptions, and have a single description for both short and long options. For me, as for a translator, this eliminates the need to maintain the two, exactly same, sets of 24 sentences. Offhand, this cure strikes me as much worse than the disease. You've converted code which was understandable, if somewhat repetitious, into code that can be understood by neither programmers nor translators. The text strings have been broken into fragments that don't make any sense individually --- which probably creates translating problems, as well as opportunities for programmer error. I see your complaint, but this doesn't seem like a good way to fix it. Perhaps it would work better to do something like #ifdef HAVE_GETOPT_LONG char* f_option = _(-f, --file=FILENAME ); ... etc ... #else /* not HAVE_GETOPT_LONG */ char* f_option = _(-f FILENAME ); ... etc ... #endif /* not HAVE_GETOPT_LONG */ printf(_( %s output file name\n), f_option); ... etc ... That seems to reduce the amount of duplication without breaking things up into chunks that aren't independent concepts. However, I'm not convinced that the above is better than what we have --- it's really not obvious that the above is more maintainable than #ifdef HAVE_GETOPT_LONG printf(_( -f, --file=FILENAME output file name\n)); #else /* not HAVE_GETOPT_LONG */ printf(_( -f FILENAME output file name\n)); #endif /* not HAVE_GETOPT_LONG */ There are worse things than a little repetitiveness, and creating the opportunity to mismatch a flag with its description may well be one of them. Comments? Can anyone do better? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_dump.options.diff
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: January 02, 2003 1:34 AM Perhaps it would work better to do something like #ifdef HAVE_GETOPT_LONG char* f_option = _(-f, --file=FILENAME ); ... etc ... #else /* not HAVE_GETOPT_LONG */ char* f_option = _(-f FILENAME ); ... etc ... #endif /* not HAVE_GETOPT_LONG */ printf(_( %s output file name\n), f_option); ... etc ... That seems to reduce the amount of duplication without breaking things up into chunks that aren't independent concepts. Thank you for your comment, Tom. A slightly more readable version of the above could be: #ifdef HAVE_GETOPT_LONG char* data_only_option = _(-f, --file=FILENAME ); char* blobs_option = _(-b, --blobs ); ... etc ... #else /* not HAVE_GETOPT_LONG */ char* data_only_option = _(-f FILENAME ); char* blobs_option = _(-b ); ... etc ... #endif /* not HAVE_GETOPT_LONG */ printf(_( %s output file name\n), data_only_option); printf(_( %s include large objects in dump\n), blobs_option); ... etc ... It loos like better than the current setup. Either way, something has to be donw about this... -s ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
