February 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Building packages from source not quite possible 25 years, 9 months

Colin Rafferty

SL Baur writes: > Carsten Leonhardt <leo(a)arioch.oche.de> writes in xemacs-beta(a)xemacs.org: >>>> Well, apparently it doesn't. I just removed "apel" and "tm" from the >>>> REQUIRES line in the Makefile, and it bytecompiles without error. Colin> What Makefile has this REQUIRES line? Is this something that is in Colin> distributed with the BBDB package, something in XEmacs packages, or Colin> something that you did? > It's something I put in to get the bbdb package to build. > Taking it out yields the following: > $ make XEMACS=/usr/local/work/XEmacs/xemacs-21.0/src/xemacs > /usr/local/work/XEmacs/xemacs-21.0/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- bbdb edit-utils gnus mh-e rmail supercite vm mail-lib xemacs-base -- lisp/bbdb-rmail.el > .... > Compiling /usr/local/work/XEmacs/xemacs-packages/comm/bbdb/lisp/bbdb-rmail.el... > While compiling toplevel forms in file /usr/local/work/XEmacs/xemacs-packages/comm/bbdb/lisp/bbdb-rmail.el: > !! File error (("Cannot open load file" "tm-view")) > Done rmail requires tm-view, not bbdb. Thanks for removing the REQUIRES. By the way, bbdb doesn't really need any of the mail/news packages. Building it from scratch, you can choose what to compile it for. Maybe I'll pull down the package-building stuff to see what's there. -- Colin

1 participants
0 comments

curiosity 25 years, 9 months

Giacomo Boffi

how many people are currently subscribed to xemacs-beta? thanks in advance g

1 participants
0 comments

call to make-device crashes XEmacs 25 years, 9 months

Paul Stodghill

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.0 "Pyrenean63" [Lucid] (i686-pc-cygwin32) of Mon Feb 15 1999 on smithers configured using `configure --error-checking=none' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I guess this has something to do with the fact that we can't currently have frame on both X and MSWINDOWS devices. Still, it probably shouldn't crash... smithers% uname -a CYGWIN_NT-4.0 SMITHERS 20.1 (0.3/1/1) 1998-12-3 20:39:18 i686 unknown smithers% echo $DISPLAY 127.0.0.1:0.0 smithers% xemacs -vanilla -eval "(make-device 'mswindows nil)" Fatal error: assertion failed, file event-unixoid.c, line 153, CONSOLE_TTY_P (co n) 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: make-device(mswindows nil) eval((make-device (quote mswindows) nil)) # bind (arg) command-line-do-eval("-eval") # bind (dir file-count line end-of-options first-file-buffer file-p arg tem) command-line-1() # bind (command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) smithers% xemacs -vanilla Recent keystrokes: misc-user Recent messages (most recent first): Parsing /home/stodghil/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug...

1 participants
0 comments

Re: [21.0.63] Bad interaction b/w customize and .Xdefaults 25 years, 9 months

Paul Stodghill

> >> When running under CYGWIN+X, doesn't the second "when" > >> expression just clobber the results of evaluating the first? > > It may very well clobber. However, the *-make-font-* functions > _should_ be checking `locale' to make sure that `locale' matches the > the particular function. Then I must be doing something wrong. Here is when I am trying under CYGWIN+X, % uname -a CYGWIN_NT-4.0 SMITHERS 20.1 (0.3/1/1) 1998-12-3 20:39:18 i686 unknown % xemacs -vanilla M-x debug-on-entry mswindows-make-font-bold M-: (make-face-bold 'bold (frame-device)) At the bottom of this message are the backtraces from entering and exiting the function. Notice that mswindows-make-font-bold is given an X font and returns a Windows font. This font is then "used" on the X device. Oops. Entering: * mswindows-make-font-bold(#<font-instance "-*-Courier-bold-R-*-*-*-140-75-75-*-*-ISO8859-1" on #<x-device on "127.0.0.1:0.0" 0x1e37> 0x40000e 0x1e65> #<x-device on "127.0.0.1:0.0" 0x1e37>) frob-face-property(bold font mswindows-make-font-bold #<x-device on "127.0.0.1:0.0" 0x1e37>) #<compiled-function nil "...(26)" [featurep x frob-face-property face font x-make-font-bold locale mswindows mswindows-make-font-bold] 5>() frob-face-font-2(bold #<x-device on "127.0.0.1:0.0" 0x1e37> default bold #<compiled-function nil "...(12)" [featurep tty set-face-highlight-p face t locale] 5> #<compiled-function nil "...(26)" [featurep x frob-face-property face font x-make-font-bold locale mswindows mswindows-make-font-bold] 5> (([default] . [bold]) ([bold] . t) ([italic] . [bold-italic]) ([bold-italic] . t))) make-face-bold(bold #<x-device on "127.0.0.1:0.0" 0x1e37>) eval((make-face-bold (quote bold) (frame-device))) #<compiled-function (expression &optional eval-expression-insert-value) "...(18)" [eval expression values prin1 eval-expression-insert-value t] 3 712083 (list (read-from-minibuffer "Eval: " nil read-expression-map t ...) current-prefix-arg)>((make-face-bold (quote bold) (frame-device)) nil) call-interactively(eval-expression) Return value: #<font-instance "Courier New:Bold:10::Western" on #<x-device on "127.0.0.1:0.0" 0x1e37> 0x40007d 0x258f> mswindows-make-font-bold(#<font-instance "-*-Courier-bold-R-*-*-*-140-75-75-*-*-ISO8859-1" on #<x-device on "127.0.0.1:0.0" 0x1e37> 0x40000e 0x1e65> #<x-device on "127.0.0.1:0.0" 0x1e37>) frob-face-property(bold font mswindows-make-font-bold #<x-device on "127.0.0.1:0.0" 0x1e37>) * #<compiled-function nil "...(26)" [featurep x frob-face-property face font x-make-font-bold locale mswindows mswindows-make-font-bold] 5>() frob-face-font-2(bold #<x-device on "127.0.0.1:0.0" 0x1e37> default bold #<compiled-function nil "...(12)" [featurep tty set-face-highlight-p face t locale] 5> #<compiled-function nil "...(26)" [featurep x frob-face-property face font x-make-font-bold locale mswindows mswindows-make-font-bold] 5> (([default] . [bold]) ([bold] . t) ([italic] . [bold-italic]) ([bold-italic] . t))) make-face-bold(bold #<x-device on "127.0.0.1:0.0" 0x1e37>) eval((make-face-bold (quote bold) (frame-device))) #<compiled-function (expression &optional eval-expression-insert-value) "...(18)" [eval expression values prin1 eval-expression-insert-value t] 3 712083 (list (read-from-minibuffer "Eval: " nil read-expression-map t ...) current-prefix-arg)>((make-face-bold (quote bold) (frame-device)) nil) call-interactively(eval-expression)

1 participants
0 comments

Re: [21.0.63] Bad interaction b/w customize and .Xdefaults 25 years, 9 months

Jan Vroonhof

Paul Stodghill <stodghil(a)cs.cornell.edu> writes: > > A. Yes. > > At least, in theory it's supposed to. I can't get gnuclient to work > to test it out though.... I am really very impressed with that feat. However why do you need gnuclient for that? Just start it up with a native frame and then 'make-frame-on-display' by hand to make an X frame. > I think that things are even more confused than this. Consider the following > code in make-faces-bold in faces.el, > > (when (featurep 'x) > (frob-face-property face 'font 'x-make-font-bold locale)) > (when (featurep 'mswindows) > (frob-face-property face 'font 'mswindows-make-font-bold locale)) > > When running under CYGWIN+X, doesn't the second "when" expression just clobber > the results of evaluating the first? This is the behavior that I'm seeing. I can not argue with experimental results :-) > There are several other places in faces.el where stuff like this is done... It doesn't surprise me. the customize isn't really up to handling more then one device type let alone four (stream, tty, Win32, x). This needs to mature (and customize needs some rethinking, my hope is that [given the fact that the current answer on g.e.m to every display question is "the new display engine in 20.5 will do that"] the FSF will aslo need to rethink and we can coordinate that. ). Jan

2 participants
1 comments

Re: [21.0.63] Bad interaction b/w customize and .Xdefaults 25 years, 9 months

Paul Stodghill

> Ah... right. I still do not understand completely. Can CYGWIN actually > display _both_ native win32 and X frames in the same instance of X emacs? The answer is, > A. Yes. At least, in theory it's supposed to. I can't get gnuclient to work to test it out though.... > [...] > Ad A. I am impressed. However this is makes it fairly difficult to > solve the problem now. I think that things are even more confused than this. Consider the following code in make-faces-bold in faces.el, (when (featurep 'x) (frob-face-property face 'font 'x-make-font-bold locale)) (when (featurep 'mswindows) (frob-face-property face 'font 'mswindows-make-font-bold locale)) When running under CYGWIN+X, doesn't the second "when" expression just clobber the results of evaluating the first? This is the behavior that I'm seeing. There are several other places in faces.el where stuff like this is done...

4 participants
4 comments

Re: [21.0.63] Bad interaction b/w customize and .Xdefaults 25 years, 9 months

Jan Vroonhof

Paul Stodghill <stodghil(a)cs.cornell.edu> writes: > ^--- This is where things don't go as expected: I'm running under > CYGWIN, so the mswindows _does_ match. However, I'm starting > XEmacs from under X, so I'd like the X resources to take > precedence for frames being displayed under X. Ah... right. I still do not understand completely. Can CYGWIN actually display _both_ native win32 and X frames in the same instance of X emacs? Answer... A. Yes. B. No. It can just display X frames but it runs under NT. Ad B. Then this is a bug, X frames are type X wherever they run. Ad A. I am impressed. However this is makes it fairly difficult to solve the problem now. Jan

2 participants
1 comments

Re: 21.0.63 crash in xlw_menubar init for bad locale 25 years, 9 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > There's something wrong with my Debian `unstable' system, and it > doesn't seem to have a C/POSIX locale. Partly out of curiosity: How unstable is unstable? Are you using the experimental glibc 2.1 stuff? Are you using Branden's latest X 3.2.2.x packages? Are you using Debian-Jp's own X 3.3.3 stuff? Jan P.S. This reminds me on a nice piece of satire by Frans van Dorselaer on c.e.wine about running a beta windows app on an alpha release of wine compiled by a snapshot pgcc compiler against a snapshot glibc :-). This is not a criticism of you but it is true that the typical beta tester is also often more "risk happy" in the choice of his other software.

1 participants
0 comments

Re: Nifty icons for XEmacs? 25 years, 9 months

Jan Vroonhof

jonathan(a)leffert.net (Jonathan B. Leffert) writes: > the OmniGroup. But since I put this package together, I believe > OmniWeb has gone opensource. It does not look that way (given the website). > So, the long and the short of it is that > I have no problem with it, but the OmniGroup might. Is it OK if I ask them? It might wake up some sleeping dogs[1] Jan Footnotes: [1] Does that expression exist in English? I think you understand what I mean anyway.

1 participants
0 comments

KO image patch fixes striped laptop gif display bug. 25 years, 9 months

Karl M. Hegbloom

I have just verified that the "image display problem" patch submitted by Kazuo Oishi <oishi(a)ae.agr.yamaguchi-u.ac.jp> fixes the striped images that I reported when XEmacs is projecting to my 24bpp laptop display panel. Thank you, Kazuo! Awwww... isn't that penguin cute? :-)

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