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.ste...@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 <dbros...@apache.org> wrote: > > > > git clone g...@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.ste...@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.ste...@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 <flame...@gmail.com> > >>>>> wrote: > >>>>>>> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz < > phil.ste...@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-unsubscr...@commons.apache.org > >>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
