July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Why do we keep mule-coding.c around ? 26 years, 2 months

Greg Klanderman

Speaking of file-coding, is there a reason the option is not listed by ./configure --help? Is there any reason not to use it for a non-mule build? greg >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> sb> Olivier Galibert <galibert(a)pobox.com> writes: >> 'cept for the pleasure to see >> "mule-coding.c", line 4808: warning: empty translation unit sb> >> of course. sb> sb> It looks deletable to me. The final decision ought to be O.K.'ed by sb> Andy Piper since he was the one who moved the code into file-coding.c. sb>

2 participants
1 comments

post forward broken in gnus 26 years, 2 months

Andy Piper

Select post forward and I get a void funciton defn for: gnus-summary-post-forward andy --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Build Success on UnixWare 2.1.2 26 years, 2 months

Vin Shelton

Everything looks OK so far. I built with nearly all the packages. This was my first 21.0 build. uname -a: UNIX_SV mithril 4.2MP 2.1.2 i386 x86at ../configure '--with-gcc' '--prefix=/usr/local/xemacs-21.0' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' '--with-gnu-make' '--infopath=/usr/local/info' '--with-mule=no' '--cflags=-O3 -finline-functions -fomit-frame-pointer -ffast-math' '--x-includes=/usr/X11R6/include' '--x-libraries=/usr/X11R6/lib' '--with-dialogs=no' '--with-site-lisp' XEmacs 21.0 "Zhong Wei" configured for `i386-univel-sysv4.2MP'. Where should the build process find the source code? /syjet/src/xemacs-21.0-b48 What installation prefix should install use? /usr/local/xemacs-21.0 What operating system and machine description files should XEmacs use? `s/usg5-4-2.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O3 -finline-functions -fomit-frame-pointer -ffast-math 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/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in support for Berkeley DB. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. vin

1 participants
0 comments

Re: scheme - my opinion 26 years, 2 months

tma＠nettest.dk

Hrvoje Niksic <hniksic(a)srce.hr> writes: > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > > >> >> 2. What constructs in one dialect would be difficult or > > >> >> impossible to implement efficiently in the other? > > > > Hrvoje> Why is this an issue? I don't *want* to implement Scheme > > Hrvoje> in CL, nor do I want to implement CL in Scheme. > > > > >> Some people _are_ thinking in those terms. So it's an issue. > > >> Closed, from your standpoint. Still open, from mine. > > > > Hrvoje> Can you name some of these people? What exactly do they > > Hrvoje> want to achieve by implementing CL in Scheme, or vice > > Hrvoje> versa? > > > > (1) Michael Sperber. > > I've never read his messages that way, except in theoretical terms > ("CL *can* be implemented in Scheme.") Do you know something that I > don't? > > > (2) Keeping CL proponents happy if the engine turns out to be > > Scheme, among other things. > > I don't think Scheme will ever satisfy CL proponents. Indead it will! Me for one. I was the one that started on a CLOS-like object implementation in XEmacs two years back. The major reason for stopping that work was the number of changes that was necessary to complete the project (the initial and very limited patch for xemacs-20.3 came to 400Kb). >From what I know today, I would much prefer to have scheme as my base language, and then use CL constructs where appropriate. More or less like to today with cl.el. When it come to call/cc, it is just a matter of "getting used to" the new syntax and semantics. Given the code I have seen from most if not all of the participants of these language threads, everybody here should be able to learn call/cc and its uses in a number of days or weeks. /tonny

1 participants
0 comments

Re: Promises, promises -- read-time macro removal from core 26 years, 2 months

SL Baur

Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>>> "Olivier" == Olivier Galibert <galibert(a)pobox.com> writes: ... Olivier> Just learning, what was wrong with these macros that the Olivier> change solves? Was the problem technical or philosophical? > Philosophical. > These macros encourage feature-specific compilation. This means, > among other things, that the same .el file might produce different > .elc files on different architectures without so much as a warning, > which is bad juju especially for things like binary packages. Yup. > Using them is almost always a bad idea, but unfortunately really, > really easy. Yup. *Real* easy and real dangerous. > The replacement macros are not as general, so their use will hopefully > be confined to what it is now. The usage in XEmacs wasn't so bad as the macros were used safely, but they set a horrible example we could come to regret for a long time to come. I was the driving force behind behind introducing this into XEmacs in the first place. I have since repented.

1 participants
0 comments

Re: Promises, promises -- read-time macro removal from core 26 years, 2 months

Michael Sperber

>>>>> "Olivier" == Olivier Galibert <galibert(a)pobox.com> writes: Olivier> On Wed, Jul 15, 1998 at 12:18:23AM -0700, SL Baur wrote: >> I promised that usage of Lisp reader read-time macros (#-, #+) >> wouldn't be used in core XEmacs code in 21.0 and Chipsy sent me >> replacement macros at my request (months ago, sigh) that work when >> bytecompiled. Olivier> Just learning, what was wrong with these macros that the change Olivier> solves? Was the problem technical or philosophical? Philosophical. These macros encourage feature-specific compilation. This means, among other things, that the same .el file might produce different .elc files on different architectures without so much as a warning, which is bad juju especially for things like binary packages. Using them is almost always a bad idea, but unfortunately really, really easy. The replacement macros are not as general, so their use will hopefully be confined to what it is now. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: scheme - my opinion 26 years, 2 months

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: ... > I've read them. Many two or three times. They don't answer my > questions (possibly because of my own ignorance). Perry's comments on > use of exceptions and objects in large software projects ring true, > but those advantages will be part of Michael's "long slow migration" To give some idea about how long a "long slow migration" can be, there was full "C" mocklisp (either the predecessor of Emacs Lisp or something else pre Emacs 17) support in XEmacs until last year and token fragmentary Lisp support of mocklisp-isms is *still* around. My guess is that given any kind of compatibility, there will be Emacs Lisp around pretty much forever. If we started reimplementing today, maybe 5 years from now a majority of the code would be natively written in the new extension language, but I doubt it. This is going to be a long-term project. > (I may be overdoing that) to using the new native Lisp. As slow as > that's going to be, it could theoretically wait on improvements in the > Scheme modules: You're probably right on that. It could also theoretically wait on improvments in Freed CL implementations too.

2 participants
1 comments

Re: Promises, promises -- read-time macro removal from core 26 years, 2 months

Olivier Galibert

On Wed, Jul 15, 1998 at 12:18:23AM -0700, SL Baur wrote: > I promised that usage of Lisp reader read-time macros (#-, #+) > wouldn't be used in core XEmacs code in 21.0 and Chipsy sent me > replacement macros at my request (months ago, sigh) that work when > bytecompiled. Just learning, what was wrong with these macros that the change solves? Was the problem technical or philosophical? OG.

1 participants
0 comments

Why do we keep mule-coding.c around ? 26 years, 2 months

Olivier Galibert

'cept for the pleasure to see "mule-coding.c", line 4808: warning: empty translation unit of course. OG.

2 participants
1 comments

Re: Common Lisp vs. Scheme 26 years, 2 months

Michael Sperber

>>>>> "Ray" == Raymond Toy <toy(a)rtp.ericsson.se> writes: >>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: Glynn> We've been *surviving* without tail recursion optimisation. Glynn> Ultimately, tail recursion can always be converted to explicit Glynn> iteration, which is what you need to do in elisp if you don't want to Glynn> take a performance hit. Ray> Of course. I'm just curious how bad it really is. I assume that the Ray> performance hit is not the lack of tail-recursivion, but the Ray> exceedingly slow funcall's in elisp. It's not just performance. You also risk a stack overflow if you don't do it. Ray> Some discussions in comp.lang.lisp (or scheme?) mentioned that even Ray> though tail-recursion is equivalent to iteration, it still takes a Ray> toll on speed. 20% maybe or more? I don't remember the numbers from Ray> the tests that were done. There is only one context where this is true: When you try to emulate tail recursion *in C procedure calls* via a trampoline. Optimizing Scheme-to-C compilers get around this in most cases, however. Let me again mention that Scheme compilers are among the best-optimizing compilers for higher-level languages, and often achieve code performance comparable to C. Glynn> However, it's effectively a bug (IMHO) which we've had to work around. Glynn> It would be nice if algorithms which would naturally be implemented Glynn> using tail recursion could be written in their natural form. Ray> I guess my question is, if things were written recursively, how a big Ray> a stack would we use and would that be big enough to matter? I don't even understand the question. Tail calls don't use stack space in Scheme. Many Scheme implementations (notably RScheme and Scheme 48) are not even stack-based, but use a stack only as a cache, so its size only affects performance in a very minor way. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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