December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

Raymond Toy <toy(a)rtp.ericsson.se> writes in xemacs-beta(a)xemacs.org: [relocated tm helper scripts] They've been moved from the core to the tm package, and have been there two months now. > That was my first thought. I looked there. I must be blind. I have > tm-1.12-pkg.tar.gz, the latest I can find in the > xemacs-21.0/packages/binary-packages directory. It is now up to tm-1.15. That doesn't look like the right directory. XEmacs 21 packages are located in ftp://ftp.xemacs.org/pub/xemacs/packages/ and I see a `tm-1.15-pkg.tar.gz' there.

1 participants
0 comments

Re: xemacs-fag.info (What is the status of Asian-language support...) 27 years

Hrvoje Niksic

Kenichi Handa <handa(a)etl.go.jp> writes: > Dear Sirs, > > I'm a member of Mule developing team. > > I found this paragraph in emacs-faq.info (XEmacs 20.4). > > ------------------------------------------------------------ > As the fundings on Mule have stopped, Mule part of XEmacs is > currently looking for a full-time maintainer. If you can provide help > here, or are willing to fund the work, please mail to > <xemacs-beta(a)xemacs.org>. > ------------------------------------------------------------ > > But, "the fundings on Mule have stopped" is very misleading. Our > project is still funded well, I think the context makes it abundingly clear that ``Mule'' refers to the XEmacs/Mule support.

2 participants
1 comments

Re: [PATCH] x-(get|set)-font-path 27 years

Christoph Wedler

>>>>>"KJ" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: KJ> Please explain how this baseline-shift property would be used. KJ> I'm assuming it wold do what glyph-baselines do now, except apply KJ> to the glyphs of a face's font. >> >> To display super- and subscripts in HTML and LaTeX buffers (via >> font-lock). >> http://www.fmi.uni-passau.de/~wedler/x-symbol/subscripts.png KJ> Hmmm, OK. I think this would fit better as a font property KJ> specifier, like font-ascent. I don't know. Yes, currently I use different fonts for super- and subscripts. But that's the point: I want to use the same font for super- and subscripts (and any smaller font, not shifted), they just should be displayed differently, i.e., shifted up/down. And having the same font with different font properties sounds strange to me... Also, the font properties seem to correspond to the properties --well-- of the font, i.e., the properties mentioned in the bdf files -- baseline-shift wouldn't. - Christoph

2 participants
1 comments

Problems with dialogs 27 years

Martin Maciaszek

After building XEmacs (with libpng 1.0.1 on a RedHat 5.2 system) I run in some Problems while trying to open a file. When I click on the "Open" icon or use File->Open the Open-file-dialog flashes up and then disappears. In the status line I get the following message: "Symbol's funktion definition is void: xpm-button-create" Is it a Problem with my xpm-libs? (xpm-3.4j) Regards Martin -- In any formula, constants (especially those obtained from handbooks) are to be treated as variables.

1 participants
0 comments

libpng 1.0.2 woes 27 years

Martin Maciaszek

I'm having some questions regarding libpng 1.0.2. While imlib and Emusic wont compile with libpng 1.0.2. XEmacs 21.2.5 wants libpng 1.0.2. I was said that imlib and Emusic don't compile with 1.0.2 because this version is somewhat buggy. So I installed libpng 1.0.1. Now I have to force XEmacs to ompile with is. Now I'm confused. What this all about the different versions of libpng? Regards Martin -- A LISP programmer knows the value of everything, but the cost of nothing. -- Alan Perlis

1 participants
0 comments

Re: Core dump building xemacs 21.0pre59 on HP/UX. 27 years

SL Baur

Christian Hudon <Christian.Hudon.chudon(a)nt.com> writes in xemacs-beta(a)xemacs.org: > Hi, > I'm trying to build xemacs 21.0 beta59, but it dumps core during "testing > for lisp shadows". This is usually an indication of problems during dump, but from the looks of your stack backtrace, this doesn't appear to be the case. > Xemacs was compiled using egcs 1.1b on a HP/UX 9.05 machine. It was configured > as follows: > /configure --prefix=/u/bmtln135/chudon > '--site-prefixes=/u/bmtln135/chudon /usr/local/lib' --error-checking=none > --with-mule --with-xfs Try adding the option `--with-xim=none' and see if that helps. > The xemacs-sumo-19981014.tar.gz file is installed as ~/lib/xemacs > Has anyone had success building recent xemacs 21.0 betas on HP/UX 9? I've built recent non-Mule ones on HP/UX 10.20. I don't know how close that is. ... > #4 malloc (size=1074722608) at gmalloc.c:586 This is a malloc call for an absurd amount of space. > #5 0x80b8fb90 in LoadLocaleName () > #6 0x80b8fa04 in _XlcLoadLocale () > #7 0x80b91138 in _XlcGetLocaleDB () > #8 0x80b91434 in _XlcMakeLocale () > #9 0x80b8f3f4 in _XlcDefaultLoader () > #10 0x80b7fa3c in _XlcCurrentLC () > #11 0x80b7f660 in XSupportsLocale () Frames 5 through 12 are in the libX library. > #12 0xdd444 in Initialize_Locale () at input-method-motif.c:63 This is the entry point for XEmacs XIM stuffs.

5 participants
4 comments

XEmacs 21.0.60 crashes while opening file 27 years

Michael Lundkvist

In XEmacs 21.0 "Poitou60" [Lucid] (sparc-sun-solaris2.5.1, Mule) of Fri Dec 18 1998 on y01u538 configured using `configure --prefix=/home/ye/tss/Mercury/gnu/ --with-gcc --with-gnu-make --with-mule --with-workshop --error-checking=none --gung-ho --site-includes=/home/ye/tss/Mercury/gnu/include --site-libraries=/home/ye/tss/Mercury/gnu/lib --with-workshop' I have a file that crashes both 21.0-b54 and 21.0.60 when I open it. Using C-u C-x C-f and specifying 'no-conversion' makes it load OK. I'm attaching various information and the file that makes it crash. Please tell me if there is anything else you need. Thanks for a great editor! /Micke -- Michael Lundkvist ml(a)epact.se Epact Technology AB Error message from XEmacs: Fatal error (11). 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 /opt/Mercury/temp/xemacs-21.0.60/src/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: # (condition-case ... . error) # (catch top-level ...) Segmentation fault (core dumped) ----------------------------------------------------------------- Backtrace: program terminated by signal SEGV (Segmentation Fault) (dbx) where =>[1] _kill(0x0, 0xb, 0x2c6020, 0x0, 0x0, 0x2c6020), at 0xef17471c [2] fatal_error_signal(0xb, 0x0, 0xefffe2b8, 0x0, 0x0, 0x0), at 0x4ce1c ---- called from signal handler with signal 11 (SIGSEGV) ------ [3] create_text_block(), at 0xf3c20 [4] generate_display_line(0x4e9e00, 0x561048, 0x490800, 0x1, 0x0, 0xefffe7c4), at 0xf0f2c [5] regenerate_window(0x4e9e00, 0x1, 0x4e9e04, 0x1, 0x7ffffffe, 0x1), at 0xf8224 [6] redisplay_window(0x4e9e00, 0x1, 0x0, 0x0, 0x490800, 0x1), at 0xf99c4 [7] redisplay_frame(0x4e9000, 0x0, 0x2c6004, 0x22185c, 0x81010100, 0xff00), at 0xf9d68 [8] redisplay_device(0x3d5700, 0x296800, 0x295fdc, 0xefffe9d0, 0xd, 0xefffe9e0), at 0xf9f7c [9] redisplay_without_hooks(0xfffc0000, 0x0, 0x1, 0x2c6004, 0x2c6004, 0x2bc000), at 0xfa2f0 [10] redisplay(0x2c6004, 0x2c6004, 0x2c6004, 0x2c6004, 0x298400, 0xefffeae8), at 0xffbb8 [11] Fnext_event(0x4d7d74, 0x2c6004, 0x2c6004, 0x295c00, 0x2c6004, 0x0), at 0x8b5a4 [12] Fcommand_loop_1(0x2c6004, 0x440600, 0x296c00, 0x4e734, 0x0, 0x0), at 0x31d34 [13] command_loop_1(0x2c6004, 0xefffed78, 0x2f55ec, 0x0, 0x0, 0x31f60), at 0x31f74 [14] condition_case_1(0x2c6074, 0x31f60, 0x2c6004, 0x31fdc, 0x2c6004, 0x0), at 0x4e790 [15] command_loop_2(0x2c6004, 0x0, 0x0, 0x296c00, 0x320a0, 0xefffec50), at 0x320e4 [16] internal_catch(0x2d9330, 0x320a0, 0x2c6004, 0x0, 0xeffff044, 0x43400c), at 0x560b8 [17] initial_command_loop(0x296800, 0x296c00, 0x434018, 0x43400c, 0x6, 0xeffff593), at 0x31854 [18] xemacs_21_0_b60_sparc_sun_solaris2_5_1(0x1, 0xeffff1ac, 0xeffff1b4, 0x0, 0x0, 0x0), at 0x4b660 [19] main(0x0, 0xeffff1ac, 0xeffff1b4, 0x28d3a8, 0x1, 0x0), at 0x4d004 -----------------------------------------------------------------

1 participants
0 comments

21.2 patch backlog cleared 27 years

Andy Piper

I have applied most patches outstanding for 21.2 core (incluing 21.0). This is still CVS only. I have some elisp that allows me to do this easily but relies on the format: ChangeLog Patch I.e. no ChangeLog and it gets rejected, no patch (including whole files posted) gets rejected. If your patch includes new files please include them in the patch by diffing -uN rather than as a separate file. This does not mean to say the patch gets rejected - it just gets accepted more slowly :) I was unable to apply Jan's package-ui fixes. I haven't applied the new splash screens because I believe there is some contention around them. Note this includes some new stuff, you may want to stick with 21.2.6 for stability. If I have missed anything else please repost to xemacs-patches. andy -- mswindows modeline crash fix from Jonathan Harris -- picon glyph fix from Gunnar Evermann -- widgets-in-buffers and subwindow support from Andy Piper -- movemail pop support under mswindows from Fabrice Popineau -- ldap fixes from Oscar Figueiredo -- fns cleanup from Hrvoje Niksic -- menubar fixes from Didier Verna -- mswindows accelerator fix from Jonathan Harris -- dired mule fix from Didier Verna -- sound doc cleanup from Charles Waldman -- new display table functionality from Hrvoje Niksic -- minor cleanups --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Re: 21.0-b60 missing tm files 27 years

Raymond Toy

>>>>> "CW" == Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: >>>>>> "RT" == Raymond Toy <toy(a)rtp.ericsson.se> writes: RT> I just noticed that 21.0-b60 is missing the tm files like RT> tm-au, tm-file, tm-html, etc. RT> They existed in b57 but not in b59 or b60. RT> Are they found somewhere else now? CW> In the tm package, i.e., lib/xemacs/xemacs-packages/lib-src CW> after having installed the newest tm package. That was my first thought. I looked there. I must be blind. I have tm-1.12-pkg.tar.gz, the latest I can find in the xemacs-21.0/packages/binary-packages directory. This tar file doesn't have any lib-src directory in it. Blind as a bat. Ray P.S. I have to ftp things (get-package doesn't work for me), so if installing tm brings other packages, can you tell me what they are.

1 participants
0 comments

Re: [CRASH] 21.2-b5 with Jonathan's gc crash fix applied 27 years

Adrian Aichner

Here is the VC++ CallStack for another of these crashes. They typically happens while clicking in a Gnus Summary buffer (gnus-version "Pterodactyl Gnus v0.66"), 21.2-b5+. Line 717 in lisp.h is where it ends: => DECLARE_LRECORD (cons, Lisp_Cons); Or, even more precisely in this assembly code which above macro expands to: 717: DECLARE_LRECORD (cons, Lisp_Cons); 01001410 push ebp 01001411 mov ebp,esp 01001413 push ecx 01001414 xor eax,eax 01001416 test eax,eax 01001418 jne error_check_cons+4 (01001414) 0100141A mov ecx,dword ptr [obj] 0100141D and ecx,3 01001420 test ecx,ecx 01001422 jne error_check_cons+28h (01001438) 01001424 mov edx,dword ptr [obj] 01001427 xor eax,eax 01001429 mov al,byte ptr [edx] 0100142B cmp dword ptr [eax*4+118BB9Ch],offset _lrecord_cons (012455a0) 01001436 je error_check_cons+58h (01001468) 01001438 cmp dword ptr [_gc_in_progress (0118bb2c)],0 0100143F je error_check_cons+3Ch (0100144c) 01001441 mov ecx,dword ptr [obj] 01001444 movsx edx,byte ptr [ecx+1] 01001448 test edx,edx 0100144A jne error_check_cons+58h (01001468) 0100144C push offset string "RECORD_TYPEP (obj, lrecord_cons)"... (011860cc) 01001451 push 2CDh 01001456 push offset string "..\\src\\lisp.h" (011860bc) 0100145B call assert_failed (01053a8f) => 01001460 add esp,0Ch 01001463 mov dword ptr [ebp-4],eax 01001466 jmp error_check_cons+5Fh (0100146f) 01001468 mov dword ptr [ebp-4],0 0100146F mov eax,dword ptr [obj] 01001472 mov esp,ebp 01001474 pop ebp 01001475 ret And here the CallStack (I still don't know what is meant by debug_backtrace()): NTDLL! 77f76148() error_check_cons(Lisp_Object {...}) line 717 + 80 bytes condition_case_unwind(Lisp_Object {...}) line 1521 + 9 bytes unbind_to_hairy(int 0x00000017) line 4625 + 18 bytes unbind_to(int 0x00000017, Lisp_Object {...}) line 4600 + 181 bytes garbage_collect_1() line 4548 + 16 bytes Ffuncall(int 0x00000001, Lisp_Object * 0x0082ec08) line 3137 execute_optimized_program(const unsigned char * 0x106eb118, int 0x00000006, Lisp_Object * 0x105eed10) line 750 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 0x00000000, Lisp_Object * 0x0082ee74) line 530 + 53 bytes Feval(Lisp_Object {...}) line 3045 + 20 bytes Fprogn(Lisp_Object {...}) line 761 + 9 bytes funcall_lambda(Lisp_Object {...}, int 0x00000000, Lisp_Object * 0x0082f0e8) line 3508 + 9 bytes Ffuncall(int 0x00000001, Lisp_Object * 0x0082f0e4) line 3229 + 17 bytes execute_optimized_program(const unsigned char * 0x0082f2d8, int 0x00000004, Lisp_Object * 0x01225b3c) line 750 + 16 bytes Fbyte_code(Lisp_Object {...}, Lisp_Object {...}, Lisp_Object {...}) line 2400 + 38 bytes Feval(Lisp_Object {...}) line 2986 + 195 bytes condition_case_1(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x01058b06 Feval(Lisp_Object), Lisp_Object {...}, Lisp_Object (Lisp_Object, Lisp_Object)* 0x0105643e run_condition_case_handlers(Lisp_Object, Lisp_Object), Lisp_Object {...}) line 1640 + 7 bytes condition_case_3(Lisp_Object {...}, Lisp_Object {...}, Lisp_Object {...}) line 1721 + 27 bytes execute_rare_opcode(Lisp_Object * 0x0082f630, const unsigned char * 0x01225e12, int 0x0000008f) line 1275 + 19 bytes execute_optimized_program(const unsigned char * 0x01225d4c, int 0x00000008, Lisp_Object * 0x01225994) line 660 + 17 bytes funcall_compiled_function(Lisp_Object {...}, int 0x00000001, Lisp_Object * 0x0082f92c) line 530 + 53 bytes Ffuncall(int 0x00000002, Lisp_Object * 0x0082f928) line 3221 + 17 bytes execute_optimized_program(const unsigned char * 0x01226764, int 0x00000005, Lisp_Object * 0x01226708) line 750 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 0x00000001, Lisp_Object * 0x0082fc24) line 530 + 53 bytes Ffuncall(int 0x00000002, Lisp_Object * 0x0082fc20) line 3221 + 17 bytes call1(Lisp_Object {...}, Lisp_Object {...}) line 3834 + 11 bytes execute_internal_event(Lisp_Object {...}) line 3044 + 19 bytes Fdispatch_event(Lisp_Object {...}) line 4689 + 9 bytes Fcommand_loop_1() line 578 + 9 bytes command_loop_1(Lisp_Object {...}) line 494 condition_case_1(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x0103a91e command_loop_1(Lisp_Object), Lisp_Object {...}, Lisp_Object (Lisp_Object, Lisp_Object)* 0x0103a3ab cmd_error(Lisp_Object, Lisp_Object), Lisp_Object {...}) line 1640 + 7 bytes command_loop_3() line 255 + 35 bytes command_loop_2(Lisp_Object {...}) line 267 internal_catch(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x0103a513 command_loop_2(Lisp_Object), Lisp_Object {...}, int * volatile 0x00000000) line 1315 + 7 bytes initial_command_loop(Lisp_Object {...}) line 304 + 25 bytes STACK_TRACE_EYE_CATCHER(int 0x00000001, char * * 0x10105680, char * * 0x101ce100, int 0x00000000) line 1715 + 9 bytes main(int 0x00000001, char * * 0x10105680, char * * 0x101ce100) line 2144 + 21 bytes XEMACS! mainCRTStartup + 180 bytes _start() line 165 KERNEL32! 77f1b304() -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

2 participants
1 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 December 1998