On Sun, Jul 14, 2013 at 12:43 AM, wrote:
> On OS X, set the rpath for executables to include
> @executable_path/../lib as well as /usr/local/lib, so we can use @rpath
> in the install names in the executables and libraries in the application
> bundle.
I get this warning when running dumpcap
On Jul 29, 2013, at 2:13 AM, Stig Bjørlykke wrote:
> I get this warning when running dumpcap from /opt/local/bin, which
> makes dumpcap unusable for wireshark:
>
> dyld: warning, LC_RPATH @executable_path/../lib in
> /opt/local/bin/dumpcap being ignored in restricted program because of
> @exec
On Mon, Jul 29, 2013 at 12:06 PM, Guy Harris wrote:
> One solution to this is not to have dumpcap be set-UID or set-GID on OS X.
> It's not that way by default; instead, the ChmodBPF startup item is installed
> and run to make the BPF devices readable and writable by the access_bpf
> group, an
This file is missing from: https://www.wireshark.org/docs/wsug_html/
I can download it, but having it online, I can EASILY read it with my
chrome extension "table-of-contents":
https://chrome.google.com/webstore/detail/table-of-contents-crx/eeknhipceeelbgdbcmchicoaoalfdnhi
thank you
--
Kaseluris
On 7/28/13 1:16 PM, Evan Huus wrote:
> I'm not sure why exactly, it seems to successfully link tshark,
> wireshark and the other target binaries. Maybe this is another
> side-effect of GTK3-by-default?
>
> Either way, the public stdio logs don't seem to indicate the actual
> cause of the problem..
Hi,
On Sun, Jul 28, 2013 at 08:33:49AM -0400, Evan Huus wrote:
> I was poking through this change and I noticed that all three places
> that call proto_unregister_field (which is very inefficient at the
> moment, possibly traversing the entire linked list twice) do so in a
> loop for all their hfs
Hi,
Is anyone attached to hf_ variables? ;)
There's no real need of them, and we can just replace them with
header_field_info structure.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists
Does this mean that all proto_tree_add_* calls would need to have
&hf_name instead of just hf_name?
I'm not attached to them in principle (and getting rid of them seems
like it would be a performance/memory win) but your description is
awfully vague...
On Mon, Jul 29, 2013 at 4:12 PM, Jakub Zawad
On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki wrote:
> Is anyone attached to hf_ variables? ;)
>
> There's no real need of them, and we can just replace them with
> header_field_info structure.
I.e., pass a pointer to the relevant structure, rather than an array index into
an internal array tha
On Mon, Jul 29, 2013 at 01:25:41PM -0700, Guy Harris wrote:
>
> On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki wrote:
>
> > Is anyone attached to hf_ variables? ;)
> >
> > There's no real need of them, and we can just replace them with
> > header_field_info structure.
>
> I.e., pass a pointer to
On Mon, Jul 29, 2013 at 10:42:02PM +0200, Jakub Zawadzki wrote:
> and some cycles on startup + max 2-3 MB less in binary doesn't seems like
> good deal
> against converting 90% of dissectors codebase :)
Another idea, is to remove ett_ variables, it requires much less
rewritting, some proof of con
On Mon, Jul 29, 2013 at 10:42:02PM +0200, Jakub Zawadzki wrote:
> On Mon, Jul 29, 2013 at 01:25:41PM -0700, Guy Harris wrote:
> >
> > On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki
> > wrote:
> >
> > > Is anyone attached to hf_ variables? ;)
> > >
> > > There's no real need of them, and we can ju
12 matches
Mail list logo
