On Jul 5, 2012, at 9:11 PM, Dirk Jagdmann wrote:
Both use cases involve a sender and multiple receiver scenario. I don't need
to
send these requests to a different computer, so a local message bus is
sufficient. In the KDE and Gnome world
http://www.freedesktop.org/wiki/Software/dbus would
Does in coding convention, it Limit lines to 79 characters?
I have gone through README.developer but didn't find any such restriction.
Even when i see some codes, packet-tcp.c etc, some or most lines does not
limit to 79 characters.
Could anyone confirm me on this. Thanks in advance.
Arun
At
http://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.htmlthere
is a reference to
http://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureOptions.html#ChCapCaptureOptionsDialog-
the filters page says You enter the capture filter into the Filter
field
of the Wireshark
Arun Sharma wrote:
Does in coding convention, it Limit lines to 79 characters?
I have gone through README.developer but didn't find any such restriction.
Even when i see some codes, packet-tcp.c etc, some or most lines does
not limit to 79 characters.
Could anyone confirm me on this.
Dirk Jagdmann wrote:
Hello developers,
I'm planning to develop a feature for two use cases. I'd like to control (or
better select) the currently displayed packet from another process. I don't
think Wireshark currently offers such a feature, so I'd like to get ideas how I
should implement this.
On 7/6/2012 10:05 AM, Jeff Morriss wrote:
Arun Sharma wrote:
Does in coding convention, it Limit lines to 79 characters?
I have gone through README.developer but didn't find any such
restriction.
Even when i see some codes, packet-tcp.c etc, some or most lines does
not limit to 79 characters.
Ben wrote:
At
http://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html
there is a reference to
http://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureOptions.html#ChCapCaptureOptionsDialog
- the filters page says You enter the capture filter into the Filter
field
SVN revision 43579 broke compilation:
prefs_nameres.c: In function 'nameres_prefs_show':
prefs_nameres.c:109: error: 'e_prefs' has no member named 'name_resolve'
prefs_nameres.c:126: error: 'e_prefs' has no member named 'name_resolve'
This is one case of trying to use the variable that no longer
2012/7/6 Stephen Fisher st...@stephen-fisher.com
SVN revision 43579 broke compilation:
prefs_nameres.c: In function 'nameres_prefs_show':
prefs_nameres.c:109: error: 'e_prefs' has no member named 'name_resolve'
prefs_nameres.c:126: error: 'e_prefs' has no member named 'name_resolve'
This
On Fri, 06 Jul 2012 11:57:35 -0600 Pascal
Quantinpascal.quan...@gmail.com wrote
give a try to current top of tree: it should compile.
I just did an svn update again and I'm at r43588 but still the same problem.
Also, prefs_nameres.c shouldn't be building anymore. The top of the tree
should have it removed from any makefiles (unless I screwed up the patch). The
functionality of prefs_nameres.c was replaced with the generic handling of
preferences that used to be unique to only protocol preferences.
On Fri, 06 Jul 2012 12:03:30 -0600 mman...@netscape.net wrote
Also, prefs_nameres.c shouldn't be building anymore. The top of the tree
should have it removed from any makefiles (unless I screwed up the patch).
The functionality of prefs_nameres.c was replaced with the
Yes, the following files can now be deleted:
\wireshark\ui\gtk\prefs_nameres.c
\wireshark\ui\gtk\prefs_nameres.h
\wireshark\ui\gtk\prefs_print.c
\wireshark\ui\gtk\prefs_print.h
\wireshark\ui\gtk\prefs_protocols.c
\wireshark\ui\gtk\prefs_protocols.h
\wireshark\ui\gtk\prefs_taps.c
Hi,
I'm using 1.8.0 and it seems the SCCP dissector is never decoding the SCCP
Address Indicator h-Bit. Under normal circumstances this should (afaik) be set
to '0' but by accident I stumbled into a situation where the h-bit was actually
set to '1', breaking things. From the packet-byte window
Arjan Van Der Oest wrote:
Hi,
I'm using 1.8.0 and it seems the SCCP dissector is never decoding the SCCP
Address Indicator h-Bit. Under normal circumstances this should (afaik) be set
to '0' but by accident I stumbled into a situation where the h-bit was actually
set to '1', breaking things.
On 6 jul. 2012, at 23:29, Jeff Morriss wrote:
Arjan Van Der Oest wrote:
Hi,
I'm using 1.8.0 and it seems the SCCP dissector is never decoding the SCCP
Address Indicator h-Bit. Under normal circumstances this should (afaik) be set
to '0' but by accident I stumbled into a situation where the
On Jul 6, 2012, at 11:43 AM, mman...@netscape.net wrote:
Yes, the following files can now be deleted:
OK, I've deleted them from the trunk.
I thought removing them was part of the patch for bug 7402, but they still
show up in the SVN (perhaps I didn't create the patch correctly).
I'm not
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 7 juli 2012 01:23
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] r43579 Generic preference implementation broken
compile
On Jul 6, 2012, at 4:26 PM, Guy Harris wrote:
BTW, when I run the resulting version of Wireshark, I get:
(wireshark:1004): Gtk-WARNING **: Attempting to add a widget with type
GtkVBox to a container of type GtkFrame, but the widget is already inside a
container of type GtkFrame, the GTK+
19 matches
Mail list logo
