On 5 Nov 2018, at 11:40, Robin Sommer wrote:
> I like the "=T|F" syntax to control this more directly, as long as
> "" remains being equivalent to "=T".
Oh, I like that too and it dovetails very nicely with the existing
syntax. I remember those discussions we had about back then and I
On Tue, Nov 6, 2018 at 3:00 PM Vern Paxson wrote:
> I think what we need to do is rethink the basic architecture/structure of
> attributes. In particular, types in general (not just named types) should
> be able to have attributes associated with them. The attributes associated
> with an
Thanks a bunch for the further context & discussion.
The more I've delved into this, the more convinced I've become that we have
a basic architectural problem with attributes: they're associated with
identifiers and values, but not types ... *except* for hacky ways for
records and record fields.
On Mon, Nov 5, 2018 at 4:40 PM Robin Sommer wrote:
>
>
> On Sat, Nov 03, 2018 at 21:58 +, Vlad Grigorescu wrote:
>
> > In my mind, if the keyword is applied to a record, I would expect any new
> > fields added to that record to also be logged.
>
> I believe the reason for not doing that is
On Sat, Nov 03, 2018 at 21:58 +, Vlad Grigorescu wrote:
> In my mind, if the keyword is applied to a record, I would expect any new
> fields added to that record to also be logged.
I believe the reason for not doing that is that then one couldn't add
a field that's *not* being logged
On Sat, Nov 3, 2018 at 9:14 PM Vern Paxson wrote:
> Thanks for the pointers & thoughts! A quick question, more in a bit:
>
> > To better understand the existing behavior, here's the commit that
> > introduced this (specifically with regards to conn_id):
> >
>
Thanks for the pointers & thoughts! A quick question, more in a bit:
> To better understand the existing behavior, here's the commit that
> introduced this (specifically with regards to conn_id):
> https://github.com/bro/bro/commit/38a1aa5a346d10de32f9b40e0869cdb48a98974b
> ...
> > Note that
To better understand the existing behavior, here's the commit that
introduced this (specifically with regards to conn_id):
https://github.com/bro/bro/commit/38a1aa5a346d10de32f9b40e0869cdb48a98974b
> The keyword now operates as discussed:
>
> - When associated with individual record fields,
H I've looked into this and there are some subtle issues.
First, I tried to make this work using TypeType's like I had sketched, and
it turns out to be a mess. Too many points where a decision has to be
made whether to access the base type (what the named type points to) rather
than the
On Mon, Sep 10, 2018 at 5:08 PM Vern Paxson wrote:
> > At least that's how I think it's currently working, so are you going
> > start using TypeType as a means of type aliasing in addition to adding
> > attributes to them?
>
> Not quite. Rather, the type of "mytype" would be a TypeType, which
> My understanding was just that TypeType's currently are *not* used
> when creating type aliases.
Correct.
> # Passing the type name/alias as a value.
> # The local variable/argument 'x' becomes of type
> # "TypeType". It's not of type "count".
> foo(mytype);
(Note that here any attributes
On Mon, Sep 10, 2018 at 4:16 PM Vern Paxson wrote:
> Seems simplest to me to have TypeType's (and only those) include attributes.
> The rest of it is easy to do from there. We could also do this with a
> separate NameType, but I don't see what that gains, since TypeType's already
> come into
> Other ideas I'm having for solving the overall problem are:
>
> (1) 'a' and 'b' need to actually be distinct BroType's. Instead of
> 'b' being a reference/alias to 'a' with extended attributes, just
> create it as it's own BroType by first cloning 'a', then adding any
> additional attributes.
On Wed, Sep 5, 2018 at 6:47 PM Vern Paxson wrote:
>
> > I think the right solution for this is to introduce a new BroType called
> > a NamedType. A NamedType has an identifier, an underlying BroType, and a
> > set of attributes. When a NamedType is constructed ...
>
> Huh, turns out there's
> I think the right solution for this is to introduce a new BroType called
> a NamedType. A NamedType has an identifier, an underlying BroType, and a
> set of attributes. When a NamedType is constructed ...
Huh, turns out there's already a "TypeType", which is the equivalent.
All I need to do,
For some scripting I'm doing, I'm running into the problem that
attributes associated with named types don't get propagated. For
example,
type a: table[count] of count = 5;
global c: a;
print c[9];
complains that c[9] isn't set, instead of returning the value 5.
Having
16 matches
Mail list logo
