|
From: Dirk M. <mu...@kd...> - 2003-10-29 16:04:25
|
CVS commit by mueller: no longer sourceforge (also known as test commit) M +1 -1 README 1.12 --- valgrind/README #1.11:1.12 @@ -72,5 +72,5 @@ 0. Check out the code from CVS, following the instructions at - http://sourceforge.net/cvs/?group_id=46268. The 'modulename' is + http://developer.kde.org/source/anoncvs.html. The 'modulename' is "valgrind". |
|
From: Jeremy F. <je...@go...> - 2003-10-30 07:44:45
|
CVS commit by fitzhardinge: Update some stuff related to the syscalls change: - restart syscalls which return ERESETARTSYS - make code to restart a syscall common - keep a process-wide pending signal set to store as-yet undelivered signals (only used in 2.4 mode; TODO: siginfo, queues) - make execve work a bit better - it is impossible to recover from execve failing, so we try to check that it will before running the syscall itself (also fixes bug with SuSE 8.2 kernel) M +1 -0 coregrind/vg_include.h 1.150 M +1 -1 coregrind/vg_mylibc.c 1.55 M +40 -52 coregrind/vg_signals.c 1.47 M +60 -12 coregrind/vg_syscalls.c 1.51 M +1 -0 include/vg_kerneliface.h 1.4 M +1 -1 include/vg_skin.h 1.96 |
|
From: Jeremy F. <je...@go...> - 2003-10-31 07:12:54
|
CVS commit by fitzhardinge: Patch from Robert Walsh <rj...@du...>. Adds some new client requests to allow client code to print messages through Valgrind's logging mechanism. The new requests are: VALGRIND_PRINTF - do a normal printf (prefixed with **PID**) VALGRIND_PRINTF_BACKTRACE - do a printf with stack trace VALGRIND_INTERNAL_PRINTF - printf, but for internal use (prefixed with ==PID==) VALGRIND_INTERNAL_PRINTF_BACKTRACE - as above, with backtrace M +5 -2 corecheck/tests/Makefile.am 1.13 M +31 -0 coregrind/vg_include.h 1.152 M +25 -10 coregrind/vg_messages.c 1.8 M +28 -0 coregrind/vg_scheduler.c 1.131 M +9 -0 coregrind/docs/coregrind_core.html 1.14 M +39 -0 include/valgrind.h 1.21 M +7 -5 include/vg_skin.h 1.98 M +2 -2 tests/filter_stderr_basic 1.11 |
|
From: Dirk M. <mu...@kd...> - 2003-10-31 03:44:29
|
CVS commit by mueller:
fixes .cfi configure problem. apparently compiling is not enough
to invoke the gnu as in all cases.
M +1 -1 configure.in 1.98
--- valgrind/configure.in #1.97:1.98
@@ -284,5 +284,5 @@
# check if the GNU as supports CFI directives
AC_MSG_CHECKING([if gas accepts .cfi])
-AC_TRY_COMPILE(, [
+AC_TRY_LINK(, [
__asm__ __volatile__ (".cfi_startproc\n"
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 16:28:11
|
CVS commit by nethercote: Deleted FAQ #2, as it is no longer relevant for the head, thanks to Jeremy's syscalls changes. M +1 -17 FAQ.txt 1.16 --- valgrind/FAQ.txt #1.15:1.16 @@ -41,21 +41,5 @@ ----------------------------------------------------------------- -Q2. My program dies complaining that syscall 197 is unimplemented. - -A2. 197, which is fstat64, is supported by valgrind. The problem is - that the /usr/include/asm/unistd.h on the machine on which your - valgrind was built, doesn't match your kernel -- or, to be more - specific, glibc is asking your kernel to do a syscall which is - not listed in /usr/include/asm/unistd.h. - - The fix is simple. Somewhere near the top of - coregrind/vg_syscalls.c, add the following line: - - #define __NR_fstat64 197 - - Rebuild and try again. The above line should appear before any - uses of the __NR_fstat64 symbol in that file. If you look at the - place where __NR_fstat64 is used in vg_syscalls.c, it will be - obvious why this fix works. +Q2. [Question erased, as it is no longer relevant] ----------------------------------------------------------------- |
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 16:32:36
|
CVS commit by nethercote: Updated FAQ #8, to reflect the fact that we now support a lot of SSE/SSE2 instructions. MERGE TO STABLE M +7 -13 FAQ.txt 1.17 --- valgrind/FAQ.txt #1.16:1.17 @@ -137,19 +137,13 @@ ----------------------------------------------------------------- -Q8. My program dies (exactly) like this: +Q8. My program dies, printing a message like this along the way: - REPE then 0xF - valgrind: the `impossible' happened: - Unhandled REPE case + disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 -A8. Yeah ... that I believe is a SSE or SSE2 instruction. Are you - building your app with -march=pentium4 or -march=athlon or - something like that? If you can somehow dissuade gcc from - producing SSE/SSE2 instructions, you may be able to avoid this. - Some folks have reported that removing the flag -march=... - works around this. - - I'd be interested to hear if you can get rid of it by changing - your application build flags. +A8. Valgrind doesn't support the full x86 instruction set, although + it now supports many SSE and SSE2 instructions. If you know + the failing instruction is an SSE/SSE2 instruction, you might + be able to recompile your progrma without it by using the flag + -march to gcc. Either way, let us know and we'll try to fix it. ----------------------------------------------------------------- |
|
From: Julian S. <js...@ac...> - 2003-11-06 00:06:48
|
CVS commit by jseward: It's not good that the head claims to be some old stable version. Change the version number to 'HEAD'. M +1 -1 configure.in 1.99 --- valgrind/configure.in #1.98:1.99 @@ -2,5 +2,5 @@ AC_INIT(coregrind/vg_main.c) # give me a source file, any source file... AM_CONFIG_HEADER(config.h) -AM_INIT_AUTOMAKE(valgrind, 20030725) +AM_INIT_AUTOMAKE(valgrind, HEAD) AM_MAINTAINER_MODE |
|
From: Jeremy F. <je...@go...> - 2003-11-07 23:10:27
|
CVS commit by fitzhardinge: Fix some bugs in syscall/signal handling: If the proxyLWP for a thread got a signal just as we were sending the syscall request to it, then we would end up running the syscall twice. The fix is to not check the results pipe while sending the syscall request - wait until we're in a better state for handling signals (the deadlock the results-read was supposed to avoid cannot actually happen). Related to that, if we're delivering a signal to a thread, and that thread is currently waiting for a syscall to complete, make sure we collect the syscall results before entering the signal handler (otherwise we may end up bogusly trying to restart the syscall by moving EIP back, even though it now points to the signal handler rather than the syscall instruction) This change also adds an assertion to VG_(restart_syscall) to make sure we were actually restarting a syscall and not just randomly changing EIP (this found the problem above). Also, make set/getitimer run in the proxyLWP context, so that they modify/read the proxyLWP's timers rather than the schedluer LWP's timers. M +1 -0 coregrind/vg_include.h 1.153 M +2 -3 coregrind/vg_mylibc.c 1.56 M +28 -6 coregrind/vg_proxylwp.c 1.3 M +11 -11 coregrind/vg_signals.c 1.48 M +19 -2 coregrind/vg_syscalls.c 1.53 M +46 -41 docs/proxylwp.sxw 1.2 M +6 -2 include/valgrind.h 1.22 M +1 -3 include/vg_kerneliface.h 1.5 |
|
From: Jeremy F. <je...@go...> - 2003-11-09 09:57:00
|
CVS commit by fitzhardinge:
Only set the thread's status to WaitSys if we're actually waiting for
a proxyLWP to complete a syscall.
Update sigaltstack test to use mmap to allocate the stack.
M +7 -5 coregrind/vg_syscalls.c 1.54
M +5 -3 memcheck/tests/sigaltstack.c 1.3
--- valgrind/coregrind/vg_syscalls.c #1.53:1.54
@@ -4392,8 +4392,6 @@ Bool VG_(pre_syscall) ( ThreadId tid )
*/
- /* post_syscall expects us to be "waiting" even if we don't
- block */
tst->syscallno = syscallno;
- tst->status = VgTs_WaitSys;
+ vg_assert(tst->status == VgTs_Runnable);
if (syscallno < MAX_SPECIAL_SYS && special_sys[syscallno].before != NULL) {
@@ -4455,4 +4453,9 @@ Bool VG_(pre_syscall) ( ThreadId tid )
VGP_POPCC(VgpCoreSysWrap);
+ /* If we're waiting on the syscall because it's in the hands of the
+ ProxyLWP, then set the thread state to WaitSys. */
+ if (!syscall_done)
+ tst->status = VgTs_WaitSys;
+
return syscall_done;
}
@@ -4478,5 +4481,4 @@ void VG_(post_syscall) ( ThreadId tid )
vg_assert(syscallno != -1); /* must be a current syscall */
- vg_assert(tst->status == VgTs_WaitSys); /* should be blocked waiting */
if (syscallno < MAX_SPECIAL_SYS && special_sys[syscallno].before != NULL) {
--- valgrind/memcheck/tests/sigaltstack.c #1.2:1.3
@@ -4,4 +4,5 @@
#include <malloc.h>
#include <signal.h>
+#include <sys/mman.h>
void sig_handler(int sig){
@@ -15,7 +15,9 @@ int main(int argv, char** argc) {
stack_t sigstk;
struct sigaction act;
- sigstk.ss_sp = (char *)malloc(SIGSTKSZ);
+ static const int size = SIGSTKSZ;
+ char *stk = (char *)mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+ sigstk.ss_sp = stk;
- sigstk.ss_size = SIGSTKSZ;
+ sigstk.ss_size = size;
sigstk.ss_flags = 0;
fprintf(stderr, "calling sigaltstack, stack base is %p\n", sigstk.ss_sp);
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-13 17:35:37
|
CVS commit by nethercote: Changed error messages: now don't print anything below main() unless the new option --show-below-main is on. It's on by default. It also affects suppressions generated with --gen-suppressions=yes. Updated reg tests accordingly. Also updated docs for this. And added some missing command-line args to docs. Also compartmentalised the options a little in the docs, and rearranged the order of options in the usage message, in anticipation of a bigger rearrangement that will be necessary soon -- to distinguish options used by all skins from those used by error-checking skins, to skin-specific ones. M +0 -24 addrcheck/tests/badrw.stderr.exp 1.2 M +0 -22 addrcheck/tests/fprw.stderr.exp 1.2 M +10 -3 coregrind/vg_errcontext.c 1.45 M +2 -0 coregrind/vg_include.h 1.154 M +25 -12 coregrind/vg_main.c 1.120 M +12 -3 coregrind/vg_symtab2.c 1.55 M +141 -85 coregrind/docs/coregrind_core.html 1.15 M +0 -8 memcheck/tests/badaddrvalue.stderr.exp 1.7 M +0 -4 memcheck/tests/badfree.stderr.exp 1.8 M +0 -2 memcheck/tests/badloop.stderr.exp 1.6 M +0 -24 memcheck/tests/badrw.stderr.exp 1.2 M +0 -4 memcheck/tests/clientperm.stderr.exp 1.5 M +0 -12 memcheck/tests/custom_alloc.stderr.exp 1.3 M +0 -4 memcheck/tests/doublefree.stderr.exp 1.8 M +0 -4 memcheck/tests/exitprog.stderr.exp 1.9 M +0 -30 memcheck/tests/fprw.stderr.exp 1.8 M +0 -2 memcheck/tests/fwrite.stderr.exp 1.7 M +0 -2 memcheck/tests/inits.stderr.exp 1.6 M +0 -4 memcheck/tests/inline.stderr.exp 1.8 M +0 -6 memcheck/tests/malloc1.stderr.exp 1.8 M +0 -8 memcheck/tests/malloc2.stderr.exp 1.8 M +0 -2 memcheck/tests/manuel1.stderr.exp 1.6 M +0 -2 memcheck/tests/manuel2.stderr.exp 1.6 M +0 -2 memcheck/tests/manuel3.stderr.exp 1.6 M +0 -4 memcheck/tests/memalign_test.stderr.exp 1.8 M +0 -2 memcheck/tests/memcmptest.stderr.exp 1.7 M +0 -2 memcheck/tests/metadata.stderr.exp 1.2 M +0 -24 memcheck/tests/mismatches.stderr.exp 1.9 M +0 -2 memcheck/tests/nanoleak.stderr.exp 1.8 M +0 -14 memcheck/tests/overlap.stderr.exp 1.7 M +0 -2 memcheck/tests/pushfpopf.stderr.exp 1.7 M +0 -12 memcheck/tests/realloc3.stderr.exp 1.2 M +0 -2 memcheck/tests/signal2.stderr.exp 1.7 M +0 -2 memcheck/tests/supp2.stderr.exp 1.6 M +0 -1 memcheck/tests/trivialleak.stderr.exp 1.7 M +0 -2 memcheck/tests/tronical.stderr.exp 1.7 M +0 -6 memcheck/tests/writev.stderr.exp 1.3 |
|
From: Nicholas N. <nj...@ca...> - 2003-11-13 17:54:19
|
CVS commit by nethercote: Changed error messages: subsidiary explanations within an error message are now indented one space; previously it was mixed, but Memcheck/Addrcheck indented "Address" lines 3, which made them hard to see in the stack trace. M +6 -6 addrcheck/tests/badrw.stderr.exp 1.3 M +6 -6 addrcheck/tests/fprw.stderr.exp 1.3 M +16 -16 coregrind/vg_signals.c 1.49 M +14 -12 helgrind/hg_main.c 1.65 M +2 -2 helgrind/tests/deadlock.stderr.exp 1.4 M +2 -2 helgrind/tests/race.stderr.exp 1.4 M +2 -2 helgrind/tests/race2.stderr.exp 1.4 M +5 -5 memcheck/mac_needs.c 1.19 M +2 -2 memcheck/tests/badaddrvalue.stderr.exp 1.8 M +2 -2 memcheck/tests/badfree-2trace.stderr.exp 1.5 M +2 -2 memcheck/tests/badfree.stderr.exp 1.9 M +2 -2 memcheck/tests/badjump.stderr.exp 1.6 M +6 -6 memcheck/tests/badrw.stderr.exp 1.3 M +2 -2 memcheck/tests/buflen_check.stderr.exp 1.7 M +4 -4 memcheck/tests/custom_alloc.stderr.exp 1.4 M +1 -1 memcheck/tests/doublefree.stderr.exp 1.9 M +2 -2 memcheck/tests/errs1.stderr.exp 1.5 M +1 -1 memcheck/tests/exitprog.stderr.exp 1.10 M +6 -6 memcheck/tests/fprw.stderr.exp 1.9 M +1 -1 memcheck/tests/fwrite.stderr.exp 1.8 M +1 -1 memcheck/tests/inline.stderr.exp 1.9 M +2 -2 memcheck/tests/malloc1.stderr.exp 1.9 M +2 -2 memcheck/tests/malloc2.stderr.exp 1.9 M +1 -1 memcheck/tests/memalign_test.stderr.exp 1.9 M +6 -6 memcheck/tests/mismatches.stderr.exp 1.10 M +3 -3 memcheck/tests/realloc3.stderr.exp 1.3 M +1 -1 memcheck/tests/sigaltstack.stderr.exp 1.7 M +1 -1 memcheck/tests/signal2.stderr.exp 1.8 M +1 -1 memcheck/tests/suppfree.stderr.exp 1.5 M +1 -1 memcheck/tests/weirdioctl.stderr.exp 1.7 M +3 -3 memcheck/tests/writev.stderr.exp 1.4 |
|
From: Nicholas N. <nj...@ca...> - 2003-11-13 23:04:09
|
CVS commit by nethercote:
Removed no-longer-needed declarations of __SOME_SKIN_H.
M +0 -4 coregrind/vg_intercept.c 1.24
M +0 -4 coregrind/vg_libpthread.c 1.138
M +1 -4 coregrind/vg_replace_malloc.c 1.13
M +1 -5 coregrind/vg_scheduler.c 1.132
M +0 -2 memcheck/mac_replace_strmem.c 1.6
M +3 -3 none/tests/discard.c 1.3
--- valgrind/coregrind/vg_intercept.c #1.23:1.24
@@ -47,9 +47,5 @@
*/
-/* Sidestep the normal check which disallows using valgrind.h
- directly. */
-#define __VALGRIND_SOMESKIN_H
#include "valgrind.h"
-
#include "vg_include.h"
#include "vg_kerneliface.h"
--- valgrind/coregrind/vg_libpthread.c #1.137:1.138
@@ -53,9 +53,5 @@
*/
-/* Sidestep the normal check which disallows using valgrind.h
- directly. */
-#define __VALGRIND_SOMESKIN_H
#include "valgrind.h" /* For the request-passing mechanism */
-
#include "vg_include.h" /* For the VG_USERREQ__* constants */
--- valgrind/coregrind/vg_replace_malloc.c #1.12:1.13
@@ -42,9 +42,6 @@
------------------------------------------------------------------ */
-#include "vg_include.h"
-
-/* Sidestep the normal check which disallows using valgrind.h directly. */
-#define __VALGRIND_SOMESKIN_H
#include "valgrind.h" /* for VALGRIND_NON_SIMD_CALL[12] */
+#include "vg_include.h"
/*------------------------------------------------------------*/
--- valgrind/coregrind/vg_scheduler.c #1.131:1.132
@@ -29,11 +29,7 @@
*/
-#include "vg_include.h"
-
-/* Sidestep the normal check which disallows using valgrind.h
- directly. */
-#define __VALGRIND_SOMESKIN_H
#include "valgrind.h" /* for VG_USERREQ__RUNNING_ON_VALGRIND and
VG_USERREQ__DISCARD_TRANSLATIONS, and others */
+#include "vg_include.h"
/* BORKAGE/ISSUES as of 29 May 02
--- valgrind/memcheck/mac_replace_strmem.c #1.5:1.6
@@ -32,6 +32,4 @@
#include "mc_include.h"
-
-#define __VALGRIND_SOMESKIN_H
#include "valgrind.h"
--- valgrind/none/tests/discard.c #1.2:1.3
@@ -1,8 +1,8 @@
#include <stdio.h>
-/* Sidestep the normal check which disallows using valgrind.h
- directly. */
-#define __VALGRIND_SOMESKIN_H
#include "../../include/valgrind.h"
+
+
+
int fooble ( void )
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-14 17:48:25
|
CVS commit by nethercote:
Started to rescind the name "skin", replacing it with "tool". Did this in all
the places that normal users will see:
- command line: --tool=foo (although --skin=foo still works)
- docs: removed all traces (included renaming coregrind_skins.html to
coregrind_tools.html)
- in the usage messages
- in error messages
Also did in in some places that I judged were unlikely to cause clashes with
existing workspaces:
- in the header comments of many files (eg. "This file is part of Memcheck, a
Valgrind tool for...")
- in the regtests script
- in the .supp files
- in AUTHORS
- in README_MISSING_SYSCALL_OR_IOCTL
Also update the AUTHORS file to mention Jeremy.
A coregrind/docs/coregrind_tools.html 1.1
M +6 -2 AUTHORS 1.5
M +1 -1 FAQ.txt 1.18
M +6 -6 README_MISSING_SYSCALL_OR_IOCTL 1.4
M +1 -1 glibc-2.1.supp 1.9
M +1 -1 glibc-2.2.supp 1.20
M +1 -1 glibc-2.3.supp 1.7
M +1 -1 linux22.supp 1.8
M +1 -1 linux24.supp 1.7
M +1 -1 make-uninstall-docs 1.2
M +1 -1 xfree-3.supp 1.6
M +1 -1 xfree-4.supp 1.9
M +3 -3 addrcheck/ac_main.c 1.54
M +5 -5 addrcheck/docs/ac_main.html 1.3
M +1 -1 cachegrind/cg_annotate.in 1.18
M +1 -1 cachegrind/cg_main.c 1.56
M +1 -1 cachegrind/cg_sim_D1.c 1.8
M +1 -1 cachegrind/cg_sim_I1.c 1.8
M +1 -1 cachegrind/cg_sim_L2.c 1.8
M +1 -1 cachegrind/cg_sim_gen.c 1.11
M +8 -9 cachegrind/docs/cg_main.html 1.5
M +2 -2 corecheck/cc_main.c 1.16
M +2 -2 corecheck/docs/cc_main.html 1.3
M +17 -24 coregrind/valgrind.in 1.39
M +15 -15 coregrind/vg_default.c 1.18
M +3 -3 coregrind/vg_dummy_profile.c 1.8
M +1 -1 coregrind/vg_errcontext.c 1.46
M +8 -8 coregrind/vg_main.c 1.121
M +4 -4 coregrind/vg_needs.c 1.12
M +1 -1 coregrind/docs/Makefile.am 1.4
M +68 -68 coregrind/docs/coregrind_core.html 1.16
M +32 -37 coregrind/docs/coregrind_intro.html 1.6
M +3 -3 docs/manual.html 1.44
M +2 -2 example/ex_main.c 1.13
M +1 -1 helgrind/helgrind.h 1.6
M +1 -1 helgrind/hg_main.c 1.66
M +3 -3 helgrind/docs/hg_main.html 1.4
M +3 -3 lackey/lk_main.c 1.20
M +3 -3 lackey/docs/lk_main.html 1.3
M +2 -2 memcheck/mac_leakcheck.c 1.10
M +2 -2 memcheck/mac_malloc_wrappers.c 1.8
M +2 -2 memcheck/mac_needs.c 1.20
M +1 -1 memcheck/mac_replace_strmem.c 1.7
M +2 -2 memcheck/mac_shared.h 1.15
M +1 -1 memcheck/mc_clientreqs.c 1.16
M +1 -1 memcheck/mc_constants.h 1.3
M +1 -1 memcheck/mc_errcontext.c 1.21
M +2 -2 memcheck/mc_from_ucode.c 1.12
M +1 -1 memcheck/mc_helpers.S 1.7
M +2 -2 memcheck/mc_include.h 1.17
M +1 -1 memcheck/mc_main.c 1.41
M +1 -1 memcheck/mc_translate.c 1.31
M +1 -1 memcheck/memcheck.h 1.15
M +5 -5 memcheck/docs/mc_main.html 1.10
M +2 -2 none/nl_main.c 1.15
M +4 -4 none/docs/nl_main.html 1.3
M +8 -8 tests/vg_regtest.in 1.15
R coregrind/docs/coregrind_skins.html 1.8
|
|
From: Johan R. <jry...@ni...> - 2003-11-16 11:33:21
|
Nicholas Nethercote <nj...@ca...> wrote: : CVS commit by nethercote: Has this list turned into just a CVS commit list? Why not create a separate valgrind-commit or valgrind-cvs list? It kinda PITA to filter out all these messages from the normal discussions. brgds Johan |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 00:17:50
|
On Sunday 16 November 2003 12:32, Johan Rydberg wrote: > > Has this list turned into just a CVS commit list? Why not create a > separate valgrind-commit or valgrind-cvs list? It kinda PITA to > filter out all these messages from the normal discussions. Its very easy: filter or delete all messages containing the message header X-Commit-Directories: |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 10:38:44
|
CVS commit by nethercote: Made the warning clearer when you try to catch SIGKILL/SIGSTOP. Also made it clearer what's wrong if you try to catch signals 32 and 33; they're not bad signals, just used internally. Updated one regtest accordingly. M +10 -6 corecheck/tests/sigkill.stderr.exp 1.4 M +17 -4 coregrind/vg_signals.c 1.50 |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:04:35
|
On Mon, 17 Nov 2003, Nicholas Nethercote wrote: > Made the warning clearer when you try to catch SIGKILL/SIGSTOP. Also made it > clearer what's wrong if you try to catch signals 32 and 33; they're not bad > signals, just used internally. Updated one regtest accordingly. > > > M +10 -6 corecheck/tests/sigkill.stderr.exp 1.4 > M +17 -4 coregrind/vg_signals.c 1.50 Sometimes these log messages contain the diff, and sometimes they don't. Is there a reason why/why not? I like seeing diffs (although I don't mind it if really big ones are trimmed a bit). N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:19:23
|
On Monday 17 November 2003 12:03, Nicholas Nethercote wrote: > Sometimes these log messages contain the diff, and sometimes they don't. > Is there a reason why/why not? there is a diff when it is < 3kb. > I like seeing diffs (although I don't mind > it if really big ones are trimmed a bit). Thats what it does :) |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:46:01
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > > Sometimes these log messages contain the diff, and sometimes they don't. > > Is there a reason why/why not? > > there is a diff when it is < 3kb. > > > I like seeing diffs (although I don't mind > > it if really big ones are trimmed a bit). > > Thats what it does :) We have different interpretations of "big" and "trimmed" :) 3kb is pretty small. That commit I just made was quite trivial, and it didn't make it. Changes bigger than 3kb are really the ones you want to see, where the commit log message isn't sufficient to understand what just happened. Any chance of this being changed, or is it a KDE-wide thing? As for trimming, I meant if you have 1000 removed lines, and 1000 new lines, having something like [500 removed lines skipped] is fine. The SF.net messages did this sometimes, I think; but they never omitted changes completely. N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:59:13
|
On Monday 17 November 2003 12:45, Nicholas Nethercote wrote: > see, where the commit log message isn't sufficient to understand what just > happened. Any chance of this being changed, or is it a KDE-wide thing? Sure, it can be changed when I know how it should behave.. :) > is fine. The SF.net messages did this sometimes, I think; but they never > omitted changes completely. Yeah.. The main point is that we want people involved in KDE development to be subscribed on kde-cvs. And many claimed that they're not going to subscribe if there are 500kb diffs appended to each mail, which is understandable, because there is not one commit per day, or ten commits per day or even a hundred commits per day but actually many many more. Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? |
|
From: Ashley P. <as...@pi...> - 2003-11-17 12:12:18
|
On Mon, 2003-11-17 at 11:58, Dirk Mueller wrote: > Yeah.. The main point is that we want people involved in KDE development to be > subscribed on kde-cvs. And many claimed that they're not going to subscribe > if there are 500kb diffs appended to each mail, which is understandable, > because there is not one commit per day, or ten commits per day or even a > hundred commits per day but actually many many more. But I'm not subscribed to kde-cvs, I'm subscribed to valgrind-developers so that argument is largely bogus. > Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? I like it (roughly) as it is but it would be nice if the 'trimmed' messages contained a link to the full commit so I could read them if I wanted to. Ashley, |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 12:16:38
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > Yeah.. The main point is that we want people involved in KDE development to be > subscribed on kde-cvs. And many claimed that they're not going to subscribe > if there are 500kb diffs appended to each mail, which is understandable, > because there is not one commit per day, or ten commits per day or even a > hundred commits per day but actually many many more. Fair enough if you're getting commit logs for all of KDE. (People really do that? Wow.) > Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? Assuming this is just for Valgrind commits, I say the higher the better; the bigger it is, the more likely I want to look at it, and we don't have many big commits. Trimming isn't important. Others may disagree. N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 12:30:01
|
On Monday 17 November 2003 13:15, Nicholas Nethercote wrote: > Fair enough if you're getting commit logs for all of KDE. (People really > do that? Wow.) Sure, thats the point of commit logs anyway (peer review and all that). > Assuming this is just for Valgrind commits, I say the higher the better; > the bigger it is, the more likely I want to look at it, and we don't have > many big commits. Trimming isn't important. Others may disagree. Yeah. like those complaining that they get commit logs at all :) Anyway, if you don't like the atomic commit logs at all we can just switch to the sourceforge-style script (which exists for a far longer time than sf but anyway). |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 12:40:13
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > > Fair enough if you're getting commit logs for all of KDE. (People really > > do that? Wow.) > > Sure, thats the point of commit logs anyway (peer review and all that). Yeah, but particular individuals getting all logs for all of KDE? > Anyway, if you don't like the atomic commit logs at all we can just switch to > the sourceforge-style script (which exists for a far longer time than sf but > anyway). I have no complaints about the atomicity of the logs, that is a clear improvement over the SF-style logs; I just want to see all of each diff :) N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 12:25:40
|
On Monday 17 November 2003 13:11, Ashley Pittman wrote: > I like it (roughly) as it is but it would be nice if the 'trimmed' > messages contained a link to the full commit so I could read them if I > wanted to. Well, the commit logs still have the information which files were modified and which revisions there are. we have a script to generate a diff from that. |