[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: Proposed Contribution to Apache Commons,
From:       Jean-Louis MONTEIRO <jeanouii () gmail ! com>
Date:       2015-10-30 3:29:50
Message-ID: CAGFtjw3EV9dGYnraJ+TNXBugpSE03dF2JO=9PnU4Cg4xy0AmmQ () mail ! gmail ! com
[Download RAW message or body]


Overall agree with the feedback.
I may have missed some emails in the thread, but did we get another email
from Norman to provide us with a bit more information?

Again I might have missed it. Apologies if so.

Jean-Louis

Le jeu 29 oct. 2015 06:34, Phil Steitz <phil.steitz@gmail.com> a écrit :

> Thanks, Dave.
>
> Instructions below look good enough to me for the VOTE.  Will kick that
> off later today.
>
> Phil
>
> > On Oct 29, 2015, at 5:56 AM, Dave Brosius <dbrosius@apache.org> wrote:
> >
> > git clone git@github.com:NormanShapiro/Naomi.git
> > git checkout gh-pages
> >
> >
> > if you like, I already have a fork on github of it, I can merge gh-pages
> into master, and delete the gh-pages branch, and then the repo will be
> obviously just a one branch project.
> >
> >
> >
> >
> >
> >> On 10/28/2015 08:19 PM, Phil Steitz wrote:
> >> I am not seeing any -1s on this, so I would like to proceed with a
> >> VOTE to accept the code and start the IP clearance process.  For
> >> that I need a definitive snapshot of somewhere that I can point to
> >> for the VOTE and clearance docs.  My git-foo is pretty limited.  Can
> >> someone suggest a stable URL that we can use to identify the code
> >> that we will be accepting, should the VOTE pass?
> >>
> >> Thanks!
> >>
> >> Phil
> >>
> >>> On 10/25/15 12:25 PM, dbrosIus wrote:
> >>> +1 and git please
> >>>
> >>> -------- Original message --------
> >>> From: Phil Steitz <phil.steitz@gmail.com>
> >>> Date: 10/25/2015  3:15 PM  (GMT-05:00)
> >>> To: Commons Developers List <dev@commons.apache.org>
> >>> Subject: Re: Proposed Contribution to Apache Commons,
> >>>
> >>>> On 10/2/15 12:08 PM, Gary Gregory wrote:
> >>>> Well, a champion can volunteer to shepherd this through our incubator
> I
> >>>> suppose,
> >>> OK, I will volunteer to do this.  I propose that we start this as a
> >>> Commons Sandbox project.  To do that, we need a VOTE to accept the
> >>> code, a software grant and the IP clearance form [1] submitted to
> >>> the Incubator PMC.  We can use either git or svn for the new sandbox
> >>> repo.
> >>>
> >>> Any objections?  Any preference for git or svn?
> >>>
> >>> Phil
> >>>
> >>> [1]
> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
> >>>
> >>>
> >>>>   like CommonsRDF, which seems pretty inactive ATM. There is also
> >>>> the issue of "donate and forget" vs. staying plugged in the community.
> >>>>
> >>>> I just do not have the extra FOSS cycles to dig into the code ATM to
> see
> >>>> what's under the hood.
> >>>>
> >>>> Gary
> >>>>
> >>>>> On Fri, Oct 2, 2015 at 12:01 PM, Phil Steitz <phil.steitz@gmail.com>
> wrote:
> >>>>>
> >>>>>> On 10/2/15 11:46 AM, Gary Gregory wrote:
> >>>>>> I do not have time to dig into this one ATM but I'd like to give my
> 2c.
> >>>>>>
> >>>>>> Does this project introduce a new RE-like language or is it an API
> >>>>> wrapper
> >>>>>> for REs? It sounds like it is both.
> >>>>> It looks to me like what it says it is, which is an alternative to
> >>>>> REs, which IMO is a nice idea.  Less "pattern matching language" and
> >>>>> more objects expressing matching intent.  End result is less
> >>>>> developer thought required to accomplish a common task.  Seems to
> >>>>> fit nicely in Commons to me.
> >>>>>
> >>>>> Phil
> >>>>>> A project like this I could see in Commons if the project was split
> into
> >>>>> an
> >>>>>> API module and modules for different pattern matching languages,
> where
> >>>>> the
> >>>>>> standard Java RE would be the reference example. Naomi (I love the
> name
> >>>>>> BTW, someones wife or daughter?) would be another implementation
> module.
> >>>>>> With both under its belt, the project would be on fairly solid
> footing
> >>>>>> (granted I do not know Naomi). You could even imaging
> implementations
> >>>>> that
> >>>>>> would accept a JXPath or a SQL WHERE clause.
> >>>>>>
> >>>>>> If the project is only meant to introduce a new RE-like language,
> then a
> >>>>>> TLP would be probably more appropriate.
> >>>>>>
> >>>>>> 2c,
> >>>>>> Gary
> >>>>>>
> >>>>>> On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell <flamefew@gmail.com>
> >>>>> wrote:
> >>>>>>> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <
> phil.steitz@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>> On 9/29/15 3:55 PM, Gary Gregory wrote:
> >>>>>>>>> Norman,
> >>>>>>>>>
> >>>>>>>>> Hello and welcome to Apache Commons.
> >>>>>>>>>
> >>>>>>>>> It's not clear to me why Naomi is better than regular
> expressions.
> >>>>>>>> Pointing
> >>>>>>>>> to Javadocs is not the best way to get traction.
> >>>>>>>>>
> >>>>>>>>> Your project would be better served by having some documentation
> on
> >>>>>>> your
> >>>>>>>>> front page with an example driven tutorial.
> >>>>>>>>>
> >>>>>>>>> Is Naomi faster than REs?
> >>>>>>>>>
> >>>>>>>>> What can I do in Naomi that REs can't do? And vice-versa.
> >>>>>>>>>
> >>>>>>>>> Examples of this on your front page would help you at least get
> folks
> >>>>>>> to
> >>>>>>>>> consider learning a brand new way of doing things...
> >>>>>>>> +1
> >>>>>>>> The code in SimpleExamples starts to get to this.  Looks
> interesting
> >>>>>>>> and powerful.  Either here or on the github readme you should
> take a
> >>>>>>>> stab at explaining a little more how hard problems using regex get
> >>>>>>>> easier with naomi, illustrated with some simple examples.  Then
> >>>>>>>> maybe with help from community members here, you can develop some
> >>>>>>>> overview / getting started docs that help people get into the
> code.
> >>>>>>> +1.
> >>>>>>>
> >>>>>>> Reading SimpleExamples, my summary would be a boilerplate
> description of
> >>>>>>> "It replaces the arcane regular expression language with an API".
> It
> >>>>>>> reminds me of command line argument parsers. Perl had/has a great
> >>>>> regular
> >>>>>>> expression like command line argument parser, but it was cryptic
> and you
> >>>>>>> either loved it or hated it. Then along came Commons CLI, args4j
> and all
> >>>>>>> the others, providing a more OO/procedural API instead of its own
> mini
> >>>>>>> language. Not as 'powerful' (in that you had to type more), but
> simpler
> >>>>> (in
> >>>>>>> that you didn't have to learn a new lingo and didn't have to juggle
> >>>>>>> multiple languages inside one context (a source file)).
> >>>>>>>
> >>>>>>> I definitely need that user manual. It's hard, with a brain
> trained on
> >>>>>>> regular expressions, to read 'Pattern greek3=new
> >>>>> CharSequencePattern("?")'
> >>>>>>> and realize (I think) that it means a literal ? character. It's
> also the
> >>>>>>> primary way it'll be successful. You need that educational path
> that
> >>>>>>> explains what a ExplicitCharClass is for, rather than randomly
> clicking
> >>>>> on
> >>>>>>> javadoc :)
> >>>>>>>
> >>>>>>> There'll also be much debate to be had I suspect. Is "a-e" too
> complex,
> >>>>>>> compared to "abcde" or "a","e". Which parts of regex are worth
> >>>>> supporting,
> >>>>>>> vs not. Can I mix bits of regexp with bits of Naomi?   new
> >>>>>>> ExplicitCharClass("a-eg-p").
> >>>>>>>
> >>>>>>> Random.... I'd like the idea of varargs for automatic and'ing. ie:
> >>>>>>>
> >>>>>>> new ExplicitCharClass("a-p", "!f")   [and is a not char class too
> >>>>>>> complex?].
> >>>>>>>
> >>>>>>> Continuing on my summary, as I peruse the code a little more, I'd
> go
> >>>>> with:
> >>>>>>> "Build a regular expression via an API, not an arcane language of
> its
> >>>>> own".
> >>>>>>> I'd love to see that grow to:
> >>>>>>>
> >>>>>>> "Express regular expressions as objects, or mix and match objects
> with
> >>>>> that
> >>>>>>> arcane mini language we all love or loathe".
> >>>>>>>
> >>>>>>> Hen
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
>
>


[prev in list] [next in list] [prev in thread] [next in thread]