gtk-gnutella-devel Digest, Vol 29, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 29, Issue 1
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. STATIC_ASSERT related to maximum alignment (Lars Nordlund) 2. Re: STATIC_ASSERT related to maximum alignment (Christian Biere) 3. Re: STATIC_ASSERT related to maximum alignment (Lars Nordlund) 4. Re: STATIC_ASSERT related to maximum alignment (Christian Biere) 5. Static assert about atoms. (Matthew Lye) 6. Re: Static assert about atoms. (Christian Biere) 7. warning: "size_t not int" in dht/routing.c (Matthew Lye) 8. Re: warning: "size_t not int" in dht/routing.c (Raphael Manfredi) 9. Re: FATAL: Assertion failure in atoms.c:928: "size > 0" in 0.96.6 (Raphael Manfredi) ---------------------------------------------------------------------- Message: 1 Date: Sun, 3 May 2009 00:58:48 +0200 From: Lars Nordlund <lars.nordlund@...> Subject: [gtk-gnutella-devel] STATIC_ASSERT related to maximum alignment To: gtk-gnutella-devel@... Message-ID: <20090503005848.0fae300c@laphroaig> Content-Type: text/plain; charset=US-ASCII Hello list When building gtk-gnutella-current on NetBSD-5.0rc4/amd64 I get this compile error: cc -c -I../.. -I.. -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -DCURDIR=src/lib -O2 -g -pipe -momit-leaf-frame-pointer -W -Wall -Wformat=2 -Wshadow atoms.c atoms.c: In function 'atom_get': atoms.c:837: error: duplicate case value atoms.c:837: error: previously used here gmake[3]: *** [atoms.o] Error 1 I think it relates this this entry in config.h %grep MEM_ALI work/gtk-gnutella/config.h /* MEM_ALIGNBYTES: #define MEM_ALIGNBYTES 16 /**/ Building the latest gtk-gnutella release, 0.96.5, gives this in the generated config.h: %grep 'define MEM_ALI' work/gtk-gnutella-0.96.5/config.h #define MEM_ALIGNBYTES 8 /**/ Changing the config.h file entry 16 to 8 gets me through the build on gtk-gnutella-current, but I have not tried starting the binary. Investigating the alignbytes detection program embedded in the configure script reveals that it is the long double type which bumps up the alignment constraint to 16. In the 0.96.5 release, only char and double types are checked. Any comments? I am not really sure how to proceed here.. I assume this works fine on other 64bit OSes? Best regards, Lars Nordlund ------------------------------ Message: 2 Date: Sun, 3 May 2009 02:18:49 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum alignment To: gtk-gnutella-devel@... Message-ID: <20090503001848.GC16818@...> Content-Type: text/plain; charset=utf-8 Lars Nordlund wrote: > When building gtk-gnutella-current on NetBSD-5.0rc4/amd64 I get this > compile error: > > cc -c -I../.. -I.. -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -DCURDIR=src/lib -O2 -g -pipe -momit-leaf-frame-pointer -W -Wall -Wformat=2 -Wshadow atoms.c > atoms.c: In function 'atom_get': > atoms.c:837: error: duplicate case value > atoms.c:837: error: previously used here > gmake[3]: *** [atoms.o] Error 1 > > I think it relates this this entry in config.h > > %grep MEM_ALI work/gtk-gnutella/config.h > /* MEM_ALIGNBYTES: > #define MEM_ALIGNBYTES 16 /**/ > > Building the latest gtk-gnutella release, 0.96.5, gives this in the > generated config.h: The latest release is actually 0.96.6 although I'd recommend using 0.96.7u from SVN instead because the "stable" release leaks quite badly. > %grep 'define MEM_ALI' work/gtk-gnutella-0.96.5/config.h > #define MEM_ALIGNBYTES 8 /**/ > Changing the config.h file entry 16 to 8 gets me through the build on > gtk-gnutella-current, but I have not tried starting the binary. > Investigating the alignbytes detection program embedded in the > configure script reveals that it is the long double type which bumps up > the alignment constraint to 16. In the 0.96.5 release, only char and > double types are checked. The old detection unit wasn't cross-compilable and suffered from blahism. It defined MEM_ALIGNBYTES but actually talked about double. I considered detecting the common maximum alignment constraint for all native types is more useful and matching the seemingly obvious semantic of "align bytes". Histerically, the widest type with the strictest alignment constraints was 'double' but this was in the dark ages before the advent of C99, maybe even before C89. gtk-gnutella doesn't use "long double" but some library might, in theory. > Any comments? I am not really sure how to proceed here.. I assume this > works fine on other 64bit OSes? Well, bugs don't exist unless reported. Apparently it does but nobody really knows. In general, if gtk-gnutella doesn't compile or the compiler reports any warnings, people should report these as soon as possible. -- Christian ------------------------------ Message: 3 Date: Mon, 4 May 2009 23:45:59 +0200 From: Lars Nordlund <lars.nordlund@...> Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum alignment To: gtk-gnutella-devel@... Cc: christianbiere@... Message-ID: <20090504234559.6f79dd01@laphroaig> Content-Type: text/plain; charset=US-ASCII On Sun, 3 May 2009 02:18:49 +0200 Christian Biere <christianbiere@...> wrote: > The latest release is actually 0.96.6 although I'd recommend using > 0.96.7u from SVN instead because the "stable" release leaks quite > badly. Yes, you are correct. I blindly thought that pkgsrc/net/gtk-gnutella was up-to-date. :-) > The old detection unit wasn't cross-compilable and suffered from blahism. > It defined MEM_ALIGNBYTES but actually talked about double. I considered > detecting the common maximum alignment constraint for all native types > is more useful and matching the seemingly obvious semantic of "align bytes". > Histerically, the widest type with the strictest alignment constraints > was 'double' but this was in the dark ages before the advent of C99, > maybe even before C89. > > gtk-gnutella doesn't use "long double" but some library might, in theory. I see. > > Any comments? I am not really sure how to proceed here.. I assume this > > works fine on other 64bit OSes? > > Well, bugs don't exist unless reported. Apparently it does but nobody really > knows. In general, if gtk-gnutella doesn't compile or the compiler reports any > warnings, people should report these as soon as possible. I commented out the long double type from the Configure script test, and have built a trunk version of gtk-gnutella. It has been running stable for a couple of hours. Not much of a formal verification, but at least an "it works here"-report.. Best regards, Lars Nordlund ------------------------------ Message: 4 Date: Tue, 5 May 2009 00:15:30 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum alignment To: gtk-gnutella-devel@... Message-ID: <20090504221530.GA16259@...> Content-Type: text/plain; charset=utf-8 Lars Nordlund wrote: > On Sun, 3 May 2009 02:18:49 +0200 > Christian Biere <christianbiere@...> wrote: > I commented out the long double type from the Configure script test, > and have built a trunk version of gtk-gnutella. It has been running > stable for a couple of hours. Not much of a formal verification, but at > least an "it works here"-report.. Well, I think I had just fixed it before responding to your mail. So it shouldn't be necessary to comment it out any longer. Don't you see any warnings from the compiler at all? Unfortunately, x86 platforms are no good for testing alignment correctness because they're too forgiving. By the way, practically there's no point for this test at all, as it's MEM_ALIGNBYTES is a compile-time evaluable constant and a similar macro could be used to evaluate alignment constraint for specific types instead of using the maximum always - which might be overkill and wasting memory. -- Christian ------------------------------ Message: 5 Date: Mon, 4 May 2009 21:34:33 -0400 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] Static assert about atoms. To: gtk-gnutella-devel@... Message-ID: <F7F2531A-D0EE-48FF-B838-1BDFFA750B4B@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hey there, I was just trying to get Darwin's llvm-gcc (low level virtual machine based gcc) going on my machine, and I'm getting a static assert at line 832 of "atoms.c"; the arena offset isn't aligning to modulo 16 bytes. (A recent change to alignment in llvm-gcc 4.2). http://devworld.apple.com/releasenotes/DeveloperTools/RN-llvm-gcc/index.html for latest changes. ------------------------------ Message: 6 Date: Tue, 5 May 2009 10:48:33 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Static assert about atoms. To: gtk-gnutella-devel@... Message-ID: <20090505084833.GA29680@...> Content-Type: text/plain; charset=utf-8 Matthew Lye wrote: > I was just trying to get Darwin's llvm-gcc (low level virtual machine > based gcc) going on my machine, and I'm getting a static assert at > line 832 of "atoms.c"; the arena offset isn't aligning to modulo 16 > bytes. (A recent change to alignment in llvm-gcc 4.2). My previous attempt to fix the bug reported by Lars Nordlund was nonsense. I think it makes more sense this time. -- Christian ------------------------------ Message: 7 Date: Sat, 9 May 2009 22:48:10 -0400 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] warning: "size_t not int" in dht/routing.c To: gtk-gnutella-devel@... Message-ID: <733A0D02-92A7-42DE-A2DF-CB392C332FAE@...> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Cosmetic in this instance I guess, but hopefully no-one's depending on size_t always equalling int. routing.c: In function ?dht_compute_size_estimate?: routing.c:2425: warning: format ?%d? expects type ?int?, but argument 4 has type ?long unsigned int? from /Users/mlye/prj/gtk-fast/src/dht/routing.cc: line 2333: > size_t i; ... line 2425: > g_message("DHT sparseness over %d nodes is %s = %f (%f)", > i - 1, kuid_to_hex_string(&sparseness), > kuid_to_double(&sparseness), ds / s); ------------------------------ Message: 8 Date: Sun, 10 May 2009 07:12:12 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] warning: "size_t not int" in dht/routing.c To: gtk-gnutella-devel@... Message-ID: <gu5uoc$2ne$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel: :Cosmetic in this instance I guess, but hopefully no-one's depending on :size_t always equalling int. : :routing.c: In function ?dht_compute_size_estimate?: :routing.c:2425: warning: format ?%d? expects type ?int?, but argument :4 has type ?long unsigned int? Thanks, fixed in r16705. Raphael ------------------------------ Message: 9 Date: Sun, 10 May 2009 07:13:53 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] FATAL: Assertion failure in atoms.c:928: "size > 0" in 0.96.6 To: gtk-gnutella-devel@... Message-ID: <gu5urh$2ne$2@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Jochen Kemnade <jochenkemnade@...> from ml.softs.gtk-gnutella.devel: :I encounter this error every time gtk-gnutella has run for some time :(about half an hour, roughly). Unfortunately I cannot tell how to :reproduce it, but it seems to happen without user interaction. Maybe, :the following backtrace provides more details: : :FATAL: Assertion failure in atoms.c:928: "size > 0" Are you still seeing this with the DHT code enabled? You'd better test it thoroughly, because the next release is likely to make DHT code enabled by default... Raphael ------------------------------ ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 29, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
