July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Jeff Miller

Well, after 7 months in Italy, I have finally made it back to the States. I grabbed 21.2.17 from cvs and the following configuration fails to compile. ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -mal ign-jumps=2 -malign-functions=2' '--package-path=/usr/local/lib/xemacs/packages- 21.0' '--with-x11=no' I get the following error: glyphs.c:2930: parse error before `struct' glyphs.c:2930: `image' undeclared here (not in a function) glyphs.c:2930: initializer element for `glyph_description[0].offset' is not cons tant make[1]: *** [glyphs.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 probably an ifdef based on whether X is available is missing. Jeff

1 participants
0 comments

Re: support of bidirectional text? 26 years

Didier Verna

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Eli Za????? --- retsky -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: support of bidirectional text? 26 years

Jan Vroonhof

"Uwe Brauer" <oub(a)eucmos.sim.ucm.es> writes: > As I understand it this would keep the text, written from the > left-to-the-right but displayed vice versa. Now it is supposed that > GNUemacs 20.4 will have something like this, but it is not clear when > it will be released. Are you sure about the version number? Eli Za????? said in March that he was thinking about it. Progress must have been extremely fast then. It is more likely they meant 20.5 which is going to contain the new end-to-all-problems mystical display engine. > Is there some hope that recent versions of xemacs will have such > type of support. Unless you start hacking, I think this is unlikely. Unfortunately there are no developers who speak any of these R-to-L languages. I think a lesson to be drawn from Mule project is that it this is very important. There is a bit of a chicken and egg problem here. Jan

2 participants
1 comments

support of bidirectional text? 26 years

Uwe Brauer

Hi I am quite interested to edit Hebrew text with emacs/xemacs. For that I re awoke an old Hebrew.el program of the beginning of the nineties. However there the text is written and SAVED from the right-to-the-left, which is sometimes called visual method. However for Tex and other purposes the text should be saved from-the-left-to-the-right and only displayed from the right-to-the-left. Now, although I am not specially attracted by MULE, is seems at the moment that they are only active group working on multilingual support within emacs/xemacs. TAKAHASHI Naoto, of the MULE team told me that they, in order to include Hebrew support within MULE, need something like a support of right-to-left display. As I understand it this would keep the text, written from the left-to-the-right but displayed vice versa. Now it is supposed that GNUemacs 20.4 will have something like this, but it is not clear when it will be released. Is there some hope that recent versions of xemacs will have such type of support. Thanks Uwe Brauer

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 26 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I forgot about the damn GCPROs. There is bound to be code that > assumes characters and integers don't need to be GCPRO'ed. some_function_that_can_gc (make_int (foo), ...); There are hundreds of such in the code. Dozens with make_char().

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 26 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > The second problem is with GC -- any Lisp object storing a character > will then need to be GCPRO'ed. I don't know if this is a big problem > or not, but GCPRO troubles /are/ hard to debug so we should consider > them carefully. I forgot about the damn GCPROs. There is bound to be code that assumes characters and integers don't need to be GCPRO'ed. Jan

1 participants
0 comments

[crash] Opening frame across ssh from inside a screen. 26 years

Karl M. Hegbloom

I logged in across the room vi ssh, started `screen -R', then ran an xemacs -nw. I started gnuserv, and used `make-frame-on-display' from the scratch buffer to try and project across to the display in front of me. It crashed. echo $DISPLAY cathcart.sysc.pdx.edu:11.0 cathcart:~ # w 12:19am up 2 days, 10:06, 3 users, load average: 0.00, 0.02, 0.00 USER TTY FROM LOGIN＠ IDLE JCPU PCPU WHAT root ttyp3 bittersweet:S.1 12:15am 0.00s 0.51s 0.06s w root ttyp1 bittersweet:S.0 12:15am 1:09 0.05s 0.05s /bin/bash cathcart:~ # tty /dev/ttyp3 cathcart:~ # xemacs -vanilla Fatal error: assertion failed, file device-x.c, line 1038, d != NULL Fatal error (6). Your files have been auto-saved. Use `M-x recover-session' to recover them. Please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/local/bin/xemacs core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: # (unwind-protect ...) make-device(x nil) # bind (display) make-x-device(nil) init-x-win() # bind (debugger debug-on-error command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) Aborted [status 134] cathcart:~# gdb xemacs GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-pc-linux-gnu"... (gdb) set args -vanilla (gdb) run Starting program: /usr/local/bin/xemacs -vanilla Fatal error: assertion failed, file device-x.c, line 1038, d != NULL Program received signal SIGABRT, Aborted. 0x40305e81 in () (gdb) where #0 0x40305e81 in () #1 0x40305acf in gsignal () #2 0x40307228 in abort () #3 0x807639a in assert_failed () at emacs.c:2665 #4 0x8123a40 in x_IO_error_handler (disp=0x823d900) at device-x.c:1038 #5 0x401bc2c9 in () #6 0x401b9cde in () #7 0x401ac801 in () #8 0x8122e5a in x_init_device (d=0x8264eb0, props=136233556) at device-x.c:487 #9 0x8069cd0 in Fmake_device (type=136355492, connection=136233556, props=136233556) at device.c:581 #10 0x807a72d in Ffuncall (nargs=3, args=0xbffff0e4) at eval.c:3189 #11 0x8059f9e in execute_optimized_program ( program=0x846e704 "ÀÁ\n\"\207karl＠ca(", stack_depth=3, constants_data=0x82a6b40) at bytecode.c:748 #12 0x8059c46 in funcall_compiled_function (fun=137013920, nargs=1, args=0xbffff1d0) at bytecode.c:521 #13 0x807a887 in Ffuncall (nargs=2, args=0xbffff1cc) at eval.c:3221 #14 0x8059f9e in execute_optimized_program ( program=0x8481464 "\b?%Á\nB\022Ã \210\f＠\rB\026\006ÇÁ!«\b\t¬\005ÈÉ!\021ÊË!\210\016\006A\025Ì\211\020\207error t1", stack_depth=2, constants_data=0x83ee330) at bytecode.c:748 #15 0x8059c46 in funcall_compiled_function (fun=138331408, nargs=0, ---Type <return> to continue, or q <return> to quit--- args=0xbffff2b4) at bytecode.c:521 #16 0x807a887 in Ffuncall (nargs=1, args=0xbffff2b0) at eval.c:3221 #17 0x8059f9e in execute_optimized_program ( program=0x824225c "\bA\031ÂÃ\034\035Æ\t!\021ÇÈ!«\004É \210\016\n«\020\016\013¬\fÌÍÎ\016\n!ÏQ! \210Ð \210*Ñ \210rÒÓ!q\210Ô \210ÕÖ!\210\016\027Øa«\005\016\031 \210)Ú Ûa«\bË ¬\004Ü \210Ý \210Ö\026\036Ë \004ßÃ!)\207macs\037", stack_depth=4, constants_data=0x83285c0) at bytecode.c:748 #18 0x8059c46 in funcall_compiled_function (fun=137511132, nargs=0, args=0xbffff3a0) at bytecode.c:521 #19 0x807a887 in Ffuncall (nargs=1, args=0xbffff39c) at eval.c:3221 #20 0x8059f9e in execute_optimized_program ( program=0x8277104 "\b«\005ÁÂ!\207Ã\020Ä \211\035«\030\rG\016\006GW«\020Ç\016\006!Ç\r!k«\006È\r!\026\006)É\016\006!\026\006Ê \210Ë \210\016\f®\aÍÎ!\002Ã\036\fÏ\016\020\016\021\"\026\022\016\f«\nÓÔÕ\016\022\"Ö\"\210\016\022¬\006× \210ª\fØ\016\022\016\031\016\032\016\f$\210Û \210)\016\034¬\022\016\035«\016Þßà\016!!\016\035\"âÃ#\210\016\034¬\024\016\031¬\006ã\016$!\210ã\016%!\210ã\016&!\210ç\216è )\207", stack_depth=6, constants_data=0x8328440) at bytecode.c:748 #21 0x8059c46 in funcall_compiled_function (fun=137511076, nargs=0, args=0xbffff430) at bytecode.c:521 #22 0x807a38e in Feval (form=137455784) at eval.c:3045 #23 0x80784ba in condition_case_1 (handlers=136233652, bfun=0x8079c54 <Feval>, barg=137455784, hfun=0x8062fe8 <cmd_error>, harg=136233556) at eval.c:1640 #24 0x806305d in top_level_1 (dummy=136233556) at cmdloop.c:205 ---Type <return> to continue, or q <return> to quit--- #25 0x80781ff in internal_catch (tag=136307820, func=0x8063034 <top_level_1>, arg=136233556, threw=0x0) at eval.c:1315 #26 0x8063124 in initial_command_loop (load_me=136233556) at cmdloop.c:284 #27 0x8075508 in sort_args (argc=2, argv=0xbffff794) at emacs.c:1756 #28 0x8075c5e in main () at emacs.c:2181 #29 0x402ff18f in () (gdb) quit The program is running. Exit anyway? (y or n) y cathcart:~ # $ cvs status src/device-x.c =================================================================== File: device-x.c Status: Up-to-date Working revision: 1.33.2.8 Repository revision: 1.33.2.8 /usr/CVSroot/XEmacs/xemacs/src/device-x.c,v Sticky Tag: release-21-2 (branch: 1.33.2) Sticky Date: (none) Sticky Options: (none) uname -a: Linux cathcart.sysc.pdx.edu 2.2.9 #1 SMP Fri May 14 14:39:39 PDT 1999 i686 unknown ./configure '--compiler=egcc' '--cflags=-g -O2 -mpentiumpro' '--with-dialogs=athena3d' '--with-gpm=no' '--package-path=~/.xemacs/::/usr/local/src/XEmacs/Packages' '--debug=no' '--error-checking=none' '--with-clash-detection' '--lockdir=/var/lib/emacs/lock' '--infopath=/usr/share/info:/usr/info:/usr/local/share/info:/usr/local/info:~/.xemacs/info' '--with-mule' '--site-includes=/usr/include/db2' XEmacs 21.2-b17 "Chiyoda" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/XEmacs/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? egcc -g -O2 -mpentiumpro Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Additional header files: /usr/include/db2 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 Berkeley DB. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d dialog boxes. Compiling in DLL support. Clash detection will use "/var/lib/emacs/lock" for locking files. movemail will use "dot-locking" for locking mail spool files.

2 participants
2 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 26 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > > Jan> Maybe putting characters in lrecords for Mule is the way to > > Jan> go. Maybe even with the ugly small-character/big-character > > Jan> thing I reposed for unsigned/signed integers above. > > > > Nope, uh-uh, sorry. There are Emchars in every textual rune. See > > redisplay.h. > > I am sorry but what has that got do with it? Or put otherwise: That > is exactly the point. All code that deals with lots of characters > already deals with emchars directly, not with LispObject. I see two potential problems with lrecord characters. First is efficiency -- examining characters from Lisp would become even slower than it is now because it would involve the overhead of "creating" the character objects. This could be partially solved by implementing the small/big character thing, but it still wouldn't help with, say, large Japanese texts. The second problem is with GC -- any Lisp object storing a character will then need to be GCPRO'ed. I don't know if this is a big problem or not, but GCPRO troubles /are/ hard to debug so we should consider them carefully.

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 26 years

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Jan> Maybe putting characters in lrecords for Mule is the way to > Jan> go. Maybe even with the ugly small-character/big-character > Jan> thing I reposed for unsigned/signed integers above. > > Nope, uh-uh, sorry. There are Emchars in every textual rune. See > redisplay.h. I am sorry but what has that got do with it? Or put otherwise: That is exactly the point. All code that deals with lots of characters already deals with emchars directly, not with LispObject. Jan

1 participants
0 comments

2025

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 July 1999