August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

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

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Could someone more knowledgable of Xt programming (Didier? Glynn?) > explain if it's OK to add XSync's to various places to ensure that the > information returned by Xt is proper? It's generally a bad idea to use XSync for something else than debugging, because it synchronizes the application with the server itself. XSync will return only when the X server has finished processing all its requests. The consequence is that it can considerably slow down the application, because you'll be blocked waiting for all events to be processed, even those completely unrelated to your problem. When a synchronization problem occurs, it's almost always the application's fault (a lack of consistency checking) and always a bad idea to synchronize with the server. The better solution is to check internally for consistency. Here it means checking that this window still belongs to a frame before enquiring the server about an XPointer information. -- / / _ _ 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

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

Hrvoje Niksic

Simon Josefsson <jas(a)pdc.kth.se> writes: > > We should either do it correctly, or not do it at all, as far as I'm > > concerned. > > Since my lack of knowledge of XEmacs internals prevents me from > doing it properly, I just wanted bignums for doing some > authentication/encryption stuff. The `calc' package will be enough > for me until I want performance. Don't get your hopes up. `calc' routines might be *really* slow. :-( -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Listen, kid, we're all in it together!" -- Harry Tuttle in _Brazil_

1 participants
0 comments

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

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Why is the XSync solution not OK? Because it randomly adds an XSync to x_get_mouse_position(). This means that, for instance, every time someone invokes `mouse-pixel-position', XSync gets called. For some reason, this feels wrong, and the original patch author seems to share this feeling. Could someone more knowledgable of Xt programming (Didier? Glynn?) explain if it's OK to add XSync's to various places to ensure that the information returned by Xt is proper? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- We must all confront and destroy our own inner geek.

1 participants
0 comments

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

Simon Josefsson

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Simon Josefsson <jas(a)pdc.kth.se> writes: > > > I wasn't thinking about adding a elisp type for bignums (I guess this > > is what you're refeering to?) but instead have the MP-routines use a > > internal representation (a vector containg bytes or something) and > > have a function like gmp-print for printing the numbers as a string. > > > > GMP works like this in C so this would be the most natural solution. > > Yuck! This is *far* from natural for me, because bignums have a > tradition of being correctly implemented in various Lisps. I agree, that's why I was so surprised this wasn't already implemented. > We should either do it correctly, or not do it at all, as far as I'm > concerned. Since my lack of knowledge of XEmacs internals prevents me from doing it properly, I just wanted bignums for doing some authentication/encryption stuff. The `calc' package will be enough for me until I want performance. In this case, a native bignum implementation or a elisp-library that uses GMP is equally good for my purposes. /s

1 participants
0 comments

Re: How many branches? [was: [for 20.2] ~user completion] 26 years, 3 months

Greg Klanderman

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> ... >> P.S. -- I've also made some major changes to Frederic Lepied's cvs.el, >> if anyone's interested (someday, I'll send these changes back to >> him ;-(). sb> sb> Yes! I'm hoping to get updated cvs.el into the Lisp packages under sb> the wire. Frédéric is still working on it, so it is definitely a live sb> package. It would be nice if cvs.el and pcl-cvs.el did not both define the functions cvs-mode and cvs-status, and the variable cvs-shell. Amazingly these seem to be the only clashes, though there are many symbols that are very close, as both use the cvs- prefix. This should allow both to coexist nicely, though I have not investigated fully. Last I looked, it seemed that cvs.el's cvs-mode would be more appropriately named cvs-minor-mode. Cvs-shell is not a problem. I'm not sure what to do about cvs-status. btw- I really do plan to synch us w/ pcl-cvs 2.0 one of these days... greg

1 participants
0 comments

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

Didier Verna

Didier Verna <verna(a)inf.enst.fr> writes: Hmmm ... > xemacs -vanilla > M-x (find-device "metheny:0") => #<x-device blahb;ah> ^^^^^ read blah :-) > M-x (find-console "metheny:0") => #<x-device blahb;ah> ^^^^^^ read console

1 participants
0 comments

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

Simon Josefsson

karlheg(a)inetarena.com (Karl M. Hegbloom) writes: > There are math functions in the `calc' package that give you > arbitrary precision and bignums. The info says you can use it from > lisp programs, it sounds like it was designed with that in mind. Thanks, I already had calc installed. :-) Unless performance turns out to be too critical, I'll forget about the GMP idea.

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 DEFINE_LRECORD_IMPLEMENTATION? Hrvoje> It allows you to specify a 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. For example, can you shrink an object after creating it? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

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

Jan Vroonhof

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > Martin suggested WINDOW_LIVE_P from window.h but unless I am mistaken > this refers to XEmacs windows and not XWindows Windows (mind the > capital W). > > Any ideas? Or suggestions for a good intro book to X? Currently I only > have the man-pages :-( Maybe you could move the call f = x_any_window_to_frame (d, win); if (!f) return 0; to before the loop. Since frames are biggest structures we support, if it is not a window of a frame there is no use iterating down anyway. I am not an X expert but from the look of things it seems it should work. Jan Why is the XSync solution not OK? Isn't the problem that we are getting return outdated information because Xt has a backlog processing events.

1 participants
0 comments

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

Karl M. Hegbloom

There are math functions in the `calc' package that give you arbitrary precision and bignums. The info says you can use it from lisp programs, it sounds like it was designed with that in mind. I guess it uses lists to hold numbers, represented in base-1000.

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