August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: ... > I got: > $ make CFLAGS="-mpentium -march=pentium -O6 -fno-risc -fno-peep-spills" check > ... > This test should produce no other output than this line, and a final "OK". > FAIL: devcom3-7 > make[1]: *** [check] Error 1 > ... This was a zsh (as /bin/sh) bug[1]. For the record, 1.10 passes all regression tests at full optimization. Footnotes: [1] bash% cat <<EOF Enew line here G＠#$^!＠#=& EOF Enew line here G＠#$^!＠#=& bash% zsh% cat <<EOF Enew line here G＠#$^!＠#=& EOF Enew line here G＠#0＠#=& zsh%

1 participants
0 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Holger Schauer

>>>>"MS" == Michael Sperber schrieb am 18 Aug 1998 14:52:08 +0200: [Common Lisp and Elisp] MS> (defvar bar 23) MS> (defmacro foo () 'bar) MS> (let ((bar 42)) (foo)) => 42 (foo) => 23 Holger> Excuse me, but this is evil by design. MS> Absolutely right, Common Lisp's macro system is evil by design. MS> I just want macros to obey the same scoping rules as the rest of MS> the language, and they don't in Common Lisp. Interesting. Seems I don't understand what you want to say. (defvar bar 23) (defun foo () bar) (let ((bar 42)) (foo)) => 42 (foo) => 23 Where is the difference ? MS> In Scheme, MS> (define bar 23) MS> (define-syntax foo MS> (syntax-rules () ((foo) bar))) MS> (let ((bar 42)) (foo)) => 23 Holger> Brr, what awful code. MS> No, it isn't. There are many perfectly valid reasons for a macro MS> to refer to an outer binding within the same lexical scope. What are those reasons ? Why not use a different name in let ? You also have to when you use functions. This would introduce a non-intuitive difference between the use of macros and those of functions, if I understand you correctly. And you seem to find some benefit in it: which is it ? [1] Holger Footnotes: [1] This is a serious question, I'm not trying to suggest that there isn't a benefit. -- --- http://www.coling.uni-freiburg.de/~schauer --- "Keine Shell, kein Prompt, keine Kekse." -- Jochen Hein in de.comp.os.linux.misc

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 3 months

Hrvoje Niksic

"Michael Harnois" <mharnois(a)sbt.net> writes: > >Not with finding as much as with prices. The "computer books" are > >usually pretty expensive hard-cover editions that cost 200-400K > >(divide with 6 to get a price in dollars), which is very expensive > >given the salaries here. > > Geez, I'd thought about the trials you'd face in getting the > hardware we consider current, The hardware is not necessarily expensive for me, because I work at computers. Once I graduate, I will likely be able to afford the "current" hardware. > So can I get a $30 O'Reilly book on some interesting topic, put it > in a box, and send it to you, or does that come with its own set of > problems? It doesn't, but I don't think it's really necessary, unless you already to own a book you no longer need, or something like that. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth

1 participants
0 comments

Re: lexical-let (was: Re: Faster lisp engine) 26 years, 3 months

Hrvoje Niksic

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > Perhaps for you, but is it acceptable to Gnus author, and to Gnus > > users? > > That's their problem. I wouldn't hesitate using it in my code. If > the users are unhappy with the speed, they can upgrade. First, they can't -- that's the whole point. The "C-based" lexical let will only be available in the future. Second, I would consider it rude to tell an enthusiast FSF Emacs user to "upgrade" to XEmacs. Perhaps he does not want to use XEmacs for other reasons. > > Your guess is as good as anyone's. I agree with Glynn and others in > > the opinion that most of the temporary variable bindings are in fact > > established by function calls. > > But I don't care about *most* of the code, only the few places in the > code where the user tends to wait on Emacs, instead of Emacs waiting > on the user. It is very questionable whether these places would be made faster by the sole introduction of `lexical-let'. But, as I said, your guess is just as good as mine. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "A Real Programmer's code can awe with its fiendish brilliance, even as its crockishness appalls."

1 participants
0 comments

Re: lexical-let (was: Re: Faster lisp engine) 26 years, 3 months

Hrvoje Niksic

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > I think `lexical-let' actually makes the code *slower* for older > > Emacsen, where all the current (X)Emacsen count as "old". > > Yes. That's an acceptable (to me) trade-off. Perhaps for you, but is it acceptable to Gnus author, and to Gnus users? > > I don't think the lexical-let proposal wins much speed, really. > > I'm not qualified to judge that. Your guess is as good as anyone's. I agree with Glynn and others in the opinion that most of the temporary variable bindings are in fact established by function calls. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- `VI' - An editor used by those heretics that don't subscribe to the Emacs religion.

2 participants
1 comments

[Success] 21.0 Danish Landrace on Solaris 2.6 / SunPro cc 26 years, 3 months

N J Doye

Running fine for 6 days so far. I don't use CDE, so I've no idea about the drag'n'drop stuff. Not sure what the --with-pop option is supposed to do, so I didn't use it. However, I use POP to get my mail for VM. ________________________________________________________________________ uname -a: SunOS gristle 5.6 Generic sun4m sparc SUNW,SPARCstation-5 ./configure '--extra-verbose' '--debug' '--compiler=cc' '--dynamic' '--gung-ho' '--site-prefixes=/usr/local' '--prefix=/opt/SUNWspro/contrib/XEmacs' XEmacs 21.0 "Danish Landrace" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /export/home/ccsnjd/src/xemacs/xemacs-21.0-b52 What installation prefix should install use? /opt/SUNWspro/contrib/XEmacs What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? cc -v -xO4 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/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Additional prefixes: /usr/local Runtime library search path: /usr/local/lib:/usr/dt/lib:/usr/openwin/lib:/opt/SUNWdt/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 native sound support. Compiling in support for GNU DBM. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage.

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 3 months

Michael Harnois

>Not with finding as much as with prices. The "computer books" are >usually pretty expensive hard-cover editions that cost 200-400K >(divide with 6 to get a price in dollars), which is very expensive >given the salaries here. Geez, I'd thought about the trials you'd face in getting the hardware we consider current, but I'd never thought about books. So can I get a $30 O'Reilly book on some interesting topic, put it in a box, and send it to you, or does that come with its own set of problems?

1 participants
0 comments

[success] linux + SUMO tarball 26 years, 3 months

Neal D. Becker

Installed using latest SUMO tarball. No major problems so far. egcs-1.0.3 glibc-2.0.7(RH5.1) uname -a: Linux nbeckerpc.hns.com 2.1.115 #2 Fri Aug 7 08:26:15 EDT 1998 i686 unknown ./configure '--gung-ho' '--verbose' XEmacs 21.0 "Danish Landrace" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21.0-b52 What installation prefix should install use? /usr/local 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 -g -O3 -Wall -Wno-switch 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? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for X-Face message headers. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation.

1 participants
0 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Michael Sperber

>>>>> "Holger" == Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: >>>>> "MS" == Michael Sperber schrieb am 18 Aug 1998 11:08:25 +0200: MS> Sure, but there's no guarantee that a given macro has hygienic MS> behavior. Generally, maintaining hygiene this way is pretty MS> tedious, which is why programmers usually don't go to the MS> necessary lengths. Holger> I will make a risky statement: a powerful tool should be used Holger> carefully. What you say is certainly true, but - as Paul Graham makes Holger> clear - macros are a way to fool with the way lisp evaluates your Holger> statements. To me, this is like a big red sign yelling: "Careful". Yeah, just like there was been a big red sign saying "use the keymap abstractions when you deal with keymap instead of treating them like ordinary sequences." This is certainly a fashionable attitude in the textual-macro camp. I would agree more if there wasn't a superior alternative. Holger> I believe that even in the Elisp programming style tips people Holger> are advised not to use macros if they can be avoided. One Holger> example that has bitten me much to often was the useless use Holger> of macros in mailcrypt or in some VM file, IIRC, which broke Holger> whenever I installed a new VM version. Therewas absolutely no Holger> reason to use macros in that places. Your example below is of Holger> the same class: It's an *example*. Of course, there's no *need* to use a macro, because there's no need for the code in the first place. What's your point? MS> (defvar bar 23) MS> and I want to refer to bar (that is, the above binding) in a MS> macro body: MS> (defmacro foo () 'bar) MS> ... but I do: MS> (let ((bar 42)) (foo)) => 42 Holger> Excuse me, but this is evil by design. Absolutely right, Common Lisp's macro system is evil by design. In Scheme, (define bar 23) (define-syntax foo (syntax-rules () ((foo) bar))) (let ((bar 42)) (foo)) => 23 Holger> Brr, what awful code. No, it isn't. There are many perfectly valid reasons for a macro to refer to an outer binding within the same lexical scope. I just want macros to obey the same scoping rules as the rest of the language, and they don't in Common Lisp. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Holger Schauer

>>>>"MS" == Michael Sperber schrieb am 18 Aug 1998 11:08:25 +0200: MS> Sure, but there's no guarantee that a given macro has hygienic MS> behavior. Generally, maintaining hygiene this way is pretty MS> tedious, which is why programmers usually don't go to the MS> necessary lengths. I will make a risky statement: a powerful tool should be used carefully. What you say is certainly true, but - as Paul Graham makes clear - macros are a way to fool with the way lisp evaluates your statements. To me, this is like a big red sign yelling: "Careful". I believe that even in the Elisp programming style tips people are advised not to use macros if they can be avoided. One example that has bitten me much to often was the useless use of macros in mailcrypt or in some VM file, IIRC, which broke whenever I installed a new VM version. Therewas absolutely no reason to use macros in that places. Your example below is of the same class: MS> (defvar bar 23) MS> and I want to refer to bar (that is, the above binding) in a MS> macro body: MS> (defmacro foo () 'bar) MS> ... but I do: MS> (let ((bar 42)) (foo)) => 42 Excuse me, but this is evil by design. Brr, what awful code. Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- "Was für'n Agent??? Und wieso benutzt ihr nicht einfach alle die Standardlösung Outlook Express (früher MS News)? Ist IMHO das beste und übersichtlichste Programm für PC und dazu noch kostenlos!" -- Aus "Wie starte ich einen Endlosthread ?", Teil 1239

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 August 1998