sample_element() BiF

[vpax]

Multiple times now I've run across the following fairly weird-looking idiom:

local t: table[X] of Y;
...
local instance: X;
for ( instance in t )
   # Just grab an arbitrary instance, doesn't matter which one
   break;

It would be nice/cleaner to have something like sample_element(t: any): any that takes a table or set and returns an arbitrary element (for tables, this would be an index).

If we had a notion of type templates, then this would be something like sample_element(t: table[T1] of _): T1 (and maybe an overloaded version sample_element(s: set[T1]): T1) ... though I'll take the simpler any version for now.

[JustinAzoff]

Where have you seen that come up? You used to have to do something like that for just about any file event, because file events had a $conns attribute (that only ever contained a single connection). But I believe we fixed that and file events should have a $conn attribute now.

[vpax]

Yeah, that's indeed the recent context. Note that there's still an instance in the base scripts, create_file_info() in base/frameworks/notice/main.zeek

There are also (different) instances in SumStats, e.g. request_all_current_keys() and get_a_key(); and describe() in base/protocols/smtp/main.zeek

[awelzel]

Multiple times now I've run across the following fairly weird-looking idiom:

Googling for Python / Golang people do ask and discuss how to do this, too, and the short-for-loop is not unpopular.

It would be nice/cleaner to have something like sample_element(t: any): any that takes a table or set and returns an arbitrary element (for tables, this would be an index).

Could be a bit more generalized if we document in terms of iteration order on the container and give it an optional offset? That would allow to pick first, second, etc. element in ordered tables/sets, too: sample_element(t: any, offset: count &default=0). Default would be non-deterministic, but for ordered sets/tables could have a bit more flexibility. Maybe as pick_element() instead of "sample".

Where have you seen that come up? You used to have to do something like that for just about any file event, because file events had a $conns attribute (that only ever contained a single connection). But I believe we fixed that and file events should have a $conn attribute now.

This still exists. The change you're probably thinking about was to unroll individual f$conns in the files.log instead of aggregating into a single log entry. The log changed, the lower layers still tracks multiple conns per file (for the better or worse).