November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

.el reported newer for xemacs-packages after DaylightSavingTime ends 24 years, 6 months

Adrian Aichner

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta19) "Shinjuku" [Lucid] (i586-pc-win32) of Sun Oct 24 1999 on ZJ75T configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: All packages were installed when DST was on. Now that DST went off automatically in Europe last sunday morning, I get tons of these messages when any lisp packages are loaded. This happens both in post 21.1.7 and post 21.2-b19 XEmacsen. Any ideas? Adrian Recent keystrokes: C-x m M-x s h - m e s SPC RET C-x 0 x e m a c s - n BS b e t a C-x k RET y misc-user Recent messages (most recent first): Loading c:\XEmacs\xemacs-packages\lisp\mail-lib\mail-extr.elc...done (file mail-extr.el is newer) Loading c:\XEmacs\xemacs-packages\lisp\mail-lib\mail-extr.elc... (file mail-extr.el is newer) Loading mail-extr... Loading emacsbug...done Loading c:\XEmacs\xemacs-packages\lisp\net-utils\emacsbug.elc...done (file emacsbug.el is newer) Loading c:\XEmacs\xemacs-packages\lisp\net-utils\emacsbug.elc... (file emacsbug.el is newer) Loading emacsbug... Buffer *mail* modified; kill anyway? (y or n) Yes Buffer *mail* modified; kill anyway? (y or n) Loading lazy-lock...done

1 participants
0 comments

Re: Q: warn_when_safe vs. stderr_out 24 years, 6 months

Hrvoje Niksic

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Can someone here give me a hint where to start looking for > documentation on usage of warn_when_safe vs. stderr_out in XEmacs > source? Use warn_when_safe() as you would use the Lisp function `display-warning', except that warn_when_safe() accepts format parameters a la `message'. > I wasn't able to find anything on either of them in 21.1 or 21.2 CVS > xemacs/man sources. Huh? `grep warn_when_safe *.c' will give you tens of examples of usage.

1 participants
0 comments

Re: Question about mule compiled elisp files 24 years, 6 months

Jan Vroonhof

James LewisMoss <dres(a)ioa.com> writes: > Is it safe to use mule compiled elisp files with a non-mule binary? Yes, if the source was plain ascii. No, otherwise. > First is that trying to use jka-compr gives an error like > coding-system-for-read undefined. This is a bug in the jka-compr package. There is patch around for ages, but for some reason we haven't had a package release release for some months. These are really urgent patches that are prime candidates for your .diff section This fixes the jka-compr bug http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00013.html This fixes a similar problem in calendar.el http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00063.html This fixes an equally stupid bug with ps-print http://www.xemacs.org/list-archives/xemacs-patches/9907/msg00053.html > 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 wrong. The package-path should NOT contain mule-packages for a non-mule build. Are you setting the package-path explicitly? Jan P.S. I suggest you either use the mainline CVS or weight for .8 as those contain some patches tailor made for you (the Linux dumping architecture problems that I sent you a patch for and a fix work around a bug in the recent glibc version that potato uses)

1 participants
0 comments

Q: warn_when_safe vs. stderr_out 24 years, 6 months

Adrian Aichner

Hello All! Can someone here give me a hint where to start looking for documentation on usage of warn_when_safe vs. stderr_out in XEmacs source? I wasn't able to find anything on either of them in 21.1 or 21.2 CVS xemacs/man sources. Regards, Adrian

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

Jan Vroonhof

Vin Shelton <acs(a)xemacs.org> writes: > /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? Did you rebuild the autoloads? Jan

1 participants
0 comments

Re: "Forked child base mismatch" using MKS Toolkit shell 24 years, 6 months

Adrian Aichner

>>>>> "Andy" == Andy Piper <andyp(a)beasys.com> writes: Andy> Vin, I think this one should go in although it hasn't been Andy> sent to xemacs-patches. However, there maybe some wierd Andy> interaction with Adrian's process patch that should be Andy> checked. Adrian, does your patch include this? Have you No Andy> tried this patch with yours? No I'll try to take a lok at this this evening. Adrian Andy> andy Andy> At 12:44 AM 10/20/99 -0400, Mike Alexander wrote: >> A few weeks ago I sent a message to the list asking if anyone knew what was >> causing the MKS Toolkit Korn shell to fail when used with the XEmacs shell >> command. If you recall any attempt to invoke a sub shell produced the >> message "Forked child base mismatch" and pipes didn't work (they appeared >> to cause the shell to hang). I think I've fixed both problems and the >> shell seems to be working ok now. >> >> The first problem was happening because nt-create-process creates the >> process suspended and then uses run-in-other-process to issue a call to >> SetConsoleCtrlHandler in the new process before it lets it run. Apparently >> this call is doing something (probably allocating memory) which confuses >> the MKS shell. I fixed this by deferring the call to SetConsoleCtrlHandler >> until after the shell has had a chance to initialize. The only way I could >> figure out to do this without changing core XEmacs was to use the >> update_status_if_terminated call back which is a bit of a kludge. If >> someone knows a better way, let me know. >> >> The other problem turned out to be caused by the fact that XEmacs was >> passing the same handle for both StdOutput and StdError. When the shell >> created the pipe between the two commands for something like "ps | sort" it >> got confused because it wasn't expecting two copies of the same >> handle. The net result was that it lost it's connection to StdError so no >> further prompts appeared and I thought the shell had hung. This was easy >> to fix by simply making StdError a copy of the StdOutput handle instead of >> passing the same handle for both. >> >> Here is the patch that fixes both problems I'd appreciate it if someone >> would give it a try and see if it breaks anything. I've tried this with >> the current CVS source as of last night. >> >> >> Mike Alexander Arbortext, Inc. >> mta(a)arbortext.com +1-734-327-6803 >> >> --- process-nt.c 1999/09/11 08:57:25 1.11.2.5 >> +++ process-nt.c 1999/10/19 08:24:07 >> ＠＠ -53,6 +53,7 ＠＠ >> struct nt_process_data >> { >> HANDLE h_process; >> + int need_enable_child_signals; >> }; >> >> #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data)) >> ＠＠ -421,7 +422,7 ＠＠ >> Lisp_Object *argv, int nargv, >> Lisp_Object program, Lisp_Object cur_dir) >> { >> - HANDLE hmyshove, hmyslurp, hprocin, hprocout; >> + HANDLE hmyshove, hmyslurp, hprocin, hprocout, hprocerr; >> LPTSTR command_line; >> BOOL do_io, windowed; >> char *proc_env; >> ＠＠ -472,6 +473,10 ＠＠ >> CreatePipe (&hprocin, &hmyshove, &sa, 0); >> CreatePipe (&hmyslurp, &hprocout, &sa, 0); >> >> + /* Duplicate the stdout handle for use as stderr */ >> + DuplicateHandle(GetCurrentProcess(), hprocout, GetCurrentProcess(), >> &hprocerr, >> + 0, TRUE, DUPLICATE_SAME_ACCESS); >> + >> /* Stupid Win32 allows to create a pipe with *both* ends either >> inheritable or not. We need process ends inheritable, and local >> ends not inheritable. */ >> ＠＠ -599,7 +604,7 ＠＠ >> { >> si.hStdInput = hprocin; >> si.hStdOutput = hprocout; >> - si.hStdError = hprocout; >> + si.hStdError = hprocerr; >> si.dwFlags |= STARTF_USESTDHANDLES; >> } >> >> ＠＠ -614,6 +619,7 ＠＠ >> /* These just have been inherited; we do not need a copy */ >> CloseHandle (hprocin); >> CloseHandle (hprocout); >> + CloseHandle (hprocerr); >> } >> >> /* Handle process creation failure */ >> ＠＠ -640,12 +646,18 ＠＠ >> CloseHandle (pi.hProcess); >> } >> >> - if (!windowed) >> - enable_child_signals (pi.hProcess); >> - >> ResumeThread (pi.hThread); >> CloseHandle (pi.hThread); >> >> + /* Remember to enable child signals later if this is not a windowed >> + app. Can't do it right now because that screws up the MKS Toolkit >> + shell. */ >> + if (!windowed) >> + { >> + NT_DATA(p)->need_enable_child_signals = 10; >> + kick_status_notify (); >> + } >> + >> /* Hack to support Windows 95 negative pids */ >> return ((int)pi.dwProcessId < 0 >> ? -(int)pi.dwProcessId : (int)pi.dwProcessId); >> ＠＠ -664,6 +676,18 ＠＠ >> nt_update_status_if_terminated (struct Lisp_Process* p) >> { >> DWORD exit_code; >> + >> + if (NT_DATA(p)->need_enable_child_signals > 1) >> + { >> + NT_DATA(p)->need_enable_child_signals -= 1; >> + kick_status_notify (); >> + } >> + else if (NT_DATA(p)->need_enable_child_signals == 1) >> + { >> + enable_child_signals(NT_DATA(p)->h_process); >> + NT_DATA(p)->need_enable_child_signals = 0; >> + } >> + >> if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code) >> && exit_code != STILL_ACTIVE) >> { >> ＠＠ -764,6 +788,14 ＠＠ >> int current_group, int nomsg) >> { >> struct Lisp_Process *p = XPROCESS (proc); >> + >> + /* Enable child signals if necessary. This may lose the first >> + but it's better than nothing. */ >> + if (NT_DATA(p)->need_enable_child_signals > 0) >> + { >> + enable_child_signals(NT_DATA(p)->h_process); >> + NT_DATA(p)->need_enable_child_signals = 0; >> + } >> >> /* Signal error if SIGNO cannot be sent */ >> validate_signal_number (signo); >> >> >> Andy> -------------------------------------------------------------- Andy> Dr Andy Piper Andy> Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Correct format for patch attachments 24 years, 6 months

Ben Wing

PLEASE PLEASE PLEASE make sure that, whenever you send a patch as an attachment, the type of the patch is "text/plain". I have seen patches in "application/octet-stream", "application/x-patch", "application/x-diff", "text/x-patch", etc. etc. These weird MIME types screw up my mail reader (and I imagine many other people's, too), so that I have to save the patch out to another directory, go find it again, and open it up in some random Windows text editor crap. If the type is "text/plain", it comes up nicely right in my mail reader, and makes it much more likely that I will carefully go over the patch. So can we agree upon a standard, i.e. all patch attachments are MIME type "text/plain"? Thank you. Ben

1 participants
0 comments

Re: "Forked child base mismatch" using MKS Toolkit shell 24 years, 6 months

Andy Piper

Vin, I think this one should go in although it hasn't been sent to xemacs-patches. However, there maybe some wierd interaction with Adrian's process patch that should be checked. Adrian, does your patch include this? Have you tried this patch with yours? andy At 12:44 AM 10/20/99 -0400, Mike Alexander wrote: >A few weeks ago I sent a message to the list asking if anyone knew what was >causing the MKS Toolkit Korn shell to fail when used with the XEmacs shell >command. If you recall any attempt to invoke a sub shell produced the >message "Forked child base mismatch" and pipes didn't work (they appeared >to cause the shell to hang). I think I've fixed both problems and the >shell seems to be working ok now. > >The first problem was happening because nt-create-process creates the >process suspended and then uses run-in-other-process to issue a call to >SetConsoleCtrlHandler in the new process before it lets it run. Apparently >this call is doing something (probably allocating memory) which confuses >the MKS shell. I fixed this by deferring the call to SetConsoleCtrlHandler >until after the shell has had a chance to initialize. The only way I could >figure out to do this without changing core XEmacs was to use the >update_status_if_terminated call back which is a bit of a kludge. If >someone knows a better way, let me know. > >The other problem turned out to be caused by the fact that XEmacs was >passing the same handle for both StdOutput and StdError. When the shell >created the pipe between the two commands for something like "ps | sort" it >got confused because it wasn't expecting two copies of the same >handle. The net result was that it lost it's connection to StdError so no >further prompts appeared and I thought the shell had hung. This was easy >to fix by simply making StdError a copy of the StdOutput handle instead of >passing the same handle for both. > >Here is the patch that fixes both problems I'd appreciate it if someone >would give it a try and see if it breaks anything. I've tried this with >the current CVS source as of last night. > > >Mike Alexander Arbortext, Inc. >mta(a)arbortext.com +1-734-327-6803 > >--- process-nt.c 1999/09/11 08:57:25 1.11.2.5 >+++ process-nt.c 1999/10/19 08:24:07 >＠＠ -53,6 +53,7 ＠＠ > struct nt_process_data > { > HANDLE h_process; >+ int need_enable_child_signals; > }; > > #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data)) >＠＠ -421,7 +422,7 ＠＠ > Lisp_Object *argv, int nargv, > Lisp_Object program, Lisp_Object cur_dir) > { >- HANDLE hmyshove, hmyslurp, hprocin, hprocout; >+ HANDLE hmyshove, hmyslurp, hprocin, hprocout, hprocerr; > LPTSTR command_line; > BOOL do_io, windowed; > char *proc_env; >＠＠ -472,6 +473,10 ＠＠ > CreatePipe (&hprocin, &hmyshove, &sa, 0); > CreatePipe (&hmyslurp, &hprocout, &sa, 0); > >+ /* Duplicate the stdout handle for use as stderr */ >+ DuplicateHandle(GetCurrentProcess(), hprocout, GetCurrentProcess(), >&hprocerr, >+ 0, TRUE, DUPLICATE_SAME_ACCESS); >+ > /* Stupid Win32 allows to create a pipe with *both* ends either > inheritable or not. We need process ends inheritable, and local > ends not inheritable. */ >＠＠ -599,7 +604,7 ＠＠ > { > si.hStdInput = hprocin; > si.hStdOutput = hprocout; >- si.hStdError = hprocout; >+ si.hStdError = hprocerr; > si.dwFlags |= STARTF_USESTDHANDLES; > } > >＠＠ -614,6 +619,7 ＠＠ > /* These just have been inherited; we do not need a copy */ > CloseHandle (hprocin); > CloseHandle (hprocout); >+ CloseHandle (hprocerr); > } > > /* Handle process creation failure */ >＠＠ -640,12 +646,18 ＠＠ > CloseHandle (pi.hProcess); > } > >- if (!windowed) >- enable_child_signals (pi.hProcess); >- > ResumeThread (pi.hThread); > CloseHandle (pi.hThread); > >+ /* Remember to enable child signals later if this is not a windowed >+ app. Can't do it right now because that screws up the MKS Toolkit >+ shell. */ >+ if (!windowed) >+ { >+ NT_DATA(p)->need_enable_child_signals = 10; >+ kick_status_notify (); >+ } >+ > /* Hack to support Windows 95 negative pids */ > return ((int)pi.dwProcessId < 0 > ? -(int)pi.dwProcessId : (int)pi.dwProcessId); >＠＠ -664,6 +676,18 ＠＠ > nt_update_status_if_terminated (struct Lisp_Process* p) > { > DWORD exit_code; >+ >+ if (NT_DATA(p)->need_enable_child_signals > 1) >+ { >+ NT_DATA(p)->need_enable_child_signals -= 1; >+ kick_status_notify (); >+ } >+ else if (NT_DATA(p)->need_enable_child_signals == 1) >+ { >+ enable_child_signals(NT_DATA(p)->h_process); >+ NT_DATA(p)->need_enable_child_signals = 0; >+ } >+ > if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code) > && exit_code != STILL_ACTIVE) > { >＠＠ -764,6 +788,14 ＠＠ > int current_group, int nomsg) > { > struct Lisp_Process *p = XPROCESS (proc); >+ >+ /* Enable child signals if necessary. This may lose the first >+ but it's better than nothing. */ >+ if (NT_DATA(p)->need_enable_child_signals > 0) >+ { >+ enable_child_signals(NT_DATA(p)->h_process); >+ NT_DATA(p)->need_enable_child_signals = 0; >+ } > > /* Signal error if SIGNO cannot be sent */ > validate_signal_number (signo); > > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: Patches Applied for 21.1.8 24 years, 6 months

Vin Shelton

I'm a little confused; do I need to apply this patch to 21.1.8 in addition to Adrian's patch for call process cleanup? --- nt.c~ Thu Jul 15 09:58:41 1999 +++ nt.c Tue Oct 26 16:45:40 1999 ＠＠ -608,7 +608,9 ＠＠ "EMACSLOCKDIR", "INFOPATH" }; - +#ifdef HEAP_IN_DATA + cache_system_info (); +#endif for (i = 0; i < countof (env_vars); i++) { if (!getenv (env_vars[i]) &&

2 participants
1 comments

--pdump -vs- fast-lock/lazy loaded byte code? 24 years, 6 months

SL Baur

[This is very exciting to me to see things this close, go go Olivier.] $ ./temacs Fatal error: assertion failed, file /usr/local/devel/xemacs-21.2/src/lread.c, line 487, !purify_flag Fatal error (6). ... Lisp backtrace follows: # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("fast-lock" nil nil nil binary) # bind (path handler filename nosuffix nomessage noerror file) load("fast-lock" nil nil nil) # (unwind-protect ...) turn-on-fast-lock() run-hooks(turn-on-fast-lock) # bind (on-p maximum-size arg) font-lock-mode(1) turn-on-font-lock() run-hooks(turn-on-font-lock) lisp-interaction-mode() # (unwind-protect ...) # bind (command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) zsh: 13346 IOT instruction (core dumped) ./temacs $ gdb ./temacs core GNU gdb 4.18 ... This GDB was configured as "sparc-sun-solaris2.6"... ... (gdb) where #0 0x6f607418 in _libc_kill () from /usr/lib/libc.so.1 #1 0xb6108 in fatal_error_signal (sig=6) at /usr/local/devel/xemacs-21.2/src/emacs.c:276 #2 <signal handler called> #3 0x6f607418 in _libc_kill () from /usr/lib/libc.so.1 #4 0x6f5ba52c in abort () from /usr/lib/libc.so.1 #5 0xb6068 in fatal_error_signal (sig=3023096) at /usr/local/devel/xemacs-21.2/src/emacs.c:2796 This crash doesn't happen when I run --vanilla, so I presume it has something to do with either fast-lock or more likely, lazy loaded byte code. uname -a: SunOS miho 5.6 Generic_105181-05 sun4u sparc ../xemacs-21.2/configure '--with-mule' '--debug=yes' '--error-checking=all' '--extra-verbose=no' '--site-prefixes=/usr/local' '--compiler=gcc' '--mail-locking=file' '--srcdir=../xemacs-21.2' '--cflags=-g -O3' '--site-includes=/usr/lib/locale/ja/wnn/demo/include' '--site-libraries=/usr/lib/locale/ja/wnn/lib' '--with-scrollbars=athena3d' '--with-dialogs=athena3d' '--with-xim=none' '--with-widgets=athena3d' '--pdump' XEmacs 21.2-b19 "Shinjuku" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /usr/local/devel/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -g -O3 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? /usr/dt/include /usr/local/X11R6/include Where do we find X Windows libraries? /usr/dt/lib /usr/local/X11R6/lib Additional header files: /usr/lib/locale/ja/wnn/demo/include Additional libraries: /usr/lib/locale/ja/wnn/lib Additional prefixes: /usr/local Runtime library search path: /usr/lib/locale/ja/wnn/lib:/usr/local/lib:/usr/dt/lib:/usr/local/X11R6/lib:/usr/local/qt/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 support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Using WNN version 6. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Athena-3d scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Using the new portable dumper (wishful thinking). 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: ---------------------------------------------------------

3 participants
2 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