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
