November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Vin Shelton

1 participants
0 comments

Re: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) 24 years, 6 months

Vin Shelton

I just downloaded the official 21.1.7 tarball from xemacs.org and xpm-button.el is in the lisp directory. Is there something else I needed to do? It seems to get byte-compiled just fine for me. And in fact, list-load-path shadows tells me: /usr/local/xemacs-packages/lisp/xemacs-base/xpm-button hides /usr/local/xemacs/lib/xemacs-21.1.7/lisp/xpm-button Am I missing something? - vin >>>>> On Mon, 01 Nov 1999, "Kevin Oberman" <oberman(a)es.net> said: Kevin> I don't know if it's in core now, but it was NOT in core for Kevin> 21.1.7. It is in xemacs-base.

1 participants
0 comments

[comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) 24 years, 6 months

Jan Vroonhof

Any ideas? xpm-button.el is back in the core wasn't it...? Jan -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

2 participants
1 comments

Question about mule compiled elisp files 24 years, 6 months

James LewisMoss

Is it safe to use mule compiled elisp files with a non-mule binary? I've hit a couple of things that make me think it's not quite right (but close). First is that trying to use jka-compr gives an error like coding-system-for-read undefined. If I set that to nil then I get file-coding-system-alist undefined, but the following bit of code lets jka-compr work just fine. (as far as I can tell) (defvar file-coding-system-alist nil) (defvar coding-system-for-read nil) (require 'jka-compr) (jka-compr-install) The other is that when starting a non-mule binary the warnings (1) (warning/warning) Autoload error in: /usr/share/xemacs21/mule-packages/lisp/skk/auto-autoloads: Cannot open load file: mule (2) (warning/warning) Autoload error in: /usr/share/xemacs21/mule-packages/lisp/lookup/auto-autoloads: Cannot open load file: mule (This is actually from a report from a debian user, but I think I've seen this before. (just tested it and I do see this at startup.)) Again it looks like it is causing no problems, but I wanted to ask in case there were things I should watch out for. Oh and just so you understand how things are compiled: 1) configure for a mule, canna, wnn setup. 2) compile the binary. 3) compile the elisp 4) configure for a mule (no input methods but xim) 5) compile the binary 6) configure for a non-mule 7) compile the binary These are then installed together (with each binary being xemacs-21.1.7-{mule,mule-canna-wnn,nomule} and doc files in /usr/lib/xemacs-21.1.7/i386-debian-linux/{mule,mule-canna-wnn,nomule}/DOC). Thanks Jim -- ＠James LewisMoss <dres(a)ioa.com> | Blessed Be! ＠ http://www.ioa.com/~dres | Linux is kewl! ＠"Argue for your limitations and sure enough, they're yours." Bach

1 participants
0 comments

Re: double negative 24 years, 6 months

Jan Vroonhof

Mikio Nakajima <minakaji(a)osaka.email.ne.jp> writes: > I was doing these for byte-opt.el of FSFmacs, and perhaps has > finished. Now I apply same thing to byte-optimize.el of XEmacs. I > will send diff file xemacs-patches. > > > 1999-11-01 Mikio Nakajima <minakaji(a)osaka.email.ne.jp> Next time please 1. include the Changelog and the patch in the same message 2. Use 'diff -u' thanks.. > > * byte-opt.el: Put byte-optimzier properties of `when' and > `unless' to `byte-optimize-when'. > (byte-optimize-when): New function. > (byte-optimize-form-code-walker): Optimize form of > which car is `when' or `unless'. Why is this needed? Isn't 'when' a macro that expands to (if (form here) (progn ...)) so that just handling the if case is enough? Jan P.S. I'll look at it in more detail later.

1 participants
0 comments

Re: [bug report, 21.2] font-lock face inheritance 24 years, 6 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Note that it would be possible to compatibly add new specifier tags > for all domains, e.g. by a new DOMAINS optional argument to > `define-specifier-tag', Something like that yes. > > However, the problem is that the current specifier implementation has > to be extended to support such on-the-fly fetching of relevant data. > I believe Kirill did some work on this, but it was never finished. I am not sure it is needed to be that dynamic. I thing adding a hook to each specifier that is called when that specifier is changed would be sufficient. Then you could put a hook on the background color specifier of the default face such that when it gets changed you simply recompute the tags, invalidate all the caches and redisplay the whole shebang. This hook could also be used to do other things. For instance imagine that the fallback value of the font specifier of a face is another specifier "font-model-font". Thus specifier is autoconstructed from the face's family, weight and size specifiers, which have hooks on them so that when they get changed the font-model code recomputes font-model-font. Jan

1 participants
0 comments

IRIX6.2 build failure 24 years, 6 months

Paul Bibilo

I CVS updated my source this morning and the build failed. ../configure '--site-libraries=/usr/local/lib' '--site-includes=/usr/local/include' '--cflags=-g' '--package-path=/devdisk/d54man/gnu/xemacs-beta/packages' '--with-mule=no' XEmacs 21.2-b19 "Shinjuku" configured for `mips-sgi-irix6.2'. Where should the build process find the source code? /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/irix6-0.h' and `m/iris4d.h' What compiler should XEmacs be built with? cc -g Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? Where do we find X Windows libraries? Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for DBM. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- A make beta went as usual until this . . . Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loaddefs.elc... Loading site-load... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Testing for Lisp shadows ... Fatal error: assertion failed, file /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/lisp.h, line 650, RECORD_TYPEP (obj, &lrecord_cons) make[1]: *** [xemacs] Abort make[1]: *** Deleting file `xemacs' make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' make: *** [src] Error 1 Any ideas ? -- Paul Bibilo, Delcam plc, | Tel: +44 121 766 5544 Talbot Way, Small Heath, Birmingham, | Fax: +44 121 766 5511 England, B10 0HJ. | ICBM-mail: 52 17N 1 30W #include <disclaimer.h> | ICQ: 32045109

1 participants
0 comments

Re: double negative 24 years, 6 months

Mikio Nakajima

At Mon, 25 Oct 1999 05:36:24 +0900, Mikio Nakajima <minakaji(a)osaka.email.ne.jp> wrote: > At 24 Oct 1999 17:28:35 +0200, > Jan Vroonhof wrote: > > > this is wrong. Although most of the time it won't matter (not (not > > a)) is not equal to a. If you want to do this you must make sure you > > only do it in contexts where we are sure we only want 'non-nil'ness. > > I got it. I will do it in byte-optimize-if or something like that > respectively. I was doing these for byte-opt.el of FSFmacs, and perhaps has finished. Now I apply same thing to byte-optimize.el of XEmacs. I will send diff file xemacs-patches. -- Mikio Nakajima <minakaji(a)osaka.email.ne.jp> <minakaji(a)pdx.ne.jp> (in case of emergency) http://www.asahi-net.or.jp/~gy2m-nkjm/

1 participants
0 comments

Re: --pdump 24 years, 6 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > If you want to try doing that, I'll give you a hint: Create a new > description type (it's simply an enum in lrecord.h), use it for the > hentry pointer description in hash_table_description (instead of the > XD_STRUCT_PTR), and implement your packed dumping in the switchs. > Sincerely, I don't think the difference will be significant. It was just an idea. If you think there will be little or no difference, then it needn't be done. Have you tried measuring startup speed of XEmacs? How long does it take to relocate the data? Is the mmap()ed data shared between XEmacs processes?

2 participants
2 comments

Re: --pdump 24 years, 6 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > > Are you sure about that? What gives you the guarantee that mmap() > > will return the same address? I'm curious. > > Nothing. It's only probable, and due to the identical virtual > memory layout. It may change if some other application forced a > remapping of the shared libraries or this kind of shit. Or if you upgrade to a different OS revision. Or if you take your binary to another system. Or... > > (Something that calls itself a "portable dumper" should be > > portable, after all. OK, I couldn't resist this one.) > > I will still work no matter what mmap returns, of course :-) In that case, I think it should print a really really scary warning.

2 participants
1 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 November 1999