June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Symbol's function definition is void: sref 25 years, 6 months

Jan Vroonhof

"Dr. Volker Zell" <vzell(a)de.oracle.com> writes: > e aka `mime-viewer/extract-content' > [..] > Symbol's function definition is void: sref > > My configuration is: > > System: WinNT 4.0/SP3 > [..] > Any hints ? This is a bug in APEL (an emulation library that tm uses), it fails to correctly treat XEmacs-NT (because XEmacs-NT is basically a very very stripped down Mule to deal with the CR/LF issue). You can resolve this particular issue by putting (defalias 'sref 'aref) in your .emacs. Jan P.S. Tomohiko, could you please check whether all the different versions of poem define all the same macros?

1 participants
0 comments

Re: Kerblooey in CDE drag -n- drop 25 years, 6 months

Oliver Graf

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes: > > This kills both 21.1 and 21.2 although the message is different in > > 21.1. I suggest making the default for CDE drag -n- drop be off until > > this bug is fixed. > > I think that is a good idea anyway, because of the _DragMotionProto > crashes we discussed a while back. Those really occur in practice -- I > have the bug reports to proove that :-). This is another problem with the CDE dnd. First I could reproduce it, but with the latest versions, I could not reproduce this bug anymore... I will also have a look at this again. But I don't know if I should really fix CDE, cause if the Motif support is working, we don't need the CDE wrappers anymore (I hope :) ). Regards, Oliver.

1 participants
0 comments

Re: Kerblooey in CDE drag -n- drop 25 years, 6 months

Oliver Graf

Hrvoje Niksic <hniksic(a)srce.hr> writes: > SL Baur <steve(a)xemacs.org> writes: > > > Fatal error: assertion failed, file insdel.c, line 364, VALID_CHARPTR_P (ptr) > > > > Fatal error (6). > > ... > > A gdb/dbx backtrace might be useful here. I suspect the DND functions > are _far_ from Mule-safety. Yap, correct. They are far away from being MULE save. Do I need a special CDE version to test japanese script in dtterm? I will look at this problem tommorrow... Regards, Oliver.

1 participants
0 comments

picture mode and egg 25 years, 6 months

Hironori Komaba

When 'egg' is loaded, the cursor does not move correctly in the picture mode. This problem is observed in XEmacs-20.4 and later. When egg is loaded, self-insert-after-hook should be set to control the cursor movement in the picture mode. Attached patch fixes this problem. In reallity, this is imported from MULE-2.3. :-) Could anybody check the correctness of this patch? -- - Hironori Komaba - mailto:komaba＠jpn.hp.com

1 participants
0 comments

Kerblooey in CDE drag -n- drop 25 years, 6 months

SL Baur

This requires a Mule XEmacs and a dtterm capable of displaying Japanese. Select a string of text displayed in the dtterm by left mouse click such as the string `だったら半角カタカナ' in mule-canna.c. Release the left mouse button and then left mouse click again to drag the text into any convenient XEmacs/Mule built with CDE drag -n- drop. Fatal error: assertion failed, file insdel.c, line 364, VALID_CHARPTR_P (ptr) Fatal error (6). ... This kills both 21.1 and 21.2 although the message is different in 21.1. I suggest making the default for CDE drag -n- drop be off until this bug is fixed. -- I protest the NATO war in Yugoslavia.

2 participants
1 comments

Re: Kerblooey in CDE drag -n- drop 25 years, 6 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Fatal error: assertion failed, file insdel.c, line 364, VALID_CHARPTR_P (ptr) > > Fatal error (6). > ... A gdb/dbx backtrace might be useful here. I suspect the DND functions are _far_ from Mule-safety.

1 participants
0 comments

Re: [Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>] more on the emacs-20.3 segfault 25 years, 6 months

SL Baur

Andreas Jaeger <aj(a)arthur.rhein-neckar.de> writes in xemacs-beta(a)xemacs.org: ... > Andreas Schwab commented on Wolfram's email with: >> Unfortunately this has a very nasty side effect: the protection against >> MALLOC_CHECK_ does not work any more. That means that Emacs will crash if >> MALLOC_CHECK_ is defined in the environment, and there is no way to fix >> that within Emacs (the malloc_initialize_hook runs too late). > And Wolfram replied: >> OK, I'll take a look at whether this can be fixed in malloc. > Therefore your hack might be the better idea. If you still can > reproduce it, you've got to decide yourself which hack works really > better. I was not in the few moments I had before the machine died, but the comment about MALLOC_CHECK_ rings a bell. I do remember getting crashes that way when I was testing. The voodoo_free_hook method had the property that full malloc checking worked without crashing. O.K. I see no reason to change how we do things at this time. We should be immune to the reported crash and if a better method of curing it becomes available some time in the future, we can switch to it. -- I protest the NATO war in Yugoslavia.

1 participants
0 comments

test release of new mailcrypt with pgp5/gnupg support 25 years, 6 months

SL Baur

[Note to Jason, please ignore the bounced version of this message.] I have made a test release of the new mailcrypt that was previously packaged under the name `mailcryptng'. If everything goes O.K. I plan on replacing the old mailcrypt with the new one (with a 2.x XEmacs version number), unless there are any reasonable objections. ftp://ftp.xemacs.org/pub/xemacs/packages/mailcrypt-1.08-pkg.tar.gz -- I protest the NATO war in Yugoslavia.

2 participants
1 comments

Re: [21.1.2] Problems running dumped xemacs on hppa1.1-hp-hpux10.20 25 years, 6 months

Marcus Thiessel

Justin Vallon writes: | On Mon, 31 May 1999, Marcus Thiessel wrote: > (usually use when the process waits very very short time on | > IO). Signals don't get delivered to a process who is currently in that | > state. If the process is blocked on that particular IO you cannot | > SIGKILL it. | | Also, NFS seems to cause this (as well). Locking especially. NFS is a special guest in this case. NFS is designed to never get killed by anybody but to wait. You know the Hitchhiker's Guide (was it)? Remember the story where the spaceship didn't leave before the planet died because no tissues for the passengers were delivered to the ship. So the automatic ship controls (nfsd) decide not to leave. In fact the control program knew that every life on planet would die, but decided to wait because if you wait long enough the lifeforms will return and some small day tissues will be available again. ;-) | > Maybe force --with-dynamic to be yes. | | Hmm. Even without --with-dynamic, [tx]emacs are dynamically linked with | libXm, libXt, libX11, libc, etc. | | --dynamic=no still gave me an executable dynamically linked with libXm, | libXt, libX11, libc, etc. HP-UX 10.20 and --with-dynamic don't work together as expected. I had soem problems with --with-dynamic={yes,no} when building XEmacs on 9.05. | Is src/s/hpux10.h correct here? | I skiped HP-UX 10.20 almost completely with regards to XEmacs beta testing. But as far as I remember there were some build reports: http://www.xemacs.org/list-archives/xemacs-build-reports/9901/msg00024.html This was the last one from the mail archives (xemacs-build-reports) and with no problems reported. | Which again would be shared, but ld chokes on the -Wl,-E (which would be | appropriate if cc -Wl,-E which passes -E to linker stage). I never managed to build XEmacs on HP-UX 9.x with HP C compiler. The one we had at our department was unusable because nobody cared about it. I always used gcc with HP-UX 9.05. So I can tell. | One (unrelated) thing I did notice between hpux9-shr.h and hpux10-shr.h. | hpux10-shr.h: | | /* We must turn off -g since it forces -static. */ | #ifdef __GNUC__ | #undef C_DEBUG_SWITCH | #define C_DEBUG_SWITCH | #endif | | But hpux9-shr.h has that disabled: | | #if 0 /* No longer needed, since in current GCC -g no longer does that. | */ | /* We must turn off -g since it forces -static. */ | #ifdef __GNUC__ | #undef C_DEBUG_SWITCH | #define C_DEBUG_SWITCH | #endif | #endif | | Maybe the hpux10-shr.h also be #if 0'ed? Same in hpux11-shr.h. For sure these file could be cleaned up a little, I guess. --Marcus

2 participants
1 comments

udp vs. multicast group 25 years, 6 months

Stephen Tse

(Didier, I am still struggling with udp stuff...) Hey folks! Have you tried to use `open-multicast-group'? (open-multicast-group "test" "test" "127.0.0.1/7/15") => Signaling: (file-error "error adding membership" "Invalid argument" "test" "127.0.0.1") open-multicast-group-internal("test" "test" "127.0.0.1" 7 15) open-multicast-group("test" "test" "127.0.0.1/7/15") eval((open-multicast-group "test" "test" "127.0.0.1/7/15")) eval-interactive((open-multicast-group "test" "test" "127.0.0.1/7/15")) eval-last-sexp(nil) call-interactively(eval-last-sexp) Same error even if I restrict address between 224.0.0.0 and 239.255.255.255 (why these?) Shouldn't udp as simple as tcp code? This works very well: (open-network-stream "test2" "test2" "127.0.0.1" 7) What I actually try to do is: ;;; ip = icq1.mirabilis.com (open-multicast-group "test" "test" "205.188.252.216/4000/127") Thank you.

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