August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: X-error in get_mouse_position 26 years, 3 months

Didier Verna

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > but, how??? x_any_window_to_frame doesn't cut it. In a vanilla XEmacs, > if the pointer is in the *scratch* buffer I need to traverse some > steps down the Window hierarchy before I get the frame from > x_any_window_to_frame. For the child_window returned by XQueryPointer > I only get NIL :-( I don't understand this. Another solution to this problem is to enclose the call to XQueryPointer in an ephemeral error handler that would basically do nothing. --didier

1 participants
0 comments

Re: XEmacs 21.0-pre11 "Finnish Landrace" is released 26 years, 3 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > We're down to a very short list of must-do items before release. The Does this include emptying the patch queue? Just to make sure all the fixes that are made (there is two of mine to the base XEmacs) actually go in? Jan

1 participants
0 comments

Re: local and networked X connections 26 years, 3 months

Didier Verna

Glynn Clements <glynn(a)sensei.co.uk> writes: > Note that it does treat ":0" as equivalent to both "localhost:0" and > "127.0.0.1:0", which (IMHO) it probably shouldn't. Yes, and actually, the *canonicalize* routines return "127.0.0.1" in cases of a local connection. The point is that if I have a display of "metheny:0" and call (make-frame-on-display ":0"), it crashes. Conversly, if I have a display of ":0" and call (make-frame-on-display "metheny:0"), it crashes too. I was wondering if it could come from the fact that XEmacs tries to create a new console whereas there's already an existing one. Chuck or Ben, could you explain to me exactly what represents a console (as opposed to a device) under X ? -- / / _ _ 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

1 participants
0 comments

XEmacs 21.0-pre10 "Erzgeberg" is released 26 years, 3 months

SL Baur

Available from the usual places: ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.0/ CVS sources are at http://cvs.xemacs.org/ Installable Lisp packages are in: ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.0/packages/binary-packages/ Jan Vroonhof has made an experimental no-Mule SUMO tarball at: http://www.math.ethz.ch/~vroonhof/emacs/xemacs-sumo-19980811-nomule.tar.gz (Could someone with write access to ftp.xemacs.org make this magically appear somewhere so we don't kill Jan's server? Thanks). This contains minor configure changes, minor build fixes for MS Windows. There are a handful of changes left to make and hopefully pre11 will be the released one. I am woefully short on XEmacs-hacking time, so it will probably slip into September. Note also that the 21.2 CVS tree was synched with these changes and is now at 21.2-beta2-pre3. to 21.0 pre10 "Erzgeberg" -- configure cleanup from Jareth Hein. -- JPEG, GIF MS Windows native build procedure fixes from Jeff Sparkes -- Doc fixes from Martin Buchholz -- Miscellaneous bug fixes from Martin Buchholz

2 participants
1 comments

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

Clemens Heitzinger

sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Clemens" == Clemens Heitzinger <cheitzin(a)rainbow.studorg.tuwien.ac.at> writes: > > Clemens> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > > >> Sure, but there's no guarantee that a given macro has hygienic > >> behavior. Generally, maintaining hygiene this way is pretty tedious, > >> which is why programmers usually don't go to the necessary lengths. > >> > >> Also, a macro might refer to bindings whose names are free in the > >> macro definition. There's no guarantee that you'll get the same > >> bindings for a use that you referred to at the point of definition. > > Clemens> Maintaining hygiene is *not* pretty tedious. If you want your CL macro > Clemens> to be hygienic, use > > Clemens> (defmacro with-hygienic-variables (var &body body) > Clemens> `(let ,(loop for var in vars collect > Clemens> `(,var (make-symbol ,(symbol-name var)))) > Clemens> ,＠body)) > > I'm not sure what you're trying to do. The macro, as it stands, is > buggy. I assume you mean "vars" instead of "var" in the argument list. Obviously yes, sorry for any confusion. > Even then, it's not clear what you're trying to do. It looks just > like some syntactic sugar around renaming variables. Fresh uninterned symbols are made and bound to prevent unintended variable capture. According to the HyperSpec (see make-symbol), (eq (make-symbol "foo") (make-symbol "foo")) => nil What do you mean, "syntactic sugar"? Are macros syntactic sugar? > Clemens> Therefore, in situations where non-hygienic macros have advantages, > Clemens> use a non-hygienic macro. When you want hygienic variables, use the > Clemens> macro above (or write your own define-hygienic-macro, which uses the > Clemens> above). It is as simple as that. > > Unfortunately, no. If used correctly, WITH-HYGIENIC-VARIABLES, can > only prevent inadvertent capture problems. To do this, you still > have to list the variables to be renamed explicitly, and you still > need to get the unquoting right to actually make use of them. Thus, > it makes maintaining hygiene only marginally easier. You still need > all annotations you needed originally, they just become smaller. Look at the example below. The definition of define-hygienic-macro is quite straight-forward, and it's use isn't difficult, either. (defmacro with-hygienic-variables (vars &body body) `(let ,(loop for var in vars collect `(,var (make-symbol ,(symbol-name var)))) ,＠body)) (defmacro define-hygienic-macro (name lambda-list hygienic-vars &body body) `(defmacro ,name ,lambda-list (with-hygienic-variables ,hygienic-vars ,＠body))) (defmacro foo0 (x) `(loop for n from 1 to 10 collect n collect ,x)) (defmacro foo1 (x) (with-hygienic-variables (n) `(loop for ,n from 1 to 10 collect ,n collect ,x))) (define-hygienic-macro foo2 (x) (n) `(loop for ,n from 1 to 10 collect ,n collect ,x)) (let ((n 0)) (foo0 (setq n 10))) => (1 10) (let ((n 0)) (foo1 (setq n 10))) => (1 10 2 10 3 10 4 10 5 10 6 10 7 10 8 10 9 10 10 10) (let ((n 0)) (foo2 (setq n 10))) => (1 10 2 10 3 10 4 10 5 10 6 10 7 10 8 10 9 10 10 10) > Hygiene, however, means that variables in macros obey the same scoping > rules as the rest of the language. WITH-HYGIENIC-VARIABLES gives you > no help whatsoever referring to lexical bindings of the macro. CL What help do you mean? > macros are not hygienic, period. Nobody claimed that. I wanted to make the point that it is quite easy to define hygienic macros in CL. Yours, -- Clemens Heitzinger Student der Techn. Mathematik, Technische Universität Wien, Österreich Vienna University of Technology, Austria

1 participants
0 comments

Re: PMG problems 26 years, 3 months

Karl M. Hegbloom

>>>>> "Amir" == Amir J Katz <amir(a)ndsoft.com> writes: Amir> Mea Culpa. Before I get flamed to death (:-), I was Amir> wrong. The attachment file 'welcome.png' file a was a GIF Amir> file, but I got confused and assigned it the type PNG Amir> because of the name. It looks like a screenshot I made a while ago, when png was first added to XEmacs. I had just installed a new `xv' with png also, and saved the screenshot using a .png extension, but didn't use the menu on the save dialog to set the file type. Apparently, `xv' doesn't auto adjust the file type according to extension.

1 participants
0 comments

Re: PMG problems 26 years, 3 months

Karl M. Hegbloom

>>>>> "Amir" == Amir J Katz <amir(a)ndsoft.com> writes: Amir> welcome.png - displays OK in xv 3.10a, fails in xemacs; Same here... file /tmp/welcome.png /tmp/welcome.png: GIF image data, version 87a, 337 x 265, Anyone else feel a deja vu? :-) Amir> opussum.png - displays OK in xemacs, fails in xv; This one displays the same in both. Are you sure your `xv' has "png"?

1 participants
0 comments

source-directory is no more 26 years, 3 months

Vin Shelton

I see that starting with b54, the variable source-directory has been removed. I used to use it to find the origin of the XEmacs source tree, more specifically, the place I could find the TAGS file. I found this generally useful when I was browsing either my own customizations or the XEmacs source. What follows is how I used to do this; I'm sure there's another way to do this - can anyone offer any suggestions? (if (string= (substring source-directory -5) "/lisp") (setq xemacs-source-directory (substring source-directory 0 (- (length source-directory) 5))) (setq xemacs-source-directory source-directory)) (setq tag-table-alist '(("\\.emacs$" . xemacs-source-directory) ("/lisp" . xemacs-source-directory) ((progn (condition-case nil (or (string-match xemacs-source-directory (buffer-file-name)) nil) (error nil))) . xemacs-source-directory))) Thanks in advance, vin

1 participants
0 comments

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> >> a) Add them as another datatype comletely separate from Elisp >> >> fixnums, with explicit coercions back and forth. >> >> >> >> This, I believe, is possible with minimal changes to the Elisp >> >> machine, even though it's still a sufficiently hairy job, 'cause >> >> you need to interface with the garbage collector in a suitable >> >> way. >> Hrvoje> Not hairy at all. Have you looked at Hrvoje> DEFINE_LRECORD_IMPLEMENTATION? It allows you to specify a Hrvoje> callback routine for the GC. >> >> I wasn't thinking about tracing, but rather about the fact that >> (according to my totally naive view of how efficient bignum >> arithmetic works), with some bignum operations, it may not be >> possible to know the size of the result without actually computing >> it. Hrvoje> I still don't understand the problem. Even if it is true that the Hrvoje> size of the resulting number is unknown (and I am not convinced in Hrvoje> this!), Huh? Subtract two very large numbers from each other. The only way I see of finding out how big the result is is to perform the subtraction. Hrvoje> you are still quite free to use realloc() and friends to Hrvoje> adjust the size incrementally. Not if the bignum is supposed to live in the Emacs Lisp heap. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Hrvoje> I still don't understand the problem. Even if it is true > Hrvoje> that the size of the resulting number is unknown (and I am > Hrvoje> not convinced in this!), > > Huh? Subtract two very large numbers from each other. The maximum storage requirements of the result can be predicted with good precision. Of course, you cannot know *exactly* how many digits the result will take (in the case of subtraction, it can always be smaller than the maximum storage), but that's probably not important. Is exact allocation what you meant by "efficient" bignum arithmetic implementation? > Hrvoje> you are still quite free to use realloc() and friends to > Hrvoje> adjust the size incrementally. > > Not if the bignum is supposed to live in the Emacs Lisp heap. If you implement bignums as lcrecords (which is the only meaningful way of implementing them in the current framework), nothing prevents you from a "bignum" being a C structure that encapsulates the bignum structure as seen by the multiprecision library. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Speak softly and carry a +6 two-handed sword.

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