> 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
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
> 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
> >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
> > 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
> 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
> 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