February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

XEmacs' desktop icon greyed out - revisited 24 years, 2 months

ALTMARK＠de.ibm.com

Hm, looks like XEmacs doesn't care too much about what visual I want him to use (at least on my graphic card!): altmark＠pdw7: */altmark (1) $ ~/rs_aix43/xemacs/bin/xemacs -visual PseudoColor8 -vanilla Invalid Visual specification in PseudoColor8... ignoring. altmark＠pdw7: */altmark (2) $ ~/rs_aix43/xemacs/bin/xemacs -visual TrueColor24 -vanilla Invalid Visual specification in TrueColor24... ignoring. altmark＠pdw7: */altmark (3) $ ~/rs_aix43/xemacs/bin/xemacs -visual DirectColor24 -vanilla Invalid Visual specification in DirectColor24... ignoring. Needless to say that it starts up with the grey icon at each of these tries. To debugging device-x.c: It decides on TrueColor (visual class 4) with depth 24. Why? x_try_best_visual returns to its caller after successfully trying for TrueColor and a depth >= 16 in the very first if-expression. Within x_try_best_visual_class, the XGetVisualInfo function call assigns a structure to vi_out[0] which has depth=24 and class=4 (TrueColor) field values and will be selected as best visual by the following for-loop. So this visual is what x_try_best_visual_class returns to x_try_best_visual. x_get_visual_depth finds depth 24. I don't know if this is exactly what you wanted, but I gladly provide any further information if necessary. Markus ---------------------- Forwarded by Markus Alt/Germany/IBM on 02/07/2000 10:27 AM --------------------------- ALTMARK(a)de.ibm.com on 02/06/2000 01:40:57 PM Please respond to ALTMARK(a)de.ibm.com To: Kazuyuki IENAGA <kazz(a)imasy.or.jp>, Jan Vroonhof <vroonhof(a)math.ethz.ch>, Valdis.Kletnieks(a)vt.edu cc: xemacs-beta(a)xemacs.org (bcc: Markus Alt/Germany/IBM) Subject: Re: XEmacs' desktop icon greyed out - revisited Will do both (debug device-x.c and also try with 'Emacs.emacsVisual: PseudoColor8') on Monday back at work - unfortunately I have no AIX box here at home ... Valdis, I'm also curious about the new GXT300P (although I must say that I don't too much hope considering the latest experiences with the other cards). We might get some boxes with those cards in 2Q2000 and of course this will be the first thing I'll try on them then! I'll keep you posted. Markus

1 participants
0 comments

Re: start XEmacs on specific CDE desktop (PR#1138) 24 years, 2 months

Pekka Marjola

>>>>> In <14492.37620.809243.143161(a)crystal.WonderWorks.COM>, >>>>> On Sat, 5 Feb 2000 13:15:32 -0800, >>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: Kyle> Gunnar Evermann writes: >> any ideas anyone? >> >> >> From: "Magnant, James A" <James.A.Magnant(a)USAHQ.UnitedSpaceAlliance.com> >> >> Under the older version of Xemacs (20.3), I am able to set my CDE desktop >> session preferences so that Xemacs starts in a particular session "screen" >> in lieu of the "screen" selected at the time it pops up. In addition, the >> CDE home session preferences allow specifying the Xemacs window geometry. >> These settings are stored in the >> $HOME/user_name/.dt/sessions/home/dt.session file. >> >> Using Version 21.1.8, Xemacs does not honor the style manager's "home >> session" settings. Xemacs21 pops up in whatever "screen" the user has >> selected at the time the window activates. Kyle> I vaguely remember something about "session support" code being Kyle> added to XEmacs, but few people actually using it. Magnant's Kyle> XEmacs might be built without this code. It used to be configured Kyle> using --with-session, but that option is gone now. The only Kyle> thing that looks related is --with-wmcommand. Using the old configure option --with-session (or new --with-wmcommand) means that DEVICE_X_WM_COMMAND_FRAME is not set. This is default in 21.1/21.2. (The command is set for device (with XSetCommand), not for frames themselves.) (It also means that -xrm "*Desk: 1" does not work for fvwm anymore.) Compiling --with-session=no should help. -- Pekka.Marjola(a)nixu.fi * http://www.nixu.fi * +358-40-551 4842

1 participants
0 comments

Re: [web] multilingual web service 24 years, 2 months

Didier Verna

Kazuyuki IENAGA <kazz(a)imasy.or.jp> wrote: > So how about to use ``MultiView'' option of Apache? It would be a good thing indeed. What's nice is that providing a new localized version of such or such page doesn't affect the getting of the others. For instance, you can work on index.html.ja and just add it to the directory to actually provided it. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

[web] multilingual web service 24 years, 2 months

Kazuyuki IENAGA

I've noticed that www.xemacs.org has Japanese contents as "/Languages/Japanese/index.html". The host www.xemacs.org is running Apache/1.3.3. So how about to use ``MultiView'' option of Apache? For what about MultiView, see the document of "mod_negotiation". (http://www.apache.org/docs/mod/mod_negotiation.html) There's some sites using it. For example, www.debian.org is one of them. To use or not to use, to be worth or not, I'd like to hear how do you think about it. When I have spare time (after 15 Feb.) and if you agree, I wish to setup some corner of www.xemacs.org to test MultiView. -- kazz

1 participants
0 comments

Re: [From the vaults of xemacs-review] Patch status... 24 years, 2 months

Oscar Figueiredo

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> [...] Jan> [ Most of these will be either Jan> - Unreviewed, or Jan> - Applied but the applier didn't notify xemacs-review] Jan> [...] Jan> 14 Nov 1999 [Oscar Figueiredo ] [21.2] LDAP add and delete functions + interrupt fixes Jan> [...] Jan> 27 Nov 1999 [Oscar Figueiredo ] LDAP extended and revamped Those two have been obsoleted by xemacs-patches : msg00075:"LDAP extensions, take 3" from December 12 1999 which has been notified to me as accepted by Hrvoje but which does neither seem to have been applied nor appears on your list. Oscar

1 participants
0 comments

CVS read lock file removed. 24 years, 2 months

Martin Buchholz

I was getting this during my last checkin: cvs server: [00:00:33] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:01:03] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:01:33] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:02:03] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:02:33] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:03:03] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:03:33] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:04:04] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:04:34] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:05:04] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:05:34] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs cvs server: [00:06:04] waiting for xemacs's lock in /usr/CVSroot/XEmacs/xemacs ... On investigation, I found a stale lock file, which I renamed as follows: -rw-rw-rw- 1 xemacs xemacs 0 Feb 5 07:45 save-#cvs.rfl.camelot-soft.camelot-soft.com.10195 The process appears to still be running. I hope nothing bad happens. Martin

1 participants
0 comments

Re: [PATCH] fix for Crash in mapcar1 .... 24 years, 2 months

Vin Shelton

OK, I'm confused again. The enclosed patch won't apply at all to 21.1. Kyle, is there a similar patch you want to apply for 21.1? I can't grok what's supposed to be going on from the limited context in the patch. The code you referenced does not appear in mapcar1 in 21.1. - vin >>>>> On Thu, 16 Dec 1999, Kyle Jones <kyle_jones(a)wonderworks.com> said: Kyle> Jan Vroonhof writes: >> Here is an easier one >> >> (let ((lijst '(a b c))) >> (mapcar >> (lambda (x) >> ;; Make list shorter behind mapcar's back >> (delete 'c lijst)) >> lijst)) >> >> The problem is this code in in mapcar1 >> >> if (LISTP (seq)) >> { >> for (i = 0; i < leni; i++) >> { >> args[1] = XCAR (seq); >> seq = XCDR (seq); >> result = Ffuncall (2, args); >> if (vals) vals[gcpro1.nvars++] = result; >> } >> } >> >> It blindingly believes that XCDR(seq) will always be a cons cell, >> although it calls user code which could have modified the list it is >> iterating over. Kyle> Here's a patch that fixes this. Recommended for 21.1 and 21.2. Kyle> 1999-12-16 Kyle Jones <kyle_jones(a)wonderworks.com> Kyle> * fns.c (mapcar1): when iterating over a list, check for Kyle> CONSP each iteration because bad user code might have Kyle> modified the list. Call Fcdr/Fcar if CONSP check fails Kyle> so that malformed lists cause an error to be signaled Kyle> instead of crashing. Kyle> --- src/fns.c 1999/10/24 03:48:39 1.30.2.23 Kyle> +++ src/fns.c 1999/12/17 04:13:14 Kyle> ＠＠ -3070,8 +3070,19 ＠＠ Kyle> { Kyle> for (i = 0; i < leni; i++) Kyle> { Kyle> - args[1] = XCAR (seq); Kyle> - seq = XCDR (seq); Kyle> + /* Use XCAR/XCDR to avoid function call overhead if we can. Kyle> + Otherwise call Fcar and Fcdr to get exceptions signaled Kyle> + if the Lisp code mangles the list. */ Kyle> + if (CONSP (seq)) Kyle> + { Kyle> + args[1] = XCAR (seq); Kyle> + seq = XCDR (seq); Kyle> + } Kyle> + else Kyle> + { Kyle> + args[1] = Fcar (seq); Kyle> + seq = Fcdr (seq); Kyle> + } Kyle> result = Ffuncall (2, args); Kyle> if (vals) vals[gcpro1.nvars++] = result; Kyle> }

2 participants
1 comments

Re: [PATCH] fix for Crash in mapcar1 .... 24 years, 2 months

Vin Shelton

Oops. I just found the next thread which Martin started about mapcar1. I will go ahead an apply Kyle's patch for 21.1.9, unless there are any objections. - vin

1 participants
0 comments

Re: [PATCH] fix for Crash in mapcar1 .... 24 years, 2 months

Vin Shelton

Kyle/Martin, What is the status of this? I'd like to have a 21.1.10 patch, if possible. - vin >>>>> On Fri, 17 Dec 1999, Martin Buchholz <martin(a)xemacs.org> said: >>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: Kyle> Jan Vroonhof writes: >>> Here is an easier one >>> >>> (let ((lijst '(a b c))) >>> (mapcar >>> (lambda (x) >>> ;; Make list shorter behind mapcar's back >>> (delete 'c lijst)) >>> lijst)) >>> >>> The problem is this code in in mapcar1 >>> >>> if (LISTP (seq)) >>> { >>> for (i = 0; i < leni; i++) >>> { >>> args[1] = XCAR (seq); >>> seq = XCDR (seq); >>> result = Ffuncall (2, args); >>> if (vals) vals[gcpro1.nvars++] = result; >>> } >>> } >>> >>> It blindingly believes that XCDR(seq) will always be a cons cell, >>> although it calls user code which could have modified the list it is >>> iterating over. Kyle> Here's a patch that fixes this. Recommended for 21.1 and 21.2. Martin> There's another GC bug with this code I tried to fix. If you are Martin> iterating over the list, and the mapping function destructively Martin> modifies the list by breaking it in the middle using (setcdr), the Martin> remaining list will not have any references and can be garbage Martin> collected. Martin> If you evaluate this in a debug xemacs, it will crash. Martin> (let ((x (list (cons 1 1) (cons 2 2) (cons 3 3) (cons 4 4)))) Martin> (mapcar (lambda (y) Martin> (garbage-collect) Martin> (when (eq (car y) 2) Martin> (setcdr x nil) Martin> (garbage-collect)) Martin> (print (car y))) Martin> x)) Martin> However, my own patch needs more work as well, I think. Perhaps I Martin> should separate out the dostring fiddling from the pure bug fix, eh? Martin> So, for the time being I veto both of our patches. I want to finish Martin> this work since I feel vaguely responsible for the core lisp stuff. Kyle> 1999-12-16 Kyle Jones <kyle_jones(a)wonderworks.com> Kyle> * fns.c (mapcar1): when iterating over a list, check for Kyle> CONSP each iteration because bad user code might have Kyle> modified the list. Call Fcdr/Fcar if CONSP check fails Kyle> so that malformed lists cause an error to be signaled Kyle> instead of crashing. Kyle> --- src/fns.c 1999/10/24 03:48:39 1.30.2.23 Kyle> +++ src/fns.c 1999/12/17 04:13:14 Kyle> ＠＠ -3070,8 +3070,19 ＠＠ Kyle> { Kyle> for (i = 0; i < leni; i++) Kyle> { Kyle> - args[1] = XCAR (seq); Kyle> - seq = XCDR (seq); Kyle> + /* Use XCAR/XCDR to avoid function call overhead if we can. Kyle> + Otherwise call Fcar and Fcdr to get exceptions signaled Kyle> + if the Lisp code mangles the list. */ Kyle> + if (CONSP (seq)) Kyle> + { Kyle> + args[1] = XCAR (seq); Kyle> + seq = XCDR (seq); Kyle> + } Kyle> + else Kyle> + { Kyle> + args[1] = Fcar (seq); Kyle> + seq = Fcdr (seq); Kyle> + } Kyle> result = Ffuncall (2, args); Kyle> if (vals) vals[gcpro1.nvars++] = result; Kyle> }

1 participants
0 comments

Re: old patch still not applied? (really: xemacs-review flame) 24 years, 2 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > http://www.xemacs.org/list-archives/xemacs-patches/199912/msg00036.html > > 1999-12-06 Jan Vroonhof <vroonhof(a)math.ethz.ch> > > * src/syntax.h (SYNTAX_START_P): Check whether the two chars > actually can start a common comment type. > * src/syntax.h (SYNTAX_END_P): ditto for end. > > hasn't been applied to 21.2 yet? Because I forgot.. > I can apply it tomorrow if you like. Please... > Jan, I am not blaming you, in case you forgot. I am just angry that > the xemacs-review board which should take care of such things, keeps > missing stuff like this and non-members are left in the dark about the > status of patches... Unfortunately the patch tracking is currently done using a wetware implemenation that is overloaded with other stuff. This really should be automated, but until then I do it by hand. I am fairly sure we haven't missed any patches by non-XEmacs people. However I do make mistakes (especially when I do this at 3:15am after a full day of bounding Feynman graphs). Somehow my own stuff falls through the cracks more often :-(.. I have only recently made a summary for xemacs-review for the first time. I'll forward it here.. Jan

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 February 2000