Re: [Bro-Dev] broctl archive copy vs move

2016-12-13 Thread Azoff, Justin S
> On Dec 13, 2016, at 3:12 PM, Aashish Sharma wrote: > > So if we have compresscmd unset then archive-log script does a copy: > > archive-log:nice cp $file_name "$dest" > > Any reason why it doesn't do move instead ? > > I propose changing cp to mv No.. I don't think

[Bro-Dev] broctl archive copy vs move

2016-12-13 Thread Aashish Sharma
So if we have compresscmd unset then archive-log script does a copy: archive-log:nice cp $file_name "$dest" Any reason why it doesn't do move instead ? I propose changing cp to mv Aashish ___ bro-dev mailing list bro-dev@bro.org

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

2016-12-13 Thread Matthias Vallentin
> I don't really like using a record like that, as that would associate > specific semantics with what's really a user-definable type. It was only meant to illustrate the idea of error handling and function composition. These ideas still hold up when substituting the user-defined result type

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

2016-12-13 Thread Robin Sommer
> >type result = record { > > error: failure > > value: any > >} I don't really like using a record like that, as that would associate specific semantics with what's really a user-definable type. I.e., we'd hardcode into the language that the record used here needs to have

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

2016-12-13 Thread Matthias Vallentin
> > local r = put(store, key, test(lookup(store, key))); > > For prototyping purposes, I see the convenience in that, but wonder if > the runtime will do something that’s useful and widely applicable > enough for that to translate directly into production code. What > exactly does the runtime

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

2016-12-13 Thread Siwek, Jon
> On Dec 13, 2016, at 6:02 AM, Matthias Vallentin wrote: > > local r = put(store, key, test(lookup(store, key))); For prototyping purposes, I see the convenience in that, but wonder if the runtime will do something that’s useful and widely applicable enough for that to

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

2016-12-13 Thread Matthias Vallentin
> I might prefer just doing the unpacking myself. Having > separate/explicit checks for each individual return value would > naturally occur over time anyway (e.g. when debugging, adding extra > logging, improving error handling). > How common do you expect async function chains to occur? Any