Re: [Wireshark-dev] Gently migrating to Git + Gerrit
On 6 August 2013 19:11, Gerald Combs wrote: > On 8/6/13 4:18 AM, Bálint Réczey wrote: > > > Currently all the library archives are stored in SVN and if we simply > convert it > > to Git anyone cloning the repository would have to download all the libs > ever > > checked in (unless using git clone --depth which imposes other > limitations). > > Handling binary files is not exactly where Git shines. There is a > > separate project, > > git-annex to support using Git helping file storage, but Windows support > is not > > perfect according to the project's page [1]. > > > > Regarding the libraries I think it would probably be enough to use a > > downloadable > > .zip file containing a snapshot of the needed Windows libraries > > instead of cloning > > a Subversion/Git repository to the machine. The scripts maintaining the > snapshot > > could be stored in Git, of course, but I'm not sure if rethinking the > > library installation > > should happen before moving the main codebase to Gerrit. > > Good point. Ultimately I'd like to get out of the third party package > business. At Sharkfest Graham mentioned that Nuget > (http://www.nuget.org/) is starting to gain popularity as a way to > package development libraries for Windows. I'm hoping we can migrate > from what we currently have to a set of scripts that generate packages > and upload them to Nuget.org. > > I was leaning more to Chocolatey (http://http://chocolatey.org/) which is a helper wrapper around Nuget. However, someone will still have to create the Chocolatey or Nuget packages, I suppose we could create them first ourselves and then try to push them upstream to the library originator. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Fwd: [Wireshark-commits] rev 51173: /trunk/epan/ /trunk/epan/: proto.c -> Use __builtin_ctz for GCC/clang
On 6 August 2013 23:42, Jakub Zawadzki wrote: > On Tue, Aug 06, 2013 at 11:39:11PM +0200, Anders Broman wrote: > > Should we use *_BitScanForward* on Windows? > > http://msdn.microsoft.com/en-us/library/wfd9z0bb%28VS.80%29.aspx > > Sure, if you know how to do it, why not. > Slight caution required, it's a Microsoft specific compiler intrinsic, but as I'm not aware of; a) an intent to support compilation of Wireshark on Windows with anything other than the MSVC toolchain and b) I don't think MS will be dropping that intrinsic anytime soon, I think it should be safe. Obviously it would need to be wrapped with the appropriate #ifdef to hide it from non- MS compilers. Despite the info from MSDN the functions are available from VS 2005 through to VS2013 although it appears that the 64 bit version is only available if targetting an x64 build. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] addr_resolv.c, transport name resolution appalingly slow.
Hi,
Another fix needed:
Index: epan/addr_resolv.c
===
--- epan/addr_resolv.c (revision 2122)
+++ epan/addr_resolv.c (working copy)
@@ -1763,7 +1763,9 @@
if( tp == NULL ) {
tp = eth_hash_new_entry(addr, resolve);
} else {
-eth_addr_resolve(tp); /* Found but needs to be resolved */
+if (resolve && (tp->status == HASHETHER_STATUS_UNRESOLVED)){
+ eth_addr_resolve(tp); /* Found but needs to be resolved */
+}
}
return tp;
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: den 6 augusti 2013 17:28
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] addr_resolv.c, transport name resolution
appalingly slow.
Hi,
This patch fixes it...
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: den 6 augusti 2013 16:05
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] addr_resolv.c, transport name resolution
appalingly slow.
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: den 6 augusti 2013 16:01
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] addr_resolv.c, transport name resolution
appalingly slow.
On Tue, Aug 6, 2013 at 9:41 AM, Anders Broman
wrote:
>> Hi,
>>
>> I will revert the change to use a hash table for transport name
>> resolution as soon as I can, the performance is horrible.
>
>It shouldn't be, glib hash tables are pretty efficient. If you profile, where
>is the time being spent?
Can't profile it just now...
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Remove hf_ variables
On 07/29/13 16:12, Jakub Zawadzki wrote: 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. Just for completeness one should mention that replacing the hf_ variables with pointers means that each proto_tree_add_xxx() call will be pushing 8 bytes (in what is hopefully by now the common case ;-)) instead of 4 bytes onto the stack. I suppose that wouldn't really make a difference but I thought I'd mention it... ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gently migrating to Git + Gerrit
On Tue, Aug 6, 2013 at 2:57 AM, Gerald Combs wrote:
> I finally have some time set aside to do more work on the Git migration.
> I'm hoping to do the following in the near future:
>
> Switch code.wireshark.org from gitweb to cgit.
>
> This isn't strictly necessary but IMHO cgit has a slightly nicer
> interface and its URL format appears to be much more sane.
>
>
> Install Gerrit.
>
> I need to do a bit of infrastructure work beforehand, but hopefully it
> won't be too difficult.
>
>
> Create our first read/write Git+Gerrit repository.
>
> I think a combined version of wireshark-win{32,64}-libs would be a good
> candidate since they could use a bit of reorganization and it would be a
> good excuse for me to check in the scripts that I use to build our
> home-grown packages.
>
> Once that's done we should have a good idea about how the workflow
> described at
>
> http://wiki.wireshark.org/Development/Workflow
>
> will work in our environment and what we need to do to get there.
>
Great news ! (And Summer project ;-) )
> ___
> Sent via:Wireshark-dev mailing list
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] rev 50749: /trunk/ /trunk/: CMakeLists.txt
On Tue, Jul 23, 2013 at 8:57 PM, Guy Harris wrote:
>
> On Jul 22, 2013, at 7:00 AM, Alexis La Goutte
> wrote:
>
> > I try also in my Ubunux box (12.04) with clang 3.0 ( Ubuntu clang
> version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0) Target:
> x86_64-pc-linux-gnu Thread model: posix )
> >
> > and i have the following error when i try to build with clang :
> >
> > [ 4%] Building C object wiretap/CMakeFiles/wiretap.dir/file_wrappers.c.o
> > /home/alagoutte/wireshark2/wiretap/file_wrappers.c:818:13: error:
> implicit conversion loses integer precision:
> > '__blksize_t' (aka 'long') to 'int' [-Werror,-Wshorten-64-to-32]
> > want = st.st_blksize;
> > ~ ~~~^~
>
> I guess Linux is prepared for the world when files should be read in
> chunks bigger than 2GB.
>
> I've checked in a change to check whether st.st_blksize <= G_MAXINT and:
>
> if it is, cast st.st_blksize to int before assigning it;
>
> if it isn't, just leave "want" at the default value.
>
> Try it now.
>
> > Have also for all file the following warning...
> > warning: unknown warning option '-Wpragmas' [-Wunknown-warning-option]
>
> This change:
>
>
> http://anonsvn.wireshark.org/viewvc/trunk/CMakeLists.txt?r1=50760&r2=50759&pathrev=50760
>
> *should* have made CMake use -Werror=unknown-warning-option when testing
> whether -W options are supported if the compiler supports
> -Werror=unknown-warning-option, so it *should* leave out all -W options
> that clang doesn't support.
>
> If that's not happening, that needs to be fixed.
Hi,
I have always some errors when i build with clang 3.0 (with cmake or
autotools):
dumpcap.c:3981:88: error: implicit conversion loses integer precision:
'const __suseconds_t'
(aka 'const long') to 'guint32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
phdr->ts.tv_sec, phdr->ts.tv_usec,
~^~~
dumpcap.c:3989:73: error: implicit conversion loses integer precision:
'const __suseconds_t'
(aka 'const long') to 'guint32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
phdr->ts.tv_sec,
phdr->ts.tv_usec,
~^~~
wiretap/lanalyzer.c:643:24: error: implicit conversion loses integer
precision: 'const __suseconds_t'
(aka 'const long') to 'gint32' (aka 'int')
[-Werror,-Wshorten-64-to-32]
gint32 usec = a->tv_usec;
~~~^~~
Fixed with add (gint32) cast before tv_usec :
- gint32 usec = a->tv_usec;
+ gint32 usec = (gint32)a->tv_usec;
I have also a another issue :
dumpcap.c:4273:20: error: array index of '3' indexes past the end of an
array
(that contains 3 elements) [-Werror,-Warray-bounds]
if (strcmp("-Z", argv[i]) == 0) {
~~~^~
/usr/include/x86_64-linux-gnu/bits/string2.h:812:21: note: expanded from:
: __strcmp_cg (s1, s2,
__s1_len)) \
^
/usr/include/x86_64-linux-gnu/bits/string2.h:885:27: note: expanded from:
(__const char *)
(s1))[3] \
^~
But now yet found a fix...
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 51119: /trunk/ /trunk/epan/: addr_resolv.c addr_resolv.h /trunk/ui/gtk/: addr_resolution_dlg.c
On 08/05/13 11:17, Anders Broman wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jeff Morriss Sent: den 5 augusti 2013 17:14 To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 51119: /trunk/ /trunk/epan/: addr_resolv.c addr_resolv.h /trunk/ui/gtk/: addr_resolution_dlg.c On 08/05/13 09:18, Jeff Morriss wrote: On 08/02/13 14:22, Jeff Morriss wrote: On 08/02/13 11:05, etx...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=511 19 User: etxrab Date: 2013/08/02 08:05 AM Log: - Use a hashtable for eth lookup. Currently broken get_ether_addr(). - Show hastable content in address dlg.(temp solution). This (or maybe another rev) is causing plenty of errors like: (lt-wireshark:6958): GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed Michael fixed this in r51133. Oops, I spoke too soon. There are still some in there. Perhaps the table(s) should be crated at initialize_ethers()? I did that (and some more) in r51191. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Remove hf_ variables
Hi, On Wed, Aug 07, 2013 at 09:57:36AM -0400, Jeff Morriss wrote: > On 07/29/13 16:12, Jakub Zawadzki wrote: > > There's no real need of them, and we can just replace them with > > header_field_info structure. > > Just for completeness one should mention that replacing the hf_ > variables with pointers means that each proto_tree_add_xxx() call will > be pushing 8 bytes (in what is hopefully by now the common case ;-)) > instead of 4 bytes onto the stack. Luckily on x64 windows first 4 arguments (integers or pointers) are passed by registers (rest of the world - 6). In either case hfinfo won't be passed by stack ;-) (source: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Remove hf_ variables
On Tue, Jul 30, 2013 at 07:40:21AM +0200, Joerg Mayer wrote: > Can you give a sample diff how a dissector would need to be changed? > Also: What would be the migration plan: All at once or incremental? I wrote some ugly gawk program for hf_ variables. Here is one + some patch for epan: http://www.wireshark.org/~darkjames/proto-new/0001-changes.txt Here is convertion of some dissectors (not quite automagic): http://www.wireshark.org/~darkjames/proto-new/0002-rewrite.txt We probably don't want this redefine macros inside proto-new.h but it's *much faster* to test. Cheers ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
