July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

call-with-current-continuation tutorial 26 years, 12 months

Michael Sperber

I've placed a tutorial on call-with-current-continuation for Elisp hackers on http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-gener... Let me know if it helps to clarify things. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: [Bug] XEmacs-21.0-b47/pre4; Popup menu at buttom/right 26 years, 12 months

Christoph Wedler

KJ> Do you use virtual desktops? If so, do you see this beahvior on KJ> all the desktops? Thanks for the answer! Desktops = workspace? I see the behavior on all workspaces. But, when starting XEmacs-21.0 under the login of my colleague, I don't see the behavior! Do you have any idea which parts in my .Xdefaults or .ctwmrc could be the reason? - Christoph

2 participants
1 comments

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

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Andy Piper <andyp(a)parallax.co.uk> writes: > > > At 09:07 15/07/98 -0400, you wrote: > >> Speaking of file-coding, is there a reason the option is not listed by > >> ./configure --help? > > No. Undoubtedly that's an oversight. > > >> Is there any reason not to use it for a non-mule build? > > No one has investigated the performance implications. Also, noone has investigated the usage problems. I, for once, don't like the `noconv' stuff in the modeline. Likewise, I don't *want* CRLF to be "autodetected" behind my back (at least not without some thought). Etc etc. Let's remember that file-coding emerged as an integral part of the Mule functionality, which is still a matter of some controversy. > > There have been reports of crashes that I have never been able to > > reproduce and which I suspect are triggered by file-coding and not > > caused by it. > > I can't parse this statement. Let me try to pretty-print a parsed version: There have been reports of crashes triggered by compiling in the file-coding support, but not caused by file-coding-specific parts of code. I [Andy] have never been able to reproduce these crashes. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Your lucky number today is 29842924728. Look for it everywhere.

1 participants
0 comments

Packages-Info ... 26 years, 12 months

Holger Schauer

Hi ! Okay, folks. I am not only complaining, I just started writing an PACKAGES-Introduction. The following is far from complete, I'm sure, so I need help. Lots and lots of help. If somebody likes to fill in the black holes, don't hesistate. Or even better: somebody with much more competence on this theme (Andy, Adrian ?) should take it, rip it apart and do it right. One more comment: Just as Steve does, I believe that with a SUMO-tarball alone, we will return to the "What can I delete"-FAQ, so a file like the one below is very necessary. Down below we go ... Holger # -*- Mode: text -*- As of Version 21.0, XEmacs no longer ships with one huge set of Emacs Lisp files. Instead most of these files are distributed separately in the form of so called packages, so that users and system administrators can choose which packages they need. This file explains how packages work in XEmacs 21.0. * 1. Getting Started ==================== When you first grab (i.e. ftp) XEmacs 21.0, you will usually ftp the file xemacs-21.0.tar.gz (currently xemacs-21.0-b46.tar.gz). Unzipping and untarring this file will leave you with the sources and a minimal set of Emacs Lisp files, which are in the subdirectory named 'lisp'. This subdirectory used to contain all Emacs Lisp files distributed with XEmacs. In the 'etc' subdirectory you can find a list of all available packages in the file 'PACKAGES'. *2. Choosing the Packages You Need ================================== The available packages can currently be found in the same ftp directory where you grabbed the 21.0 sources from, from the subdirectory 'binary_packages'. Package file names follow the naming convention '<package-name>-<version>-pkg.tar.gz'. Now, check the above mentioned file 'PACKAGES' to see which packages you want. You will probably always want to install the 'xemacs-base' -package. Here is an overview which packages should be dumped [1] with XEmacs and thus need to be installed before compiling XEmacs, if you like to use them. <please fill out this section !> <I think we also need a list of suggestions for people that want to do several stuff with XEmacs, like reading/sending mail, programming, W3 surfing, etc. You get the idea. Yes, I know of etc/PACKAGES but that contains no suggestions.> Hint to system administrators of multi-user systems: it might be a good idea to install all packages and not to interfer with the wishes of your users. *3. Directories =============== When installing XEmacs, it will be installed in a certain place, usually underneath a directory, here commonly refered to as $(prefix) [2]. Usually, XEmacs will be installed under $(prefix), with the XEmacs binary in $(prefix)/bin and the "rest" under $(prefix)/xemacs-<version>. This includes the etc/, info/ and lisp/-subdirectories as well as the directory for architecture-specific binaries. Thus, a typical installation (as performed by `make install') looks like: $(prefix)/bin \ $(prefix)/lib/xemacs-<version>/etc | $(prefix)/lib/xemacs-<version>/info - Core 21.0 distribution $(prefix)/lib/xemacs-<version>/lisp | $(prefix)/lib/xemacs-<version>/<architecture> / The "normal" intended way where packages should go is in a directory _beneath_ 'xemacs-<version>', for instance to 'xemacs'. For a XEmacs with MULE [3] you will need a 'mule-packages' subdirectory and a 'xemacs-packages' directory for all common packages. Thus, for the packages you should have the following directory-structure: $(prefix)/lib/xemacs/xemacs-packages/lisp zvf $(prefix)/lib/xemacs/xemacs-packages/etc $(prefix)/lib/xemacs/mule-packages *4. Installing packages and XEmacs ================================== For installing packages, you will now need to unzip and untar all packages you want to install. After that, you are done for the moment with the package stuff and can proceed to compiling and installing XEmacs. When configuring XEmacs, specify the package-path you are using, i.e., configure with, say ./configure <other-configure-options> --package-path=<PACKAGE-DIRECTORY> If you don't specify --package-path a default of $(prefix)/lib/xemacs/xemacs-packages will be used. *5. Using Packages from Emacs Lisp ================================== Aehh, HELP, I do know nothing yet ... *X. Final Notes =============== This should be all you need. Footnotes: [1] If you don't know what dumping is, please refer to the file etc/INSTALL. [2] This notion stems from the makefile used to build XEmacs, and is set with configure by using the option --with-prefix=<DIRNAME>. [3] If you don't know what MULE is, please refer to the file etc/MULE.

2 participants
1 comments

Re: scheme - my opinion 26 years, 12 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> Multiple extension languages sounds like big > Hrvoje> trouble. > > What do you think "elisp:foo-n", n goes from 1 to 1000, is, if all the > foo-n are defined in base Common Lisp too, but differently? I believe multiple extension languages are a wholly different kind of trouble. One I am too scared to even contemplate! *shiver* > Obviously, I think that that is the same problem as multiple > extension languages, of perhaps somewhat lesser degree. I take it > you think it is not a problem (most likely because you believe n is > small)? I'd call n "reasonably small," if Erik's packages scheme can be made to work. I am not yet 100% convinced that it can work flawlessly, but we'll see. Common Lisp reader is very flexible. > If we make "old ELisp" available as an option, who's going to police > the contributors who continue to use it? The whole point is for the contributors to be able to keep using it -- for compatibility, if nothing else. > And there are some people who find the prospect exciting. Undoubtedly. There are people who find the prospect of Perl-in-Emacs exciting. > Bruno does not seem to be an expert on XEmacs internals. And he has > committed to extensions needed by XEmacs, not to implementation > changes needed by XEmacs. Can you assert that there are none of the > latter? Will Bruno go so far as to change internals of CLisp to fit > XEmacs needs? I don't know. Hopefully, he will. You would have to ask Bruno this question. > Hrvoje> If enough work is done on ensuring it is, I don't see why > Hrvoje> [CLisp] wouldn't be a good choice [as a substrate for > Hrvoje> XEmacs]. > > "Enough work" can be one hell of a lot of work. Yup. > Hrvoje> Define "confidence." > > The _definition_ of confidence is a written proposal with a schedule > (cf. Fred Brooks, Ed Yourdon, Watts Humphrey, ad nauseum). Wow. Then I'm surely not confident. :-) That's not how Webster defines the word, but hey -- not that I will argue English semantics with a native speaker! > I have no thought of _asking_ anyone for that. But one of the > attractions of Scheme for me is that Michael is already moving in > the direction of a written proposal, Yeah, I notice that. More to the point, Michael gets more credit because he is prepared to do the actual work, rather than only argue about it. That's a great point pro Michael, but means nothing in terms of general CL-vs.-Scheme arguments. > That gives me some confidence that a Scheme implementation will > happen, with few defects, in a timely fashion, with its necessary > documentation, if it gets a green light. Yes, but I fear that the implementation will be buggy, that the elisp emulation will be inadequate, and that we'll wind up with n00 users, the rest of the folks happily using XEmacs 21.x. But I fear the same in a CL-based XEmacs 2x, so the above was a digression. > Hrvoje> Because otherwise the whole thing would make no sense. > Hrvoje> If this goal cannot be met with clisp, then clisp is not > Hrvoje> the right choice. > > So tell us how we're going to meet the goal. I don't doubt your > desire or willingness to work and to help coordinate with the CLisp > project. You'd better doubt my willingness to do that! I don't have a sufficient amount of time to devote to that, nor do I have the necessary knowledge; I thought I have made this clear. My past contributions to XEmacs were more or less elaborate hacks and, when I'm in a good mood, bugfixes. Porting XEmacs to clisp is clearly outside my scope. I argue for clisp and against Scheme 48 because I feel I would prefer using (in the sense of "enhancing") the finished product. > You're the obvious candidate that participants in this discussion > will look to for managing the clean up if anything does go wrong > with a CL engine, don't you think? I don't think that at all. Noone has expressed their wishes to do a substantial amount of work on this, except for Michael. Following your line of thought, we are more or less stuck with his choice of extension/implementation language because he will do the work. > rm -rf xemacs-22; cvs co -rr21_release xemacs > > Sure, this is pessimistic. But such disasters happen, and we need > to be prepared for the possibility, and to have a plan to avoid it. Yup. But unlike you, I consider it just as likely with Scheme as with Common Lisp. > Hrvoje> There is no way I can compete with Michael. > > You don't have to. Oh yes I do! See above. > Not even to get me to agree that CL is the way to go. But Michael's > expertise _is_ an advantage for Scheme. It would be nice if you > could find someone to play the same role for CL. I cannot. I am certainly not the person you want me to find. Thanks, but no, thanks. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Do not meddle in the affairs of troff, for it is subtle and quick to anger.

1 participants
0 comments

Vacation 26 years, 12 months

Hrvoje Niksic

Quite unexpectedly, I'll be leaving tomorrow (or the day after) to a Place Without Email (but with sunny coast!:-), and will stay there for three weeks. Feel free to send mails to me, but don't expect me to read them until August 10th or so. I'll be subscribed to xemacs-beta during the vacation. Enjoy! -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Then... his face does a complete change of expression. It goes from a "Vengeance is mine" expression, to a "What the fuck" blank look.

1 participants
0 comments

Re: post forward broken in gnus 26 years, 12 months

Hrvoje Niksic

Andy Piper <andyp(a)parallax.co.uk> writes: > Select post forward and I get a void funciton defn for: > > gnus-summary-post-forward For best results, you should mail your bug report to <bugs(a)gnus.org>, preferably via `C-c C-b'. Gnus is (very) actively maintained. -- 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

1 participants
0 comments

Re: Obsolescence -- I like `eval-current-buffer' 26 years, 12 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > `window-system' is a special case. True, it has different and wrong > semantics. It is not obsolete in the sense that we have no plans on > removing it in the future We don't? Why not? It's evil! -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- By any chance, have you seen a summoned 9th order fire elemental wandering around? No? Oh.. Tell me if you do.

1 participants
0 comments

Re: scheme - my opinion 26 years, 12 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Eg, who really understands Mule? Hrvoje doesn't claim to AFAIK---but > he knows how to write code around it, and even wrote the tutorial for > that. You misunderstood Martin. He meant that he doesn't understand the *usage* pattern (interface) of call/cc, not its implementation. As you say, I don't understand the mule-*.c files, but I've taken care to study the MULE interface by looking at Ben's code, and I found it easy to understand and follow. This is not the case with Martin and call/cc -- he finds he cannot understand call/cc, and I'm not sure I can blame him for it. > The questions are "How useful might call/cc be? call/cc is obviously useful to Scheme hackers, so if we choose Scheme for an extension language, we'll get people who will know how to use it for their purposes. However, I doubt that call/cc will in itself be a good enough reason to choose Scheme over something else. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- HOW YOU CAN TELL THAT IT'S GOING TO BE A ROTTEN DAY: #15 Your pet rock snaps at you.

1 participants
0 comments

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

Raymond Toy

>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "Ray" == Raymond Toy <toy(a)rtp.ericsson.se> writes: >>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: Michael> There is only one context where this is true: When you try to emulate Michael> tail recursion *in C procedure calls* via a trampoline. Optimizing Michael> Scheme-to-C compilers get around this in most cases, however. Let me Michael> again mention that Scheme compilers are among the best-optimizing Michael> compilers for higher-level languages, and often achieve code Michael> performance comparable to C. Which compilers do this? I know Stalin is very good, but it compiles to C as does gambit, so these must have the performance hit. 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? Michael> I don't even understand the question. Tail calls don't use stack I meant if it wasn't tail-recursive. I understand the desire and need for tail-recursive algorithms, and I think we should strive to have it. Ray

1 participants
0 comments

2025

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