You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2016/11/04 15:27:35 UTC
Gfsh Parsing
We have several jira issues related to gfsh parsing (GEODE-1598,
GEODE-1912). After spending some time understanding how the parsing works,
I found out we have three components intertwined together all trying to do
parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
outcome is I am able to maintain the current parsing and tabbing completion
capabilities (and fix a few bugs) by removing 40+ files. The only
difference I see so far lies in the help and hint messages. It seems the
main reason we are using these home backed Gfsh parsing is to provide more
readable help messages. Below are the differences:
Using Spring Shell's provided help:
Using Gfsh Parsing with JoptSimple:
I do like the outcome of the latter, but added complexity of the code is
too expensive to bear. So I am asking the community how important it is to
maintain the current style of help? Can we do with the cheaper way by just
using whatever provided by the libraries?
--
Cheers
Jinmei
Re: Gfsh Parsing
Posted by Kevin Duling <kd...@pivotal.io>.
+1
On Fri, Nov 4, 2016 at 11:14 AM, Jens Deppe <jd...@pivotal.io> wrote:
> One of the 'features' of the current output is for the text to be able to
> indicate whether the command is currently available or not. Personally I
> don't think there's much value to that. If necessary, more information
> could always be added to the help text.
>
> Definitely +1 for removing code complexity.
>
> --Jens
>
> On Fri, Nov 4, 2016 at 11:06 AM, Jared Stewart <js...@pivotal.io>
> wrote:
>
> > Huge +1 to the idea of simplifying Gfsh parsing. I find the green help
> > text from Spring Shell too be less readable then the black text from
> > JoptSimple, but I assume we can configure that to our choosing.
> >
> > > On Nov 4, 2016, at 10:05 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> > >
> > > This is a good idea. I'll reach out to find it out. Thanks!
> > >
> > > On Fri, Nov 4, 2016 at 9:48 AM, Michael Stolz <ms...@pivotal.io>
> wrote:
> > >
> > >> Can we suggest improvements to the Spring help capabilities? The
> Spring
> > >> community tends to be very responsive to good suggestions.
> > >>
> > >> --
> > >> Mike Stolz
> > >> Principal Engineer - Gemfire Product Manager
> > >> Mobile: 631-835-4771
> > >> On Nov 4, 2016 8:27 AM, "Jinmei Liao" <ji...@pivotal.io> wrote:
> > >>
> > >>> We have several jira issues related to gfsh parsing (GEODE-1598,
> > >>> GEODE-1912). After spending some time understanding how the parsing
> > >> works,
> > >>> I found out we have three components intertwined together all trying
> to
> > >> do
> > >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment
> by
> > >>> getting rid of Gfsh and JoptSimple parsing and only using Spring
> Shell.
> > >> The
> > >>> outcome is I am able to maintain the current parsing and tabbing
> > >> completion
> > >>> capabilities (and fix a few bugs) by removing 40+ files. The only
> > >>> difference I see so far lies in the help and hint messages. It seems
> > the
> > >>> main reason we are using these home backed Gfsh parsing is to provide
> > >> more
> > >>> readable help messages. Below are the differences:
> > >>>
> > >>> Using Spring Shell's provided help:
> > >>>
> > >>> Using Gfsh Parsing with JoptSimple:
> > >>>
> > >>>
> > >>>
> > >>> I do like the outcome of the latter, but added complexity of the
> code
> > is
> > >>> too expensive to bear. So I am asking the community how important it
> is
> > >> to
> > >>> maintain the current style of help? Can we do with the cheaper way by
> > >> just
> > >>> using whatever provided by the libraries?
> > >>>
> > >>> --
> > >>> Cheers
> > >>>
> > >>> Jinmei
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> >
> >
>
Re: Gfsh Parsing
Posted by Jens Deppe <jd...@pivotal.io>.
One of the 'features' of the current output is for the text to be able to
indicate whether the command is currently available or not. Personally I
don't think there's much value to that. If necessary, more information
could always be added to the help text.
Definitely +1 for removing code complexity.
--Jens
On Fri, Nov 4, 2016 at 11:06 AM, Jared Stewart <js...@pivotal.io> wrote:
> Huge +1 to the idea of simplifying Gfsh parsing. I find the green help
> text from Spring Shell too be less readable then the black text from
> JoptSimple, but I assume we can configure that to our choosing.
>
> > On Nov 4, 2016, at 10:05 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > This is a good idea. I'll reach out to find it out. Thanks!
> >
> > On Fri, Nov 4, 2016 at 9:48 AM, Michael Stolz <ms...@pivotal.io> wrote:
> >
> >> Can we suggest improvements to the Spring help capabilities? The Spring
> >> community tends to be very responsive to good suggestions.
> >>
> >> --
> >> Mike Stolz
> >> Principal Engineer - Gemfire Product Manager
> >> Mobile: 631-835-4771
> >> On Nov 4, 2016 8:27 AM, "Jinmei Liao" <ji...@pivotal.io> wrote:
> >>
> >>> We have several jira issues related to gfsh parsing (GEODE-1598,
> >>> GEODE-1912). After spending some time understanding how the parsing
> >> works,
> >>> I found out we have three components intertwined together all trying to
> >> do
> >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> >>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell.
> >> The
> >>> outcome is I am able to maintain the current parsing and tabbing
> >> completion
> >>> capabilities (and fix a few bugs) by removing 40+ files. The only
> >>> difference I see so far lies in the help and hint messages. It seems
> the
> >>> main reason we are using these home backed Gfsh parsing is to provide
> >> more
> >>> readable help messages. Below are the differences:
> >>>
> >>> Using Spring Shell's provided help:
> >>>
> >>> Using Gfsh Parsing with JoptSimple:
> >>>
> >>>
> >>>
> >>> I do like the outcome of the latter, but added complexity of the code
> is
> >>> too expensive to bear. So I am asking the community how important it is
> >> to
> >>> maintain the current style of help? Can we do with the cheaper way by
> >> just
> >>> using whatever provided by the libraries?
> >>>
> >>> --
> >>> Cheers
> >>>
> >>> Jinmei
> >>>
> >>
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
>
>
Re: Gfsh Parsing
Posted by Jared Stewart <js...@pivotal.io>.
Huge +1 to the idea of simplifying Gfsh parsing. I find the green help text from Spring Shell too be less readable then the black text from JoptSimple, but I assume we can configure that to our choosing.
> On Nov 4, 2016, at 10:05 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> This is a good idea. I'll reach out to find it out. Thanks!
>
> On Fri, Nov 4, 2016 at 9:48 AM, Michael Stolz <ms...@pivotal.io> wrote:
>
>> Can we suggest improvements to the Spring help capabilities? The Spring
>> community tends to be very responsive to good suggestions.
>>
>> --
>> Mike Stolz
>> Principal Engineer - Gemfire Product Manager
>> Mobile: 631-835-4771
>> On Nov 4, 2016 8:27 AM, "Jinmei Liao" <ji...@pivotal.io> wrote:
>>
>>> We have several jira issues related to gfsh parsing (GEODE-1598,
>>> GEODE-1912). After spending some time understanding how the parsing
>> works,
>>> I found out we have three components intertwined together all trying to
>> do
>>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
>>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell.
>> The
>>> outcome is I am able to maintain the current parsing and tabbing
>> completion
>>> capabilities (and fix a few bugs) by removing 40+ files. The only
>>> difference I see so far lies in the help and hint messages. It seems the
>>> main reason we are using these home backed Gfsh parsing is to provide
>> more
>>> readable help messages. Below are the differences:
>>>
>>> Using Spring Shell's provided help:
>>>
>>> Using Gfsh Parsing with JoptSimple:
>>>
>>>
>>>
>>> I do like the outcome of the latter, but added complexity of the code is
>>> too expensive to bear. So I am asking the community how important it is
>> to
>>> maintain the current style of help? Can we do with the cheaper way by
>> just
>>> using whatever provided by the libraries?
>>>
>>> --
>>> Cheers
>>>
>>> Jinmei
>>>
>>
>
>
>
> --
> Cheers
>
> Jinmei
Re: Gfsh Parsing
Posted by Jinmei Liao <ji...@pivotal.io>.
This is a good idea. I'll reach out to find it out. Thanks!
On Fri, Nov 4, 2016 at 9:48 AM, Michael Stolz <ms...@pivotal.io> wrote:
> Can we suggest improvements to the Spring help capabilities? The Spring
> community tends to be very responsive to good suggestions.
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
> On Nov 4, 2016 8:27 AM, "Jinmei Liao" <ji...@pivotal.io> wrote:
>
> > We have several jira issues related to gfsh parsing (GEODE-1598,
> > GEODE-1912). After spending some time understanding how the parsing
> works,
> > I found out we have three components intertwined together all trying to
> do
> > parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> > getting rid of Gfsh and JoptSimple parsing and only using Spring Shell.
> The
> > outcome is I am able to maintain the current parsing and tabbing
> completion
> > capabilities (and fix a few bugs) by removing 40+ files. The only
> > difference I see so far lies in the help and hint messages. It seems the
> > main reason we are using these home backed Gfsh parsing is to provide
> more
> > readable help messages. Below are the differences:
> >
> > Using Spring Shell's provided help:
> >
> > Using Gfsh Parsing with JoptSimple:
> >
> >
> >
> > I do like the outcome of the latter, but added complexity of the code is
> > too expensive to bear. So I am asking the community how important it is
> to
> > maintain the current style of help? Can we do with the cheaper way by
> just
> > using whatever provided by the libraries?
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: Gfsh Parsing
Posted by Michael Stolz <ms...@pivotal.io>.
Can we suggest improvements to the Spring help capabilities? The Spring
community tends to be very responsive to good suggestions.
--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Nov 4, 2016 8:27 AM, "Jinmei Liao" <ji...@pivotal.io> wrote:
> We have several jira issues related to gfsh parsing (GEODE-1598,
> GEODE-1912). After spending some time understanding how the parsing works,
> I found out we have three components intertwined together all trying to do
> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
> outcome is I am able to maintain the current parsing and tabbing completion
> capabilities (and fix a few bugs) by removing 40+ files. The only
> difference I see so far lies in the help and hint messages. It seems the
> main reason we are using these home backed Gfsh parsing is to provide more
> readable help messages. Below are the differences:
>
> Using Spring Shell's provided help:
>
> Using Gfsh Parsing with JoptSimple:
>
>
>
> I do like the outcome of the latter, but added complexity of the code is
> too expensive to bear. So I am asking the community how important it is to
> maintain the current style of help? Can we do with the cheaper way by just
> using whatever provided by the libraries?
>
> --
> Cheers
>
> Jinmei
>
Re: Gfsh Parsing
Posted by Kenneth Howe <kh...@pivotal.io>.
Thanks!
A problem for me with the Spring Shell output is the lack of the command syntax summary.
Ken
> On Nov 4, 2016, at 8:38 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> --resend with attachments
>
> We have several jira issues related to gfsh parsing (GEODE-1598, GEODE-1912). After spending some time understanding how the parsing works, I found out we have three components intertwined together all trying to do parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The outcome is I am able to maintain the current parsing and tabbing completion capabilities (and fix a few bugs) by removing 40+ files. The only difference I see so far lies in the help and hint messages. It seems the main reason we are using these home backed Gfsh parsing is to provide more readable help messages. Below are the differences:
>
> Using Spring Shell's provided help:
> <Screen Shot 2016-11-04 at 8.19.02 AM.png>
>
> Using Gfsh Parsing with JoptSimple:
>
> <Screen Shot 2016-11-04 at 8.21.45 AM.png>
>
> I do like the outcome of the latter, but added complexity of the code is too expensive to bear. So I am asking the community how important it is to maintain the current style of help? Can we do with the cheaper way by just using whatever provided by the libraries?
>
> --
> Cheers
>
> Jinmei
>
>
>
> --
> Cheers
>
> Jinmei
Re: Gfsh Parsing
Posted by Jinmei Liao <ji...@pivotal.io>.
Hi, it would be nice to know what kind of GFSH Parser api you are using?
Are you specifically using GfshParser or just the execution result?
On Fri, Nov 4, 2016 at 9:51 AM, Real Wes <Th...@outlook.com> wrote:
> I call the GFSH Parser from code and rely on the formatting of the return
> message to determine the response. So I’d like to see that code as
> encapsulated in one place.
>
> > On Nov 4, 2016, at 11:38 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> >
> > We have several jira issues related to gfsh parsing (GEODE-1598,
> > GEODE-1912). After spending some time understanding how the parsing
> works,
> > I found out we have three components intertwined together all trying to
> do
> > parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> > getting rid of Gfsh and JoptSimple parsing and only using Spring Shell.
> The
> > outcome is I am able to maintain the current parsing and tabbing
> completion
> > capabilities (and fix a few bugs) by removing 40+ files. The only
> > difference I see so far lies in the help and hint messages. It seems the
> > main reason we are using these home backed Gfsh parsing is to provide
> more
> > readable help messages. Below are the differences:
> >
> > Using Spring Shell's provided help:
> >
> > Using Gfsh Parsing with JoptSimple:
> >
> >
> > I do like the outcome of the latter, but added complexity of the code is
> > too expensive to bear. So I am asking the community how important it is
> to
> > maintain the current style of help? Can we do with the cheaper way by
> just
> > using whatever provided by the libraries?
> >
> > Cheers
> >
> > Jinmei
> >
>
>
--
Cheers
Jinmei
Re: Gfsh Parsing
Posted by Dan Smith <ds...@pivotal.io>.
+1 for simplifying the parsing and using spring shell.
-Dan
On Fri, Nov 4, 2016 at 1:42 PM, Real Wes <Th...@outlook.com> wrote:
> That would be a really good implementation since it would keep production
> code from relying on the formatting of the GFSH return message. If you did
> —output=json, then the call to the GfshParser could possibly involve
> non-internal classes, which would be even nicer.
>
> > On Nov 4, 2016, at 4:31 PM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> > Wes, I think it would be interesting if we added a new option
> ‘--output=json’ to better handle the use case you described. Then you
> could pipe the gfsh command through a json parser like jq.
> >
> > Anthony
> >
> >> On Nov 4, 2016, at 9:51 AM, Real Wes <Th...@outlook.com> wrote:
> >>
> >> I call the GFSH Parser from code and rely on the formatting of the
> return message to determine the response. So I’d like to see that code as
> encapsulated in one place.
> >>
> >>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> >>>
> >>>
> >>> We have several jira issues related to gfsh parsing (GEODE-1598,
> >>> GEODE-1912). After spending some time understanding how the parsing
> works,
> >>> I found out we have three components intertwined together all trying
> to do
> >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> >>> getting rid of Gfsh and JoptSimple parsing and only using Spring
> Shell. The
> >>> outcome is I am able to maintain the current parsing and tabbing
> completion
> >>> capabilities (and fix a few bugs) by removing 40+ files. The only
> >>> difference I see so far lies in the help and hint messages. It seems
> the
> >>> main reason we are using these home backed Gfsh parsing is to provide
> more
> >>> readable help messages. Below are the differences:
> >>>
> >>> Using Spring Shell's provided help:
> >>>
> >>> Using Gfsh Parsing with JoptSimple:
> >>>
> >>>
> >>> I do like the outcome of the latter, but added complexity of the code
> is
> >>> too expensive to bear. So I am asking the community how important it
> is to
> >>> maintain the current style of help? Can we do with the cheaper way by
> just
> >>> using whatever provided by the libraries?
> >>>
> >>> Cheers
> >>>
> >>> Jinmei
> >>>
> >>
> >
>
>
Re: Gfsh Parsing
Posted by Real Wes <Th...@outlook.com>.
That would be a really good implementation since it would keep production code from relying on the formatting of the GFSH return message. If you did —output=json, then the call to the GfshParser could possibly involve non-internal classes, which would be even nicer.
> On Nov 4, 2016, at 4:31 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> Wes, I think it would be interesting if we added a new option ‘--output=json’ to better handle the use case you described. Then you could pipe the gfsh command through a json parser like jq.
>
> Anthony
>
>> On Nov 4, 2016, at 9:51 AM, Real Wes <Th...@outlook.com> wrote:
>>
>> I call the GFSH Parser from code and rely on the formatting of the return message to determine the response. So I’d like to see that code as encapsulated in one place.
>>
>>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>>>
>>>
>>> We have several jira issues related to gfsh parsing (GEODE-1598,
>>> GEODE-1912). After spending some time understanding how the parsing works,
>>> I found out we have three components intertwined together all trying to do
>>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
>>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
>>> outcome is I am able to maintain the current parsing and tabbing completion
>>> capabilities (and fix a few bugs) by removing 40+ files. The only
>>> difference I see so far lies in the help and hint messages. It seems the
>>> main reason we are using these home backed Gfsh parsing is to provide more
>>> readable help messages. Below are the differences:
>>>
>>> Using Spring Shell's provided help:
>>>
>>> Using Gfsh Parsing with JoptSimple:
>>>
>>>
>>> I do like the outcome of the latter, but added complexity of the code is
>>> too expensive to bear. So I am asking the community how important it is to
>>> maintain the current style of help? Can we do with the cheaper way by just
>>> using whatever provided by the libraries?
>>>
>>> Cheers
>>>
>>> Jinmei
>>>
>>
>
Re: Gfsh Parsing
Posted by Anthony Baker <ab...@pivotal.io>.
Wes, I think it would be interesting if we added a new option ‘--output=json’ to better handle the use case you described. Then you could pipe the gfsh command through a json parser like jq.
Anthony
> On Nov 4, 2016, at 9:51 AM, Real Wes <Th...@outlook.com> wrote:
>
> I call the GFSH Parser from code and rely on the formatting of the return message to determine the response. So I’d like to see that code as encapsulated in one place.
>
>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>>
>>
>> We have several jira issues related to gfsh parsing (GEODE-1598,
>> GEODE-1912). After spending some time understanding how the parsing works,
>> I found out we have three components intertwined together all trying to do
>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
>> outcome is I am able to maintain the current parsing and tabbing completion
>> capabilities (and fix a few bugs) by removing 40+ files. The only
>> difference I see so far lies in the help and hint messages. It seems the
>> main reason we are using these home backed Gfsh parsing is to provide more
>> readable help messages. Below are the differences:
>>
>> Using Spring Shell's provided help:
>>
>> Using Gfsh Parsing with JoptSimple:
>>
>>
>> I do like the outcome of the latter, but added complexity of the code is
>> too expensive to bear. So I am asking the community how important it is to
>> maintain the current style of help? Can we do with the cheaper way by just
>> using whatever provided by the libraries?
>>
>> Cheers
>>
>> Jinmei
>>
>
Re: Gfsh Parsing
Posted by Real Wes <Th...@outlook.com>.
I call the GFSH Parser from code and rely on the formatting of the return message to determine the response. So I’d like to see that code as encapsulated in one place.
> On Nov 4, 2016, at 11:38 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
>
> We have several jira issues related to gfsh parsing (GEODE-1598,
> GEODE-1912). After spending some time understanding how the parsing works,
> I found out we have three components intertwined together all trying to do
> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
> outcome is I am able to maintain the current parsing and tabbing completion
> capabilities (and fix a few bugs) by removing 40+ files. The only
> difference I see so far lies in the help and hint messages. It seems the
> main reason we are using these home backed Gfsh parsing is to provide more
> readable help messages. Below are the differences:
>
> Using Spring Shell's provided help:
>
> Using Gfsh Parsing with JoptSimple:
>
>
> I do like the outcome of the latter, but added complexity of the code is
> too expensive to bear. So I am asking the community how important it is to
> maintain the current style of help? Can we do with the cheaper way by just
> using whatever provided by the libraries?
>
> Cheers
>
> Jinmei
>
Fwd: Gfsh Parsing
Posted by Jinmei Liao <ji...@pivotal.io>.
--resend with attachments
We have several jira issues related to gfsh parsing (GEODE-1598,
GEODE-1912). After spending some time understanding how the parsing works,
I found out we have three components intertwined together all trying to do
parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
outcome is I am able to maintain the current parsing and tabbing completion
capabilities (and fix a few bugs) by removing 40+ files. The only
difference I see so far lies in the help and hint messages. It seems the
main reason we are using these home backed Gfsh parsing is to provide more
readable help messages. Below are the differences:
Using Spring Shell's provided help:
Using Gfsh Parsing with JoptSimple:
I do like the outcome of the latter, but added complexity of the code is
too expensive to bear. So I am asking the community how important it is to
maintain the current style of help? Can we do with the cheaper way by just
using whatever provided by the libraries?
--
Cheers
Jinmei
--
Cheers
Jinmei
Re: Gfsh Parsing
Posted by Kenneth Howe <kh...@pivotal.io>.
Jinmei, Your examples didn’t come through the mail
Ken
> On Nov 4, 2016, at 8:27 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> We have several jira issues related to gfsh parsing (GEODE-1598, GEODE-1912). After spending some time understanding how the parsing works, I found out we have three components intertwined together all trying to do parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The outcome is I am able to maintain the current parsing and tabbing completion capabilities (and fix a few bugs) by removing 40+ files. The only difference I see so far lies in the help and hint messages. It seems the main reason we are using these home backed Gfsh parsing is to provide more readable help messages. Below are the differences:
>
> Using Spring Shell's provided help:
>
>
> Using Gfsh Parsing with JoptSimple:
>
>
>
> I do like the outcome of the latter, but added complexity of the code is too expensive to bear. So I am asking the community how important it is to maintain the current style of help? Can we do with the cheaper way by just using whatever provided by the libraries?
>
> --
> Cheers
>
> Jinmei