May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Compile failure in frame-x.c 26 years, 6 months

Oliver Graf

"Kevin Oberman" <oberman(a)es.net> writes: > Compilation of beta 39 failed for frame-x.c on Digital UNIX V4.0C on a > 500au personal workstation running X11R6 with Motif, CDE. Pure b39 will not compile with CDE. Try b40-pre4 from the testing path. This one should... Regards, Oliver.

1 participants
0 comments

Re: NEWS update 26 years, 6 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > The Great Erik Naggum sayeth: > | Lambda lets you generate anonymous functions. You use it when you don't > | need/want to give a name to function, so why the "very sparingly"? > > oh, my advice here was limited to Emacs Lisp. since the Emacs Lisp byte > code object doesn't identity itself (I have tried to make it do that, so > error messages would be a little easier on the programmer and user), it > is much more convenient with named functions. It would probably be doable with XEmacs and its compiled-function objects, but Erik is too self-contained to look at XEmacs without ranting. I can't try to duplicate his work because he didn't specify what he meant by "byte code object identifying itself". > also, using anonymous functions in hooks is a bad idea since they > are hard to remove. binding a key to an anonymous (and > interactive) function is equally a bad idea. > > IMHO, it does make sense. It does, but in the specific NEWS example it looks better to use the anonymous function than to cons up a new function only for that purpose. In fact, the best thing would be if a `gdb-highlight-mode' existed as a minor mode, so we could simply autoload `add-minor-mode'. However, I don't feel like changing Jamie's code right now. I don't want to die young. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Thou Who might be our Father Who perhaps may be in Heaven... -- Roger Zelazny

2 participants
1 comments

[BUG] (widget-apply push-button :activate) 26 years, 6 months

Adrian Aichner

Hello Hrvoje, I reported this bug some betas ago. Following example works fine under NT Emacs 20.2.1 under Windows NT. Please load the attached file and then run widget-example via xemacs -q -no-site-file -l ~/el/we.el -f widget-example After you toggle the two push-buttons at he bottom to inactive and back to active they remain to be rendered inactive. Per pointed me your way, since this work works fine in the latest GNU Emacs. Regards, Adrian -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Straße 2 Fax +49/89/41861-217 D-81673 MÜNCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

Re: enable-clash-detection 26 years, 6 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Clash detection is an incredible fucking drag in an environment such > > as the one here. (...) It's really hard to explain to the spoiled > > bastard that has a 4 CPU ultra that he has to wait for an NFS server > > to listen to him before he can to a find-file on a local disk path! > > > > Sorry, but I feel pretty strongly about this one. > > OK, what you say makes sense. I say we keep it disabled by default, > and roll Jan's patch into 21.1. Please guys, could you read the patch again. The new clash detection does NOT use a global locking directory. It makes a symlink in the same directory as the file is. Jan

2 participants
1 comments

Compile failure in frame-x.c 26 years, 6 months

Kevin Oberman

Compilation of beta 39 failed for frame-x.c on Digital UNIX V4.0C on a 500au personal workstation running X11R6 with Motif, CDE. I tried compiling with both cc and gcc and got similar results. I have made no attempt to find the problem at this time but will do so if time permits. Here is the error printout from gcc 2.7.2.3: > gcc -c -O2 -g -Demacs -I. -DHAVE_CONFIG_H -I/usr/local/include -D_BSD -I/usr/dt/include frame-x.c frame-x.c: In function `x_cde_transfer_callback': frame-x.c:1110: parse error before `*' frame-x.c:1113: `transferInfo' undeclared (first use this function) frame-x.c:1113: (Each undeclared identifier is reported only once frame-x.c:1113: for each function it appears in.) And here is the result from cc: > cc -c -O2 -Demacs -I. -DHAVE_CONFIG_H -I/usr/local/include -D_BSD -I/usr/dt/include frame-x.c cc: Warning: frame-x.c, line 2574: # not in column 1 is ignored, skipping to end of line. #ifdef HAVE_TOOLBARS --^ cc: Warning: frame-x.c, line 2580: # not in column 1 is ignored, skipping to end of line. #endif /* HAVE_TOOLBARS */ --^ cc: Error: frame-x.c, line 1110: In this statement, "DtDndTransferCallbackStruct" is declared as a typedef, and so may not occur as an expression. DtDndTransferCallbackStruct *transferInfo = --^ cc: Error: frame-x.c, line 1110: In this statement, "transferInfo" is not declared. DtDndTransferCallbackStruct *transferInfo = -------------------------------^ cc: Warning: frame-x.c, line 1128: In this statement, the referenced type of the pointer value "hurl" is "signed char", which is not compatible with "const unsigned char". l_data = Fcons ( make_string (hurl, strlen (hurl)), l_data ); ---------------------------^ cc: Warning: frame-x.c, line 1147: In this statement, the referenced type of the pointer value ""text/plain"" is "signed char", which is not compatible with "const unsigned char". l_data = Fcons ( list3 ( make_string ("text/plain", 10), -----------------------------------^ cc: Warning: frame-x.c, line 1148: In this statement, the referenced type of the pointer value ""8bit"" is "signed char", which is not compatible with "const unsigned char". make_string ("8bit", 4), -----------------------------------^ (I am new to this list and, if this has been reported, sorry for wasting your time.) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

1 participants
0 comments

Re: NEWS update 26 years, 6 months

SL Baur

In case anyone is still not clear on why quoting lambda expressions is a good thing, consider the following snippet of code: (add-hook 'foo-hook (lambda () (let ((i 1)) (setq foo-map (make-sparse-keymap)) (while (< i 4) (define-key foo-map (intern (format "button-%d" i)) nil) (incf i))))) (add-hook 'foo1-hook '(lambda () (let ((i 1)) (setq foo-map (make-sparse-keymap)) (while (< i 4) (define-key foo-map (intern (format "button-%d" i)) nil) (incf i))))) After bytecoompiling and loading do: foo-hook => (#<compiled-function nil "...(43)" [1 i make-sparse-keymap foo-map 4 define-key intern format "button-%d" nil] 7>) foo1-hook => ((lambda nil (let ((i 1)) (setq foo-map (make-sparse-keymap)) (while (< i 4) (define-key foo-map (intern (format "button-%d" i)) nil) (incf i))))) Note that quoting lambda prevents the bytecompiler from bytecompiling it. Hrvoje Niksic <hniksic(a)srce.hr> writes: >> The Great Erik Naggum sayeth: >> oh, my advice here was limited to Emacs Lisp. since the Emacs Lisp byte >> code object doesn't identity itself (I have tried to make it do that, so >> error messages would be a little easier on the programmer and user), it >> is much more convenient with named functions. > It would probably be doable with XEmacs and its compiled-function > objects, but Erik is too self-contained to look at XEmacs without > ranting. > I can't try to duplicate his work because he didn't specify what he > meant by "byte code object identifying itself". I'm not sure either, but I know that it is inconvenient attempting to identify where an error came from in a bytecompiled lambda expression on a hook. >> also, using anonymous functions in hooks is a bad idea since they >> are hard to remove. binding a key to an anonymous (and >> interactive) function is equally a bad idea. One point being you can't just evaluate the hook variable in *scratch*, modify something and reevalute it -- it'll puke on the un(lisp)readable bytecode object. > It does, but in the specific NEWS example it looks better to use the > anonymous function than to cons up a new function only for that > purpose. Yup. Just what is gdb-highlight doing in NEWS anyway? Or do I want to know?

1 participants
0 comments

Re: enable-clash-detection 26 years, 6 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I later saw your other message indicating that. However in that > light it what he said does NOT make sense. With the new method a > remote NFS server is never involved in find-file'ing on local > disks[1]. Yup, and that is good. The only reason I ask that the patch be postponed for 21.1 is that the change involved is fairly large. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Union break!

1 participants
0 comments

Re: [Doc-bug] zap-to-char - including or up-to? 26 years, 6 months

Hrvoje Niksic

acs(a)acm.org writes: > Oops. I thought this discussion started because someone pointed out the > documentation of zap-to-char indicated that the deletion was up to but not > including the character. OK, I see the confusion. Yes, the documentation was wrong, but not the docstring -- it was the info documentation. And yes, it has been fixed now. It is good to see that our volunteers care about fixing the Info documentation. Christian, thanks for providing the fix. > All I was trying to say is that if there is a disagreement between > the code and the documentation, in this case we should fix the > documentation. Yup, I agree, and this has been done. Note that a second function (`M-x zap-up-to-char') has been added, but it is *not* bound to a key by default. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Personifiers Unite! You have nothing to lose but Mr. Dignity!

1 participants
0 comments

Re: enable-clash-detection 26 years, 6 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > > Clash detection is an incredible fucking drag in an environment such > > > > as the one here. (...) It's really hard to explain to the spoiled > > > > bastard that has a 4 CPU ultra that he has to wait for an NFS server > > > > to listen to him before he can to a find-file on a local disk path! > > > > > > OK, what you say makes sense. I say we keep it disabled by default, > > > and roll Jan's patch into 21.1. > > > > Please guys, could you read the patch again. The new clash detection > > does NOT use a global locking directory. > > I know that. What makes you think I don't? I later saw your other message indicating that. However in that light it what he said does NOT make sense. With the new method a remote NFS server is never involved in find-file'ing on local disks[1]. Jan

1 participants
0 comments

Re: [Doc-bug] zap-to-char - including or up-to? 26 years, 6 months

Hrvoje Niksic

acs(a)acm.org writes: > Personally, I think the documentation for zap-to-char should be > changed, Why, and to what? > and the definition and binding of zap-to-char be left alone. I agree. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymour Cray, on virtual memory

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