On Feb 11, 2013, at 8:11 PM, Evan Huus wrote:
> Ever since the recent Makefile changes, running a 'clean' make (i.e.
> no changes at all since the last build) now results in a couple of
> calls to lemon:
>
> LEMONgrammar.h
> LEMONdtd_grammar.h
> LEMONmate_grammar.h
>
> Is this inte
Ever since the recent Makefile changes, running a 'clean' make (i.e.
no changes at all since the last build) now results in a couple of
calls to lemon:
LEMONgrammar.h
LEMONdtd_grammar.h
LEMONmate_grammar.h
Is this intentional? Or has it always done this, and it's just more
noticeable
On Feb 11, 2013, at 5:02 PM, Hadriel Kaplan wrote:
> I guess I'll just fix it and have it say "works for tshark only".
...but there's not even a guarantee that it'll work for TShark forever, so I
changed your update to use only the post-dissector code.
On Feb 11, 2013, at 7:37 PM, Guy Harris wrote:
> *If* Wireshark is supposed to support setting columns in taps, rather than in
> dissectors or in post-dissectors:
> http://wiki.wireshark.org/Lua/Examples/PostDissector
> *then* the listener taps would have to be called whenever the columns
On Feb 11, 2013, at 4:10 PM, Hadriel Kaplan wrote:
> Setting column text via Lua plugins by using the pinfo:set() method (the
> Pinfo from a Listener tap), doesn't seem to work for two reasons:
> 1) The TL_REQUIRES_COLUMNS flag wasn't being set when registering Lua
> listener taps in Listener_
Howdy,
Setting column text via Lua plugins by using the pinfo:set() method (the Pinfo
from a Listener tap), doesn't seem to work for two reasons:
1) The TL_REQUIRES_COLUMNS flag wasn't being set when registering Lua listener
taps in Listener_new(). I fixed that in my local copy.
2) Wireshark ap
On Mon, Feb 11, 2013 at 6:42 PM, Ed Beroset wrote:
> Evan Huus wrote:
>>
>> On Mon, Feb 11, 2013 at 1:47 PM, Guy Harris
>> wrote:
>
>
>>> Note all the lines flagged with "[-Wc++-compat]"; those are for
>>> code that's valid C but not valid C++ and that would have to be
>>> fixed in order to compi
Evan Huus wrote:
On Mon, Feb 11, 2013 at 1:47 PM, Guy Harris
wrote:
Note all the lines flagged with "[-Wc++-compat]"; those are for
code that's valid C but not valid C++ and that would have to be
fixed in order to compile with a C++ compiler (unless there's a
"let valid C code that *could* be
Evan Huus skrev 2013-02-11 20:40:
And some code (e.g. our copy of lemon) doesn't need to be converted
anyways, so any c++-compat warnings in it can be ignored completely.
We could heck if any fixes are available from
http://www.sqlite.org/src/finfo?name=tool/lemon.c
Anders
___
On Mon, Feb 11, 2013 at 1:47 PM, Guy Harris wrote:
>
> On Feb 11, 2013, at 8:01 AM, Dirk Jagdmann wrote:
>
>> To me the biggest advantage of transitioning to a C++ compiler is the
>> availability of std::string and std::list, std::set, std::map. They are so
>> much
>> more convinient to use than
On Mon, Feb 11, 2013 at 12:36:52PM -0500, Evan Huus wrote:
> Moving just to a C++ compiler shouldn't cause problems for anybody.
> While C++ isn't technically a superset of C, it is trivial for C
> programmers to avoid the few areas of incompatibility (as far as I
> know there are simply a few more
On Feb 11, 2013, at 8:01 AM, Dirk Jagdmann wrote:
> To me the biggest advantage of transitioning to a C++ compiler is the
> availability of std::string and std::list, std::set, std::map. They are so
> much
> more convinient to use than equivalents from the glib or the alternatives
> designed fo
Not critiquing your approach, but if you've got a tool that analyzes pcap data
for TCP/IP connections/stats, and also uses Wireshark, why not just write the
tool inside Wireshark? (e.g., as a tap)
Alternatively, if your tool is stand-alone and uses Wireshark only for detailed
drill-down on-dema
On Mon, Feb 11, 2013 at 12:18 PM, Richard Stearn
wrote:
> A thought from the sidelines. I have contributed to Wireshark, once.
> I probably will not contribute again (unless I find another protocol
> itch to scratch). This is an observation from scratching that itch.
>
> Creating suite of dissec
A thought from the sidelines. I have contributed to Wireshark, once.
I probably will not contribute again (unless I find another protocol
itch to scratch). This is an observation from scratching that itch.
Creating suite of dissectors from the skeletons in the development
guide was not difficul
On Mon, Feb 11, 2013 at 11:01 AM, Dirk Jagdmann wrote:
> To me the biggest advantage of transitioning to a C++ compiler is the
> availability of std::string and std::list, std::set, std::map. They are so
> much
> more convinient to use than equivalents from the glib or the alternatives
> designed
To me the biggest advantage of transitioning to a C++ compiler is the
availability of std::string and std::list, std::set, std::map. They are so much
more convinient to use than equivalents from the glib or the alternatives
designed for Wireshark. Since the C++ STL classes allow a custom allocator
On 2/11/2013 8:23 AM, eapa...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=47629
User: eapache
Date: 2013/02/11 05:23 AM
Log:
Add an if (tree) check to prevent a very-long-but-not-infinite loop,
since without a tree the proto_tree_add_item calls won'
Hi,
Thank you for replying.
Sure, firstly for other bespoke network analysis tools that aim to use
Wireshark to analyse low level network data (but where the main focus of
the tool isn't aimed at that level of detail). In comparison to it's
alternatives Wireshark is feature-rich, very customisabl
19 matches
Mail list logo
