Re: [Bro-Dev] Fwd: [REL - 10amd64-default][security/bro] Failed for bro-2.2 in build
On 12/03/13 08:09, Robin Sommer wrote: > Which clang version is this? I've tried it with a recent version of > the clang 3.4 release branch, and that works fine for me. I dunno, I've asked them them to include the clang version before; I'll ask again. > But based on the error message, I'm attaching a patch; does that help > by any chance? I'll see if I can get someone to test it. Thanks! Craig ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1107) Documentation of BIFs that take variable number of arguments
[
https://bro-tracker.atlassian.net/browse/BIT-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14918#comment-14918
]
Robin Sommer commented on BIT-1107:
---
The work-around of turning va_args function arguments into {{(...)}}}, along
with a manual textual description of how the parameters are supposed to look
like in each case, would sound good to me.
Btw, I believe this is how Bro recognizes va_args functions:
{noformat}
int check_and_promote_exprs(ListExpr*& elements, TypeList* types)
{
[...]
if ( tl->length() == 1 && (*tl)[0]->Tag() == TYPE_ANY )
return 1;
[...]
}
{noformat}
Would be nicer to have some more explicit way some time.
> Documentation of BIFs that take variable number of arguments
>
>
> Key: BIT-1107
> URL: https://bro-tracker.atlassian.net/browse/BIT-1107
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Reporter: Daniel Thayer
>
> The function prototype for BIFs that take a variable number of
> arguments appears in an altered form in the online documentation.
> Here is a comparison of how these functions appear in the source code,
> versus what they look like in the online documentation:
> md5_hash%(...%) ===> Type : function (va_args: any)
> order%(v: any, ...%) ===> Type : function (va_args: any)
> sort%(v: any, ...%) ===> Type : function (va_args: any)
> cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args:
> any)
> The functions that have a named argument ("v" in sort, or "sep" in cat_sep)
> have those arguments described in the online documentation, but we
> cannot see them in the function prototype (only "va_args" is shown,
> which isn't actually the name of any function argument).
--
This message was sent by Atlassian JIRA
(v6.2-OD-03#6206)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-701) Autodoc final version of redef'ed records (for logging)
[ https://bro-tracker.atlassian.net/browse/BIT-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14916#comment-14916 ] Jon Siwek commented on BIT-701: --- This is addressed by BIT-1098 > Autodoc final version of redef'ed records (for logging) > --- > > Key: BIT-701 > URL: https://bro-tracker.atlassian.net/browse/BIT-701 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro >Reporter: gregor > Labels: docs > Fix For: 2.3 > > > (from an earlier e-mail) > Hi, > given a bunch of scripts, that extend record types (I mostly thinking > about the Info records used for logging) if there a way to get a autodoc > generated file that shows the final version of the record? > The idea would be, that this "final version" is exactly what actually > gets logged, so it would be a nice-to-have for users who want to > understand all the columns in a log file. Now, they have to know all the > scripts that are loaded that extend a particular record and look at > their documentation to find out the meaning of columns / fields. This is > fine for scripts in policy, but for the base scripts it would be nice to > have a single place to go too. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1107) Documentation of BIFs that take variable number of arguments
[
https://bro-tracker.atlassian.net/browse/BIT-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Siwek updated BIT-1107:
---
Description:
{quote}
md5_hash%(...%) ===> Type : function (va_args: any)
{quote}
I'm thinking the only thing here would be to expect the documenter to know how
the BIF compiler translates variadic functions and to add documentation for the
va_args parameters. Otherwise the only thing I can think that might make it
more clear would be to change the Bro parser to do variadic functions in a more
familiar way.
{quote}
order%(v: any, ...%) ===> Type : function (va_args: any)
sort%(v: any, ...%) ===> Type : function (va_args: any)
{quote}
These look like a hack to workaround the BIF compiler's limitation of not being
able to parse the full range of Bro types, in this case functions.
Ideal solution: fix it so full range of Bro types can be parsed in BIFs.
Workaround: just improve documentation about how a function with a param of
type "any" can be used like a variadic function and for each hacky use of it,
make it clear in the docs what the expected arguments are.
{quote}
cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args: any)
{quote}
I'm not sure what would fix this... maybe better variadic function support in
Bro is needed so the BIF compiler will just pass the named arguments through
instead of combining it into one "va_args: any" ?
was:
The function prototype for BIFs that take a variable number of
arguments appears in an altered form in the online documentation.
Here is a comparison of how these functions appear in the source code,
versus what they look like in the online documentation:
md5_hash%(...%) ===> Type : function (va_args: any)
order%(v: any, ...%) ===> Type : function (va_args: any)
sort%(v: any, ...%) ===> Type : function (va_args: any)
cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args: any)
The functions that have a named argument ("v" in sort, or "sep" in cat_sep)
have those arguments described in the online documentation, but we
cannot see them in the function prototype (only "va_args" is shown,
which isn't actually the name of any function argument).
> Documentation of BIFs that take variable number of arguments
>
>
> Key: BIT-1107
> URL: https://bro-tracker.atlassian.net/browse/BIT-1107
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Reporter: Daniel Thayer
>
> {quote}
> md5_hash%(...%) ===> Type : function (va_args: any)
> {quote}
> I'm thinking the only thing here would be to expect the documenter to know
> how the BIF compiler translates variadic functions and to add documentation
> for the va_args parameters. Otherwise the only thing I can think that might
> make it more clear would be to change the Bro parser to do variadic functions
> in a more familiar way.
> {quote}
> order%(v: any, ...%) ===> Type : function (va_args: any)
> sort%(v: any, ...%) ===> Type : function (va_args: any)
> {quote}
> These look like a hack to workaround the BIF compiler's limitation of not
> being able to parse the full range of Bro types, in this case functions.
> Ideal solution: fix it so full range of Bro types can be parsed in BIFs.
> Workaround: just improve documentation about how a function with a param of
> type "any" can be used like a variadic function and for each hacky use of it,
> make it clear in the docs what the expected arguments are.
> {quote}
> cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args:
> any)
> {quote}
> I'm not sure what would fix this... maybe better variadic function support in
> Bro is needed so the BIF compiler will just pass the named arguments through
> instead of combining it into one "va_args: any" ?
--
This message was sent by Atlassian JIRA
(v6.2-OD-03#6206)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1107) Documentation of BIFs that take variable number of arguments
[
https://bro-tracker.atlassian.net/browse/BIT-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Siwek updated BIT-1107:
---
Description:
The function prototype for BIFs that take a variable number of
arguments appears in an altered form in the online documentation.
Here is a comparison of how these functions appear in the source code,
versus what they look like in the online documentation:
md5_hash%(...%) ===> Type : function (va_args: any)
order%(v: any, ...%) ===> Type : function (va_args: any)
sort%(v: any, ...%) ===> Type : function (va_args: any)
cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args: any)
The functions that have a named argument ("v" in sort, or "sep" in cat_sep)
have those arguments described in the online documentation, but we
cannot see them in the function prototype (only "va_args" is shown,
which isn't actually the name of any function argument).
was:
{quote}
md5_hash%(...%) ===> Type : function (va_args: any)
{quote}
I'm thinking the only thing here would be to expect the documenter to know how
the BIF compiler translates variadic functions and to add documentation for the
va_args parameters. Otherwise the only thing I can think that might make it
more clear would be to change the Bro parser to do variadic functions in a more
familiar way.
{quote}
order%(v: any, ...%) ===> Type : function (va_args: any)
sort%(v: any, ...%) ===> Type : function (va_args: any)
{quote}
These look like a hack to workaround the BIF compiler's limitation of not being
able to parse the full range of Bro types, in this case functions.
Ideal solution: fix it so full range of Bro types can be parsed in BIFs.
Workaround: just improve documentation about how a function with a param of
type "any" can be used like a variadic function and for each hacky use of it,
make it clear in the docs what the expected arguments are.
{quote}
cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args: any)
{quote}
I'm not sure what would fix this... maybe better variadic function support in
Bro is needed so the BIF compiler will just pass the named arguments through
instead of combining it into one "va_args: any" ?
> Documentation of BIFs that take variable number of arguments
>
>
> Key: BIT-1107
> URL: https://bro-tracker.atlassian.net/browse/BIT-1107
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Reporter: Daniel Thayer
>
> The function prototype for BIFs that take a variable number of
> arguments appears in an altered form in the online documentation.
> Here is a comparison of how these functions appear in the source code,
> versus what they look like in the online documentation:
> md5_hash%(...%) ===> Type : function (va_args: any)
> order%(v: any, ...%) ===> Type : function (va_args: any)
> sort%(v: any, ...%) ===> Type : function (va_args: any)
> cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args:
> any)
> The functions that have a named argument ("v" in sort, or "sep" in cat_sep)
> have those arguments described in the online documentation, but we
> cannot see them in the function prototype (only "va_args" is shown,
> which isn't actually the name of any function argument).
--
This message was sent by Atlassian JIRA
(v6.2-OD-03#6206)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-701) Autodoc final version of redef'ed records (for logging)
[ https://bro-tracker.atlassian.net/browse/BIT-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-701: -- Resolution: Fixed Fix Version/s: (was: 2.2) 2.3 Status: Closed (was: Open) > Autodoc final version of redef'ed records (for logging) > --- > > Key: BIT-701 > URL: https://bro-tracker.atlassian.net/browse/BIT-701 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro >Reporter: gregor > Labels: docs > Fix For: 2.3 > > > (from an earlier e-mail) > Hi, > given a bunch of scripts, that extend record types (I mostly thinking > about the Info records used for logging) if there a way to get a autodoc > generated file that shows the final version of the record? > The idea would be, that this "final version" is exactly what actually > gets logged, so it would be a nice-to-have for users who want to > understand all the columns in a log file. Now, they have to know all the > scripts that are loaded that extend a particular record and look at > their documentation to find out the meaning of columns / fields. This is > fine for scripts in policy, but for the base scripts it would be nice to > have a single place to go too. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1107) Documentation of BIFs that take variable number of arguments
[
https://bro-tracker.atlassian.net/browse/BIT-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14915#comment-14915
]
Jon Siwek commented on BIT-1107:
(sorry, meant to comment, not edit the description)
{quote}
md5_hash%(...%) ===> Type : function (va_args: any)
{quote}
I'm thinking the only thing here would be to expect the documenter to know how
the BIF compiler translates variadic functions and to add documentation for the
va_args parameters. Otherwise the only thing I can think that might make it
more clear would be to change the Bro parser to do variadic functions in a more
familiar way.
{quote}
order%(v: any, ...%) ===> Type : function (va_args: any)
sort%(v: any, ...%) ===> Type : function (va_args: any)
{quote}
These look like a hack to workaround the BIF compiler's limitation of not being
able to parse the full range of Bro types, in this case functions.
Ideal solution: fix it so full range of Bro types can be parsed in BIFs.
Workaround: just improve documentation about how a function with a param of
type "any" can be used like a variadic function and for each hacky use of it,
make it clear in the docs what the expected arguments are.
{quote}
cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args: any)
{quote}
I'm not sure what would fix this... maybe better variadic function support in
Bro is needed so the BIF compiler will just pass the named arguments through
instead of combining it into one "va_args: any" ?
> Documentation of BIFs that take variable number of arguments
>
>
> Key: BIT-1107
> URL: https://bro-tracker.atlassian.net/browse/BIT-1107
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Reporter: Daniel Thayer
>
> The function prototype for BIFs that take a variable number of
> arguments appears in an altered form in the online documentation.
> Here is a comparison of how these functions appear in the source code,
> versus what they look like in the online documentation:
> md5_hash%(...%) ===> Type : function (va_args: any)
> order%(v: any, ...%) ===> Type : function (va_args: any)
> sort%(v: any, ...%) ===> Type : function (va_args: any)
> cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args:
> any)
> The functions that have a named argument ("v" in sort, or "sep" in cat_sep)
> have those arguments described in the online documentation, but we
> cannot see them in the function prototype (only "va_args" is shown,
> which isn't actually the name of any function argument).
--
This message was sent by Atlassian JIRA
(v6.2-OD-03#6206)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1098) topic/jsiwek/broxygen
[
https://bro-tracker.atlassian.net/browse/BIT-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Siwek updated BIT-1098:
---
Status: Merge Request (was: Open)
> topic/jsiwek/broxygen
> -
>
> Key: BIT-1098
> URL: https://bro-tracker.atlassian.net/browse/BIT-1098
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro, Broccoli
>Affects Versions: git/master
>Reporter: Jon Siwek
> Fix For: 2.3
>
>
> This branch is in the bro and broccoli repos and improves the automated
> script-reference documentation generation process, broxygen.
> This should address issues in BIT-701 and BIT-751, let me know if there's
> anything not covered that's still relevant.
> Highlights:
> - Remove {{--doc-scripts}} and {{-Z}} options to toggle documentation mode --
> the parser is now always instrumented to gather documentation from comments
> of the form "##", "##!", or "##<".
> - Raw comments are available at runtime through several BIF functions:
> {{get_*_comments}};
> - Add {{--broxygen}} and {{-X}} options to toggle generating reST-format
> documentation output, driven by a config file argument.
> - Add a "broxygen" Sphinx extension domain, allowing certain pieces of
> documentation to be generated on-the-fly via invoking a Bro process.
> Re-organized/cleaned up the Sphinx source tree in {{doc/}} to use this in
> some places.
--
This message was sent by Atlassian JIRA
(v6.2-OD-03#6206)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1098) topic/jsiwek/broxygen
[
https://bro-tracker.atlassian.net/browse/BIT-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14914#comment-14914
]
Jon Siwek commented on BIT-1098:
{quote}
- what would you think about moving the global type alias table into BroType as
a private static member, along with a few static accessor methods to
manipulate it?
{quote}
Seems better. Done.
{quote}
- if there's a bro binary in PATH, it seems that "make doc" picks up that one
instead of the one in {{src/build/bro}}
{quote}
Fixed.
{quote}
- "make doc" shows {{received termination signal}} right before {{Running
Sphinx}}. Is that expected?
{quote}
Expected, I guess. It's just a result of the broxygen/ package calling
{{terminate()}} in {{bro_init()}}. I do that so that scripts like
{{listen.bro}} can be loaded during the doc-generation process. I don't want
to filter all stderr to /dev/null, because that can give useful diagnostics
when something goes wrong. Could grep out just that string, but I'm kind of
fine with it...
{quote}
-- I'd remove the "Param" in the function descriptions (or is that a Sphinx
thing?)
{quote}
(I think) that was there in the previous Broxygen version, too. And I think it
was only there to make the raw reST output look more like some Python docstring
markup. But I think we're different enough that keep it isn't that beneficial.
So removed.
{quote}
-- If a package has scripts both w/ and wo/ a further description, they appear
separately in the package overview; see, e.g.,
{{scripts/base/frameworks/packet-filter/index.html}}
{quote}
Think I fixed it, or at least made it render consistently.
{quote}
-- should we just omit {{__load__.bro}} in the package overviews?
{quote}
Not sure, but I think it's easiest to just treat them no different than other
scripts. In some cases there might actually be stuff other than {{@load}} in
there that would be useful for a person browsing docs (or maybe even having
quick access to the set of {{@load}} that is done is useful for quickly
switching to other docs).
{quote}
-- I like how the records now show fields that are redefined somewhere else.
Two further thoughts:
--- how about changing {{from redef in XXX}} to {{added if XXX is loaded}}. For
a user, it might be more intuitive to talk about loading another script than
just redef.
{quote}
Sounds good, changed to {{present if XXX is loaded}}, which seemed clearer that
it's referring to the existence of the field.
{quote}
--- for the script that does the redef, can we show the new fields there as
well? For example, in
{{scripts/policy/protocols/http/software-browser-plugins.bro.html}} it would
show not only that {{HTTP::Info}} got redef, but also repeat the fields it
added right there. Same for the enums.
{quote}
Should be technically possible (all the info is tracked), but there'd be some
effort setting up new linkage to the doc. Also not sure how confusing it is to
have pieces of the total type put in various places -- right now there's always
one canonical place for the full type and there's no duplication of any
documentation. Holding off on doing anything for now.
Updated the /topic/jsiwek/broxygen branch with the changes.
> topic/jsiwek/broxygen
> -
>
> Key: BIT-1098
> URL: https://bro-tracker.atlassian.net/browse/BIT-1098
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro, Broccoli
>Affects Versions: git/master
>Reporter: Jon Siwek
> Fix For: 2.3
>
>
> This branch is in the bro and broccoli repos and improves the automated
> script-reference documentation generation process, broxygen.
> This should address issues in BIT-701 and BIT-751, let me know if there's
> anything not covered that's still relevant.
> Highlights:
> - Remove {{--doc-scripts}} and {{-Z}} options to toggle documentation mode --
> the parser is now always instrumented to gather documentation from comments
> of the form "##", "##!", or "##<".
> - Raw comments are available at runtime through several BIF functions:
> {{get_*_comments}};
> - Add {{--broxygen}} and {{-X}} options to toggle generating reST-format
> documentation output, driven by a config file argument.
> - Add a "broxygen" Sphinx extension domain, allowing certain pieces of
> documentation to be generated on-the-fly via invoking a Bro process.
> Re-organized/cleaned up the Sphinx source tree in {{doc/}} to use this in
> some places.
--
This message was sent by Atlassian JIRA
(v6.2-OD-03#6206)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1107) Documentation of BIFs that take variable number of arguments
Daniel Thayer created BIT-1107:
--
Summary: Documentation of BIFs that take variable number of
arguments
Key: BIT-1107
URL: https://bro-tracker.atlassian.net/browse/BIT-1107
Project: Bro Issue Tracker
Issue Type: Problem
Components: Bro
Reporter: Daniel Thayer
The function prototype for BIFs that take a variable number of
arguments appears in an altered form in the online documentation.
Here is a comparison of how these functions appear in the source code,
versus what they look like in the online documentation:
md5_hash%(...%) ===> Type : function (va_args: any)
order%(v: any, ...%) ===> Type : function (va_args: any)
sort%(v: any, ...%) ===> Type : function (va_args: any)
cat_sep%(sep: string, def: string, ...%) ===> Type : function (va_args: any)
The functions that have a named argument ("v" in sort, or "sep" in cat_sep)
have those arguments described in the online documentation, but we
cannot see them in the function prototype (only "va_args" is shown,
which isn't actually the name of any function argument).
--
This message was sent by Atlassian JIRA
(v6.2-OD-03#6206)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [Auto] Merge Status
Open Merge Requests === IDComponentReporterAssigneeUpdated For VersionPrioritySummary --- -- -- -- - -- -- BIT-1106 [1] Bro Bernhard Amann - 2013-12-05 - Normal Merge topic/bernhard/input-error-fixes BIT-1105 [2] Bro,Broccoli,BroControl Jon Siwek - 2013-12-05 2.3High/topic/jsiwek/misc-fixes BIT-1104 [3] Bro Michael Stone Seth Hall 2013-12-05 - Normal Add tracking for MSIE 11 BIT-1103 [4] Bro Andrew Hoying Bernhard Amann 2013-12-05 - HighMemory leak in Bro Intel framework [1] BIT-1106 https://bro-tracker.atlassian.net/browse/BIT-1106 [2] BIT-1105 https://bro-tracker.atlassian.net/browse/BIT-1105 [3] BIT-1104 https://bro-tracker.atlassian.net/browse/BIT-1104 [4] BIT-1103 https://bro-tracker.atlassian.net/browse/BIT-1103 ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
