commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [VOTE] CLI 1.2 release (RC2)
Date Fri, 27 Feb 2009 09:38:13 GMT
I went ahead and did this. No exceptions - just doing the best it can.

I'll go ahead and kick off a new vote.

On Sat, Feb 21, 2009 at 8:49 PM, Henri Yandell <flamefew@gmail.com> wrote:
> Best way might be to discard the concept that the indent under the
> parameter occurs. Maybe just do 1 or 2 characters. Choosing 2 works
> fine - for some reason 1 causes wrapping to break which is odd.
>
> Also need to add code so it wraps the parameters themselves. Looking
> at it I'm realizing that that is not there. With an auto-adaptation to
> an indent of 2, you get:
>
> ###############
> Header
> -x,--extralongarg
>  This
>  description
>  has
>  ReallyLongVa
> ...
> ###############
>
> Though that does mean a really silly width of 2 probably infinite
> loops. And a width of 1.
>
> I'm starting to get the urge to do CLI 3 :)
>
> Hen
>
> On Fri, Feb 20, 2009 at 9:29 AM, Gary Gregory
> <GGregory@seagullsoftware.com> wrote:
>> Hm... I take it that wrapping to the given width no matter what means a re-write.
WRT to a tiny width, throwing an exception is ok for now but I would imagine that if we had
wrapping that chopped long words it would not be an issue even though the output might look
silly for a width of 2 or 3.
>>
>> Gary
>>
>> -----Original Message-----
>> From: Henri Yandell [mailto:flamefew@gmail.com]
>> Sent: Wednesday, February 18, 2009 11:37 PM
>> To: Commons Developers List
>> Subject: Re: [VOTE] CLI 1.2 release (RC2)
>>
>> I've been digging in a bit further. A few issues:
>>
>> * The 1.0/1.1 feature for a long line is to output it, rather than cut
>> it up as the change below. So this is a feature change, but I agree
>> with you on this being how it should work.
>>
>> * You can still cause infinite loops if you request something silly,
>> ie: the width is less than the flag, longflag and prefix. Previously
>> it used width + arg indent + prefix due to the fixed CLI-151 bug. I
>> think this should be an IllegalArgumentException.
>>
>> Hen
>>
>> On Wed, Feb 18, 2009 at 10:54 PM, Gary Gregory
>> <GGregory@seagullsoftware.com> wrote:
>>> Good news all around.
>>> Thanks Hen,
>>> Gary
>>>
>>> -----Original Message-----
>>> From: Henri Yandell [mailto:flamefew@gmail.com]
>>> Sent: Wednesday, February 18, 2009 9:08 PM
>>> To: Commons Developers List
>>> Subject: Re: [VOTE] CLI 1.2 release (RC2)
>>>
>>> So committed. I thought it would be harder to implement it that way
>>> but turned out to be easier.
>>>
>>> On Wed, Feb 18, 2009 at 9:55 AM, Gary Gregory
>>> <GGregory@seagullsoftware.com> wrote:
>>>> Hi Hen:
>>>>
>>>> In my mind, the width is like a newspaper column, or a page in a book, it
always wraps, no matter what. The issue is how is a word broken up. My vote is to chop and
wrap, so that no matter what, you get all of the text in the given width.
>>>>
>>>> Gary
>>>>
>>>> -----Original Message-----
>>>> From: Henri Yandell [mailto:flamefew@gmail.com]
>>>> Sent: Tuesday, February 17, 2009 9:45 PM
>>>> To: Commons Developers List
>>>> Subject: Re: [VOTE] CLI 1.2 release (RC2)
>>>>
>>>> This is fixed. Now we need to decide what should happen when text is
>>>> too large, do we simply output it or do we break it up.
>>>>
>>>> ie) in your test case Gary, the codehaus url is longer than the space
>>>> you provide to print it. Do you expect it to be cut up or to overrun?
>>>>
>>>> Currently I let it overrun as that code was simpler.
>>>>
>>>> Hen
>>>>
>>>> On Tue, Feb 10, 2009 at 6:55 PM, Henri Yandell <flamefew@gmail.com>
wrote:
>>>>> I had a stab last night, but didn't figure out how the code should
>>>>> look to fix it.
>>>>>
>>>>> Lack of pronoun = "Equally buried :) My 2 jobs at work are behaving
>>>>> like 3 right now. "
>>>>>
>>>>> I'll keep looking, but not turning away anyone else from looking
>>>>> either as it's not immediately obvious.
>>>>>
>>>>> Hen
>>>>>
>>>>> On Tue, Feb 10, 2009 at 1:48 PM, Gary Gregory
>>>>> <GGregory@seagullsoftware.com> wrote:
>>>>>> Hey Hen:
>>>>>>
>>>>>> "So need to figure out how to fix that."
>>>>>>
>>>>>> Can you look into this issue? I'm buried at work here. I'm not sure
if you wanted me to do this due to the missing pronoun ;)
>>>>>>
>>>>>> Thanks,
>>>>>> Gary
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Henri Yandell [mailto:flamefew@gmail.com]
>>>>>> Sent: Monday, February 09, 2009 10:58 PM
>>>>>> To: Commons Developers List
>>>>>> Subject: Re: [VOTE] CLI 1.2 release (RC2)
>>>>>>
>>>>>> If I rollback the change from CLI-162, and comment out the
>>>>>> testInfiniteLoop; your new test also infinite loops. So CLI-162 is
a
>>>>>> sign that something has broken in that class since 1.1, rather than
it
>>>>>> being an existing issue in 1.1.
>>>>>>
>>>>>> Rolling back each commit on HelpFormatter, the issue appears to have
>>>>>> come in with:
>>>>>>
>>>>>> ----
>>>>>> r654428 | bayard | 2008-05-07 23:40:58 -0700 (Wed, 07 May 2008) |
1 line
>>>>>>
>>>>>> Applying J. Lewis Muir's patch from CLI-151 fixing HelpFormatter
so it
>>>>>> wraps properly on multiple lines
>>>>>> ----
>>>>>>
>>>>>> Said patch was:
>>>>>>
>>>>>> Index: src/java/org/apache/commons/cli/HelpFormatter.java
>>>>>> ===================================================================
>>>>>> --- src/java/org/apache/commons/cli/HelpFormatter.java  (revision
654427)
>>>>>> +++ src/java/org/apache/commons/cli/HelpFormatter.java  (revision
654428)
>>>>>> @@ -809,7 +809,7 @@
>>>>>>         while (true)
>>>>>>         {
>>>>>>             text = padding + text.substring(pos).trim();
>>>>>> -            pos = findWrapPos(text, width, nextLineTabStop);
>>>>>> +            pos = findWrapPos(text, width, 0);
>>>>>>
>>>>>>             if (pos == -1)
>>>>>>             {
>>>>>>
>>>>>> So need to figure out how to fix that.
>>>>>>
>>>>>> Hen
>>>>>>
>>>>>> On Mon, Feb 9, 2009 at 10:37 PM, Henri Yandell <flamefew@gmail.com>
wrote:
>>>>>>> Thanks for the update.
>>>>>>>
>>>>>>> It's invoked when I run mvn package:
>>>>>>>
>>>>>>> Running org.apache.commons.cli.bug.BugCLI162Test
>>>>>>> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.013
>>>>>>> sec <<< FAILURE!
>>>>>>>
>>>>>>> Hen
>>>>>>>
>>>>>>> On Mon, Feb 9, 2009 at 8:46 PM, Gary Gregory
>>>>>>> <GGregory@seagullsoftware.com> wrote:
>>>>>>>> Hen:
>>>>>>>>
>>>>>>>> Ok, I've updated the class BugCLI162Test in SVN with a failing
test. Note that BugCLI162Test is not invoked during a Maven build. Is this an omission? How
about an AllTests class for the "bug" package?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Gary Gregory [mailto:GGregory@seagullsoftware.com]
>>>>>>>> Sent: Monday, February 09, 2009 7:58 PM
>>>>>>>> To: Commons Developers List
>>>>>>>> Subject: RE: [VOTE] CLI 1.2 release (RC2)
>>>>>>>>
>>>>>>>> I'll extract a unit test from our code and post a new ticket.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Henri Yandell [mailto:flamefew@gmail.com]
>>>>>>>> Sent: Monday, February 09, 2009 7:10 PM
>>>>>>>> To: Commons Developers List
>>>>>>>> Subject: Re: [VOTE] CLI 1.2 release (RC2)
>>>>>>>>
>>>>>>>> I think it's a showstopper - that was a fix due to infinite
looping
>>>>>>>> causing an OOM. Sounds like you have a test case that isn't
covered by
>>>>>>>> the current tests.
>>>>>>>>
>>>>>>>> Hen
>>>>>>>>
>>>>>>>> On Mon, Feb 9, 2009 at 1:33 PM, Gary Gregory
>>>>>>>> <GGregory@seagullsoftware.com> wrote:
>>>>>>>>> Hello Hen:
>>>>>>>>>
>>>>>>>>> I've encountered a backwards compatibility issue in our
application unit test suite related to [CLI-162].
>>>>>>>>>
>>>>>>>>> With version 1.1, I can print call HelpFormatter#printHelp(String,Options)
without any problems without our options. When I replace 1.1 with 1.2 I get:
>>>>>>>>>
>>>>>>>>> Exception in thread "main" java.lang.RuntimeException:
Text too long for line - throwing exception to avoid infinite loop [CLI-162]:
>>>>>>>>>
>>>>>>>>> Since the only thing that I changed is the CLI version,
I assume that this means that the HelpFormatter format changed between 1.1 and 1.2. Is that
so?
>>>>>>>>>
>>>>>>>>> I worked around this by calling the HelpFormatter API
with a width large enough to avoid the RE. Sadly this makes CLI 1.2 not 100% binary compatible
with 1.1.
>>>>>>>>>
>>>>>>>>> Before I go any further and extract my code into a JIRA
ticket, is this a showstopper? If not, there's plenty of work I need to do before I spin my
wheels on extracting the code.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Henri Yandell [mailto:flamefew@gmail.com]
>>>>>>>>> Sent: Sunday, February 08, 2009 1:01 PM
>>>>>>>>> To: Commons Developers List
>>>>>>>>> Subject: [VOTE] CLI 1.2 release (RC2)
>>>>>>>>>
>>>>>>>>> Apologies for the revote. I've added a note to the release
page to
>>>>>>>>> check the NOTICE file's copyright year.
>>>>>>>>>
>>>>>>>>> There should be no difference between the two other than
the RC1->RC2
>>>>>>>>> in the pom and the updated year in the NOTICE file.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tag:
>>>>>>>>>
>>>>>>>>> https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC2
>>>>>>>>>
>>>>>>>>> Site remains unchanged:
>>>>>>>>>
>>>>>>>>> http://people.apache.org/~bayard/cli-1.2-rc1
>>>>>>>>>
>>>>>>>>> Binaries:
>>>>>>>>>
>>>>>>>>> http://people.apache.org/builds/commons/cli/1.2/RC1/staged/commons-cli/commons-cli/1.2/
>>>>>>>>>
>>>>>>>>> [ ] +1 release it
>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>> [ ] -1 no, do not release it because
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message