December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Gnus broken with current CVS XEmacs 21.1.9 version 25 years

Andreas Jaeger

This change in the 21.1.9 CVS version breaks Gnus: 1999-12-03 Yoshiki Hayashi <t90553(a)mail.ecc.u-tokyo.ac.jp> * lisp/mule-misc.el (coding-system-get): Imported from 21.2. (coding-system-put): Ditto. (coding-category): Imported from 21.2 and modified for 21.2. The problem is the following test in Gnus 5.8.3 (file lisp/mm-util.el): (defun mm-preferred-coding-system (charset) ;; A typo in some Emacs versions. (or (get-charset-property charset 'prefered-coding-system) (get-charset-property charset 'preferred-coding-system))) (defun mm-mime-charset (charset) "Return the MIME charset corresponding to the MULE CHARSET." (if (fboundp 'coding-system-get) ;; This exists in Emacs 20. (or (and (mm-preferred-coding-system charset) (coding-system-get (mm-preferred-coding-system charset) 'mime-charset)) (and (eq charset 'ascii) 'us-ascii) (mm-preferred-coding-system charset) (mm-mule-charset-to-mime-charset charset)) ;; This is for XEmacs. (mm-mule-charset-to-mime-charset charset))) Two problems with the code: The first one is XEmacs: XEmacs now has coding-system-get - but it doesn't have get-charset-property. If we have coding-system-get should we also have get-charset-property? The other one is Gnus: Lars, can you change this to check properly XEmacs (sorry, I don't have a patch)? Thanks, Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

2 participants
1 comments

check out our website 25 years

Greg Klanderman

Sorry for the mass mailing, but I just wanted to let you all know our airline travel planning website is up (in beta form) and can be checked out at http://www.itasoftware.com Also, have a look at the truly glowing article about us that appeared in yesterday's Washington Post travel section: http://washingtonpost.com/wp-srv/travel/online/ita120599.htm and the article in the current Industry Standard: http://www.thestandard.com/article/display/0,1151,8029,00.html cheers, Greg

1 participants
0 comments

Windows Headers for Cygwin/MinGW 25 years

Craig Lanning

In trying to get my mingw configuration working again, I reinstalled the cygwin toolchain several times in various configurations. Along the way, I noticed that there are two distinct sets of Windows headers. The original set (from Cygwin b20.1) has several win*.h files which all "#include <windows.h>" and windows.h then includes several files in the Windows32 subdirectory. Things work fine when I use this set of headers. The second set (included in the cygwin-inst-*.tar.gz files) is intended to better mimic the MS Windows headers. When I use these headers, I get complaints about various things being redefined. The build does not complete. I suspect that starting with Cygwin v1.0 and continuing with all subsequent commercial and net releases the included set will be the one which mimics the MS Windows headers. Is there a way to detect which set the compiler is using? Is it important to accomodate both sets of headers? Craig

2 participants
2 comments

Re: "Fix" for Progressbar crash....(and the Gutters exit?) 25 years

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > But how do people who have just overwritten their Xaw headers get things to > work? I must admit to still being confused about what works and what doesn't. > > a) Xaw3d headers, libXaw ? > b) Xaw headers, libXaw - works > c) Xaw headers, libXaw3d ?works No, this is the case that breaks. > d) Xaw3d headers, libXaw3d - ?breaks I am not exactly sure what you mean here. This works. The problem is that xlwgauge.c (and others) use c) in this case. > e) Xaw3d overwritten headers, libXaw3d works Yes. > f) Xaw3d overwritten headers, libXaw - ? Breaks Note that people who have overwritten the headers typically also have overwritten lixXaw.so. > > So what are we fixing and won't we break (e)? Are these all the > possibilites. How do we cope with each? We are trying to never get into c). We want d) Note that e) is what people used to do, but modern installations all use d). we need to do something like this Check for libXaw3d.so If found FOUND_XAW3D = yes LIBXAW3D = libXaw3d.so else FOUND_XAW3D = no Check for libXaw.so If found Check for existance of threeDClassRec if found # Xaw.so is actually Xaw3D FOUND_XAW3D = yes FOUND_XAW = no if not set LIBXAW3D = libXaw3d.so else FOUND_XAW = yes LIBXAWNORMAL = libXaw.so Check for ThreeD_P in Xaw3D/<something>.h if found if FOUND_XAW3D == yes HAVE_XAW3D = yes INCLXAW3D = Xaw3D else check in X11/Xaw/<something.h> if found if FOUND_XAW3D == yes HAVE_XAW3D = yes INCLXAW3D = X11/Xaw else #error else HAVE_XAW3D = no HAVE_XAW = yes INCLXAWBORMAL = X11/Xaw/ ....process user options if HAVE_XAW3D = yes INCLXAW = INCLXAW3D LIBXAW = LIMLXAW3D else if HAVE_XAW = yes INCLXAW = INCLXAWNORMAL LIBXAW = LIMLXAWNORMAL and then make sure we include from INCLXAW and link with LIBXAW Jan

1 participants
0 comments

Re: -b20 and -b22 are leaking tab widgets 25 years

Karl Kleinpaste

Andy Piper <andy(a)xemacs.org> writes: > It seems I wasn't invalidating the subwindow cache often enough so that > widgets wouldn't get GC'd until some major change happened to the frame > (which wouldn't happen while you were reading news). The attached patch > fixes this and at least fixes Jan's test case, I hope it makes things > better generally. Sorry, that patch appears to have no effect at all on my situation -- the newly-compiled XEmacs I'm now using for Gnus is up to 73 children, and counting. xwininfo: Window id: 0x4c00029 "emacs: *Summary nnml:list.xemacs*" Root window id: 0x26 (the root window) (has no name) Parent window id: 0x1804d0e (has no name) 1 child: 0x4c0002a (has no name): () 1267x976+0+0 +5+21 73 children: 0x4c001f8 (has no name): () 15x661+1248+287 +1253+308 0x4c00172 (has no name): () 15x188+1248+85 +1253+106 0x4c00a3c (has no name): () 481x15+4+258 +9+279 0x4c00489 (has no name): () 15x173+485+85 +490+106 0x4c00492 (has no name): () 15x661+485+287 +490+308 0x4c03ab6 (has no name): () 80x18+0+0 +5+21 ... It doesn't seem to have any effect on the minimalist case of repeated "C-x 2 C-x 0", either.

2 participants
1 comments

Re: "Fix" for Progressbar crash....(and the Gutters exit?) 25 years

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > >#ifdef HAVE_XAW3D > ># include <Xaw3D/LabelP.h> > >#else > ># include <X11/Xaw/LabelP.h> > >#endif > > Won't this break people who *have* installed Xaw3d headers over the normal > headers? At least it will do so explicitly and at configure time. IRIC most people who have installed the Xaw3d headers over the normal headers, also have a copy in Xaw3D. Jan

2 participants
1 comments

Re: unexec causes crash in Xt [was: Re: XEmacs 21.1 CVS updates] 25 years

Gunnar Evermann

Alexandre Oliva <oliva(a)lsd.ic.unicamp.br> writes: > On Dec 6, 1999, Gunnar Evermann <ge204(a)eng.cam.ac.uk> wrote: > > > [ Alexandre, are you reading xemacs-beta? > > Nope, sorry. Should I? no, not really -- I just didn't now whether I should CC you. > We should probably stick with unexelfsgi.c, at least for now. Maybe > some day I can try to port/generalize Max Matveev's change to > unexelf.c OK, I'm building with Max's patch now. > > Please note that we have received a couple of reports of similar > > crashes (i.e. same C backtrace) from people using Solaris 7. > > I'm going to give it a try on IRIX and Solaris7. In fact, on all > platforms I've got. Unfortunately, this patch can't possibly make any > difference on Solaris7 :-( > > BTW, which compiler is being used on Solaris7? In 32 or 64 bits mode? Good questions. From what I can see some used gcc (one mentioned having tried gcc 2.8.1 and egcs 1.1.2) and one used Sun's cc. I would guess that most people used 32bit. One report mentioned the same problem on Sparc and x86 Solaris7. Gunnar

1 participants
0 comments

Re: status of PCL-CVS 25 years

Jan Vroonhof

Charles G Waldman <cgw(a)fnal.gov> writes: > Not having gotten any feedback, I was starting to wonder if maybe I > was the only one interested in this! No you are not. I suggest you ask Greg for permission and then do the port. Jan

1 participants
0 comments

Re: unexec causes crash in Xt [was: Re: XEmacs 21.1 CVS updates] 25 years

Jan Vroonhof

Alexandre Oliva <oliva(a)lsd.ic.unicamp.br> writes: > I'm going to give it a try on IRIX and Solaris7. In fact, on all > platforms I've got. Unfortunately, this patch can't possibly make any > difference on Solaris7 :-( > > BTW, which compiler is being used on Solaris7? In 32 or 64 bits mode? Note that on solaris we use their OS provided dumper so we can file a bug report with them. Jan

1 participants
0 comments

Re: status of PCL-CVS 25 years

Mike Fabian

Charles G Waldman <cgw(a)fnal.gov> writes: > The reason I asked is that back in September I posted a patch > > http://www.xemacs.org/list-archives/xemacs-beta/9909/msg00376.html > > which is all that's needed to get pcl-cvs-2.9.7 to work with XEmacs. > > I also cc'd this message to the pcl-cvs mailing list. > > Not having gotten any feedback, I was starting to wonder if maybe I > was the only one interested in this! no, you are not. I would very much appreciate being able to use pcl-cvs-2.9.7 with XEmacs too. Mike -- Mike Fabian <mike.fabian(a)gmx.de> <mike(a)nozomi.rhein-neckar.de>

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

2002

2001

2000

1999

1998

XEmacs-Beta December 1999