August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Macros: Scheme vs Common Lisp 27 years, 1 month

Craig Lanning

At 08:52 PM 8/27/98 -0400, Rick Campbell wrote: >Run Plugin:"c:\users\craig\mail\attach\Re Macros Scheme vs Common Li3.ems <0880.0002>" >Content-Type: text/plain; charset=US-ASCII > > Date: Thu, 27 Aug 1998 19:43:24 -0400 > From: Craig Lanning <CraigL(a)internetx.net> > > At 07:13 AM 8/27/98 -0400, Rick Campbell wrote: > > > > From: sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) > > Date: 26 Aug 1998 14:20:32 +0200 > > > > I suspect your CL actually processes the forms in some weird > > order. In any case, I strongly doubt that the CL standard > > mandates the behavior you describe. > > > >Common Lisp does not mandate much of anything regarding when expansion > >occurs. It's an implementation detail, i. e. you should not write > >code that depends on expansion happening at a certain time. > > That's not really true. All forms are processed in order from left to > right. Macros are expanded as they are reached. In compiled code, > macros are expanded at compile time in such a way as not be expanded > at runtime. > >I'm pretty sure that you're wrong about this. At the risk of being >hypocritical (I didn't cite spec), can you point to something in the >spec that dictates that in compiled code, macros *must* be expanded at >compile time. I believe an implementation is allowed to expand macros >at read time and then compile whatever's been previously expanded at >compile time, e. g. See HyperSpec section 3.2.2.2 "Minimal Compilation": All macro and symbol macro calls appearing in the source code being compiled are expanded at compile time in such a way that they will not be expanded again at run time. macrolet and symbol-macrolet are effectively replaced by forms corresponding to their bodies in which calls to macros are replaced by their expansions. >* (defmacro foo ...) >* (defun bar () ... (foo ...)) ; expand macro here >* (defmacro foo ...) ; inconsistent with first definition >* (compile 'bar) ; uses first definition of foo cuz it was already expanded > >At least, I've never seen spec saying the above is taboo and I believe >that I've seen discussion saying that it's allowed. The CL compilers that I have seen will issue a warning after the second definition of FOO saying that functions which used the old definition will not get the new definition. I thought I saw something in the HyperSpec last night, but I can't find it today. Craig Lanning E-Mail: CraigL(a)InternetX.net

1 participants
0 comments

Re: (cdr (cdr (car ls))) vs (cddar ls) 27 years, 1 month

Karl M. Hegbloom

>>>>> "Rick" == Rick Campbell <campbell(a)cyberpass.net> writes: Rick> If you have a PC running Linux or FreeBSD, a Sun, or an HP, Rick> you can get CMUCL which has a real compiler and avoids a lot Rick> of the problems that any system trying to piggy back on top Rick> of C will have. Yes, I have CMU-CL installed; there's a Debian GNU/Linux package of it now, and it's the one with the new gengc and mt. It is very fast. Hemlock works, but is very blah by comparison to XEmacs. I wonder how hard it would be to make Hemlock do everything that XEmacs does? :-) A *lot* of work by many people, no doubt. I would like to try and get Garnet to compile sometime... but not until after I've completed some other studies, so I'll be able to fix it if it's broken. The gesture support it's got sounds neat; kind of like what `strokes-mode' does in XEmacs. Rick> I've heard some good things about guile, but it's definitely Rick> more in the Scheme camp than the Common Lisp camp and I Rick> believe that it suffers from RMSism (as compared to scheme) Rick> in the same sorts of ways that FSF's version of GNU Emacs Rick> does (as compared to XEmacs). I'm working on some guile1.3 CVS snapshot Debian packages right now. I've begun to learn how libguile operates. I think it will help me understand XEmacs' internals; `guile' is certainly much simpler and probably easier to understand. You can get it via anon CVS now; check out their CVSROOT/modules file to see what's there. The guile hobbit compiler almost works now. It will compile simple functions and itself to C. I was also able to get the guile-unexec to work, and have packaged it. What is `RMSism'? I will also try and study Scheme48. I think it may be a better engineered product than `guile'... but cannot judge without a lot more study. It's implemented very differently; it looks like the bulk of the code is written in scheme, and compiled to C via the prescheme. I've only spent a total of about 2 hours looking at it, finding that I need to read a few books and theory papers first. Right now I'm part way through a book on garbage collection, and another book on threads... I should kill a few of my threads and concentrate my efforts and time on one project at a time for a while, I think. :-)

2 participants
1 comments

Re: (cdr (cdr (car ls))) vs (cddar ls) 27 years, 1 month

Raymond Toy

>>>>> "Karl" == Karl M Hegbloom <karlheg(a)inetarena.com> writes: Karl> I would like to try and get Garnet to compile sometime... but not Karl> until after I've completed some other studies, so I'll be able to fix Karl> it if it's broken. The gesture support it's got sounds neat; kind of Karl> like what `strokes-mode' does in XEmacs. Garnet compiles out of the box; no problems at all. Be sure to get the sources from the ports directory on www.cons.org. It's the latest with many fixes. Ray

1 participants
0 comments

Re: Should 'package-*' install into user dir and other questions? 27 years, 1 month

Jan Vroonhof

Darryl Okahata <darrylo(a)sr.hp.com> writes: > I'm still working on these. As the deadlines have passed, I > suppose they'll be in 21.2. Well as the package management tools are currently in a 'partly broken' state anything that fixes them could very well go in 21.1 IMHO. Jan

2 participants
2 comments

Re: Seppuku and x_IO_error_handler() 27 years, 1 month

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > I assume that delete_device_internal() eventually calls > XtCloseDisplay(). > > What do you mean by ASAP? As soon as possible. Preferably before any other calls to Xt functions are made. See the other branch of this thread. Jan

1 participants
0 comments

[wishlist item] Export/Import customized item. 27 years, 1 month

Karl M. Hegbloom

Here's a wishlist item for whoever is keeping track of them to tuck away for us... I'd like to be able to run a `M-x export-customized-item' command, sending output to a file, the current buffer, an arbitrary buffer, a variable, (or network socket?), then on my laptop run `M-x import-customized-item' in order to transfer settings from one to the other. The import function ought to be smart enough to merge face specs, possibly prompting for precedence and/or overrides. It should be able to join lists, such as `savehist-history-variables', `After-save-alist', or the `scheme-lock' keyword lists.

1 participants
0 comments

Re: Seppuku and x_IO_error_handler() 27 years, 1 month

Didier Verna

Glynn Clements <glynn(a)sensei.co.uk> writes: > A simple test case seems to indicate that you can longjmp() out of the > IOErrorHandler as long as you delete the `Display *' from the > XtAppContext (if you don't, select() continuously fails). > > The bad news is that: > > a) The XtDeleteFromAppContext function is internal to libXt, and > (worse still): > > b) XtAppContext is an opaque type. It's actually an `_XtAppStruct *', > and _XtAppStruct is defined in InitialI.h, which is an internal Xt > header. We could just copy the definition, but there's no guarantee > that individual vendors haven't made changes to it. > > IOW: there seems to be a solution, but I don't know whether it can be > implemented in a way that doesn't mean that you need the X11 source > code to build XEmacs. I don't understand why you're trying to twiddle the app context. Isn't XtCloseDisplay enough to solve the problem ?

2 participants
1 comments

Re: Macros: Scheme vs Common Lisp 27 years, 1 month

Holger Schauer

>>>>"CL" == Craig Lanning schrieb am Thu, 27 Aug 1998 18:35:21 -0400: CL> You can only pass in an arbitrary environment if you call CL> MACROEXPAND or MACROEXPAND-1 directly. These functions allow an CL> environment to be passed so that programs that analyze CL code CL> (e.g. the compiler) can specify an environment other that the CL> global one. Even "worse": AFAIK, how the environment looks like, is an implementation detail (at least, I haven't found any example in the HyperSpec). -- --- http://www.coling.uni-freiburg.de/~schauer --- "Deine capslock und '!' Tasten klemmen." "Nee, ich habe eine Win95 Tastatur." -- Robin Socha und H.Wulff in de.comp.os.linux.misc

2 participants
1 comments

Re: Seppuku and x_IO_error_handler() 27 years, 1 month

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > I'm afraid you are right. The "correct" behaviour is that killing an > existing X frame deletes all the X frames *on that display*, not on > all displays. If you have only X frames running, it is normal that > XEmacs will exit -- as you say it yourself, that's how X handles > killing. Yes, and this should not be considered bogus anyway. The semantics of *killing* a window is really a loss of connection with this particular display, and it's normal that it affects the whole application. If you want to delete a single (X) window (XEmacs frame), you have the *delete* window manager protocol for that. It often appears just before `kill' in the WM menus. > I have now tried my patch with multiple X connections and the result > is, well, bogus. > > Still, I believe my patch should be applied because it at least > attempts to bring some order to the situation, and makes things work > with the TTY consoles. No problem with me. > > The real pain is that X considers it fatal to loose a connection, > > even in the case you have several ones. > > Yuck! Is there a way around that? Dunno. One day I'll try to return from a fatal io error handler and continue calling Xlib on the other displays if I have some. I'd be curious to see if still works but I doubt it seriously. The other solution I was thinking of was using a set of set/long jmp stuff to go back some place once we know that a connection is broken (the io error handler was called), and try to get rid of the connection ourself. I haven't investigated much yet. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
2 comments

Re: Seppuku and x_IO_error_handler() 27 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > > Dunno. One day I'll try to return from a fatal io error handler and > > > continue calling Xlib on the other displays if I have some. > > > > Hey, that's exactly what my patch does. > > Does it do an XtCloseDisplay ASAP as Peter suggested? I assume that delete_device_internal() eventually calls XtCloseDisplay(). What do you mean by ASAP? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A jury consists of 12 persons chosen to decide who has the better lawyer.

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