Re: coloured emojis and regional indicators kill gitk
Ben Pfaff wrote: > FWIW, I don't see the crash here with > git-gui version 0.21.0.99.gdf4f9e > libXft-2.3.3-7.fc35.x86_64 > using Fedora Core 35. Good to hear that the fix is being rolled out. > I did get a funny message I've never seen before from "git fetch": > $ git fetch > remote: Counting objects: 19423, done. > remote: warning: suboptimal pack - out of memory > remote: Compressing objects: 100% (3819/3819), done. > > I guess Savannah is running low on memory. Savannah was moved to a new machine a week ago. [1] If the problem persists, you might want to open a ticket at [2]. Bruno [1] https://savannah.nongnu.org/support/?110588 [2] https://savannah.nongnu.org/support/?group=administration
Re: coloured emojis and regional indicators kill gitk
On Fri, Dec 31, 2021 at 6:19 AM Bruno Haible wrote: > gitk crashes when displaying a specific commit in the gnulib git repo. > > How to reproduce: > $ gitk > Navigate to the commit 2995fb5e993a5d7434d96465758087b35a1488ac Interesting. FWIW, I don't see the crash here with git-gui version 0.21.0.99.gdf4f9e libXft-2.3.3-7.fc35.x86_64 using Fedora Core 35. I did get a funny message I've never seen before from "git fetch": $ git fetch remote: Counting objects: 19423, done. remote: warning: suboptimal pack - out of memory remote: Compressing objects: 100% (3819/3819), done. I guess Savannah is running low on memory.
Re: Infinite recusion in test-timespec_getres.exe
On 12/31/21 04:56, Gisle Vanem wrote: Paul Eggert wrote: On 12/30/21 07:48, Gisle Vanem wrote: -#elif defined HAVE_TIMESPEC_GETRES +#elif defined HAVE_TIMESPEC_GETRES && HAVE_TIMESPEC_GETRES This change has an effect only if there's the equivalent of '#define HAVE_TIMESPEC_GETRES 0' somewhere. Since 'time.in.h' says: # if ! @HAVE_TIMESPEC_GETRES@ _GL_FUNCDECL_SYS (timespec_getres, int, (struct timespec *ts, int base) .. it makes sense to me this should be replaced with a '0' or '1'. That would make sense, but it's not how it works. Although the shell variable and Makefile macro (which is what @HAVE_TIMESPEC_GETRES@ expands to) is either 0 or 1, the C preprocessor macro of the same name is either 1 or undefined. This is like most other HAVE_ symbols, e.g., HAVE_OPENAT. Or you mean it should be replaced with defined HAVE_TIMESPEC_GETRES ? I don't see why anything needs replacing. Perhaps you configured or built with the compiler option '-DHAVE_TIMESPEC_GETRES=0'? If so, don't do that. On the other hand, if './gnulib-tool --test timespec_getres' caused the stack overflow you mentioned, without any special compiler options, we need to figure out how the HAVE_TIMESPEC_GETRES preprocessor macro was incorrectly #defined to 0. I fail to understand how the value of 'HAVE_TIMESPEC_GETRES' is used by m4 etc. gnulib-tool creates Makefile snippets that use HAVE_TIMESPEC_GETRES. The 'time' module replaces @HAVE_TIMESPEC_GETRES@ with $(HAVE_TIMESPEC_GETRES) in these snippets. When you then run 'configure', it replaces @HAVE_TIMESPEC_GETRES@ with $(HAVE_TIMESPEC_GETRES) in those snippets, and it also defines the Makefile HAVE_TIMESPEC_GETRES macro to be 1 or 0 in the generated Makefiles. 'configure' also arranges for '#define HAVE_TIMESPEC_GETRES 1', or just a comment, to appear in config.h. $ git grep HAVE_TIMESPEC_GETRES lib/gettime-res.c:#elif defined HAVE_TIMESPEC_GETRES lib/time.in.h:# if ! @HAVE_TIMESPEC_GETRES@ m4/time_h.m4: HAVE_TIMESPEC_GETRES=1; AC_SUBST([HAVE_TIMESPEC_GETRES]) m4/timespec_getres.m4:HAVE_TIMESPEC_GETRES=0 modules/time: -e 's|@''HAVE_TIMESPEC_GETRES''@|$(HAVE_TIMESPEC_GETRES)|g' \ modules/timespec_getres:gettime-res [test $HAVE_TIMESPEC_GETRES = 0] modules/timespec_getres:if test $HAVE_TIMESPEC_GETRES = 0; then
coloured emojis and regional indicators kill gitk
Hi, gitk crashes when displaying a specific commit in the gnulib git repo. How to reproduce: $ gitk Navigate to the commit 2995fb5e993a5d7434d96465758087b35a1488ac (title "unilbrk: Update handling of zero-width joiner for Unicode 10.0.0.") => X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 139 (RENDER) Minor opcode of failed request: 20 (RenderAddGlyphs) Serial number of failed request: 12728 Current serial number in output stream: 12796 This is a known bug in the Xft library [1][2]. I noticed that it also happens for "regional indicator" characters. (Pairs of regional indicators render as a region's flag.) Sorry, I did not know about this bug before checking in the commit. Bruno [1] https://unix.stackexchange.com/questions/629281/ [2] https://bugs.launchpad.net/ubuntu/+source/git/+bug/1852985
Re: Infinite recusion in test-timespec_getres.exe
Paul Eggert wrote: On 12/30/21 07:48, Gisle Vanem wrote: -#elif defined HAVE_TIMESPEC_GETRES +#elif defined HAVE_TIMESPEC_GETRES && HAVE_TIMESPEC_GETRES This change has an effect only if there's the equivalent of '#define HAVE_TIMESPEC_GETRES 0' somewhere. Since 'time.in.h' says: # if ! @HAVE_TIMESPEC_GETRES@ _GL_FUNCDECL_SYS (timespec_getres, int, (struct timespec *ts, int base) .. it makes sense to me this should be replaced with a '0' or '1'. Or you mean it should be replaced with defined HAVE_TIMESPEC_GETRES ? But I fail to understand how the value of 'HAVE_TIMESPEC_GETRES' is used by m4 etc. -- --gv
Re: Infinite recusion in test-timespec_getres.exe
On 12/30/21 07:48, Gisle Vanem wrote: -#elif defined HAVE_TIMESPEC_GETRES +#elif defined HAVE_TIMESPEC_GETRES && HAVE_TIMESPEC_GETRES This change has an effect only if there's the equivalent of '#define HAVE_TIMESPEC_GETRES 0' somewhere. How did that happen? If your platform lacks timespec_getres, 'configure' is supposed to arrange for HAVE_TIMEPSEC_GETRES to not be #defined at all.
