September 2005 - XEmacs-Patches - XEmacs Mailing List Archives

[PATCH] Fix non-MULE Windows build 19 years, 1 month

Mike Alexander

As Rick Rankin recently pointed out, the non-MULE Windows build has been broken for a while. I noticed this last night and here's my fix which is somewhat different than his. I just moved the definition of mswindows_current_locale out of the #ifdef MULE rather than calling GetSystemDefaultLCID directly. Mike src/ChangeLog addition: 2005-09-08 Mike Alexander <mta(a)arbortext.com> * intl-win32.c: Move mswindows_current_locale out of #ifdef MULE since it's now called in non-MULE builds. xemacs source patch: Diff command: C:/PROGRA~1/GNU/WinCvs~1.3/cvs -q diff -u Files affected: src/intl-win32.c Index: src/intl-win32.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/intl-win32.c,v retrieving revision 1.15 diff -u -u -r1.15 intl-win32.c --- src/intl-win32.c 2005/03/13 09:21:04 1.15 +++ src/intl-win32.c 2005/09/08 04:11:01 ＠＠ -70,13 +70,35 ＠＠ /* Qcode_page, Qlocale, Qcurrent, Quser_default, Qsystem_default in general-slots.h */ +LCID current_locale; + +static void +set_current_lcid (LCID lcid) +{ + int cp; + + /* This will fail under Win9x, so we remember our own locale rather than + consulting GetThreadLocale. */ + SetThreadLocale (lcid); + current_locale = lcid; + cp = mswindows_locale_to_code_page (lcid); +#ifndef NO_EXT_MULTIBYTE_FEATURES + _setmbcp (cp); +#endif +} + +LCID +mswindows_current_locale (void) +{ + /* Even if SetThreadLocale() failed, return the right locale anyway */ + return current_locale; +} + #ifdef MULE static Lisp_Object Vmswindows_charset_code_page_table; static Lisp_Object Vmswindows_charset_registry_table; -LCID current_locale; - /************************************************************************/ /* Language/locale/code page conversion functions */ ＠＠ -760,21 +782,6 ＠＠ return atoi (codepagestr); } -static void -set_current_lcid (LCID lcid) -{ - int cp; - - /* This will fail under Win9x, so we remember our own locale rather than - consulting GetThreadLocale. */ - SetThreadLocale (lcid); - current_locale = lcid; - cp = mswindows_locale_to_code_page (lcid); -#ifndef NO_EXT_MULTIBYTE_FEATURES - _setmbcp (cp); -#endif -} - DEFUN ("mswindows-set-current-locale", Fmswindows_set_current_locale, 1, 1, 0, /* Set the current MS Windows locale. ＠＠ -974,13 +981,6 ＠＠ #endif /* DEBUG_XEMACS */ -LCID -mswindows_current_locale (void) -{ - /* Even if SetThreadLocale() failed, return the right locale anyway */ - return current_locale; -} - DEFUN ("mswindows-current-locale", Fmswindows_current_locale, 0, 0, 0, /* Return the current MS Windows locale. ＠＠ -2377,9 +2377,7 ＠＠ void init_intl_win32 (void) { -#ifdef MULE set_current_lcid (GetUserDefaultLCID ()); -#endif /* MULE */ if (initialized) /* If not initialized, we also call this, but early -- see the

1 participants
0 comments

Patches for Cygwin build 19 years, 1 month

Rick Rankin

The patches below target three distinct problems with the Cygwin build of 21.5: 1. When building without X, make would exit with a syntax error when including XPM in one of the files in src. I don't recall which file. configure was properly determining the location of the non-X version of the XPM header and library files, but was not propagating the include directive to XE_CFLAGS. The change to configure.ac just adds the correct include directive to XE_CFLAGS. 2. When linking, the linker would complain about an unresolved external mswindows_current_locale when building without MULE. Someone with some knowledge of MULE should look at what I did in event-msw.c. It's very simple and it seems to work so far, but I may just be getting lucky. 3. When installing, lib-src/installexe.sh would add an extra .exe suffix to the end of the executable file name. The result was, in the most recent build, xemacs-21.5-b21.exe.exe. The change to installexe.sh just checks to make sure that the target argument doesn't already end in '.exe' The diffs are against the current CVS code. I've built with and without MULE and X in all combinations and everything appears to be working (so far). --Rick ChangeLog: 2005-08-06 Rick Rankin <rrankin1424 hyphen xemacs at yahoo dot com> * configure.ac: Make sure that the correct include directories are added to XE_CFLAGS for building with XPM and without X * lib-src/installexe.sh: Prevent an extra '.exe' suffix from being added if the target name already has a '.exe' suffix * src/event-msw.c (mswindows_wnd_proc): Make sure that mswindows_current_local doesn't get called if MULE isn't defined. Diffs: Index: configure.ac =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/configure.ac,v retrieving revision 1.11 diff -u --unified -r1.11 configure.ac --- configure.ac 2005/05/28 04:51:28 1.11 +++ configure.ac 2005/09/07 05:25:08 ＠＠ -3755,6 +3755,7 ＠＠ xpm_problem="" if test -z "$with_xpm"; then XE_PREPEND("$incpath_xpm", CFLAGS) + XE_PREPEND("$incpath_xpm", XE_CFLAGS) XE_PREPEND("$libpath_xpm", LDFLAGS) AC_MSG_CHECKING(for Xpm - no older than 3.4f) xe_check_libs=-lXpm ＠＠ -3794,6 +3795,7 ＠＠ XE_PREPEND("$libpath_xpm", LDFLAGS) XE_PREPEND(-lXpm, libs_x) XE_PREPEND("$incpath_xpm", CFLAGS) + XE_PREPEND("$incpath_xpm", XE_CFLAGS) AC_MSG_CHECKING(for \"FOR_MSW\" xpm) xe_check_libs=-lXpm AC_TRY_LINK(, [XpmCreatePixmapFromData()], Index: lib-src/installexe.sh =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lib-src/installexe.sh,v retrieving revision 1.4 diff -u --unified -r1.4 installexe.sh --- lib-src/installexe.sh 2001/04/12 18:21:02 1.4 +++ lib-src/installexe.sh 2005/09/07 05:25:08 ＠＠ -5,11 +5,16 ＠＠ tstr="" -while [ $# -gt 0 ] +while [[ $# -gt 0 ]] do - if [ -f $1.exe ] + if [[ -f $1.exe ]] then - tstr="$tstr$1.exe $2.exe" + if [[ "$2" == *.exe ]] + then + tstr="$tstr$1 $2" + else + tstr="$tstr$1.exe $2.exe" + fi shift 2 else tstr="$tstr$1 " Index: src/event-msw.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/event-msw.c,v retrieving revision 1.104 diff -u --unified -r1.104 event-msw.c --- src/event-msw.c 2005/06/26 18:05:04 1.104 +++ src/event-msw.c 2005/09/07 05:25:09 ＠＠ -2803,7 +2803,11 ＠＠ case KEYCHAR_UNDERLYING_VIRTUAL_KEY_CURRENT_LANGENV: vk_only = 1; case KEYCHAR_CURRENT_LANGENV: +#ifdef MULE lcid = mswindows_current_locale (); +#else + lcid = GetSystemDefaultLCID (); +#endif break; case KEYCHAR_UNDERLYING_VIRTUAL_KEY_DEFAULT_USER:

1 participants
0 comments

Re: [SJT-XFT] Performance enhancement patch - cache the XftDraw structure. 19 years, 1 month

Daniel Pittman

"Stephen J. Turnbull" <stephen(a)xemacs.org> writes: >>>>>> "Daniel" == Daniel Pittman <daniel(a)rimspace.net> writes: > > Daniel> The Xft library uses this structure for, among other > Daniel> things, keeping a cache of rendered characters in the > Daniel> server. > > I'd been wondering about that; it takes forever even over ADSL, and I > bet the speed up will be noticable even on a local connection for a > moderately slow box. I think so. It has certainly made rendering more snappy on my P4m-1.7, which is a very over-powered machine for what it needs to do. > I guess I'm going to have to find the documentation for Xft and add > that to the general-docs package, too, I just have no idea about the > stuff you're finding at this point. There isn't any. The tutorial on Xft by Keith Packard is the closest to documentation I could find. (google xft tutorial, if you don't already know it. :) For the other things, like the question of the expected XftDraw life-span, I answer them by reading code. The Xft library, other Xft applications, and so forth. It isn't much fun, but it does work. Sadly, I cannot find *anything* easier to do when working with this. I would join an Xft mailing list and ask them, if I could find one. :) > Daniel> Retaining the object means that they stick around, rather > Daniel> than being recreated every time text needs to be drawn. > > I would call this "lazy initialization" rather than "caching". It seems to be a bit of both: Xft keeps a limited quantity of Picture/Pixmap memory in the server to retain the rendered characters, and seems to do other stuff in a lazy way. This object is related to both, I think. > I've got your other patch in my development workspace now, but in my > usage pattern it doesn't make any difference. I'll review and apply > this and push ASAP. I found it by using WindowMaker to switch from one desktop to another, showing and hiding XEmacs in the process. This forced a menubar redraw which, in turn, leaked Pictures into the server. I suspect that, normally, you wouldn't see this unless you actually used the menu, and even that might only leak a little. Anyway, it really was a nasty leak for me, so I am glad to have fixed it. > BTW, I'm seeing these: > > X Error of failed request: BadValue (integer parameter out of range for operation) > Major opcode of failed request: 12 (X_ConfigureWindow) > Value in failed request: 0x0 > Serial number of failed request: 11519370 > Current serial number in output stream: 11519377 > > all the time when starting to compose mail or return to reading in > Gnus. Seems to have something to do with window configuration. Uh-huh. I don't see them at all, but I seldom split windows and certainly not into more than a couple of them. I do use Gnus under this branch, BTW. It does look to me like there may be another leak of Pixmaps somewhere in the Xft branch, since they are slowly creeping up and up in my running instance. Pictures are well under control, though, and the system stays nice and responsive despite running more than 24 hours now. Formerly, it would now be slow to the point I could see both complete redraws done by redisplay. :) > I bet it's whatever Michael fixed a month ago, so probably a 21.5.22 > release of the mainline and a synch of sjt-xft to that is in order. At the moment I am still poking at the redisplay code to try and work out what, if any, improvements can be made there. The biggest irritation that the Xft code has for me is a set of rendering issues: * characters, especially 'w', are clipped too aggressively, resulting in the top right corner not drawing well. Oblique lower-case 'd' is worse - it lost the entire stroke, so looks like a 'o' or 'a'... * single pixel wide "droppings" are left all over the place when the display scrolls. The easiest way to see it is: - start zmacs selection - move down with 'C-down' until the page switches - watch some lines gain "underbars" in the colour of the zmacs region I suspect that the later is related to the hacks used to address the anti-aliasing bleeding outside the character cell you mention in comments. ...the redisplay code is surely a mess, though. I am giving vague consideration to attacking it the way I did a similar mess many jobs ago. GUI toolkits all seem to end up this way inside. :) Daniel

2 participants
1 comments

[SJT-XFT] Performance enhancement patch - cache the XftDraw structure. 19 years, 1 month

Daniel Pittman

Implementing one of the todo items from the redisplay-x.c code, the following patch keeps an XftDraw structure in the X frame object, and uses that for all drawing related to that frame. The Xft library uses this structure for, among other things, keeping a cache of rendered characters in the server. Retaining the object means that they stick around, rather than being recreated every time text needs to be drawn. This should improve performance everywhere, but most significantly on remote X sessions by avoiding a huge number of X requests to create and destroy the pixmaps associated with the frame. Daniel

2 participants
2 comments

bbdb-gui.el highlight-headers-hack-x-face-p bugglet 19 years, 1 month

Jeff Mincy

Patch for minor bug in bbdb-hack-x-face, which tests (fboundp 'highlight-headers-hack-x-face-p) instead of boundp. Index: bbdb-gui.el =================================================================== RCS file: /home/cvsroot/xemacs/xemacs-packages/lisp/bbdb/bbdb-gui.el,v retrieving revision 1.4 diff -u -d -w -r1.4 bbdb-gui.el --- bbdb-gui.el 9 Nov 2004 19:26:10 -0000 1.4 +++ bbdb-gui.el 29 Jul 2005 00:30:42 -0000 ＠＠ -261,9 +261,8 ＠＠ "Process a face property of a record and honour it. Not done for GNU Emacs just yet, since it doesn't have image support as of GNU Emacs 20.7" - (if (not (or (and (fboundp 'highlight-headers-hack-x-face-p) - (symbol-value (intern ;; compiler - "highlight-headers-hack-x-face-p"))) ;; ick. + (if (not (or (and (boundp 'highlight-headers-hack-x-face-p) + (symbol-value 'highlight-headers-hack-x-face-p)) (and (featurep 'xemacs) (string-match "^21\\." emacs-version)))) ;; XXX () ;; nothing doing 2005-09-05 Jeff Mincy <jeff(a)delphioutpost.com> * bbdb-gui.el (bbdb-hack-x-face): use boundp on highlight-headers-hack-x-face-p -jeff

1 participants
0 comments

Mailing BP Server 19 years, 1 month

Robert

Dear xemacs-patches(a)xemacs.org: BulletProof server: Fresh IPs 1024MB RAM P4 CPU 72GB SCSI Dedicated 100M fiber Unlimited Data Transfer Any software Based in China US$599.00 for per month May use the server for: Bulk Hosting Direct Mailing We also supply Target list according to your order and sending out your message for you. Looking forward to do business with you. Cheers! Robert Server Dept Marketingtoyou(a)126.com For off: NotEmail(a)yahoo.com

1 participants
0 comments

[SJT-XFT] Fix an Xft leak, and make a minor cleanup in the process. 19 years, 1 month

Daniel Pittman

G'day Stephen. I recently got annoyed enough to track down a problem with the XFT branch that was causing my X server to lock up for minutes when I exited XEmacs, as well as causing a gradual slowdown as I used it. Basically, the Xft integration to lwlib was leaking an XftDraw context from menu drawing, resulting in a pixmap leak in the server. Once you have 90,000 Pixmaps, things get a little slow. The server lockup is a suboptimal X.org bug when freeing all 90,000 Pixmaps at one time, apparently. The don't seem to handle that at all well.:) Anyway, the attached patch fixes the leak by freeing the XftDraw context appropriately. It also cleans up some XLFD loading, and adds a more sane fallback path to the font loading. One possible controversial part: the original code tried to enforce that an XLFD font was not scaled, while the new version just doesn't care. I think that is a better behavior, since if someone really wants a scaled font we should oblige them. Daniel ? build.sh ? lib-src/insert-data-in-exec ? src/dump-size ? src/xemacs.def ? src/xemacs.def.in Index: lwlib/lwlib-fonts.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lwlib/Attic/lwlib-fonts.c,v retrieving revision 1.1.2.1 diff -u -u -r1.1.2.1 lwlib-fonts.c --- lwlib/lwlib-fonts.c 2004/11/25 12:44:05 1.1.2.1 +++ lwlib/lwlib-fonts.c 2005/09/02 07:39:45 ＠＠ -26,6 +26,8 ＠＠ /* Synched up with: Not in GNU Emacs. */ #include <config.h> +#include <stdio.h> +#include <stdlib.h> #include "lwlib-fonts.h" #if 0 ＠＠ -62,29 +64,24 ＠＠ pos++; } + /* #### hard-coding DefaultScreen is evil! */ if (count < 14 && !(count >= 5 && index (name, '*'))) - /* #### hard-coding DefaultScreen is evil! */ res = XftFontOpenName (dpy, DefaultScreen (dpy), name); else - { - FcPattern *pat = FcPatternCreate (); - /* This is the magic pattern to open core fonts ... */ - /* Dudes, I love Xft!!! */ - FcPatternAddString (pat, XFT_XLFD, (FcChar8 *) name); - /* #### Is this core fonts, or is this using the core protocol when - Xrender is unavailable? */ - FcPatternAddBool (pat, XFT_CORE, True); - FcPatternAddBool (pat, FC_SCALABLE, False); - res = XftFontOpenPattern (dpy, pat); - } + res = XftFontOpenXlfd (dpy, DefaultScreen (dpy), name); + + /* Try for a generic monospace font */ + if (!res) + res = XftFontOpenName (dpy, DefaultScreen (dpy), "monospace"); + /* Try for anything we can get */ if (!res) - /* this is our last try ... */ res = XftFontOpenName (dpy, DefaultScreen (dpy), ""); if (!res) { /* #### This is Just So Wrong ... ! */ /* sorry folks ... */ + fprintf (stderr, "Unable to find any usable XFT font, even the defaults!\n"); abort (); return 0; } Index: lwlib/xlwmenu.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lwlib/xlwmenu.c,v retrieving revision 1.37.2.2 diff -u -u -r1.37.2.2 xlwmenu.c --- lwlib/xlwmenu.c 2004/12/10 06:43:25 1.37.2.2 +++ lwlib/xlwmenu.c 2005/09/02 07:39:47 ＠＠ -894,6 +894,7 ＠＠ XftTextExtents8 (display, renderFont, &string[start], end - start, &glyphinfo); + XftDrawDestroy (xftDraw); return glyphinfo.xOff; } #else

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

XEmacs-Patches September 2005