November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: menubar.c in current cvs doesn't like me 24 years, 5 months

Gunnar Evermann

Jeff Miller <jmiller(a)smart.net> writes: > have you applied any patches or anything odd? perhaps one of your .c > or .h files was corrupted? > > a possible suggestion... occaasionally, I remove all the .c & .h > files from, say, src or lib-src, so-on, prior to a cvs update, just to > make sure everything is clean...... might be worth a shot. you can use 'cvs diff' to achieve the same. I do that quite often just to check that I removed all my old changes. Gunnar

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, 5 months

Jan Vroonhof

Vin Shelton <acs(a)xemacs.org> writes: > Vin> Meanwhile, in my package-less XEmacs, I can still use the toolbar (at > Vin> least to cut text). What was the bug that I was trying to address by > Vin> copying xpm-button.el to the lisp directory? xpm-button.el is used by gui.el, which is used to make the dialog box you get on the find-file button. Jan

1 participants
0 comments

Re: menubar.c in current cvs doesn't like me 24 years, 5 months

Michael Harnois

On 31 Oct 1999 17:45:23 -0600, Michael Harnois <mharnois(a)willinet.net> said: > /usr/src/xemacs-21.2/src/menubar.c:531: macro > `DEFVAR_SYMVAL_FWD_OBJECT' used with too many (55) args make[1]: > *** [menubar.o] Error 1 Am I really the only one seeing this? And if so, can someone please help me figure out why? I configured with "with menubars=none" and got past this error, but then hit this one: /usr/src/xemacs-21.2/src/file-coding.c:694: parse error at null character /usr/src/xemacs-21.2/src/file-coding.c: In function `Fmake_coding_system': /usr/src/xemacs-21.2/src/file-coding.c:866: number of arguments doesn't match prototype /usr/src/xemacs-21.2/src/file-coding.c:694: prototype declaration /usr/src/xemacs-21.2/src/file-coding.c:873: `type' undeclared (first use in this function) /usr/src/xemacs-21.2/src/file-coding.c:873: (Each undeclared identifier is reported only once /usr/src/xemacs-21.2/src/file-coding.c:873: for each function it appears in.) /usr/src/xemacs-21.2/src/file-coding.c:890: `name' undeclared (first use in this function) /usr/src/xemacs-21.2/src/file-coding.c:894: `doc_string' undeclared (first use in this function) /usr/src/xemacs-21.2/src/file-coding.c:900: `props' undeclared (first use in this function) make[1]: *** [file-coding.o] Error 1 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin

2 participants
1 comments

XEmacs 21.1.8 "Bryce Canyon" Released 24 years, 5 months

Vin Shelton

2 participants
1 comments

Re: Correct format for patch attachments 24 years, 5 months

William M. Perry

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Ben Wing <ben(a)666.com> writes: > > > So can we agree upon a standard, i.e. all patch attachments are MIME > > type "text/plain"? > > We already agreed on that. However it doesn't really help. A lot of > patches are submitted by "first time patchers" and those won't know > that. The problem here is that the TM uses that type as a device for > patches. So we cannot do much more than repeat this plea every now and > again. > > The best solution would be to migrate you away from such a broken > platform. IBM has released its viavoice dev kit for linux as beta, have > you tried using something like kvoice? If it is anything close to > sufficient would create XEmacs support for this. (Unfortunately it is > unlikely that we will be able to release it to the general public). I actually did a bit of hacking with ViaVoice to get XEmacs to recognize it. It wouldn't be that hard to do. I was debating whether to put it in as part of the main XEmacs executable, or just write a generic program that would run in a subprocess and have a process-filter on it that just inserted the text. I didn't actually get any of it working before work starting beckoning again (ah, to have more than a weekend to hack on things). My goal was going to be something like: (defun viavoice-mode (&optional arg) "Toggle ViaVoice mode. With arg, turn ViaVoice mode on if and only if arg is positive. When ViaVoice mode is enabled, voice recognition is performed. All voice data is analyzed and put into the current buffer as keystrokes." ...) (defun viavoice-vocabulary-define-word () "Define a word in the XEmacs vocabulary for voice recognition. You will be prompted to say the word clearly, as well as type the textual equivalent." ...) (defun viavoice-vocabulary-remove-word () "Remove a word from the XEmacs vocabulary for voice recognition." ...) (defun viavoice-vocabulary-save () "Save the currently loaded vocabulary" ...) ViaVoice mode would basically boil down to turning the mic on and off by the appropriate ViaVoice SDK functions. If anybody wants to hack on this, I'd love to help as much as I can. I need to just take a month off from work. :( -Bill P.

2 participants
1 comments

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

Vin Shelton

Well, I don't get it, but I finally managed to build an auto-autoloads.el file which included the autoload from xpm-button.el. I checked in that auto-autoload.el file. As you saw from the build bot message, 21.1.8 is in the process of being released. - vin >>>>> On 02 Nov 19990, Vin Shelton <acs(a)xemacs.org> said: Vin> I believe the build scripts take care of rebuilding the autoloads. Vin> Just now I ran 'make autoloads', but it didn't change anything. Vin> ...and there is no mention of the string 'xpm' in any of the Vin> lisp/auto* files. Vin> OK. I built up a 21.1.7 without any packages, and xpm-button-create Vin> does not get defined until I load-library xpm-button. Vin> These lines appear in xpm-button.el: Vin> ;;;###autoload Vin> (defun xpm-button-create (text shadow-thickness fg-color bg-color) Vin> Meanwhile, in my package-less XEmacs, I can still use the toolbar (at Vin> least to cut text). What was the bug that I was trying to address by Vin> copying xpm-button.el to the lisp directory? Vin> I don't get it. Help! Vin> - vin >>>>> On 02 Nov 1999, Jan Vroonhof <vroonhof(a)math.ethz.ch> said: Jan> 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? Jan> Did you rebuild the autoloads? Jan> Jan

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, 5 months

Vin Shelton

I believe the build scripts take care of rebuilding the autoloads. Just now I ran 'make autoloads', but it didn't change anything. ...and there is no mention of the string 'xpm' in any of the lisp/auto* files. OK. I built up a 21.1.7 without any packages, and xpm-button-create does not get defined until I load-library xpm-button. These lines appear in xpm-button.el: ;;;###autoload (defun xpm-button-create (text shadow-thickness fg-color bg-color) Meanwhile, in my package-less XEmacs, I can still use the toolbar (at least to cut text). What was the bug that I was trying to address by copying xpm-button.el to the lisp directory? I don't get it. Help! - vin >>>>> On 02 Nov 1999, Jan Vroonhof <vroonhof(a)math.ethz.ch> said: Jan> 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? Jan> Did you rebuild the autoloads? Jan> Jan

1 participants
0 comments

XEmacs Build Report for XEmacs-21.1.8 24 years, 5 months

XEmacs Build 'Bot

Hello XEmacs beta testers. I am in the process of building XEmacs-21.1.8 for distribution. I have tested the attached configuration. Have a great day! Sincerely, The XEmacs Build 'Bot (revision 2) -- uname -a: Linux zion.ne.mediaone.net 2.2.13 #2 SMP Tue Oct 19 22:29:47 EDT 1999 i686 unknown ./configure '--prefix=/home/acs/cvsroot' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.1.8 "Bryce Canyon" configured for `i686-pc-linux'. Where should the build process find the source code? /home/acs/cvsroot/xemacs-21.1 What installation prefix should install use? /home/acs/cvsroot What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O 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? none Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits.

1 participants
0 comments

Re: Correct format for patch attachments 24 years, 5 months

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > So can we agree upon a standard, i.e. all patch attachments are MIME > type "text/plain"? We already agreed on that. However it doesn't really help. A lot of patches are submitted by "first time patchers" and those won't know that. The problem here is that the TM uses that type as a device for patches. So we cannot do much more than repeat this plea every now and again. The best solution would be to migrate you away from such a broken platform. IBM has released its viavoice dev kit for linux as beta, have you tried using something like kvoice? If it is anything close to sufficient would create XEmacs support for this. (Unfortunately it is unlikely that we will be able to release it to the general public). Jan

2 participants
1 comments

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

Hrvoje Niksic

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Hrvoje> Huh? `grep warn_when_safe *.c' will give you tens of > Hrvoje> examples of usage. > > This is true. I still find it hard though to deduce correct usage > from examples. Yes. Such is the way of hacking XEmacs internals. *Some* things are, of course, explained in the Internals manual, but many more are not. > The recognized warning levels, in decreasing order of priority, > are 'emergency, 'alert, 'critical, 'error, 'warning, 'notice, > 'info, and 'debug. Use common sense. Most code uses 'warning, I think.

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