Re: [Bro-Dev] Final Broker branch testing
I’m able to get this built and running on FreeBSD 11.1 . - Keith On 26 Apr 2018, at 11:16, Jon Siwek wrote: > The latest version of the new Broker-ized cluster/communication system > for Bro in 'topic/actor-system' branch is wrapping up and, in my > opinion, ready to be merged into Bro's 'master' branch. > > However, since it's such a big change, I'd like a last round of feedback > before merging. If you want to test, the build process should now be as > simple as: > > $ git clone --recursive --branch=topic/actor-system git://git.bro.org/bro > $ cd bro && ./configure && make > > Configuring BroControl is not any different from before. > > If you had custom scripts, they may require porting. There's a guide > and examples for that at [1] and [2] (hyperlinks in those docs will > render more nicely when it's up on bro.org). > > Though, for this round of testing, I'd be most interested just in any > general stability issues or major feature breakages from a vanilla Bro > installation. Mild performance issues, minor bugs, or other issues w/ > porting custom scripts are things I think we can iron out even after > merging into 'master'. > > - Jon > > [1] > https://github.com/bro/bro/blob/topic/actor-system/doc/frameworks/broker.rst > [2] https://github.com/bro/bro/tree/topic/actor-system/doc/frameworks/broker > ___ > bro-dev mailing list > bro-dev@bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev smime.p7s Description: S/MIME digital signature ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
On 4/30/18 9:54 AM, Robin Sommer wrote: > One additional piece of context here: That vector(...) syntax could > then be used more broadly in the sense of creating a different > semantic context for the operations inside. That kind of opens up a > whole new set of of type-specific operator meanings, without affecting > current/standard ones (it's like introducing R inside parentheses :-). Yeah, framing it as type-specific operators makes sense. > It's not the super-great, but at least it's explicit and we couldn't > come up with anything better if we want to have such operations as > operators. Might work for some other types as well. Isn't the existing "v + e" an alternative that one could say is "better" ? Other languages also take that to mean "vectorized/array operation". I think for Bro, it's just that vectorized/array operations will be a less common use-case than appending and so there's incentive to make the later more succinct? Just to put it out there again: I wouldn't mind something like "append(v, e)" and leaving the existing vector operations like "v + e" alone. It may make the common case more verbose, though there's also less ambiguities. - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
On Mon, Apr 30, 2018 at 07:10 -0700, you wrote: > Okay, I can live with this as long as '|' and '-' support add-to-set and > remove-from-set. But I think those have to work, given we'll enable them > for operations on two sets. Well, my vote then remains not adding new set operators for add/delete, so that we don't have multiple ways to do the same thing. Just looked at Python again, as a data point: That's what they do, too. There are '|'/'&'/'-' for set/set operations, but no versions of those for individual elements (they do that through methods instead; add/delete are kind of our version of methods). Same for Ruby. I looked around for a few more minutes for other languages, but didn't immediately find any that even have any set operators at all (only methods/functions for union/intersection/etc.). Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
On 4/30/18 9:10 AM, Vern Paxson wrote: > The question then was what would be the new "v op e" syntax. > The best we could come up with (which we both found not-too-awful) is > "vector(v op e)". Wrapped in "vector(...)", the operation becomes the > current semantics (apply "op e" separately to each element of v). Maybe "vectorize(v op e)" ? Implies implementing via SIMD instructions. > "v op e" by itself would now be an error (which could point the user > at the "vector(...)" syntax as possibly providing what they're looking > for). "v += e" would be "append e to v". That still seems odd to me. If "v += e" means "append", then I might expect "v + e" to do the same, except producing a new value w/ original vector not modified. Maybe that's a less common use-case, though, and so "v op e" being an error would be less weird than suddenly changing the meaning of that operation. - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
On 30 Apr 2018, at 11:13, Robin Sommer wrote: > On Mon, Apr 30, 2018 at 07:10 -0700, you wrote: > >> Okay, I can live with this as long as '|' and '-' support add-to-set and >> remove-from-set. But I think those have to work, given we'll enable them >> for operations on two sets. > > Well, my vote then remains not adding new set operators for > add/delete, so that we don't have multiple ways to do the same thing. > Just looked at Python again, as a data point: That's what they do, > too. There are '|'/'&'/'-' for set/set operations, but no versions of > those for individual elements (they do that through methods instead; > add/delete are kind of our version of methods). Same for Ruby. I > looked around for a few more minutes for other languages, but didn't > immediately find any that even have any set operators at all (only > methods/functions for union/intersection/etc.). Yup, I think I concur. Johanna ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
On Mon, Apr 30, 2018 at 07:10 -0700, you wrote: > "vector(v op e)". Wrapped in "vector(...)", the operation becomes the > current semantics (apply "op e" separately to each element of v). One additional piece of context here: That vector(...) syntax could then be used more broadly in the sense of creating a different semantic context for the operations inside. That kind of opens up a whole new set of of type-specific operator meanings, without affecting current/standard ones (it's like introducing R inside parentheses :-). It's not the super-great, but at least it's explicit and we couldn't come up with anything better if we want to have such operations as operators. Might work for some other types as well. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> I think I actually would prefer just keeping add/delete, at least for > sets, and not introduce the plus-syntax. Okay, I can live with this as long as '|' and '-' support add-to-set and remove-from-set. But I think those have to work, given we'll enable them for operations on two sets. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> It especially feels weird to me if v + e and > v += e are operations that perform something completely different. Yeah, I hear you. OTOH, I *really* would like a succinct way to say "add this to the end of this vector", it's such a common idiom. Robin and I discussed this a bit. Our ultimate thinking was along the lines of: (1) likely there's no significant use right now of "v op e" semantics, given how none of us initially remembered it (2) down the line such semantics could be quite handy if we start pushing on vector operations for doing statistical or ML computations (that's why I added "v op e" in the first place, inspired by how easy R makes these), (3) "v += e" really is a nice append-to-vector idiom (4) so how about we change "v op e" into something else to avoid the conceptual clash w/ v += e, while still having it available for the possible uses in (2) above? The question then was what would be the new "v op e" syntax. The best we could come up with (which we both found not-too-awful) is "vector(v op e)". Wrapped in "vector(...)", the operation becomes the current semantics (apply "op e" separately to each element of v). "v op e" by itself would now be an error (which could point the user at the "vector(...)" syntax as possibly providing what they're looking for). "v += e" would be "append e to v". Do you buy that? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
