Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@mmiklavc Can you please merge master in and commit this?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Did you verify that these functions run on:
* the profiler
* the parser topology via field transformations
* the enrichment topology via stellar enrichments
* the Stellar
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Kick Travis
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Merged with latest master and modified Stellar.g4 to handle EOL fragments.
Test went from failing to passing locally.
---
If your project is set up for it, you can reply to this email
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Ok, this is making more sense now. GitHub has merged this PR out of band of
the build. That fetch is not doing a merge. It's fetching what has already been
merged out of band from the
Github user jjmeyer0 commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@mmiklavc have you rebased lately? If not, I'm sure the PR I submitted for
Stellar comparisons is the culprit.
---
If your project is set up for it, you can reply to this email and have
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@jjmeyer0 Makes sense and that explains things. @mmiklavc despite it being
out of the scope of this ticket, it should just be a 1-liner and we should
probably correct it as part of this
Github user jjmeyer0 commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Okay, I took a look. It's because EOL isn't defined as a fragment.
If `EOL : '\n';` is changed to `fragment EOL : '\n';` it should work.
Without the `fragment` keyword antlr4
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@jjmeyer0 @mmiklavc It appears that a regression was added relatively
recently that affects whitespace at the end of stellar rules (the whitespace
isn't sent to the skip channel in the
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@dlyle65535 the thing I'm not fully understanding is how this is working in
my local branch. Doing a git fetch and checkout shouldn't merge anything from
master, so the most recent master
Github user jjmeyer0 commented on the issue:
https://github.com/apache/incubator-metron/pull/397
This looks like an issue with the grammar. My guess is it isn't properly
handling white space at the end. If you change the variable
`hllpDefaultConstructorRule` to the below, it should
Github user dlyle65535 commented on the issue:
https://github.com/apache/incubator-metron/pull/397
I was able to duplicate the failures in my environment by doing the
following (based on what Travis does).
```
mkdir mike_test
cd mike_test
git clone --depth=50
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Hm, something fishy going on here with Travis. Running all tests fine from
Maven (on OSX) locally.
```
[INFO] metron-analytics ... SUCCESS [
1.079
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@nickwallen @cestella Moved the HLLP implementation wrapper and Stellar
functions to the metron-statistics project. Bloomfilter Stellar functions
should probably be moved to the stats
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@nickwallen Thanks for the feedback! - I'm currently working on finishing
up some performance metrics (p/sp vals vs accuracy, cardinality, serialized mem
consumption) in addition to an
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Very cool stuff, @mmiklavc. Can't wait to see it hit master.
Just to lend my $.02, I do agree with @ottobackwards that a more detailed
example would be helpful. Maybe something
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@nickwallen Fair point; I missed that last sentence. Sorry for the
confusion.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Yes, understood. I think that's what I wrote at the bottom of my last
post. More clear for a motivating example to actually do the calculation as
the `result`.
---
If your project
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@nickwallen That does look right, but you probably want the result to just
be `out` so you can decouple the in-degree and out-degree calculation from the
window size in the profiler.
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@mmiklavc Meant to ask previously, does this look right? Am I using your
API correctly?
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/397
I was thinking how I could use your HLLP functionality with the Profiler.
I think I could use this functionality to track the in-degree and out-degree of
a host over time. This might
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Ok, I propose a [discuss] around docs. These are great questions, but they
are probably not going to result in getting us HLL functionality soon ;)
---
If your project is set up for it,
Github user ottobackwards commented on the issue:
https://github.com/apache/incubator-metron/pull/397
what we need is a plan, whatever it is ;)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@ottobackwards Good point, there is some overlap between end-user docs and
the stuff in the README.md's. Things like the stellar language and function
docs should be part of the wiki, I
Github user ottobackwards commented on the issue:
https://github.com/apache/incubator-metron/pull/397
But, I just download the binaries or install through ambari? You mean I
have to look through the codebase?
---
If your project is set up for it, you can reply to this email and
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
I imagine the wiki is for things like process docs (bylaws, etc.) and high
level coverage of end-to-end usecases aimed at multiple features working in
concert to achieve an end (e.g. the
Github user ottobackwards commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Maybe we could build a readme-wiki, like a section of our wiki which is
just the readme's from the current build?
---
If your project is set up for it, you can reply to this email
Github user ottobackwards commented on the issue:
https://github.com/apache/incubator-metron/pull/397
In that case, we should have multiple concise README's with more detail and
a top level overview readme
---
If your project is set up for it, you can reply to this email and have
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Now, regarding the wiki vs the Readme. The reason I am hesitant to move
things to the wiki is that the wiki doesn't really track with the code well.
What happens when we change things
Github user ottobackwards commented on the issue:
https://github.com/apache/incubator-metron/pull/397
I agree with keeping the README's lean. What I'm struggling with ( and
this may just be as an FOSS noob ) is that there seems to be no process around
calling out documentation. On
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
A couple things. First off, these functions (Bloom and HLL) really should
exist in `stellar-statistics`. rather than being in common IMO (thoughts?).
Second, *stellar* should exist in
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/397
@ottobackwards +1 on some working examples. We currently plop the whole lot
of Stellar documentation in the metron-common README and I wonder if we should
start splitting any of this out
Github user ottobackwards commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Should functions like this have a more expansive description, that perhaps
includes a set of sample data and the outcome? Similar to what the Profiler
functions have?
---
If your
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/397
Because this is a function that will 99% be used from the profiler, could
you please design a simple test around using this with the profiler and give us
quick rundown on the test
34 matches
Mail list logo
