{"thread":{"id":"41720","subject":"[PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","startedAt":"2016-03-16T23:16:58Z","lastAt":"2016-03-20T09:07:01Z","messageCount":8,"participants":["Pranit Bauva","Jeff King","Eric Sunshine"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"280988","messageId":"0102015381b7c7b5-5b57a780-369b-478b-94d2-7094f0befdad-000000@eu-west-1.amazonses.com","threadId":"41720","inReplyTo":null,"subject":"[PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-16T23:16:58Z","receivedAt":"2016-03-16T23:16:58Z","isPatch":true,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"The reason to make it consider negative values or more specifically\n\"unspecified\" values is to differentiate between the option passed\nonce, multiple times or with --no-option. This makes the receiver\nknow what actually happened with the arguments which is particularly\nrequired with option have multiple levels of that option.\n\nEg. :\ninitialize verbose = -1\n`git commit` => verbose = -1\n`git commit -v` => verbose = 1\n`git commit -v -v` => verbose = 1\n`git commit --no-verbose` => verbose = 0\n\nSigned-off-by: Pranit Bauva <pranit.bauva@gmail.com>\n\n---\nThe discussion on the mailing list[1] suggested this approach.\nI plan to include this with my previous patch regarding \"configuration\nfor commonly used command `git commit -v`\" as this is a requirement for\nlatter.\n\n[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027\n---\n Documentation/technical/api-parse-options.txt | 6 ++++--\n parse-options.c                               | 8 +++++++-\n 2 files changed, 11 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt\nindex 5f0757d..a908d8a 100644\n--- a/Documentation/technical/api-parse-options.txt\n+++ b/Documentation/technical/api-parse-options.txt\n@@ -144,8 +144,10 @@ There are some macros to easily define options:\n \n `OPT_COUNTUP(short, long, &int_var, description)`::\n \tIntroduce a count-up option.\n-\t`int_var` is incremented on each use of `--option`, and\n-\treset to zero with `--no-option`.\n+\tIf the `int_var` is negative and `--option` is absent,\n+\tthen it will retain its value. Otherwise it will first set\n+\t`int_var` to 0 and then increment it on each use of `--option`,\n+\tand reset to zero with `--no-option`.\n \n `OPT_BIT(short, long, &int_var, description, mask)`::\n \tIntroduce a boolean option.\ndiff --git a/parse-options.c b/parse-options.c\nindex 47a9192..86d30bd 100644\n--- a/parse-options.c\n+++ b/parse-options.c\n@@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,\n \t\treturn 0;\n \n \tcase OPTION_COUNTUP:\n-\t\t*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;\n+\t\tif (unset)\n+\t\t\t*(int *)opt->value = 0;\n+\t\telse {\n+\t\t\tif (*(int *)opt->value < 0)\n+\t\t\t\t*(int *)opt->value = 0;\n+\t\t\t*(int *)opt->value += 1;\n+\t\t}\n \t\treturn 0;\n \n \tcase OPTION_SET_INT:\n\n--\nhttps://github.com/git/git/pull/212\n"},{"id":"280996","messageId":"20160317015044.GB12830@sigill.intra.peff.net","threadId":"41720","inReplyTo":"0102015381b7c7b5-5b57a780-369b-478b-94d2-7094f0befdad-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-17T01:50:44Z","receivedAt":"2016-03-17T01:50:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 16, 2016 at 11:16:58PM +0000, Pranit Bauva wrote:\n\n> The reason to make it consider negative values or more specifically\n> \"unspecified\" values is to differentiate between the option passed\n> once, multiple times or with --no-option. This makes the receiver\n> know what actually happened with the arguments which is particularly\n> required with option have multiple levels of that option.\n> \n> Eg. :\n> initialize verbose = -1\n> `git commit` => verbose = -1\n> `git commit -v` => verbose = 1\n> `git commit -v -v` => verbose = 1\n> `git commit --no-verbose` => verbose = 0\n\nThis second to last example would be 2, right?\n\nThat aside, this patch does mean that one can no longer use\nOPT_COUNTUP() for negative values (i.e., the caller must start it at\neither 0 or 1, and it must always go up from there).\n\nAnd we would need to verify that all of the existing callers are OK with\nthis. Did you check that that (not rhetorical; I suspect they are all\nOK, but somebody needs to check)?\n\nWe are also changing semantics without changing the interface, which\nmeans any topics in flight (that you _cannot_ review, because you have\nnot seen them yet) may be subtly broken. To me that is not an absolute\ndeal-breaker, but something to weigh against the utility of the change.\n\nWhen looking more carefully at builtin/commit.c for the other thread, it\noccurred to me that OPT_BOOL might be a better fit for commit's \"-v\". It\nreally is a boolean \"show the diff or not\" and thus unlike the other\n\"make me more verbose\". And OPT_BOOL already has the behavior you want,\nI think.\n\n-Peff\n"},{"id":"281007","messageId":"CAPig+cRkAE4BzbgniP=peHE-pBfKt1i2C4MqJcJ36sMfsSh3KQ@mail.gmail.com","threadId":"41720","inReplyTo":"20160317015044.GB12830@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-03-17T07:28:58Z","receivedAt":"2016-03-17T07:28:58Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Mar 16, 2016 at 9:50 PM, Jeff King <peff@peff.net> wrote:\n> On Wed, Mar 16, 2016 at 11:16:58PM +0000, Pranit Bauva wrote:\n>> The reason to make it consider negative values or more specifically\n>> \"unspecified\" values is to differentiate between the option passed\n>> once, multiple times or with --no-option. This makes the receiver\n\nThis is inaccurate and rather confusing. It's not that an\n\"unspecified\" value gives you the ability to \"differentiate between\nonce, multiple time or with --no-option\", but rather that it allows\nyou to determine wether --option or --no-option was encountered at\nall.\n\n>> know what actually happened with the arguments which is particularly\n>> required with option have multiple levels of that option.\n>>\n>> Eg. :\n>> initialize verbose = -1\n>> `git commit` => verbose = -1\n>> `git commit -v` => verbose = 1\n>> `git commit -v -v` => verbose = 1\n>> `git commit --no-verbose` => verbose = 0\n>\n> This second to last example would be 2, right?\n\nRight.\n\nI'm not sure that this example block is helpful, though. A clearer\ncommit message which does a better job of explaining the reason for\nthe change would likely eliminate the need for an example.\n\n> That aside, this patch does mean that one can no longer use\n> OPT_COUNTUP() for negative values (i.e., the caller must start it at\n> either 0 or 1, and it must always go up from there).\n>\n> And we would need to verify that all of the existing callers are OK with\n> this. Did you check that that (not rhetorical; I suspect they are all\n> OK, but somebody needs to check)?\n>\n> We are also changing semantics without changing the interface, which\n> means any topics in flight (that you _cannot_ review, because you have\n> not seen them yet) may be subtly broken. To me that is not an absolute\n> deal-breaker, but something to weigh against the utility of the change.\n\nIndeed, I was envisioning a more conservative approach of having\nOPT__VERBOSE use a custom callback or perhaps introducing a new\n'flags' value or even (probably too ugly) abusing the 'defval' field\nto specially indicate that it wants the \"negative means unspecified\"\nbehavior; the other consumers of OPT_COUNTUP would not request this\nspecial behavior. But, as you say, changing the behavior of\nOPT_COUNTUP unconditionally may not be a deal-breaker.\n\nI also realized that Pranit can achieve the desired behavior without\nmodifying OPT__VERBOSE at all. Specifically, rather than initializing\nhis opt_verbose variable to -1, he can instead initialize it to 1.\nThen:\n\n* if --verbose is seen (one or more times), opt_verbose will be >=2,\nand the real verbosity level will be (opt_verbose - 1)\n\n* if --no-verbose is seen, opt_verbose will be 0\n\n* if neither is seen, then opt_verbose will remain 1\n\nHowever, I think this approach is far too ugly and non-obvious to\nseriously suggest using it, whereas the change to OPT__VERBOSE is\neasily understood and could prove useful in the future for other\ncommands with multiple verbosity levels.\n\n> When looking more carefully at builtin/commit.c for the other thread, it\n> occurred to me that OPT_BOOL might be a better fit for commit's \"-v\". It\n> really is a boolean \"show the diff or not\" and thus unlike the other\n> \"make me more verbose\". And OPT_BOOL already has the behavior you want,\n> I think.\n\nFor completeness (for readers of this thread), it was pointed out in\nthe other thread[1] that git-commit does indeed recognize multiple\nverbosity levels, so changing it to use OPT_BOOL would be undesirable\n(wrong).\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289074\n"},{"id":"281014","messageId":"CAPig+cTi7biYK7=P07-VZvA=d6mwgsdYxZG_vvVm7sRj2fcu6Q@mail.gmail.com","threadId":"41720","inReplyTo":"CAPig+cRkAE4BzbgniP=peHE-pBfKt1i2C4MqJcJ36sMfsSh3KQ@mail.gmail.com","subject":"Re: [PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-03-17T08:14:47Z","receivedAt":"2016-03-17T08:14:47Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Mar 17, 2016 at 3:28 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n> I also realized that Pranit can achieve the desired behavior without\n> modifying OPT__VERBOSE at all. Specifically, rather than initializing\n> his opt_verbose variable to -1, he can instead initialize it to 1.\n> Then:\n>\n> * if --verbose is seen (one or more times), opt_verbose will be >=2,\n> and the real verbosity level will be (opt_verbose - 1)\n>\n> * if --no-verbose is seen, opt_verbose will be 0\n>\n> * if neither is seen, then opt_verbose will remain 1\n\nEh, this is bogus. \"git commit --no-verbose --verbose\" would leave\nopt_verbose at 1, which would fool it into thinking neither had been\nseen.\n\nThus, a further +1 for an OPT__VERBOSE which understands \"unspecified\".\n\n> However, I think this approach is far too ugly and non-obvious to\n> seriously suggest using it, whereas the change to OPT__VERBOSE is\n> easily understood and could prove useful in the future for other\n> commands with multiple verbosity levels.\n"},{"id":"281080","messageId":"CAFZEwPPJ37+Yc1ANoOEcniOTpocKVUsXkh1fKoJr50-=ZcCp+Q@mail.gmail.com","threadId":"41720","inReplyTo":"CAPig+cRkAE4BzbgniP=peHE-pBfKt1i2C4MqJcJ36sMfsSh3KQ@mail.gmail.com","subject":"Re: [PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-17T20:22:13Z","receivedAt":"2016-03-17T20:22:13Z","isPatch":true,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Thu, Mar 17, 2016 at 12:58 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n> On Wed, Mar 16, 2016 at 9:50 PM, Jeff King <peff@peff.net> wrote:\n>> On Wed, Mar 16, 2016 at 11:16:58PM +0000, Pranit Bauva wrote:\n>>> The reason to make it consider negative values or more specifically\n>>> \"unspecified\" values is to differentiate between the option passed\n>>> once, multiple times or with --no-option. This makes the receiver\n>\n> This is inaccurate and rather confusing. It's not that an\n> \"unspecified\" value gives you the ability to \"differentiate between\n> once, multiple time or with --no-option\", but rather that it allows\n> you to determine wether --option or --no-option was encountered at\n> all.\n\nI guess the language wasn't very clear. I will change this.\n\n>>> know what actually happened with the arguments which is particularly\n>>> required with option have multiple levels of that option.\n>>>\n>>> Eg. :\n>>> initialize verbose = -1\n>>> `git commit` => verbose = -1\n>>> `git commit -v` => verbose = 1\n>>> `git commit -v -v` => verbose = 1\n>>> `git commit --no-verbose` => verbose = 0\n>>\n>> This second to last example would be 2, right?\n>\n> Right.\n\nMy bad, it should be 2.\n\n>\n> I'm not sure that this example block is helpful, though. A clearer\n> commit message which does a better job of explaining the reason for\n> the change would likely eliminate the need for an example.\n>\n>> That aside, this patch does mean that one can no longer use\n>> OPT_COUNTUP() for negative values (i.e., the caller must start it at\n>> either 0 or 1, and it must always go up from there).\n>>\n>> And we would need to verify that all of the existing callers are OK with\n>> this. Did you check that that (not rhetorical; I suspect they are all\n>> OK, but somebody needs to check)?\n>>\n>> We are also changing semantics without changing the interface, which\n>> means any topics in flight (that you _cannot_ review, because you have\n>> not seen them yet) may be subtly broken. To me that is not an absolute\n>> deal-breaker, but something to weigh against the utility of the change.\n>\n> Indeed, I was envisioning a more conservative approach of having\n> OPT__VERBOSE use a custom callback or perhaps introducing a new\n> 'flags' value or even (probably too ugly) abusing the 'defval' field\n> to specially indicate that it wants the \"negative means unspecified\"\n> behavior; the other consumers of OPT_COUNTUP would not request this\n> special behavior. But, as you say, changing the behavior of\n> OPT_COUNTUP unconditionally may not be a deal-breaker.\n>\n> I also realized that Pranit can achieve the desired behavior without\n> modifying OPT__VERBOSE at all. Specifically, rather than initializing\n> his opt_verbose variable to -1, he can instead initialize it to 1.\n> Then:\n>\n> * if --verbose is seen (one or more times), opt_verbose will be >=2,\n> and the real verbosity level will be (opt_verbose - 1)\n>\n> * if --no-verbose is seen, opt_verbose will be 0\n>\n> * if neither is seen, then opt_verbose will remain 1\n>\n> However, I think this approach is far too ugly and non-obvious to\n> seriously suggest using it, whereas the change to OPT__VERBOSE is\n> easily understood and could prove useful in the future for other\n> commands with multiple verbosity levels.\n>\n>> When looking more carefully at builtin/commit.c for the other thread, it\n>> occurred to me that OPT_BOOL might be a better fit for commit's \"-v\". It\n>> really is a boolean \"show the diff or not\" and thus unlike the other\n>> \"make me more verbose\". And OPT_BOOL already has the behavior you want,\n>> I think.\n>\n> For completeness (for readers of this thread), it was pointed out in\n> the other thread[1] that git-commit does indeed recognize multiple\n> verbosity levels, so changing it to use OPT_BOOL would be undesirable\n> (wrong).\n>\n> [1]: http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289074\n"},{"id":"281141","messageId":"CAFZEwPOib-3JJQ+ufAbmNf1HYb5003LJw_paF2s9L8OK59N0PQ@mail.gmail.com","threadId":"41720","inReplyTo":"20160317015044.GB12830@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-18T11:23:34Z","receivedAt":"2016-03-18T11:23:34Z","isPatch":true,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"Sorry for a little late reply. I was under the impression that I had\nreplied before.\n\nOn Thu, Mar 17, 2016 at 7:20 AM, Jeff King <peff@peff.net> wrote:\n\n> That aside, this patch does mean that one can no longer use\n> OPT_COUNTUP() for negative values (i.e., the caller must start it at\n> either 0 or 1, and it must always go up from there).\n>\n>\n> And we would need to verify that all of the existing callers are OK with\n> this. Did you check that that (not rhetorical; I suspect they are all\n> OK, but somebody needs to check)?\n\nI did a grep on parse-options.h and saw that only \"verbose\", \"quiet\"\nand \"force\" use OPT_COUNTUP().\nI then did a git grep for \"verbose = -1\", \"quiet = -1\"\nBut with \"force = -1\" showed that \"builtin/clean.c\" uses it. On a bit\ncareful examination, this patch would not make difference to it.\n\n> We are also changing semantics without changing the interface, which\n> means any topics in flight (that you _cannot_ review, because you have\n> not seen them yet) may be subtly broken. To me that is not an absolute\n> deal-breaker, but something to weigh against the utility of the change.\n\nAs I am new here, I don't really know how to go about with this. Could\nyou describe in a little detail so that I can work on it?\n> When looking more carefully at builtin/commit.c for the other thread, it\n> occurred to me that OPT_BOOL might be a better fit for commit's \"-v\". It\n> really is a boolean \"show the diff or not\" and thus unlike the other\n> \"make me more verbose\". And OPT_BOOL already has the behavior you want,\n> I think.\n>\n> -Peff\n"},{"id":"281254","messageId":"20160320041009.GA18312@sigill.intra.peff.net","threadId":"41720","inReplyTo":"CAFZEwPOib-3JJQ+ufAbmNf1HYb5003LJw_paF2s9L8OK59N0PQ@mail.gmail.com","subject":"Re: [PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-20T04:10:10Z","receivedAt":"2016-03-20T04:10:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 18, 2016 at 04:53:34PM +0530, Pranit Bauva wrote:\n\n> > And we would need to verify that all of the existing callers are OK with\n> > this. Did you check that that (not rhetorical; I suspect they are all\n> > OK, but somebody needs to check)?\n> \n> I did a grep on parse-options.h and saw that only \"verbose\", \"quiet\"\n> and \"force\" use OPT_COUNTUP().\n> I then did a git grep for \"verbose = -1\", \"quiet = -1\"\n> But with \"force = -1\" showed that \"builtin/clean.c\" uses it. On a bit\n> careful examination, this patch would not make difference to it.\n\nYeah, I see that it handles the config for force separately, and then\nmunges the \"-1\" into 0 before we get to parse_options.\n\nThere are uses of COUNTUP in cmd_hash_object() and test-parse-options.c,\nbut I think they are both fine.\n\nGrepping for \"verbose = -1\" would miss any cases where we call the\nargument something else (e.g., apply_verbosely). So I think it would be\nmore thorough to grep for OPT__VERBOSE, etc, and then follow-up on\nwhatever variable they use.\n\nI just did so, and I didn't see any problems.\n\n> > We are also changing semantics without changing the interface, which\n> > means any topics in flight (that you _cannot_ review, because you have\n> > not seen them yet) may be subtly broken. To me that is not an absolute\n> > deal-breaker, but something to weigh against the utility of the change.\n> \n> As I am new here, I don't really know how to go about with this. Could\n> you describe in a little detail so that I can work on it?\n\nA more canonical example is changing a function return value. Imagine I\nhave a function which returns \"1\" for success and \"0\" for error, and I\nwant to change it to return \"0\" for success and \"-1\" for error. If I do\nso and update each caller, then merging with a branch that has a new\ncaller will not result in any conflicts (there is no textual link\nbetween the callers and the function), but the result will be subtly\nbroken (the new caller will get the error-check wrong).\n\nSo we generally try to find some way that the compiler will notice the\nbreakage. E.g., if the function changes name when the return value\nsemantics change, or if it gains a new argument at the same time, then\nthe compiler will notice and complain. We still have to fix it up during\nthe merge, of course, but it's easy to spot.\n\nLikewise here. If you change the semantics of OPT_COUNTUP(), then any\nbranch which introduces a new use of \"int foo = -1\" and expects the old\nsemantics will be subtly broken.\n\nThe obvious fix would be to switch the name (to OPT_COUNTUP_DEFAULT() or\nsomething). But that's a bit painful, as almost nobody uses COUNTUP\ndirectly, so we'd need OPT__VERBOSE_DEFAULT().\n\nI do think we could also declare that it's sufficiently unlikely for\nsomebody to have been using the old semantics for OPT_COUNTUP() with\na negative integer (as it does not really do anything useful), and just\naccept the risk.\n\nWhich in the end is the same as ignoring the problem in the first place,\nbut there is a big difference between not thinking about the problem,\nand thinking about it and deciding it's not a problem. :)\n\n-Peff\n"},{"id":"281267","messageId":"CAFZEwPM2XZzGuVBRoQt1e8uVvfd3_b9h2-j+vCe3XymW6kjRsg@mail.gmail.com","threadId":"41720","inReplyTo":"20160320041009.GA18312@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] parse-options.c: make OPTION__COUNTUP consider negative values","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-20T09:07:01Z","receivedAt":"2016-03-20T09:07:01Z","isPatch":true,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Sun, Mar 20, 2016 at 9:40 AM, Jeff King <peff@peff.net> wrote:\n>> > We are also changing semantics without changing the interface, which\n>> > means any topics in flight (that you _cannot_ review, because you have\n>> > not seen them yet) may be subtly broken. To me that is not an absolute\n>> > deal-breaker, but something to weigh against the utility of the change.\n>>\n>> As I am new here, I don't really know how to go about with this. Could\n>> you describe in a little detail so that I can work on it?\n>\n> A more canonical example is changing a function return value. Imagine I\n> have a function which returns \"1\" for success and \"0\" for error, and I\n> want to change it to return \"0\" for success and \"-1\" for error. If I do\n> so and update each caller, then merging with a branch that has a new\n> caller will not result in any conflicts (there is no textual link\n> between the callers and the function), but the result will be subtly\n> broken (the new caller will get the error-check wrong).\n>\n> So we generally try to find some way that the compiler will notice the\n> breakage. E.g., if the function changes name when the return value\n> semantics change, or if it gains a new argument at the same time, then\n> the compiler will notice and complain. We still have to fix it up during\n> the merge, of course, but it's easy to spot.\n>\n> Likewise here. If you change the semantics of OPT_COUNTUP(), then any\n> branch which introduces a new use of \"int foo = -1\" and expects the old\n> semantics will be subtly broken.\n>\n> The obvious fix would be to switch the name (to OPT_COUNTUP_DEFAULT() or\n> something). But that's a bit painful, as almost nobody uses COUNTUP\n> directly, so we'd need OPT__VERBOSE_DEFAULT().\n\nThis is quite new to me. It took me some time to digest it.\n\n> Which in the end is the same as ignoring the problem in the first place,\n> but there is a big difference between not thinking about the problem,\n> and thinking about it and deciding it's not a problem. :)\nTrue That! ;)\n\nRegards,\nPranit Bauva\n"}]}